Que faire lorsqu’un freelance livre du code cassé

Que faire lorsqu’un freelance livre du code cassé

Le code cassé n’est pas la même chose qu’un bug ordinaire. Un bug classique apparaît dans une fonctionnalité qui fonctionne globalement ; du code cassé peut bloquer une mise en production, empêcher une connexion ou rendre un fichier inutilisable dès le premier jour. La différence compte, car votre prochain geste doit correspondre à l’ampleur du problème, pas à votre humeur.

Commencez par une question : quelqu’un peut-il l’utiliser sans risque ? Si la réponse est non, traitez cela comme un problème de livraison, pas comme une simple retouche. Si la réponse est oui, mais qu’un seul parcours échoue, vous êtes probablement face à un défaut qui doit encore être corrigé. Simple, mais utile.

Qu’est-ce qui relève du « code cassé » et qu’est-ce qui est un bug normal ?

Le code cassé se présente généralement sous 3 formes : un travail incomplet, un travail instable ou un travail qui ne peut pas s’exécuter dans l’environnement convenu. Un bouton de formulaire qui renvoie une erreur à l’envoi est un bug. Un tunnel d’achat qui n’atteint jamais le paiement parce que le freelance a omis la validation, le fichier de routage ou le hook API requis, c’est du code cassé.

Commencez par regarder l’ampleur. Si le freelance a promis un constructeur de page et n’a livré que l’en-tête, ce n’est pas un petit défaut. S’il a livré un script qui dépend d’un fichier jamais mentionné nulle part, ce n’est pas non plus un petit défaut. Le code peut exister, mais la livraison reste cassée.

Un test pratique aide beaucoup : peut-on évaluer le code par rapport au résultat attendu en moins de 5 minutes ? Si vous avez besoin de connaissances cachées, d’étapes de configuration secrètes ou d’une explication privée pour le faire fonctionner, le problème est plus grave qu’une simple faute de frappe. C’est souvent le moment où il faut relire ses notes et, si besoin, comparer le problème avec comment recruter un freelance en toute sécurité pour le projet suivant.

Que faut-il vérifier en premier avant de contacter le freelance ?

Reproduisez le problème une fois avant d’écrire. Deux fois, c’est mieux. Utilisez si possible le même navigateur, le même appareil et le même compte. Notez précisément ce que vous avez cliqué, ce qui s’est produit et à quel endroit l’échec est apparu. « Ça ne marche pas » est trop vague pour aider qui que ce soit.

Ensuite, précisez l’environnement. Indiquez le nom du navigateur, sa version, le système d’exploitation, l’URL du serveur, et si vous étiez en préproduction ou en production. Un chemin de code qui fonctionne dans Chrome sur ordinateur peut échouer dans Safari sur téléphone, et cette différence peut éviter beaucoup d’échanges inutiles ensuite.

Rassemblez les preuves tant que tout est encore frais : captures d’écran, messages de la console, logs serveur, identifiants d’erreur et horodatage de l’échec. Si le bug apparaît après un déploiement, notez le fichier ou la version exacte reçue. Ces détails transforment une plainte vague en rapport exploitable.

Ne modifiez pas trois choses à la fois. Si vous changez la configuration, remplacez le jeu de données et redémarrez le service, personne ne peut savoir quelle modification a provoqué l’échec. Gardez un seul parcours de test inchangé.

Comment signaler du code cassé sans transformer cela en dispute ?

Gardez le premier message court, factuel et daté. Une bonne structure est : 1) ce qui a échoué, 2) où cela a échoué, 3) ce que vous attendiez, 4) ce dont vous avez besoin ensuite. C’est suffisant pour ouvrir une conversation de correction sans paraître accusateur.

Exemple : « Sur le site de préproduction, le formulaire de contact renvoie une erreur 500 après l’envoi. Je m’attendais à ce qu’il transmette le message et affiche une confirmation. J’ai joint la capture d’écran et le journal de console. Merci de confirmer la cause et d’envoyer un correctif ou une version corrigée. »

Cette formulation ne laisse pas place au théâtre. Elle évite aussi de reprocher au freelance une intention, ce que vous ne pouvez pas prouver de toute façon. Gardez la phrase sur l’impact concrète : « les clients ne peuvent pas envoyer de commande », « le panneau d’administration se fige » ou « le fichier exporté est vide ». Ces détails comptent plus que les émotions. Si vous vous demandez comment signaler un bug à un freelance, cette méthode reste la plus simple et la plus efficace.

Si le projet concerne une interface publique, le message doit mentionner clairement la conséquence. Une page d’atterrissage cassée peut gaspiller un budget marketing en quelques heures ; un tunnel d’achat défaillant peut faire perdre des ventes immédiatement. Inutile d’écrire un long paragraphe dramatique pour que cela soit compris.

Quelles preuves partager pour permettre au freelance de corriger plus vite ?

Envoyez les étapes pour reproduire le problème dans l’ordre, pas sous forme de récit. Étape 1 : se connecter. Étape 2 : ouvrir le tableau de bord. Étape 3 : cliquer sur Exporter. Étape 4 : le téléchargement échoue. Ce type de liste permet au freelance de reprendre exactement votre parcours.

Incluez les données de test qui ont déclenché le problème, comme un compte de démonstration, un enregistrement d’exemple ou un nom de fichier précis. Si le code dépend d’un réglage de langue, d’une extension de navigateur ou d’une variable d’environnement spécifique, mentionnez-le. Un détail manquant peut faire perdre tout un après-midi.

Partagez les informations de version du livrable lui-même. Si vous avez reçu la « v3 », dites-le. Si le freelance a poussé un correctif après votre dernière revue, indiquez lequel. S’il existe un dépôt privé, ajoutez le nom de la branche et le hash du commit.

Les fichiers aident, mais seulement les bons. Une capture d’écran d’un écran blanc est utile. Un enregistrement vidéo de 4 minutes peut être encore mieux s’il montre les clics et l’échec en un seul passage. C’est là que l’expression avis sur les freelances devient parfois pertinente, car un schéma de transferts peu clairs apparaît souvent là avant d’apparaître dans le code. Quand un freelance a livré du code cassé, ce niveau de preuve accélère souvent la correction.

Quand demander une correction, un retour en arrière ou un remboursement ?

Choisissez la solution selon la gravité, pas selon la frustration. Si le bug est mineur et que la base de code reste utilisable, demandez une correction. Si le code cassé bloque un lancement ou corrompt des données, un retour en arrière peut être la solution la plus sûre et la plus rapide. Si le livrable est inutilisable ou trop risqué à réparer, un remboursement devient raisonnable.

Posez une question directe : peut-on corriger cela sans endommager d’autres parties du projet ? Si la réponse est incertaine et que le freelance procède à tâtons, revenir en arrière peut vous protéger mieux qu’attendre. Un mauvais correctif peut transformer un seul module cassé en trois modules cassés.

Le remboursement ne doit pas être la première menace du message 1. Il intervient après une revue claire des preuves et des conditions de livraison. Cela dit, si le travail ne peut pas être réparé sur place, ou si le freelance admet que l’architecture est mauvaise, il ne faut plus considérer le fichier comme étant à un seul pas de la version finale.

Il y a ici un enjeu très concret. Si une mise en production bloque du chiffre d’affaires, chaque heure de retard a un coût, même si vous ne le calculez pas au centime près. Si le projet est privé et peu risqué, la correction peut attendre davantage. Le contexte compte.

Que faire si le freelance dit que le code fonctionne de son côté ?

Ne considérez pas cette réponse comme une dispute. Prenez-la comme un indice. Dans de nombreux cas, le problème vient d’une différence d’environnement : une machine a des dépendances en cache, une autre utilise une version différente de Node, ou un serveur masque un fichier manquant derrière une étape de configuration locale.

Demandez précisément la configuration utilisée par le freelance. Exigez les numéros de version, les étapes d’installation et toute étape manuelle effectuée après le clonage ou le transfert. S’il dit « ça marchait en local », il vous faut la recette locale, pas des assurances. C’est bien là l’essentiel.

Parfois, le code repose sur une hypothèse implicite. Le freelance a peut-être supposé qu’un compte administrateur existait, qu’un fichier de configuration était déjà présent, ou que la base de données contenait déjà un enregistrement d’amorçage. Ces hypothèses auraient dû être documentées, mais l’objectif immédiat est maintenant de les mettre au jour une par une.

Gardez un ton calme, même si la réponse vous paraît évasive. Une formule comme « Merci d’envoyer les étapes de configuration exactes que vous avez utilisées afin que je puisse les comparer avec mon environnement » suffit. Si le freelance coopère, l’écart se réduit souvent vite. Sinon, vous savez au moins que le problème n’est plus seulement technique.

À quel moment le code cassé devient-il un problème de transfert ou de propriété ?

Le code cassé devient un problème de transfert lorsque les fichiers arrivent sans les étapes nécessaires pour les exécuter. Cela inclut des notes d’installation manquantes, des identifiants d’accès manquants, des fichiers d’environnement manquants et des instructions de déploiement absentes. Le code peut être présent ; la propriété, non.

Cela arrive souvent dans les projets qui dépendent d’une équipe, et non d’une seule personne. Un développeur envoie un dépôt, mais les identifiants du serveur restent dans un message privé. Un designer remet un thème de site, mais l’outil de build n’est jamais mentionné. Un script backend ne fonctionne que sur la machine du freelance parce que le reste de la configuration n’a jamais été noté.

À ce stade, le problème n’est plus seulement « corrige ce bug ». C’est « mon équipe peut-elle seulement reprendre ce travail ? » Si la réponse est non, la livraison est incomplète, même si chaque fichier semble propre. C’est ici que les règles de le règlement du site 24freelance.pro. freelance peuvent servir de point de repère utile pour savoir comment le travail, les fichiers et la communication doivent être gérés.

Certaines équipes ont aussi besoin d’une checklist de transfert avant d’accepter le projet. Une ligne pour les accès. Une ligne pour l’hébergement. Une ligne pour les identifiants administrateur. Une ligne pour la structure des dossiers. Sans cela, le transfert peut échouer même quand le code lui-même est correct.

Comment éviter le même problème de livraison la prochaine fois ?

Rédigez des critères d’acceptation avant le début du travail. Pas un paragraphe. Une liste. « La connexion réussit avec des identifiants valides. » « L’export produit un CSV avec 3 colonnes. » « Le formulaire envoie l’e-mail et affiche un message de succès. » Ces lignes rendent le code cassé plus facile à repérer, car la cible est visible.

Demandez des cas de test à l’avance, surtout pour les fonctionnalités comportant 2 branches ou plus. Si le freelance sait comment vous allez tester, il a plus de chances de construire pour le vrai contrôle, et non pour un contrôle imaginaire. La revue en préproduction aide aussi, car elle détecte le code cassé avant que quiconque le considère comme terminé.

Définissez « terminé » en une phrase qui inclut les fichiers, les accès et une preuve. Par exemple : « Terminé signifie que le code fonctionne sur notre serveur de préproduction, que le README liste les étapes d’installation et que le compte de test vérifie le flux principal. » Cette définition ne résout pas un mauvais travail, mais elle le rendra visible plus tôt.

Pour les tâches complexes, demandez une courte note de transfert. Même 5 points peuvent vous faire gagner du temps ensuite : environnement, dépendances, limites connues, données de test et responsable de l’étape suivante. Petite demande, grand bénéfice.

Dernière habitude utile : gardez la discussion du projet et la liste finale des fichiers au même endroit. Si le freelance envoie un correctif par e-mail, mais que la note de déploiement est dans le chat et que le mot de passe du serveur se trouve dans un tableur, le transfert est fragile. Et les transferts fragiles échouent sous pression.