Si l’IA écrit le code, la session doit-elle aussi faire partie du commit ?

(github.com/mandel-macaque)

26 points par GN⁺ 2026-03-03 | 4 commentaires | Partager sur WhatsApp

git-memento est un outil d’extension qui enregistre automatiquement dans les commits Git les sessions de code générées par l’IA, en stockant l’historique de chaque conversation IA associée à un commit dans des git notes
Lors du commit, si l’ID de session IA est indiqué, le résumé est stocké dans refs/notes/commits et la conversation complète dans refs/notes/memento-full-audit, séparément, afin d’assurer à la fois traçabilité et confidentialité
Il prend en charge divers fournisseurs d’IA comme Codex et Claude, et permet d’appliquer des skills personnalisés lors de la génération du résumé afin de contrôler la qualité des notes de commit
Intégré à GitHub Actions, il offre des fonctions de commentaires automatiques sur les notes de commit, de vérification par CI, et de transfert automatique des notes lors d’une fusion (merge-carry)
Compatible Windows/macOS/Linux. Un outil qui améliore la transparence de la génération de code par IA et garantit, en environnement collaboratif, la capacité d’audit des contributions de l’IA

Présentation de git-memento

git-memento est une extension Git qui enregistre les sessions de codage avec IA au niveau du commit
- Au moment du commit, elle organise le contenu de la conversation de la session IA et l’enregistre sous forme de note Markdown
- Elle laisse, pour chaque commit, la source et le contexte conversationnel de la session IA, ce qui permet de retracer le processus de génération du code
L’outil prend en charge Codex par défaut, et d’autres modèles d’IA comme Claude peuvent aussi être configurés
Il est publié sous licence MIT et distribué sous forme d’exécutable autonome basé sur NativeAOT

Principales commandes et fonctionnalités

git memento init initialise la configuration du dépôt et enregistre les informations du fournisseur d’IA dans .git/config
La commande git memento commit ajoute une note de session en même temps que le commit
- Avec l’option --summary-skill, le résumé et la session complète sont stockés séparément
- Le résumé est enregistré dans refs/notes/commits, et le journal complet dans refs/notes/memento-full-audit
git memento amend permet d’ajouter une nouvelle session à un commit existant ou de la modifier
git memento audit vérifie, sur une plage de commits, l’absence de notes manquantes et la validité des métadonnées
git memento doctor contrôle la configuration, les références de notes et l’état de synchronisation avec le dépôt distant

Gestion et synchronisation des notes

git memento share-notes pousse les notes vers un dépôt distant (origin, etc.)
git memento notes-sync fusionne en toute sécurité les notes distantes et crée des sauvegardes
- Synchronise à la fois refs/notes/commits et refs/notes/memento-full-audit
git memento notes-carry transfère les notes vers un nouveau commit après un rebase ou un squash
git memento notes-rewrite-setup active la configuration de transfert automatique des notes

Intégration à GitHub Actions

Le dépôt inclut une GitHub Action réutilisable
- mode: comment — lit les notes de commit pour rédiger automatiquement un commentaire
- mode: gate — vérifie en CI l’absence de notes manquantes et bloque le build en cas d’échec
- mode: merge-carry — transfère les notes vers le commit de fusion lors de la fusion d’une PR
Chaque mode est défini dans action.yml, avec l’artefact destiné à la publication sur la Marketplace (dist/note-comment-renderer.js) inclus
Les PR portant le label ignore-notes ignorent la vérification gate et laissent un commentaire « Notes ignored »

Format des notes et gestion des versions

Les notes sont enregistrées au format git notes add -f -m ""
Des tags de version (``) et des séparateurs de section sont utilisés pour prendre en charge plusieurs sessions
Les messages utilisateur sont étiquetés avec le nom d’utilisateur Git, et les réponses de l’IA avec le nom du fournisseur
Les anciennes notes à session unique sont automatiquement mises à niveau si nécessaire afin de préserver la compatibilité

4 commentaires

wedding 2026-03-03

Pour les projets privés, j’exporte la session et je la commit ; pour les projets publics, je ne la commit que si j’estime qu’un fichier de résumé est vraiment nécessaire.
Il y a aussi la question des données personnelles... et selon l’outil, on dépasse facilement les 10 Mo par session... donc je préfère éviter de les mettre en ligne sans réfléchir.

roxie 2026-03-28

Mais nous vivons à une époque où les disques n'ont jamais été aussi bon marché !

GN⁺ 2026-03-03

Avis sur Hacker News

Quand j’écris du code avec une IA, je commence par un fichier project.md
J’y décris le résultat que je veux obtenir, puis je demande à l’IA de rédiger un plan.md à partir de cela
Ensuite, je révise plusieurs fois plan.md jusqu’à obtenir le plan souhaité, puis je génère une liste de tâches détaillée que j’ajoute à la fin de plan.md
Une fois entièrement satisfait, j’ordonne à l’IA d’exécuter les tâches et d’aller jusqu’au bout sans me redemander quoi que ce soit
Enfin, je commit project.md, plan.md et l’ensemble du code
De cette façon, plan.md devient une sorte d’artefact reproductible, qu’un modèle plus avancé pourra ensuite utiliser pour modifier le code ou repérer des erreurs
- Je fais quelque chose de similaire, mais en séparant en trois documents — design, plan, debug
  Le design est rédigé par fonctionnalité, en indiquant explicitement les questions non résolues
  Le plan est géré selon la structure plan/[feature]/phase-N-[description].md, et je m’arrête dès que je bute sur une limite de build ou d’exécution
  À l’étape debug, j’élabore des hypothèses sur les causes possibles, puis je les vérifie via logging/tracing avant de corriger
  Avec cette méthode, j’ai obtenu un taux de réussite proche de 100 % aussi bien sur des projets neufs que legacy
  L’inconvénient, c’est l’accumulation de trop nombreux fichiers Markdown, mais comme l’historique est utile pour les changements futurs, je n’ai pas encore automatisé ça
- Ça ressemble à une approche pilotée par les spécifications
  Le GitHub spec-kit vaut le détour
- La fonctionnalité “brainstorming” de obra/superpowers suit quasiment le même workflow. C’est vraiment excellent à l’usage
- J’utilisais Beads de cette façon auparavant, puis j’ai créé GuardRails
  En faisant itérer le modèle sur des études de marché et des revues de propositions, on finit par concevoir des prompts dans un langage que le modèle comprend lui-même
  J’ai récemment découvert que le XML influence le comportement de Claude, donc je repense actuellement la structure de GuardRails
  Lien vers l’article de présentation
- J’utilise une structure proche moi aussi, mais avec un fichier “context” séparé
  Une fois le plan terminé, je crée un context.md pour pouvoir m’y référer plus tard si je dois revenir sur un mauvais plan
  Je n’en ai pas encore eu besoin en pratique, mais conceptuellement c’est utile
  En revanche, je ne sais pas trop où placer ces fichiers, donc je ne les inclus pas encore dans le repo
  Je serais curieux de savoir où vous stockez ces fichiers md par tâche
À mon avis, c’est le même type de question que « faut-il committer chaque ligne ? »
Au fond, la vraie question est : pour qui conserve-t-on cet historique ?
La plupart des sessions contiennent beaucoup de bruit, de fausses pistes et d’informations inutiles
Ce qui compte, c’est le résultat de la session, pas le processus en lui-même
En revanche, la spec initiale ou le premier prompt peuvent avoir de la valeur. Les résumer dans un message de commit ou un fichier Markdown me paraît pertinent
- Pour les humains, c’est complexe et bruyant, mais ce type d’information de session peut être utile à une future IA
  On peut utiliser les sessions passées comme contexte d’apprentissage pour prolonger le travail en cours
  Cela peut notamment aider à comprendre les limites du modèle et à repérer les points où le code s’est écarté de l’intention de l’utilisateur
  Au final, je pense qu’enregistrer toutes les entrées humaines est important pour faire progresser les modèles open source
- Une meilleure analogie que « committer chaque ligne » serait peut-être : faut-il conserver toutes les notes et toutes les tentatives ratées ?
- La recherche scientifique se heurte déjà à ce problème — la crise de la reproductibilité
  Il faut pouvoir obtenir le même résultat, même en tenant compte des conditions initiales et du bruit
  Sinon, la maintenance future du code deviendra un jeu de devinettes sur les intentions
  Article lié
- Pour les organisations où la transparence est importante, cela peut avoir une valeur d’audit, mais en pratique, qui va lire ces longs logs ?
- Il n’est pas nécessaire de stocker toutes les sessions, mais les moments où les exigences se précisent au fil des corrections valent la peine d’être conservés
J’ai proposé une idée similaire il y a une semaine (lien)
Mais il y avait aussi beaucoup d’opposition : un projet IA n’est pas généré à partir d’une seule entrée, c’est un processus conversationnel, donc il est difficile d’en faire un artefact comme le code source
Malgré tout, il y a tellement de projets générés qui arrivent sur Show HN que le bruit devient un vrai problème
On ne peut pas les exclure complètement, mais dans l’état actuel, ça devient moins intéressant
Je réfléchis à la manière dont la communauté devrait traiter ce sujet
- Je m’inspire de la façon dont Boris Tane utilise Claude pour coder
  Je commit research.md et plan.md, que j’utilise comme dictionnaire vivant de l’architecture et des fonctionnalités
  Je préfixe les noms de fichiers par le nom de la fonctionnalité pour que Claude puisse retrouver rapidement les conceptions liées
  Billet de blog de référence
- Le problème, ce n’est pas le manque de contexte, c’est l’abaissement du seuil d’effort
  Des projets qui auraient semblé intéressants autrefois sont désormais trop faciles à produire
  Forcer les gens à lire de longs logs de session n’est pas la solution. La capacité de synthèse et de conception devient plus importante
- Ce serait bien que Codex puisse exporter toute une session en Markdown
  La vraie valeur du vibe coding, c’est de voir le processus d’essais et d’échecs
- J’hésite moi aussi à publier deux projets sur Show HN
  C’est plus intéressant quand il y a le récit de fabrication et des explications, pas seulement le résultat
  C’est pourquoi j’aimerais voir, en plus de [Show HN], une catégorie du type [Creations]
  Par exemple : un simple moteur d’échecs irait dans [Creations], tandis qu’un moteur d’échecs fait en 1k irait dans [Show HN]
  PerfBoard et Lerc en sont de bons exemples
Une session n’est qu’un artefact intermédiaire ; il n’est pas nécessaire de l’inclure dans le résultat final
Si la raison des changements de code est importante, il vaut mieux la formaliser dans le message de commit ou la documentation
- Au fond, c’est un problème de résumé
  Au moment du commit, on ne peut pas savoir quelles questions se posera le futur lecteur
  C’est pourquoi je préfère conserver la session, puis générer plus tard un résumé à partir de questions
  Git AI utilise cette approche
  Les ingénieurs vont tellement vite aujourd’hui qu’au bout d’une semaine, beaucoup ne se souviennent déjà plus pourquoi ils ont fait tel choix
- Il faut au minimum une version résumée de la session
  Les prompts de recherche devraient être résumés, tandis que les prompts de génération de code devraient être conservés tels quels
  Cela permet de garantir la reproductibilité et la possibilité de revue
- Avant, je faisais seulement écrire les messages de commit par le LLM, mais maintenant j’ai l’impression que versionner les fichiers de plan est une meilleure approche
  Le plan intègre même le processus de correction d’erreurs, ce qui en fait un document utile pour l’itération suivante
- Dans mon cas, le repo lui-même sert de mémoire de l’agent
  Chaque repo échange des messages avec d’autres et gère les demandes de fonctionnalités
  J’y stocke à la fois la conversation d’origine et une mémoire compressée sémantiquement, afin de réorganiser les specs et les exigences
- Stocker les sessions peut aussi servir à retracer l’origine d’un bug ou à faire des analyses a posteriori
Les logs de session sont principalement du bruit
C’est une suite de tentatives ratées et de retours en arrière ; les mettre à côté des commits revient à conserver l’historique du navigateur
Ce qui compte, c’est le message de commit qui porte l’intention et les contraintes
Si une IA a écrit le code, l’essentiel n’est pas la conversation, mais pourquoi on lui a demandé cela
En fin de compte, le vrai problème n’est peut-être pas le stockage des sessions, mais la mauvaise habitude de négliger les messages de commit
Même en utilisant une IA, je garde une procédure de conception traditionnelle
exigences → cas d’usage → conception des classes → définition des contraintes → exécution par l’IA
Cela permet de préserver le jugement architectural humain tout en laissant l’IA accélérer l’implémentation répétitive
Si on inclut dans le commit ce type de documents UML/contraintes plutôt qu’un log de session, on laisse une trace claire de l’intention et du contexte
Je pense qu’en 2026, les développeurs devront préserver ce cadre de collaboration de qualité
C’est similaire à la question de savoir s’il faut squash les commits ou non
Si on préfère le squash, seul le résultat compte et on ne conserve pas le processus
Si l’on pense l’inverse, on documente aussi le parcours
Pour les sessions IA, c’est pareil : c’est utile pour déboguer le raisonnement, mais ceux qui préfèrent un historique propre n’ont pas forcément besoin de le voir
En pratique, il est plus réaliste de gérer les sessions séparément du repo
- Je suis moi aussi plutôt team squash, mais si un système permettait de dérouler l’historique interne, j’aimerais aussi pouvoir voir les sessions
  J’ai entendu dire que Mercurial ou Fossil gèrent mieux ce genre de choses
- Je trouve que c’est l’analogie la plus juste
  En vibe-coding, plus que le code lui-même, ce sont les prompts qui montrent les traces de la réflexion
  Les mettre ou non dans git est une autre question, mais le fait qu’ils restent accessibles a de la valeur
- Dans un développement piloté par un humain, l’usage de l’IA n’est qu’un outil
  Dans ce cas, il n’est pas nécessaire de voir le processus en temps réel
  Mais si le code a été entièrement produit par l’IA, alors la publication des prompts devient nécessaire
J’ai déjà extrait des sessions moi aussi
Il y a un certain risque de perte d’information, mais la lisibilité et l’accessibilité y gagnent énormément
Je pense qu’il faut au minimum conserver les prompts résumés d’une session
Les revues de code par IA sont moins rigoureuses que celles des humains, et l’intention n’existe souvent que dans les prompts
Sinon, on risque de répéter les mêmes erreurs
La valeur d’une revue de code, c’est l’apprentissage et l’amélioration ; comme l’IA n’apprend pas, l’historique des prompts doit en tenir lieu
C’est aussi utile pour évaluer la qualité des prompts ou former des juniors
- Mais je ne suis pas d’accord avec l’idée que ce soit « évident »
  Nous n’incluons pas dans les commits les frappes clavier, les clics dans les menus ou les tentatives de debug
  Si l’on conserve toutes les conversations, il y a beaucoup trop de bruit
  En pratique, mieux vaut ne garder qu’un document qui résume l’intention et les hypothèses
- Au passage, je serais curieux de savoir quelle taille de session tu as en tête
C’est comme demander : « faut-il inclure l’historique Google dans les commits ? » — je pense évidemment que non
- C’est l’analogie parfaite. Enregistrer chaque fragment de pensée donne un rapport signal/bruit bien trop mauvais
  Mieux vaut ne garder qu’un résumé des raisons, hypothèses et alternatives
- Mais si l’on archive la session, on conserve aussi les requêtes de recherche et leurs résultats effectués par l’IA, ce qui peut être utile pour le contexte du projet
- Personne n’a envie de savoir combien de fois quelqu’un a cherché « centrer une div »
  De la même manière, les logs où le modèle patauge sur des détails insignifiants sont inutiles
- En plus, toutes les recherches n’ont pas forcément de lien avec le commit. Elles peuvent aussi contenir des informations sensibles