Que faire lorsque un freelance livre du code défectueux

Que faire lorsque un freelance livre du code défectueux

Un code cassé n'est pas la même chose qu'un bug normal. Un bug normal apparaît dans une fonctionnalité qui fonctionne principalement ; un code cassé peut arrêter une version, bloquer une connexion ou rendre le fichier inutilisable dès le premier jour. Cette différence est importante car votre prochaine action doit correspondre aux dégâts, pas à votre humeur.

Commencez par une question : quelqu'un peut-il l'utiliser en toute sécurité ? Si la réponse est non, considérez-le comme un problème de livraison, pas comme une tâche de finition. Si la réponse est oui, mais qu'un chemin échoue, vous êtes probablement confronté à un défaut qui nécessite encore une correction. Simple, mais utile.

Qu'est-ce qui compte comme « code cassé » par rapport à un bug normal ?

Le code cassé se présente généralement sous 3 formes : travail incomplet, travail instable ou travail qui ne peut pas s'exécuter dans la configuration convenue. Un bouton de formulaire qui génère une erreur lors de la soumission est un bug. Un flux de paiement qui n'atteint jamais le paiement parce que le freelance a omis la validation, le fichier de routage ou le hook API requis est un code cassé.

Regardez d'abord la portée. 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. Si le freelance a livré un script qui dépend d'un fichier jamais mentionné, ce n'est également pas un petit défaut. Le code peut exister, mais la livraison est toujours cassée.

Un test pratique aide : le code peut-il être jugé par rapport au résultat convenu 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 grand qu'une simple faute de frappe. C'est à ce moment que de nombreux clients devraient revoir leurs notes et, si nécessaire, comparer le problème avec comment embaucher un freelance en toute sécurité pour le prochain projet.

Que devez-vous vérifier en premier avant de contacter le freelance ?

Reproduisez le problème une fois avant d'écrire. Deux fois, c'est mieux. Utilisez le même navigateur, le même appareil et le même compte si possible. Notez exactement sur quoi vous avez cliqué, ce qui s'est passé et où l'échec est apparu. « Ça ne fonctionne pas » est trop vague pour aider qui que ce soit.

Ensuite, notez l'environnement. Enregistrez le nom du navigateur, la version, le système d'exploitation, l'URL du serveur et si vous avez utilisé un environnement de staging ou de production. Un chemin de code qui fonctionne sur Chrome sur un ordinateur portable peut échouer sur Safari sur un téléphone, et cette différence peut éviter beaucoup d'allers-retours par la suite.

Collectez les preuves tangibles pendant qu'elles sont encore fraîches : captures d'écran, messages de la console, journaux du serveur, identifiants d'erreur et l'horodatage de l'échec. Si le bug apparaît après un déploiement, notez le fichier exact ou la version que vous avez reçue. Ces détails transforment une plainte vague en un rapport utilisable.

Ne changez pas trois choses à la fois. Si vous modifiez la configuration, remplacez le jeu de données et redémarrez le service, personne ne peut dire quel changement a causé l'échec. Gardez un chemin de test fixe.

Comment devriez-vous signaler un code cassé sans en faire une 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. Cela suffit pour ouvrir une conversation de réparation sans paraître accusateur.

Exemple : « Sur le site de staging, le formulaire de contact renvoie une erreur 500 après soumission. Je m'attendais à ce que le formulaire envoie le message et affiche une confirmation. J'ai joint la capture d'écran et le journal de la console. Veuillez confirmer la cause et envoyer un correctif ou une version corrigée. »

Cette formulation ne laisse aucune place au théâtre. Elle évite également le piège de blâmer le freelance pour ses intentions, ce que vous ne pouvez de toute façon pas prouver. Gardez la phrase sur l'impact concrète : « les clients ne peuvent pas soumettre de commandes », « le panneau d'administration se fige » ou « le fichier exporté est vide ». Ces détails comptent plus que les émotions.

Si le projet a touché un travail visible par le public, le message doit mentionner clairement la conséquence. Une page d'atterrissage cassée peut gaspiller un budget marketing en quelques heures ; un processus de paiement cassé peut coûter des ventes immédiatement. Personne n'a besoin d'un paragraphe dramatique pour comprendre cela.

Quelle preuve devriez-vous partager pour que le freelance puisse le corriger plus rapidement ?

Envoyez les étapes à reproduire dans l'ordre, pas comme une histoire. Étape 1 : connectez-vous. Étape 2 : ouvrez le tableau de bord. Étape 3 : cliquez sur Exporter. Étape 4 : le téléchargement échoue. Ce genre de liste permet au freelance de retracer exactement votre chemin.

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 spécifique. Si le code dépend d'un paramètre de langue, d'une extension de navigateur ou d'une variable d'environnement spécifique, mentionnez-le. Un détail manquant peut faire perdre un après-midi.

Partagez les informations de version pour le livrable lui-même. Si vous avez reçu “v3”, dites-le. Si le freelance a poussé un correctif après votre dernière révision, indiquez quel correctif. S'il y a un dépôt privé, incluez le nom de la branche et le hash du commit.

Les fichiers aident, mais seulement les bons. Une capture d'écran d'un écran vide est utile. Un enregistrement d'écran de 4 minutes peut être encore mieux s'il montre les clics et l'échec en une seule fois. C'est là que la phrase avis sur les freelancers devient parfois pertinente, car un schéma de transmissions peu claires apparaît souvent là avant d'apparaître dans le code.

Quand devriez-vous demander un correctif, un retour en arrière ou un remboursement ?

Choisissez le remède par gravité, pas par frustration. Si le bug est mineur et que la base de code est par ailleurs utilisable, demandez un correctif. Si le code défectueux bloque un lancement ou corrompt des données, un retour en arrière peut être le mouvement sûr le plus rapide. Si le livrable est inutilisable ou dangereux à réparer, un remboursement devient raisonnable.

Posez une question directe : cela peut-il être corrigé sans endommager d'autres parties du projet ? Si la réponse est incertaine et que le freelance devine, un retour en arrière peut vous protéger mieux que d'attendre. Un mauvais correctif peut transformer un module cassé en trois modules cassés.

Les remboursements ne devraient pas être la première menace dans le message 1. Ils doivent venir après un examen clair des preuves et des conditions de livraison. Cependant, si le travail ne peut pas être réparé sur place, ou si le freelancer admet que l'architecture est incorrecte, vous devez cesser de traiter le fichier comme s'il n'était qu'à un pas de la finition.

Il y a un aspect pratique ici. Si une version bloque les revenus, 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 à faible risque, la correction peut attendre plus longtemps. Le contexte est important.

Que se passe-t-il si le freelancer dit que le code fonctionne de son côté ?

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

Demandez la configuration exacte que le freelancer a utilisée. Demandez les numéros de version, les étapes d'installation et toutes les étapes manuelles qu'il a suivies après le clonage ou le téléchargement. S'ils disent « ça a fonctionné localement », vous avez besoin de la recette locale, pas d'une assurance. C'est tout le but.

Parfois, le code dépend d'une hypothèse silencieuse. Le freelancer a peut-être supposé qu'un compte administrateur existe, ou qu'un fichier de configuration était déjà présent, ou que la base de données contient déjà un enregistrement de départ. Ces hypothèses auraient dû être documentées, mais maintenant la tâche immédiate est de les exposer une par une.

Gardez un ton calme, même si la réponse semble évasive. Une phrase comme « Veuillez envoyer les étapes exactes de configuration que vous avez utilisées afin que je puisse les comparer avec mon environnement » suffit. Si le freelance est coopératif, l'écart se réduit souvent rapidement. Sinon, vous savez au moins que le problème n'est plus uniquement technique.

Quand 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 détails d'accès manquants, des fichiers d'environnement manquants et des instructions de déploiement manquantes. Le code peut être présent ; la propriété ne l'est pas.

Cela se produit souvent dans des 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 se trouvent dans un message privé. Un designer remet un thème de site, mais l'outil de construction n'est jamais nommé. Un script backend ne fonctionne que sur la machine du freelance car le reste de la configuration n'a jamais été noté.

À ce stade, le problème n'est pas seulement « corrigez ce bug ». C'est « mon équipe peut-elle adopter ce travail ? » Si la réponse est non, la livraison est incomplète, même si chaque fichier semble en ordre. C'est ici que les règles de les règles du site 24freelance.pro. freelance peuvent être un point de référence utile pour la manière dont le travail, les fichiers et la communication doivent être gérés.

Certaines équipes ont également besoin d'une liste de contrôle de transfert avant d'accepter le projet. Une ligne pour l'accès. Une ligne pour l'hébergement. Une ligne pour les identifiants administratifs. Une ligne pour la structure des dossiers. Sans cela, le transfert peut échouer même lorsque le code lui-même est solide.

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'exportation produit un CSV avec 3 colonnes. » « Le formulaire envoie l'email et affiche un message de succès. » Ces lignes rendent le code défectueux plus facile à repérer car l'objectif est visible.

Demandez des cas de test à l'avance, surtout pour les fonctionnalités avec 2 branches ou plus. Si le freelance sait comment vous allez tester, il est plus probable qu'il construise pour le véritable contrôle, et non pour un imaginaire. La révision en staging aide aussi, car elle détecte le code défectueux avant que quiconque ne le considère comme terminé.

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

Pour des tâches complexes, demandez une courte note de transfert. Même 5 points peuvent vous faire gagner du temps plus tard : environnement, dépendances, limites connues, données de test, et qui possède l'étape suivante. Petite demande, grand retour.

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