Le processus d'examen de code dégénère dans la plupart des équipes en chaos ou en échange purement émotionnel. Un commentaire « ce code est mauvais » devient une critique personnelle, un bouton « approved » reste juste un point de contrôle. Chez Roibase, en 8 ans d'intégrations headless commerce, migrations CDN et mises en place de pipelines de données, nous avons constaté une réalité : sans critères mesurables, la culture d'examen ne se construit pas. Sans fixer des seuils numériques pour time-to-review, comment density et PR size, la review n'est pas une culture, c'est une compétition de politesse.
Time-to-Review : Premier retour dans les 4 heures
La vitesse d'examen affecte directement le momentum de l'équipe. Si plus de 4 heures s'écoulent entre l'ouverture d'une PR et le premier commentaire, les coûts de context switch s'accumulent chez l'auteur. Sans notification « reviewed » sur Slack, l'auteur passe à la tâche suivante. Le lendemain, au retour, il faut 15 minutes de mise en contexte pour se souvenir des changements.
Chez Roibase, nous extraits la métrique time-to-review de l'API GitHub et la reflètons dans Linear sous forme de tableau. Si le temps médian de review dépasse 4 heures à la fin du sprint, nous réorganisons la rotation d'assignation des reviewers au sprint suivant. Ainsi, personne ne se retrouve bloqué, chacun a un créneau d'examen dans son calendrier.
La deuxième métrique : le temps de fusion — l'intervalle entre l'ouverture et la fusion dans main. Une PR pour une fonctionnalité e-commerce ne doit pas attendre plus de 48 heures, sinon elle interfère avec le plan A/B testing. Au-delà de 48 heures, il y a scope creep (le reviewer a demandé des modifications). Il est plus sain d'ouvrir une story supplémentaire et de fermer la PR actuelle.
Système d'alerte : notification Slack après 24 heures
Via un webhook Linear, si une PR reste ouverte 24 heures, un ping automatique va au reviewer. Cette simple automatisation extrait la discipline d'examen du théorique à l'opérationnel. Le bot Slack rappelle poliment : « PR #342 ouverte depuis 28 heures — scope trop large ou créneau de review manquant ? » Cette question ouvre naturellement la conversation.
Comment Density : 2-5 commentaires par 100 lignes
Un reviewer qui commente trop contrôle chaque détail mais bloque l'auteur. Un reviewer qui commente trop peu fait juste un coup d'œil. Un examen équilibré laisse 2-5 commentaires par 100 lignes modifiées.
Chez Roibase, nous suivons le comment density pour chaque reviewer sur le dashboard PR. Au-delà de 10 commentaires/100 lignes, le reviewer ne comprend peut-être pas le scope et impose des changements arbitraires. Moins d'1 commentaire/100 lignes, c'est un rubber stamp.
Pour maîtriser le comment density, notre template PR contient une checklist. « La logique est-elle rétrocompatible ? », « La couverture de tests a-t-elle diminué ? », « Une variable d'environnement a-t-elle été ajoutée ? » — 7 points. Le reviewer ne peut approuver sans parcourir cette checklist. Les commentaires cessent d'être des réactions émotionnelles aléatoires pour devenir des points de contrôle systématiques.
## Checklist du Reviewer
- [ ] Les changements de logique sont-ils rétrocompatibles ?
- [ ] Y a-t-il une nouvelle variable d'environnement ? .env.example à jour ?
- [ ] Migration de base de données avec script de rollback ?
- [ ] Couverture de tests en dessous de 80 % ?
- [ ] Taille du bundle augmentée de plus de 5 KB ? (frontend)
- [ ] Changement d'API non compatible ? Changelog mis à jour ?
- [ ] Nouvelle dépendance externe ? Licence compatible ?
Ce template transforme « ce code est mauvais » en « script de rollback migration manquant » — un commentaire actionnable.
Règle PR Size : +300 / -100 lignes → diviser
Une grosse PR ne peut pas être examinée. Vue 600 lignes modifiées dans GitHub diff, le reviewer jette un coup d'œil, dit « LGTM », passe. Chez Roibase, la limite de taille PR : +300 lignes ajoutées, -100 lignes supprimées. Une PR au-delà laisse un commentaire automatique du bot CI : « Cette PR est voluminense — fusionnez par incrément avec feature flag ou divisez en deux stories. »
Pour diviser les changements volumineux, nous utilisons des feature flags. Par exemple, un nouveau flux de checkout avec 450 lignes en 8 fichiers : la première PR couvre juste la couche API (100 lignes), la deuxième le composant UI (120 lignes), la troisième l'intégration (150 lignes). Chaque PR fusible indépendamment, le flag reste fermé en production. Quand la dernière PR ouvre le flag, le flux s'active.
| Type de PR | Lignes modifiées | Temps d'examen (médian) | Bug après fusion |
|---|---|---|---|
| Micro (<150 lignes) | +120 / -30 | 1,8 h | 2% |
| Normal (<300 lignes) | +280 / -90 | 3,5 h | 5% |
| Volumineux (>300 lignes) | +450 / -200 | 12 h | 18% |
Sur grosse PR, le taux de bug est 3x plus élevé car le reviewer ne voit pas les détails. Divisées, chaque partie est moins risquée, le rollback post-fusion devient rare.
Feedback sans conflit : commentez le code, pas la personne
Au lieu de « cette approche est mauvaise », dire « cette fonction génère N+1 queries — ajoute eager loading » n'est pas personnel, c'est technique. Chez Roibase, les commentaires d'examen bannissent : « mauvais », « stupide », « laid », « c'est quoi ça ». Modèle préféré : « Comment ce changement affecte-t-il la métrique X ? Peut-il causer le problème Z dans le scénario Y ? »
Pour contrôler le ton, nous utilisons un bot GitHub Actions. Chaque commentaire contenant « mauvais », « pourri », « nul » reçoit un message automatique au reviewer : « Ce commentaire n'est pas constructif — décrivez le problème spécifique ou proposez une alternative. » Ce n'est pas de la politesse imposée, c'est de la discipline d'ingénierie.
Une autre tactique : ouvrir une issue de suivi après approbation. Si un improvement mineur est détecté, plutôt que de bloquer la PR actuelle, nous ouvrons « Post-fusion : refactoriser la logique d'invalidation de cache » et la lien. La PR fusionne vite, l'improvement entre dans le backlog.
Review en binôme : deux reviewers, deux perspectives
Sur les PR critiques (intégration de paiement, auth utilisateur, migration de données), deux reviewers obligatoires. Le premier examine la logique, le second sécurité + performance. Cette division évite la redondance. Le temps d'examen ne double pas, la qualité double.
Review asynchrone : pas de réunion synchrone, fil asynchrone
Pas de réunion d'examen de code. Le fil PR suffit. Le reviewer poste un commentaire, l'auteur répond dans 4 heures, fait un commit si besoin. Une réunion où on demande « pourquoi c'est comme ça ? » prend 5 minutes de discussion. En asynchrone, la même question s'échange en 2 phrases + snippet de code.
Pour ancrer la discipline asynchrone, nous avons intégré Slack. Une PR reçoit un commentaire → l'auteur reçoit une notification Slack, pas une invitation à réunion. L'auteur revient au fil à son point de context switch (quand la tâche actuelle finit). Cette méthode est cruciale pour les équipes distribuées (+3 fuseaux horaires). Dans le triangle Istanbul-Berlin-San Francisco de Roibase, l'examen synchrone est impossible. Un fil asynchrone : Berlin poste un commentaire 9h, Istanbul répond l'après-midi, San Francisco fusionne le soir.
Mesurer l'examen de code élimine le langage personnel « ton code est mauvais » dans l'équipe. Les métriques time-to-review, comment density et PR size créent un terrain neutre. Quand la qualité d'examen est clairement définie, tout le monde maintient le même standard. Dans nos travaux de stratégie de contenu géolocalisée, nous ciblons aussi la production d'équipe cohérente avec des critères mesurables — la culture d'examen de code est l'aspect technique du même discipline. Sans règles, l'examen n'est pas une culture, c'est de la politesse aléatoire. Avec règles, l'examen accélère, la qualité augmente, les conflits disparaissent.