Un outil qui marche
n’est pas un produit.

Trois choses qui ont fini par ne plus passer

Notre métier tenait sur un socle très répandu et son constructeur de pages. Nous le connaissions mieux que la plupart. Trois choses ont fini par ne plus passer.

La maintenance d’abord. Chaque site client était un assemblage d’extensions écrites par des gens différents, qui se mettaient à jour sans se prévenir. Un site pouvait casser tout seul, la nuit, sans que personne n’ait rien touché.

Le client ensuite. Son administration lui parlait de « permaliens », de « types de publication personnalisés », de « champs personnalisés ». Il ne comprenait pas, donc il n’y touchait pas, donc il rappelait. Chaque appel est du temps qui n’est facturé à personne.

Le coût enfin. Chaque site traînait sa pile d’abonnements annuels, pour des fonctions dont un dixième servait réellement.

Je passais plus de temps à réparer les sites que j’avais livrés qu’à en livrer de nouveaux.

Un client pour qui l’outil habituel ne convenait pas

Le déclencheur a un nom : TTRIP, un site de recueil de récits pour deux laboratoires de l’Université Côte d’Azur. Il fallait un back-office très précis, avec du chiffrement en base, un anonymat sans compte utilisateur et trois langues jusque dans les courriels.

Le faire sur le socle habituel, c’était l’étouffer sous les contraintes d’un outil pensé pour autre chose, et accepter une surface d’attaque qu’on ne saurait pas tenir sur dix ans. Nous l’avons écrit en PHP nu, le 24 avril 2026.

Ça a marché. Et ça a marché mieux.

Le même socle, repris et généralisé

Ce qui suit n’est pas trois projets, c’est le même back-office repris trois fois. Quatre jours après TTRIP, le socle était porté sur un client beaucoup plus banal, un food truck de Saulieu, pour voir s’il était portable. Réponse : oui, à condition de rendre optionnel tout ce qui était en dur. Un deuxième site client a suivi en mai, et c’est là que le socle est devenu un point de départ et non une réponse à un cas.

Le passage du premier au deuxième est le moment le plus délicat de toute l’histoire. C’est là qu’on décide ce qui appartient au produit et ce qui appartient à ce client-là. Chaque fois qu’on se trompe, on met dans le socle une chose qui n’y a pas sa place, et on la traîne pour toujours.

Un exemple qu’on assume encore : l’adresse d’une vidéo est rangée dans la table des articles du socle, alors qu’elle aurait dû vivre dans un module séparé. Elle y est parce que le socle ne savait pas lire une table qui n’existe que si ce module est installé. Cette limite a été levée le 13 septembre 2026, cinq mois plus tard.

Quatre décisions qui n’ont jamais bougé

Aucune dépendance extérieure. Pas de cadre applicatif, pas de gestionnaire de paquets. La raison est assumée : une dépendance, c’est quelqu’un d’autre qui décide quand votre site casse. Le prix à payer, c’est qu’il faut tout écrire.

Le client ne lit jamais un mot de jargon. Pas de « slug », pas de « type de contenu personnalisé ». L’administration parle français, avec les mots du métier de celui qui s’en sert.

Un site n’active que ce qu’il utilise. Un module principal peut être enrichi par des modules satellites qui s’accrochent à des points d’extension déclarés, jamais en modifiant le principal. Aujourd’hui trente-sept modules principaux et trente-cinq satellites.

Un module se retire. Il pose ses tables quand on l’installe, il les enlève quand on le retire. Pas de résidu. C’est exactement ce qui distingue un module d’une extension.

Le jour où « ça marche chez moi » ne suffit plus

Tant qu’il y a un site, on teste en regardant. À trois sites, on ne peut plus : personne ne rouvre trente écrans à la main avant chaque mise à jour.

C’est ce qui a fait naître une commande de diagnostic, qui passe dix-neuf familles de contrôles automatiques sur une installation : la navigation, les liens morts, les jetons de style, les points d’extension, les bibliothèques, la cohérence des modules. Elle sort aujourd’hui cinquante-neuf vérifications sur notre propre vitrine.

Sans elle, le produit aurait été impossible à vendre. On n’aurait jamais pu affirmer devant un tiers qu’une mise à jour ne casse rien.

À un homme, la documentation est toujours la première victime. Il a fallu sortir les règles du cerveau et les mettre dans des fichiers qui vivent avec le code.

Tout ce qu’il faut en plus, et que personne n’imagine

Le 15 juillet 2026, le socle entre dans un dépôt versionné sous le nom de Sillon. Voici la liste de ce qui ne sert strictement à rien quand on est seul utilisateur, et sans quoi il n’y a pas de produit.

Un installateur qui pose un site vierge sans aucune question : configuration, migrations, compte propriétaire, langue, licence. Le client tombe sur un écran de mise en route, pas sur un formulaire de base de données.

Un canal de mises à jour. Chaque version est un paquet complet avec son empreinte et sa signature. Le site vérifie la signature, sauvegarde ses fichiers et sa base, passe en maintenance, copie, migre, lance le diagnostic, et revient en arrière tout seul si le diagnostic échoue. Cent deux mises à jour sont passées par ce canal sur notre vitrine, sans une intervention manuelle.

Un système de licence qui ne prend personne en otage : sans paiement le site s’éteint, mais rien n’est perdu. Les fichiers et la base restent chez le client, et reprendre l’abonnement rallume le site tel qu’il était.

La traduction. Seize langues complètes en plus du français, avec un moteur qui gère les langues à plusieurs formes de pluriel et celles qui s’écrivent de droite à gauche. En avril, il y en avait zéro.

Et la documentation destinée au client : quatre-vingt-une pages, plus une fiche par module, fabriquées depuis les modules eux-mêmes. Le point important n’est pas leur nombre, c’est qu’elles ne peuvent pas être périmées, puisqu’elles sont écrites depuis le code qu’elles décrivent.

Le bug qu’on ne pouvait trouver qu’en s’en servant

L’outil qui vérifie le référencement déclarait « description trop longue » sur onze pages parfaitement calibrées. La cause : il comptait les caractères du code source sans décoder les entités. Chaque apostrophe française y vaut cinq caractères au lieu d’un, et une description en français en contient trois ou quatre.

Aucun test automatique ne l’aurait attrapé. Il fallait une langue à apostrophes, de vrais textes, et quelqu’un qui les calibre au caractère près. Corrigé, parti chez tous les clients par le canal de mise à jour.

C’est l’argument central de toute cette histoire : un produit se corrige par son propre usage, pas par un plan de test. Nous sommes notre premier client, et c’est ce qui rend les autres possibles.

Six semaines, mesurées

Les chiffres qui suivent sont des relevés sur le dépôt, à deux dates. Ils ne disent pas la qualité, ils disent le rythme et ce qu’il a fallu ajouter pour passer de l’outil au produit.

Cent soixante-six versions publiées en quatre mois et demi, dont cent vingt-neuf sur le seul mois de septembre. Six sites en production, tous sur la même version.

La frontière entre un outil et un produit

Un audit de sécurité offensif a été mené en conditions réelles sur une installation de test, écritures comprises. Verdict solide, et une faille réelle trouvée et corrigée. Nous n’en publierons pas le détail : des installations clientes tournent dessus.

Si vous deviez retenir une seule chose de cette histoire, ce serait celle-ci. Entre l’outil qui marche et le produit qu’on vend, il n’y a presque rien de ce qui fait le travail. Il y a l’installateur, le canal de mise à jour, la licence, les traductions, la documentation, les tests, le diagnostic. C’est-à-dire tout ce qui permet à quelqu’un d’autre de s’en servir sans vous.

C’est vrai pour un logiciel. C’est exactement aussi vrai pour un site que nous vous livrons : la différence entre un site qui marche le jour de la livraison et un site dont vous avez les clés, c’est tout ce qu’on met autour.