Qui a modifié les règles de l’agent, et quand ?

Dans la plupart des systèmes existants, la question est sans réponse. La configuration d’un agent conversationnel ressemble à une cuisine dont personne ne connaît ni les recettes, ni les instructions données au cuisinier : du code éparpillé, des variables d’environnement enfouies, des bases de données sans journal — et aucune trace de qui a touché à quoi, ni pourquoi. GitClaw part d’une hypothèse en apparence simple : et si toute la définition d’un agent tenait dans un dépôt Git, versionné comme n’importe quel projet logiciel ?

La réponse, si elle semble évidente rétrospectivement, n’allait pas de soi. Car avant d’être un problème technique, c’est un problème de gouvernance. Qu’est-ce qu’on accepte de ne pas voir dans un système qui prend des décisions — ou plutôt, qui sélectionne des réponses — en notre nom ?

L’architecture de GitClaw tient en cinq éléments : un fichier agent.yaml pour le modèle et ses paramètres d’exécution, un fichier SOUL.md pour la personnalité, un fichier RULES.md pour les contraintes, un répertoire memory/ pour la mémoire persistante, et un répertoire skills/ pour les compétences modulaires. Rien d’autre ne définit le système. Cette sobriété est le cœur du projet.

Chaque modification — corriger une règle, reformuler un trait de caractère, ajouter une compétence — produit une validation Git (commit) standard, horodatée et signée. L’historique complet du système devient une ligne du temps consultable, à la manière des versions successives d’un article encyclopédique en ligne : chaque état est conservé, chaque changement est attribuable. Qui a durci les contraintes du système ? Quand la personnalité a-t-elle été reformulée ? Git répond nativement à ces questions — sans qu’on le lui demande.

Ce détail recèle une rupture réelle pour qui s’y arrête. Les grands modèles de langage (large language models, ou LLMs) sont sans état entre deux sessions — ils ne conservent aucune information d’une conversation à l’autre, comme un interlocuteur frappé d’amnésie à chaque réveil. Stocker la mémoire dans des fichiers versionnables la rend persistante sans base de données externe, sans infrastructure supplémentaire, sans couche logicielle supplémentaire à surveiller. C’est une forme d’élégance architecturale : réduire la surface d’incertitude en s’appuyant sur un outil que des millions de développeurs maîtrisent déjà.

Diagramme scientifique
Diagramme scientifique

Le mécanisme de retour arrière — ce qu’on appelle un rollback dans le jargon du contrôle de versions — devient alors presque trivial. Si une modification de RULES.md produit un comportement indésirable, une seule commande suffit à revenir à l’état précédent. L’analogie n’est pas celle d’un simple « annuler » dans un traitement de texte : c’est davantage un registre notarié qu’un bouton de retour. Chaque modification est datée, signée, immuable dans l’historique — tout en restant révocable dans la pratique.

Des cadres d’agents comme LangChain, AutoGen ou CrewAI offrent des fonctionnalités de traçabilité, mais généralement via des intégrations tierces plutôt que comme fondation native. GitClaw fait de cette garantie son point de départ, non une option à configurer séparément.

Il serait toutefois malhonnête de s’arrêter là. Git excelle sur la configuration textuelle, pas sur l’exploration de grands volumes de données. Pour parcourir sémantiquement une mémoire de milliers d’entrées — retrouver, parmi des centaines de conversations passées, celles qui concernent un thème précis —, les bases vectorielles surpassent généralement les fichiers plats à cette échelle. Des approches hybrides (fichiers indexés, SQLite avec extensions vectorielles) existent également. GitClaw ne prétend pas résoudre ce problème, et c’est à mettre à son crédit : il délimite son périmètre plutôt que de promettre l’universel.

La vraie question que le projet laisse ouverte est plus profonde. La traçabilité de la configuration ne dit rien de la traçabilité des décisions. Savoir que RULES.md a été modifié le 14 mars à 11h34 n’explique pas pourquoi le système a produit telle réponse plutôt que telle autre dans une session donnée. L’historique Git documente les intentions des concepteurs — pas le comportement du modèle. Ce sont deux registres distincts, et les confondre serait une erreur d’interprétation coûteuse.

Techniquement, le projet repose sur TypeScript 5.7 et Node.js dans une version égale ou supérieure à la vingtième, installable via le gestionnaire de paquets npm. Il expose une interface en ligne de commande et un kit de développement logiciel (SDK), extensibles par greffons (plugins) et crochets d’événements (hooks). L’interface de programmation d’Anthropic est requise pour faire fonctionner l’ensemble — ce qui signifie une dépendance commerciale non négligeable à documenter.

Au 26 mars 2026, le projet comptait 175 étoiles sur GitHub. Confidentiel, actif, encore balbutiant — l’outil intéresse, mais il n’a pas encore rencontré son heure.

Ce qui reste, au fond, c’est une intuition : que la question de la confiance dans les systèmes automatisés ne se résoudra pas uniquement par des règlements ou des certifications, mais par des conventions partagées — des pratiques communes, des formats lisibles, des historiques accessibles. Git n’est pas une réponse à la question de la gouvernance des agents. Mais il est peut-être le genre d’outil autour duquel une réponse pourrait s’organiser.

Reste à savoir si l’industrie est prête à regarder dans le rétroviseur aussi souvent qu’elle avance.

Source

GitClaw est un projet logiciel hébergé sur GitHub. Il ne fait pas l’objet d’une prépublication ou d’un article évalué par les pairs à ce jour. Les affirmations techniques reposent sur l’examen du dépôt source au 26 mars 2026. Les comparaisons avec d’autres cadres d’agents sont présentées à titre indicatif et sous réserve de vérification indépendante.

À lire aussi sur Mémorabilité :