IA en équipe

1. Le problème de l'IA non coordonnée

Quand chaque dev utilise l'IA sans coordination :

• Dev A a ses prompts perso → du code à sa sauce
• Dev B a ses propres règles → du code à une autre sauce
• Dev C laisse l'IA ressortir des patterns dépréciés que personne n'a documentés
• Les fichiers de contexte de chacun finissent par se contredire
• Et les revues de code prennent plus de temps qu'avant l'IA

2. Partager le contexte et les prompts

Le principe est simple : ce qui aide un dev à obtenir du bon code doit être versionné dans le repo et accessible à tous, pas gardé dans un coin de l'IDE de chacun.

Deux artefacts à mutualiser

1. Le fichier de contexte projet (CLAUDE.md / AGENTS.md / GEMINI.md, voir Module 5). Un seul owner nommé, responsable de sa justesse. Toute PR qui change une convention met le fichier à jour dans la même PR.
2. Les prompts récurrents, versionnés comme du code. La forme la plus naturelle aujourd'hui, ce sont les slash commands et les Skills de Claude Code (Module 6 §9) : des fichiers Markdown dans le repo, reviewés en PR, partagés par toute l'équipe. Inutile de réinventer un dossier .ai/prompts/ parallèle.

La règle de contribution

Un prompt qui t'a fait gagner du temps mérite une PR. Avant de le merger, un pair le teste au moins une fois. S'il vieillit mal avec une nouvelle version de modèle, on ouvre une issue et on le corrige, exactement comme du code.

3. Revue de Code Augmentée

La revue avec l'IA ne remplace pas le reviewer humain. C'est une revue en 3 temps.

Temps 1 — Pré-soumission (par l'auteur)

Avant d'ouvrir la PR, l'auteur se sert de l'IA pour s'auto-relire :

Objectif : arriver en PR avec un code déjà dégrossi, moins d'allers-retours.

Temps 2 — Revue assistée (par le reviewer)

Le reviewer humain utilise l'IA pour approfondir les parties complexes :

Objectif : le reviewer comprend mieux et pose de meilleures questions.

Temps 3 — Agent automatisé (dans le pipeline CI)

L'agent CI fait une passe automatique sur chaque PR (Module 7). Objectif : sortir les problèmes systématiques (sécurité, conventions) avant la revue humaine.

Ce que la revue IA ne remplace PAS

• La compréhension du contexte métier
• La discussion sur les choix d'architecture
• La validation que la feature répond au besoin utilisateur
• Le mentorat (expliquer pourquoi, pas seulement quoi)
• Le consensus d'équipe sur les décisions importantes

4. Quand un bug IA-assisté part en prod

Soyons réalistes : il n'y aura pas de post-mortem. Il y aura un correctif à 18 h, un déploiement, et on passe à autre chose. Le seul réflexe qui tient dans ces conditions est une question, à se poser au moment du fix : est-ce que l'agent va me le refaire ?

Si la réponse est non, c'était un accident, tu corriges et tu oublies. Si c'est oui, le correctif ne peut pas rester seulement dans le code : le code corrigé ne dit rien à l'agent la prochaine fois. Il doit atterrir quelque part qu'il relit. Une ligne dans le fichier de contexte suffit souvent. Un test vaut mieux, parce qu'il échoue tout seul au lieu de compter sur la bonne volonté du modèle.

C'est là qu'est la vraie différence avec un bug écrit à la main. Quand tu corriges un collègue en revue, la correction lui reste. Avec un agent, elle ne va pas plus loin que ta machine : ton collègue relance un prompt équivalent la semaine suivante et récupère le même code. Tant que ça n'est pas écrit dans un fichier versionné, l'équipe tourne en rond sans s'en rendre compte.

Sur la responsabilité, rien de spécifique à l'IA : le code a été signé par un humain, et « c'est l'agent qui l'a écrit » n'a jamais été une défense.

5. Le garde-fou des données

À l'échelle d'une équipe ou d'une entreprise, la vraie question n'est pas « est-ce qu'on utilise l'IA » mais « quelle donnée a le droit de partir vers quel modèle ». C'est le seul élément de gouvernance vraiment incontournable. Le reste (rétention, audits formels, contrats) relève de ta conformité interne, pas d'un guide comme celui-ci.

La règle pratique qui en découle : jamais de secret ni de PII réelle dans un chat grand public (Claude.ai, ChatGPT, Gemini, Mistral Le Chat publics). Pour le détail technique (exclusions, anonymisation, scan de secrets), voir le Module 9.

6. Convaincre les sceptiques

Toute équipe a ses sceptiques, parfois pour de bonnes raisons. Les ignorer rate l'adoption ; les écouter améliore la pratique. Quelques profils fréquents et une façon de répondre :

Le bon rythme d'adoption reste le même partout : commencer par des volontaires, mesurer sa baseline, étendre progressivement. On ne force pas, on montre.

7. Savoir qu'un prompt marche encore (evals légers)

Tu as versionné tes prompts, tes skills, tes slash commands. Une question reste : comment tu sais qu'ils marchent toujours ? Surtout le jour où le modèle change de version, ce qui arrive tous les trimestres sans te demander ton avis.

C'est le rôle des evals : des tests pour tes prompts, comme tu as des tests pour ton code. Rien de sophistiqué au début.

La version simple, mais qui marche :

• Garde 5 à 10 cas réels par prompt important : une entrée, et la sortie attendue (ou les critères que la sortie doit remplir).
• Quand tu changes le prompt, ou quand le modèle est mis à jour, tu rejoues ces cas et tu compares.
• Un cas qui régresse, tu corriges le prompt avant que ça parte en prod.

Ce que tu vérifies dépend du prompt. Parfois une sortie exacte (un JSON conforme au schéma). Parfois juste des critères : « le résumé mentionne bien la faille », « aucun secret dans la réponse ». Pour ces critères flous, tu peux même te servir d'un second modèle comme juge : un LLM qui note la sortie d'un autre selon une grille que tu écris. C'est pratique, mais souviens-toi que le juge se trompe aussi. Il dégrossit, il ne remplace pas ton œil.

Le moment où ça devient non négociable : dès qu'un prompt tourne sans humain dans la boucle (revue de PR en CI, tri de tickets, agent de support). Là, un prompt qui régresse en silence fait des dégâts en silence. Un petit jeu d'evals rejoué à chaque montée de version, c'est le filet.

Un prompt qui tourne en prod sans surveillance mérite ses evals, exactement comme du code qui tourne en prod mérite ses tests.