Chaque mois de septembre depuis trois ans, un auditeur externe mandaté par un établissement de santé vient vérifier que le module de prise de rendez-vous et de gestion de dossiers patients développé par l’agence respecte un ensemble d’exigences de traçabilité et de fiabilité. Les deux premières années, cette préparation a mobilisé cinq jours pleins de l’équipe technique, à retrouver manuellement quels tests couvraient quelles exigences.
La troisième année, une stratégie différente a été mise en place : relier explicitement chaque exigence d’audit à un ou plusieurs tests automatisés précis, documentés dans un format que l’auditeur peut consulter directement, sans dépendre de la mémoire d’un développeur présent au moment de l’audit précédent.
Cartographier les exigences avant d’écrire le moindre test
La première étape a consisté à extraire, du rapport d’audit de l’année précédente, la liste précise des exigences vérifiées : traçabilité des accès aux dossiers patients, purge automatique des données après le délai réglementaire, journalisation des modifications de rendez-vous, entre autres. Chaque exigence a reçu un identifiant court, réutilisé ensuite dans le nom des tests correspondants.
/**
* @audit-req TRACE-01 : chaque accès à un dossier patient doit être journalisé
*/
public function test_acces_dossier_patient_est_journalise(): void {
$dossier = $this->create_dossier_patient();
$this->simulate_medecin_access( $dossier->id );
$journal = get_audit_log_entries( $dossier->id );
$this->assertCount( 1, $journal );
$this->assertSame( 'consultation_dossier', $journal[0]->action );
}
Cette annotation @audit-req, simple commentaire PHPDoc sans effet sur l’exécution du test, sert ensuite de point d’ancrage pour générer automatiquement un rapport qui associe chaque exigence à ses tests.
Générer un rapport lisible par un non-développeur
Un script PHP parcourt l’ensemble des fichiers de test à la recherche de l’annotation @audit-req, exécute la suite de tests correspondante, et produit un rapport HTML simple listant chaque exigence, les tests qui la couvrent, et leur statut de réussite. Ce rapport, généré en quelques secondes, remplace ce qui prenait auparavant des heures de recherche manuelle dans le code.
| Exigence | Tests associés | Statut |
|---|---|---|
| TRACE-01 | 2 tests | Conforme |
| PURGE-03 | 3 tests | Conforme |
| ACCES-02 | 1 test | À vérifier manuellement |
La dernière ligne de ce tableau illustre une limite assumée de l’approche : certaines exigences, comme la formation du personnel médical à la confidentialité des données, ne se vérifient tout simplement pas par un test automatisé et restent marquées comme telles, sans faux-semblant de couverture.
Conserver l’historique des audits passés
Chaque rapport généré est archivé avec sa date, dans un dossier versionné distinct du code source, accompagné des remarques de l’auditeur et des actions correctives engagées. Cet historique a permis, lors du troisième audit, de montrer une progression claire : une exigence marquée non conforme l’année précédente disposait désormais de trois tests dédiés et d’un correctif documenté.
Faire dialoguer développeurs et auditeur sans jargon inutile
L’auditeur externe n’a pas de formation en développement logiciel et ne lira jamais directement le code PHP des tests. Le rapport généré traduit donc chaque test en une phrase compréhensible sans vocabulaire technique, extraite du commentaire associé à l’annotation @audit-req plutôt que du nom de la méthode de test elle-même, souvent plus cryptique.
- Le commentaire d’annotation sert de traduction humaine du test
- Le rapport ne montre jamais de code brut à l’auditeur
- Chaque exigence non couverte est signalée explicitement plutôt que masquée
Ce que cette stratégie ne résout pas
Cette organisation ne dispense pas l’équipe de comprendre en profondeur les exigences réglementaires elles-mêmes, ni de traiter la question distincte de l’anonymisation des données utilisées en environnement de test, gérée séparément par un processus de génération de données fictives réalistes mais non identifiantes.
Un audit qui se prépare bien ne se prépare pas la veille : il se prépare en continu, un test à la fois, tout au long de l’année.
Notre verdict
Le temps de préparation de l’audit annuel est passé de cinq jours à environ une journée, consacrée surtout à relire le rapport généré plutôt qu’à le construire depuis zéro. Plus significatif encore, l’auditeur lui-même a salué la clarté du document lors du dernier passage, un retour rare qui a renforcé la confiance du client dans la fiabilité du module au-delà de la seule question technique.
