Votre développeur web a disparu ? Comment reprendre le contrôle de votre site

Les messages restent sans réponse une semaine, puis un mois. Le téléphone sonne dans le vide. Pendant ce temps, le site continue de fonctionner, et c'est bien là le piège : le problème reste invisible jusqu'au jour où vous devez changer un prix, ajouter une page ou renouveler un service dont vous ignoriez l'existence. Vous découvrez alors que chaque identifiant, chaque e-mail de renouvellement et chaque mot de passe partait chez quelqu'un qui n'est plus là.

La même situation arrive par une autre porte quand vous héritez d'un site : vous avez racheté une entreprise, rejoint une société ou repris le poste d'un collègue, et le site est arrivé sans identifiants ni notes de passation. Dans les deux cas, le travail est le même. Établir ce que vous possédez, reprendre la main sur chaque élément dans le bon ordre, puis fermer la brèche pour qu'elle ne se rouvre pas.

Que faire en premier si votre développeur web disparaît ?

Sécurisez le nom de domaine avant toute chose, car c'est le seul actif que vous pouvez perdre définitivement. Ensuite, listez chaque compte dont dépend le site et notez qui contrôle chacun. Ne supprimez, n'annulez et ne reconstruisez rien pour l'instant. Un site qui fonctionne encore vous laisse du temps.

Le réflexe est de commencer par le site lui-même, puisque c'est la partie visible. Résistez-y. Un site peut toujours être reconstruit de zéro s'il le faut, moyennant un coût. Un domaine qui expire et qui est enregistré par quelqu'un d'autre peut ne jamais revenir, et chaque lien, chaque adresse e-mail et chaque position dans Google y sont rattachés.

Le premier après-midi ressemble donc à ceci : trouver la date d'expiration du domaine, savoir sur quel compte il se trouve, et noter chaque service que le site utilise probablement. Cette liste est votre plan de récupération. Tout le reste consiste à la dérouler.

À qui appartient réellement votre site ?

Un site web est en réalité plusieurs actifs distincts, et chacun peut être détenu par une personne différente. Le domaine est enregistré au nom d'un titulaire. L'hébergement est un compte chez un prestataire. Le code et le contenu vivent sur cet hébergement. Autour gravitent la messagerie, les statistiques et les outils de recherche. Posséder l'un ne vous donne pas les autres.

C'est là que beaucoup de propriétaires se font surprendre. Payer les factures pendant des années ne signifie pas que les comptes sont à votre nom, et le développeur qui a tout créé sur son propre compte « par commodité » en était, juridiquement et en pratique, le titulaire. Deux de ces actifs, le domaine et l'hébergement, décident si le reste est récupérable, et les autres suivent une fois que vous les tenez. Voici quoi vérifier et ce qu'il vous faut pour chacun :

Comment savoir qui contrôle votre nom de domaine ?

Passez votre domaine dans un outil de recherche RDAP public, comme celui que l'ICANN propose sur lookup.icann.org. Il affiche le registrar, la date d'expiration et les serveurs de noms. Contactez ce registrar, prouvez que votre entreprise est le titulaire inscrit, et demandez la récupération du compte ou le transfert du domaine vers vous.

Depuis 2018, la plupart des coordonnées des titulaires sont masquées dans les recherches publiques pour des raisons de confidentialité, ne vous inquiétez donc pas si le champ indique simplement « redacted ». Le registrar sait toujours qui est le titulaire. Ce qui compte, c'est le nom et l'organisation inscrits dans cet enregistrement. Si c'est votre entreprise, le domaine est à vous même si vous ne vous êtes jamais connecté, et le registrar dispose d'une procédure pour vous en donner le contrôle. Si c'est le nom personnel du développeur, la récupération devient une discussion avec le registrar, voire une question juridique, et c'est pourquoi cette étape passe en premier.

Une fois le compte du registrar entre vos mains, vous pouvez déplacer le domaine où vous voulez. Pour les domaines génériques comme .com, la politique de transfert de l'ICANN oblige les registrars à vous fournir le code d'autorisation de transfert dans les cinq jours calendaires suivant votre demande. Les domaines nationaux comme .fr, géré par l'AFNIC, ou .be et .ch suivent les règles de leur propre registre : renseignez-vous auprès du registrar ou du registre concerné.

Une parenthèse qui évite de vrais ennuis : activez le renouvellement automatique dès que vous avez l'accès, et remplacez l'e-mail de contact du compte par une adresse sur votre propre domaine, que vous contrôlez. Une façon très courante de perdre un domaine est un simple renouvellement oublié, parce que les rappels continuent d'arriver dans une boîte que plus personne ne lit.

Comment récupérer l'accès à votre compte d'hébergement ?

Identifiez la société qui héberge le site, puis demandez-lui de vous vérifier comme titulaire du compte. Si le compte est facturé à votre entreprise, cela suffit généralement. S'il est au nom du développeur, l'hébergeur ne peut le céder qu'avec son accord ou sur une base légale, et la solution de repli consiste alors à copier le site ailleurs.

Retrouver l'hébergeur demande un peu d'enquête, rarement beaucoup. Vos enregistrements DNS pointent vers un serveur, et une recherche sur l'adresse de ce serveur révèle le plus souvent le prestataire. Les anciennes factures et les relevés de carte bancaire sont parfois plus rapides.

Si le compte d'hébergement ne peut pas être récupéré, vous n'en avez pas forcément besoin. Tant que le site reste accessible publiquement et que vous contrôlez le domaine, il peut être reconstruit ou copié sur un nouvel hébergement, puis le domaine pointé dessus. Certains sites s'exportent presque entièrement depuis l'extérieur ; d'autres, surtout ceux qui reposent sur une base de données, ont besoin d'un véritable accès pour être déplacés proprement. C'est par là que nous commençons habituellement un sauvetage : établir ce qui peut être récupéré sur le serveur actuel et ce qui doit être reconstruit, puis le transférer vers un hébergement que le propriétaire contrôle.

Et si vous n'arrivez pas à vous connecter au site lui-même ?

Si le site tourne sur un CMS courant comme WordPress, le mot de passe administrateur peut être réinitialisé depuis le compte d'hébergement, via la base de données ou les outils de la plateforme ; l'accès à l'hébergement règle donc généralement le problème. S'il a été développé sur mesure, il vous faut le code source. S'il a été créé avec un constructeur de sites hébergé, il vit dans le compte de celui qui détient ce constructeur.

Ces trois cas se comportent très différemment, alors identifiez le vôtre avant de planifier quoi que ce soit :

• Un CMS standard. Le cas le plus simple. Avec l'accès à l'hébergement, on peut créer un nouveau compte administrateur ou réinitialiser l'ancien mot de passe. WordPress documente plusieurs méthodes pour cela, dont une directement via la base de données.
• Un site ou une application développés sur mesure. Les fichiers en ligne peuvent suffire à le faire tourner, mais le modifier correctement exige le code source d'origine et une compréhension de son architecture. Demandez si le code se trouve dans un dépôt (GitHub, GitLab, Bitbucket) et sur quel compte.
• Un constructeur de sites hébergé. Le site existe à l'intérieur de la plateforme, sous un seul compte. Si ce compte est celui du développeur, le support de la plateforme est votre porte d'entrée, et l'on pourra vous répondre que le site ne peut pas du tout être transféré ailleurs, seulement reconstruit.

Et si vous avez hérité d'un site que vous ne pouvez pas modifier ?

Commencez par le même inventaire, puis cherchez pourquoi la modification est bloquée. Le plus souvent, c'est l'une de trois raisons : pas d'identifiant administrateur, un site entièrement codé sans interface d'édition, ou une licence de thème ou de constructeur de pages qui a expiré avec l'ancien propriétaire. Chacune a sa solution, et seule la dernière se règle par un simple achat.

La version héritée s'accompagne en général de moins d'hostilité et de plus de confusion. Personne ne vous refuse quoi que ce soit. Le savoir est simplement parti avec la personne qui a construit le site. Demandez à l'ancien propriétaire ou au collègue sur le départ trois choses précises plutôt que « tous les identifiants » : le compte du registrar, le compte d'hébergement et tout compte dans lequel le site a été construit. Avec ces trois-là, tout le reste peut être récupéré.

Soyez réaliste avec les sites entièrement codés. Si chaque modification de texte est toujours passée par un développeur, c'est ainsi que le site a été conçu, et les options honnêtes sont soit de garder un développeur disponible, soit de déplacer le site vers une solution que vous pouvez modifier vous-même. Aucune n'est une erreur. Tout dépend de la fréquence à laquelle votre contenu change.

Faut-il réparer l'ancien site, le migrer ou le reconstruire ?

Réparez-le si le site est sain et que vous détenez désormais tous les comptes. Migrez-le si le site est correct mais que l'hébergement ou les comptes qui l'entourent ne le sont pas. Reconstruisez-le si le code n'est pas maintenable, si le design a des années de retard, ou si rien d'autre que le contenu ne peut être récupéré.

Notre avis, pour ce qu'il vaut : ne reconstruisez pas dans la panique. Reprendre le contrôle et refaire le design sont deux décisions distinctes, et les prendre en même temps transforme un sauvetage en projet de six mois. Stabilisez le site, sauvegardez-le et placez-le sous des comptes qui vous appartiennent. Ensuite seulement, décidez du design à tête reposée.

Quel que soit votre choix, protégez ce que le site a déjà acquis dans les résultats de recherche. Si des URL changent pendant une migration ou une refonte, chaque ancienne adresse doit être redirigée en 301 vers son équivalent, sinon les positions associées à ces pages sont perdues. Notre guide sur comment changer d'hébergeur sans perdre de données ni de référencement détaille cette séquence. Et si le vrai problème est l'hébergement plutôt que le développeur absent, l'article sur les signes qu'il est temps de quitter votre hébergeur actuel vous aidera à distinguer les deux.

Comment éviter que cela se reproduise ?

Mettez chaque compte au nom de votre entreprise, sur une adresse e-mail de votre propre domaine, avec vous comme propriétaire principal et le développeur ajouté comme second utilisateur. Conservez les identifiants dans un gestionnaire de mots de passe contrôlé par l'entreprise. Demandez une courte passation écrite chaque fois que quelqu'un termine un travail sur le site.

Rien de tout cela ne relève de la méfiance envers les développeurs. La plupart sont parfaitement corrects, et beaucoup disparaissent pour des raisons ordinaires, comme la fermeture d'une petite agence ou un changement de carrière. Le problème, c'est une organisation où une seule personne détenait tous les accès. Corrigez l'organisation, et le départ d'un développeur devient une simple passation.

Le code lui-même est une question à part. La propriété juridique du code et du design d'un site commandé dépend de votre contrat et de votre pays. Si le site compte pour votre activité, faites inscrire la cession des droits dans le contrat avant le début des travaux. S'il est trop tard et qu'un litige se profile, consultez un avocat plutôt que de vous fier à un article de blog, celui-ci compris.

Une courte liste à garder sous la main :

• Domaine : enregistré au nom de votre entreprise, renouvellement automatique activé, e-mail de contact sur votre propre domaine.
• Hébergement : facturé à l'entreprise et détenu par elle, développeur ajouté comme utilisateur si nécessaire.
• Administration du site : au moins un compte administrateur à votre nom.
• Code : si le site est sur mesure, un dépôt détenu par l'entreprise, et la propriété du code écrite dans votre contrat.
• Sauvegardes : une copie récente des fichiers et de la base de données stockée en dehors du compte d'hébergement.
• Comptes Google : vous êtes propriétaire dans Search Console et Analytics, pas seulement le développeur.