Donner un cerveau à l'IA de votre équipe

Donner un cerveau à l'IA de votre équipe, l'essentiel

14 min de lecture

Cette page résume les neuf fiches et mène à chacune ; toutes les sources sont en bas. Si vous n’en lisez qu’une, lisez la fiche 4. Pour donner un cerveau à votre IA, un dépôt git de fichiers Markdown suffit, avec n’importe quel éditeur : « Obsidian », ici, est un mot d’habitude pour ce jeu de fichiers (fiche 2). Pour voir comment je me suis fait accompagner par l’IA pour construire ces fiches et ce site, lisez aussi les coulisses.

Quatre mots. Une règle : une consigne que l’IA lit à chaque session, avant tout ; les règles tiennent dans un fichier, AGENTS.md. La mémoire : les notes du projet, le but, les sources, les hypothèses, les décisions, le vocabulaire, que l’IA lit quand la tâche en a besoin, en partant d’un sommaire. Un skill : une procédure écrite une fois, par exemple « préparer un PowerPoint », avec le plan que l’équipe veut, son style et ce qu’on vérifie avant d’envoyer ; l’IA la lit seulement quand la tâche l’exige. Un agent : une IA autorisée à modifier vos fichiers et à lancer des commandes, dont git, sous réserve des règles écrites juste au-dessus ; un chatbot ne le peut pas.

Les mots de git. Git : l’outil qui garde l’historique de vos fichiers ; GitHub : le site qui héberge le dépôt partagé. Dépôt : le dossier partagé et son historique. Cloner : en faire une copie sur son poste. Commit : l’enregistrement d’un changement, avec son auteur et une phrase qui le décrit. Push : envoyer ses commits aux autres. Pull : récupérer ceux des autres. Conflit : deux personnes ont modifié les mêmes lignes, et git ne sait pas laquelle garder.

En six lignes

  1. Un chatbot oublie tout ; une IA efficace travaille dans un dossier de notes partagé qui lui sert de cerveau : le socle, avec ses règles, sa mémoire et ses skills.
  2. Ce socle est un dépôt GitHub de fichiers Markdown : un seul cerveau pour l’équipe, que chacun voit, quel que soit son outil d’IA.
  3. L’IA sera votre meilleur ami ou votre pire ennemi : elle amplifie ce qu’elle trouve. Ayez peur : contrôlez ce qu’elle sait, et ne perdez pas ce que vous savez.
  4. L’étape cruciale : la nourrir de tout ce que vous savez, puis réfléchir avec elle, en retouchant son plan, avant d’agir ; et ne rien laisser entrer dans le socle que vous ne compreniez. Faites-en trop.
  5. Une feuille de route pour démarrer. Ensuite, l’historique partagé, c’est git : c’est l’IA qui fait les pull, les commits et les push, sous des règles écrites et des interdits bloqués dans l’outil.
  6. Quand l’IA se trompe, on corrige le socle, pas seulement sa réponse : la note qui manquait, on l’écrit ; la règle floue, on la reformule ; la procédure qu’on a dû réexpliquer devient un skill. Une erreur qui revient, c’est une règle qui manque.

Les neuf fiches

1. Un chatbot n’est pas un collègue

  • Un modèle de langage oublie tout d’une conversation à l’autre : il ne voit que son contexte, une ressource finie, à remplir de peu d’informations, mais les bonnes.
  • Le piège de la longue session : à chaque message, le modèle relit toute la conversation ; plus elle est longue, moins il y retrouve ce qu’il cherche, et près de la limite l’outil la résume. Une session, une idée : ce qui doit rester va dans le socle, puis la session se ferme.
  • Le socle a trois couches : les règles (AGENTS.md, lues à chaque session), la mémoire (les notes du projet, lues à la demande en partant d’index.md), les skills (des procédures lues quand la tâche l’exige). Pour y travailler, il faut un agent, qui modifie les fichiers et lance git.
  • Agnostique, « sans avoir à savoir » quel outil ni quel modèle : le cerveau est en fichiers texte, chacun garde son outil d’IA, et l’équipe change de modèle sans rien perdre. À une condition : un seul fichier de règles, AGENTS.md ; pour Claude Code, un CLAUDE.md d’une ligne, @AGENTS.md, un import que le programme colle au lancement, là où la phrase « Lis AGENTS.md » laisse le modèle décider.
  • Le gain dépend de ce que vous écrivez. Sur des tâches de code, un fichier de règles généré par l’IA n’améliore pas la réussite de l’agent et coûte 20 % de plus ; écrit par les développeurs, il fait mieux que lui, de peu [5]. Ce qui marche, ce sont les consignes précises, que l’IA suit ; une description générale du projet ne sert à rien.

2. Le cerveau, vu dans Obsidian

  • Le cerveau, ce sont des fichiers texte sur votre disque, reliés par des liens écrits en clair : vous lisez exactement ce que l’IA lit, et git garde l’historique. N’importe quel éditeur convient. Obsidian, en plus, affiche les rétroliens, qui cite une note, et le graphe, où une note isolée est un souvenir que l’IA risque de ne pas trouver.
  • Ce que vous ne voyez pas, vous ne le contrôlez pas : l’IA amplifie ce qu’elle trouve dans ce cerveau, il faut donc pouvoir le lire en entier. Obsidian le montre ; un simple éditeur de texte le permet aussi.

3. Ayez peur

  • L’IA aide vraiment, mais ne prévient pas quand elle sort de son terrain : elle fait ce qu’on lui demande même quand elle ne sait pas, sans le dire, parce qu’elle est faite pour vous satisfaire et tend à vous donner raison [6]. Harvard et le BCG l’ont mesuré sur 758 consultants. Sur les tâches que l’IA savait faire, ceux qui l’avaient allaient plus vite et faisaient mieux. Sur une tâche construite pour la piéger, où la bonne réponse demandait de lire des entretiens aussi bien que des chiffres, ce que l’IA ratait, ils ont eu raison moins souvent que sans elle, 60 à 71 % contre 84,5 %, avec des réponses fausses mieux rédigées : ils avaient repris sa réponse sans l’interroger [1]. Elle amplifie ce qui existe déjà [3].
  • La méthode, pour toute tâche qui compte : le contexte, vos hypothèses, les siennes, vos réponses, la décision écrite, et alors seulement l’action.
  • Le plus grand danger, c’est vous : l’ingénieur risque de perdre ce qu’il sait ; qui apprend, de ne jamais l’acquérir. Déléguez la tactique, gardez la stratégie, et comprenez les principes : savoir écrire chaque ligne n’est pas le but.

4. L’étape cruciale : nourrir, puis réfléchir

  • Nourrir : une séance où toute l’équipe verse ce qu’elle sait, chaque chose à sa place (projet.md, sources/, hypotheses/, decisions/, glossaire.md), le solide séparé du supposé, jamais de secret. Faites-vous interroger par l’IA, puis testez avec une session neuve. Faites-en trop.
  • Réfléchir : ne jamais s’arrêter à sa première réponse ; six réflexes (des options, la contestation, les sources, la réfutation, un autre regard, écrire ce qui sort). Avancez quand chaque hypothèse dont dépend la décision est vérifiée ou son risque accepté par écrit, que la décision est écrite avec ses options, et qu’une session neuve sait dire pourquoi.
  • Le mode plan : l’IA propose, vous retouchez, passe après passe ; la puissance est dans vos retouches, et c’est là que se trace la ligne entre tactique et stratégie.
  • Le questionnaire, si l’équipe l’adopte : avant chaque commit, trois à cinq questions sur ce qui entre (des principes, des conséquences, des points clés), dont au moins une piège ; ou bien vous expliquez, et l’IA corrige.
  • Nourrir et réfléchir, c’est aussi ce qui vous protège du plus gros danger, la régression : perdre ce que vous savez faire, ou, quand on apprend, ne jamais l’acquérir. Servez-vous de l’IA pour apprendre et gagner en compétences, pas pour vous en dispenser.

5. La feuille de route Sept étapes, chacune avec son signe de réussite.

  1. S’équiper : git, un éditeur, un agent et un compte GitHub, chez chacun.
  2. Créer le dépôt GitHub privé ; chacun le clone sur son poste.
  3. Poser les protections : fichiers ignorés, contrôle de secrets, interdits bloqués, prouvées avant le premier push par un faux secret refusé.
  4. Écrire les règles : AGENTS.md et les deux premiers skills.
  5. Répéter un conflit : deux membres modifient exprès la même ligne, pour voir l’IA résoudre un conflit git avant qu’un vrai n’arrive.
  6. Verser ce que vous savez : la séance de la fiche 4, où toute l’équipe nourrit le cerveau.
  7. Poser la première vraie question : une question qui compte pour le projet, en mode plan, avec la méthode de la fiche 3 ; pas un essai pour voir.

Les étapes 1 à 5 se font une fois, à la création de l’équipe ; un nouveau membre refait la 1 et une partie des suivantes sur son poste. Les étapes 6 et 7 durent tout le projet : chaque chose apprise repasse par la 6, chaque question qui compte par la 7.

6. Le socle, par criticité

  • Ce qui est vital : un tableau dit, pour chaque élément du socle, ce qu’il protège, ce qui arrive sans lui, quand on s’en rend compte et si ça se rattrape. Vital avant le premier push : les interdits bloqués et le contrôle de secrets. Vital tout le projet, sans alarme : la mémoire nourrie, comprendre ce qui entre, la veille. Ce qui fait du bruit, l’outil vous le signale ; ce qui se dégrade en silence, personne.
  • Les gestes, un par un : git réglé sur chaque poste, un dépôt GitHub privé, cloné hors de tout dossier synchronisé par un cloud, .gitignore et .gitattributes avant toute note, AGENTS.md, index.md, la mémoire nourrie, les skills, un contrôle de secrets prouvé sur chaque poste, les interdits bloqués, un responsable des règles.
  • Trois exemples annotés, à lire avant d’écrire les vôtres : l’arborescence, avec production/, ce que l’équipe livre (des PDF fabriqués à partir du Markdown, le code dans le vault ou dans un dépôt à part) ; AGENTS.md ; un skill.

7. Le rituel, tenu par l’IA

  • Le rituel, ce sont les gestes git que l’IA fait à votre place, parce qu’un humain les oublie. Au premier message : elle fait commiter ce que vous avez écrit à la main, avec votre accord ; puis un pull, pour récupérer le travail des autres ; puis elle vous dit ce qui a changé depuis votre dernière session, lit le sommaire et pose ses questions. Avant chaque modification, un pull ; après, un commit dont le message dit le fait, puis le push.
  • Pour savoir ce qui a changé, l’IA pose une étiquette git, vu, sur le dernier commit que vous avez lu ; elle reste sur votre poste et avance après chaque point.
  • Une règle écrite reste un conseil : d’où le hook, une commande que l’outil lance seul à l’ouverture, quand il le permet, et les interdits bloqués dans ses réglages. Le commit porte votre nom : votre IA, votre responsabilité.
  • Une veille quotidienne des technologies du projet, classée de la régression à la révolution [22] : la première session du jour l’écrit dans le dépôt, et un niveau −1, 3 ou 4 ouvre une étude avant tout emploi.

8. Améliorer, niveau par niveau

  • Six niveaux : fonctionnel, cerveau nourri, réflexion écrite, skills, automatismes, serveur. Jugez sur ces critères, pas au ressenti : 16 développeurs expérimentés croyaient avoir gagné 20 % de temps avec l’IA, et en avaient mis 19 % de plus, avec les outils de début 2025 ; les mesures de fin 2025 penchent vers une accélération, sans effet établi [4].
  • Chaque erreur corrige le socle, et AGENTS.md reste court.
  • Aller plus loin avec git, des pistes que je n’ai pas testées : une branche par membre, fusionnée à chaque commit, et un agent qui fusionne et soumet les conflits à l’équipe.
  • Plus tard, un serveur qui veille : il relit chaque commit et peut faire le point du matin.

9. Dangers et parades Le plus gros danger reste la régression : perdre la main sur ce que vous savez faire, ou ne jamais l’acquérir. Ce cerveau est là pour vous épargner ce qui vous prend du temps alors que vous le maîtrisez déjà, jamais pour vous dispenser de comprendre. Gardez la maîtrise, sinon c’est le mur. Puis cinq dangers, à chacun son fait sourcé et sa parade : invention avec assurance, secrets poussés, agent qui détruit, consignes cachées, compétences perdues.

Commencer la lecture : 1. Un chatbot n’est pas un collègue →

Toutes les sources

Olivier & Mentordinator

Vue Graphique

Liens retour