Tout responsable de système d’information sanitaire en Afrique de l’Ouest finit par se poser la question : faut-il déployer DHIS2, OpenMRS, ou un autre logiciel ? Les deux noms reviennent dans chaque appel d’offres, chaque atelier de l’OMS, chaque mémoire d’étudiant en santé publique. Sauf qu’on les confond — ce sont en réalité deux outils complémentaires, pas concurrents, et savoir lequel ouvrir dépend entièrement de la question qu’on cherche à résoudre.
Cet article pose la grille de décision pour un ministère de la santé, une ONG, un district sanitaire ou une équipe de développement basée à Dakar, Abidjan, Cotonou, Bamako, Ouagadougou, Conakry, Niamey ou Lomé. Pas un tutoriel d’installation — un cadre de choix appuyé sur les caractéristiques techniques et organisationnelles réelles des deux plateformes en 2026.
La différence fondamentale : HMIS versus EMR
Avant de comparer license, stack ou communauté, il faut comprendre que DHIS2 et OpenMRS ne résolvent pas le même problème. DHIS2 est un Health Management Information System (HMIS) agrégé : il collecte des indicateurs (nombre de consultations par mois, taux de couverture vaccinale par district, stock de médicaments restant) pour piloter la santé publique à l’échelle d’un pays ou d’une région. OpenMRS est un Electronic Medical Record (EMR) individuel : il garde la trace du patient (consultations, prescriptions, résultats de labo, allergies, antécédents) pour soigner une personne précise dans un hôpital ou une clinique.
Concrètement : un agent du ministère qui veut savoir « combien d’enfants ont reçu le vaccin contre la rougeole dans la région de Kaolack en mars 2026 » ouvre DHIS2. Un médecin qui consulte « monsieur Ndiaye Mamadou, 47 ans, suivi pour HTA depuis 2022 » ouvre OpenMRS. Les deux requêtes ne se font pas sur les mêmes données, ne demandent pas la même architecture, et n’engagent pas la même chaîne de responsabilité légale.
DHIS2 en bref
DHIS2 est développé depuis 2004 par le Health Information Systems Programme (HISP Centre) de l’université d’Oslo, désigné en 2017 WHO Collaborating Centre. La version 42 (sortie courant 2026) est la dernière en date ; les versions 40, 41 et 42 sont supportées simultanément. Le cycle de release est annuel avec des correctifs trimestriels.
L’OMS reconnaît DHIS2 comme global public good. En 2026, le logiciel est utilisé comme HMIS national par plus de 80 ministères de la santé dans des pays à revenu faible ou intermédiaire. En intégrant les programmes ONG, l’outil dépasse 100 pays et couvre des indicateurs sanitaires concernant environ 3,2 milliards de personnes, soit 40 % de la population mondiale.
Stack technique : DHIS2 est écrit en Java (Spring framework), s’appuie sur PostgreSQL comme base de données, et expose une API REST sur laquelle se connectent une application web (Web App) et une application mobile Android (DHIS2 Android Capture). License : BSD 3-clause, la plus permissive — vous pouvez forker, modifier, redistribuer, même dans un produit commercial, à condition de garder le copyright original.
OpenMRS en bref
OpenMRS naît en 2004 d’une collaboration entre Regenstrief Institute (Indianapolis), Partners In Health (Boston) et plusieurs équipes africaines, notamment AMPATH au Kenya. La version de référence actuelle (Reference Application 3.x, surnommée O3) propose une interface React moderne au-dessus du moteur Java historique. Une démo publique tourne en permanence sur o3.openmrs.org pour qui veut tester sans installer.
Architecture : OpenMRS suit un design modulaire articulé en trois couches (interface utilisateur, services métier, accès aux données). Le cœur (openmrs-core) gère les concepts médicaux génériques, et chaque besoin spécifique — laboratoire, pharmacie, facturation, télémédecine — vient en module .omod qu’on installe à la demande. Cette modularité permet de partir d’une base commune et de l’adapter au contexte d’un hôpital de district burkinabè comme d’un CHU sénégalais.
Stack technique : Java avec Spring, base de données MySQL ou MariaDB par défaut (PostgreSQL possible), front-end O3 en React, API REST + FHIR. License : Mozilla Public License 2.0 avec Healthcare Disclaimer (MPL 2.0 w/HD) — copyleft modéré qui oblige à publier les modifications de fichiers existants, mais n’oblige pas à libérer les modules tiers.
Comparaison tête à tête
| Critère | DHIS2 | OpenMRS |
|---|---|---|
| Type de SIH | HMIS — données agrégées | EMR — dossier patient individuel |
| Échelle visée | National, régional, district | Établissement (hôpital, clinique) |
| Utilisateur principal | Statisticien santé publique, ministère | Médecin, infirmier, pharmacien |
| Question type | « Combien et où ? » | « Qui et quoi pour ce patient ? » |
| License | BSD 3-clause | MPL 2.0 w/HD |
| Stack backend | Java / Spring / PostgreSQL | Java / Spring / MySQL ou MariaDB |
| Front-end | Apps Web et Android natives | React (Reference App 3.x) |
| API standard | REST DHIS2 propriétaire | REST + FHIR R4 |
| Adoption | 80+ pays comme HMIS national | Implémentations dans 80+ pays |
| Backers institutionnels | WHO, HISP Centre, U. Oslo | Regenstrief, Partners In Health |
| Cycle de release | Annuel (3 versions supportées) | Continu (Reference App) |
| Capacité de personnalisation | Forms designer, programmes | Modules .omod sur mesure |
Quand choisir DHIS2
DHIS2 est le bon outil dès que la question relève du pilotage à l’échelle. Un ministère de la santé qui veut consolider mensuellement les rapports d’activité de 1 200 structures sanitaires y trouve ce qu’il cherche : un modèle de données pensé pour les indicateurs, des dashboards publics, des analyses pivot sur dimensions multiples (temps, lieu, programme, démographie). Le module Tracker de DHIS2 permet aussi de suivre des cas individuels — vaccination, surveillance des maladies à potentiel épidémique, suivi de grossesse — mais sans la profondeur clinique d’un EMR.
Trois signaux qui orientent vers DHIS2 : le besoin de remontée standardisée vers l’OMS et les bailleurs (Gavi, Fonds mondial, USAID), le besoin de tableaux de bord publics par district, et le besoin de surveillance épidémiologique en temps quasi-réel.
Quand choisir OpenMRS
OpenMRS est le bon outil dès que la question relève des soins individuels. Un hôpital régional qui veut numériser les dossiers patients (consultations, prescriptions, résultats de labo, ordonnances, allergies, antécédents familiaux) y trouve un socle robuste et personnalisable. La conformité FHIR R4 native facilite l’interopérabilité avec un laboratoire, une pharmacie ou un autre établissement utilisant un EMR différent.
Trois signaux qui orientent vers OpenMRS : un projet d’établissement clinique (pas de pilotage statistique), un besoin de continuité de soins (le patient revient et son historique doit s’afficher), et la nécessité d’extensions métier spécifiques via modules .omod (par exemple un module dispensation pharmaceutique adapté aux médicaments génériques locaux).
Choisir les deux : l’architecture combinée
Dans la plupart des implémentations matures en Afrique de l’Ouest, la bonne réponse n’est pas « DHIS2 ou OpenMRS » mais « DHIS2 et OpenMRS, intégrés ». OpenMRS gère le dossier patient au point de soin. Une couche d’agrégation (souvent via OpenHIM ou un script ETL) extrait périodiquement les indicateurs anonymisés et les remonte dans DHIS2 pour le reporting. Le ministère pilote, l’hôpital soigne, et chacun voit ce qui le concerne.
Le pivot d’interopérabilité s’appuie sur FHIR R4, le standard d’échange clinique porté par HL7. OpenMRS exporte des ressources FHIR natives ; DHIS2 propose un module FHIR encore en maturation. Pour l’implémentation pratique d’un serveur FHIR (HAPI) entre les deux, le tutoriel FHIR pour l’interopérabilité santé en Afrique détaille la chaîne de bout en bout.
Adapter le choix au contexte ouest-africain
Trois contraintes locales pèsent sur la décision et le déploiement. Première : la souveraineté des données. Les lois nationales de protection des données (Sénégal 2008, Côte d’Ivoire 2013, Burkina Faso 2004 puis 2021, Mali 2013, Bénin 2017) et la directive CEDEAO sur la protection des données personnelles imposent que les données de santé restent sur le territoire national ou à défaut sur le continent. DHIS2 et OpenMRS étant tous deux auto-hébergeables, ils respectent ce cadre — à condition de choisir un hébergement souverain (datacenter national type SONATEL, ADC Côte d’Ivoire, Liquid Intelligent, ou un VPS européen comme Hetzner pour réduire les coûts en attendant). L’article santé numérique conforme CEDEAO détaille l’architecture sécurisée recommandée.
Deuxième contrainte : la connectivité. Dans les districts ruraux, internet est intermittent. DHIS2 Android Capture supporte nativement la collecte hors-ligne avec synchronisation différée. OpenMRS Reference App fonctionne en mode hors-ligne partiel via Service Workers, mais la complétude offline reste imparfaite. Pour un projet de soins en zone rurale, prévoir un déploiement local sur serveur de la formation sanitaire avec synchronisation périodique vers un nœud central.
Troisième : le budget total. Les deux logiciels sont gratuits, mais l’écosystème ne l’est pas. Coût d’hébergement (300 à 2 000 € par an pour un VPS Hetzner type CCX13 à CCX33 selon la charge), coût de l’expertise (consultant DHIS2 entre 25 000 et 60 000 F CFA par jour à Dakar, plus rare et plus cher pour OpenMRS), coût de la formation du personnel (5 à 15 jours-personnes par site). Sous-estimer l’expertise d’implémentation est l’erreur n° 1 des projets de SIH en Afrique.
Erreurs fréquentes lors du choix
| Erreur | Cause | Solution |
|---|---|---|
| Vouloir faire de l’EMR clinique avec DHIS2 Tracker | Confusion HMIS / EMR, économie supposée d’un seul outil | Garder DHIS2 pour le pilotage, déployer OpenMRS pour le soin individuel |
| Vouloir faire du reporting national avec OpenMRS seul | Bonne expérience hospitalière, extrapolation abusive | Garder OpenMRS au point de soin, ajouter DHIS2 pour l’agrégation |
| Choisir sans formuler la question métier | Pression du bailleur ou de l’éditeur | Spécifier d’abord 3 à 5 cas d’usage prioritaires, puis tester l’outil sur ces cas |
| Sous-estimer le coût d’expertise | Logiciel gratuit confondu avec déploiement gratuit | Prévoir 30 à 50 % du budget total pour l’expertise et la formation |
| Déploiement sans plan d’interopérabilité | Silos de données entre DHIS2 et OpenMRS | Adopter FHIR dès la conception, prévoir OpenHIM ou équivalent comme bus d’échange |
Foire aux questions
Peut-on installer DHIS2 et OpenMRS sur le même serveur ?
Techniquement oui, mais pas recommandé en production. Les deux applications consomment chacune 4 à 8 Go de RAM en charge et ont des cycles de mises à jour différents. Mieux : deux VPS distincts (ou deux conteneurs LXC sur un même hôte si le budget l’impose) reliés par un réseau privé.
Quelle est la courbe d’apprentissage pour un dev junior ?
DHIS2 est plus abordable côté configuration (interface web pour créer dataset, indicateurs, dashboards). OpenMRS demande une maîtrise Java plus solide pour écrire des modules métier. Pour un dev junior francophone, viser DHIS2 en premier, puis basculer sur OpenMRS si le projet l’exige.
Existe-t-il une certification officielle ?
HISP Centre propose des académies DHIS2 régulièrement, et HISP West & Central Africa (HISP WCA) — qui appuie 23 pays de la zone et organise des sessions à Dakar, Abidjan ou Yaoundé — forme et certifie des experts régionaux. OpenMRS propose des badges de contribution mais pas de certification commerciale officielle ; la reconnaissance vient surtout de l’historique de PR mergées dans openmrs-core et les modules officiels.
FHIR remplace-t-il DHIS2 ou OpenMRS ?
Non. FHIR est un standard d’échange, pas une application. C’est le format dans lequel les deux outils peuvent dialoguer entre eux et avec des partenaires externes (assurance maladie, labos, télémédecine). Penser FHIR comme HTTP : essentiel pour faire communiquer les systèmes, mais pas un système en soi.
Quel niveau d’investissement initial pour un démarrage pilote ?
Pour un pilote DHIS2 couvrant un district sanitaire de 50 à 100 structures : 3 à 6 mois de mise en place, un VPS à 50 € par mois, 30 à 50 jours-consultant pour la configuration et la formation, soit un ordre de grandeur de 6 à 15 millions de F CFA. Pour un pilote OpenMRS dans un hôpital de 200 lits : 6 à 12 mois, infrastructure similaire, 60 à 100 jours-consultant pour personnaliser les modules métier, soit 12 à 30 millions de F CFA.
Que disent les bailleurs ?
Gavi, Fonds mondial, Banque mondiale, USAID, GIZ et OOAS poussent DHIS2 comme socle de remontée d’indicateurs depuis 2017. Pour l’EMR clinique, ces mêmes bailleurs financent souvent OpenMRS ou des solutions propriétaires (Bahmni — distribution d’OpenMRS qui agrège OpenMRS pour le dossier patient, Odoo pour la facturation, OpenELIS pour le laboratoire — est déployée dans plus de 50 pays, notamment au niveau national en Tanzanie, au Lesotho et au Bangladesh, et progresse en zone francophone).
Ressources officielles
- dhis2.org — site officiel, téléchargements, documentation, communauté HISP
- docs.dhis2.org — documentation utilisateur et développeur DHIS2 version par version
- openmrs.org — site officiel, démos, modules, calendrier des squad meetings
- wiki.openmrs.org — wiki communautaire, guides d’implémentation et de développement
- o3.openmrs.org — démo publique OpenMRS Reference Application 3.x à explorer sans installer
- community.dhis2.org et talk.openmrs.org — forums communautaires actifs où poser ses questions