Un site que ton client ne peut pas reprendre sans toi n'est pas livré. Il est en dépôt chez toi. La différence ne se voit pas le jour de la mise en ligne, elle se voit six mois plus tard : quand il veut brancher son nom de domaine, quand il change de prestataire, ou quand toi tu quittes l'outil sur lequel tu as construit. À ce moment-là ce n'est plus un sujet technique, c'est un sujet de propriété, et ça se règle très mal après coup.
Je ne parle pas de la cession des droits sur le code, qui est une affaire de contrat. Je parle de quelque chose de plus bête et de plus bloquant : qui détient les comptes.
Trois propriétés qu'on confond
- Le projet : le code, l'espace de travail de l'outil no-code, l'historique des versions. Il vit dans un compte, le tien ou le sien.
- Le nom de domaine : acheté chez un registrar, avec une carte bancaire et une adresse mail. Qui détient ce compte détient l'adresse du site. Rien d'autre ne compte.
- Les comptes tiers branchés dessus : formulaires, paiement, analytics, envoi d'e-mails, base de données, clés d'API. Ce sont ceux qu'on oublie, et ce sont ceux qui lâchent.
Un site peut être livré sur les trois, sur deux, ou sur aucune. Tant que personne ne pose la question, la réponse est « aucune » — et elle penche toujours du côté du prestataire, parce que c'est lui qui a ouvert les comptes en premier pour aller vite.
Construire chez soi ou chez le client
Deux options, et je n'ai pas de réponse unique.
Chez moi, puis transfert. Je démarre dans mon espace, avec mes conventions, sans attendre que quelqu'un crée un compte et sorte sa carte. C'est plus rapide, et le client ne voit que le résultat. Le coût : le transfert doit vraiment avoir lieu. Tant qu'il n'est pas planifié comme un livrable, avec une date, il n'arrive jamais — un projet n'a presque jamais de fin franche.
Chez le client dès le départ. Rien à transférer, le domaine et l'abonnement sont sur son moyen de paiement dès le premier jour, et il voit le chantier avancer en direct. Le coût : la première séance part en administration de comptes au lieu de produit, et je travaille dans un environnement que je ne contrôle pas.
Mon critère de décision est simple : qui va porter le coût récurrent. S'il y a un abonnement mensuel pour que le site reste en ligne, le compte doit être le sien dès le début, sinon je deviens l'intermédiaire de paiement de mon propre client — et c'est une mauvaise place, autant pour la trésorerie que pour la relation. Si le build n'a pas de coût récurrent côté outil, je construis chez moi et je transfère à la livraison.
Les quatre pièges, toujours les mêmes
- Le domaine acheté avec ma carte « en attendant ». Un an plus tard, l'alerte de renouvellement arrive dans ma boîte, pas dans la sienne.
- Les intégrations posées sur mes comptes. Le jour où je ferme l'un d'eux, les formulaires du site cessent d'envoyer, et personne ne le remarque tout de suite.
- Le transfert promis « à la fin ». La fin n'existe pas. Il y a toujours une dernière correction.
- L'identifiant partagé au lieu d'un vrai accès. Deux personnes sur un même compte, aucune trace de qui a changé quoi, et un client dehors le jour où le mot de passe change.
Aucun de ces quatre points ne coûte quoi que ce soit à faire correctement au moment où on ouvre le compte. Les quatre coûtent cher six mois plus tard.
Ce que je pose maintenant dans le cadrage
Je mets ça au même niveau que les pages à produire, et je le fais à l'écrit. Quatre lignes.
Qui détient le compte de l'outil ? Qui achète le nom de domaine, et avec quel moyen de paiement ? Quels comptes tiers sont nécessaires, et sur quelle adresse mail les ouvre-t-on ? À quelle date le client récupère le tout ?
La dernière question est celle qui fait le travail. Une date, dans le planning, avec une tâche à cocher. Pas « à la livraison » : un jour précis, si possible avant le solde de la facture — c'est le seul moment où tout le monde est encore motivé pour cliquer sur les bons boutons.
Et un transfert se vérifie dans l'autre sens. Ce n'est pas moi qui déclare que c'est fait : c'est le client qui se connecte, seul, depuis son poste, et qui voit le projet dans son espace. J'ai vu assez de transferts « effectués » qui n'avaient en réalité ajouté qu'un invité sur un projet resté chez le prestataire.
Ce que ça change dans la façon de construire
Quand on sait dès le départ que le projet changera de mains, on construit autrement. On évite les bricolages qui ne tiennent que parce qu'on sait où ils sont. On nomme les choses pour quelqu'un d'autre. On écrit, en une page, ce qui est branché où et pourquoi.
Cette page-là n'est pas pour un développeur : elle sera ouverte le jour où quelque chose ne marche plus, par quelqu'un qui ne connaît pas l'outil. Donc elle liste les comptes avant la technique.
Le test du jour où tu disparais
Pose la question pour chaque site que tu as livré cette année : si demain tu ne réponds plus, qu'est-ce qui s'éteint, et dans combien de temps ?
Si la réponse est « le site tient, mais plus personne ne peut le modifier », c'est gérable. Si la réponse est « le domaine expire dans quelques mois et le mail de renouvellement est le mien », tu as une dette à régler. Elle se règle en une heure aujourd'hui, contre une semaine de panique le jour où ça tombe.
Pour demain, le geste utile : une page par client, trois lignes — projet, domaine, comptes tiers — et le nom du détenteur en face de chacune. Les cases vides, ce sont tes transferts à faire.