GitAgent : industrialisez vos agents IA grâce à la puissance de Git

Les consignes qui pilotent un agent IA changent souvent sans trace : le jour où il se trompe, personne ne sait pourquoi. Sur un projet réel, une seule consigne mal écrite a fait chuter le taux de défauts détectés par notre agent de 100 % à 72 %. Parce que ses consignes étaient gérées comme du code, datées, relues et réversibles, la cause a été trouvée et corrigée en une opération. Voici comment, et ce qu’il faut exiger avant de généraliser les agents.

Ailleurs, retrouver la cause d’une dérive prend bien plus de temps. Les instructions d’un agent sont saisies dans l’interface d’un outil, et chacun les modifie au fil de l’eau, sans noter qui, quand ni pourquoi. Quand l’agent se dégrade, le vrai coût n’est pas le texte modifié : c’est le temps passé à chercher la cause, les décisions prises entre-temps sur la base d’un agent défaillant, et l’impossibilité d’expliquer son comportement à un auditeur. Gartner prévoit l’abandon de plus de 40 % des projets d’IA agentique d’ici fin 2027. [1]

Notre thèse. Un prompt est du code. Une règle est de la configuration. Une mémoire est un état. Git apporte aux agents IA les mêmes garanties qu’au logiciel : un historique, une relecture, un retour arrière et une traçabilité.

Le principe : un agent, c’est un dépôt Git

Deux projets open source, publiés sous licence MIT par l’éditeur Lyzr, portent cette approche. GitAgent (anciennement Gitclaw) fait fonctionner l’agent. OpenGAP est le standard qui organise les fichiers décrivant l’agent ; il est encore en version 0.x (0.5.0 lors de nos tests) et peut donc évoluer.

Versionner du code n’a rien de nouveau. La nouveauté : tout ce qui définit l’agent devient un fichier versionné. Modifier son comportement suit donc le même circuit qu’une modification de code : on propose le changement, il est relu, il entre dans l’historique, et on peut revenir en arrière à tout moment.

Composant	Fichier	Rôle
Identité	SOUL.md	Qui est l’agent et quel est son rôle
Règles	RULES.md	Ce qu’il doit respecter
Séparation des rôles	DUTIES.md	Ce qu’il doit faire et ne pas faire
Compétences	skills/	Ce qu’il sait faire
Connaissances	knowledge/	Les informations qu’il peut consulter
Mémoire	memory/	Ce qu’il retient de ses expériences passées

Chaque composant est un fichier du dépôt : toute modification est datée, attribuée à son auteur et réversible.

Ce que nous avons mesuré

Notre agent relit du code, sans jamais le modifier. Nous l’avons testé sur un projet métier réel, dont certains fichiers dépassent 180 000 caractères : la taille d’un vrai code de production, pas d’une application de démonstration.

Nous n’avons inventé aucun défaut. Nous avons repris 23 bugs réellement corrigés dans l’historique du projet, chacun lié à son ticket, et annulé leur correction pour les faire réapparaître : 6 de sécurité (un contrôle d’accès absent, une requête construite à partir de paramètres), 8 de logique (une valeur vide non gérée, un virement sans protection contre les accès simultanés) et 9 de qualité (une mise à jour perdue sans message d’erreur, du code inutile). Cinq modifications ordinaires, sans défaut connu, servent de témoins : toute remarque à leur sujet est du bruit.

Les 25 modifications ont été soumises à notre agent avec deux modèles d’éditeurs différents, GPT-5 mini (OpenAI) et Claude Haiku 4.5 (Anthropic), et à deux outils classiques d’analyse de code, Semgrep et SonarQube. Chaque test a été répété trois fois ; tous les taux sont des moyennes par passe, calculés de la même façon dans tout l’article. Un défaut ne compte comme détecté que si l’outil indique le bon fichier, la bonne ligne et le bon type de problème.

Le banc d’essai en bref. 23 défauts réels sur 20 modifications, plus 5 témoins · 2 modèles × 3 passes = 150 revues · GitAgent 2.2.0, OpenGAP 0.5.0 · Mise en place : une journée

Les résultats

L’agent détecte presque tous les défauts : 100 % avec GPT-5 mini et 98,6 % avec Claude Haiku 4.5. Les deux outils classiques n’en trouvent qu’un chacun, soit 4 %. Ces outils ne sont pas conçus pour relire un changement. Ils restent nécessaires pour ce qu’ils font bien. L’agent les complète, il ne les remplace pas.

Mesure (moyenne par passe)	Agent · GPT-5 mini	Agent · Claude Haiku 4.5	Semgrep	SonarQube [2]
Défauts détectés (sur 23)	100 %	98,6 %	4,3 % (1)	4,3 % (1)
Remarques par revue	3,1	1,8	0,2	0,04
Part de remarques hors corrigé	58 %	33 %	75 %	0 %
Remarques sur les témoins (sans défaut)	3,4	1,1	0,2	0
Temps par revue	38 s	9 s	6 à 30 s	22 à 81 s

Un taux de détection ne veut rien dire seul : un outil qui signale tout trouve tous les défauts, mais personne ne lit ses rapports. Environ la moitié des remarques de l’agent portent sur autre chose que les défauts introduits. Certaines pointent de vrais problèmes du code, comme un bloc qui masque les refus d’autorisation ; par prudence, nous les comptons toutes comme du bruit, soit le scénario le moins favorable à l’agent. Semgrep repère une requête SQL mal construite, SonarQube du code inutile ; aucun ne voit un contrôle d’accès manquant ou une erreur de logique. Ce sont des problèmes de sens, pas de forme : c’est là que l’agent apporte une vraie valeur.

Ce que ce taux mesure vraiment. Chaque défaut apparaît parce qu’une correction a été retirée : l’agent voit une protection disparaître, et le dit lui-même (« la méthode supprimée contenait explicitement la validation »). Le taux mesure sa capacité à repérer un garde-fou retiré, pas à trouver un défaut dans un code inconnu. Sans le détail du changement, sur 10 modifications, la détection tombe à 79 % (44 % en sécurité) et les remarques doublent : c’est l’écart entre relire une modification et auditer un code.

L’expérience de la mauvaise règle

Nous avons volontairement ajouté une mauvaise règle pour tester le contrôle. La consigne semblait raisonnable : « ne signaler que les problèmes bloquants ». La validation du standard l’a acceptée sans avertissement, car elle vérifie la forme des fichiers, pas l’effet de leur contenu.

L’effet a été immédiat : la détection est passée de 100 % à 72 %. Les rapports, une remarque par revue au lieu de trois, semblaient plus clairs. Mais l’agent ignorait désormais plus d’un quart des défauts : la moitié des défauts de qualité et trois défauts mineurs sur quatre, dont du code inutile et une vérification de droits qui ne tenait pas compte des majuscules.

Grâce à l’historique Git, nous avons retrouvé la règle en cause et l’avons annulée en une commande (git revert) ; une empreinte numérique a confirmé le retour exact à l’état précédent. Sans historique, c’était impossible : le fichier dégradé restait parfaitement cohérent, et rien n’indiquait quelle consigne retirer. Pour une direction, c’est la différence entre une dérive inexpliquée et un incident daté, attribué et clos en une opération.

À retenir. Avec la mauvaise règle, l’agent a reclassé comme « bloquants » neuf défauts qu’il jugeait « majeurs » auparavant, sur le même code. Une règle qui limite ce que l’agent peut signaler ne change pas ce qu’il voit, mais la façon dont il le rapporte : seule une mesure de référence le révèle.

Benchmark : trois façons de définir un agent

Seule la colonne GitAgent repose sur nos mesures (cases « mesuré ») ; les autres viennent de la documentation publique de chaque projet.

Critère	Git-native · GitAgent / OpenGAP	Code-first · LangGraph, OpenAI Agents SDK	Config-first · CrewAI
Traçabilité	Règles, mémoire et compétences versionnées par défaut	Le code oui ; la mémoire est stockée en base	La configuration oui ; la mémoire est gérée par le framework
Retour arrière	Une commande, vérifiable (mesuré)	Annuler, puis redéployer	Annuler, puis redéployer
Portabilité	Export vers une quinzaine d’outils (mesuré)	Liée au framework	Liée au framework
Orchestration complexe	Limitée : enchaînements simples	Avancée : scénarios complexes entre agents	Intermédiaire : étapes en séquence

Portabilité (mesuré). Exporté vers Claude Code, Cursor et Copilot avec le même modèle, l’agent détecte de 97,9 % à 100 % des défauts. Ces approches sont complémentaires : GitAgent encadre la définition des agents, un framework d’orchestration enchaîne leurs étapes.

Industrialiser : quatre bonnes pratiques

À exiger de vos équipes techniques avant d’étendre l’usage des agents au-delà des tests :

1. Limiter les droits là où l’agent s’exécute. Ses règles sont des consignes données au modèle ; ses droits réels dépendent de son environnement. Faites-le tourner isolé, avec des accès limités au strict nécessaire.
2. Relire l’historique, y compris les modifications que l’outil fait automatiquement à chaque démarrage.
3. Tester les garde-fous : vérifiez qu’un contrôle en échec empêche bien l’agent de démarrer.
4. Relire tout agent externe avant de l’utiliser, comme une bibliothèque logicielle.

Ce qu’il faut retenir, et comment démarrer

1. Un agent mérite d’être géré comme du code. Historique, relecture, retour arrière : Git transforme une dérive inexpliquée en incident traçable.
2. GitAgent sert à gouverner, pas à orchestrer. Il répond à « qui a changé quoi, quand, et comment revenir en arrière ? », pas à « comment enchaîner plusieurs étapes métier ? ».
3. Git ne suffit pas sans mesure de référence. Git montre ce qui a changé ; la référence dit si c’est une amélioration. Sans elle, notre dégradation serait passée pour un progrès.

Pour démarrer efficacement, en trois étapes :

1. Sortez les règles de l’interface et placez les instructions de vos agents dans un dépôt Git.
2. Mesurez avant de changer, sur des cas dont vous connaissez déjà la bonne réponse.
3. Imposez la relecture, puis suivez deux indicateurs : la part des changements relus avant application, et le temps pour revenir en arrière en cas de problème.

Et vos agents ?

Vos agents IA prennent des décisions qui engagent votre organisation. Leurs règles méritent la même rigueur que votre code. Discutons de la gouvernance de vos agents IA : nous partageons volontiers la méthode, les chiffres et le protocole de ce retour d’expérience.

Sources

1. Gartner, « Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027 », 25 juin 2025.
2. SonarQube Community 26.10, analyse du code source sans compilation.