Le fichier d’instructions du projet
À la racine, versionné, relu en PR comme du code. Il contient les commandes, les conventions et les interdits. Quand quelqu’un s’en écarte, la discussion porte sur le fichier, pas sur la personne.
1 · Le socle commun
Des règles partagées, versionnées
Si chacun a son propre fichier d’instructions dans son coin, le code produit diverge autant que les configurations. La règle projet doit vivre dans le repo, comme le reste.
Ce qui reste local
Tes préférences de style de réponse, tes raccourcis, ta config d’outils : ça reste chez toi. Ne pollue pas le repo avec des goûts individuels.
Les garde-fous partagés
Les interdits critiques (secrets, force push, fichiers sensibles) doivent être des règles bloquantes ou des hooks, identiques pour tout le monde — pas une consigne que chacun applique à sa façon.
Mis à jour après chaque incident
Un piège découvert en review devient une ligne dans le fichier d’instructions. C’est comme ça qu’une équipe capitalise au lieu de répéter les mêmes corrections.
Le raccourci pour les nouveaux
Un bon fichier de règles fait gagner des jours à quelqu’un qui arrive : il donne le contexte que l’agent utilisera, et que l’humain lira aussi.
Court, sinon ignoré
Un fichier de six cents lignes n’est respecté ni par l’agent ni par l’équipe. Découpe par domaine et garde l’essentiel.
2 · La review
Relire une PR écrite avec une IA
Ce n’est pas la même activité que relire du code humain. Les erreurs ne sont pas au même endroit, et le volume est plus élevé.
| Code humain | Code assisté par IA | |
|---|---|---|
| Erreurs typiques | Étourderies, cas oubliés, raccourcis assumés | Code plausible mais faux, API inventée, cas limites bâclés |
| Apparence | Parfois brouillon, souvent cohérent avec l’intention | Toujours propre et bien nommé, ce qui endort la vigilance |
| Volume | Proportionnel au temps passé | Peut être énorme pour un petit besoin |
| Question clé | « Est-ce que c’est bien fait ? » | « Est-ce que ça fait bien ce qu’on voulait, et rien d’autre ? » |
×10la vitesse de production de code
×1,2la vitesse de relecture et de compréhension
=une file de PR qui s'allonge jusqu'à ce qu'on approuve sans lire
1
Exiger des PR petites
La règle qui compte le plus. Une PR de mille lignes ne sera pas relue, elle sera approuvée. Découper est la responsabilité de l’auteur, pas du reviewer.
2
Demander l’intention, pas le résumé
La description doit dire pourquoi ce changement existe et ce qui a été vérifié. Un résumé du diff généré automatiquement n’apporte rien au reviewer.
3
L’auteur reste responsable
Ouvrir une PR signifie « j’ai lu et je réponds de ce code ». Si l’auteur ne peut pas expliquer une ligne, elle ne devrait pas être là.
4
Automatiser la première passe
Lint, types, tests, revue automatique : tout ce qui est mécanique doit être attrapé avant l’humain, pour que la relecture porte sur le fond.
3 · Le cadre
Décider ensemble jusqu’où va l’IA
Sans discussion explicite, chacun improvise sa propre limite — et ça finit en conflit au premier incident. Mieux vaut trancher à froid.
Les questions qui méritent une réponse d’équipe, écrite quelque part :
- Quelles parties du code peuvent être générées, et lesquelles demandent une écriture humaine (sécurité, paiement, données sensibles) ?
- Quelles données a-t-on le droit d’envoyer à un service externe ?
- Signale-t-on dans la PR qu’un changement est largement généré ?
- Quel est le plafond de taille d’une PR avant découpage obligatoire ?
- Qui tranche quand un agent propose un choix d’architecture ?
Le piège du niveau moyen : l’IA fait progresser vite les débutants
sur la production, mais pas sur le jugement. Une équipe où tout le monde produit du
code qu’une seule personne sait évaluer crée un goulot d’étranglement — et un risque.
La bonne pratique qui coûte le moins : imposer que l’auteur explique
son diff en review. Ça remet la compréhension au centre sans interdire quoi que ce
soit, et ça se remarque immédiatement quand elle manque.
4 · La documentation
Ce qui doit survivre aux sessions
Le contexte qu’un agent reconstruit à chaque session est perdu à chaque fois. En équipe, ce qui n’est pas écrit n’existe pas.
Les décisions, pas les descriptions
Documenter « pourquoi on a choisi ça et ce qu’on a écarté » a une vraie valeur. La description de ce que fait le code se périme et se relit dans le code.
Faire rédiger, toujours relire
Un agent écrit une doc claire en deux minutes à partir d’un diff. Il peut aussi inventer une justification plausible : c’est à toi de valider le « pourquoi ».
La doc morte est pire que rien
Une documentation fausse fait perdre plus de temps que son absence — humains comme agents s’y fient. Mieux vaut peu de doc à jour que beaucoup de doc périmée.
Vérifie que c’est acquis
Depuis que l’équipe utilise des agents, les PR sont deux fois plus nombreuses et beaucoup plus grosses. Quel est le vrai risque ?
La production accélère beaucoup plus que la relecture. Quand la file s’allonge, les
reviewers approuvent au lieu de lire — et le code généré a justement l’air propre, ce
qui endort la vigilance. La parade est organisationnelle : PR petites, intention
expliquée, auteur responsable.
À retenir
La contrainte s’est déplacée
Écrire du code n’est plus le goulot d’étranglement : le comprendre et le valider l’est devenu. Des règles partagées dans le repo, des PR petites, une intention expliquée et un auteur qui répond de son diff — c’est ce qui permet à une équipe d’aller vite sans accumuler de dette invisible.