Le prestataire precedent a disparu, ne repond plus, ou le resultat ne convient tout simplement plus. Reprendre un site existant est une situation courante, mais elle demande une methode differente d'un projet neuf : avant de changer quoi que ce soit, il faut d'abord comprendre ce qui existe reellement derriere l'interface visible.
Le premier reflexe : faire l'etat des lieux technique
Un site web repose sur plusieurs elements qu'il faut identifier avant toute intervention : le nom de domaine et qui le detient reellement, l'hebergement et ses identifiants, le systeme utilise (WordPress, Prestashop, un developpement sur-mesure, ou un constructeur type Wix), et l'acces a la base de donnees si elle existe. Sans ces acces, aucune intervention n'est possible, meme mineure. Il n'est pas rare qu'un ancien prestataire garde la main sur le nom de domaine ou l'hebergement sans que le client le sache, ce qui bloque tout transfert.
Les acces a reclamer en priorite
- Identifiants du registrar (ou est deposé le nom de domaine)
- Acces FTP ou SSH a l'hebergement
- Identifiants administrateur du CMS ou de la base de donnees
- Comptes lies : Google Search Console, Google Analytics, compte publicitaire
Ce qu'une agence verifie avant de reprendre un site
Une reprise serieuse commence par un audit, pas par des modifications immediates. Cet audit couvre l'etat du code (a jour ou obsolete, faille de securite connue), la structure SEO existante (positions actuelles, contenu deja indexe par Google, a ne surtout pas perdre en route), et la qualite technique globale (temps de chargement, compatibilite mobile). Ce diagnostic evite une erreur frequente : tout refaire par reflexe, alors que certains elements du site existant fonctionnent deja bien et meritent d'etre conserves, notamment le referencement acquis au fil du temps.
Refonte totale ou reprise partielle
Deux options se presentent selon l'etat du site. Si la base technique est saine mais le design date ou le contenu est pauvre, une refonte de site ciblee suffit souvent, en conservant l'architecture qui fonctionne. Si le code est obsolete, truffe de failles de securite, ou developpe sur un outil abandonne, repartir sur une base neuve devient plus rentable a moyen terme qu'un rafistolage couteux. Dans les deux cas, le point non negociable reste la continuite du referencement : les URLs existantes, quand elles sont bien positionnees, doivent etre conservees ou redirigees proprement, sous peine de perdre en quelques semaines une visibilite construite sur plusieurs annees.
Les pieges specifiques a la reprise
- Le contrat avec l'ancien prestataire : verifiez s'il existe une clause de propriete du code ou des contenus avant de rompre la relation
- Les redirections mal faites : changer de systeme sans rediriger les anciennes pages fait chuter le trafic organique brutalement
- Les comptes tiers orphelins : Search Console ou Analytics crees avec l'email de l'ancien prestataire et jamais transferes
- L'absence de sauvegarde : intervenir sur un site sans backup prealable, c'est prendre un risque inutile des le premier jour
Ce qu'on recommande avant de se lancer
Rassemblez d'abord tous les acces que vous pouvez retrouver, meme partiels, et listez precisement ce qui ne fonctionne pas ou plus dans votre situation actuelle : lenteur, impossibilite de modifier le contenu, absence de suivi, faille de securite deja detectee. Cette liste, transmise des le premier echange, permet a l'agence de chiffrer un devis realiste plutot qu'une estimation a l'aveugle. Et si la securite du site actuel vous inquiete deja, un point sur la maintenance et la securite doit faire partie de la discussion des le depart, pas apres coup.