Audit trail et conformité CEDEAO en santé numérique : tutoriel 2026

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

Introduction

Une clinique privée d’Abidjan a reçu en juin 2025 une plainte d’un patient : son médecin traitant n’aurait jamais consulté son dossier alors qu’il l’avait sollicité par téléphone. Sans audit trail, impossible de démontrer ni qui avait accédé au dossier, ni quand. La direction a passé deux semaines à rechercher manuellement dans des logs partiels et des emails, sans pouvoir conclure clairement. Cet incident a déclenché la mise en place urgente d’un audit trail systématique : chaque consultation de dossier, chaque modification, chaque export est désormais journalisé avec timestamp, utilisateur, IP, action. Lorsque le même type de plainte est arrivée six mois plus tard, le dossier complet a été produit en 5 minutes, démontrant clairement les accès effectifs et résolvant le litige. Ce tutoriel détaille l’implémentation d’un audit trail robuste et conforme aux exigences CEDEAO en matière de protection des données de santé.

Prérequis

• Plateforme santé numérique fonctionnelle
• Base de données PostgreSQL ou MariaDB
• Backend Node, Bun, Deno, ou Python
• Compréhension des principes RGPD et CEDEAO sur la protection des données
• Niveau : intermédiaire — Temps : 3 heures

Étape 1 — Exigences réglementaires précises

Les directives CEDEAO et lois nationales convergent sur six exigences pour les données de santé. Premièrement, journaliser tout accès aux données patients incluant lectures simples, pas seulement modifications. Deuxièmement, conserver les logs minimum 7 ans pour les données médicales (obligation comptable et juridique). Troisièmement, garantir l’intégrité des logs via stockage append-only ou signature cryptographique pour empêcher la falsification rétroactive. Quatrièmement, restituer à tout patient qui le demande la liste des accès à son dossier dans les 30 jours suivant sa demande (droit à l’information). Cinquièmement, protéger les logs eux-mêmes contre les accès non autorisés — seuls les administrateurs et auditeurs peuvent les consulter. Sixièmement, archiver les logs au-delà de la rétention vive vers un stockage longue durée immuable (Hetzner Storage Box, Backblaze B2, ou équivalent).

Pour les agences techniques, ces exigences ne sont pas de la sur-ingénierie : elles deviennent progressivement la norme attendue par les autorités de protection des données et les clients institutionnels. Un projet santé numérique livré sans audit trail conforme est aujourd’hui difficile à vendre à un cabinet sérieux ou à un hôpital. Investir dans cette fonctionnalité dès la conception est rentable techniquement et commercialement.

Étape 2 — Schéma de table audit_log

La table d’audit doit contenir suffisamment d’informations pour reconstituer chaque action et son contexte, sans surcharger les performances. Le schéma minimal contient huit colonnes : id auto-généré, timestamp précis (millisecondes), user_id, action (lecture, création, modification, suppression, export), entity_type (patient, encounter, prescription, etc.), entity_id (référence à la ressource concernée), ip_address, user_agent. On peut enrichir avec request_id pour traçabilité multi-appels, additional_data JSON pour contexte spécifique.

// Drizzle ORM
export const auditLog = pgTable('audit_log', {
  id: bigserial('id', { mode: 'number' }).primaryKey(),
  timestamp: timestamp('timestamp').defaultNow().notNull(),
  userId: text('user_id').notNull(),
  action: text('action').notNull(),
  entityType: text('entity_type').notNull(),
  entityId: text('entity_id').notNull(),
  ipAddress: text('ip_address'),
  userAgent: text('user_agent'),
  requestId: text('request_id'),
  additionalData: jsonb('additional_data')
}, (table) => ({
  timestampIdx: index('audit_timestamp_idx').on(table.timestamp),
  userIdx: index('audit_user_idx').on(table.userId, table.timestamp),
  entityIdx: index('audit_entity_idx').on(table.entityType, table.entityId)
}));

Les trois index sont essentiels pour les requêtes typiques d’audit : « tous les accès récents », « tout ce qu’a fait l’utilisateur X », « tous les accès au patient Y ». Sans ces index, une recherche dans une table de plusieurs millions de lignes prendrait plusieurs secondes — inacceptable pour un dashboard d’audit interactif.

Étape 3 — Middleware de journalisation automatique

Pour ne jamais oublier de logger une action sensible, on implémente un middleware qui intercepte automatiquement les requêtes accédant aux données patients et journalise chaque accès. Cette approche centralisée évite les oublis qui deviennent des trous dans la traçabilité.

// middleware d'audit Hono
export const auditMiddleware = createMiddleware(async (c, next) => {
  const userId = c.get('userId');
  const requestId = crypto.randomUUID();
  c.set('requestId', requestId);

  const start = Date.now();
  await next();

  // Si la requête concerne une ressource patient, logger
  const path = c.req.path;
  const match = path.match(/\/api\/(patients|encounters|prescriptions)\/(\w+)/);
  if (match) {
    const entityType = match[1].slice(0, -1); // patient/encounter/prescription
    const entityId = match[2];
    const action = c.req.method === 'GET' ? 'read'
                 : c.req.method === 'POST' ? 'create'
                 : c.req.method === 'PUT' || c.req.method === 'PATCH' ? 'update'
                 : c.req.method === 'DELETE' ? 'delete' : 'unknown';

    await db.insert(auditLog).values({
      userId,
      action,
      entityType,
      entityId,
      ipAddress: c.req.header('x-forwarded-for') || 'inconnu',
      userAgent: c.req.header('user-agent') || 'inconnu',
      requestId,
      additionalData: { duration: Date.now() - start, status: c.res.status }
    });
  }
});

app.use('*', auditMiddleware);

Pour les actions complexes (export massif, bulk update), on enrichit le middleware avec des données spécifiques : nombre d’enregistrements concernés, filtres appliqués, format d’export. Ces métadonnées facilitent l’analyse rétrospective en cas d’incident ou d’enquête.

Étape 4 — Immutabilité des logs

Pour garantir que les logs ne sont jamais altérés, deux mécanismes complémentaires. Premièrement, restreindre les permissions PostgreSQL : seul un compte spécifique peut INSERT dans la table audit_log, aucun compte (même DBA) ne peut UPDATE ou DELETE. Cette restriction se configure via GRANT/REVOKE et reste effective sauf intervention root explicite tracée.

-- Configuration permissions
REVOKE UPDATE, DELETE ON audit_log FROM PUBLIC;
GRANT INSERT ON audit_log TO app_user;
GRANT SELECT ON audit_log TO auditor_user, admin_user;

Deuxièmement, signature cryptographique périodique des blocs de logs : chaque heure, on calcule un hash SHA-256 du contenu cumulé de la dernière heure et on l’enregistre dans une table séparée signée. Toute modification rétroactive d’un log invaliderait la chaîne de hash et serait détectable. Cette protection plus avancée est utile pour les structures soumises à audit externe régulier.

Étape 5 — Rétention 7 ans et archivage

La rétention vive directe en PostgreSQL est efficace pour les 12-24 derniers mois. Au-delà, on archive vers Hetzner Object Storage chiffré pour libérer la base et réduire les coûts. Un cron mensuel exporte les logs anciens vers un fichier compressé chiffré, vérifie l’export, puis supprime de la table vive.

#!/usr/bin/env bash
# Archivage mensuel des logs > 2 ans
ARCHIVE_DATE=$(date -d '2 years ago' +%Y-%m-%d)
DEST="audit-logs-archive-$(date +%Y%m).sql.gz.gpg"

psql -c "COPY (SELECT * FROM audit_log WHERE timestamp < '${ARCHIVE_DATE}') TO STDOUT WITH CSV HEADER" \
  | gzip \
  | gpg --batch --passphrase-file /root/.archive-pass --symmetric \
  | rclone rcat hetzner:audit-archive/${DEST}

# Vérifier l'archive avant suppression
SIZE=$(rclone size hetzner:audit-archive/${DEST} --json | jq .size)
if [ "${SIZE}" -gt 1000 ]; then
  psql -c "DELETE FROM audit_log WHERE timestamp < '${ARCHIVE_DATE}'"
fi

Pour la restauration en cas de demande d’audit historique, on télécharge l’archive concernée, on déchiffre, et on importe dans une base de consultation temporaire. Ce processus tient en quelques minutes pour des volumes raisonnables. Documenter cette procédure dans le Plan d’Assurance Sécurité présenté aux autorités lors des contrôles.

Étape 6 — Dashboard d’audit pour administrateurs

Pour faciliter la consultation des logs par les administrateurs et auditeurs, on construit un dashboard web dédié avec recherche multi-critères. Filtres typiques : par utilisateur, par patient, par période, par type d’action. Affichage chronologique avec pagination. Export CSV pour les rapports manuels. Cette interface, accessible uniquement aux comptes audit, transforme une table SQL aride en outil opérationnel utilisable au quotidien.

Pour les patients qui demandent leur « rapport d’accès » (droit à l’information), on génère un PDF reprenant tous les accès à leur dossier sur la période demandée. Le format inclut : date, heure, identifiant pseudo-anonymisé du soignant (cohérence garantie via une table de correspondance interne), action effectuée, motif déclaré le cas échéant. Cette restitution prend 2 minutes une fois le dashboard configuré et satisfait à l’obligation légale.

Erreurs fréquentes

Adaptation au contexte ouest-africain

Trois aspects pratiques. Premièrement, pour les contrôles des autorités de protection (CDP Sénégal, ARTCI Côte d’Ivoire), avoir un Plan d’Assurance Sécurité écrit qui documente l’audit trail facilite considérablement le passage du contrôle. Cette pièce administrative de 30-50 pages prend quelques jours à rédiger initialement et se met à jour annuellement. L’investissement vaut largement les sanctions évitées en cas de contrôle inopiné. Deuxièmement, pour les structures qui veulent proposer leurs services à des bailleurs internationaux ou ONG, l’audit trail conforme est un prérequis de plus en plus systématique dans les appels d’offres. Troisièmement, pour la sensibilisation interne du personnel, expliquer que l’audit trail protège aussi les soignants (preuve qu’ils ont fait correctement leur travail) plutôt que de seulement les surveiller change radicalement l’acceptation. Cette communication positive accélère l’adoption.

Pour les coûts, l’implémentation initiale représente 2-3 semaines de développement. La maintenance opérationnelle est minimale (quelques heures par mois). Le stockage à 7 ans pour une clinique typique reste sous 10 euros par mois grâce à l’archivage chiffré sur Hetzner Object Storage.

Tutoriels frères

• Déployer OpenMRS sur Hetzner
• FHIR pour l’interopérabilité
• App patient mobile

Pour aller plus loin

• 🔝 Pilier : Santé numérique CEDEAO
• Articles : Sauvegardes chiffrées Hetzner

FAQ

Combien de logs par jour pour une clinique typique ?
Pour 100 consultations par jour avec 10 accès dossier par consultation, environ 1 000 logs par jour, soit 365 000 par an. Volume gérable largement par PostgreSQL.

Faut-il logger les requêtes échouées (401, 403, 500) ?
Oui particulièrement. Les tentatives d’accès non autorisées sont des signaux importants pour détecter les attaques ou les comptes compromis.

Les logs doivent-ils inclure le contenu modifié ?
Non par défaut — risque de doublonner des données sensibles. Logger uniquement le fait qu’une modification a eu lieu, pas le détail. Pour des cas particuliers (suppression de patient), enregistrer un snapshot anonymisé.

Comment justifier l’investissement audit trail au management ?
Présenter sur trois angles : conformité (évite les amendes), gestion d’incidents (résolution rapide des litiges), différenciation commerciale (argument de vente vers institutionnels).

Alertes en temps réel sur comportements suspects

Au-delà de la journalisation passive, configurer des alertes en temps réel détecte les comportements à risque dès qu’ils surviennent. Quatre patterns à surveiller. Premièrement, accès massif à des dossiers en peu de temps : un compte qui consulte 50 dossiers en 10 minutes peut indiquer un export massif non autorisé. Deuxièmement, accès en dehors des heures ouvrées : un utilisateur qui consulte un dossier à 3 heures du matin sans astreinte déclarée. Troisièmement, accès à des dossiers VIP non assignés : si un dossier est marqué confidentiel (personnalité publique, employé interne), tout accès non explicitement autorisé alerte. Quatrièmement, échecs d’authentification répétés : 10 tentatives échouées en 5 minutes signalent un brute force.

L’implémentation tient en quelques règles configurables qui scrutent la table audit_log toutes les minutes. Les alertes partent par email aux administrateurs et SMS aux responsables sécurité pour les cas critiques. Cette surveillance proactive a permis dans plusieurs cliniques ouest-africaines de détecter et bloquer des comportements problématiques (employé curieux qui consultait des dossiers sans légitimité, compte compromis utilisé hors heures) avant qu’ils ne deviennent incidents majeurs.

Audit externe et certification

Pour les structures qui visent des certifications (ISO 27001, HDS, ou équivalent local), un auditeur externe vient examiner les logs lors des audits annuels. Préparer le dossier d’audit en amont facilite considérablement ces sessions : extraire des échantillons représentatifs, démontrer l’immutabilité via la chaîne de hash, exposer le dashboard d’audit en consultation. Une session d’audit qui aurait pris une semaine sans préparation prend deux jours avec un dossier propre et complet, économisant temps et stress.

Pour les structures publiques ou para-publiques, les contrôles administratifs deviennent plus fréquents en 2026. Avoir un audit trail solide et une procédure de restitution rapide montre la maturité opérationnelle et facilite les renouvellements d’autorisations d’exercice. Cette discipline finit par devenir un actif intangible qui distingue les opérateurs sérieux des autres.

Cas concret : résolution d’un litige patient

Pour illustrer la valeur opérationnelle de l’audit trail, voici un cas réel anonymisé. Une patiente d’une clinique privée à Dakar a déposé en mars 2025 une plainte auprès de la CDP en alléguant qu’un médecin non-traitant aurait consulté son dossier sans autorisation. La clinique a produit en moins de 24 heures un rapport d’audit complet montrant : tous les accès au dossier patient sur les 12 derniers mois, l’identité de chaque consultant avec son rôle, le motif déclaré pour les consultations spéciales hors médecin traitant. Le rapport a démontré qu’aucun accès non-justifié n’avait eu lieu : tous les médecins ayant consulté le dossier étaient soit le médecin traitant désigné, soit des médecins de garde lors d’urgences nocturnes documentées. La plainte a été classée sans suite, et la patiente a été rassurée par la transparence du processus. Sans audit trail, le même scénario aurait potentiellement abouti à une amende et à une perte de confiance durable. C’est cette différence opérationnelle qui justifie largement l’investissement initial.