Pourquoi le sujet est traité trop tard, presque toujours
Il y a une constante dans les dossiers de reprise de site : personne n'appelle avant. On appelle après. Après la lettre de résiliation, après le mail sec envoyé un vendredi soir, après le silence radio du prestataire sortant. Et là, la conversation commence toujours par la même phrase : « on a un souci, on n'arrive plus à accéder à... »
Ce n'est pas de la négligence. C'est simplement que la question de la sortie ne se pose jamais au moment de l'entrée. On signe pour construire quelque chose, pas pour organiser la séparation. Sauf que dans le numérique, la sortie se prépare dès le premier jour, ou elle ne se prépare pas du tout.
Le moment où l'on pense à la réversibilité est déjà le mauvais moment
Un contrat qui se termine bien, ça existe. C'est même la majorité des cas. Mais la minorité qui se passe mal coûte très cher, et elle coûte cher précisément parce que le rapport de force s'inverse au moment de la rupture.
Tant que la relation est bonne, obtenir un export de base de données prend dix minutes. Une fois la résiliation notifiée, le même export devient une prestation à devis, ou une demande qui reste sans réponse pendant trois semaines. Rien d'illégal là-dedans, dans bien des cas. Juste un contrat qui ne prévoyait rien.
Le bon moment pour parler réversibilité, c'est donc quand tout va bien. Quand on n'en a aucun besoin. C'est contre-intuitif, et c'est exactement pour cette raison que ça ne se fait presque jamais.
Ce que l'on croit posséder et ce que l'on possède réellement
Voici un exercice qui décoiffe. Prenez une feuille, listez ce que vous pensez posséder : le nom de domaine, le site, les adresses mail, le compte Analytics, la fiche Google, le compte publicitaire. Puis, en face de chaque ligne, écrivez le nom exact de l'entité titulaire.
Dans la plupart des PME, la moitié des lignes reste vide. Un tiers porte le nom du prestataire.
Le cas classique : un nom de domaine déposé « pour vous rendre service » au démarrage, avec la carte bancaire de l'agence, et qui n'a jamais été retransféré. Le domaine fonctionne parfaitement, il vous appartient dans les faits d'usage, mais au registre il appartient à quelqu'un d'autre. Tant que la relation tient, personne ne le remarque.
Autre cas, plus insidieux encore : la propriété Search Console. Vous y avez accès, vous voyez vos données, tout va bien. Sauf que vous êtes utilisateur délégué sur une propriété créée et détenue par un tiers. Le jour où l'accès est retiré, ce ne sont pas les données du mois qui disparaissent, c'est l'historique complet.
Le coût réel d'une migration mal préparée : délai, perte de trafic, perte d'historique
Le coût visible, c'est le temps. Une reprise préparée se boucle en deux à trois semaines. Une reprise à l'aveugle, avec reconstitution des accès un par un, s'étale sur deux à trois mois. Multipliez par un taux journalier, l'addition parle d'elle-même.
Le coût invisible est plus douloureux. Un site remis en ligne sans son plan de redirections perd mécaniquement une partie de sa visibilité acquise, parfois construite sur des années. Les URLs changent, les liens externes pointent dans le vide, les pages positionnées disparaissent des résultats. On récupère, souvent. Mais ça prend des mois, et une partie ne revient jamais.
Et puis il y a la perte d'historique de mesure. Repartir d'une propriété Search Console vierge, c'est effacer trois ans de données de requêtes. Rien ne casse, le site tourne. Mais vous devenez aveugle sur votre propre passé, et toute analyse comparative devient impossible pendant seize mois, le temps que l'historique se reconstitue.
Cartographier ce qui est en jeu avant toute décision
Avant de résilier quoi que ce soit, avant même d'en parler, il faut savoir de quoi on parle. Un inventaire. Fastidieux, oui. Mais c'est le seul document qui transforme une reprise anxiogène en simple opération technique.
Inventaire des actifs numériques : noms de domaine, hébergement, code, base de données, médias
On commence par le concret. Tous les noms de domaine, y compris ceux que vous avez oubliés : les variantes orthographiques déposées défensivement, les extensions achetées « au cas où », les domaines d'anciennes campagnes qui redirigent encore vers le site principal.
Ensuite l'hébergement, avec un détail qui compte : chez qui, sur quelle offre, avec quelles sauvegardes incluses. Puis le code source, la base de données, la médiathèque. Photos produits, visuels de campagne, vidéos, documents PDF téléchargeables.
Un point souvent oublié : les fichiers sources. Le logo en PNG posé sur le site ne vaut pas grand-chose. Le fichier vectoriel modifiable, lui, vaut beaucoup. Même chose pour les photos retouchées dont vous n'avez que la version compressée en 800 pixels de large.
Inventaire des accès : registrar, hébergeur, CMS, DNS, messagerie, CDN, certificats
Pour chaque service, trois colonnes : l'URL de connexion, l'identifiant, et surtout l'adresse mail associée au compte. Cette troisième colonne est celle qui pose problème.
Parce que si le compte registrar est rattaché à une adresse en @nomdelagence.fr, vous ne pourrez jamais effectuer une réinitialisation de mot de passe sans passer par eux. Vous êtes techniquement dépendant, même en connaissant le mot de passe actuel.
Ajoutez à la liste tout ce qui gravite autour et qu'on oublie systématiquement : le CDN, le service d'envoi de mails transactionnels, l'outil de formulaires, le prestataire de certificats SSL s'il n'est pas automatisé, le service de sauvegarde externalisée.
Inventaire des données de mesure : Analytics, Search Console, Tag Manager, régies publicitaires, outils SEO
Ces comptes-là ont une particularité redoutable : ils contiennent de l'historique, et l'historique ne se reconstitue pas.
Analytics, Search Console, Tag Manager forment le trio de base. Ajoutez les comptes publicitaires, le Business Manager si vous êtes présent sur les réseaux sociaux, et les éventuels abonnements à des outils de suivi de positions.
Pour chacun, une seule question : êtes-vous propriétaire ou simplement invité ? La différence ne saute pas aux yeux dans l'interface. Elle saute aux yeux le jour où l'invitation est révoquée.
Inventaire des contenus et de la production : rédactionnel, visuels, licences d'images, polices
Les textes du site vous appartiennent-ils ? La réponse dépend entièrement de ce que dit le contrat, et le silence du contrat ne joue pas en votre faveur.
Les images posent une question distincte, souvent ignorée. Une photo issue d'une banque d'images a été achetée sous licence, et cette licence est nominative. Si elle a été souscrite par l'agence, elle ne vous suit pas automatiquement. Le site continue de tourner, personne ne dit rien pendant des années, et puis un jour une mise en demeure arrive.
Idem pour les polices de caractères. Une typographie sous licence commerciale, achetée pour un projet donné, n'est pas transférable par simple copie du fichier. Ce sont des détails, jusqu'à ce qu'ils cessent d'en être.
Identifier le titulaire juridique de chaque actif, ligne par ligne
Le travail se termine par une colonne unique et sans nuance : qui est le titulaire ? Pas « qui gère », pas « qui a la main », pas « qui s'en occupe ». Qui est inscrit comme propriétaire.
Cette colonne fait apparaître la carte réelle de votre dépendance. Elle est souvent inconfortable à lire. C'est précisément son utilité.
La réversibilité : une clause contractuelle, pas une bonne intention
« Bien sûr qu'on vous rendra tout, on n'est pas des voyous. » Cette phrase, sincère dans neuf cas sur dix, ne vaut rien juridiquement. Et dans le dixième cas, celui qui vous intéresse, elle ne vaut rien du tout.
Ce que le RGPD impose déjà : portabilité, restitution, suppression en fin de contrat
Le règlement européen offre un socle, à condition de comprendre son périmètre exact. Le droit à la portabilité, prévu à l'article 20, concerne les données personnelles que la personne concernée a fournies. Il s'applique aux personnes physiques : vos clients, vos prospects, vos abonnés.
Par ailleurs, l'article 28 encadre la relation entre responsable de traitement et sous-traitant. Il prévoit qu'au terme de la prestation, le sous-traitant restitue ou supprime les données personnelles selon votre choix. C'est une obligation réelle, opposable.
Voilà pour la bonne nouvelle. Elle a des limites.
Ce que le RGPD n'impose pas et qui doit figurer au contrat
Le RGPD protège les données personnelles. Il ne protège pas votre code, vos maquettes, vos textes, votre configuration serveur, votre arborescence de redirections ou vos historiques de mesure agrégés.
Autrement dit, il couvre peut-être vingt pour cent de ce qui compte dans une reprise de site. Le reste relève du contrat, et uniquement du contrat.
Ce qui explique cette situation absurde qu'on rencontre régulièrement : un prestataire parfaitement en règle sur le plan réglementaire, qui vous restitue proprement votre fichier clients, et qui n'a strictement aucune obligation de vous remettre le thème sur mesure développé pour votre site.
Les éléments d'une clause de réversibilité qui tient : format des livrables, délai, périmètre, assistance
Une bonne clause tient en quinze lignes et répond à quatre questions.
Quoi : la liste des livrables, énumérée, sans formule générale du type « l'ensemble des éléments du projet ». On nomme. Code source, base de données au format SQL, médias en résolution native, fichiers sources graphiques, documentation technique, table des redirections, liste des accès.
Sous quelle forme : des formats standards, lisibles sans l'outil du prestataire. Un export SQL plutôt qu'une sauvegarde propriétaire. Un fichier CSV plutôt qu'un dump binaire indéchiffrable.
Quand : un délai chiffré en jours ouvrés à compter de la demande. Quinze jours est raisonnable, trente devient long, « dans les meilleurs délais » ne veut rien dire.
À quelles conditions : la réversibilité est-elle comprise dans la prestation ou facturée en supplément ? Si elle est facturée, à quel tarif, plafonné à combien ? Une clause de réversibilité assortie d'un devis surprise à cinq chiffres n'est pas une clause de réversibilité.
Formats exploitables contre formats verrouillés : la question du standard ouvert
Recevoir ses données ne signifie pas pouvoir les utiliser. Nuance capitale.
Un export de base au format SQL standard se réimporte partout. Un export propriétaire d'un CMS maison, sans documentation de schéma, est une archive que vous possédez sans pouvoir l'ouvrir. Techniquement, l'obligation est remplie. Pratiquement, vous n'avez rien.
Le réflexe à avoir : demander que les livrables soient exploitables sans outil propriétaire du prestataire. Cette formulation, dans un contrat, vaut mieux qu'une longue liste technique qui sera de toute façon obsolète dans trois ans.
Le cas des solutions propriétaires et des CMS maison
Certaines agences développent leur propre système de gestion de contenu. L'argument commercial se tient : outil sur mesure, parfaitement adapté, personne d'autre ne fait ça.
Le revers est structurel. Vous pouvez récupérer vos textes et vos images, très bien. Mais vous ne pouvez pas récupérer le système qui les affiche, car il appartient à l'agence et sert aussi ses autres clients. Sortir signifie donc reconstruire.
Ce n'est pas nécessairement disqualifiant. C'est un facteur à intégrer dès le départ, dans le prix et dans la réflexion. Un CMS maison ajoute un coût de sortie qu'une solution répandue n'a pas. Autant le savoir avant de signer plutôt que de le découvrir cinq ans plus tard.
Négocier la réversibilité à la signature, pas à la rupture
À la signature, vous avez du poids : le contrat n'est pas signé. À la rupture, vous n'en avez plus aucun.
Et la manière dont un prestataire réagit à cette demande est en soi une information précieuse. Un professionnel solide répond « pas de problème, on a un modèle de clause » et vous l'envoie dans la journée. Une réaction agacée, ou un « c'est prématuré de parler de ça », mérite qu'on s'y attarde.
Sauvegarder avant d'annoncer : la séquence qui protège
L'ordre des opérations n'est pas un détail de méthode. C'est le cœur du sujet.
Pourquoi la sauvegarde précède la notification de résiliation
Tant que la relation est en cours, vos accès fonctionnent normalement. Vous pouvez exporter, télécharger, archiver, sans rien demander à personne.
Après la notification, plusieurs choses peuvent se produire, et pas nécessairement par malveillance. Un compte fermé automatiquement à la fin de facturation. Une équipe qui a réaffecté ses ressources sur d'autres dossiers. Un interlocuteur en congés au mauvais moment. Le résultat est identique : vous attendez.
Le principe est donc simple. On sauvegarde tout, on vérifie que les sauvegardes sont exploitables, et ensuite seulement on annonce. Ce n'est pas de la dissimulation, c'est de la prudence élémentaire, et n'importe quel prestataire sérieux comprend parfaitement cette logique s'il l'apprend après coup.
Sauvegarde complète du site : fichiers, base de données, médias, configuration serveur
Une sauvegarde complète, ce n'est pas un export du contenu depuis l'interface d'administration. C'est l'ensemble de l'arborescence de fichiers, plus la base de données, plus la configuration.
Concrètement : tous les fichiers via FTP ou SSH, un dump SQL complet incluant la structure et les données, la médiathèque en résolution d'origine, les fichiers de configuration serveur, et la liste des tâches planifiées, ces fameux crons qui font tourner des choses en arrière-plan sans que personne s'en souvienne.
Ce dernier point mérite attention. Une synchronisation de stock, un envoi automatique de relances, un import de catalogue nocturne : tout cela vit dans des tâches planifiées invisibles depuis l'interface. On les découvre après la migration, quand elles ne s'exécutent plus.
Exports de données métier : commandes, clients, formulaires, CRM, facturation
Le site n'est qu'une partie de l'histoire. Les données métier vivent souvent ailleurs, et parfois dans des endroits inattendus.
Historique de commandes, base clients, contenu des formulaires reçus, fiches CRM, factures émises. À exporter en CSV, format universel et pérenne, et non dans le format natif de l'outil.
Point de vigilance : les données de formulaires. Beaucoup de solutions n'archivent que quelques mois de soumissions. Si un formulaire de demande de devis alimente votre activité commerciale depuis deux ans, il y a de fortes chances que l'historique complet ne soit nulle part.
Archiver l'historique de mesure : exports Analytics, Search Console, positions, backlinks
C'est la partie qu'on oublie et qu'on regrette. Toujours.
Search Console conserve seize mois glissants. Au-delà, les données sont définitivement perdues, y compris pour vous. Un export régulier des requêtes, des pages et des performances est donc une assurance, indépendamment de toute question de prestataire.
Sur Analytics, un export des sessions, sources de trafic et conversions sur toute la période disponible. Sur vos outils de suivi de positions, un export de l'historique. Et si vous disposez d'un audit de backlinks, une copie de la liste des domaines référents.
Le format importe peu, CSV fait très bien l'affaire. Ce qui compte, c'est que ces fichiers existent quelque part chez vous, en dehors de tout outil dont l'accès peut être coupé.
Conserver les redirections, le fichier robots, les sitemaps, les balises canoniques
Voilà probablement le point le plus sous-estimé de toute cette liste, et celui dont l'oubli coûte le plus cher en trafic.
Un site qui a vécu accumule des redirections. Anciennes URLs de la version précédente, pages produits supprimées, restructurations de rubriques, changement de structure d'adresses. Ces règles vivent dans un fichier .htaccess, dans une configuration serveur ou dans une extension du CMS.
Elles sont invisibles. Elles ne figurent dans aucun tableau de bord. Et elles portent une part significative de la valeur acquise du site, parce que ce sont elles qui transmettent le bénéfice des liens accumulés au fil des années.
Les perdre lors d'une migration, c'est perdre d'un coup le travail de plusieurs refontes successives. Alors : copie intégrale du .htaccess, export de la table de redirections si elle est gérée par extension, sauvegarde du robots.txt et des sitemaps XML.
La règle 3-2-1 appliquée à un site professionnel
Trois copies des données, sur deux supports différents, dont une hors site. Le principe vient du monde de la sauvegarde informatique, il s'applique parfaitement ici.
En pratique : une copie sur un poste de travail, une sur un disque externe rangé ailleurs, une sur un stockage en ligne dont vous seul détenez les accès. Trois copies dans trois endroits qui ne peuvent pas disparaître ensemble.
Et le point crucial : aucune de ces copies ne doit dépendre d'un accès fourni par le prestataire. Une sauvegarde stockée sur l'espace client de l'agence n'est pas une sauvegarde. C'est un fichier chez quelqu'un d'autre.
Vérifier une sauvegarde : la restaurer ailleurs, sinon elle n'existe pas
Une archive de deux gigaoctets sur un disque dur, c'est rassurant. Ça ne prouve rien.
La seule vérification qui vaille consiste à restaurer la sauvegarde dans un environnement de test et à constater que le site se lance. Un hébergement mutualisé à quelques euros suffit largement.
Combien d'archives se révèlent inexploitables au moment où on en a besoin ? Plus qu'on ne l'imagine. Dump SQL tronqué, médiathèque incomplète, fichier de configuration manquant. Le problème n'est jamais dans l'existence de la sauvegarde, il est toujours dans sa complétude, et on ne le découvre qu'en essayant.
Reprendre la main sur les comptes : ordre d'opérations
L'inventaire est fait, les sauvegardes sont vérifiées. On peut passer à la reprise des accès. Là encore, l'ordre compte, parce que certains éléments en conditionnent d'autres.
Le nom de domaine d'abord : vérifier le titulaire au Whois, récupérer le code de transfert
Le nom de domaine est le socle. Sans lui, ni site ni mails. Il passe donc en premier.
Première étape, une consultation Whois. Elle vous indique le titulaire déclaré, le registrar, et la date d'expiration. C'est public et gratuit. Si le titulaire porte le nom de votre entreprise, l'essentiel est acquis. Sinon, il faut engager une procédure de changement de titulaire, ce qui suppose la coopération de la partie inscrite.
Deuxième étape, le code de transfert, aussi appelé auth code ou EPP. Ce code permet de déplacer le domaine vers un autre registrar. Sa communication est encadrée par les règles des registres, et notamment par celles de l'Afnic pour les .fr.
Troisième étape, souvent négligée : vérifier que le domaine n'est pas verrouillé et que la date d'expiration laisse de la marge. Transférer un domaine qui expire dans dix jours est une aventure qu'il vaut mieux éviter.
Les DNS : comprendre qui les héberge et pourquoi c'est le point de bascule critique
Le domaine et ses DNS sont deux choses distinctes, et cette distinction échappe à beaucoup de monde.
Le domaine, c'est le nom. Les DNS, c'est l'annuaire qui indique où pointe ce nom : quel serveur pour le site, quel serveur pour les mails, quelles vérifications pour les services tiers. Cet annuaire peut être hébergé chez le registrar, chez l'hébergeur, ou chez un service spécialisé.
Avant toute modification, exportez la zone DNS complète. Tous les enregistrements, sans exception, y compris ceux que vous ne comprenez pas. Ces enregistrements TXT énigmatiques valident souvent votre messagerie ou un service tiers, et leur disparition provoque des pannes difficiles à diagnostiquer.
Un conseil de méthode : ne changez jamais le domaine et les DNS dans la même opération. Un pas après l'autre, avec vérification entre les deux.
La messagerie professionnelle : le risque le plus sous-estimé
Un site indisponible quelques heures, c'est ennuyeux. Une messagerie coupée, c'est une entreprise à l'arrêt.
La messagerie dépend des enregistrements MX de la zone DNS. Une manipulation approximative pendant la bascule, et plus rien n'arrive. Pire : les mails envoyés pendant la coupure peuvent être définitivement rejetés selon la configuration des serveurs émetteurs.
La séquence qui protège tient en trois temps. Sauvegarder d'abord l'intégralité des boîtes, localement, au format standard. Documenter ensuite précisément les enregistrements MX, SPF, DKIM et DMARC actuels. Ne toucher aux DNS qu'après avoir validé ces deux points.
Et si la messagerie est hébergée sur la même offre que le site, prévoir explicitement son sort : elle reste où elle est, ou elle migre aussi, mais la question doit être tranchée avant, pas pendant.
Passer d'un accès délégué à une propriété réelle sur Analytics, Search Console et Tag Manager
Reprenons la distinction, parce qu'elle est vraiment décisive.
Sur Analytics, un compte contient des propriétés. Le rôle d'administrateur sur le compte donne le contrôle réel. Un accès en lecture sur une propriété ne donne rien du tout, ni la capacité d'ajouter quelqu'un, ni la garantie de conserver l'accès demain.
Sur Search Console, il existe deux niveaux : propriétaire vérifié et utilisateur. Le propriétaire vérifié a validé son contrôle du site par une méthode technique, fichier déposé, balise HTML ou enregistrement DNS. L'utilisateur, même délégué avec tous les droits, dépend entièrement du propriétaire.
L'action à mener : devenir propriétaire vérifié par une méthode que vous contrôlez, et l'enregistrement DNS est de loin la plus robuste, car elle survit à un changement d'hébergement ou de CMS.
Sur Tag Manager, la logique est identique. Le conteneur appartient à un compte, et c'est le rôle sur le compte qui compte, pas l'accès au conteneur.
Comptes publicitaires et Business Manager : la différence entre accès et propriété
Sur les plateformes publicitaires, la structure ajoute une couche. Une agence dispose d'un compte administrateur qui gère plusieurs comptes clients. Votre compte peut ainsi être rattaché à une structure qui ne vous appartient pas.
Il faut vérifier deux choses. Que votre compte publicitaire existe bien de façon autonome, avec son propre identifiant, et qu'il n'est pas une simple sous-section du compte agence. Et que vous y disposez d'un accès administrateur direct, pas d'un accès hérité de la structure parente.
Sur les réseaux sociaux, le Business Manager pose exactement le même problème. Votre page peut être détenue par un Business Manager tiers. Vous l'administrez au quotidien, vous publiez, vous répondez aux messages, tout va bien. Mais la propriété est ailleurs, et la récupérer relève d'une procédure formelle qui prend du temps.
Fiche d'établissement Google et présence locale
Pour une activité avec une présence physique, la fiche d'établissement pèse souvent plus lourd que le site lui-même en volume de contacts entrants.
Cette fiche a un propriétaire. Elle a aussi des gestionnaires. Si l'agence a créé la fiche, elle en est propriétaire, et vous n'êtes que gestionnaire.
La bonne nouvelle, c'est que Google prévoit une procédure de transfert de propriété. La moins bonne, c'est qu'elle nécessite la coopération du propriétaire actuel, ou à défaut une procédure de revendication plus longue. À traiter tôt, pas dans les derniers jours.
Pensez également aux avis clients. Ils sont attachés à la fiche, pas à vous. Perdre la fiche, c'est perdre les avis, et quelques années de réputation accumulée avec.
Hébergement, dépôt de code, certificats SSL, licences et abonnements tiers
L'hébergement se traite en dernier, une fois le domaine sécurisé et les sauvegardes validées.
Le dépôt de code, s'il existe, mérite une attention particulière. Il contient l'historique complet du développement, et cet historique a de la valeur pour comprendre ce qui a été fait et pourquoi. Un dépôt hébergé sur un compte d'agence se transfère, mais il faut le demander explicitement.
Les certificats SSL sont généralement automatisés aujourd'hui et se régénèrent sans intervention. Si un certificat payant est en place, il faut vérifier sa date de validité et son mode de renouvellement.
Restent les licences et abonnements tiers. Extensions premium du CMS, thème acheté, service de formulaires, outil de chat, solution de réservation. Chacun a un compte, une facturation, une adresse de contact. Chacun doit être identifié et rattaché à vous.
Rotation des mots de passe et révocation des accès : quand et dans quel ordre
Dernière étape, et elle intervient vraiment à la fin, une fois que tout fonctionne dans le nouvel environnement.
L'ordre logique : d'abord vérifier que le nouveau dispositif tourne correctement, ensuite changer les mots de passe des comptes centraux, puis révoquer les accès délégués, enfin supprimer les comptes utilisateurs du prestataire sortant sur le CMS et les outils.
Attention à un piège classique. Révoquer un accès trop tôt, alors qu'un service dépend encore de l'ancien environnement, provoque une panne dont l'origine sera difficile à identifier. Une passerelle de paiement, un service de mail transactionnel, une synchronisation avec un logiciel de gestion : ces liaisons passent parfois par des identifiants qu'on n'a pas cartographiés.
D'où l'intérêt de garder une trace écrite de chaque révocation, avec sa date. Si quelque chose casse trois jours plus tard, cette liste devient le premier endroit où chercher.
Les points de rupture qui font perdre du trafic
Une migration réussie techniquement peut être un échec en visibilité. Ce sont deux évaluations différentes, et la seconde ne se voit qu'après plusieurs semaines.
Perdre les redirections historiques lors d'une migration technique
On en a parlé plus haut, mais le sujet mérite d'y revenir, parce que c'est la cause numéro un des chutes de trafic post-migration.
Le scénario type : nouveau site, nouvelle structure d'URLs, redirections mises en place uniquement depuis l'ancien site vers le nouveau. Sauf que l'ancien site portait lui-même des redirections venant d'une version encore antérieure. Ces chaînes disparaissent, et avec elles la transmission des liens accumulés depuis dix ans.
Le contrôle à faire est simple : croiser la liste des URLs indexées, la liste des URLs ayant reçu du trafic sur les douze derniers mois, et la table de redirections du nouveau site. Toute URL présente dans les deux premières listes et absente de la troisième est une fuite.
Changer d'hébergeur sans anticiper la propagation DNS et le temps de coupure
La propagation DNS n'est pas instantanée. Selon la durée de vie configurée sur les enregistrements, elle prend de quelques minutes à quarante-huit heures. Pendant cette fenêtre, une partie des visiteurs atteint l'ancien serveur, une autre le nouveau.
Sur un site vitrine, l'inconvénient est mineur. Sur un site marchand, c'est autre chose : des commandes peuvent atterrir dans l'ancienne base pendant que vous travaillez sur la nouvelle.
La méthode consiste à abaisser la durée de vie DNS quarante-huit heures avant la bascule, à maintenir les deux environnements actifs pendant la propagation, puis à ne couper l'ancien qu'après vérification complète.
Repartir d'une propriété Search Console vierge et perdre l'antériorité de mesure
Créer une nouvelle propriété Search Console est immédiat et gratuit. Le piège, c'est que ça donne l'illusion d'avoir résolu le problème.
Une propriété neuve démarre à zéro. Aucune donnée antérieure, aucune possibilité de comparer avant et après, aucune base pour évaluer l'impact de la migration.
Or c'est précisément après une migration qu'on a besoin de comparer. Sans historique, impossible de distinguer une variation saisonnière normale d'une perte réelle liée à la bascule. On navigue sans instruments, au moment exact où on en aurait le plus besoin.
Les scripts, pixels et intégrations tierces oubliés dans l'ancien code
Un site ancien accumule des morceaux de code déposés au fil des campagnes. Pixel publicitaire, script de suivi, outil de test, widget d'avis, balise de partenaire affilié.
Beaucoup ne servent plus, et leur disparition ne pose aucun problème. Mais certains sont actifs et alimentent des dispositifs en cours. Un pixel de conversion supprimé, et c'est le suivi d'une campagne publicitaire qui tombe, sans message d'erreur, sans alerte, juste des chiffres qui s'écroulent.
Le réflexe : inventorier tous les scripts présents dans le code avant migration, identifier leur rôle, et décider explicitement de garder ou de supprimer. Décider, pas subir.
Le contenu récupéré sans ses métadonnées : titres, descriptions, données structurées, alt
Récupérer les textes, c'est bien. Récupérer ce qui les accompagne, c'est indispensable.
Chaque page porte un titre, une méta description, éventuellement des données structurées, et chaque image un attribut alternatif. Ces éléments ne sont pas dans le corps du texte. Ils vivent dans les champs techniques du CMS ou dans le code source.
Un export de contenu qui ne remonte que le texte visible produit un nouveau site où toutes ces informations sont à ressaisir. Sur cinquante pages, c'est un chantier. Sur mille pages, c'est un projet à part entière, avec son budget.
La parade : une extraction complète du code source avant migration, incluant l'ensemble des métadonnées. Un outil de crawl fait ça en quelques minutes et produit un tableau exploitable.
Ce qui relève du droit et ce qui se négocie
Toutes les questions n'ont pas la même nature. Certaines sont tranchées par le droit, d'autres relèvent d'un accord entre les parties. Savoir dans quelle catégorie on se trouve change complètement la manière d'aborder la discussion.
Cession des droits d'auteur sur les créations graphiques et rédactionnelles
Voici le point qui surprend le plus souvent. En droit français, payer une création ne signifie pas en acquérir les droits d'auteur. La cession doit être écrite, et elle doit préciser les droits cédés, l'étendue de l'usage, la durée et le territoire.
En l'absence de clause de cession, l'auteur conserve ses droits. Vous avez payé la prestation, vous disposez du fichier, mais vous ne détenez pas nécessairement le droit de le modifier ou de le réutiliser ailleurs.
En pratique, la plupart des prestataires ne font aucune difficulté. Mais le jour où la relation se tend, ce point peut ressortir. Il vaut donc mieux qu'une clause de cession figure au contrat initial, formulée clairement.
Le code sur mesure : propriété, licence, dépendances
Pour le code, la situation est plus nuancée qu'il n'y paraît, et souvent en trois couches.
La couche socle, le CMS lui-même, est fréquemment sous licence libre. Elle ne pose pas de problème.
La couche intermédiaire regroupe les extensions et thèmes du marché, sous licences commerciales rattachées à un compte acheteur. Elles se transfèrent, ou se rachètent.
La couche haute est le développement spécifique réalisé pour vous. C'est celle qui se négocie, et elle relève des mêmes principes que la propriété intellectuelle en général : sans cession écrite, elle reste à son auteur.
Une précision utile : même quand le code vous est cédé, il dépend de bibliothèques externes, de versions de langage, de configurations serveur. Recevoir le code sans sa documentation d'environnement, c'est recevoir un moteur sans savoir dans quelle voiture il rentre.
Sous-traitance et responsabilité : ce que dit l'article 28 du RGPD
Quand un prestataire traite des données personnelles pour votre compte, il agit en sous-traitant. Vous restez responsable de traitement. Cette répartition n'est pas un choix, elle découle des rôles réels.
L'article 28 impose un contrat écrit qui encadre cette relation, et il prévoit explicitement ce qui se passe à la fin : le sous-traitant restitue ou supprime les données personnelles, selon votre instruction.
C'est une obligation légale directement mobilisable. Si un prestataire refuse de restituer un fichier clients, il n'est plus dans un débat commercial, il est en manquement réglementaire. La formulation de la demande change alors de registre, et souvent d'efficacité.
Registre des traitements et documentation à récupérer
Au-delà des données elles-mêmes, il existe une documentation qui vous appartient et qu'on oublie systématiquement de réclamer.
Le registre des traitements, s'il a été tenu par le prestataire pour votre compte. Les mentions légales et la politique de confidentialité du site, dans leur version à jour. La configuration du dispositif de consentement aux cookies. Les éventuelles analyses d'impact réalisées.
Ces documents ne se reconstituent pas facilement, et leur absence se remarque au premier contrôle.
Attester la suppression des données chez l'ancien prestataire
Dernier point, souvent négligé : demander une attestation écrite de suppression.
Une fois vos données restituées, le prestataire sortant ne doit plus les conserver, sauf obligation légale de conservation spécifique, comme les documents comptables. Une attestation datée, précisant ce qui a été supprimé et quand, clôt proprement le dossier.
C'est aussi une protection pour vous. Si une fuite survient chez votre ancien prestataire deux ans plus tard, ce document établit que vos données n'auraient pas dû s'y trouver.
Conduire la transition sans zone grise
Le meilleur des inventaires ne remplace pas une conduite d'opération correcte. La plupart des incidents ne viennent pas d'un manque d'information, mais d'un flou sur qui fait quoi et à quel moment.
Constituer un dossier de reprise et un calendrier commun
Un document unique, partagé entre l'ancien prestataire, le nouveau et vous. Il liste les éléments à transmettre, leur état, la date de livraison prévue, et la personne responsable de chaque ligne.
Cela paraît lourd. C'est en réalité ce qui allège tout le reste, parce que ce document supprime les allers-retours par mail, les malentendus et les « je pensais que c'était vous qui deviez le faire ».
Le calendrier fixe une date de bascule, avec un avant et un après clairement identifiés. Une migration sans date décidée s'étire, et c'est pendant cet étirement que les choses se perdent.
La période de recouvrement : maintenir l'ancien environnement pendant la bascule
Ne coupez jamais l'ancien environnement le jour où le nouveau démarre. Jamais.
Une période de recouvrement de deux à quatre semaines permet de revenir en arrière si un problème majeur apparaît, de récupérer un élément oublié, et de comparer les comportements. Le coût est celui d'un hébergement supplémentaire pendant un mois. C'est dérisoire au regard du risque évité.
Cette période doit être prévue au contrat de sortie, pas négociée en urgence le jour de la bascule.
Ce que le nouveau prestataire doit exiger avant de démarrer
Un prestataire entrant sérieux ne se lance pas sans avoir vérifié quelques points, et son insistance sur ces sujets est plutôt bon signe.
Il demandera la confirmation que le domaine est bien à votre nom. La liste des accès effectivement en votre possession. Les sauvegardes complètes, vérifiées. La table des redirections existantes. Les exports d'historique de mesure. Et le statut des droits sur les contenus et le code.
S'il ne demande rien de tout cela et propose de démarrer immédiatement, c'est un signal. Pas forcément rédhibitoire, mais un signal.
Le contrôle post-bascule : ce qu'on vérifie à J+1, J+7 et J+30
Trois points de contrôle, trois niveaux de lecture.
À J+1, le fonctionnel immédiat. Le site répond sur toutes ses pages principales, les formulaires envoient bien, les mails arrivent, le certificat est valide, le suivi analytique enregistre des visites, aucune erreur serveur n'apparaît dans les journaux.
À J+7, l'indexation. Les redirections répondent correctement, les erreurs remontées dans Search Console restent dans des proportions normales, le sitemap est soumis et traité, les pages clés sont toujours indexées.
À J+30, la mesure de fond. Comparaison du trafic organique avec la période équivalente précédente, contrôle des positions sur les requêtes stratégiques, vérification du volume de conversions. C'est là qu'un problème structurel devient visible, et c'est encore assez tôt pour corriger.
Le mémo à garder : votre check-list de réversibilité permanente
Tout ce qui précède décrit une opération ponctuelle. Mais l'idée, au fond, c'est de ne plus jamais avoir à la mener dans l'urgence.
Tenir un registre des accès à jour en continu
Un tableau, cinq colonnes : service, URL de connexion, identifiant, adresse mail rattachée, titulaire. Stocké dans un gestionnaire de mots de passe dont vous êtes propriétaire.
Mis à jour à chaque ajout de service. Pas une fois par an dans un grand élan de rangement, mais au fil de l'eau, au moment où le service est créé. Cinq minutes à chaque fois, contre plusieurs jours de reconstitution le jour venu.
Les quatre choses à ne jamais déléguer entièrement
Si vous ne retenez que quatre points de cet article, ce sont ceux-là.
Le nom de domaine, déposé à votre nom, sur un compte registrar qui vous appartient, rattaché à une de vos adresses mail.
La propriété administrateur sur Analytics et Search Console, avec une vérification par enregistrement DNS.
Une sauvegarde complète du site, chez vous, actualisée régulièrement.
Les fichiers sources des créations graphiques, dans leur format modifiable.
Un prestataire peut tout gérer au quotidien, c'est même son travail. Mais ces quatre éléments doivent rester rattachés à vous, structurellement. Ce n'est pas de la défiance. C'est simplement la différence entre déléguer et dépendre.
Auditer sa dépendance une fois par an
Une heure par an. Vous ouvrez le registre des accès, vous vérifiez ligne par ligne que les titulaires n'ont pas changé, vous consultez le Whois de vos domaines, vous contrôlez que vous êtes toujours propriétaire vérifié sur vos outils de mesure, et vous testez la restauration de votre dernière sauvegarde.
Une heure. C'est tout. Et cette heure-là, investie chaque année, transforme une éventuelle séparation en formalité administrative plutôt qu'en crise.
Se faire accompagner sur une reprise de site sans casse
Une reprise de site n'est pas un chantier technique isolé. Elle croise du juridique, de l'organisationnel, de la mesure et de la visibilité, et c'est justement à l'intersection de ces domaines que les choses se perdent.
Un accompagnement extérieur apporte deux choses. D'abord un regard neutre, qui ne dépend d'aucune des deux parties en présence. Ensuite une méthode éprouvée, qui évite de découvrir les points de rupture au moment où ils cassent.
Que la reprise soit prévue dans six mois ou déjà engagée dans la douleur, l'ordre des opérations reste le même : cartographier, sauvegarder, vérifier les sauvegardes, reprendre les accès, migrer, contrôler. Aucune étape ne se saute, et celles qu'on saute sont exactement celles qui coûtent cher.
Et si le changement de prestataire n'est pas à l'ordre du jour, cette lecture aura peut-être servi à autre chose : à vérifier, tranquillement, qu'en cas de besoin, vous auriez la main sur ce qui vous appartient.