Corriger un code défectueux livré par un freelance

Comment corriger un code défectueux livré par un freelance

Un code cassé, c’est agaçant, et c’est exactement le genre de situation qui fait se demander comment gérer un bug après livraison par un freelance. C’est aussi coûteux, car chaque heure passée à deviner est une heure de moins consacrée à livrer. Si un freelance remet un build qui échoue au chargement, casse le paiement, ou passe les tests en local mais plante en staging, la bonne réaction n’est pas la panique. C’est de reprendre le contrôle. Le premier geste est simple : empêcher les dégâts de s’étendre, puis recueillir des faits avant que quelqu’un ne commence à débattre des responsabilités.

1. Geler la version endommagée et conserver les preuves

Suspendez les déploiements. Si le code défectueux est déjà en ligne, figez la version actuelle, notez le commit exact ou le tag de version, et stoppez tout pipeline automatique susceptible d’écraser les preuves. Un redéploiement imprudent peut effacer l’erreur même que vous devez examiner.

Conservez l’état en échec. Faites des captures d’écran, copiez la sortie de la console, exportez les journaux, et gardez un instantané de la base de données si le problème touche aux données. L’horodatage compte ici. Le nom de l’environnement aussi. Si le bug n’apparaît qu’en staging à 14:20 après l’exécution d’un script de seed, ce détail n’est pas décoratif : c’est la différence entre une correction en 10 minutes et une recherche à l’aveugle.

Ne “nettoyez” pas le système avant. Cette tentation détruit les preuves. Un développeur peut corriger beaucoup plus vite un module cassé si la pile d’erreurs, la réponse du serveur et le dernier build valide sont encore intacts. Si vous utilisez un système de tickets, joignez les journaux immédiatement et étiquetez le problème avec le numéro de release. La même règle apparaît dans les règles de placement et d’affichage : gardez des traces claires, car la confusion coûte du temps.

2. Trier l’échec selon son ampleur, son risque et son impact métier

Tous les échecs ne se valent pas. Une faute de frappe dans un lien de pied de page est un défaut. Un tunnel de paiement qui fait tomber les commandes est un blocage. Un filtre de tableau de bord cassé qui touche une équipe mais pas les clients peut se situer entre les deux. Votre rôle est de classer les dégâts par portée avant que le freelance ne se mette à corriger des éléments au hasard.

Posez trois questions. Quelle fonctionnalité est bloquée ? La production est-elle affectée ? Les utilisateurs peuvent-ils encore accomplir la tâche principale ? Si la réponse à la dernière question est “non”, traitez cela comme un blocage de mise en production. Si la fonctionnalité marche mais qu’un cas limite échoue, il peut s’agir d’une régression partielle. Si le problème n’apparaît que dans un rapport non critique, cela peut souvent attendre. Cette classification détermine la vitesse de réaction nécessaire, et si le freelance doit tout laisser tomber.

L’impact métier n’est pas une impression vague. Il doit être relié à quelque chose de concret : commandes perdues, inscription cassée, données corrompues, ou file d’attente du support qui a grossi de 30 tickets. Les chiffres aident. Le fait de nommer le groupe de clients concerné aussi. Un bug qui touche 2 administrateurs internes n’est pas équivalent à un bug qui bloque 200 acheteurs au moment de payer.

3. Distinguer les livrables réels des correctifs consécutifs

C’est là que beaucoup de projets se compliquent. Le freelance a peut-être livré une fonctionnalité, et le code cassé peut révéler un second problème qui n’était pas du tout dans le périmètre. Ce ne sont pas les mêmes choses. Le livrable initial est ce qui a été convenu dans le brief. Tout ce qui apparaît ensuite peut relever de correctifs ultérieurs, de maintenance ou d’une nouvelle tâche. Autrement dit, il faut d’abord corriger un code livré par un freelance en distinguant ce qui relève vraiment de sa prestation.

Relisez le périmètre d’origine ligne par ligne. Si le freelance a été engagé pour créer un formulaire de contact, alors une règle de validation défectueuse dans ce formulaire fait partie de la livraison. Si ce même formulaire a maintenant besoin d’un nouveau filtre anti-spam, c’est une demande distincte. Gardez cette distinction nette. Elle évite la dérive du périmètre et vous aide à attribuer les responsabilités sans transformer chaque défaut en débat.

Un test pratique consiste à se demander ceci : le problème existerait-il si la fonctionnalité avait été construite correctement dès le départ ? Si oui, il appartient probablement à la livraison. Si le problème n’est apparu que parce que votre équipe a modifié le CMS, l’API ou le thème après la remise, alors la correction peut relever des correctifs ultérieurs plutôt que du travail initial du freelance. Cette frontière compte, car une remise de projet propre en dépend. Si vous gérez souvent de l’aide externe, l’article sur la migration d’un projet d’un studio web vers un freelance est utile pour comprendre où se déplace la responsabilité.

4. Faire une revue de code rapide avant de demander des changements

Il n’est pas nécessaire d’être un ingénieur senior pour faire une revue de code utile. En revanche, il faut de la patience pour les détails. Commencez par l’évidence : le freelance a-t-il branché la mauvaise variable d’environnement, oublié une instruction return, ou connecté le mauvais point de terminaison ? Ce sont des erreurs du genre qui peuvent casser une fonctionnalité sans toucher tout le système.

Vérifiez ensuite les points d’intégration. Beaucoup de code cassé vient d’un décalage, pas d’une incompétence : le frontend attend du JSON, le backend renvoie du HTML ; le module de paiement attend une clé active, le dépôt contient une clé de test ; le nouveau composant suppose un champ nommé customer_id, mais la base stocke client_id. Un seul décalage peut provoquer un échec qui paraît bien plus large qu’il ne l’est.

Recherchez aussi les tests manquants. Si le freelance a ajouté de la logique sans fichier de test, le risque augmente. Si des tests existent mais échouent seulement dans un navigateur ou une version de serveur, cela vous dit quelque chose de précis sur la panne. Une revue de code rapide peut également révéler des problèmes d’architecture, comme une fonction qui fait trop de choses à un seul endroit. C’est un signal d’alerte, car un correctif simple peut masquer un défaut plus profond.

Prenez des notes pendant l’inspection. Indiquez chaque constat avec un numéro de ligne ou un chemin de fichier. Une bonne revue de code n’a pas besoin de drame. Elle a besoin de traçabilité. Si vous demandez ensuite une correction, vos notes rendront la discussion plus courte et la réparation moins chaotique.

5. Établir un plan de correction avec options de rollback, de patch ou de refonte

Décidez maintenant comment rétablir la situation. Il existe généralement quatre voies : corriger le défaut par un patch, revenir partiellement en arrière sur la zone cassée, annuler complètement la release, ou refondre le module. Chaque voie a un coût différent. Chacune a aussi un profil de risque distinct.

Un patch minimal est le bon choix lorsque le bug est étroit, isolé et bien compris. Si un seul opérateur de comparaison casse une règle de remise, corrigez-le. Un rollback partiel fonctionne lorsqu’une nouvelle fonctionnalité est stable et qu’une autre ne l’est pas, ce qui permet de conserver la partie saine tout en retirant la partie défectueuse. Le revert complet est plus sûr lorsque la release a touché aux paiements, aux connexions ou aux écritures de données et que le système est instable. La refonte est l’option lourde. Utilisez-la lorsque la structure est tellement dégradée qu’un patch ne ferait que rendre le code plus difficile à maintenir plus tard.

Choisissez selon les conséquences, pas selon l’ego. Un patch précipité qui maintient la production en vie pendant une heure mais provoque trois autres pannes demain n’est pas une victoire. Un rollback plus propre peut sembler plus lent, mais il peut éviter à l’équipe support de passer les deux jours suivants à répondre à la même plainte. Si le freelance est disponible, demandez un plan avec une voie principale et une voie de secours. C’est une meilleure conversation que “corrige juste ça”.

6. Demander des corrections ciblées avec des étapes de reproduction précises

Envoyez une demande qu’un développeur peut exploiter sans deviner. Les meilleures demandes de correction de bugs contiennent cinq éléments : les étapes exactes pour reproduire, le comportement attendu, le comportement observé, l’environnement concerné et les critères d’acceptation. S’il en manque un, le freelance perdra du temps à poser des questions de suivi. C’est particulièrement vrai quand on se demande que faire si un freelance livre un code cassé : la réponse commence presque toujours par une demande claire et testable.

Rédigez les étapes de reproduction comme si la personne n’avait jamais vu le projet. Par exemple : “Ouvrir Chrome 128 sur le staging, se connecter en tant que manager, ouvrir la page de facture, cliquer sur Exporter, et la page renvoie une erreur 500.” C’est bien mieux que “l’export est cassé”. La première version peut être testée. La seconde déclenche une longue conversation.

Ajoutez les détails d’environnement qui comptent. Un bug peut n’apparaître que sur Safari mobile, sur PHP 8.2, ou après un rafraîchissement du cache. Si le projet possède plusieurs environnements, nommez celui où la panne s’est produite. Un seul mot comme “production” ne suffit pas si le bug n’est apparu que dans une région ou après une fenêtre de déploiement précise. La précision évite les allers-retours.

Exprimez les critères d’acceptation en langage simple. Par exemple : “Le bouton d’export doit générer le fichier CSV, la requête doit retourner 200, et aucune erreur console ne doit apparaître.” Cela donne un objectif au freelance et vous donne un moyen de vérifier le résultat sans ambiguïté. Si vous avez aussi besoin d’un point de référence sur la manière de gérer le placement et l’exposition dans les assets du projet, la page sur les règles de placement et d’affichage est pertinente.

7. Vérifier le code réparé avant de clôturer le problème

Ne fermez pas le ticket sur la seule confiance. Re-testez le chemin corrigé, puis testez les chemins voisins. Une correction pour un écran de paiement peut facilement casser l’écran de code promo si les deux partagent la même fonction utilitaire. C’est pourquoi la vérification doit comporter au moins deux niveaux : le cas cassé exact et un cas adjacent.

Relancez les étapes de reproduction initiales. Si le bug n’apparaît plus, vérifiez les régressions dans la même zone. Ouvrez la console du navigateur, relancez la requête API et confirmez que les journaux serveur sont propres. Si votre équipe a des tests, lancez-les. Si le freelance a ajouté de nouveaux tests avec la correction, examinez-les aussi. Une correction qui passe une fois mais échoue avec une seconde entrée n’est pas terminée.

Surveillez les effets de bord. Un patch qui corrige une erreur d’index peut modifier silencieusement l’ordre de tri. Un revert peut restaurer une fonctionnalité tout en en désactivant une autre. C’est pourquoi la vérification ne doit pas s’arrêter à “ça a l’air bon”. Elle doit inclure le suivi de la revue de code, une comparaison rapide avec le problème initial et un dernier passage sur le parcours utilisateur qui n’aurait pas dû changer.

Si la correction arrive en production, continuez la surveillance pendant au moins un cycle de release. Les 24 premières heures après une correction révèlent souvent si le changement a vraiment tenu. Un rapport de code cassé clôturé trop tôt revient souvent sous forme d’un second ticket.

8. Documenter la passation pour la maintenance future

Consignez ce qui a cassé, ce qui a changé et ce qui reste ouvert. Ce compte rendu n’a pas besoin d’être long, mais il doit contenir des noms, des dates et des références de fichiers. Un futur freelance doit pouvoir le lire et comprendre pourquoi une fonction a été patchée, pourquoi un rollback a été choisi, ou pourquoi un module a été laissé intact.

De bonnes notes de passation doivent inclure le tag de release, le lien vers le problème, les étapes de reproduction, la voie de correction retenue et les résultats des tests. Si le freelance a mis en place un contournement au lieu d’une réparation définitive, dites-le clairement. Si une équipe ultérieure devra prendre en charge la prochaine série de corrections de bugs, écrivez-le noir sur blanc. Sinon, le même problème sera redécouvert trois semaines plus tard par quelqu’un de nouveau.

Gardez des notes pratiques. “La connexion a cassé après la mise à jour du panier” est trop vague. “La connexion échouait seulement en staging après la mise à jour du panier parce que l’URL de rappel d’authentification a changé dans le commit 48a1c2” est le genre de détail qui fait gagner du temps plus tard. Les numéros et les identifiants de commit comptent plus qu’une explication soignée.

Une dernière habitude aide plus qu’on ne le pense : stocker les commentaires finaux de la revue de code avec le ticket. Un futur mainteneur peut ainsi voir pourquoi la correction a été validée, quelles vérifications ont réussi et quel cas limite a été reporté à une tâche ultérieure. C’est utile la prochaine fois que le même freelance revient, ou lorsqu’un nouveau développeur hérite du projet avec seulement une après-midi pour en lire l’historique.