Prestataire digital défaillant : comment sortir d'un projet web qui dérape (et récupérer ses accès)

Le vrai risque n'est pas le retard, c'est la dépendance

Un projet web qui glisse de trois semaines, ça se rattrape. Un projet web dont vous ne détenez ni le nom de domaine, ni l'hébergement, ni le code source, ça ne se rattrape pas : ça se rachète. Et souvent au prix fort.

C'est la nuance que beaucoup de dirigeants découvrent trop tard, généralement au pire moment, celui où la relation avec l'agence s'est déjà tendue. On appelle, on relance, on menace un peu. En face, plus rien. Le site tourne toujours, les clients continuent d'arriver, mais vous n'avez plus la main sur votre propre outil de travail.

Une refonte subie, décidée dans l'urgence parce qu'on ne peut pas récupérer l'existant, coûte facilement entre deux et quatre fois le prix d'une reprise en main organisée. Sans compter les mois de référencement perdus. À l'inverse, un audit de propriété des actifs demande une demi-journée et se fait à froid, quand tout va bien.

Ce guide propose trois choses : une méthode pour faire l'état des lieux de ce que vous possédez réellement, une chronologie de sortie qui ne casse ni le site ni le trafic, et les leviers juridiques qui fonctionnent vraiment en France. Pas ceux qu'on lit partout et qui s'arrêtent à « demandez vos accès ».

Reconnaître un projet qui dérape avant qu'il ne soit trop tard

Soyons honnêtes : tous les projets web dérapent un peu. Les délais glissent, les périmètres bougent, un développeur tombe malade, un client change d'avis sur la home trois fois. C'est le métier. Le problème n'est donc pas le retard en lui-même.

La vraie question est ailleurs : votre prestataire glisse-t-il en transparence ou en silence ? Une agence qui vous dit « on a deux semaines de retard, voilà pourquoi, voilà le nouveau planning » gère mal son projet mais reste fiable. Une agence qui répond « ça avance » depuis six semaines sans jamais rien montrer, c'est autre chose.

Les signaux faibles que les clients ignorent trop longtemps

Ils s'installent progressivement, ce qui explique qu'on les laisse passer. Les réponses aux mails s'espacent : deux jours, puis quatre, puis une semaine. Votre interlocuteur habituel change sans qu'on vous prévienne, et le nouveau semble découvrir votre dossier en direct.

Autre marqueur, plus subtil : les comptes rendus remplacent peu à peu les livrables. On vous envoie des points d'avancement détaillés, bien rédigés, rassurants. Mais vous n'avez toujours rien vu de concret. Un compte rendu n'est pas un livrable. Un planning actualisé non plus.

Et puis il y a le classique du « c'est en cours » sans environnement de recette accessible. Si personne ne peut vous montrer le travail sur une URL de préproduction, posez-vous la question de ce qui existe vraiment.

Dernier signal, le plus parlant : les factures avancent plus vite que le périmètre livré. Vous en êtes à 70 % du budget engagé pour 30 % du projet visible. Ce déséquilibre-là ne se résorbe jamais tout seul.

Les signaux d'alerte techniques

Ceux-là sont plus objectifs, et franchement plus inquiétants.

• Aucun accès à un environnement de préproduction, même en lecture seule
• Aucun dépôt de code visible, ni GitHub, ni GitLab, ni rien d'équivalent
• Pas de politique de sauvegarde documentée, ou une réponse vague du type « c'est géré par l'hébergeur »
• Refus de vous donner un accès administrateur, avec l'argument imparable : « pour éviter que vous cassiez quelque chose »
• Mises à jour de sécurité du CMS et des extensions non appliquées depuis des mois
• Hébergement mutualisé chez le prestataire, au nom du prestataire, sans contrat d'hébergement distinct

Ce dernier point mérite qu'on s'y attarde. Un hébergement en marque blanche n'a rien d'illégal ni même de suspect en soi. Beaucoup d'agences sérieuses le proposent, c'est un service. Mais il crée une dépendance totale : le jour où la relation se dégrade, votre site vit sur un serveur auquel vous n'avez juridiquement aucun droit d'accès. L'hébergeur réel, celui qui possède l'infrastructure, ne vous connaît pas. Vous n'êtes pas son client.

Le point de bascule

À un moment, la question n'est plus « comment on redresse le projet » mais « est-ce que continuer coûte plus cher que sortir ». Trois critères permettent de trancher assez vite.

La dette technique est-elle rattrapable ? Un code mal structuré mais lisible se reprend. Un site sans documentation, sans versionnement, avec des modifications directes en production et des fonctions maison partout, se réécrit. Faites auditer par un tiers, ça coûte une journée et ça évite des mois d'illusion.

La confiance opérationnelle est-elle encore là ? Pas la confiance affective, la confiance opérationnelle. Est-ce que vous croyez encore ce qu'on vous annonce ? Si vous avez pris l'habitude de vérifier systématiquement, la relation est déjà morte, vous ne l'avez juste pas encore actée.

Détenez-vous vos actifs ? Et c'est le critère qui change tout. Si oui, vous pouvez sortir quand vous voulez, en position de force. Si non, chaque semaine de plus renforce la dépendance et fait monter le prix de la sortie.

Cartographier vos actifs numériques : l'audit de propriété

Voilà la partie qui devrait vous occuper la prochaine heure. Pas demain, pas « quand j'aurai le temps ». Cet audit se fait aussi bien quand tout va bien, d'ailleurs c'est même le meilleur moment : personne n'est sur la défensive, les réponses arrivent naturellement.

Les cinq familles d'actifs à vérifier

Tout se range dans cinq catégories, et chacune a ses propres règles de récupération.

Le nom de domaine et les DNS. C'est l'actif souverain. Celui qui le détient contrôle où pointe votre site, où arrivent vos emails, et donc tout le reste.

L'hébergement et la base de données. Le serveur, les fichiers, les sauvegardes, les certificats SSL.

Le code source et l'environnement de développement. Le dépôt, les branches, l'historique des versions, les scripts de déploiement.

Les contenus, les médias et les droits associés. Textes, photos, vidéos, illustrations, et surtout les licences qui vont avec.

Les comptes tiers. La liste est longue et on en oublie toujours : Google Search Console, Google Analytics, Google Business Profile, Google Ads, les réseaux sociaux, l'outil d'emailing, la plateforme de gestion du consentement, la passerelle de paiement, éventuellement un CRM, un outil de réservation, un chat.

Vérifier qui possède réellement le nom de domaine

Cinq minutes suffisent, et le résultat surprend souvent.

Interrogez le Whois du domaine. Pour un .fr, l'Afnic propose son propre outil de recherche ; pour les extensions génériques, n'importe quel service Whois public fait l'affaire. Vous obtenez plusieurs champs, et c'est là qu'il faut savoir lire.

Le champ qui compte s'appelle le titulaire, ou registrant. C'est le propriétaire juridique du nom de domaine. Point. Les autres champs, contact administratif et contact technique, ne confèrent aucun droit de propriété : ce sont des rôles de gestion.

Beaucoup de dirigeants découvrent à cette étape que leur agence figure comme titulaire. Parfois par malveillance, souvent par simple négligence au moment de la réservation. Le résultat est le même : le domaine ne vous appartient pas.

Attention à une subtilité française : pour les extensions gérées par l'Afnic (.fr, .re, .pm et quelques autres), les données du titulaire d'une personne morale sont publiques, mais celles d'une personne physique sont masquées par défaut. Si le domaine a été réservé au nom d'une personne physique, le Whois affichera peu de choses. Il faudra passer par le registrar pour obtenir la confirmation.

Notez également le registrar (le bureau d'enregistrement, OVH, Gandi, Ionos, etc.) et le statut du domaine. Un statut de type clientTransferProhibited indique un verrouillage de transfert. Ce n'est pas grave en soi, c'est même une protection standard contre le détournement, mais il faudra le lever le moment venu.

Identifier votre hébergeur et vos points de dépendance

Le nom qui apparaît sur votre facture n'est pas forcément celui de l'hébergeur réel. Une agence peut acheter un serveur chez un grand hébergeur et vous en revendre une part sous son propre nom. C'est la revente d'hébergement, ou marque blanche.

Comment le repérer ? Vérifiez à quelle entité appartiennent les adresses IP du site, regardez si vous disposez d'un panneau de gestion à votre nom, demandez simplement le nom du datacenter. Si les réponses sont floues, vous êtes en marque blanche.

Et puis il y a les dépendances masquées, celles auxquelles personne ne pense avant qu'elles ne posent problème :

• Les licences de thèmes et d'extensions premium achetées au nom du prestataire (la licence expire ou est révoquée, plus de mises à jour, plus de support)
• Les briques SaaS intégrées au site : moteur de recherche, gestionnaire de formulaires, système d'avis
• Les clés d'API tierces configurées sur son compte : cartographie, traduction automatique, transactionnel
• Le CDN et les certificats, souvent liés au même compte que l'hébergement

Chacune de ces dépendances est un petit fil qui vous relie au prestataire. Un fil, ça se coupe. Vingt fils emmêlés, c'est un autre chantier.

Le cas des accès Google

C'est probablement le sujet le plus mal compris, et celui qui fait le plus de dégâts.

Il faut distinguer deux choses radicalement différentes : la propriété du compte et le niveau d'autorisation dont vous disposez dessus. Avoir un accès administrateur ne signifie pas être propriétaire. Le propriétaire peut retirer votre accès en trois clics ; l'inverse n'est pas vrai.

Le scénario type, que l'on croise vraiment souvent :

La propriété Search Console a été validée par une balise HTML posée par le prestataire dans le code du site. Le compte Analytics a été créé sur son adresse mail à lui, avec votre société comme simple libellé de propriété. Et la fiche établissement Google reste à son nom en tant que propriétaire principal, vous n'étant que gestionnaire.

Les conséquences sont concrètes et douloureuses. Perte de l'historique de données : plusieurs années de trafic, de requêtes, de conversions, effacées de votre horizon. Perte de la fiche établissement, avec ses avis clients accumulés patiemment. Et impossibilité de suivre correctement une migration, précisément au moment où vous en auriez le plus besoin.

Un détail qui a son importance : la balise de validation Search Console est posée dans le code du site. Si vous récupérez le site, vous pouvez la retirer et revalider la propriété à votre nom. Ce n'est pas irréversible. La fiche établissement et l'ancienneté d'un compte Analytics, elles, ne se récupèrent pas aussi facilement.

La grille d'audit à remplir

Reprenez chaque actif identifié et remplissez ce tableau. Il devient votre document de travail pour tout le reste de la procédure.

Actif	Détenteur du compte	Niveau d'accès dont vous disposez	Criticité	Action à mener
Nom de domaine	Titulaire au Whois	Aucun / Contact / Compte registrar	Critique	Changement de titulaire ou transfert
DNS	Registrar ou tiers	Aucun / Lecture / Édition	Critique	Reprendre la main avant bascule
Hébergement	Prestataire ou vous	FTP / SSH / Panneau complet	Critique	Sauvegarde puis migration
Base de données	Idem hébergement	Aucun / Export possible	Critique	Export immédiat
Code source	Dépôt du prestataire	Aucun / Lecture / Propriétaire	Élevée	Vérifier la cession de droits
Search Console	Compte Google	Restreint / Complet / Propriétaire	Élevée	Ajouter une propriété à votre nom
Analytics	Compte Google	Lecture / Édition / Administrateur	Élevée	Transfert d'administration
Fiche établissement	Compte Google	Gestionnaire / Propriétaire	Critique	Demande de propriété principale
Emails professionnels	Hébergeur ou tiers	Boîtes seules / Administration	Critique	Anticiper la bascule MX
Licences et extensions	Prestataire	Aucun	Moyenne	Racheter à votre nom

Une colonne mérite votre attention particulière : la criticité. Tout n'a pas le même poids. Perdre une licence de thème premium à 60 euros, c'est agaçant. Perdre le nom de domaine sur lequel repose votre chiffre d'affaires, c'est autre chose.

Récupérer ses accès, actif par actif

Passons au concret. Chaque type d'actif obéit à sa propre logique, et les conseils génériques du type « demandez poliment puis insistez » ne vous mèneront nulle part.

Le nom de domaine

Trois scénarios possibles, du plus simple au plus délicat.

Premier cas : vous êtes titulaire et vous détenez le compte registrar. Situation confortable. Vous n'avez qu'à changer les contacts administratif et technique pour retirer le prestataire, modifier les mots de passe, et éventuellement activer une authentification à deux facteurs. Comptez dix minutes.

Deuxième cas : vous êtes titulaire mais le prestataire détient le compte registrar. Vous êtes propriétaire, il a les clés. La solution passe par un transfert vers un compte à vous, chez le même registrar ou chez un autre. Il faut obtenir le code d'autorisation de transfert (auth code, code de transfert, EPP code selon les appellations). Le registrar est tenu de le fournir au titulaire, c'est-à-dire à vous. Si le prestataire fait obstruction, écrivez directement au service client du registrar en joignant un justificatif d'identité de la société : extrait Kbis, pièce d'identité du gérant. Ça fonctionne, mais comptez une à trois semaines.

Troisième cas : vous n'êtes pas titulaire du tout. Le plus compliqué. Juridiquement, le domaine appartient au prestataire. Il faut alors passer par une procédure de changement de titulaire, qui nécessite son accord explicite. S'il refuse, plusieurs leviers existent : la démonstration que le domaine reprend votre marque déposée ou votre dénomination sociale, la procédure de résolution des litiges propre à l'extension (le Syreli pour les .fr gérés par l'Afnic, l'UDRP pour les extensions génériques), ou la voie judiciaire.

Quelques mécanismes à connaître, parce qu'ils conditionnent les délais :

• Un domaine récemment créé ou récemment transféré est bloqué en transfert pendant soixante jours. Rien à faire, c'est une règle de l'ICANN pour les extensions génériques.
• Le transfert lui-même prend généralement de cinq à sept jours une fois lancé, parfois moins.
• Le déverrouillage préalable est obligatoire chez la plupart des registrars.
• Un changement de titulaire peut lui-même déclencher une nouvelle période de blocage.

Un point critique, à graver quelque part : ne laissez jamais un domaine expirer pendant un conflit. C'est le pire scénario. Après expiration, le domaine passe en période de rédemption (délai de restauration coûteux) puis, à terme, redevient disponible à la réservation. Des sociétés spécialisées surveillent les expirations en temps réel et récupèrent les domaines à trafic en quelques secondes. Vous ne les récupérerez pas, ou alors à un prix qui n'a plus rien à voir avec les quinze euros de renouvellement. Si vous avez le moindre doute sur qui paie le renouvellement, payez-le vous-même, quitte à ce que ce soit en double.

L'hébergement et les données

Le RGPD est régulièrement invoqué à tort et à travers dans ces situations. Voyons ce qu'il couvre réellement.

Le droit à la portabilité concerne les données à caractère personnel : votre fichier clients, les comptes utilisateurs, les inscrits à la newsletter, les données de commandes. Le prestataire, s'il agit comme sous-traitant au sens du règlement, doit vous les restituer dans un format structuré et lisible par machine. Il doit également, à la fin de la prestation, soit les supprimer soit vous les retourner.

En revanche, le RGPD ne couvre pas le code source, la mise en page, les visuels ou l'architecture technique. Ce sont d'autres régimes juridiques, propriété intellectuelle en tête. Invoquer le RGPD pour réclamer votre thème WordPress ne mènera à rien, sinon à affaiblir votre crédibilité sur le reste.

Concrètement, ce que vous devez récupérer avant toute chose :

1. Un export complet de la base de données, au format SQL
2. Une archive de l'arborescence des fichiers, thème et fichiers téléversés compris
3. Les sauvegardes existantes, avec leurs dates
4. Les identifiants de connexion à la base (utile pour la reconfiguration)
5. Les éventuelles tâches planifiées configurées côté serveur

Si vous disposez encore d'un accès administrateur au CMS, une extension de sauvegarde fait le travail en quelques minutes. Si vous avez un accès FTP, téléchargez tout et exportez la base via l'outil de gestion. Faites-le maintenant, avant d'engager quoi que ce soit avec le prestataire. On y revient plus loin, mais c'est le point sur lequel tout le monde se plante.

Et si l'hébergeur réel refuse de vous parler ? C'est le cas classique de la marque blanche : vous n'êtes pas son client, il n'a aucune obligation envers vous, et il appliquera ses conditions générales à la lettre. Il vous répondra que son interlocuteur contractuel est l'agence. Rien à faire de ce côté. Le levier se trouve ailleurs : chez le prestataire lui-même, ou par voie judiciaire si l'urgence est caractérisée.

Le code source : ce que vous possédez vraiment

Voilà le point aveugle du marché français. Asseyez-vous.

En droit d'auteur français, la cession de droits ne se présume pas. Autrement dit : payer un développement ne vous en rend pas propriétaire. Sans clause écrite de cession des droits patrimoniaux, précisant les droits cédés, leur étendue, leur destination, leur durée et leur territoire, le prestataire reste titulaire des droits d'auteur sur le code qu'il a écrit.

Oui, même si vous avez payé la facture. Oui, même si le devis mentionne « développement d'un site internet ». La facture prouve que vous avez acheté une prestation, pas que vous avez acquis des droits.

Cette règle surprend systématiquement, et elle explique pourquoi certains prestataires peu scrupuleux se sentent en position de force. Ils ne sont d'ailleurs pas complètement dans leur tort sur ce point précis.

Mais il faut nuancer, parce que tout n'est pas logé à la même enseigne :

Le socle open source vous reste accessible. WordPress, PrestaShop, Drupal et la plupart des CMS sont distribués sous licence GPL. Cette licence est virale : les thèmes et extensions qui en dérivent héritent des mêmes conditions, ce qui vous donne le droit d'utiliser, de modifier et de faire évoluer le code. Un prestataire ne peut pas vous interdire d'utiliser un thème WordPress qu'il a développé pour vous, la licence GPL prime sur ses éventuelles prétentions.

Le développement spécifique est la zone grise. Un module métier écrit de zéro, une application web sur mesure, une intégration complexe avec un ERP : là, sans cession écrite, vous êtes dans une position délicate.

Les contenus de la base vous appartiennent dès lors que vous les avez produits ou fait produire avec cession.

En pratique, comment décider ? Posez-vous trois questions. Ce qui tourne sur un socle open source, reprenez-le sans état d'âme. Ce qui relève d'un développement spécifique dont vous avez besoin et dont vous n'avez pas les droits, négociez son rachat ou sa cession, ça reste souvent moins cher qu'une réécriture. Et ce qui est mal fichu, obsolète ou peu utilisé, ne perdez pas d'énergie à le récupérer : réécrivez. Un développeur compétent refait en trois jours ce qu'on refuse de vous rendre depuis deux mois.

Les comptes tiers et l'historique de données

Chaque plateforme a sa procédure, et il faut les traiter une par une.

Search Console. Si vous récupérez l'accès au site ou au DNS, vous pouvez valider une nouvelle propriété à votre nom, par enregistrement DNS de préférence (c'est la méthode la plus robuste, elle couvre l'ensemble du domaine). Bonne nouvelle : les données historiques sont attachées au site, pas au compte. Vous récupérez donc l'historique disponible, généralement seize mois.

Analytics. Un utilisateur disposant du rôle Administrateur sur le compte peut en promouvoir un autre. Si personne de votre côté n'a ce rôle, il faut passer par le prestataire ou par le support Google, qui demandera des justificatifs de propriété du domaine. Sachez que créer une nouvelle propriété repart de zéro : l'historique n'est ni transférable ni fusionnable. C'est perdu.

Fiche établissement Google. La procédure de revendication de propriété existe et fonctionne. Vous demandez l'accès, le propriétaire actuel reçoit une notification et dispose de sept jours pour répondre. S'il ne répond pas, vous pouvez généralement obtenir le transfert. S'il refuse, il reste la vérification par les moyens habituels et un recours auprès du support. C'est long, parfois plusieurs semaines, mais ça aboutit dans la majorité des cas de bonne foi.

Un mot sur la valeur de l'historique, parce qu'on la sous-estime beaucoup. Perdre trois ans de données Analytics, ce n'est pas juste perdre des graphiques. C'est perdre la capacité de mesurer la saisonnalité réelle de votre activité, de comparer une performance à celle de l'an dernier, d'identifier ce qui a fonctionné et ce qui n'a jamais rien rapporté. Ça ne se reconstruit pas. On repart à zéro et on attend deux ans.

Les contenus et les visuels

Même logique que pour le code, avec quelques particularités.

Les textes rédigés par le prestataire ou par un rédacteur qu'il a mandaté sont protégés par le droit d'auteur s'ils présentent un caractère original. Là encore, sans cession écrite, la situation est ambiguë. En pratique, les contentieux sur des textes de pages de service sont rares, mais le risque existe.

Les photographies commandées suivent le même régime, et c'est un sujet plus sensible : les photographes professionnels sont généralement bien informés de leurs droits et cèdent des utilisations limitées (un support, une durée, un territoire). Vérifiez ce qui figure sur la facture du photographe, si vous y avez accès.

Le vrai piège concerne les banques d'images. Si le prestataire a utilisé des visuels issus d'un abonnement à son nom, la licence lui est attachée, à lui, pas à vous. Continuer à afficher ces images après la fin de la relation vous expose à une réclamation. Et les sociétés de gestion de droits photographiques sont particulièrement actives sur ce terrain : elles scannent le web automatiquement et envoient des demandes de régularisation qui se chiffrent en centaines d'euros par image.

Conseil pratique : au moment de la reprise en main, faites l'inventaire des visuels et remplacez ceux dont vous ne pouvez pas prouver la licence. C'est fastidieux, ça prend une demi-journée, et ça vaut mieux qu'un courrier recommandé dans dix-huit mois.

Sécuriser la sortie sans casser le site

La plupart des articles sur le sujet s'arrêtent à « récupérez vos accès ». C'est dommage, parce que le plus dur commence après. Récupérer ses accès et perdre 60 % de son trafic organique dans la foulée, ce n'est pas une victoire.

L'ordre des opérations

L'erreur la plus courante, et de loin : annoncer sa sortie avant d'avoir sauvegardé.

Le scénario se déroule toujours pareil. Le dirigeant, agacé, envoie un mail ferme annonçant la fin de la collaboration. Dans l'heure qui suit, les accès sont coupés. Parfois le site est mis hors ligne. Parfois pire. Et il ne reste plus qu'à négocier depuis une position de faiblesse totale.

La séquence correcte, dans l'ordre, sans en sauter :

1. Sauvegarde complète et vérifiée, avant toute annonce. Fichiers, base, médias. Et surtout : testez la restauration sur un environnement local. Une sauvegarde non testée n'est pas une sauvegarde.
2. Inventaire des accès en votre possession, avec la grille d'audit remplie plus haut.
3. Sécurisation des comptes dont vous êtes propriétaire : changement des mots de passe, activation de l'authentification à deux facteurs, retrait des utilisateurs qui n'ont plus lieu d'être.
4. Préparation du nouvel environnement : hébergement commandé, site restauré, testé, validé sur une URL temporaire ou un fichier hosts.
5. Récupération du contrôle DNS ou du domaine, selon le scénario.
6. Notification officielle au prestataire, avec la demande formelle de restitution.
7. Bascule DNS vers le nouvel hébergement, avec un TTL abaissé quelques jours avant pour accélérer la propagation.
8. Contrôle post-bascule : réponses HTTP, certificat, formulaires, emails, tracking.
9. Revalidation des outils : Search Console, Analytics, balises de conversion.
10. Surveillance rapprochée pendant quatre à six semaines.

Vous remarquerez que la notification arrive en sixième position, pas en première. Ce n'est pas de la ruse, c'est de la gestion du risque. Vous n'avez aucune obligation d'annoncer votre départ avant d'être prêt.

Préserver le référencement pendant la migration

Une migration bien faite ne coûte rien en visibilité. Une migration bâclée peut effacer des années de travail en quinze jours.

La règle numéro un tient en une phrase : conservez la structure d'URL. Si les adresses de vos pages restent identiques, vous supprimez 80 % du risque. Le changement d'hébergement, en lui-même, n'a aucun impact sur le référencement tant que les performances suivent.

Si les URL doivent changer (refonte simultanée, changement de CMS), il faut un plan de redirections 301 exhaustif. Exhaustif signifie : chaque ancienne URL indexée pointe vers l'équivalent le plus pertinent. Pas vers la page d'accueil en bloc, c'est le meilleur moyen de tout perdre. Récupérez la liste complète des URL depuis Search Console, depuis le sitemap et depuis un crawl du site avant migration.

Les points de contrôle qui sautent le plus souvent :

• Le fichier robots.txt laissé en mode blocage total, hérité de l'environnement de recette. C'est l'accident classique, et il fait des dégâts en quelques jours.
• Les balises meta robots en noindex, même origine, même conséquence.
• Les balises canoniques qui pointent encore vers l'ancien environnement de préproduction.
• L'environnement de recette laissé accessible et indexable, créant une duplication complète du site.
• Le certificat SSL non renouvelé ou mal configuré au moment de la bascule.
• Le sitemap XML non régénéré, listant des URL mortes.
• Les temps de réponse serveur dégradés parce que le nouvel hébergement est sous-dimensionné.

Dans les semaines qui suivent, surveillez trois choses : le rapport de couverture d'indexation dans Search Console (les erreurs 404 doivent rester marginales), les positions sur vos requêtes principales, et le trafic organique jour par jour. Une baisse de 5 à 10 % pendant deux semaines est normale, le temps que les redirections soient assimilées. Une baisse de 40 % signale un problème technique, pas une fluctuation.

Continuité de service et messagerie

Celui-là, on l'oublie une fois sur deux. Et il fait mal.

Dans de très nombreuses configurations, les adresses email professionnelles sont hébergées sur le même compte que le site. Vous basculez les DNS, vous coupez l'hébergement, et vos emails s'arrêtent. Parfois sans que personne s'en rende compte immédiatement, ce qui est encore pire : les messages sont refusés ou partent dans le vide pendant deux jours.

La bonne pratique consiste à traiter la messagerie avant le site, et séparément. Migrez d'abord les boîtes vers une solution indépendante (Google Workspace, Microsoft 365, ou un hébergeur mail dédié), en récupérant l'historique par IMAP. Testez la réception. Puis seulement, occupez-vous du site.

Pendant la propagation DNS, abaissez le TTL des enregistrements MX à cinq minutes au moins vingt-quatre heures avant la bascule. Et gardez l'ancienne boîte active quelques jours, le temps d'être certain que plus rien n'y arrive.

Les leviers juridiques et contractuels

Restons pragmatiques. L'objectif n'est pas de gagner un procès, c'est de récupérer ses actifs le plus vite possible et au moindre coût. Le droit sert surtout à créer le rapport de force qui débloque la situation.

Relire le contrat avec les bons réflexes

Sortez le contrat, s'il existe, et cherchez ces points dans l'ordre :

• La clause de cession des droits d'auteur. Existe-t-elle ? Précise-t-elle les droits cédés, l'étendue, la destination, la durée, le territoire ? Sans ces mentions, la cession peut être contestée.
• La clause de réversibilité. Prévoit-elle une restitution des données et des accès en fin de contrat ? Dans quel délai ? À quel coût ?
• La propriété du nom de domaine. Est-elle mentionnée noir sur blanc ?
• La durée d'engagement et la tacite reconduction. Beaucoup de contrats de maintenance se reconduisent automatiquement avec un préavis de trois mois. Ratez la fenêtre, vous repartez pour un an.
• Les conditions de résiliation pour manquement. Elles imposent généralement une mise en demeure préalable et un délai de régularisation.
• L'obligation de restitution des données, des accès, des sauvegardes.

Et si vous n'avez pas de contrat, seulement un devis signé ? C'est le cas le plus fréquent chez les TPE et PME, de loin.

Un devis signé constitue bel et bien un contrat : il y a offre, acceptation, prix. Mais il ne contient que ce qui y est écrit. S'il ne mentionne pas la cession des droits, il n'y a pas de cession. S'il ne dit rien du domaine, rien n'est acquis. Le devis fixe le périmètre de la prestation et son prix, c'est tout. Il ne règle aucune des questions de propriété qui vous préoccupent aujourd'hui.

À noter tout de même : le prestataire reste soumis à une obligation de conseil et d'information, ainsi qu'à une obligation de loyauté dans l'exécution du contrat. Une agence qui ne vous a jamais informé que le domaine était réservé à son nom manque à cette obligation, et ça pèse dans une négociation.

La mise en demeure

C'est le point de bascule formel. Elle marque la fin des échanges informels et ouvre les délais juridiques.

Quand la déclencher ? Après une ou deux relances écrites restées sans réponse satisfaisante, et une fois que vous avez sauvegardé ce qui pouvait l'être. Pas avant.

Sur la forme : lettre recommandée avec accusé de réception, adressée au siège social de la société, avec copie par email pour accélérer la prise de connaissance. La mention « mise en demeure » doit figurer explicitement.

Sur le fond, une trame qui fonctionne :

Rappel du cadre contractuel. Date du devis ou du contrat, objet de la prestation, montants réglés à ce jour. Factuel, daté, chiffré.

Description des manquements. Chronologie précise : « le 12 mars, demande d'accès administrateur restée sans réponse ; le 3 avril, relance ; le 18 avril, réponse indiquant que la demande serait traitée ; à ce jour, aucun accès transmis ». Les dates valent mieux que les adjectifs.

Demandes précises et nominatives. C'est là que beaucoup de courriers échouent, en restant vagues. Ne demandez pas « la restitution de mes accès », listez : le code d'autorisation de transfert du domaine, les identifiants FTP ou SSH de l'hébergement, un export SQL complet de la base, un compte administrateur sur le CMS au nom de telle adresse email, le transfert de la propriété principale de la fiche établissement, la remise du code source sur support numérique. Chaque ligne doit être vérifiable.

Délai de régularisation. Quinze jours calendaires est un standard raisonnable et défendable. Huit jours si l'urgence est caractérisée (site hors ligne, échéance de renouvellement du domaine proche).

Réserve de recours. Mention que, faute d'exécution dans le délai, vous vous réservez le droit de saisir la juridiction compétente et de demander réparation du préjudice.

Une mise en demeure bien construite débloque une bonne partie des situations. Non pas par la menace, mais parce qu'elle signale que vous savez précisément ce que vous voulez et que vous documentez. Les prestataires de mauvaise foi comptent sur le flou ; le flou, une mise en demeure précise le supprime.

Quand la rétention d'accès devient contestable

Il faut être honnête sur ce point : toutes les rétentions ne sont pas abusives.

Un prestataire qui n'a pas été payé et qui suspend une prestation en cours applique une logique d'exception d'inexécution, qui est reconnue. Si vous devez trois factures, votre position est nettement moins solide, et votre mise en demeure risque de vous revenir avec la sienne.

La ligne de partage se situe ici : suspendre une prestation pour impayé se discute ; retenir des actifs dont vous êtes propriétaire est une autre affaire. Un domaine dont vous êtes titulaire, vos données personnelles clients, des contenus que vous avez produits : rien ne justifie leur rétention, même en cas de litige financier.

Le conseil pratique dans ce cas de figure : réglez ce qui est incontestablement dû, contestez formellement le reste par écrit, et traitez la restitution comme un sujet distinct. Mélanger les deux dossiers vous affaiblit sur les deux.

Les voies de recours

Par ordre de coût et de délai croissants.

La négociation directe assistée. Un courrier d'avocat coûte quelques centaines d'euros et change souvent le ton de la discussion du jour au lendemain. C'est généralement le meilleur rapport résultat/investissement.

Le médiateur des entreprises. Service public, gratuit, confidentiel. Il intervient dans les litiges entre entreprises et obtient de bons résultats quand les deux parties restent de bonne foi. Comptez quelques semaines à quelques mois.

Les procédures propres aux noms de domaine. Pour un .fr, le Syreli géré par l'Afnic traite les litiges en environ deux mois pour un coût modéré. Pour les extensions génériques, l'UDRP suit une logique proche. Ces procédures sont efficaces quand le domaine reprend une marque ou une dénomination sociale dont vous êtes titulaire.

Le référé. En cas d'urgence caractérisée (site hors ligne, activité paralysée, domaine sur le point d'expirer), le juge des référés peut ordonner la restitution sous astreinte. Comptez quelques semaines et plusieurs milliers d'euros d'honoraires. Réservé aux situations où l'enjeu le justifie clairement.

La procédure au fond. Longue, coûteuse, incertaine. À envisager uniquement pour des préjudices importants et documentés.

Un calcul froid s'impose souvent à ce stade. Si le litige porte sur un site à 8 000 euros, engager une procédure à 6 000 euros d'honoraires pour un résultat aléatoire n'a pas de sens. Reconstruire proprement, avec les bonnes clauses cette fois, coûte parfois moins cher que d'avoir raison. Ça n'est pas satisfaisant, mais c'est souvent la décision rationnelle.

Reprendre la main : reconstruire une relation prestataire saine

Sortir d'une mauvaise relation ne sert à rien si la suivante reproduit les mêmes failles. Et c'est fréquent : on change d'agence, on reste dans la même configuration de dépendance, on recommence trois ans plus tard.

Les clauses à exiger dès le prochain devis

Ces six clauses ne coûtent rien à demander et changent tout. Un prestataire sérieux les acceptera sans discuter, la plupart les proposent déjà spontanément.

Cession expresse et écrite des droits patrimoniaux sur les développements spécifiques, avec mention des droits cédés, de l'étendue, de la destination, de la durée et du territoire. Sans ces cinq mentions, la clause reste fragile.

Titularité du nom de domaine au nom de l'entreprise cliente, avec le dirigeant ou une adresse email générique de la société comme contact administratif.

Accès administrateur permanent et nominatif sur le CMS, l'hébergement et l'ensemble des outils. Nominatif signifie une adresse email par personne, pas un compte partagé.

Dépôt du code sur un dépôt dont vous êtes propriétaire. Vous créez l'organisation GitHub ou GitLab, vous y invitez le prestataire. Ça prend cinq minutes et ça règle définitivement la question de l'accès au code.

Clause de réversibilité chiffrée, avec délai de restitution (quinze jours est raisonnable), liste des éléments restitués et coût éventuel de l'opération. Une réversibilité chiffrée à l'avance évite les factures surprises au moment de la séparation.

Sauvegardes accessibles, avec fréquence, durée de rétention et modalité d'accès. Idéalement, une copie automatique vers un espace de stockage qui vous appartient.

La règle des comptes maîtres

S'il ne fallait retenir qu'un principe de tout cet article, ce serait celui-là.

Tous les comptes stratégiques sont créés sur une adresse email de l'entreprise. Le prestataire y est invité. Jamais propriétaire.

C'est simple, ça ne coûte rien, et ça neutralise à peu près tous les scénarios décrits plus haut. Déclinez-le partout :

• Compte registrar au nom de la société, avec le domaine réservé sur cette adresse
• Compte d'hébergement au nom de la société, le prestataire ayant des identifiants techniques distincts
• Compte Google (Search Console, Analytics, fiche établissement, Ads) créé sur une adresse générique de type contact@ ou direction@
• Comptes publicitaires et de paiement au nom de la société
• Dépôt de code sur une organisation qui vous appartient

Une précision qui a son importance : utilisez une adresse générique plutôt que l'adresse personnelle d'un salarié. Le jour où cette personne quitte l'entreprise, vous ne voulez pas rejouer le même scénario en interne.

Choisir un prestataire qui ne vous enferme pas

Quelques questions à poser en phase de sélection, et les réponses qui devraient vous rassurer.

« Le nom de domaine sera réservé à quel nom ? » Réponse attendue : au vôtre, sans hésitation, avec proposition de vous accompagner dans la création du compte.

« Est-ce que j'aurai un accès administrateur permanent ? » Réponse attendue : oui, évidemment. Une réserve du type « on préfère éviter pour ne pas risquer de casse » est un signal négatif. Un prestataire peut vous mettre en garde sur les manipulations sensibles, c'est légitime ; vous refuser l'accès, non.

« Où sera hébergé le code ? » Réponse attendue : sur un dépôt versionné, dont vous pouvez être propriétaire.

« Que se passe-t-il si nous arrêtons de travailler ensemble ? » Réponse attendue : une procédure claire, un délai, éventuellement un coût. L'absence de réponse structurée en dit long.

« Le devis inclut-il la cession des droits sur les développements spécifiques ? » Réponse attendue : oui, ou une explication honnête sur ce qui est cédé et ce qui ne l'est pas (un framework maison réutilisé sur plusieurs clients peut légitimement rester la propriété de l'agence, sous réserve de vous accorder une licence d'utilisation).

Une observation, après avoir vu passer pas mal de ces situations : un prestataire solide n'a strictement aucun intérêt à retenir vos accès. Il vous garde parce que son travail est bon, pas parce que vous êtes coincé. La rétention d'actifs est toujours l'aveu d'une faiblesse commerciale, la stratégie d'une agence qui sait qu'elle ne retiendra pas ses clients autrement. Ceux qui la pratiquent le font rarement une seule fois.

La sortie se prépare le jour de la signature

La dépendance technique n'est pas un accident de parcours. C'est un choix de départ, parfois délibéré du côté du prestataire, presque toujours par défaut du côté du client. Personne ne signe un devis en se disant qu'il faudra peut-être partir un jour. C'est pourtant précisément le moment où cette sortie se règle, en trois clauses et une adresse email générique.

Si vous êtes déjà dans la situation difficile, la marche à suivre reste la même : auditez avant d'agir, sauvegardez avant d'annoncer, et traitez chaque actif avec sa propre procédure. La précipitation coûte beaucoup plus cher que les quelques jours de préparation.

Et si vous n'y êtes pas encore, prenez l'heure nécessaire pour remplir la grille d'audit. Vérifiez qui est titulaire de votre domaine, qui possède votre compte Analytics, qui détient votre fiche établissement. Le pire moment pour découvrir la réponse, c'est le jour où vous en avez besoin.

Un audit de propriété des actifs, un plan de migration sans perte de référencement, une surveillance rapprochée pendant la bascule : ces trois chantiers se mènent sereinement quand ils sont anticipés, et dans l'urgence quand ils ne le sont pas. À vous de choisir dans quelle configuration vous voulez être.