Développement IA et conformité : comment garantir HDS, RGPD et RGAA

La conformité n'est pas une étape, c'est un processus

Dans le développement logiciel classique, la conformité réglementaire est souvent traitée comme un audit de fin de projet. On développe pendant des mois, puis on fait appel à un consultant pour vérifier que le résultat respecte les normes HDS, RGPD et RGAA. Le consultant identifie les problèmes, les corrections sont coûteuses parce qu'il faut revenir sur du code déjà validé, et le projet prend du retard.

Cette approche est inefficace. Elle est aussi risquée : tant que l'audit n'est pas passé, personne ne sait si le projet est conforme. Et quand les non-conformités sont majeures, c'est parfois tout le projet qui doit être revu.

Le vibe coding professionnel prend le problème à l'envers. La conformité n'est pas vérifiée en fin de projet : elle est intégrée dans chaque étape du développement. Des contrôles automatisés détectent les problèmes au moment où le code est écrit, pas six mois plus tard. C'est plus fiable, plus rapide et moins coûteux.

Conformité RGPD : des contrôles intégrés dans le code

Le problème avec le RGPD dans le développement classique

Le RGPD impose des obligations techniques précises : minimisation des données, chiffrement, pseudonymisation, droit à l'effacement, consentement explicite. En théorie, chaque développeur est censé connaître et appliquer ces règles. En pratique, les failles RGPD se glissent dans le code au quotidien :

• Des données patients qui se retrouvent dans les logs applicatifs par inadvertance
• Des requêtes de base de données construites par concaténation de chaînes (vulnérables à l'injection SQL)
• Des identifiants ou des numéros de sécurité sociale transmis en clair dans les URLs
• Des données conservées au-delà des durées légales sans mécanisme de purge

Ces problèmes ne sont pas détectés par une relecture classique du code. Ils nécessitent des outils spécialisés.

L'automatisation des contrôles RGPD

Dans notre workflow de développement, Semgrep est configuré avec un jeu de règles personnalisées, spécifiques aux données de santé et référencées selon les standards CWE et OWASP. Avant qu'une modification de code soit validée, ces règles vérifient automatiquement :

• Données sensibles dans les logs : détection des patterns de NIR (numéro de sécurité sociale), d'identifiants patients, de notes médicales ou de codes diagnostics dans les instructions de journalisation
• Requêtes paramétrées : vérification que toutes les requêtes de base de données utilisent des paramètres, jamais de concaténation de chaînes
• Secrets en dur : détection des mots de passe, clés d'API, tokens ou chaînes de connexion codés directement dans le code source
• Commandes système : vérification que les appels système n'utilisent pas de paramètres non validés (prévention de l'injection de commandes)

Si une alerte est déclenchée, le code est bloqué. Il ne peut pas être intégré dans le projet tant que le problème n'est pas corrigé et validé par un expert humain.

Le résultat : les failles RGPD sont détectées en temps réel, au moment où le développeur écrit le code. Pas lors d'un audit six mois plus tard.

Conformité HDS : sécurité de bout en bout

Les exigences techniques de la certification HDS

La certification HDS ne se limite pas au choix d'un hébergeur. Elle impose des exigences sur l'ensemble de la chaîne : l'infrastructure, le code, les processus d'exploitation et la traçabilité. Un logiciel hébergé chez un hébergeur certifié HDS mais développé sans rigueur de sécurité ne répond pas à l'esprit de la certification.

Les exigences HDS qui impactent le développement :

• Chiffrement : données chiffrées au repos et en transit
• Gestion des accès : authentification renforcée, principe du moindre privilège
• Traçabilité : journalisation de tous les accès et modifications avec horodatage
• Gestion des secrets : aucun secret (clé, mot de passe, token) stocké dans le code source
• Disponibilité : architecture résiliente, sauvegardes testées, plan de reprise d'activité

Comment ces exigences sont intégrées dans le workflow

Gestion des secrets dans un coffre-fort

Aucun mot de passe, aucune clé de chiffrement, aucun token n'apparaît dans le code source. Tous les secrets transitent par un coffre-fort dédié (HashiCorp Vault) qui délivre des credentials éphémères aux applications autorisées via un mécanisme d'authentification applicative (AppRole), avec rotation automatique.

L'intérêt pour la conformité HDS est double : en cas de compromission du dépôt de code, aucun accès réel n'est exposé. Et la rotation automatique des secrets satisfait les exigences d'audit sans intervention manuelle.

Traçabilité et audit trail

Chaque action significative est journalisée de manière structurée : quel utilisateur a accédé à quelle donnée, à quel moment, depuis quelle adresse IP, avec quel niveau de privilège. Les données sensibles (mots de passe, tokens, NIR, notes médicales) sont automatiquement expurgées des journaux avant enregistrement. Ces journaux sont horodatés, stockés de manière sécurisée et conservés conformément aux durées légales.

Cette traçabilité n'est pas ajoutée après coup. Elle est intégrée nativement dans l'architecture de chaque application. Les développeurs n'ont pas besoin de penser à ajouter un log : le framework le fait automatiquement pour toute opération sur des données sensibles.

Pipeline de vérification pré-production

Avant qu'une modification atteigne l'environnement de production, elle traverse un pipeline automatisé qui vérifie la conformité à chaque étape. Du point de vue réglementaire, c'est un atout majeur : chaque déploiement génère une preuve documentée que les contrôles ont été passés avec succès.

En pratique, le pipeline couvre la validité du code, le respect des bonnes pratiques de sécurité, les règles spécifiques HDS et RGPD, les tests fonctionnels et la cohérence architecturale. Si un seul contrôle échoue, le déploiement est bloqué tant que le problème n'est pas résolu. Un mécanisme de retour arrière automatique permet de restaurer la version précédente en cas d'anomalie en production.

Ce pipeline est décrit en détail dans notre article sur la sécurité du code IA.

Hébergement souverain SecNumCloud

La conformité du code ne vaut rien si l'infrastructure sous-jacente ne suit pas. Pour les données de santé, deux certifications font référence :

• HDS : obligatoire dès qu'un système manipule des données de santé à caractère personnel
• SecNumCloud : qualification ANSSI qui garantit la souveraineté juridique et technique de l'infrastructure cloud

Le choix d'un hébergeur doublement certifié assure que les données restent sous juridiction française, à l'abri des lois extraterritoriales. C'est un prérequis de conformité, pas un argument commercial.

Conformité RGAA : l'accessibilité dans le code

L'obligation légale

Les établissements publics de santé sont soumis au RGAA (Référentiel Général d'Amélioration de l'Accessibilité). Les établissements privés y sont de plus en plus encouragés. Concrètement, chaque interface numérique doit être utilisable par les personnes en situation de handicap.

L'accessibilité intégrée dans le processus de développement

L'IA est guidée pour générer du code qui respecte les standards d'accessibilité dès la première version :

• Structure sémantique : utilisation correcte des balises HTML (titres hiérarchisés, listes, formulaires avec labels)
• Attributs ARIA : ajout systématique des attributs d'accessibilité pour les éléments interactifs
• Contrastes : respect des ratios de contraste minimaux pour le texte et les éléments interactifs
• Navigation clavier : tous les éléments interactifs sont accessibles sans souris
• Textes alternatifs : chaque image et chaque élément visuel dispose d'une alternative textuelle

Ces critères sont vérifiés automatiquement à chaque modification. Les écarts sont signalés et corrigés avant validation, au même titre que les failles de sécurité.

L'avantage structurel de l'approche IA

Le paradoxe du développement assisté par IA est que ses détracteurs lui reprochent un manque de contrôle alors que c'est précisément cette approche qui force à automatiser les contrôles.

Dans un développement classique, les vérifications de conformité dépendent de la vigilance individuelle de chaque développeur. Si un développeur est fatigué, pressé ou simplement peu familier avec les exigences HDS, la faille passe. Et elle ne sera détectée qu'à l'audit, des mois plus tard.

Dans un développement AI-native, les contrôles sont automatiques, systématiques et indépendants de l'état du développeur. Chaque ligne de code, qu'elle soit générée par l'IA ou écrite manuellement, passe par les mêmes vérifications. C'est un filet de sécurité qui ne dort jamais.

Ce qu'il faut retenir

La conformité réglementaire en santé numérique (HDS, RGPD, RGAA) n'est pas incompatible avec le développement assisté par IA. Elle est mieux garantie par cette approche que par le développement classique, à condition que les contrôles soient automatisés et intégrés dans le processus de développement.

Scans de sécurité spécifiques santé, gestion des secrets dans un coffre-fort, traçabilité native, pipeline de vérification pré-production, hébergement souverain SecNumCloud, accessibilité intégrée : ce sont les six piliers d'un développement IA conforme. Chez Ducal, ils sont intégrés dans chaque projet, dès la première ligne de code. C'est notre manière de concilier vitesse de livraison et exigence réglementaire, avec un accompagnement continu qui maintient cette conformité dans la durée. Pour approfondir les aspects sécurité, consultez notre article sur la fiabilité du code IA en santé.