Revue de code : pourquoi le propriétaire d'un site ou d'une application en a besoin

Vous gérez un site, une boutique en ligne ou une petite application. Quelqu'un a écrit le code : un prestataire, un ami, une agence passée à autre chose depuis, ou vous-même après quelques week-ends de tutoriels. Ça marche, en gros. Mais vous ne savez pas si c'est solide ou tenu avec du scotch. Une revue de code, c'est un second regard par quelqu'un qui ne l'a pas écrit, et elle répond à cette question avant qu'un petit problème ne devienne coûteux.

Quand une revue en vaut la peine

• Avant de payer un travail terminé. Une revue montre si le code reçu est correct ou plein de raccourcis.
• Quand vous reprenez un projet. Un code hérité sans documentation reste une boîte noire tant que personne ne l'explique.
• Quand quelque chose casse sans cesse. Un formulaire qui échoue parfois, une page lente, une erreur qui revient après chaque correction.
• Avant un lancement ou une grosse promotion, quand un bug coûte de l'argent réel.
• Quand vous codez vous-même et voulez apprendre à mieux faire.

Ce que détecte une revue

Le relecteur lit le code ligne par ligne et cherche :

• Les bugs : une logique qui échoue dans certains cas, comme un panier vide, une date en fin de mois ou un nom avec une apostrophe.
• Les points à risque : des mots de passe écrits dans le code, des saisies utilisateur utilisées sans contrôle, des messages d'erreur trop bavards.
• Les points faibles : du code qui marche aujourd'hui mais cassera quand le trafic augmentera ou qu'une bibliothèque sera mise à jour.
• La lisibilité : des noms peu clairs, des fonctions trop longues et du code répété qui rendent chaque modification future plus lente et plus chère.

Les problèmes sont classés par importance : vous savez quoi corriger d'abord et ce qui peut attendre.

Ce qu'une revue ne fait pas

Une revue lit et explique le code ; elle ne l'exécute pas sur votre serveur et ne teste pas votre site en ligne. Ce n'est ni un audit de sécurité complet ni un test de charge. Considérez les corrections suggérées comme des propositions : la personne qui maintient le projet doit tester chacune avant sa mise en ligne.

Comment choisir ce qu'il faut envoyer

Il est rarement utile d'envoyer tout le site. Choisissez les parties qui comptent le plus :

• Là où circule l'argent : commande, paiements, prix et remises.
• Là où les utilisateurs saisissent quelque chose : formulaires d'inscription, de connexion, de contact et de recherche.
• Là où se trouve le problème : le fichier ou la fonction derrière l'erreur que vous voyez.

Quelques centaines de lignes bien choisies en disent plus que des milliers de lignes prises au hasard.

Comment préparer le code

• Retirez les secrets. Remplacez les mots de passe, clés API et données clients par des repères comme PASSWORD_HERE.
• Indiquez le langage et la version, par exemple PHP 8 ou JavaScript avec React.
• Décrivez ce que le code doit faire en une ou deux phrases simples.
• Copiez le message d'erreur exact, s'il y en a un, en entier.
• Dites sur quoi se concentrer : le bug, la vitesse, la lisibilité ou les points à risque.

Comment utiliser le résultat

Transmettez la revue à la personne qui maintient le code et convenez de l'ordre des corrections, en commençant par les plus critiques. Si vous n'êtes pas technicien, le résumé en termes simples vous aide à poser les bonnes questions et à juger les réponses.

En bref

Une revue de code est un regard indépendant qui trouve les bugs, les points à risque et les points faibles avant vos clients. Si vous en voulez une, commandez une revue de code : vous collez 100, 400 ou 1 000 lignes maximum et décrivez ce qui ne va pas, et vous recevez une explication écrite de ce que fait le code, une liste des problèmes classés par importance et des fragments corrigés à tester dans votre propre projet. Le paiement n'est versé qu'une fois que vous avez validé le travail.