Reprendre un site quand le prestataire est parti
Un client d'agence arrive avec un site qui fonctionne encore, un développeur injoignable depuis six mois, et une facture d'hébergement dont plus personne ne connaît le mot de passe. Le site tourne, mais tout ce qui permettrait de le modifier, de le sauvegarder ou de le déplacer est verrouillé chez quelqu'un qui ne répond plus. C'est la situation que je vois le plus souvent quand on me demande de reprendre un site laissé par un prestataire parti, et le premier réflexe, avant même de regarder une ligne de code, c'est l'inventaire des accès.
La récupération des accès décide de tout le reste
Un site en production repose sur une chaîne d'accès distincts, détenus parfois par des personnes différentes, souvent sans que le client sache lesquels. Tant que cette chaîne n'est pas reconstituée, toute estimation du chantier est de la spéculation. J'ai vu des reprises s'effondrer non pas à cause du code mais parce qu'un maillon manquait et qu'il n'existait aucun moyen de le récupérer sans la coopération de celui qui était parti.
Voici les accès à récupérer, dans l'ordre où ils bloquent, avec ce qui coince le plus souvent en pratique.
| Accès | Détenu par | Ce qui bloque le plus souvent |
|---|---|---|
| Titulaire du nom de domaine | Bureau d'enregistrement (registrar) | Le prestataire est inscrit comme titulaire, pas le client. Transfert impossible sans lui. |
| Gestion DNS | Registrar ou hébergeur | Zone DNS gérée sur un compte tiers dont personne n'a l'identifiant. |
| Hébergement (FTP/SSH) | Hébergeur | Compte au nom du prestataire, facturé sur sa carte, résilié à son départ. |
| Base de données | Hébergeur | Identifiants stockés uniquement dans un fichier de config qu'on n'a pas encore. |
| Code source complet | Dépôt Git ou poste du dev | Seul le code compilé est sur le serveur, les sources sont perdues. |
| Comptes tiers (mail, paiement, API) | Services externes | Clés API dans le code, comptes ouverts avec l'email du prestataire. |
Le domaine arrive en tête parce que c'est le seul accès qu'on ne peut pas contourner. On peut reconstruire un site, migrer une base, réécrire une config, mais on ne peut pas fabriquer un nom de domaine que quelqu'un d'autre détient légalement. Le titulaire inscrit au whois est propriétaire, indépendamment de qui paie. Quand un prestataire a acheté le domaine à son nom, sa coopération devient obligatoire, et si la relation est rompue, ce point seul peut geler le projet plusieurs semaines. Je vérifie le whois avant tout le reste, parce que c'est là que se cache le pire des blocages.
L'hébergement vient juste après. Si le compte est au nom du prestataire et facturé sur sa carte, il peut disparaître au premier impayé, emportant le site et sa base avec lui. Tant que le client n'a pas récupéré ou recréé cet accès à son nom, il vit sur un sursis dont il ignore la date d'expiration. Je considère qu'une reprise n'est jamais sécurisée tant que le domaine et l'hébergement ne sont pas revenus dans un compte contrôlé par le client.
L'audit du code hérité mesure la dette avant de s'engager
Une fois les accès en main, je télécharge tout et je regarde ce que je récupère réellement. La question n'est pas seulement de savoir si le code fonctionne, il fonctionne, sinon on ne serait pas là, mais de savoir combien il coûte à maintenir et à faire évoluer. Un site qui tourne peut cacher une dette technique telle que la moindre modification devient un chantier. C'est exactement la démarche que je décris dans mon article sur l'audit technique avant refonte, appliquée ici à un code dont je n'ai ni l'auteur ni la documentation.
Je regarde d'abord la version des briques principales. Un WordPress bloqué sur PHP 7.2 avec des extensions abandonnées, ou un Symfony sur une version en fin de support, signale que la mise à niveau sera un chantier à part entière. Je regarde ensuite comment le code est organisé: un thème enfant propre et des extensions à jour se reprennent facilement, du code injecté directement dans le thème parent ou dans la base signifie qu'une simple mise à jour peut tout casser. Sur un site construit avec React ou un autre outil à build, je vérifie si les sources non compilées existent quelque part, car sans elles je récupère un résultat que je ne peux pas modifier proprement, seulement remplacer.
Je mesure aussi les performances réelles, parce qu'un site lent hérité est souvent le vrai motif de la reprise. Quand je tombe sur un WordPress lent avec un mauvais PageSpeed, la cause est presque toujours une accumulation d'extensions et un hébergement mutualisé saturé, et non un problème que trois réglages corrigeront. L'audit doit dire si le socle est récupérable ou s'il faut changer de socle, et c'est souvent à ce moment que se pose la question du choix entre Symfony et WordPress pour la suite.
Reprendre ou reconstruire est une décision de marge, pas de goût
La tentation est de reprendre, parce que reprendre semble moins cher que reconstruire. Ce n'est vrai que si la dette héritée est faible. Dès que le code est illisible, les sources manquantes, les versions périmées, chaque intervention future coûte deux à trois fois le temps normal, et cette surcharge se paie à chaque évolution pendant toute la vie du site. Reconstruire coûte cher une fois, reprendre un mauvais code coûte cher indéfiniment.
Ma règle est simple. Si l'audit montre un socle à jour, une organisation propre et des sources complètes, je reprends, même s'il y a du travail. Si je découvre du code compilé sans sources, des versions en fin de vie et des modifications sauvages dans le cœur, je chiffre honnêtement la reconstruction et je la compare au coût cumulé d'une maintenance sur un socle pourri. Dans la moitié des cas que je traite, la reconstruction est la moins chère sur deux ans, même si elle affiche le devis le plus élevé le premier jour.
La limite, celle qu'il faut dire au client dès le devis, c'est que la reprise coûte parfois plus cher que la reconstruction sans qu'on le voie venir. Un site hérité qu'on répare de rustine en rustine, sans jamais résoudre le problème de fond, engloutit du temps facturé pour un résultat toujours fragile. Quand j'estime qu'une reprise va me forcer à intervenir dans un code que je ne maîtrise pas, sur des bases que je ne peux pas tester proprement, je préfère annoncer une reconstruction chiffrée plutôt qu'une réparation dont je ne garantis pas le coût final. Un devis de reconstruction assumé vaut mieux qu'une reprise qui dérape sans plafond.
La migration ne doit pas coûter le référencement
Reprendre ou reconstruire, dans les deux cas il faudra probablement déplacer le site, changer d'hébergement ou refaire l'architecture des URL. C'est le moment le plus dangereux, celui où un site qui rankait correctement peut perdre sa visibilité du jour au lendemain si la migration est bâclée. Les redirections des anciennes URL vers les nouvelles, la conservation des balises, la vérification dans la Search Console: rien de tout cela n'est optionnel. Je détaille la méthode complète dans mon article sur la migration sans perdre le référencement, et c'est la partie que les agences sous-estiment le plus, parce qu'elle ne se voit pas tant qu'on ne regarde pas les positions un mois après.
Une reprise réussie ne se juge pas le jour de la livraison, où tout a l'air identique, mais quelques semaines plus tard, quand le trafic est resté stable et que le client peut enfin modifier son site sans dépendre d'un prestataire injoignable. C'est ce type de dossier que je prends en sous-traitance pour les agences qui n'ont pas de développeur en interne: récupérer les accès, auditer le legacy, trancher entre reprise et reconstruction, et migrer sans casser le référencement, en laissant l'agence garder la relation client.