Conformité et traçabilité

Le défi de la conformité

Quand un développeur écrit du code, la traçabilité est simple : git log, code review, PR. Quand un agent écrit du code, trois questions se posent que le workflow habituel ne couvre pas.

Qui a décidé quoi ? Le développeur a donné un prompt, l’agent a pris des décisions d’implémentation. Le git log ne montre que le résultat, pas le raisonnement.

Quelles données ont transité ? L’agent lit des fichiers du projet et les envoie à une API externe. Si ces fichiers contiennent des données personnelles ou sensibles, c’est un transfert de données au sens réglementaire.

D’où vient le code ? Le code généré par un LLM est issu de son entraînement. La question de la propriété intellectuelle et des licences reste ouverte.

Audit trail en développement agentique

Un audit trail classique repose sur le versioning (git), les pull requests et les revues de code. En développement agentique, il faut y ajouter une couche : le contexte de la session.

Ce qu’il faut tracer

• Le prompt — l’instruction donnée par le développeur à l’agent.
• Les actions de l’agent — fichiers lus, fichiers modifiés, commandes exécutées, outils appelés.
• Les décisions implicites — pourquoi l’agent a choisi telle implémentation plutôt qu’une autre (visible dans les logs de session).
• Le modèle utilisé — version, provider, paramètres de sampling.

Convention de commit

Un commit agent-assisté devrait être identifiable. Plusieurs conventions existent : un tag Co-authored-by: AI Agent, un trailer Agent-session: <id>, ou un préfixe dans le message. L’important est la cohérence au sein de l’équipe.

Attention : Un commit sous le nom du développeur sans indication d’assistance agentique n’est pas un mensonge — le développeur reste responsable. Mais cela complique le travail des auditeurs qui doivent comprendre le processus de production du code.

RGPD et données sensibles

Quand un agent cloud lit des fichiers du projet, leur contenu est envoyé à l’API du fournisseur LLM. Si ces fichiers contiennent des données personnelles, cela constitue un transfert de données soumis au RGPD (ou équivalent local).

Sources courantes de données sensibles dans une codebase

• Fichiers de configuration avec des chaînes de connexion contenant des identifiants.
• Fixtures de test avec des données réalistes (noms, emails, adresses).
• Fichiers de logs embarqués contenant des IP ou des identifiants utilisateur.
• Commentaires de code mentionnant des cas métier avec des données réelles.

Mesures de mitigation

• DPA (Data Processing Agreement) avec le fournisseur LLM — vérifier que les données ne sont pas retenues pour l’entraînement.
• Fichiers .gitignore / .claudeignore — exclure les fichiers sensibles du contexte de l’agent.
• Hooks pré-envoi — scanner les fichiers avant qu’ils ne soient envoyés à l’API (patterns regex sur les PII).
• LLM on-premise — éliminer le transfert externe (mais introduit d’autres contraintes).

Point clé : La distinction anonymisation vs pseudonymisation est juridiquement critique. Des données pseudonymisées (réversibles) restent des données personnelles au sens du RGPD. Seules les données véritablement anonymisées (irréversibles) sortent du périmètre.

Propriété intellectuelle et licences

Le code généré par un LLM est produit à partir de patterns appris lors de l’entraînement. Deux risques principaux.

Reproduction de code sous licence

Si le modèle reproduit du code structurellement identique à une bibliothèque open source sous GPL ou AGPL, le code généré pourrait être considéré comme une œuvre dérivée. Conséquence potentielle : obligation de publier le projet sous la même licence.

Dépendances suggérées

L’agent peut suggérer d’ajouter des dépendances dont la licence est incompatible avec le projet. Un agent ne vérifie pas la compatibilité des licences sauf si on le lui demande explicitement.

Mitigation pragmatique : reviewer le code généré pour détecter les similarités suspectes, surtout dans les couches d’accès aux données et les patterns d’infrastructure où les implémentations standards sont nombreuses.

ZTE comme cadre de conformité

Les principes du Zero Trust Execution s’appliquent directement à la conformité :

Point clé : La conformité n’est pas une couche qu’on ajoute après coup. C’est un ensemble de contraintes d’ingénierie qu’on intègre dans le workflow agentique dès le départ — exactement comme les tests ou le linting.

Quiz