8. Améliorer, niveau par niveau

↑ L’essentiel · ← 7. Le rituel, tenu par l’IA · 9. Dangers et parades →

Les niveaux suivent la criticité de la fiche 6 ; le niveau 3 fait de la méthode une habitude.

Niveau	Ce qu’on ajoute	Passez au suivant quand…
1. Fonctionnel	Le critique technique (fiche 5, étapes 1 à 5)	les signes de réussite des étapes 1 à 5 sont vus chez chacun, et chaque IA fait pull, commit et push sans rappel
2. Cerveau nourri	La mémoire : la séance de la fiche 4	le test de la fiche 4 passe
3. Réflexion écrite	La méthode et les réflexes (fiche 3, fiche 4), à chaque question qui compte ; le questionnaire, si vous l’avez adopté	chaque décision a sa note, avec ses options et un lien vers les hypothèses qui la fondent
4. Skills	Toute consigne répétée devient un skill	plus personne ne réexplique la même procédure
5. Automatismes	Hook (déjà posé à l’étape 3 pour Claude Code), plugin Git	chez chacun, l’ouverture d’une session fait le pull sans qu’on le demande
6. Le serveur	Plus bas : les pistes git, non testées, et « Plus tard, un serveur qui veille »	—

La boucle

Jugez sur ces critères, pas au ressenti : 16 développeurs expérimentés croyaient que l’IA leur avait fait gagner 20 % de temps, alors qu’ils en avaient mis 19 % de plus (outils de début 2025) [4] ; les mesures de fin 2025 penchent vers une accélération, sans effet établi [4]. Quand l’IA se trompe, ne corrigez pas seulement sa réponse : corrigez le socle. Une note manquait ? Écrivez-la. Une règle était floue ? Reformulez-la. Une procédure a été réexpliquée ? Elle devient un skill. Une erreur qui revient, c’est une règle qui manque [17] ; vérifiez ensuite que le comportement change [17].

Gardez AGENTS.md court, puisqu’un fichier long est moins bien suivi [17] ; d’où une règle simple : une qui entre en fait sortir une. Anthropic conseille moins de 200 lignes, et de tailler sans pitié : si la retirer ne fait faire aucune erreur à l’IA, elle sort [17]. Le détail vit dans les notes et les skills ; archivez les notes périmées.

La veille (fiche 7) nourrit la boucle : chaque jour, les nouveautés des technologies du projet, classées de la régression à la révolution ; un niveau −1, 3 ou 4 devient une étude, puis une note ou une règle du socle.

Aller plus loin avec git, des pistes à explorer

Le montage de la fiche 7 est le classique : tout le monde travaille sur la branche principale, main ; un pull avant, un commit et un push après. Il a ses limites. Un conflit n’apparaît jamais sur GitHub : le push est refusé, et les deux versions se rencontrent sur le poste de celui qui fait le pull [20], bloqué tant qu’il ne l’a pas résolu, même quand le conflit touche surtout le travail d’un autre. Des IA qui commitent vite multiplient les conflits. Et une personne qui fait travailler plusieurs agents en même temps les voit se gêner entre eux.

Des pistes, pas une recette

Je n’ai pas testé ce qui suit. Ce sont des idées : il y a peut-être mieux, peut-être moins bien. À vous de les étudier, avec votre IA et avec ce qui existe déjà, ou d’en imaginer une autre, avec la méthode de la fiche 3. Pour commencer, par exemple : « Voici notre montage git et ses limites. Quelles façons de travailler à plusieurs avec git existent, avec ce que chacune coûte et ce qu’elle risque ? Donne tes sources. »

• Une branche par membre. L’IA de chacun pousse sur sa branche après chaque commit : ce push n’est jamais refusé, puisque personne d’autre n’y écrit, et le travail est à l’abri sur GitHub tout de suite. Le risque : tant qu’un conflit reste ouvert, les commits s’empilent sur la branche, qui s’éloigne de main, et le conflit grossit. La parade est une règle : un conflit ouvert se règle d’abord, ou l’on ne touche qu’à d’autres fichiers.
• Fusionner dans main à chaque commit. Une note restée sur une branche est invisible pour les IA des autres : sans fusion rapide, le cerveau partagé se découpe en morceaux. Ce qui ne se contredit pas se fusionne aussitôt ; seul le conflit attend.
• Les worktrees, pour qui fait travailler plusieurs agents à la fois : plusieurs dossiers de travail du même dépôt, chacun sur sa branche [20], pour que les agents ne se marchent pas dessus.
• Un agent qui fusionne, sur un serveur (plus bas). À chaque push, il fusionne dans main ce qui ne se contredit pas. En cas de conflit, il ne tranche pas : il écrit dans le dépôt un rapport de conflit, par exemple conflits/<date>-<sujet>.md, avec les deux versions, ce que chacune change, la décision à prendre et une demande toute prête pour retravailler le conflit avec une IA. Chez vous, un skill lit ce rapport et propose une résolution, que les membres concernés valident ou font réviser ; elle passe par ecrire-decision, puis la fusion se fait. Le serveur prévient l’équipe : un bot Telegram peut envoyer un sondage non anonyme dans un groupe, Discord aussi, pas l’API officielle de WhatsApp [21] ; chacun vote sous son nom. L’agent propose, l’équipe tranche.
• Ce qui existe déjà : les pull requests de GitHub, la proposition de fusionner une branche dans main, que l’équipe relit et commente avant de l’accepter [20].

Plus tard, un serveur qui veille

Quand le socle tient, un serveur peut garder une copie du dépôt toujours à jour, où un agent relit chaque commit. Il repère les contradictions que git fusionne sans alerte, sur des lignes différentes, et peut devenir l’agent qui fusionne des pistes ci-dessus.

À explorer, sans obligation. Le serveur peut aussi faire la veille seul, chaque matin, et vous l’envoyer par mail ou dans le groupe de l’équipe ; tenir un journal des changements du projet ; rappeler qui a commité quoi. C’est possible, pas une étape à franchir. Telegram s’y prête bien : un bot se crée en quelques minutes [21], le serveur lui fait envoyer des messages à l’heure voulue, et on peut lui écrire en retour. Le mien m’envoie mes rappels et ma newsletter du matin, et je lui en programme un nouveau d’un simple /rappel.

Le point du matin, en vrai. Mon propre serveur fait déjà, pour moi seul, le rapport de la fiche 7 : c’est mon projet Bureau. Chaque matin, un script relève les commits et les fichiers modifiés de chaque projet. Pour chaque projet qui a bougé, une IA en écrit une fiche où chaque affirmation pointe vers sa preuve ; une dernière IA lit ces fiches, avec mes décisions en attente, et en tire un résumé de 250 mots au plus. Ce que ça ajoute au point de la fiche 7 : un seul résumé pour toute l’équipe, preuves à l’appui, même pour qui n’a pas ouvert de session ce jour-là.

Sources de cette fiche

Toutes les sources, par famille : L’essentiel.

• [4] Le ressenti ne prouve rien. Des développeurs se croyaient plus rapides avec l’IA, et l’étaient moins. METR, étude du 12/07/25, puis son suivi du 24/02/26
• [17] Règles, mémoire, hooks et interdits dans Claude Code. Mémoire et AGENTS.md, bonnes pratiques, hooks, permissions, mode plan, PowerShell, les coûts d’une longue session, la fenêtre de contexte et le résumé
• [20] Git, GitHub et le contrôle de secrets. Conflits et fusion, push refusé, fins de ligne, pre-commit, gitleaks, ne pas synchroniser un dépôt par un cloud, chercher dans les fichiers, les liens dans un fichier Markdown sur GitHub, les liens d’un wiki GitHub, les worktrees, les pull requests, verrouiller un fichier avec Git LFS, pandoc, du Markdown au PDF
• [21] Les sondages par bot. Telegram, Discord, WhatsApp ↑ L’essentiel · ← 7. Le rituel, tenu par l’IA · 9. Dangers et parades →

Olivier & Mentordinator