Reprendre un site WordPress, Woo, Presta ou Symfony quand le développeur d'origine a disparu (ou refuse de répondre) est un cas TMA fréquent. On n'a pas les accès, ou on les a sans doc, ou la doc ment. Cet article décrit la reprise : inventaire des accès, copies, secrets, dette, ce qu'on peut maintenir, ce qu'on doit isoler, comment ne pas devenir le prochain otage. Pas de magie. Une liste de points que je parcours avant de signer un forfait.
🔎 Jour 1 : les accès, rien que les accès
Hébergeur, DNS, nom de domaine (registrar), WordPress / Presta / SSH, CDN, mails, Search Console, analytics, caisses, stores d'apps, dépôts Git, CI, coffres. On liste ce qui manque. On change les mots de passe dès qu'on entre (le prestataire parti les a encore). 2FA au nom du client.
Sans DNS et hébergeur, on ne « reprend » rien. On contemple. Beaucoup de clients ont « l'admin WordPress » et croient que c'est le site. Ce n'est qu'une porte. La maison est ailleurs.
🛠️ Copie avant tout geste héroïque
Sauvegarde fichiers + base, stockée chez vous, restaurée une fois sur un clone. Voir l'article sur les sauvegardes qui se restaurent vraiment. Reprendre sans copie, c'est accepter de tout perdre au premier rm. Je ne touche pas un site hérité avant ça.
Les secrets (clés Stripe, SMTP, API) se renouvellent si on soupçonne qu'ils ont fuité. Un prestataire fâché, c'est un risque sécu, pas seulement un risque d'humeur.
✅ Inventaire technique
Versions, thème, plugins / modules, custom, crons, webhooks, overrides. Qui parle à qui. Ce qui est documenté, ce qui est commenté dans le code, ce qui est magique. On produit une page. C'est livrable. C'est le début de la TMA.
On ne refond pas le jour 2 parce que le code est laid. On dit ce qui est dangereux (sécu, tunnel de vente, PHP mort) et ce qui est laid. Le laid attend. Le dangereux non.
- Accès complets + mots de passe changés + 2FA
- Backup restauré sur un clone
- Inventaire stack et intégrations
- Décision : TMA, nettoyage, refonte, ou refus
⚠️ Le droit de refuser
Un site pirate, une boutique illégale, un otage (licence dans le compte perso du dev), un PHP d'un autre âge sans budget : je refuse, ou je ne prends que la mise à l'abri (sauvegarde, hors ligne, migration d'urgence). Signer une TMA sur un inconnu explosif, c'est devenir responsable d'une bombe qu'on n'a pas posée.
Le client n'aime pas ce discours. Il l'aime mieux que l'incident à son nom trois semaines plus tard.
📌 Devenir le prestataire, pas l'otage suivant
Dépôts au nom du client, accès partagés documentés, pas de licence dans mon compte perso, une page « comment déployer ». Reprendre un site, c'est aussi promettre de pouvoir le quitter. Ironique. Nécessaire.
Les custom « maison » sans licence claire se réécrivent ou se remplacent quand on y touche. On ne les sanctuarise pas.
🧭 Parler au métier, pas seulement au FTP
Qui édite, qui facture, quels pics, quels irritants. Un site hérité « marche » parfois parce que personne n'ose plus le faire évoluer. La reprise inclut cette phrase : que voulez-vous faire dans six mois que vous ne faites plus par peur ?
Ça oriente TMA ou refonte (voir l'article TMA ou refonte). Sans le métier, on maintient un musée.
💡 Calendrier type
Semaine 1 : accès, copies, urgence sécu. Semaine 2-3 : inventaire, petites fuites, 2FA, XML-RPC, monitoring. Puis forfait ou chantier de nettoyage. La refonte, si elle vient, vient après le diagnostic, pas à la place.
Reprendre un site sans le développeur d'origine n'est pas une honte. C'est le cas standard. On l'industrialise. On ne le folklorise pas.
🧪 Le prestataire qui répond encore, un peu
Je lui achète une passation de deux heures plutôt qu'un conflit. Accès, pièges, « ne touche pas à ce cron ». Moins cher qu'une rétro-ingénierie. Reprendre un site sans le développeur d'origine, quand il est encore au bout du fil, c'est d'abord parler, même mal.
S'il refuse, on documente le refus et on avance. On n'attend pas six mois. Les sites sans maître pourrissent à une vitesse connue.
🔎 Licences et comptes perso
Thème et plugins dans le compte ACF / ThemeForest du prestataire : on transfère, ou on rachète, ou on remplace. Un site qui « marche » avec des licences qui ne sont pas à vous est un site en sursis. La reprise inclut cette liste. Elle est moins glamour que le design. Elle évite le lockout de licence à J+30.
Les comptes Cloud, CDN, SMTP pareil. Au nom du client. Dès le jour 1 de ma TMA. Je ne veux pas être l'otage suivant, je ne veux pas en créer un.
🛠️ Annonce à l'équipe interne
On dit qui est le nouveau contact, comment on ouvre une demande, ce qui change (2FA, URL d'admin). Une reprise invisible produit des comptes fantômes et des mots de passe encore chez l'ancien. Le social fait partie de la technique.
Reprendre un site sans le développeur d'origine est un changement d'équipe. On le traite comme tel. Puis je code.
Sans le métier, on maintient un musée. Pas un site.
