# Faire reprendre un site développé par quelqu’un d’autre

> Reprendre un site n’est pas un acte administratif, c’est une décision technique. Avant d’accepter, je regarde trois choses : ce qui a été modifié dans le cœur du logiciel, ce qui n’est documenté nulle part, et ce qui n’est pas à votre nom. Ces trois points décident si la reprise est raisonnable, coûteuse ou déconseillée.

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

## Ce que je lis en premier, et pourquoi

La première question n’est pas « le site fonctionne-t-il », c’est « que se passe-t-il si on le met à jour ». La réponse tient dans un endroit précis : les fichiers du cœur ont-ils été modifiés directement ?

Sur PrestaShop, l’extension propre passe par un module ou un override placé dans le répertoire prévu à cet effet. Sur WordPress, elle passe par une extension ou un thème enfant. Quand ces mécanismes ont été respectés, une montée de version est un travail prévisible. Quand du code a été écrit dans les fichiers d’origine, chaque mise à jour écrase le travail, et personne ne sait ce qui a disparu — parce que rien ne le note.

Vient ensuite la question des traces : existe-t-il un dépôt de sources, un environnement de test, une note quelconque expliquant pourquoi telle chose a été faite ? Un site sans historique ne se modifie pas, il s’explore. Cette exploration est du temps facturé qui ne produit rien de visible, et c’est la partie que les clients ont le plus de mal à accepter — à juste titre, puisqu’ils la paient sans l’avoir causée.

## Ce que je vérifie avant de chiffrer quoi que ce soit

- Les fichiers du cœur, comparés à une installation de référence de la même version. C’est ce qui révèle les modifications directes, y compris celles que personne n’a mentionnées.
- Le parc de modules et d’extensions : lesquels sont actifs, lesquels sont abandonnés par leur éditeur, lesquels ont été modifiés après installation.
- L’existence d’un dépôt de sources et d’un environnement de préproduction. Sans eux, toute modification se fait directement en production, ce que je refuse sur une boutique qui vend.
- Les sauvegardes : leur existence, leur fréquence, et surtout la preuve qu’une restauration a déjà été réalisée. Une sauvegarde jamais restaurée n’est pas une sauvegarde.
- La version de PHP et celle de la plateforme, pour savoir si l’on travaille sur une base encore corrigée ou sur un socle abandonné.
- Les accès : qui détient le domaine, l’hébergement, le backoffice, les comptes de paiement et les comptes transporteurs. C’est le point qui réserve le plus de mauvaises surprises.
- Les tâches planifiées et les connexions vers l’extérieur, souvent invisibles dans l’interface et pourtant vitales : synchronisations, exports comptables, flux marchands.

## Comment se déroule une reprise

1. **Sauvegarder avant de toucher à quoi que ce soit** — Fichiers et base, copie récupérée hors du serveur d’origine, restauration vérifiée sur un environnement séparé. Tant que cette copie n’existe pas et ne fonctionne pas, aucune intervention ne commence.
2. **Reproduire le site hors production** — Une copie de travail où l’on peut casser sans conséquence. C’est là que se fait l’exploration, pas sur la boutique qui encaisse. Sans cet environnement, la reprise se transforme en série d’incidents en direct.
3. **Cartographier ce qui a été modifié** — Comparaison avec une installation de référence, inventaire des overrides, liste des modules non standards. Le résultat est un document qui vous appartient, y compris si vous décidez ensuite de travailler avec quelqu’un d’autre.
4. **Rétablir la propriété des accès** — Domaine et hébergement à votre nom, comptes administrateurs recréés, anciens comptes désactivés, clés et jetons d’interface renouvelés. Cette étape est indépendante de la technique et elle est prioritaire.
5. **Décider ensuite, chiffres en main** — Reprendre, remettre en ordre progressivement, ou reconstruire. Cette décision se prend après l’audit, pas avant — et parfois la réponse honnête est de ne pas reprendre.

## Les cas où je refuse une reprise

> Un cœur réécrit sans aucune trace sur une version qui n’est plus corrigée, sans sauvegarde exploitable et sans accès complet : dans cette configuration, chaque intervention crée un risque que je ne peux pas maîtriser, et je le dis plutôt que d’encaisser une première facture. Je refuse également d’intervenir directement en production sur une boutique qui vend, sans copie de travail. Ce n’est pas une posture : c’est la seule manière de ne pas transformer un problème en panne.

## Pages liées

- **Prestataire précédent injoignable** — Le cas d’urgence : établir ce que vous détenez quand plus personne ne répond. ([/problemes/prestataire-precedent-injoignable](/problemes/prestataire-precedent-injoignable))
- **Site laissé sans maintenance** — Ce qui se dégrade quand personne ne s’occupe d’un site pendant des mois. ([/problemes/site-laisse-sans-maintenance](/problemes/site-laisse-sans-maintenance))
- **Override ou module PrestaShop** — Le critère technique qui distingue une extension propre d’une bombe à retardement. ([/guides/override-ou-module-prestashop](/guides/override-ou-module-prestashop))
- **Audit du parc de modules** — L’inventaire détaillé des modules installés, actifs, abandonnés ou modifiés. ([/modules/audit-du-parc-de-modules](/modules/audit-du-parc-de-modules))

## FAQ

### Faut-il tout refaire quand on change de prestataire ?

Non, et c’est même rarement la bonne réponse. Un site fonctionnel, à jour et construit proprement se reprend sans difficulté particulière. Ce qui déclenche une reconstruction, ce n’est pas le changement d’intervenant : c’est un cœur modifié sans trace, une version abandonnée, ou une modélisation de catalogue fausse à la racine.

### Combien coûte l’audit d’entrée ?

C’est une prestation courte et bornée, facturée à la journée, dont le livrable est un document : ce qui a été modifié, ce qui est à risque, ce qui manque en accès, et une hiérarchisation des corrections. Ce document vous reste, y compris si vous décidez de confier la suite à quelqu’un d’autre. C’est volontaire : payer un audit pour se retrouver captif n’aurait aucun sens.

### Peut-on reprendre un site sans le code source d’origine ?

Le code est sur le serveur : si vous avez un accès complet à l’hébergement, vous avez le code, même sans dépôt. Ce qui manque, c’est l’historique — pourquoi telle modification a été faite, ce qui a été essayé, ce qui a été abandonné. C’est reconstituable, mais cela se paie en temps d’exploration.

### Que faire si l’ancien prestataire garde des accès ?

Les révoquer, sans négociation. Comptes administrateurs supprimés, mots de passe changés, clés d’interface régénérées, accès serveur et bases revus. Un accès resté ouvert n’est pas seulement un risque de sécurité : c’est aussi la garantie qu’une modification pourra survenir sans que personne sache d’où elle vient.

### Faites-vous de la maintenance sur un site que vous n’avez pas construit ?

Oui, c’est même le cas de figure le plus fréquent chez moi. La condition est l’audit d’entrée : je n’assure pas la maintenance d’un code que je n’ai pas lu. Un contrat signé sans cette lecture reviendrait à m’engager sur un état que j’ignore, ce qui finit toujours mal, pour vous comme pour moi.