Un jour, tout fonctionne. Le site tourne, les mails arrivent, le formulaire de contact remplit la boîte de réception. Et puis plus rien. Le prestataire ne répond plus aux mails, le téléphone sonne dans le vide, le site affiche une erreur de certificat, et personne dans l'entreprise ne sait où sont les identifiants.
Cette situation est beaucoup plus courante qu'on ne l'imagine. Une agence qui met la clé sous la porte, un freelance qui change de métier, un développeur qui disparaît au milieu d'une refonte, un partenaire historique racheté par un groupe qui ne veut plus des petits comptes. Les causes varient. Le résultat est identique : une entreprise qui découvre, souvent brutalement, qu'elle ne possède pas ce qu'elle croyait posséder.
Voilà le point important. Un prestataire digital défaillant, ce n'est pas d'abord un problème technique. C'est un problème de propriété et de contrôle. Le site, le nom de domaine, les données de trafic, la base clients : tout cela constitue un patrimoine, au même titre qu'un local ou un fichier commercial. Sauf que ce patrimoine-là est immatériel, dispersé entre une dizaine de comptes différents, et que personne ne pense à en vérifier les titres de propriété avant que ça ne casse.
La bonne nouvelle, c'est qu'il existe une méthode. Elle se déroule en cinq temps : inventorier, sécuriser l'urgent, demander formellement, récupérer actif par actif, migrer sans casser le référencement. Avec, en toile de fond, un cadre juridique français plutôt favorable au client : le contrat de prestation, le droit de la propriété intellectuelle et le RGPD offrent des leviers réels, à condition de savoir lesquels actionner et dans quel ordre.
Reconnaître une défaillance avant qu'elle ne devienne un blocage
Avant de dégainer la mise en demeure, une question de bon sens : s'agit-il vraiment d'une défaillance ? Un prestataire débordé qui répond en cinq jours au lieu de deux n'est pas un prestataire défaillant. Un bras de fer déclenché trop tôt abîme une relation parfois récupérable, et surtout, il pousse l'autre partie à se retrancher. Autant faire le tri.
Les signaux faibles qui doivent alerter
Ils sont discrets et s'installent progressivement. Les délais de réponse s'allongent, de deux jours à une semaine, puis à trois. Les factures d'hébergement arrivent sous la forme d'une ligne unique intitulée « maintenance et hébergement annuel », sans détail, sans nom d'hébergeur, sans référence de contrat.
Autre marqueur classique : le refus poli de communiquer un accès administrateur, justifié « pour des raisons de sécurité ». Cet argument mérite d'être examiné de près. La sécurité d'un site ne repose pas sur le fait que son propriétaire en ignore les clés. Elle repose sur des mots de passe robustes, une double authentification et une gestion sérieuse des droits. Un prestataire sérieux fournit un compte administrateur au client, éventuellement avec un rappel des précautions à prendre. Il ne le retient pas.
À surveiller également : l'absence totale de documentation technique, un interlocuteur unique parti sans être remplacé, et un nom de domaine systématiquement renouvelé la veille de son expiration. Ce dernier détail en dit long sur l'organisation interne du prestataire.
Les signaux de rupture
Ceux-là ne laissent aucune place au doute. Le site est hors ligne depuis plusieurs jours. Le certificat SSL a expiré et les navigateurs affichent un avertissement rouge aux visiteurs. Le nom de domaine est entré en période de rédemption, cette phase où il n'est plus actif mais pas encore libéré, et où sa récupération coûte plusieurs fois le prix d'un renouvellement normal.
Plus grave encore : la messagerie professionnelle est coupée. Là, l'activité s'arrête net. Les devis ne partent plus, les commandes n'arrivent plus, les clients pensent que l'entreprise a fermé.
Et puis il y a le cas juridique : le prestataire est en liquidation judiciaire, ou l'agence a changé de main sans que personne ne prévienne les clients. Un mandataire est alors le seul interlocuteur légitime, ce qui change complètement la manière d'aborder la récupération.
Défaillance technique ou défaillance contractuelle ?
La distinction est loin d'être théorique, car elle détermine toute la stratégie à suivre.
Une prestation mal exécutée (un site lent, un cahier des charges non respecté, des fonctionnalités absentes) relève du terrain contractuel. Le recours passe par la mise en cause de la bonne exécution du contrat, éventuellement par une réduction du prix ou une résolution.
Une rétention d'accès, c'est autre chose. Le prestataire détient des éléments qui appartiennent à l'entreprise et refuse de les restituer, souvent pour faire pression dans un litige commercial. On entre dans un rapport de force, où la question n'est plus « la prestation était-elle conforme ? » mais « qui est propriétaire de quoi, et comment le prouver ? ».
Ces deux situations se cumulent parfois. Elles ne se traitent pas de la même façon, et surtout, elles ne se traitent pas dans le même ordre. La restitution des accès prime toujours : sans elle, aucun débat sur la qualité de la prestation n'a de portée pratique.
Étape 1 : dresser l'inventaire complet de votre patrimoine numérique
C'est l'étape que tout le monde veut sauter, et c'est précisément celle qui détermine la suite. Impossible de réclamer ce qu'on n'a pas identifié.
Un constat revient dans presque tous les dossiers de reprise en main : les dirigeants sous-estiment massivement le nombre de comptes concernés. On pense au site et au nom de domaine. On oublie les douze autres actifs qui, mis bout à bout, représentent souvent davantage de valeur.
Pour chaque élément de la liste qui suit, trois questions à se poser systématiquement : où le vérifier concrètement, au nom de qui il est enregistré, et quel serait le coût réel de sa perte définitive.
Le nom de domaine : l'actif le plus critique
Il n'y a pas de hiérarchie discutable ici. Le nom de domaine passe avant tout le reste. Un site peut se reconstruire, des contenus peuvent se réécrire, mais un nom de domaine perdu emporte avec lui l'adresse, la messagerie, le référencement accumulé et l'ensemble des liens pointant vers le site depuis des années.
La vérification se fait par une requête WHOIS, accessible gratuitement en ligne. Trois rôles distincts apparaissent, et la confusion entre eux est à l'origine de la plupart des mauvaises surprises.
Le titulaire (owner, ou registrant) est le propriétaire juridique. C'est lui, et lui seul, qui peut décider de transférer, vendre ou laisser expirer le domaine. Le contact administratif gère le domaine au quotidien mais n'en est pas propriétaire. Le bureau d'enregistrement (registrar) est l'intermédiaire technique auprès duquel le domaine est déposé.
Pour les extensions en .fr, l'AFNIC impose que le titulaire soit identifiable et rattaché à l'Union européenne. Elle propose surtout une procédure de résolution des litiges, ce qui constitue un avantage réel par rapport à certaines extensions génériques.
Un domaine déposé au nom du prestataire est la faille la plus grave possible. Concrètement, cela signifie que l'entreprise loue son adresse. Elle peut être coupée du jour au lendemain, sans préavis, sans recours immédiat. Et si le prestataire disparaît sans transférer, la récupération devient un dossier de plusieurs mois.
L'hébergement et les fichiers du site
Identifier l'hébergeur réel demande un peu de méthode. Les enregistrements DNS et l'adresse IP du site donnent une première piste, mais attention : elle peut être trompeuse.
Pourquoi ? Parce que beaucoup d'agences travaillent en revendeur white label. Elles achètent de la capacité chez un hébergeur, la revendent sous leur propre marque, et le client ne voit jamais le nom du fournisseur final. L'entreprise croit héberger chez son agence, alors qu'elle est en réalité sur un mutualisé chez un grand hébergeur, dans un compte partagé avec quarante autres sites.
Cette configuration a une conséquence lourde : si le compte revendeur est résilié pour impayés, tous les sites tombent en même temps. Et le client n'a aucun lien contractuel direct avec l'hébergeur qui coupe le service.
Trois accès à réclamer et à tester : le panneau de gestion de l'hébergement, les identifiants FTP ou SFTP, et l'accès à la base de données. Les tester, oui. Un identifiant communiqué mais non fonctionnel n'a strictement aucune valeur.
Les accès au CMS et aux outils de production
Le compte administrateur du CMS constitue le minimum absolu. Pas un compte éditeur, pas un compte auteur : un compte administrateur, avec la capacité de gérer les utilisateurs et les extensions.
Ensuite viennent les licences. Thèmes premium, extensions payantes, outils de sécurité, solutions de sauvegarde : au nom de qui ont-elles été achetées ? Si elles sont rattachées au compte du prestataire, elles cessent d'être mises à jour dès la rupture. Un thème non mis à jour pendant deux ans devient une porte d'entrée pour n'importe quelle faille connue.
Sur les projets plus élaborés, il faut aussi penser au dépôt Git (où est-il, qui y a accès ?) et aux environnements de préproduction, qui traînent parfois en ligne, indexés, avec une copie complète du site et de sa base.
Les comptes Google et les données de mesure
Voilà le domaine où les pertes sont les plus définitives, et paradoxalement celui qu'on inventorie en dernier.
Cinq comptes à vérifier : Google Search Console, Google Analytics 4, Google Business Profile, Google Ads et Google Tag Manager.
Pour chacun, une seule question compte vraiment : qui est propriétaire du compte, et non qui y a simplement accès ? Un utilisateur, même avec des droits étendus, peut être retiré en trois clics par le propriétaire. Le propriétaire, lui, garde la main quoi qu'il arrive.
Ce point mérite qu'on s'y arrête, parce qu'il est régulièrement mal compris. Beaucoup d'entreprises se croient propriétaires de leur Analytics parce qu'elles s'y connectent tous les jours. Elles y sont invitées, nuance considérable.
Et il faut être direct sur un point : les données historiques ne se reconstituent pas. Perdre un compte Analytics avec quatre ans d'historique, c'est perdre quatre ans de saisonnalité, de comparaisons annuelles, de suivi de conversions. Aucun outil ne les recrée. On repart de zéro, avec un compteur à zéro et aucun point de comparaison pour juger de la performance des mois à venir.
Les actifs annexes que l'on oublie systématiquement
La liste est longue, et chaque élément a déjà causé sa part de sueurs froides.
La messagerie professionnelle et ses enregistrements MX, d'abord, dont dépend toute la communication commerciale. Les certificats SSL et leur mode de renouvellement. Les comptes de réseaux sociaux et les pages entreprise, souvent créés depuis le compte personnel d'un salarié du prestataire.
Puis l'outil d'emailing et sa base d'abonnés, qui représente parfois le premier canal de chiffre d'affaires. Le CRM et ses données commerciales. Les connecteurs de paiement pour les sites marchands. Les comptes publicitaires tiers, sur les plateformes sociales notamment.
Enfin, un oubli quasi universel : les fichiers sources des visuels et du logo. Pas les JPEG affichés sur le site, non. Les fichiers vectoriels d'origine, ceux qui permettent de décliner une identité sur un camion, une enseigne ou un catalogue. Combien d'entreprises se retrouvent à faire redessiner leur propre logo faute de pouvoir en récupérer la source ? Beaucoup plus qu'on ne le croit.
Étape 2 : sécuriser l'urgent avant d'engager le dialogue
Un principe gouverne cette étape, et il ne souffre aucune exception : préserver d'abord ce qui est irrécupérable, discuter ensuite.
La raison est simple. Une demande formelle, aussi courtoise soit-elle, signale au prestataire que la relation touche à sa fin. Dans une situation tendue, cela peut déclencher une réaction défensive, voire une suppression de données. Mieux vaut avoir tout sauvegardé avant.
Sauvegarder ce qui peut disparaître du jour au lendemain
Si les accès serveur fonctionnent encore, il faut télécharger l'intégralité des fichiers et exporter la base de données. Pas une sauvegarde partielle : tout, y compris le dossier des médias, généralement le plus volumineux et le plus difficile à reconstituer.
Côté données de mesure, exporter tout ce qui peut l'être depuis Search Console (requêtes, pages, positions, sur la période la plus large disponible) et depuis Analytics (audience, acquisition, conversions, mois par mois). Ces exports en tableur ne remplaceront jamais l'accès aux comptes, mais ils permettent de conserver une trace des performances passées, ce qui vaut infiniment mieux que rien.
La base clients et la liste d'abonnés méritent un traitement à part. Elles constituent un actif commercial direct, et leur export est en général possible en quelques clics depuis l'outil d'emailing ou le CRM.
Si aucun accès serveur n'est disponible, il reste la capture des contenus depuis le site public : textes, images, structure des pages. Fastidieux, mais toujours préférable à une page blanche.
Dernier point, souvent négligé sur le moment et déterminant plus tard : rassembler et classer les factures, devis, contrats et échanges par mail. Ces pièces constitueront le dossier de preuve en cas d'escalade juridique. Une conversation supprimée ne se retrouve pas.
Reprendre la main sur les identifiants encore accessibles
Une fois les sauvegardes en sécurité, place au verrouillage.
Changer les mots de passe de tous les comptes accessibles. Retirer les accès devenus superflus, en commençant par ceux d'anciens collaborateurs du prestataire. Activer la double authentification partout où elle est proposée, avec un numéro de téléphone et une adresse mail contrôlés par l'entreprise.
Ce dernier point est capital et régulièrement bâclé. Vérifier les adresses de récupération de chaque compte. Il arrive souvent qu'un compte soit techniquement au nom de l'entreprise, mais que son adresse de récupération pointe vers la boîte mail du prestataire. Résultat : celui-ci peut réinitialiser le mot de passe à tout moment. La propriété est théorique, le contrôle réel est ailleurs.
Ce qu'il ne faut surtout pas faire dans la précipitation
La colère est mauvaise conseillère, et certaines décisions prises à chaud coûtent très cher.
Couper l'hébergement avant d'avoir migré. Le site disparaît, les mails aussi, et la reconstruction se fait alors sans matériau de départ. Le nouvel hébergement doit être prêt et testé avant de résilier l'ancien.
Laisser expirer le nom de domaine. Par principe, parfois : « je ne paie plus rien à ce prestataire ». Sauf que le domaine part en rédemption, puis peut être racheté par un tiers, parfois par un concurrent, parfois par un revendeur spécialisé qui le proposera à un prix sans rapport avec sa valeur d'origine. Un renouvellement coûte quelques dizaines d'euros. Une récupération après expiration, un multiple à trois chiffres, et parfois rien du tout.
Supprimer un compte Google pour « repartir sur des bases saines ». Cette idée revient régulièrement, avec les meilleures intentions. Elle efface l'historique de manière irréversible. Un compte encombré vaut toujours mieux qu'un compte vide.
Lancer une refonte immédiate. C'est la tentation la plus forte : puisque tout est cassé, autant tout refaire. Mais une refonte menée sans plan de redirections, sans cartographie des URL existantes et sans relevé des positions actuelles peut faire perdre l'essentiel du trafic organique. Une entreprise qui capte plusieurs milliers de visiteurs mensuels via Google et qui refait son site sans précaution peut voir cette audience fondre en quelques semaines. La reconquête, elle, prend des mois. Parfois davantage.
Étape 3 : demander formellement la restitution
Sauvegardes faites, comptes verrouillés : le moment est venu d'écrire. Et il faut le dire clairement, parce que cela évite bien des angoisses inutiles : la grande majorité de ces situations se règle sans le moindre contentieux. Une demande précise, datée et professionnelle suffit dans la plupart des cas.
Relire le contrat avant d'écrire
Étape préalable indispensable, et souvent expédiée. Quatre points à chercher dans les documents contractuels.
La clause de propriété intellectuelle et la cession des droits sur les livrables. Sans cession explicite, un développeur reste titulaire des droits sur le code spécifique qu'il a écrit. Sur un site standard, l'impact reste limité. Sur une application métier développée sur mesure, il devient considérable.
La clause de réversibilité, qui organise la fin de la relation : quels éléments sont restitués, sous quel format, dans quel délai. Quand elle existe, elle règle le dossier à elle seule. Elle est malheureusement rare dans les contrats des petites structures.
Les conditions de résiliation et le préavis applicable, à respecter scrupuleusement pour ne pas se retrouver en position de faute.
Le sort des livrables en fin de contrat, notamment les sauvegardes et la documentation.
Et si aucun contrat écrit n'existe ? Cas de figure extrêmement fréquent, en particulier avec les prestataires indépendants et les relations nouées de longue date. La situation n'est pas désespérée pour autant. Les devis acceptés, les factures acquittées et les échanges par mail constituent un faisceau contractuel opposable. Le droit commun s'applique, et le prestataire qui a été payé pour livrer un site ne peut raisonnablement en retenir les accès.
Rédiger une demande de restitution efficace
Un bon courrier de restitution tient en une page et suit une structure simple.
Il commence par un rappel factuel de la relation : date de début, nature des prestations, références des factures acquittées. Aucun jugement, aucun reproche à ce stade. Des faits.
Il se poursuit par la liste précise et exhaustive des accès demandés. C'est le cœur du courrier, et c'est là que l'inventaire de l'étape 1 prend toute sa valeur. Une demande floue (« merci de me transmettre les accès au site ») autorise une réponse tout aussi floue. Une liste nominative (registrar et code de transfert du domaine, panneau d'hébergement, FTP, base de données, administrateur CMS, propriété Search Console, propriété Analytics, gestionnaire du Business Profile, licences, zone DNS) ne laisse aucune marge d'interprétation.
Il précise ensuite le format attendu des livrables : archive complète des fichiers, export SQL de la base, documentation des services tiers utilisés.
Il fixe un délai raisonnable. Quinze jours constituent un standard acceptable. Trop court, le délai paraît agressif ; trop long, il n'incite à rien.
Il indique enfin un canal de transmission sécurisé. Des identifiants ne s'envoient pas en clair dans un mail. Un gestionnaire de mots de passe partagé ou un lien sécurisé à expiration font parfaitement l'affaire.
Le ton reste factuel, daté, professionnel. Un courrier agressif obtient rarement mieux qu'un courrier neutre, et il se retourne contre son auteur si le dossier devient contentieux.
Escalade progressive
Sans réponse, l'escalade se fait par paliers, jamais d'un bloc.
D'abord une relance écrite à l'échéance du délai, brève, rappelant la demande initiale. Ensuite un courrier recommandé avec accusé de réception, qui donne une date certaine et prouve la réception. Puis une mise en demeure, formulée avec un nouveau délai et la mention explicite des suites envisagées.
Au-delà, plusieurs voies existent. Un avocat spécialisé en droit du numérique devient pertinent dès que l'enjeu dépasse quelques milliers d'euros ou qu'un actif stratégique est bloqué. Le médiateur des entreprises propose une médiation gratuite et confidentielle, souvent efficace pour débloquer une situation sans passer par le tribunal. La procédure d'injonction de faire, enfin, permet d'obtenir judiciairement l'exécution d'une obligation, ici la remise des accès.
Cas particulier à connaître : le prestataire en liquidation judiciaire. Il ne faut alors plus s'adresser à lui, mais au mandataire ou liquidateur désigné. Celui-ci gère la restitution des actifs appartenant aux clients. La démarche est administrative, souvent lente, mais elle aboutit. Il est important de se manifester rapidement, avec un dossier complet, avant que les serveurs ne soient résiliés dans le cadre de la liquidation.
Le levier RGPD, souvent sous-estimé
Voilà un angle que peu d'entreprises pensent à mobiliser, alors qu'il est parfois le plus efficace.
Le raisonnement est le suivant. L'entreprise qui collecte des données via son site (formulaires, comptes clients, newsletter) est responsable de traitement. Le prestataire qui héberge, développe ou maintient le site pour son compte est sous-traitant au sens de l'article 28 du RGPD.
Or ce même article prévoit qu'en fin de prestation, le sous-traitant doit, au choix du responsable de traitement, restituer ou supprimer l'ensemble des données personnelles traitées. Ce n'est pas une faculté négociable : c'est une obligation réglementaire.
En pratique, mentionner cette obligation dans une mise en demeure change souvent le ton de la conversation. Le prestataire qui pensait tenir un moyen de pression découvre qu'il détient surtout une responsabilité, avec une autorité de contrôle en face, la CNIL, qui peut être saisie par simple plainte en ligne.
Il faut cependant être précis sur la portée de ce levier, sous peine de déception. Le RGPD couvre les données personnelles : base clients, comptes utilisateurs, contacts, adresses email. Il ne couvre ni le code source, ni les visuels, ni le nom de domaine, ni les contenus rédactionnels. Ces éléments relèvent du contrat et de la propriété intellectuelle.
Le levier est donc partiel. Mais sur une base clients de plusieurs milliers de contacts, il est décisif.
Étape 4 : les procédures de récupération, actif par actif
Reste la question que tout le monde pose, et qui mérite une réponse concrète : et si le prestataire ne coopère pas du tout ?
Bonne nouvelle, chaque actif dispose d'une procédure de récupération autonome, indépendante de la bonne volonté du prestataire. Elles sont plus ou moins longues, plus ou moins coûteuses, mais elles existent.
Récupérer un nom de domaine sans la coopération du prestataire
Si l'entreprise est titulaire du domaine mais n'a pas accès au compte du bureau d'enregistrement, la voie est relativement simple : il suffit de contacter directement le registrar, justificatifs à l'appui, pour reprendre la main sur le compte. Les registrars sérieux disposent d'une procédure dédiée. Le transfert vers un autre bureau d'enregistrement se fait ensuite via un code de transfert (auth code, ou code de transfert pour les .fr).
Si le prestataire est titulaire, en revanche, l'affaire se complique. Il faut engager une procédure de changement de titulaire, qui exige normalement son accord. En cas de refus, deux voies d'arbitrage.
Pour les extensions en .fr, l'AFNIC propose la procédure Syreli. Elle est payante, mais son coût reste sans commune mesure avec une action judiciaire, et le délai de traitement se compte en semaines. Pour les extensions génériques (.com, .net, .org), la procédure UDRP joue un rôle équivalent au niveau international.
Dans les deux cas, il faut constituer un dossier de preuves solide : extrait Kbis établissant l'identité de l'entreprise, marque déposée si elle existe, preuves d'antériorité d'usage du nom (documents commerciaux, captures du site, mentions dans la presse), factures démontrant que l'entreprise a financé le domaine et son renouvellement.
Un point à souligner : ces procédures reposent sur la démonstration d'un droit sur le nom. Une entreprise dont la dénomination sociale correspond au domaine part avec un dossier très favorable. Une marque commerciale distincte de la raison sociale, non déposée à l'INPI, rend le dossier nettement plus incertain. C'est un argument de plus en faveur du dépôt de marque, au-delà des seules considérations juridiques classiques.
Reprendre le contrôle des comptes Google
Chaque service Google a sa logique propre, et les issues sont très inégales.
Le Google Business Profile dispose d'une procédure de revendication de propriété. L'entreprise demande l'accès, le gestionnaire actuel reçoit une notification et dispose d'un délai pour répondre. Sans réponse de sa part, l'accès est généralement transféré. C'est, en pratique, l'une des récupérations les plus accessibles.
La Search Console est encore plus simple, et c'est une excellente nouvelle. Une propriété se valide par un enregistrement DNS ou un fichier déposé sur le serveur. Dès lors que l'entreprise contrôle sa zone DNS, elle peut créer sa propre propriété et devenir propriétaire vérifié, sans rien demander à personne. Seule limite : l'historique affiché démarre à la date de validation. D'où l'intérêt d'avoir exporté les données en amont.
Google Analytics 4 pose le vrai problème. Sans compte propriétaire, il n'existe aucune procédure de revendication comparable. Le support Google peut être sollicité, mais les chances d'aboutir sont modestes. Dans la plupart des cas, il faut arbitrer : créer une nouvelle propriété et accepter de repartir de zéro, en s'appuyant sur les exports réalisés pour conserver un minimum de comparaison historique. Décision frustrante, mais souvent plus rationnelle que six mois d'échanges avec un support qui ne tranchera pas.
Google Ads peut faire l'objet d'un transfert de compte entre gestionnaires. Attention à un aspect généralement ignoré : l'historique d'apprentissage des campagnes constitue une valeur en soi. Repartir sur un compte neuf, c'est relancer la phase d'apprentissage des algorithmes d'enchères, avec un coût par acquisition dégradé pendant plusieurs semaines. Le transfert du compte existant est donc à privilégier chaque fois qu'il est possible.
Reconstruire un site sans les fichiers d'origine
Situation extrême, mais pas rare : le site est en ligne, personne n'a d'accès serveur, et le prestataire est injoignable.
Ce qui reste récupérable : les contenus publics, via un crawl complet du site avec un outil dédié. Le sitemap XML, qui donne la liste exhaustive des URL. Le cache des moteurs de recherche, pour les pages récemment supprimées. Les archives du web, qui conservent parfois des versions anciennes, y compris de pages depuis longtemps disparues. Et si un accès administrateur au CMS subsiste, un export natif des contenus, souvent suffisant pour repartir.
Ce qui est définitivement perdu : les développements spécifiques et le code sur mesure, les configurations d'extensions, les données non publiques (commandes, comptes clients, historiques d'achat), les fichiers sources des visuels.
Se pose alors un arbitrage honnête : reconstruire à l'identique ou assumer une refonte ?
La reconstruction à l'identique protège le référencement, puisque les URL et les contenus restent stables. Elle a du sens quand le site performait bien. La refonte assumée se justifie quand le site était déjà vieillissant ou mal structuré, à condition de conserver l'arborescence des URL performantes et de bâtir un plan de redirections rigoureux pour les autres. Dans les deux cas, c'est la préservation des URL qui fait la différence, pas le fait de reprendre ou non le design.
Reprendre la main sur la messagerie et les DNS
Le chantier le plus délicat, parce que c'est celui qui peut interrompre l'activité commerciale.
La zone DNS se récupère avec le nom de domaine : celui qui contrôle le compte du registrar contrôle les serveurs de noms. Une fois cette main reprise, il faut recréer l'ensemble des enregistrements.
Les enregistrements MX orientent les mails entrants. Les enregistrements SPF, DKIM et DMARC authentifient les mails sortants et conditionnent leur délivrabilité. Négliger ces trois derniers, c'est voir ses mails atterrir massivement en indésirables, avec un délai avant que quiconque ne s'en aperçoive.
Le risque principal, c'est la coupure de messagerie pendant la bascule. Quelques précautions le réduisent nettement : relever l'intégralité de la configuration existante avant toute modification, abaisser le TTL des enregistrements plusieurs jours à l'avance pour accélérer la propagation, créer les boîtes sur le nouveau serveur avant de basculer les MX, et maintenir l'ancienne messagerie active pendant quelques jours pour récupérer les mails arrivés en retard.
Un conseil pratique : basculer un vendredi soir ou pendant une période creuse. Une heure de coupure un dimanche matin passe inaperçue. La même coupure un mardi à 10 h, beaucoup moins.
Étape 5 : migrer sans sacrifier votre référencement
Voilà le point qui distingue une reprise en main réussie d'un désastre différé. Une migration mal exécutée coûte régulièrement plus cher que la défaillance initiale, parce que la perte de trafic organique se traduit directement en chiffre d'affaires, et qu'elle met des mois à se corriger.
Un exemple qui revient souvent : une entreprise récupère son site chez un prestataire défaillant, le fait remonter en urgence chez un nouvel hébergeur, et découvre six semaines plus tard que son trafic a été divisé par trois. Cause identifiée après coup : un fichier robots.txt de préproduction bloquant l'indexation, resté en place lors de la mise en ligne. Une ligne de texte, six semaines de trafic perdu.
Préparer la migration avant de toucher aux DNS
Rien ne se touche avant d'avoir photographié l'existant.
Un crawl complet du site permet de récupérer l'ensemble des URL, des titres, des balises meta et de la structure interne. Cette cartographie devient la référence de contrôle après migration.
Le relevé des positions actuelles sur les requêtes stratégiques constitue le point de comparaison. Sans lui, impossible de distinguer une baisse liée à la migration d'une fluctuation naturelle des résultats de recherche.
La sauvegarde du profil de liens (les sites externes qui pointent vers le site) identifie les pages à protéger absolument. Une page qui a accumulé des liens de qualité pendant dix ans ne se remplace pas : elle se redirige, ou elle se conserve à l'identique.
Enfin, un relevé des performances de référence (trafic, pages vues, conversions sur les trois derniers mois) sert de juge de paix pour les semaines suivantes.
Les points de vigilance techniques
Le plan de redirections 301 est la pièce maîtresse. Chaque ancienne URL doit pointer vers son équivalent le plus proche. Pas vers la page d'accueil : vers l'équivalent réel. Une redirection massive vers l'accueil est traitée comme une page introuvable et perd tout le bénéfice accumulé.
La conservation des URL reste la meilleure stratégie quand elle est possible. Pas de redirection, pas de perte, pas de risque. On ne change une URL que si l'on a une raison sérieuse de le faire.
Les balises canoniques doivent être vérifiées après migration. Une canonique pointant encore vers l'ancien domaine, et l'ensemble du travail est annulé.
Le robots.txt et les directives d'indexation méritent une double vérification. C'est l'erreur la plus fréquente et la plus coûteuse. Un environnement de préproduction est légitimement bloqué à l'indexation ; ce blocage ne doit jamais survivre à la mise en production.
Le sitemap XML doit être régénéré et soumis à la Search Console dès la mise en ligne, pour accélérer la découverte des pages.
La propagation DNS demande de la patience : de quelques heures à quarante-huit heures selon les configurations. Abaisser le TTL plusieurs jours en amont réduit considérablement ce délai. C'est une précaution gratuite, et pourtant systématiquement oubliée.
La continuité HTTPS, enfin. Le certificat SSL doit être actif dès la première seconde sur le nouvel hébergement. Un site en HTTP, même quelques heures, déclenche des avertissements navigateur qui font fuir les visiteurs.
Surveiller les semaines qui suivent
La migration ne s'arrête pas à la mise en ligne. Elle se surveille.
Les erreurs d'exploration remontées par la Search Console sont le premier indicateur : elles révèlent les URL non redirigées et les pages devenues inaccessibles. La courbe d'indexation montre si les nouvelles pages sont bien prises en compte. Les positions sur les requêtes de référence signalent tout décrochage anormal.
Une précision qui évite bien des paniques : une fluctuation dans les deux à quatre semaines suivant une migration est normale. Les moteurs doivent réexplorer l'ensemble du site, comprendre les redirections et réévaluer les pages. Une baisse temporaire de dix à vingt pour cent du trafic organique pendant cette phase n'a rien d'alarmant.
Quand faut-il vraiment s'inquiéter ? Trois cas de figure. Une chute brutale supérieure à cinquante pour cent dès les premiers jours, qui signale un problème technique franc. Une absence de retour à la normale au-delà de six à huit semaines. Ou des pages stratégiques qui disparaissent purement et simplement de l'index.
Dans ces trois situations, un diagnostic technique s'impose sans attendre. Plus l'anomalie est corrigée tôt, plus la récupération est rapide.
Ne plus jamais se retrouver dans cette situation
Une reprise en main réussie, c'est bien. Ne jamais avoir à en refaire une, c'est mieux. Et cela tient à quelques règles simples, à poser dès le premier jour d'une relation avec un prestataire.
Les règles de propriété à poser dès le premier jour
Quatre principes, non négociables.
Le nom de domaine et l'hébergement sont toujours souscrits au nom de l'entreprise, avec sa carte bancaire et son adresse mail. Le prestataire y accède, il n'en est jamais titulaire. Cette règle unique élimine à elle seule la majorité des situations de blocage.
Les comptes Google sont créés par l'entreprise, depuis une adresse professionnelle contrôlée en interne, puis délégués au prestataire avec les droits nécessaires. Jamais l'inverse.
Les accès administrateur restent conservés en interne. Le prestataire dispose de ses propres identifiants, distincts, révocables à tout moment.
Les licences sont achetées au nom de la société. Thèmes, extensions, outils : facturés à l'entreprise, rattachés à ses comptes.
Les clauses à exiger dans un contrat de prestation
Cinq clauses transforment un contrat standard en contrat protecteur.
La cession des droits sur les livrables, explicite, couvrant le code, les visuels et les contenus produits. Sans elle, le prestataire conserve ses droits d'auteur.
La clause de réversibilité, avec délai chiffré et format précisé. Par exemple : restitution sous quinze jours de l'archive complète des fichiers, de l'export SQL de la base et de la liste documentée des accès.
La documentation technique livrable, décrivant l'architecture, les services tiers utilisés et les procédures de maintenance.
Les conditions de sortie, précisant le préavis, les modalités et le sort des prestations en cours.
Les sauvegardes accessibles au client, avec une fréquence définie et un accès direct, sans passer par le prestataire.
Un prestataire sérieux acceptera ces clauses sans discussion. Elles ne le contraignent en rien s'il travaille correctement. Une résistance sur ce terrain constitue en soi un signal, et probablement le plus fiable de tous.
Mettre en place un registre des accès
La gouvernance interne compte autant que le contrat.
Un coffre-fort de mots de passe partagé centralise les identifiants dans un outil chiffré, accessible à plusieurs personnes de l'entreprise. Les mots de passe dans un tableur, sur un post-it ou dans la tête d'une seule personne : c'est un risque, au même titre que l'absence de sauvegarde.
Un référent interne désigné, même non technique, sait où se trouvent les accès et qui contacter. Ce rôle n'exige aucune compétence particulière, juste une organisation.
Une revue trimestrielle des accès, un quart d'heure dans l'agenda, permet de vérifier qui accède à quoi et de retirer les comptes obsolètes. C'est peu coûteux et remarquablement efficace.
Une procédure de sortie de prestataire, formalisée à l'avance : liste des accès à révoquer, éléments à récupérer, contrôles à effectuer. Rédigée à froid, elle s'applique sereinement le jour venu.
Des sauvegardes indépendantes de l'hébergeur, enfin. Une sauvegarde stockée sur le serveur qu'elle est censée protéger n'est pas une sauvegarde. Une copie externe, même mensuelle, change tout.
Le bon niveau de dépendance à un prestataire
Un mot pour finir cette section, parce que le sujet peut conduire à des réactions excessives.
La formule tient en une phrase : déléguer l'exécution sans déléguer la propriété. Une entreprise n'a aucune raison de gérer elle-même son hébergement, d'écrire son code ou de piloter ses campagnes. Ce sont des métiers, et faire appel à des spécialistes est parfaitement rationnel.
Ce qui ne se délègue pas, c'est la propriété des actifs et la connaissance de leur emplacement.
Un point de nuance mérite d'être posé, car la défiance systématique est un mauvais réflexe. La quasi-totalité des prestataires sont honnêtes et compétents. La plupart des situations décrites dans cet article ne résultent pas de mauvaise foi, mais de négligence : un domaine déposé à la va-vite sur le compte de l'agence lors du lancement, un compte Analytics créé avec l'adresse du développeur parce que c'était plus rapide, une documentation jamais rédigée faute de temps. Rien de malveillant. Simplement des raccourcis qui deviennent des impasses le jour où la relation s'arrête.
La solution n'est donc pas la méfiance, mais la traçabilité. Savoir qui détient quoi, l'écrire quelque part, et le vérifier de temps en temps. Cela prend quelques heures par an et évite des mois de complications.
Ce qu'il faut retenir
La logique d'ensemble tient en six mouvements : inventorier ce qu'on possède, sécuriser ce qui peut disparaître, demander formellement la restitution, récupérer actif par actif ce qui n'est pas rendu, migrer sans casser le référencement, et poser les règles pour que la situation ne se reproduise jamais.
La leçon de fond, elle, dépasse largement la technique. La propriété des actifs numériques est un sujet de direction générale, pas un sujet de service informatique. Un nom de domaine, une base clients, un historique de mesure : ce sont des éléments du patrimoine de l'entreprise, avec une valeur économique réelle. Ils méritent la même attention qu'un bail commercial ou qu'un contrat d'assurance. Personne ne signerait un bail sans en conserver une copie. Pourquoi accepter de ne pas savoir qui détient le nom de domaine sur lequel repose l'intégralité de la présence en ligne ?
Reste que dans le feu de l'action, avec une activité à faire tourner, ces vérifications passent après. C'est humain, et c'est précisément pour cela qu'un regard extérieur a de la valeur.
Trois interventions répondent aux situations décrites ici : l'audit de propriété des actifs numériques, qui établit en quelques jours qui détient quoi et où sont les failles ; la reprise en main technique, incluant la récupération des accès et la migration ; et le rattrapage du référencement après une migration mal conduite, chantier plus fréquent qu'on ne l'imagine.
Si la lecture de cet article a fait naître un doute sur un point précis, un domaine dont le titulaire n'est pas certain, un compte Analytics dont personne ne connaît le propriétaire, il vaut mieux le lever maintenant. Une vérification prend une heure. Une récupération en prend beaucoup plus.
