Code review (revue de code)

La code review (ou revue de code) est la relecture du code écrit par un développeur par un ou plusieurs de ses collègues, avant que ce code ne rejoigne la version principale du projet. Le relecteur cherche les bugs, les failles de sécurité, les choix d’architecture discutables et les tests manquants, pendant qu’il est encore facile et peu coûteux de corriger. Une erreur repérée à ce stade coûte quelques minutes. La même erreur découverte en production coûte un incident, un correctif en urgence et parfois la confiance d’un client.

Dans les équipes qui la pratiquent systématiquement, aucune ligne de code n’est intégrée sans avoir été lue et approuvée par au moins une autre personne. La règle est contraignante. C’est aussi, avec les tests automatisés, la pratique qui pèse le plus sur la qualité d’un logiciel dans la durée, et l’un des premiers points à vérifier quand on reprend un projet existant.

Comment fonctionne une code review

Le développeur travaille sur une branche séparée du projet, gérée avec Git, pour une fonctionnalité ou une correction. Quand il estime son travail prêt, il ouvre une pull request (PR), appelée merge request sur GitLab : une demande formelle d’intégrer ses modifications dans la base de code commune. Ce mode de travail vient des projets open source, où des inconnus devaient pouvoir proposer du code sans casser le projet, et GitHub l’a popularisé à partir de 2008.

Un ou plusieurs collègues lisent alors les changements, ligne par ligne, et laissent des commentaires directement sur le code : « pourquoi cette approche plutôt que celle-là ? », « cette fonction pourrait être simplifiée », « il manque un test pour ce cas limite ». L’auteur répond, ajuste, et le va-et-vient continue jusqu’à ce que le relecteur approuve. Le code est alors fusionné (mergé) dans la branche principale.

Une bonne revue porte sur le fond : la logique, la sécurité, la lisibilité, la cohérence avec le reste du projet. La forme (indentation, ordre des imports, conventions de nommage) est vérifiée par des outils automatiques appelés linters et formateurs. Le temps du relecteur humain va à ce que la machine ne sait pas juger.

Ce que la code review détecte

Les bugs logiques d’abord : une condition inversée, un cas limite oublié, un calcul faux. L’auteur, plongé dans son code depuis des heures, ne les voit plus. Un regard extérieur les repère souvent en quelques secondes.

Les failles de sécurité ensuite. Une vérification d’autorisation absente, une donnée sensible écrite dans les logs, une entrée utilisateur non filtrée qui ouvre la porte à une injection SQL. Ces défauts passent les tests fonctionnels sans encombre, puisque l’application « marche », et ne se révèlent qu’au moment d’une attaque.

Les problèmes de conception sont plus discrets. Un module qui fait trop de choses, une logique dupliquée à trois endroits, une dépendance placée au mauvais niveau : ce sont les premiers signes de dette technique, et la revue est le dernier moment où on peut les refuser à bas coût. Notre guide sur la dette technique détaille ce que coûtent ces raccourcis quand ils s’accumulent.

Les tests manquants enfin. Le relecteur vérifie que les cas importants et les scénarios d’erreur sont couverts. Un code sans test est un code dont personne ne pourra garantir le comportement lors de la prochaine modification.

Ce que la code review apporte au-delà des bugs

La réduction des bugs est le bénéfice le plus visible. Ce n’est probablement pas le plus important.

La connaissance circule. Quand chacun lit le code des autres, personne n’est le seul à comprendre un module critique. Si un développeur part en vacances ou quitte l’entreprise, ses collègues reprennent son travail sans période de flottement. On parle de « bus factor » : le nombre de personnes dont le départ mettrait le projet en danger. La revue le fait monter.

Les développeurs progressent. Un junior dont le code est relu par un senior apprend plus vite qu’avec n’importe quelle formation. L’inverse vaut aussi : le senior qui relit un junior reste au contact du projet et découvre parfois une approche qu’il n’avait pas envisagée.

Les décisions restent traçables. L’historique des pull requests et de leurs commentaires explique pourquoi le code a été écrit ainsi. Deux ans plus tard, quand quelqu’un se demande la raison d’un choix étrange, la PR d’origine donne la réponse. C’est une documentation que personne n’a eu à rédiger.

Les bonnes pratiques d’une code review efficace

Des changements courts. Une étude de SmartBear menée chez Cisco sur 2 500 revues, encore citée aujourd’hui, a montré que la détection des défauts chute au-delà de 400 lignes et d’une heure de lecture. Une PR de 200 lignes se relit avec attention en vingt minutes. Une PR de 1 500 lignes sera survolée. Quand un changement est gros, on le découpe en plusieurs PR successives.

Une description qui explique le pourquoi. Quel problème la PR résout-elle, quelle approche a été retenue, où le relecteur doit-il porter son attention ? Une bonne description divise les allers-retours.

Un premier retour sous 24 heures. Une PR qui attend trois jours bloque son auteur et finit par entrer en conflit avec le travail des autres. Le rapport DORA 2023 de Google relie d’ailleurs la rapidité des revues à une performance de livraison logicielle supérieure de 50 %. La revue fait partie du travail quotidien, pas de ce qu’on fait « quand on a le temps ».

Une checklist partagée. Sécurité, tests, performance, accessibilité, cohérence avec l’architecture existante : une liste courte de points à vérifier évite les oublis et rend les revues comparables d’un relecteur à l’autre.

On relit le code, pas la personne. « Cette logique pourrait être extraite dans une fonction dédiée, qu’en penses-tu ? » fait avancer. « Pourquoi tu as fait ça ? » met sur la défensive. Certaines équipes préfixent leurs commentaires (nitpick, suggestion, question, bloquant) pour distinguer d’un coup d’œil le détail du problème réel. Côté auteur, le code soumis n’est pas « son » code mais une proposition faite au projet commun, et les remarques sont une aide.

Les erreurs courantes en code review

Le goulot d’étranglement. Si une seule personne peut approuver les PR, tout s’arrête dès qu’elle est absente. Il faut plusieurs relecteurs possibles, former les juniors à cette responsabilité, et surveiller la file d’attente des PR comme on surveille le travail en cours dans une équipe Kanban.

La revue cosmétique. Passer vingt minutes sur le nom d’une variable ou une indentation, c’est du temps humain dépensé sur ce qu’un outil fait mieux, pendant qu’un bug de logique passe.

L’approbation de façade. Un « approuvé » posé en deux minutes sur 300 lignes n’a aucune valeur et crée un faux sentiment de sécurité. Mieux vaut dire honnêtement qu’on n’a pas eu le temps de lire.

L’exigence uniforme. Un correctif urgent en production et une refonte de l’architecture ne demandent pas la même profondeur de revue. Les équipes efficaces modulent selon le risque et l’impact du changement.

Code review et CI/CD

La revue humaine s’insère dans un pipeline de CI/CD. Dès qu’une PR est ouverte, les tests automatisés tournent, l’analyse statique vérifie la qualité du code, et des scanners cherchent les vulnérabilités connues dans les dépendances. Si l’un de ces contrôles échoue, la PR est marquée en erreur et le relecteur ne perd pas son temps sur un code qui ne fonctionne pas. Si tout passe, il sait que la base est saine et concentre son attention sur ce que les tests ne couvrent pas.

Les plateformes permettent aussi de rendre la revue obligatoire par configuration : la branche principale est protégée, et rien n’y entre sans une approbation et des tests verts. C’est ce réglage, plus qu’une consigne orale, qui garantit que la pratique tient dans le temps.

Code review à l’ère du code généré par IA

Les assistants de programmation ont changé l’équilibre. Quand un développeur, ou un agent, produit deux fois plus de code en deux fois moins de temps, la charge ne disparaît pas : elle se déplace vers la relecture. La revue est devenue le goulot d’étranglement de beaucoup d’équipes, et le risque principal du code généré n’est pas le bug grossier mais le code plausible, bien formaté, qui ressemble à du bon code et passe une revue distraite. Notre article sur l’impact de l’IA sur la productivité des développeurs chiffre ce déplacement.

Deux règles en découlent. La première : le développeur qui soumet du code généré en reste l’auteur responsable et doit pouvoir l’expliquer ligne par ligne, ce que le vibe coding fait facilement oublier. La seconde : l’IA relit aussi. GitHub Copilot, CodeRabbit ou Claude Code commentent une PR en quelques minutes et attrapent bien les oublis, les vulnérabilités connues et les motifs à problème. Ils servent de premier filtre. Le jugement sur un compromis technique, sur la cohérence avec le métier ou sur ce qu’il vaut mieux ne pas construire reste humain.

Ce qu’un dirigeant non technique doit vérifier

Vous n’avez pas besoin de lire le code pour savoir si votre équipe ou votre prestataire pratique la revue. Trois questions suffisent. La branche principale est-elle protégée, avec une approbation obligatoire ? Quel est le délai moyen entre l’ouverture d’une PR et son premier commentaire ? Qui relit le code du développeur le plus senior, y compris celui du CTO ? Si la réponse à la dernière question est « personne », la pratique n’est pas réellement en place. L’historique des pull requests, consultable sur GitHub ou GitLab, permet de vérifier les réponses en dix minutes.

FAQ code review

Combien de temps prend une code review ?

Entre dix minutes et une heure pour une PR bien dimensionnée. Ce temps est presque toujours inférieur à celui des bugs qu’elle évite, d’autant qu’un défaut corrigé en revue n’implique ni incident, ni retour arrière, ni support client.

Quelle différence entre code review et pair programming ?

Le pair programming réunit deux développeurs sur le même code en temps réel. La revue intervient après, de manière asynchrone. Certaines équipes considèrent qu’un code écrit en binôme a déjà été relu et allègent la revue formelle.

Faut-il une code review quand on est seul développeur ?

Oui, dans une version adaptée. Un développeur solo peut relire sa propre PR le lendemain avec un regard neuf, s’appuyer sur un outil de revue par IA et faire relire ponctuellement les parties sensibles (paiement, authentification) par un pair extérieur. Ce que la revue apporte, c’est un second regard. Il faut le fabriquer autrement.

Comment Polara Studio pratique la code review

Chez Polara Studio, la code review est obligatoire : aucun code ne rejoint la branche principale sans au moins une approbation d’un pair, quel que soit le niveau d’expérience de l’auteur, et nous nous fixons un délai maximum de 24 heures pour un premier retour sur chaque pull request.

La revue porte sur la logique métier, la sécurité, la couverture de tests et la cohérence avec l’architecture. Le formatage et le style sont réglés par les outils de notre chaîne d’intégration. Chaque remarque vient avec son « pourquoi », parce qu’une revue sert autant à former qu’à contrôler. Quand une PR révèle une zone de code fragile, nous préférons planifier un refactoring plutôt que d’empiler des corrections locales.