Reprendre un module laissé inachevé par un autre prestataire
Un module à moitié fait, un développeur qui ne répond plus, une boutique qui attend : la question n’est pas « pouvez-vous finir », mais « qu’y a-t-il réellement dans ce code », et personne ne peut y répondre sans l’avoir lu.
Ce que je récupère avant de dire quoi que ce soit
Je demande trois choses : le code complet du module tel qu’il est déployé, un accès en lecture à la boutique où il tourne, et la description de ce qu’il devait faire. Le troisième point manque presque toujours, et c’est le plus utile : sans lui, on ne peut pas distinguer un comportement volontaire d’un bug. Une fonction laissée à moitié ressemble énormément à une fonction cassée.
Je vérifie ensuite ce qui a été livré au-delà du dossier du module : des surcharges de classes déposées ailleurs, des tables ajoutées en base, des tâches planifiées côté serveur, des clés d’API stockées quelque part. Un module inachevé a souvent laissé des morceaux hors de son propre dossier, et ce sont eux qui posent problème plus tard.
Les quatre points qui décident entre finir et réécrire
-
L’architecture est-elle celle de la plateforme
Un module qui respecte le cycle d’installation, les points d’accroche et les conventions de la plateforme se termine. Un module qui écrit directement dans les tables du cœur en contournant les objets prévus se réécrit, parce que chaque mise à jour le remettra en cause.
-
Le code est-il lisible
Nommage cohérent, séparation entre affichage et traitement, absence de blocs recopiés dix fois. Ce n’est pas une question d’élégance : c’est ce qui détermine si une correction prend une heure ou une journée.
-
Que fait-il des données
Requêtes sans échappement, données stockées sans contrainte, absence totale de gestion d’erreur : ces trois signaux à eux seuls justifient souvent une réécriture, quelle que soit l’avancée apparente.
-
Quelle part est réellement faite
Un module qui affiche un écran n’est pas un module qui fonctionne. Je teste les cas réels avant de croire l’état d’avancement annoncé.
Finir coûte parfois plus cher que refaire
C’est contre-intuitif et je le dis pourtant régulièrement : reprendre un code qu’on n’a pas écrit demande d’abord de le comprendre entièrement, y compris ses parties que l’on ne touchera pas. Sur un module modeste, ce temps de lecture peut dépasser le temps d’écriture d’une version propre. Quand c’est le cas, je le dis, avec les raisons, et vous décidez.
À l’inverse, quand la base est saine, la reprise est nettement plus rapide qu’un redémarrage : les choix fonctionnels ont déjà été faits, les cas particuliers de votre activité sont déjà identifiés dans le code, et il ne reste qu’à finir et sécuriser. Je rencontre les deux situations, à peu près aussi souvent l’une que l’autre.
Dans tous les cas, la reprise se termine par la même chose : un module que vous pouvez confier à quelqu’un d’autre. Sources complètes, dépendances identifiées, procédure d’installation écrite. C’est précisément ce qui manquait au départ.
Pages liées
-
Maintenance et infogérance
Ce qui doit être en place ensuite pour qu’un module ne redevienne pas orphelin.
-
Audit du parc de modules
L’inventaire complet quand plusieurs développements se sont succédé sans continuité.
-
Ce qui fait le prix d’un module sur mesure
Pourquoi une reprise ne se chiffre pas comme un développement neuf.
-
Dépannage e-commerce urgent
Si la boutique est bloquée en production pendant que la reprise s’organise.
- 2019 développeur e-commerce depuis
- 3 plateformes : PrestaShop, WooCommerce, Shopify
- 3 langues de travail : FR, EN, TR
- 100 % des échanges directs avec le développeur
Aucun intermédiaire : la personne qui répond est celle qui intervient sur le code.
Décrivez votre besoin en 1 minute
Quelques questions ciblées pour que je vous réponde avec une estimation, pas avec un questionnaire de plus.