Votre prestataire est injoignable : comment reprendre la main sur votre site

Le scénario que personne n’anticipe#

Le freelance qui a fait votre site ne répond plus depuis trois semaines. Ou l’agence a fermé. Ou la personne qui s’en occupait a changé de métier, et vous n’avez jamais eu son mot de passe.

Votre site fonctionne encore — c’est bien ce qui est trompeur. Il tourne quelque part, sur un serveur dont vous ignorez le nom, avec un nom de domaine que vous ne savez pas renouveler, et un code source que vous n’avez jamais vu.

Tant que rien ne bouge, tout va bien. Le problème, c’est que quelque chose finit toujours par bouger : un renouvellement qui n’est pas payé, une version de logiciel qui n’est plus supportée, une faille qui s’ouvre. Et le jour où ça casse, vous n’avez la main sur rien.

Voici la marche à suivre, dans l’ordre. Elle commence par ce qu’il ne faut pas faire.

Étape 0 : ne cassez rien#

Le réflexe naturel, quand on découvre qu’on ne maîtrise plus son site, c’est de vouloir reprendre le contrôle vite. C’est le meilleur moyen de transformer un problème en catastrophe.

Ne résiliez aucun abonnement. Pas l’hébergement, pas le nom de domaine, pas les services tiers, même s’ils sont facturés par un prestataire qui ne répond plus. Un prélèvement de 12 € par mois qui continue est un désagrément. Un hébergement résilié, c’est un site effacé.

Ne laissez pas expirer le nom de domaine. C’est le seul élément de la liste dont la perte soit réellement irréversible. Un code source, on peut le reconstruire. Un hébergement, on peut le remplacer. Un nom de domaine qui expire retombe dans le domaine public, et il peut être racheté dans la foulée — par un concurrent, ou par un revendeur qui vous le proposera à un prix sans rapport avec sa valeur.

C’est donc par là qu’il faut commencer : vérifiez la date d’expiration de votre domaine. Une recherche whois publique suffit, elle est gratuite et instantanée. Si l’échéance est dans les semaines qui viennent, tout le reste attend.

Étape 1 : l’inventaire des six clés#

Un site, ce n’est pas un objet. C’est un empilement de six choses distinctes, détenues par des acteurs différents. Vous pouvez parfaitement posséder les unes et pas les autres — et c’est presque toujours le cas.

Le tableau se lit dans un ordre précis. Traitez la colonne de droite d’abord. Ce qui est irréversible passe avant ce qui est seulement pénible.

Étape 2 : ce que vous pouvez récupérer seul#

Vous en récupérerez plus que vous ne le croyez, et sans avoir besoin de l’accord de qui que ce soit.

Le nom de domaine. Contactez le bureau d’enregistrement (une recherche whois vous dit lequel c’est). Même si votre prestataire y figure comme contact technique ou administratif, un registraire sérieux vous rendra la main sur preuve d’identité et de facturation. C’est une démarche administrative, parfois lente, mais elle aboutit.

L’hébergement. Même logique : si les factures sont à votre nom ou à celui de votre société, l’hébergeur est votre fournisseur, pas celui de votre prestataire. Demandez la réinitialisation des accès.

Le contenu public. Tout ce que votre site affiche est, par définition, accessible. Les textes, les images, la structure des pages, les URL : cela s’aspire depuis le site en ligne. C’est le filet de sécurité qu’on oublie systématiquement, et il change tout dans le pire scénario.

Étape 3 : ce qui va résister#

Deux choses vont poser problème, et il vaut mieux le savoir tout de suite.

Les comptes ouverts au nom du prestataire. Un compte de paiement, une console publicitaire, une clé d’API, une boîte mail technique créée avec son adresse à lui. Juridiquement, ces comptes ne sont pas les vôtres. Certains fournisseurs acceptent un transfert de propriété sur justificatifs ; d’autres non. C’est souvent là que la reprise coince.

Le code source, si le contrat est muet. Et c’est le point le plus mal compris.

En droit français, la cession des droits sur un logiciel n’est jamais automatique. Elle doit être écrite et explicite. Autrement dit : avoir payé le développement ne fait pas de vous le propriétaire du code. Sans clause de cession dans votre contrat, le prestataire reste titulaire de ses droits — et il n’a aucune obligation de vous livrer les sources.

C’est une découverte brutale, et elle arrive toujours au pire moment. Nous détaillons le sujet dans un article dédié sur la propriété du code source.

Étape 4 : le pire cas, et pourquoi il n’est pas une impasse#

Admettons le pire : le code est perdu, personne ne vous le livrera, et le site tourne sur un serveur auquel vous n’avez plus accès.

Ce n’est pas une impasse. C’est un chantier.

Tant que le site répond encore, tout ce qui est public reste récupérable — pages, textes, images, structure des URL. On peut donc reconstruire un site équivalent et basculer sans casser votre référencement, à condition de conserver les mêmes adresses ou de poser des redirections propres. C’est exactement le métier de la reprise de site existant.

Ce qui est réellement perdu, c’est l’invisible : un back-office, des règles métier, des intégrations avec votre comptabilité ou votre logiciel de caisse. Là, il n’y a pas de miracle. Il faut redocumenter le fonctionnement à partir des usages — c’est-à-dire en interrogeant les gens qui s’en servent tous les jours. C’est fastidieux. C’est faisable.

Le coût de ce chantier dépend entièrement de la complexité du site. Un site vitrine se reprend en quelques jours. Une application métier, c’est plusieurs mois. Dans les deux cas, il commence par un audit technique : savoir ce qui tourne, où, avec quelles dépendances, avant de décider quoi que ce soit.

Étape 5 : reprendre la main pour de bon#

Une fois la crise passée, la vraie question n’est pas « comment réparer », c’est « comment faire pour que cela ne se reproduise jamais ».

Cinq exigences. Elles ne coûtent rien à poser au moment de signer, et elles valent des dizaines de milliers d’euros le jour où ça tourne mal.

1. Le nom de domaine est enregistré à votre nom, avec vos identifiants à vous. Pas ceux de l’agence. C’est non négociable.
2. Les comptes d’hébergement et de services tiers sont ouverts à votre nom. Le prestataire y est invité comme collaborateur, il n’en est pas le titulaire.
3. Le code est déposé sur un dépôt que vous détenez (GitHub, GitLab…), et non sur le poste de quelqu’un. Vous n’avez pas besoin de savoir le lire : vous devez juste le posséder.
4. Une clause de cession des droits figure au contrat. Explicite, écrite. Sans elle, vous louez votre propre site.
5. Une clause de réversibilité prévoit ce que le prestataire vous remet en fin de mission : code, accès, documentation, sauvegardes.

Aucun prestataire honnête ne refusera ces cinq points — ils ne lui coûtent rien non plus. Un refus, en revanche, est en soi une réponse. Nous avons détaillé ce que doit contenir un bon contrat dans un article sur les clauses essentielles d’un contrat de prestation.

Ce que cette situation révèle vraiment#

Un prestataire injoignable n’est pas un accident de parcours. C’est le symptôme d’une fonction qui n’existait pas : personne, dans votre entreprise, n’avait la responsabilité de savoir où tournait votre site, qui en détenait les clés, et ce qui se passerait si le prestataire disparaissait.

Ce n’est pas un reproche. C’est une fonction qui, dans une TPE ou une PME, n’est confiée à personne — parce qu’elle ne ressemble à aucun métier connu, et qu’elle ne se manifeste que le jour où elle a manqué.

Il n’est pas nécessaire de recruter un directeur technique à temps plein pour la couvrir. Il suffit que quelqu’un dont c’est le métier tienne l’inventaire et arbitre les décisions, quelques jours par an. C’est tout l’objet d’un CTO à temps partagé — et à 1 000 € HT la journée, facturée au quart d’heure entamé, l’inventaire complet de vos accès coûte moins cher que le premier jour de panique.

Vous êtes dans cette situation, ou vous soupçonnez de l’être sans en avoir la certitude ? Le point de départ est toujours le même : faire l’inventaire, calmement, avant que quoi que ce soit n’expire. Parlons-en.