Il y a un message qui arrive dans presque toutes les mises en ligne. Le site est propre, le client est content, et trois semaines plus tard : « est-ce que tu peux changer la date, elle est passée ». Rien de grave en soi. Sauf que ce message reviendra toutes les deux semaines pendant deux ans, et qu'à chaque fois il faudra que je sois disponible pour qu'une information fausse disparaisse d'un site qui n'est pas le mien.
Ce n'est pas un problème technique. C'est un arbitrage qu'on a oublié de faire avant de construire.
Le critère de livraison, c'est ce qui bouge
Avant d'écrire une ligne, je fais la liste de tout ce qui changera après la mise en ligne, avec sa fréquence. Pas les fonctionnalités : les contenus.
Un site ordinaire en contient trois familles, et elles n'ont rien à voir entre elles.
- Ce qui ne bouge jamais — le positionnement, la promesse, la structure des pages. Ça change une fois par an et ça mérite une vraie discussion à chaque fois.
- Ce qui bouge quand l'activité bouge — une offre, un tarif, une page en plus. Quelques fois par an, et ça passe très bien par moi ou par un prestataire.
- Ce qui bouge tout seul — des dates, un agenda, des disponibilités, une liste de lieux, un stock. Fréquence hebdomadaire, et une information périmée en page d'accueil fait plus de dégâts qu'une page moche.
La troisième famille est la seule qui compte au moment de livrer. Si sa mise à jour dépend de toi, tu n'as pas livré un site : tu as vendu un abonnement à ta disponibilité.
Le mécanisme le plus bête qui fait le travail
Pour cette troisième famille, le réflexe du métier consiste à construire un espace d'administration. Une connexion, un formulaire, une liste, des droits. C'est propre, c'est satisfaisant à construire, et c'est presque toujours disproportionné.
Un tableur que le site lit au chargement fait le même travail. Le client ouvre un fichier qu'il connaît déjà, ajoute une ligne, l'information est en ligne. Pas de mot de passe supplémentaire, pas d'interface à apprendre, pas de republication à demander. Et surtout pas de code à maintenir, donc rien à casser à la prochaine évolution du site.
J'ai arbitré comme ça récemment sur un site où les prochaines dates s'affichent à deux endroits. Pas de page admin : un onglet de tableur, et des dates qui disparaissent d'elles-mêmes une fois passées. La personne qui tient ces dates ne se connectera jamais à un back-office — elle vit dans son agenda et dans ses fichiers.
L'échelle que j'applique, du plus léger au plus lourd :
- Un tableur ou une base lue par le site, pour des listes : dates, lieux, tarifs simples, membres.
- Des fichiers de contenu ou un CMS, quand il y a des textes longs et du formatage — un blog, des pages de ressources.
- Un back-office, uniquement s'il y a des droits différents selon les personnes, une étape de validation, ou de la donnée qui ne doit pas se promener dans un fichier partagé.
Le niveau 3 se justifie, parfois. Mais il se justifie, il ne se présume pas. Un back-office construit par défaut, c'est trois semaines de build, une surface de bug permanente, et un client qui finira par t'envoyer ses modifications par mail plutôt que de s'y connecter.
Le test, c'est lui qui clique
Quand le mécanisme est en place, je ne demande pas au client s'il a compris. Je le laisse faire la modification lui-même, devant moi, sans que je touche à rien, et je regarde où il hésite.
C'est là qu'on découvre les vraies choses : qu'il n'est pas connecté au bon compte, que le fichier est sur un espace auquel il n'a pas accès, qu'il ne sait pas si c'est enregistré, qu'il attend une confirmation qui n'existe pas. Aucun de ces problèmes n'apparaît dans une démonstration où c'est moi qui clique.
Et si une modification exige une republication du site, il faut le dire noir sur blanc, parce que tout se joue sur ce détail. Un client qui doit demander un déploiement pour corriger une date ne le demandera pas. Il laissera l'erreur en ligne.
Ce que ça change dans le cadrage
Cette liste est maintenant dans mon périmètre, au même niveau que les pages à produire : qui met à jour quoi, à quelle fréquence, par quel moyen. Trois colonnes, dix lignes, un quart d'heure de discussion.
Ce quart d'heure déplace des choses. Il arrive qu'on s'aperçoive qu'une rubrique prévue demande en réalité une mise à jour hebdomadaire que personne n'assumera — et qu'on la supprime avant de l'avoir construite. C'est un bon résultat. Un site qui affiche moins mais juste vaut mieux qu'un site complet et périmé.
Il arrive aussi qu'on découvre l'inverse : que la personne qui va maintenir n'est pas celle qui commande. Deux interlocuteurs, deux niveaux de confort avec les outils, et c'est le second qui décide si le mécanisme tiendra. Si tu cadres uniquement avec le premier, tu construis pour quelqu'un qui n'ouvrira jamais ce que tu livres.
Je construis mes sites sur Lovable, en concevant et en itérant avec Claude. La vitesse de build n'est plus le facteur limitant depuis longtemps — ce qui limite, c'est de savoir qui tiendra le contenu une fois que je ne serai plus dans la boucle.
Le réflexe à garder
Avant toute mise en ligne, pose la question dans ce sens-là, pas dans l'autre :
« Qu'est-ce qui sera faux dans trois semaines si personne ne m'appelle ? »
Ce que tu listes doit être modifiable sans toi, par la personne qui détient l'information, avec un outil qu'elle ouvre déjà. Tout le reste peut rester dans le code.