Journaliser les interventions IA dans un dépôt : une piste d’audit pour équipes dev

Un agent ou un assistant IA peut modifier du code, proposer un test, réécrire une migration, reformuler une documentation ou suggérer une correction de sécurité. Le diff reste visible dans Git, mais il ne raconte pas toujours pourquoi l’outil a été sollicité, quelles contraintes lui ont été données, quelles propositions ont été rejetées et quel contrôle humain a réellement eu lieu.

Le problème n’est pas de marquer chaque ligne comme « humaine » ou « IA ». Cette séparation devient vite artificielle dès qu’un développeur réécrit, découpe ou corrige une proposition. Le sujet utile pour une équipe technique est plus simple : garder une trace exploitable des interventions IA qui ont influencé une décision de développement.

Le trou entre le commit et la conversation

Un commit documente l’état final du code. Une pull request documente parfois l’intention. Entre les deux, l’usage d’un outil IA peut rester invisible : prompt de départ, fichiers donnés en contexte, recommandations ignorées, risques signalés, tests ajoutés après coup. Quand tout se passe bien, cette invisibilité paraît confortable. Lorsqu’une régression arrive trois semaines plus tard, elle devient coûteuse.

Le journal d’intervention IA sert à combler ce trou sans transformer l’équipe en service documentaire. Il ne doit pas copier toute la conversation avec le modèle, ni stocker des données sensibles. Il doit produire une mémoire courte, ciblée et vérifiable, reliée au travail réel : ticket, branche, pull request, commit ou incident.

Ce qu’il ne faut pas chercher à tracer

Une erreur fréquente consiste à vouloir tout enregistrer. C’est lourd, difficile à relire et parfois risqué si des secrets, extraits de code propriétaire ou données personnelles se retrouvent dans les journaux. Un bon journal d’intervention IA est volontairement incomplet : il conserve ce qui aide à auditer une décision, pas ce qui donne l’illusion d’une reproduction parfaite.

Il n’a pas non plus vocation à noter les développeurs. Si le journal devient un outil de surveillance individuelle, il sera contourné ou rempli avec des formules creuses. Son rôle est opérationnel : faciliter la revue, accélérer le diagnostic, améliorer les consignes données aux agents et clarifier la responsabilité de validation.

Les événements à garder

Une équipe peut commencer avec une liste courte. Chaque entrée doit pouvoir être remplie en moins de deux minutes, sinon le rituel ne survivra pas au quotidien.

• Objectif demandé : correction, génération de test, refactorisation, migration, analyse de risque ou documentation.
• Périmètre : dépôt, module, ticket, fichiers principaux ou zone fonctionnelle concernée.
• Contraintes données : conventions du projet, limites de modification, exigences de compatibilité, tests attendus.
• Sortie utilisée : code repris, plan suivi, test ajouté, diagnostic seulement, ou proposition rejetée.
• Contrôle humain : relecture, exécution de tests, revue sécurité, comparaison de comportement ou validation produit.
• Décision finale : accepté tel quel, modifié avant intégration, abandonné, reporté ou transformé en tâche séparée.

Cette liste matérialise la différence entre « l’IA a aidé » et « l’équipe sait ce qu’elle a accepté ». Le second énoncé est plus utile en revue, en incident et en amélioration continue.

Un format léger suffit

Le format le plus robuste est souvent le moins spectaculaire : un bloc structuré dans la description de pull request, un fichier de notes associé au ticket, ou un commentaire standardisé généré par l’outil interne. Le journal doit rester proche du workflow existant. S’il impose une application séparée, il perdra les détails au moment précis où ils sont encore frais.

Un exemple volontairement sobre :

Intervention IA
Objectif : proposer des tests de non-régression pour le parseur de dates.
Périmètre : module billing/date_parser.
Contraintes : ne pas modifier l'API publique ; couvrir les dates invalides.
Sortie utilisée : trois cas de test repris, un cas rejeté.
Contrôle humain : tests unitaires exécutés ; revue manuelle des cas limites.
Décision : intégré après réécriture des noms de tests.

Ce niveau de détail ne prétend pas reconstruire toute la session. Il donne assez d’information pour comprendre la nature de l’aide, les limites posées et la validation effectuée.

Où placer le journal dans le workflow

Le bon emplacement dépend de la maturité de l’équipe. Pour une équipe qui débute, la description de pull request est suffisante. Elle centralise déjà le contexte, les discussions et les validations. Pour une organisation plus structurée, le journal peut être relié au ticket, puis indexé dans un outil d’observabilité ou de conformité interne.

Le point important est la proximité avec la décision. Une note ajoutée après fusion perd en précision. Une note demandée avant revue améliore au contraire la qualité de la pull request : le développeur doit expliciter ce qui vient de l’outil, ce qu’il a retenu et ce qu’il a contrôlé.

Illustration du flux

Les risques à éviter

Le premier risque est la collecte excessive. Un journal ne doit pas contenir de clés, de jetons, de données client ou de conversations complètes collées sans filtre. La trace doit être résumée et nettoyée. Les mêmes exigences de prudence que pour les prompts et les journaux techniques s’appliquent ici ; l’article sur la protection des secrets avec les agents IA détaille ce point côté sécurité : protéger les secrets avec les agents IA de code.

Le deuxième risque est le faux confort. Une case « IA utilisée » ne prouve rien. Elle ne dit pas si le changement est correct, si le test couvre le bon comportement ou si la proposition a été comprise. Le journal doit donc toujours mentionner le contrôle humain associé.

Le troisième risque est la granularité excessive. Tracer chaque autocomplétion n’a aucun intérêt. Il vaut mieux cibler les interventions qui changent une décision : plan de refactorisation, génération de test, correction de bug, analyse de sécurité, migration ou modification multi-fichiers.

Comment démarrer sans alourdir les équipes

Commencez par une règle simple : toute pull request où l’IA a influencé une décision non triviale contient un bloc d’intervention. Non triviale signifie que l’outil a orienté le plan, produit un morceau de code repris, suggéré un test important ou détecté un risque. Les usages mineurs, comme reformuler un commentaire ou compléter une ligne évidente, peuvent rester hors journal.

Ajoutez ensuite un modèle court dans le template de pull request. Le modèle doit être facultatif quand aucune intervention significative n’a eu lieu, mais obligatoire quand l’auteur déclare en avoir utilisé une. La revue peut alors poser des questions concrètes : quelles contraintes ont été données ? quels tests valident la proposition ? quelle partie a été rejetée ?

Après quelques semaines, relisez les entrées. Les journaux révéleront souvent des motifs : prompts trop vagues, zones du code systématiquement mal comprises, tests générés mais rarement utiles, ou au contraire tâches où l’IA accélère vraiment le travail. Cette lecture complète les approches de benchmark et de ROI déjà nécessaires, sans les remplacer.

Une frontière claire avec l’évaluation

Le journal d’intervention IA n’est pas un benchmark. Il ne compare pas des outils, ne calcule pas un coût par tâche et ne mesure pas seul la qualité de livraison. Pour ces sujets, une équipe aura besoin d’un protocole séparé, comme dans la construction d’un benchmark reproductible pour agents IA de code.

Sa valeur est ailleurs : il rend les décisions lisibles. Quand un changement passe en production, l’équipe sait si l’IA a servi à explorer, écrire, tester ou seulement reformuler. Cette clarté aide la revue, réduit les angles morts en incident et donne une base plus saine pour améliorer les consignes données aux outils.

Le bon critère de réussite

Un journal d’intervention IA réussit quand il est consulté sans effort pendant une revue ou une analyse d’incident. S’il devient une archive jamais lue, il est trop détaillé ou mal placé. S’il ne contient qu’une mention générique, il est trop pauvre. Entre les deux, quelques lignes bien structurées suffisent souvent à transformer une aide invisible en décision assumée.