Comment faisons-nous pour suivre les revues de PR à l'ère de l'IA ?

1. Limitez chaque PR à une seule chose

Le moyen le plus rapide de tuer l’élan d’une revue, c’est une PR qui fait trois choses à la fois. Les relecteurs ne devraient pas avoir à démêler mentalement quelles modifications relèvent du correctif de bug et lesquelles relèvent de la refactorisation que vous avez glissée au passage.

• Un correctif de bug, un champ, une fonctionnalité, pas les trois dans la même PR.

• Une PR ciblée d’environ 1 000 lignes qui résout un problème clair, c’est acceptable. Une PR de 300 lignes avec trois sujets, non. Si vous dépassez largement 1 000 lignes, c’est un signal fort qu’il faut la scinder.

• Utilisez des PR empilées pour les changements plus importants.

• Vérification rapide avant ouverture : quelqu’un peut-il relire cela en une seule fois ? Est-ce que cela fait exactement une seule chose ? Le fusionneriez-vous ?

2. Ne demandez pas de revue tant que ce n’est pas vraiment prêt

Les brouillons existent pour une raison. Sortir une PR du mode brouillon signale à l’équipe que vous avez fait preuve de diligence et que cela mérite le temps de quelqu’un d’autre. Si ce signal n’est pas fiable, tout le système de revue s’effondre.

Ne désactivez le brouillon que si vous pouvez répondre oui à tout ce qui suit :

• Vous avez fait une auto-revue

• Tous les tests passent, y compris l’e2e

• Zéro commentaire non résolu (y compris ceux de Devin)

• Vous l’avez testée localement pour les changements UI/UX

• Pour les changements qui peuvent être couverts par des tests automatisés, vous avez vérifié qu’ils sont couverts à 100 %

• Tous les jobs CI sont au vert (sauf les pénibles aperçus Vercel)

Si la réponse est non pour l’un de ces points, laissez-la en brouillon. Les brouillons qui demandent une revue polluent la file et retardent les PR réellement prêtes.

3. Limitez vos PR ouvertes à 5 (les brouillons comptent)

Les PR ouvertes sont du stock. Elles entraînent un coût de changement de contexte, un risque de conflit de fusion et une dette de revue. Si vous en avez plus de cinq ouvertes en même temps, le calcul ne tient pas. Vous produisez plus vite que l’équipe ne peut absorber.

Si vous avez 5 PR ouvertes, brouillons et non-brouillons confondus, ne commencez rien de nouveau. Allez plutôt relire les PR de vos coéquipiers ou terminez votre travail plus ancien.

4. Donnez une voix humaine à la description de votre PR

La description n’a pas besoin d’être entièrement rédigée par vous. L’IA convient pour poser la structure et résumer le diff. Le problème avec ce que nous voyons aujourd’hui, ce sont les énormes descriptions générées par l’IA qui ressemblent à une checklist générique avec laquelle personne n’a réellement interagi. Il manque l’élément humain dont un relecteur a vraiment besoin.

• Une note d’auteur en une phrase sur le compromis que vous avez choisi, ou sur les raisons pour lesquelles ce correctif est important maintenant, va plus loin qu’un long bloc « Key Review Points » / « Human Review Checklist ».

• Si vous livrez du code qui n’est encore utilisé nulle part, dites pourquoi.

• Si l’IA a rédigé la description, raccourcissez-la et ajoutez le contexte que vous seul connaissez.

5. Prouvez que le correctif fonctionne

Une PR qui dit « corrige le bug X » sans preuve demande au relecteur de vous croire sur parole. Ne lui faites pas faire ça.

• Captures d’écran, enregistrements d’écran, tableaux de bord avant/après, tout ce qui montre que le bug est bien corrigé et que rien d’autre n’a régressé.

• La QA fonctionnelle est obligatoire pour les changements UX/UI, pas facultative.

6. Les changements SQL et de performance nécessitent une vraie validation

La revue de code seule ne peut pas confirmer qu’une réécriture de requête tient sous la charge de production. Lire un diff de requête et dire « ça a l’air bon » n’est pas une validation. Pour les PR qui touchent aux chemins de requête ou aux réécritures :

• EXPLAIN ANALYZE sur un jeu de données ressemblant à la production

• Mesures de latence avant/après ou captures d’écran de tableaux de bord

• Déploiement progressif via feature flag pour les changements risqués

7. L’IA est un accélérateur, pas un cerveau

L’IA peut générer du code rapidement. Elle ne peut pas décider si ce code doit exister. La réflexion doit toujours venir de vous.

• Commencez par la conception. Esquissez l’approche, réfléchissez aux cas limites, rédigez une note rapide, puis lancez le prompt.

• Après la génération par l’agent, lisez-le vraiment. L’auto-revue repère des appels Prisma mal placés, des consignes d’agent ignorées, une structure fragile, etc.

• Avant d’ouvrir, demandez-vous : que touche cela ? Y a-t-il un impact utilisateur ? Des implications de performance ou de sécurité ? Quel est le rayon d’impact si c’est faux ?

8. Validez les PR de sécurité avant de les ouvrir

Vérifiez que la vulnérabilité s’applique réellement à la manière dont nous utilisons le code. Les PR « corrige la vulnérabilité X » qui touchent à des chemins sensibles peuvent introduire plus de risques que le signalement initial.

9. Orientez les PR vers le bon relecteur

Le mauvais relecteur fait perdre du temps à deux personnes : le relecteur qui ne peut pas fournir de retour utile et l’auteur qui doit attendre un second passage avec la bonne personne.

• Les PR très orientées domaine (routage Salesforce/CRM, migrations de profil d’équipe, etc.) doivent aller au propriétaire du domaine, pas à Foundation qui tamponne une suite de tests générée par l’IA.

• Les changements sur les chemins cœur/fondation (query infra, hasTeamAccess, etc.) méritent une rapide mise au point avec l’équipe propriétaire avant l’ouverture de la PR.

10. Les conversations d’architecture ont lieu tôt

Corriger la même zone trois fois est un signal, pas une coïncidence. Si vous contournez encore la même limitation, la bonne réponse est une discussion et éventuellement une réécriture, pas un correctif de plus.

Parlez à Foundation / Head of Engineering avant d’implémenter. C’est ainsi que les modules d’infrastructure ont été construits, et la cohérence se renforce avec le temps.

11. Parcours allégé pour les correctifs triviaux

Tout ne nécessite pas une revue Foundation. Nous devons consacrer la bande passante de revue là où elle compte le plus.

Les ajustements de toast, le dimensionnement des boutons, les renommages mécaniques, les changements de texte, les fonctionnalités principales - tout cela peut passer par une revue IA et/ou une revue au niveau de l’équipe. Réservez la revue Foundation aux changements qui en ont réellement besoin.

12. N’ouvrez pas de PR au nom des autres

Si l’ingénieur X fait le travail, c’est l’ingénieur X qui ouvre la PR. Sinon, les commentaires arrivent chez la mauvaise personne, les questions restent sans réponse et la PR s’enlise.