Déployer OpenMRS sur Hetzner Cloud : tutoriel 2026

📍 Article principal : Santé numérique conforme CEDEAO 2026

Introduction

Un cabinet pédiatrique à Bouaké voulait passer du papier à un système numérique pour gérer ses 3 500 patients actifs. Budget contraint, équipe technique réduite (un consultant externe à temps partiel), exigences de sécurité et de conformité fortes. Le déploiement d’OpenMRS sur un VPS Hetzner CX32 a été réalisé en deux semaines avec configuration sécurité de base, sauvegardes automatisées, et formation du personnel médical. Coût mensuel total : 18 euros (VPS et sauvegardes), bien inférieur à toute solution SaaS commerciale équivalente. Ce tutoriel décrit pas à pas le déploiement complet, depuis la création du VPS jusqu’à la mise en production avec premier patient enregistré.

Prérequis

• Compte Hetzner Cloud avec moyen de paiement
• Domaine pour l’application (par exemple cabinet.example.sn)
• Connaissances de base SSH, Docker, et administration Linux
• Niveau : intermédiaire — Temps : 4-6 heures pour le déploiement initial

Étape 1 — Provisionner le VPS

OpenMRS 3 demande des ressources modérées : 4 Go de RAM minimum, 40 Go de disque, 2 vCPUs. Sur Hetzner, le CX32 (4 vCPU, 8 Go RAM, 80 Go SSD) à 8,49 euros HT par mois est le bon dimensionnement pour un cabinet de 5 000 patients ou moins. Pour des structures plus importantes (clinique avec plusieurs services), monter à CX42 (8 vCPU, 16 Go RAM) à 16 euros par mois.

# Création VPS via console Hetzner ou hcloud CLI
hcloud server create --name openmrs-cabinet --type cx32 --image debian-12 --location nbg1 --ssh-key ma-cle

Localisation Nuremberg (NBG1) ou Falkenstein (FSN1) — latence depuis l’Afrique de l’Ouest comparable. Choix du pays ne change rien au RGPD. Une fois le VPS créé, configurer le firewall Hetzner pour n’ouvrir que les ports 22 (SSH), 80 (HTTP), 443 (HTTPS) — aucun autre port public.

Étape 2 — Configuration base du serveur

Connexion en SSH puis hardening de base : créer un utilisateur non-root pour le déploiement, désactiver l’auth root et l’auth par mot de passe, installer Docker et Docker Compose. Cette base prend 30 minutes mais pose les fondations sécurité essentielles. Voir notre tutoriel détaillé VPS SSH hardening pour le pas-à-pas complet.

adduser openmrs
usermod -aG sudo openmrs
mkdir -p /home/openmrs/.ssh && cp /root/.ssh/authorized_keys /home/openmrs/.ssh/
chown -R openmrs:openmrs /home/openmrs/.ssh

# Installation Docker
curl -fsSL https://get.docker.com | sh
usermod -aG docker openmrs

# Désactiver auth root SSH
sed -i 's/^PermitRootLogin.*/PermitRootLogin no/' /etc/ssh/sshd_config
sed -i 's/^#?PasswordAuthentication.*/PasswordAuthentication no/' /etc/ssh/sshd_config
systemctl reload ssh

Étape 3 — Déployer OpenMRS via Docker Compose

OpenMRS fournit une image Docker Compose officielle qui démarre la stack complète : MariaDB pour la base, OpenMRS Backend Java, OpenMRS Frontend React 3, FHIR module activé. Cloner le repo officiel et adapter la configuration pour la production.

cd /home/openmrs
git clone https://github.com/openmrs/openmrs-distro-referenceapplication.git
cd openmrs-distro-referenceapplication
# Adapter docker-compose.yml pour production
# - persister les volumes mariadb et openmrs-data
# - configurer les variables d'environnement (mot de passe DB, etc.)
# - activer FHIR via les modules de référence

docker compose up -d

Le démarrage initial prend 10 à 15 minutes pour télécharger les images, initialiser la base, et précharger les concepts médicaux. Pendant ce temps, on configure le reverse proxy. Une fois démarré, OpenMRS écoute sur le port 8080 par défaut — non exposé directement, on passe par Caddy.

Étape 4 — Reverse proxy Caddy avec HTTPS

Caddy obtient automatiquement le certificat Let’s Encrypt et gère HTTPS sans configuration. Installation et config en cinq lignes. Le domaine doit pointer DNS vers l’IP du VPS avant le démarrage de Caddy.

apt install -y caddy

cat > /etc/caddy/Caddyfile <<EOF
cabinet.example.sn {
    reverse_proxy localhost:8080
    encode gzip
    header {
        Strict-Transport-Security "max-age=31536000"
        X-Content-Type-Options "nosniff"
    }
    log {
        output file /var/log/caddy/access.log
        format json
    }
}
EOF

systemctl reload caddy

Une fois propagation DNS faite, l’application est accessible via HTTPS sur l’URL publique. Tester avec un navigateur : on arrive sur la page de connexion OpenMRS avec admin/Admin123 par défaut. Premier réflexe critique : changer immédiatement ce mot de passe pour un mot de passe robuste, puis créer les comptes utilisateurs réels du cabinet.

Étape 5 — Configuration spécifique cabinet

OpenMRS est ultra-flexible : on configure les concepts médicaux, les formulaires, les rapports selon les besoins du cabinet. Pour un cabinet pédiatrique à Bouaké, la configuration initiale inclut typiquement le carnet de vaccination conforme au calendrier ivoirien, la croissance enfant (poids, taille, périmètre crânien) avec courbes OMS, les motifs de consultation fréquents, et les antécédents familiaux. Cette personnalisation prend deux à trois jours pour un cabinet typique et peut être faite par un consultant familier d’OpenMRS.

Pour les patients, la création se fait via formulaire web avec champs adaptés : nom complet, date de naissance, sexe, contact tuteur (parents pour pédiatrie), adresse libre (point de repère pour les zones sans adresse formelle). OpenMRS génère automatiquement un identifiant unique patient utilisable pour les recherches futures. Pour un cabinet qui démarre, importer les patients existants depuis un export Excel se fait via l’API REST en quelques heures.

Étape 6 — Sauvegardes automatisées

Les données patients étant critiques, une stratégie de sauvegarde robuste est non-négociable. Le dump MariaDB nocturne chiffré GPG envoyé vers Hetzner Object Storage primaire et Backblaze B2 secondaire. Voir notre tutoriel Sauvegardes rclone pour le pattern complet. Pour OpenMRS spécifiquement, le dump inclut la base MariaDB et le dossier des fichiers uploadés (résultats labo PDF, photos cliniques).

#!/usr/bin/env bash
DATE=$(date +%Y%m%d)
docker exec openmrs-mariadb mariadb-dump -u root -p${DB_ROOT_PASSWORD} openmrs \
  | gzip \
  | gpg --batch --passphrase-file /root/.backup-pass --symmetric \
  | rclone rcat hetzner:openmrs-backups/db-${DATE}.sql.gz.gpg

docker exec openmrs-backend tar czf - /openmrs/data \
  | gpg --batch --passphrase-file /root/.backup-pass --symmetric \
  | rclone rcat hetzner:openmrs-backups/files-${DATE}.tar.gz.gpg

# Rétention 30 jours
rclone delete --min-age 30d hetzner:openmrs-backups/

Cron quotidien à 2h du matin GMT. Test trimestriel de restauration sur un VPS jetable pour valider que la procédure marche réellement. Sans ce test régulier, la sauvegarde est illusoire.

Étape 7 — Sécurité et 2FA

Pour la protection des comptes, configurer la 2FA via TOTP. OpenMRS 3 supporte nativement les modules d’authentification additionnels. Activer aussi le verrouillage temporaire après 5 tentatives échouées (protection brute force) et la complexité minimale du mot de passe (12 caractères, mélange casse, chiffre, symbole). Configurer la session timeout à 30 minutes d’inactivité — protection contre l’écran resté ouvert sans surveillance.

Pour le chiffrement applicatif des champs ultra-sensibles (numéro CNI, antécédents psychiatriques), OpenMRS supporte des champs chiffrés via configuration. La clé de chiffrement est stockée séparément dans Hashicorp Vault ou une variable d’environnement protégée. Cette configuration ajoute deux jours de paramétrage mais offre une protection forte en cas de compromission base.

Erreurs fréquentes

Adaptation au contexte ouest-africain

Trois aspects pratiques. Premièrement, le calendrier vaccinal ivoirien diffère légèrement du PEV OMS standard — adapter les concepts d’OpenMRS pour intégrer les vaccins spécifiques (méningite ACWY, hépatite A) selon les recommandations du Programme National Elargi de Vaccination du pays. Deuxièmement, les paiements espèces et mobile money cohabitent — intégrer le module facturation OpenMRS avec un connecteur Wave/Orange Money pour les encaissements digitaux. Troisièmement, la dématérialisation progressive des ordonnances impose un format papier conservé en archive plus l’envoi numérique au patient via WhatsApp ou SMS. Cette double sortie satisfait à la fois les contraintes administratives et les usages réels des patients.

Pour les coûts complets, le déploiement initial revient à 200-500 euros (consultant + paramétrage), plus environ 20 euros par mois en opération. Pour un cabinet ou clinique modeste, l’investissement se rentabilise en quelques mois via les gains de productivité administrative et la qualité de soins améliorée.

Tutoriels frères

• FHIR pour l’interopérabilité
• Audit trail et conformité
• App patient mobile

Pour aller plus loin

• 🔝 Pilier : Santé numérique CEDEAO
• Articles : Hetzner Cloud Afrique
• Doc : OpenMRS Reference Application

FAQ

OpenMRS supporte-t-il vraiment plusieurs cliniques ?
Oui via les « Locations » qui partitionnent les patients et les utilisateurs. Pour un réseau de cliniques, c’est la fonctionnalité de base à activer.

Combien de patients un VPS CX32 supporte-t-il ?
Environ 50 000 patients actifs avec des consultations régulières. Au-delà, monter à CX42 ou découper en plusieurs instances par site.

Peut-on utiliser PostgreSQL au lieu de MariaDB ?
OpenMRS 3 supporte officiellement MariaDB et MySQL. PostgreSQL est possible avec adaptations mais non recommandé sauf besoin spécifique.

Faut-il un développeur Java pour personnaliser ?
Pour des modules custom oui. Pour la configuration standard (concepts, formulaires, rapports), un consultant OpenMRS sans Java suffit largement.

Patterns avancés de production

Trois patterns améliorent significativement la robustesse opérationnelle d’OpenMRS en production. Le premier est la mise en place d’un read replica PostgreSQL dédié aux rapports et exports lourds. Sans cela, les requêtes statistiques mensuelles peuvent dégrader temporairement les performances de l’application clinique pendant que le médecin essaie d’enregistrer une consultation. Le deuxième pattern est la séparation logique entre le serveur OpenMRS principal et un serveur de fichiers (uploads PDF, images radiologiques) — typiquement Hetzner Object Storage ou Orthanc auto-hébergé pour DICOM. Cette séparation simplifie la sauvegarde et libère le disque du serveur principal qui peut rester compact. Le troisième pattern est le monitoring proactif via Better Stack ou Uptime Kuma : alertes immédiates sur 500 erreurs, latence anormale, espace disque critique. Ces alertes permettent de réagir avant que les utilisateurs ne signalent le problème.

Pour les structures qui veulent aller plus loin, considérer la haute disponibilité via deux instances OpenMRS derrière un load balancer Caddy avec PostgreSQL répliqué. Cette architecture multiplie le coût par deux mais élimine le single point of failure. Pour les cabinets et petites cliniques, c’est généralement de l’over-engineering — un seul serveur bien sauvegardé suffit avec un RTO de quelques heures acceptable. Pour les hôpitaux ou cliniques d’urgence, la haute dispo peut se justifier.

Formation et accompagnement du personnel

L’investissement technique est rarement le facteur limitant — c’est l’acceptation par le personnel médical. Trois principes pratiques améliorent l’adoption. Premièrement, déployer progressivement par fonctionnalité : commencer par le dossier patient simple, ajouter ensuite les prescriptions, puis les rapports, puis les fonctionnalités avancées. Cette approche permet à chaque utilisateur d’absorber les nouveautés sans submersion. Deuxièmement, désigner des champions internes parmi les médecins les plus enthousiastes : ils deviennent référents pour leurs collègues et accélèrent l’adoption par effet pair. Troisièmement, prévoir un support technique réactif pendant les premiers mois — un canal WhatsApp dédié où l’équipe technique répond rapidement aux questions élimine les blocages qui décourageraient sinon les utilisateurs.

Pour la formation initiale, deux journées intensives plus deux semaines de support rapproché donnent typiquement 80 % d’autonomie. Les médecins moins à l’aise avec le numérique demandent 5-10 sessions individuelles supplémentaires. Cet investissement pédagogique conditionne le retour sur investissement réel : un système techniquement parfait mais peu utilisé n’apporte aucune valeur. Pour les agences techniques qui livrent ces déploiements, intégrer formation et accompagnement dans l’offre commerciale rend les clients beaucoup plus satisfaits que la simple livraison technique.

Évolution OpenMRS et roadmap 2026-2028

OpenMRS continue d’évoluer avec sa communauté internationale active. Trois évolutions majeures attendues à court terme. Premièrement, l’amélioration de l’interface utilisateur du Reference Application 3 avec un design plus moderne et plus rapide pour les utilisateurs sur smartphones et tablettes — particulièrement utile pour les médecins en pédiatrie ou en visite à domicile qui privilégient les interfaces tactiles. Deuxièmement, l’intégration FHIR plus profonde avec import/export massif via Bundle, alignement strict sur les profils nationaux des pays d’utilisation. Troisièmement, l’intelligence artificielle médicale via plugins : aide au diagnostic, alertes automatiques sur prescriptions à risque, prédiction des complications. Ces fonctionnalités demandent prudence éthique mais offrent des gains concrets quand bien implémentées.

Pour les cabinets qui adoptent OpenMRS aujourd’hui, ces évolutions arriveront naturellement par mises à jour Docker — pas de migration coûteuse à anticiper. La continuité d’investissement de la communauté garantit que la plateforme reste pertinente plusieurs années. Pour les agences techniques, suivre les conférences OpenMRS Africa annuelles et participer aux groupes de travail régionaux maintient l’expertise à jour et ouvre des opportunités de collaboration.