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

Ce qui est mesuré (GitClear, 2024) : forte hausse du code dupliqué/copié-collé (au point de dépasser le code déplacé ou refactorisé) et un churn (code réécrit peu après sa création) en nette augmentation. C'est le seul constat chiffré qu'on se permet ici, parce qu'il est sourcé.

La direction : traiter le contexte IA comme une ressource d'équipe, pas individuelle. Le reste du module développe cette idée.

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 4). 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 5 §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 6). 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. Mesurer, sans inventer de chiffres

Si tu veux suivre l'effet de l'IA sur ton équipe, suis quelques signaux par rapport à ta propre baseline : la tendance compte, pas une cible importée d'ailleurs.

• Temps de cycle d'un ticket (ouverture → merge)
• Volume de commentaires de PR liés à des violations de conventions
• Couverture de tests
• Bugs détectés après merge

Aucun chiffre cible ici : ils dépendent trop de ton équipe, et personne ne peut honnêtement te promettre « -20 % ». Mesure chez toi, regarde si ça monte ou descend.

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

Tôt ou tard, un bug introduit dans une PR co-écrite avec l'IA partira en production. Ce n'est ni tabou ni honteux : c'est instructif, à condition d'en tirer quelque chose.

Les 5 questions du post-mortem

1. Quel modèle, quelle session ? Garde la référence (voir Module 8 sur l'audit trail).
2. Quel prompt a produit le code ? Conservé via le transcript de session.
3. Quelle étape de revue a manqué ? Le Verify d'EPCV ? Une revue humaine sautée ? Des tests insuffisants ?
4. L'erreur est-elle systémique ? Un pattern récurrent mérite une règle dans le fichier de contexte (CLAUDE.md / AGENTS.md / GEMINI.md) ou un hook.
5. Qu'est-ce qu'on met à jour ? Contexte, prompts, skills, hooks, tests CI — au moins une chose, pour que ce type de bug ne repasse plus.

La règle culturelle

Le post-mortem ne désigne pas un coupable. Le code a été signé par un humain (il en est responsable), mais la cause se trouve presque toujours dans le système : contexte manquant, prompt insuffisant, revue ratée. On corrige le système, pas la personne.

6. 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 publics). Pour le détail technique (exclusions, anonymisation, scan de secrets), voir le Module 8.

7. 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.

8. 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.