Votre site vitrine peut devenir votre outil de gestion

Une association sportive tenait son administration comme beaucoup de petites structures : des tableurs, des carnets, et la mémoire de la personne qui s'en occupe. Son site web, lui, affichait les horaires et les tarifs, avec un formulaire de contact.

Ce même site prend aujourd'hui en charge les inscriptions, les abonnements, les absences et la déclaration comptable mensuelle. Pas un second outil acheté à côté : le site lui-même est devenu le logiciel de gestion.

Voici ce qui rend ce passage possible — et pourquoi, la plupart du temps, il ne l'est pas.

Pourquoi ça finit presque toujours par une réécriture

Le scénario habituel est connu. Le site vitrine marche très bien pour ce qu'il fait. On lui ajoute un formulaire d'inscription, puis un tableau des présences, puis un suivi des paiements. Chaque ajout est raisonnable pris isolément. Et un jour le constat tombe : « il faudrait tout refaire proprement ».

La cause n'est pas le manque de compétence de celui qui a construit le site. Elle est structurelle : un site vitrine et un outil de gestion ne reposent pas sur les mêmes fondations, et on ne glisse pas les secondes sous un bâtiment déjà habité sans le vider.

D'où la seule règle qui compte ici, et qui résume tout l'article :

Les fondations avant les fonctionnalités. Pas l'inverse, et pas « on verra plus tard ».

D'abord, ne pas jeter ce qui existe

Première étape, avant toute nouveauté : reconstruire le site sur une base solide sans changer une virgule à son apparence.

L'ancien site a été gardé comme référence intouchable. Le nouveau a été rebâti derrière — un moteur différent, un contenu entièrement modifiable depuis un éditeur de texte — avec une contrainte stricte : l'apparence doit rester identique au pixel près. Ce n'est pas une promesse, c'est une vérification : les écrans de l'ancien site ont été capturés, et les deux versions sont comparées automatiquement à chaque modification. Un écart d'affichage fait échouer le contrôle.

Pour le client, la traduction est simple : votre site ne bouge pas pendant qu'on remplace le moteur en dessous. Vos visiteurs ne voient rien. Vous ne perdez ni votre référencement, ni vos habitudes, ni la validation esthétique que vous aviez déjà donnée.

C'est le genre d'exigence qui paraît tatillonne jusqu'au jour où une refonte vous fait perdre trois mois à re-valider des maquettes que tout le monde avait déjà approuvées.

Les trois fondations, et pourquoi elles passent en premier

Une fois la base saine, trois choses ont été posées avant la moindre fonctionnalité de gestion. Aucune des trois ne se voit à l'écran. Toutes les trois décident de ce qui sera possible ensuite.

Le multi-structures. Le site d'un studio est devenu une plateforme capable d'en accueillir plusieurs : chacun avec ses coordonnées, son logo, sa couleur, son domaine, sa propre publication. Pourquoi d'abord ? Parce que transformer après coup une application mono-structure en plateforme touche à peu près chaque requête de la base. Fait au départ, c'est une décision de conception ; fait après, c'est la réécriture qu'on voulait éviter.

Le contrat d'interface. Ce que le serveur expose est décrit noir sur blanc, et ce contrat est vérifié automatiquement. Conséquence concrète : la partie visible et le moteur évoluent séparément sans se casser mutuellement, et le jour où un autre outil doit se brancher — une comptabilité, une billetterie — il y a quelque chose à quoi se brancher.

L'isolation. Un test vérifie qu'une structure ne voit jamais les données d'une autre. C'est le genre de garantie qui ne s'ajoute pas plus tard : soit elle est vérifiée depuis le premier jour à chaque modification, soit vous n'en savez rien. Pour des données d'adhérents, cette différence n'est pas théorique.

Ces trois-là sont arrivées ensemble, dans une première passe qui ne livre aucune fonctionnalité visible. C'est contre-intuitif à expliquer — on paie une étape dont le client ne voit rien — mais c'est exactement ce qui évite la facture bien plus lourde d'après.

Ce que « gestion » veut dire, concrètement

La suite, c'est la reprise une par une des choses que l'association faisait à la main :

• les inscriptions, validées manuellement, avec leurs statuts successifs ;
• les abonnements et les quotas de séances ;
• les pauses, et le gel des abonnements pendant les fermetures de la structure ;
• les absences, avec leurs conséquences ;
• les paiements, sans terminal bancaire ;
• les exports tableur ;
• la déclaration comptable mensuelle.

Chacun de ces points est un tableur, un carnet ou un pense-bête qui disparaît. Et chacun est une occasion de se tromper en moins.

C'est aussi là qu'on mesure l'intérêt d'avoir posé les fondations : ces fonctionnalités s'ajoutent les unes après les autres sans toucher à ce qui existe déjà. Elles n'ont pas à renégocier l'architecture, elle est là.

Les décisions restent les vôtres

Le point qui compte pour un dirigeant, et qu'on escamote souvent quand on parle d'outils : savoir qui tranche.

Une règle comme « un abonnement souscrit après l'annonce d'une fermeture n'est pas gelé » n'est pas une question technique. C'est une décision de gestion, avec des conséquences sur l'argent et sur la relation aux adhérents. Elle se tranche par la personne responsable, puis se trace par écrit, puis s'exécute. Dans cet ordre.

C'est ce qui distingue un outil sur mesure d'un logiciel du commerce : vos règles ne sont pas celles que l'éditeur a choisies pour vous. Encore faut-il qu'elles soient écrites quelque part plutôt que dans la tête de la personne qui les applique — et c'est précisément ce que le passage au logiciel oblige à faire.

Comment la qualité est tenue

La conception du projet a été relue par un relecteur indépendant du concepteur, avec un droit de refus réel. Au premier passage, elle a été recalée : une règle de gestion n'était pas reportée partout où elle s'appliquait. Elle est repassée après correction.

Ça mérite d'être dit, parce que c'est le genre de détail qu'on ne met jamais en avant : la conception a été refusée une fois avant d'être acceptée. Un relecteur qui valide tout du premier coup ne relit pas.

Ensuite, pendant la fabrication, chaque élément est développé dans sa propre copie du projet, et son intégration est conditionnée à une batterie de contrôles automatiques : les tests, le respect du contrat d'interface, l'isolation entre structures, la comparaison des écrans. Un contrôle rouge bloque l'intégration. Pas d'appréciation, pas de « c'est un détail, on corrigera après ».

Enfin, chaque étape se termine par une vitrine publique : le parcours réel, filmé dans un vrai navigateur, pas une démonstration commentée en réunion. Deux de ces films sont en ligne — l'édition du site par la gérante, et la réservation des séances de bout en bout.

Le quotidien, en une capture d'écran

Voici mon écran pendant la fabrication. C'est la partie dont on ne montre jamais rien, et c'est pourtant celle qui décide si un projet de ce genre est tenable ou pas.

Trois choses s'y lisent (cliquez pour agrandir).

Un backlog découpé pour être exécuté sans réexplication

À droite, trois chantiers avancent en même temps, chacun dans sa propre copie du projet. Ce parallélisme n'est pas une prouesse d'outillage : c'est la conséquence directe de la façon dont le travail a été découpé.

Pour qu'un élément du backlog parte sans accompagnement, il doit porter avec lui tout ce qu'il faut pour être exécuté puis jugé :

• un identifiant et un périmètre — ce qui est dedans, ce qui n'y est pas ;
• les contrôles qui l'acceptent ou le refusent, décidés à l'avance plutôt que négociés à la livraison ;
• ses dépendances, écrites. C'est le point que la capture illustre le mieux : un des chantiers a démarré plus tard que les deux autres, parce qu'il part du socle et devait l'attendre. Ce n'est pas un retard, c'est une dépendance respectée.

C'est ce qu'on appelle un backlog prêt pour une exécution par des agents. La différence avec une liste de souhaits est entière : une liste de souhaits ne se parallélise pas, parce que chaque ligne demande qu'un humain vienne réexpliquer ce qu'elle veut dire. Un backlog découpé ainsi, oui — et c'est là que le temps se gagne, pas dans la frappe du code.

Au centre de l'écran, le registre du projet joue le rôle de source de vérité : chaque étape, chaque intégration, chaque décision y est inscrite. N'importe qui — un autre intervenant, moi après une interruption — peut reprendre là où on en est sans que personne ait à raconter l'historique de mémoire.

Ce que je fais, moi, dans cette journée

À gauche, la question que j'ai posée : « pourquoi je vois trois chantiers et pas quatre ? »

C'est une question de responsable, pas de développeur. Et la réponse arrive au bon niveau : la première passe ne construit que les trois pièces de fondation — le socle, le schéma de données, le contrat d'interface — et le chantier des inscriptions n'a rien à faire tant qu'elles n'existent pas ; il démarrera à la passe suivante, conformément au planning que j'avais validé.

Retenez la forme de cet échange, parce que c'est le cœur du sujet : je pose une question en langage courant, j'obtiens une réponse qui se vérifie contre le plan que j'ai signé, et je n'ai pas eu à lire une ligne de code. C'est exactement ce qui rend le rôle de décideur tenable sur un projet technique — et ce qui manque quand on vous répond « c'est compliqué à expliquer ».

Ma journée ressemble donc à ceci : je lis où on en est, je réponds aux questions qui demandent un arbitrage métier, je vérifie le rapport avant d'autoriser une intégration, et je signe les étapes. Les décisions restent à leur place. Ce qui change, c'est que je passe mon temps à décider plutôt qu'à attendre.

L'échec en rouge n'est pas un incident

Un des contrôles vient de tomber, et c'est écrit en toutes lettres à l'écran.

Rien ne s'intègre tant qu'il n'est pas repassé au vert : le chantier corrige et relance, et le rapport est relu avant toute fusion. Un tableau de bord entièrement vert en permanence ne prouverait rien — sinon que les contrôles ne cherchent pas grand-chose. Voir un rouge, c'est voir le dispositif fonctionner : j'en parlais à propos d'un autre projet où vingt-deux erreurs ont été introduites volontairement pour vérifier que chaque contrôle savait dire non.

Ce que ça change pour vous

Si vous avez un site vitrine et que votre administration vit dans des tableurs, la question n'est pas « faut-il un logiciel ? » mais « sur quoi va-t-il reposer ? ».

Trois questions suffisent à juger une proposition :

• Mon site change-t-il d'apparence pendant l'opération — et comment le vérifiez-vous ?
• Ce qui conditionne la suite (plusieurs structures, un contrat d'interface, l'isolation des données) est-il posé avant les fonctionnalités, ou promis pour plus tard ?
• Les contrôles qui autorisent une mise en production ont-ils déjà bloqué quelque chose ?

Les limites, dites franchement

Deux choses que je ne vais pas enjoliver.

Le code de ce projet n'est pas public. C'est un outil de gestion client, avec des données d'adhérents : c'est le seul projet dont je parle ici sans pouvoir vous renvoyer au dépôt. Ce qui est public, c'est la méthode qui l'encadre, et les parcours filmés des étapes déjà livrées. Si cette vérifiabilité compte pour vous, dites-le dès le départ : elle se décide au moment du cadrage, pas à la fin.

Les fondations se paient avant d'être utiles. La première passe ne livre rien de visible. C'est inconfortable à vendre et inconfortable à acheter. La seule honnêteté possible est de le dire au moment du devis plutôt que de le découvrir ensemble.

Et la part humaine ne diminue pas. Reprendre les contenus réels, vérifier avec les personnes qui utiliseront l'outil, basculer sans perdre l'historique : c'est ce travail-là qui dimensionne le projet, et c'est le vôtre autant que le mien.

Si vous voulez regarder ce que ça donnerait chez vous, parlons-en. La méthode et ses garde-fous sont documentés publiquement : gilmry.github.io/foyer.