La code review, c'est le moment où un développeur relit le code écrit par un autre avant qu'il parte en production. Sur le papier, c'est simple. En pratique, c'est l'une des pratiques qui sépare le plus nettement les équipes qui livrent du code fiable de celles qui passent leur temps à éteindre des incendies. Bien menée, elle attrape les bugs tôt et fait monter toute l'équipe en compétence. Mal menée, elle devient un goulot d'étranglement qui frustre tout le monde.
La code review, c'est quoi ?
C'est une relecture du code par une ou plusieurs personnes qui ne l'ont pas écrit. Concrètement, un développeur propose ses modifications (le plus souvent via une pull request), un collègue les lit, pose des questions, signale des problèmes, suggère des améliorations. Une fois les remarques traitées, le code est validé et intégré.
Ce qu'on regarde vraiment
Une revue ne se résume pas à chasser les fautes de frappe. On vérifie plusieurs choses en parallèle : le code fait-il ce qu'il est censé faire, gère-t-il les cas limites, reste-t-il lisible pour celui qui le reprendra dans six mois, respecte-t-il les conventions du projet, introduit-il un risque de sécurité ou de performance. La partie « est-ce que ça compile et c'est bien indenté » doit être déléguée aux outils. Le cerveau humain sert à juger ce qu'une machine ne sait pas évaluer : la pertinence d'une approche.
Prenons un cas concret. Le code suivant compile, passe le linter, et contient pourtant un défaut qu'un relecteur repère en quelques secondes :
function moyennePanier(commandes) {
const total = commandes.reduce((somme, c) => somme + c.montant, 0);
return total / commandes.length;
}Le jour où commandes est un tableau vide, la fonction renvoie NaN et casse l'affichage en aval. Aucun outil ne le signalera : c'est exactement le genre de cas qu'une revue attrape. Le commentaire associé ressemblerait à ça :
issue (bloquant) —
commandes.lengthpeut valoir0ici, ce qui produit une division par zéro. Ajouter un garde en début de fonction et renvoyer0pour un panier vide.
Ce que la code review n'est pas
Ce n'est pas un contrôle de tests. Une revue ne remplace pas les tests unitaires : un relecteur ne va pas exécuter tous les scénarios à la main. Les deux sont complémentaires. Ce n'est pas non plus un tribunal. L'objectif n'est pas de juger la valeur du développeur, mais d'améliorer une portion de code précise, à un instant donné.
Pourquoi prendre le temps de faire des revues
Ralentir pour aller plus vite, c'est tout le paradoxe. Voici ce qu'on y gagne concrètement.
Attraper les problèmes au plus tôt
Un bug repéré en revue coûte quelques minutes à corriger. Le même bug découvert en production peut coûter une journée, sans compter l'impact sur les utilisateurs. Plus on détecte un défaut tôt dans le cycle, moins il est cher à réparer. La revue est le dernier filet avant que le code ne touche le réel.
Diffuser la connaissance dans l'équipe
Quand un seul développeur connaît une partie du code, son absence devient un risque. La revue force à expliquer ses choix et permet aux autres de découvrir des zones qu'ils ne touchent jamais. C'est aussi le meilleur moyen pour un junior d'apprendre les réflexes d'un senior, et inversement pour un senior de repérer une simplification évidente qu'un regard neuf a vue.
Maintenir une cohérence sur la durée
Sans revue, chaque développeur applique ses propres habitudes. Au bout de quelques mois, la base de code ressemble à un patchwork où chaque fichier a son style. Cette incohérence est l'une des sources les plus discrètes de dette technique. La revue maintient une ligne commune, projet après projet.
Une base de code dont vous n'êtes pas sûr ?
Les différentes formes de revue
Il n'y a pas une seule façon de relire du code. Le format se choisit selon le contexte.
La pull request
C'est le standard aujourd'hui. Le développeur ouvre une pull request sur GitHub, GitLab ou équivalent, les relecteurs commentent ligne par ligne, et la discussion reste tracée. L'avantage : c'est asynchrone, chacun relit quand il a le temps, et l'historique des échanges est conservé. Le risque : des PR trop grosses que personne n'ose vraiment relire.
La revue en binôme
Deux développeurs devant le même écran, l'un écrit, l'autre commente en direct. Le pair programming est en quelque sorte une revue continue. Plus coûteux en temps immédiat, mais redoutable sur les parties complexes ou critiques, où l'on veut éviter toute erreur.
La relecture rapide
Pour une correction d'une ligne, inutile de déclencher un processus lourd. Un coup d'œil par-dessus l'épaule ou une validation expresse suffit. Adapter la profondeur de la revue à l'ampleur du changement évite d'épuiser l'équipe sur des broutilles.
Une code review efficace, en pratique
C'est là que la plupart des équipes se trompent. Quelques règles font toute la différence entre une revue qui fluidifie et une qui paralyse.
Garder des revues petites
Au-delà de 400 lignes, la capacité à détecter des défauts s'effondre : on lit en diagonale. Mieux vaut découper une grosse fonctionnalité en plusieurs PR courtes que demander à un collègue d'avaler 2 000 lignes d'un coup. Une revue de moins de 200 lignes, traitée en moins d'une heure, est largement plus efficace.
Critiquer le code, pas la personne
« Cette fonction fait trop de choses » passe mieux que « tu as mal découpé ». La nuance paraît anodine, elle change tout sur la durée. On commente le code, jamais celui qui l'a écrit. Et quand on bloque une modification, on explique pourquoi : un relecteur qui se contente d'un « non » sans justification fait perdre du temps à tout le monde.
Automatiser ce qui peut l'être
Le formatage, le respect des conventions, la détection des erreurs évidentes : tout ça doit tourner automatiquement avant même que la revue commence. Un linter, un formateur et une mesure de la couverture de tests branchés sur la CI déchargent le relecteur de l'ennuyeux pour qu'il se concentre sur le fond. C'est aussi ce qui évite les débats stériles sur les espaces et les points-virgules.
Distinguer l'essentiel du détail
Tout commentaire n'a pas le même poids. Une faille de sécurité doit bloquer la fusion ; une préférence de nommage est une simple suggestion. Signaler clairement ce qui est bloquant et ce qui ne l'est pas — certaines équipes utilisent une convention de préfixes type Conventional Comments — évite qu'une remarque mineure ne fasse traîner une PR pendant des jours. En pratique, ça donne ceci :
praise: bien vu d'extraire ce helper, le reste devient beaucoup plus lisible.
issue (blocking): cette requête concatène l'input utilisateur → risque d'injection SQL.
suggestion (non-blocking): renommer `tmp` en `pendingOrders` serait plus parlant.
question: pourquoi un timeout de 30 s ici plutôt que la valeur par défaut ?Le préfixe dit tout de suite au développeur ce qui doit être corrigé avant la fusion et ce qui relève du confort. Un issue (blocking) se traite, un suggestion (non-blocking) se discute.
Les pièges à éviter
La revue fantôme, d'abord : approuver sans lire, juste pour débloquer un collègue. C'est pire que pas de revue du tout, parce que ça donne une fausse sécurité. À l'opposé, le perfectionnisme : exiger un code parfait avant chaque fusion bloque la livraison et démoralise. Le « assez bon » l'emporte sur le « parfait jamais livré ».
Autre travers fréquent : la revue tardive. Une PR qui attend trois jours, c'est un développeur qui repart sur un contexte oublié et une branche qui diverge. Traiter les revues dans la journée fait partie de l'hygiène d'une équipe. Enfin, méfiez-vous des goulots d'étranglement : si une seule personne valide tout, elle devient un point de blocage et un risque dès qu'elle s'absente.
Conclusion
La code review n'est ni un luxe ni une formalité. C'est un investissement qui se rentabilise à chaque bug évité et à chaque développeur qui monte en compétence. La clé tient en peu de choses : des revues courtes, bienveillantes, automatisées sur la partie mécanique, et traitées vite. Si vous reprenez une base de code dont la qualité vous inquiète, c'est souvent par là qu'il faut commencer — et parfois par un audit du code existant avant même de poser un processus. Une équipe qui relit sérieusement son code livre plus sereinement, sur la durée.
