Chapitre 5.2
La revue de code

Quand un développeur termine son travail sur une fonctionnalité, il ouvre une pull request sur Github. Avant que ce code soit intégré dans le projet, il passe généralement par une étape de relecture par un ou plusieurs collègues. C'est ce qu'on appelle la revue de code (code review).

Sur le papier, c'est une pratique vertueuse. En pratique, c'est un sujet qui divise beaucoup les équipes de développement.

Le principe

L'auteur du code ouvre une pull request. La plateforme (GitHub, GitLab) affiche les différences entre l'ancienne version et la nouvelle : fichier par fichier, ligne par ligne. Les ajouts en vert, les suppressions en rouge.

Un ou plusieurs collègues relisent ces modifications. Ils peuvent commenter n'importe quelle ligne, poser des questions, signaler un problème ou suggérer une approche différente. L'auteur répond, ajuste son code, et repousse ses modifications. La pull request se met à jour automatiquement. Quand tout le monde est satisfait, la pull request est approuvée et fusionnée.

Dans beaucoup d'équipes, la fusion est bloquée tant qu'au moins une personne n'a pas explicitement approuvé le code. C'est un verrou : rien ne passe sans un regard extérieur.

Les arguments pour

La revue de code est considérée comme une bonne pratique dans la majorité de l'industrie. Voici les arguments qu'on entend le plus souvent en sa faveur.

Détecter des erreurs

Un regard neuf peut voir des problèmes que l'auteur ne voit plus après des heures de travail. Un oubli de cas limite, une variable mal nommée, une logique inversée ou un problème de conception... Le relecteur n'a pas la tête dans le guidon et voit le code avec du recul.

Partager les connaissances

En relisant le code des collègues, les développeurs apprennent de nouvelles techniques, découvrent des parties du projet qu'ils ne connaissaient pas, et construisent une vision commune de l'architecture.

C'est particulièrement utile dans les grandes équipes où chacun a tendance à se spécialiser sur son périmètre. Sans revue de code, il arrive qu'un seul développeur connaisse une partie critique du système. S'il part en vacances ou quitte l'entreprise, personne ne peut reprendre son travail efficacement. La revue de code réduit ce risque en exposant régulièrement tout le monde au code des autres.

Documenter les décisions

La pull request et ses commentaires forment un historique consultable. Six mois plus tard, quand quelqu'un se demande "pourquoi ce code est écrit comme ça ?", il peut retrouver la discussion qui a mené à cette décision. Avec l'historique Git, c'est une documentation vivante, attachée directement au code concerné.

Maintenir une cohérence

Sans revue, chaque développeur code "à sa façon". Avec le temps, le projet devient un assemblage de styles différents, difficile à lire et à maintenir. La revue de code permet de s'assurer que le code suit les conventions de l'équipe et s'intègre harmonieusement dans l'existant.

Les arguments contre

Malgré sa popularité, la revue de code a ses détracteurs. Certaines équipes la considèrent comme une perte de temps nette.

Un goulot d'étranglement

En pratique, la revue de code ralentit le flux de travail. Le développeur a terminé son code, mais il ne peut pas le livrer : il attend qu'un collègue soit disponible pour le relire. Ce collègue est peut-être en réunion, concentré sur un autre sujet, ou débordé par ses propres tâches.

Résultat : le code stagne, parfois des jours. Pendant ce temps, d'autres modifications s'accumulent, les branches divergent, et les conflits de fusion deviennent plus complexes.

Les tests automatisés suffisent

Pour certaines équipes, les tests automatisés et la CI/CD remplissent déjà le rôle de filet de sécurité. Si le code compile, que tous les tests passent, que l'analyse de qualité est verte et qu'il n'y a pas de faille de sécurité détectée, pourquoi bloquer le code en attendant l'avis subjectif d'un humain ?

Un pipeline CI/CD bien configuré vérifie le code en quelques minutes, 24h/24, sans fatigue. Un relecteur humain, lui, peut passer à côté d'un bug tout en perdant du temps à débattre du nom d'une variable.

Le partage de connaissances peut se faire autrement

L'argument du partage de connaissances est souvent le plus mis en avant par les défenseurs de la revue de code. Mais ses détracteurs répondent que c'est un moyen peu efficace d'apprendre.

Relire du code hors contexte, sans avoir participé à la réflexion initiale, c'est comme lire la dernière page d'un roman : on voit le résultat, mais on ne comprend pas toujours le raisonnement derrière.

Des alternatives existent : le pair programming (deux développeurs qui codent ensemble en temps réel), les sessions de "mob programming" (toute l'équipe sur un seul écran), les présentations techniques internes, ou simplement des réunions régulières où chacun explique ce qu'il a construit et pourquoi. Ces formats permettent de poser des questions en direct, de comprendre le contexte, et d'apprendre plus efficacement qu'en lisant des différences de code ligne par ligne.

Les dérives culturelles

Mal organisée, la revue de code peut devenir toxique. Certains relecteurs transforment chaque pull request en tribunal. Ils chipotent sur des détails cosmétiques, imposent leurs préférences personnelles, ou bloquent du code pour des raisons qui relèvent plus de l'ego que de la qualité.

Pour les développeurs juniors, l'expérience peut être particulièrement décourageante. Proposer son travail pour le voir systématiquement critiqué, même quand il fonctionne, n'est pas la meilleure façon de progresser sereinement.

Quand la revue de code devient un rapport de force plutôt qu'une collaboration, elle fait plus de mal que de bien.

En pratique

La plupart des entreprises pratiquent la revue de code. Mais la façon dont elles le font varie énormément.

• Les équipes strictes : chaque ligne de code est relue par au moins deux personnes. La fusion est impossible sans deux approbations. C'est fréquent dans les secteurs réglementés (banque, santé, aéronautique) où une erreur peut avoir des conséquences graves.
• Les équipes pragmatiques : une seule approbation suffit. Le relecteur vérifie la logique globale sans s'attarder sur le style (les outils automatiques s'en chargent). L'objectif est de garder un bon rythme de livraison.
• Les équipes sans revue formelle : elles s'appuient sur le pair programming, une couverture de tests élevée et un pipeline CI/CD solide. Quand le code est écrit à deux et que les tests sont verts, la revue par un tiers n'apporte pas assez de valeur pour justifier le ralentissement.

Il n'y a pas de réponse universelle. La bonne approche dépend de la taille de l'équipe, du domaine d'activité, de la maturité des tests automatisés et de la culture de l'entreprise. Ce qui compte, c'est que le processus choisi serve réellement la qualité du produit sans devenir une formalité vide de sens.

Les bonnes pratiques

Pour les équipes qui choisissent de faire de la revue de code, voici ce qui distingue les revues efficaces des revues pénibles :

• Des pull requests courtes : une pull request de 50 lignes se relit en 10 minutes. Une pull request de 2000 lignes ne sera jamais relue correctement. Le relecteur finira par approuver en diagonale, ce qui annule tout l'intérêt.
• Commenter le code, pas la personne : "cette condition pourrait être simplifiée" plutôt que "tu n'as pas compris comment faire". Le ton fait toute la différence.
• Automatiser ce qui peut l'être : le style de code, le formatage, les conventions de nommage... tout ça peut être vérifié par des outils. Le relecteur humain doit se concentrer sur ce que les machines ne savent pas faire : la logique métier, l'architecture, les cas limites.
• Répondre vite : une revue de code qui traîne pendant trois jours est pire qu'une absence de revue. Si l'équipe s'engage dans ce processus, elle doit s'engager aussi à le faire dans un délai raisonnable.