Lore: Repurposing Git Commit Messages as a Structured Knowledge Protocol for AI Coding Agents

Ce papier propose « Lore », un protocole léger réutilisant les messages de commit Git pour capturer le « Shadow de décision » (raisonnements, contraintes et alternatives rejetées) et ainsi préserver la connaissance institutionnelle pour les agents de codage IA.

L'essentiel

🕵️‍♂️ Le Problème : L'Ombre des Décisions

Imaginez que vous construisez une maison. À la fin, vous avez les murs, le toit et les fenêtres. C'est le code de l'ordinateur.

Mais imaginez que vous n'avez laissé aucune trace de pourquoi vous avez fait ces choix.

• Pourquoi avez-vous mis la cuisine à gauche et pas à droite ?
• Pourquoi avez-vous choisi ce type de bois ?
• Avez-vous envisagé de mettre une piscine, mais l'avez-vous rejeté parce que le terrain était trop humide ?

Tout ce raisonnement, ces alternatives rejetées et ces contraintes, a disparu. L'auteur du papier appelle cela l'Ombre de la Décision (Decision Shadow).

Aujourd'hui, quand un développeur (humain ou robot) modifie un logiciel, il enregistre seulement le résultat final (le "diff"). Il perd tout le contexte. C'est comme si un futur architecte arrivait dans votre maison, voyait la cuisine, mais ne savait pas pourquoi elle est là. Il risque de faire des erreurs ou de refaire des erreurs que vous aviez déjà évitées il y a 5 ans.

🤖 Pourquoi c'est urgent ?

Aujourd'hui, les Intelligences Artificielles (IA) écrivent et lisent de plus en plus de code.

1. Les IA lisent le code : Elles essaient de comprendre ce qu'il faut modifier. Mais si elles ne voient que les murs sans savoir pourquoi ils sont là, elles sont perdues.
2. Les IA écrivent le code : Quand une IA écrit du code, elle résume souvent ce qu'elle a fait, mais elle ne garde pas le "pourquoi". Le problème s'aggrave : plus le code grandit, plus l'histoire (le savoir) disparaît.

💡 La Solution : "Lore" (La Légende)

L'auteur, Ivan Stetsenko, propose une idée géniale : n'achetez pas de nouveaux outils compliqués. Utilisez ce que vous avez déjà.

Actuellement, les développeurs utilisent Git (un outil pour sauvegarder les versions du code). À chaque sauvegarde, ils écrivent un petit message (un "commit message"). Aujourd'hui, ces messages disent souvent : "Correction du bug" ou "Ajout de la fonction X". C'est très ennuyeux et peu utile pour une IA.

Lore propose de transformer ces petits messages en cartes au trésor structurées.

L'analogie du "Journal de Bord"

Imaginez que chaque fois qu'une IA ou un humain modifie le code, il doit remplir un petit formulaire spécial dans son journal de bord, juste avant de le signer. Ce formulaire ne décrit pas seulement ce qui a changé, mais le contexte de la décision.

Le papier utilise une fonctionnalité existante de Git appelée "Trailers" (des étiquettes en bas du message) pour ajouter ces informations de manière automatique et lisible par les machines.

Voici ce que ce formulaire contient (avec des analogies) :

• Les Contraintes (Constraint) : "Je ne pouvais pas utiliser la porte arrière car elle est bloquée par un mur." (C'est une règle qui doit être respectée plus tard).
• Les Rejetés (Rejected) : "J'ai pensé à utiliser la fenêtre, mais c'était trop dangereux." (Pour que l'IA ne réessaie pas la même erreur dans 6 mois).
• La Confiance (Confidence) : "Je suis sûr à 100% de ce choix" ou "C'est un peu un pari, surveillez ça."
• Les Instructions (Directive) : "Si vous changez ça dans le futur, faites attention à ne pas casser le pont." (Un message du passé vers le futur).

🛠️ Comment ça marche en pratique ?

L'avantage énorme de Lore, c'est qu'il ne demande aucune nouvelle infrastructure.

• Pas de base de données géante.
• Pas de serveur central.
• Pas de logiciel coûteux à installer.

Tout est déjà là, dans l'historique de votre projet.

1. Pour les humains : C'est un simple texte dans l'historique.
2. Pour les IA : Il existe un petit outil en ligne de commande (un "CLI") qui permet de poser des questions à l'historique.
   • L'IA demande : "Quelles sont les règles pour modifier ce fichier ?"
   • L'outil Lore répond : "Voici les contraintes, voici ce qui a été rejeté, voici les avertissements."

🆚 Pourquoi pas d'autres solutions ?

Le papier compare Lore à d'autres idées :

• Les ADRs (Architectural Decision Records) : Ce sont de longs documents séparés. Le problème ? Ils se déconnectent du code. Si le code change mais pas le document, le document devient faux. Lore, lui, est collé au code comme une étiquette sur un colis. Impossible de les séparer.
• Les "Jumeaux Numériques" : Des systèmes ultra-complexes et lourds. Lore est léger comme une plume.
• Les commentaires dans le code : Les commentaires sont souvent faux ou oubliés. Lore est un historique immuable et vérifié.

🚀 En résumé

Lore, c'est comme donner une mémoire à long terme à vos projets informatiques.

Au lieu de laisser les IA et les humains deviner pourquoi le code est fait d'une certaine manière, on leur laisse un journal de bord structuré à chaque étape. C'est simple, gratuit (car basé sur Git), et cela permet aux intelligences artificielles de ne pas répéter les mêmes erreurs, de comprendre les pièges évités, et de construire sur des bases solides.

C'est passer d'un code qui dit "Voici ce que je fais" à un code qui dit "Voici ce que je fais, pourquoi je le fais, et ce que vous ne devez surtout pas faire".

Résumé technique

1. Problématique : L'Ombre de la Décision (The Decision Shadow)

L'article identifie un problème critique dans le développement logiciel moderne, exacerbé par l'essor des agents de codage IA : la perte accélérée de connaissances institutionnelles.

• Le phénomène : Chaque commit Git capture la différence de code (le « quoi »), mais dissipe le raisonnement sous-jacent (le « pourquoi »). Ce contexte perdu inclut les contraintes, les alternatives rejetées, les compromis de conception et les directives futures. L'auteur nomme ce contexte manquant l'Ombre de la Décision (Decision Shadow).
• L'urgence : Avec l'IA agissant à la fois comme productrice et consommatrice principale de code, les agents tentent de déduire l'intention à partir du code existant. Or, les messages de commit actuels (souvent de simples résumés de diff) transmettent un signal quasi nul. Cela conduit à une accumulation de « code legacy » fonctionnel mais dont la logique structurelle est perdue, rendant la maintenance par l'IA inefficace et risquée.
• Limites des solutions actuelles : Les approches existantes comme les Architecture Decision Records (ADR) ou les « jumeaux numériques de code » (Code Digital Twin) sont soit trop granulaires (architecture vs implémentation), soit trop lourdes en infrastructure (graphes de connaissances, bases de données séparées), ce qui crée des problèmes de synchronisation et de maintenance.

2. Méthodologie : Le Protocole Lore

L'auteur propose Lore, un protocole léger qui transforme le message de commit Git en un enregistrement de décision structuré et auto-contenu, sans nécessiter d'infrastructure externe.

• Concept de base : Le message de commit ne doit pas être une étiquette sur un diff, mais l'unité atomique de connaissance institutionnelle.
• Mécanisme technique : Lore utilise nativement les Git Trailers (un format clé-valeur standardisé dans Git, ex: Key: Value). Cela permet d'ajouter des métadonnées structurées sans modifier le cœur de Git ni créer de nouveaux fichiers.
• Structure du message Lore :
  1. Ligne d'intention : Décrit pourquoi le changement a été fait (et non ce qui a changé).
  2. Corps narratif : Contexte détaillé.
  3. Trailers (Métadonnées) : Données machine-optimisables. Le vocabulaire inclut :
     • Constraint: : Règles ayant façonné la décision.
     • Rejected: : Alternatives évaluées et rejetées avec leurs raisons.
     • Confidence: : Niveau de confiance de l'auteur.
     • Scope-risk: : Rayon d'impact (étroit, modéré, large).
     • Reversibility: : Facilité de retour en arrière.
     • Directive: : Instructions pour les futurs modificateurs (humains ou IA).
     • Tested/Not-tested: : Couverture de validation.
• Outil CLI : Un outil en ligne de commande (lore) permet d'interroger l'historique (ex: lore context <path>, lore rejected <path>, lore stale). Cet outil est conçu pour être découvrable et utilisable par n'importe quel agent IA capable d'exécuter des commandes shell.

3. Contributions Clés

1. Réutilisation d'un canal existant : Lore propose d'utiliser le message de commit, un artefact présent dans tous les projets Git, comme canal de connaissance structuré, éliminant ainsi le coût d'infrastructure.
2. Liaison atomique et immuable : Contrairement aux documents externes (ADR, Wiki) qui peuvent se désynchroniser du code, la connaissance Lore est fusionnée de manière immuable avec le changement de code spécifique qu'elle décrit.
3. Modèle de consommation pour les agents IA : Le protocole définit un flux de travail où l'agent découvre le protocole via le CLI, récolte les contraintes, filtre les anti-modèles (via les trailers Rejected:) et serialise ses propres décisions dans le prochain commit.
4. Comparaison rigoureuse : L'article compare Lore à cinq approches concurrentes (ADR, Jumeaux Numériques, Contrôleurs de Contexte Git, Attribution IA, et Générateurs de messages de commit) pour démontrer que Lore comble le vide spécifique des décisions d'implémentation avec un coût minimal.

4. Résultats et Validation (Proposée)

Bien que l'article soit une proposition théorique et méthodologique (datée de mars 2026), il ne présente pas de résultats empiriques chiffrés issus d'une étude de terrain passée, mais propose un plan de validation empirique :

• Hypothèse de validation : Une étude comparative sur six mois entre deux équipes travaillant sur le même projet.
  • Groupe A : Utilise des commits conventionnels.
  • Groupe B : Utilise le protocole Lore.
• Métriques attendues : Taux de réussite des tâches par l'agent, temps de correction, taux de réitération d'approches rejetées, et nombre de cycles de revue avant fusion.
• Analyse des objections : L'auteur anticipe les critiques (surcharge de travail, fenêtres de contexte limitées, risque de « gaming » du système) et y répond en soulignant que la surcharge est principalement lors de la revue (pas de rédaction), que la valeur est inter-session, et que le format structuré rend la qualité auditable.

5. Signification et Impact

L'article Lore représente un changement de paradigme dans la gestion de la connaissance logicielle pour l'ère de l'IA :

• Minimalisme comme fonctionnalité : En s'appuyant sur des fonctionnalités natives de Git (trailers) et en évitant les bases de données complexes, Lore rend la connaissance institutionnelle accessible à tous les projets, pas seulement aux grandes entreprises.
• Boucle de rétroaction pour l'IA : Il transforme le cycle de développement en une « roue de la connaissance » (knowledge flywheel) où chaque commit enrichit l'historique pour les agents futurs, permettant une évolution du code plus sûre et mieux informée.
• Passage du « Quoi » au « Pourquoi » : Il comble le fossé critique entre le code exécutable et le raisonnement humain/IA qui l'a produit, essentiel pour la maintenance à long terme des systèmes complexes.

En résumé, Lore propose une solution élégante et immédiate au problème de la perte de connaissance tacite, en transformant le message de commit, souvent négligé, en un canal de communication structuré et machine-lisible entre les générations d'agents de codage.