Dans le logiciel médical, la conformité réglementaire a longtemps été vécue comme un frein à la vélocité des équipes techniques : process de changement lourds, validations manuelles, documentation produite après coup pour satisfaire un audit. Le GitOps inverse ce rapport. Bien pensé, il ne s’ajoute pas à la démarche qualité, il en devient une brique native : chaque déploiement produit de lui même la preuve d’audit que la réglementation exige.

Le GitOps en une phrase

Le GitOps, c’est déclarer l’état voulu d’un système (infrastructure, configuration, version applicative) dans un dépôt Git, et laisser un contrôleur (ArgoCD, FluxCD) réconcilier en continu l’état réel avec cet état déclaré. Toute évolution passe par un commit, revu et validé avant le merge, jamais par une action manuelle directe sur l’environnement cible.

Trois propriétés en découlent, qui n’ont rien d’anecdotique pour du logiciel réglementé : Git est le seul endroit où l’état désiré est décrit, chaque changement est un enregistrement immuable (auteur, horodatage, diff, hash), et un contrôleur automatisé vérifie en permanence que ce qui tourne correspond à ce qui a été approuvé.

Ce que les référentiels exigent réellement

Les référentiels qui encadrent le logiciel médical ne parlent presque jamais d’outillage, ils parlent de propriétés à démontrer. Ce sont ces propriétés qui comptent, pas la conformité d’un outil en particulier :

• IEC 62304 : identifier les éléments de configuration, contrôler les changements, tracer l’état de configuration à tout moment.
• ISO 13485 : qui a modifié quoi, quand, avec quelle approbation.
• Le règlement européen 2017/745 (MDR) : exige une documentation technique démontrant la maîtrise des changements logiciels, impose une surveillance après commercialisation qui suppose de savoir précisément quelle version tourne où.
• IEC 81001-5-1 : va plus loin en intégrant explicitement la gestion de configuration et le contrôle des changements au cycle de développement sécurisé, pas seulement à la qualité.
• La guidance FDA de 2023 sur la cybersécurité des dispositifs médicaux (Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions) demande un SBOM tenu à jour et un mécanisme de mise à jour maîtrisé.

Le fil commun à tous ces textes : prouver qu’on sait, à tout instant, ce qui tourne, qui l’a approuvé, et comment revenir en arrière si besoin. C’est exactement ce que Git fait par construction.

Pourquoi le GitOps répond nativement à ces exigences

Chaque primitive Git a un équivalent réglementaire direct, sans qu’il soit nécessaire de construire un système parallèle pour le documenter :

• Un commit (auteur, horodatage, hash, diff) est un enregistrement électronique : impossible à falsifier sans le détecter, daté sans ambiguïté.
• Une pull request avec relecteurs obligatoires est le contrôle de changement exigé par IEC 62304 : la demande, la justification, la revue et l’approbation sont dans un seul et même enregistrement, lié au commit qui l’implémente.
• Un tag ou une release Git correspond à une baseline de configuration : on sait dire précisément quelle version d’un composant est associée à quelle validation.
• Un revert Git est un rollback documenté, traçable, immédiat, ce que la plupart des process de gestion des changements manuels peinent à garantir dans les mêmes délais.
• La boucle de réconciliation du contrôleur GitOps (ArgoCD, FluxCD) est le mécanisme de surveillance post-commercialisation exigé par le MDR : elle détecte et signale tout écart entre ce qui a été approuvé et ce qui tourne réellement, en continu, sans intervention humaine.

Un auditeur qui demande “montrez moi que la version en production correspond bien à ce qui a été validé” reçoit une réponse immédiate : l’historique Git, le statut de synchronisation du contrôleur, et rien d’autre à reconstituer.

Un levier d’efficacité, pas seulement un atout réglementaire

C’est là que le GitOps sort du strict cadre de la conformité. Dans une organisation qui gère sa documentation qualité et son déploiement comme deux systèmes séparés, chaque changement coûte deux fois : une fois pour le livrer techniquement, une fois pour documenter qu’il a été livré. Avec un GitOps bien pensé, ces deux actions n’en font qu’une, le commit est la preuve.

Ça change concrètement le quotidien des équipes : un déploiement ne dépend plus d’un accès manuel à l’environnement, la détection de drift devient automatique là où elle demandait auparavant un audit périodique, et un incident se résout par un revert en quelques secondes plutôt que par une procédure de rollback manuelle sujette à erreur. Sur un système où chaque changement non documenté est un risque qualité, cette automatisation réduit autant le temps d’équipe mobilisé sur le run que la surface d’erreur humaine.

À condition de le penser pour ça

Le GitOps n’est pas nativement conforme, il le devient seulement si le dépôt et le pipeline sont construits avec cette exigence en tête. Un repo sans protection de branche, avec force-push autorisé et fusion sans revue, ne prouve rien de plus qu’un accès SSH direct en production. Quelques points sont non négociables dans ce contexte :

• Historique immuable : branches protégées, force-push interdit sur les branches de référence, commits signés pour garantir l’identité de l’auteur.
• Séparation des rôles : au moins un relecteur indépendant de l’auteur sur les changements critiques, ce qui rejoint l’exigence de revue indépendante d’IEC 62304 et d’ISO 13485.
• Traçabilité des dépendances : générer un SBOM et le tenir à jour à chaque changement pour répondre à la guidance FDA, avec un outil comme Dependency-Track pour suivre en continu les vulnérabilités des composants embarqués.
• Secrets hors de Git : aucun secret en clair dans le dépôt, y compris chiffré à la légère. SOPS permet de committer des secrets chiffrés en gardant le contrôle des clés en dehors du repo.
• Convention de commits : des messages structurés (type de changement, référence à l’exigence ou au ticket de risque associé) transforment l’historique Git en index consultable plutôt qu’en simple journal, ce qui facilite considérablement le travail d’un auditeur.

Aucun de ces points n’a de valeur réglementaire tant qu’il reste un choix d’ingénierie implicite. Le processus GitOps n’est pas conforme par nature : c’est une pratique technique, pas une procédure qualité. Pour qu’un auditeur puisse s’appuyer dessus, il doit être décrit noir sur blanc dans le système qualité de l’entreprise, typiquement dans le plan de gestion de configuration ou le plan de développement logiciel exigé par IEC 62304 : qui a le droit d’approuver une pull request, quelles branches font foi, ce qui constitue une baseline validée, comment un incident donne lieu à un revert tracé. Sans cette procédure documentée et approuvée, le GitOps reste une bonne pratique d’ingénierie parmi d’autres, pas une preuve de maîtrise des changements au sens de la réglementation.

Conclusion

Le GitOps n’ajoute pas une couche de paperasse à la démarche qualité du logiciel médical, il en absorbe une bonne partie dans le fonctionnement normal des équipes. La condition, c’est de concevoir le dépôt et le pipeline comme faisant partie du système qualité dès le départ, pas comme un outil technique auquel on plaquerait de la conformité après coup. Bien pensé, l’auditabilité n’est pas un sous-produit du GitOps : c’est la raison pour laquelle il vaut la peine d’être adopté dans ce secteur.