Une seule personne sait remettre votre site en ligne

La question se pose rarement à froid. Elle se pose un vendredi soir, quand le site est tombé et que la seule personne qui sait le relancer est injoignable.

Le test qui donne la réponse

Demander à quelqu’un d’autre — un autre développeur, un prestataire, un administrateur — de remettre le site en service à partir de la seule documentation, dans un environnement séparé.

Ce test prend une demi-journée. Il échoue presque toujours la première fois, et les points de blocage sont remarquablement constants :

• un accès dont personne d’autre n’a les identifiants ;
• une étape « évidente » absente de la procédure ;
• une variable de configuration connue de mémoire ;
• une dépendance installée à la main un jour, jamais consignée ;
• une sauvegarde restaurable en théorie, jamais restaurée en pratique.

Chacun de ces points se corrige en quelques minutes une fois identifié. Le difficile est de les identifier avant l’incident.

Ce que la documentation doit contenir

Pas une architecture générale : une procédure exécutable.

Comment construire le projet, comment le déployer, où sont les sauvegardes, comment les restaurer, où sont les secrets, qui contacter chez l’hébergeur et le bureau d’enregistrement du domaine.

Le test de validité est simple : une personne compétente mais étrangère au projet y parvient-elle seule ? Si elle doit appeler, la documentation est incomplète — et le point d’appel désigne exactement ce qu’il manque.

Les accès, premier point de blocage

Un compte d’hébergement, un domaine ou un dépôt rattachés à l’adresse électronique personnelle d’un salarié ou d’un prestataire créent une dépendance juridique, pas seulement technique.

Trois vérifications : le nom de domaine est-il au nom de l’entreprise, les comptes critiques sont-ils sur des adresses de service plutôt que nominatives, et les secrets sont-ils dans un coffre partagé plutôt que dans un fichier local ou une conversation ?

Le cas du prestataire unique

La dépendance est la même, avec une différence : elle est contractuelle. Un prestataire qui refuse de remettre le code, les accès ou la documentation ne protège pas un savoir-faire ; il protège une situation.

Le test se demande aussi à lui, en cours de contrat, quand la relation est bonne. Ce qui manque apparaît en une journée, et coûte alors une demi-journée à corriger.

Ce que le test change

Il transforme une inquiétude diffuse — « que se passe-t-il si… » — en liste de cinq actions concrètes, chacune traitable dans la semaine.

C’est le meilleur rapport entre effort et risque supprimé de tout ce qui touche à l’exploitation.