# 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.

- Source canonique : [https://allaux.fr/modules/reprendre-un-module-inacheve](https://allaux.fr/modules/reprendre-un-module-inacheve)
- Langue : FR
- Dernière mise à jour : 2026-08-02

## 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

1. **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.
2. **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.
3. **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.
4. **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.

## Avant tout, vérifiez ce à quoi vous avez encore accès

> Récupérez les codes du serveur, de la base de données, du dépôt de code s’il existe, et des comptes tiers utilisés par le module. Un prestataire qui ne répond plus est un problème ; un prestataire qui détient seul un accès de production en est un autre, plus grave, et il se règle avant de parler de code.

## Pages liées

- **Maintenance et infogérance** — Ce qui doit être en place ensuite pour qu’un module ne redevienne pas orphelin. ([/services/maintenance](/services/maintenance))
- **Audit du parc de modules** — L’inventaire complet quand plusieurs développements se sont succédé sans continuité. ([/modules/audit-du-parc-de-modules](/modules/audit-du-parc-de-modules))
- **Ce qui fait le prix d’un module sur mesure** — Pourquoi une reprise ne se chiffre pas comme un développement neuf. ([/modules/ce-qui-fait-le-prix-d-un-module](/modules/ce-qui-fait-le-prix-d-un-module))
- **Dépannage e-commerce urgent** — Si la boutique est bloquée en production pendant que la reprise s’organise. ([/services/depannage-urgent](/services/depannage-urgent))

## FAQ

### Acceptez-vous de reprendre le code de quelqu’un d’autre ?

Oui, c’est une part régulière de mon travail. Je ne m’engage simplement pas au forfait avant de l’avoir lu : je propose d’abord un temps borné de diagnostic, avec un compte rendu écrit, puis un chiffrage.

### Le module n’est pas documenté du tout, est-ce bloquant ?

Non. L’absence de documentation est la règle plutôt que l’exception. Ce qui bloque vraiment, c’est le code encodé et l’absence d’accès au serveur : sans le code lisible, il n’y a rien à reprendre.

### Puis-je récupérer le travail déjà payé ?

Techniquement, oui, si vous disposez des fichiers déployés sur le serveur : ce sont eux qui font foi, pas ce qui a été promis. Juridiquement, cela dépend de votre contrat, et ce n’est pas mon domaine.

### Combien de temps prend le diagnostic ?

Cela dépend de la taille du module, mais il est toujours borné à l’avance : je fixe une durée maximale avant de commencer, et je m’y tiens, quitte à conclure que la lecture ne suffit pas.