Le socle · la fabrique

De l’idée à la production,
par le même chemin à chaque fois.

Une application de la flotte ne part jamais d’une page blanche. Un cadrage écrit, un gabarit qui engendre tout le projet, des fiches qui disent comment écrire chaque besoin, et une livraison qui promeut en production exactement ce qui a été éprouvé en recette.

Les étapes

Retour au socle

À quoi elle sert

Plus de cinquante applications vivent dans notre dépôt. Elles se ressemblent parce qu’elles naissent toutes de la même façon : par la fabrique. C’est un ensemble d’outils et de règles — une méthode de cadrage, un gabarit d’application, un catalogue de cas d’usage, un dépôt Maven embarqué, une chaîne de livraison — qui fait qu’une nouvelle application consacre son temps à son métier, et seulement à lui.

Les étapes

1. Cadrer : la méthode Besoin→Plan

La règle est simple : la méthode d’abord, et aucun code avant le go. La chaîne va du besoin à l’exécution : vision, spécification des besoins, récits utilisateurs, fonctionnalités et épopées, arbitrages, phasage par étapes contrôlées, plan technique avec sa matrice de couverture, puis exécution. Trois de ces temps passent par une relecture.

Avant le go, un contrôle vérifie que le plan respecte les règles de la plateforme : la nomenclature des tables, l’identité par l’annuaire du Hub, l’exposition par sa passerelle d’API, les secrets en coffre, « rien de réécrit » de ce que la plateforme rend déjà, et la traçabilité du besoin jusqu’au plan. Tout écart non levé bloque le go.

La méthode a sa propre page : la méthode →

2. Engendrer : le gabarit et son bootstrap

Une seule commande, bootstrap.sh, avec le nom de l’application et son identifiant. Elle :

• valide l’identifiant et en dérive le nom du schéma PostgreSQL de l’application ;
• écrit le projet : le pom.xml, le manifeste de déploiement, le Dockerfile, le script SQL d’initialisation, la configuration et la journalisation ;
• pose le code de départ : le point d’entrée, le filtre de connexion unique, la route « qui suis-je », la déconnexion, la redirection de l’interface, et un premier Worker ;
• recopie les 148 fiches de cas d’usage dans l’application, pour qu’elle reste autonome ;
• prépare la livraison : le script, les cibles de déploiement et le flux d’intégration continue ;
• monte le chantier de la méthode, avec ses dossiers de M0 à M7, ses spécifications et son dossier de preuves ;
• branche l’interface, sur option : le cadre lmvi-ui, épinglé sur une version ;
• crée le dépôt git de l’application, avec un filet qui bloque le premier commit si un fichier sensible s’y trouve ;
• ouvre le chantier visible : un salon du Hub et quatre tableaux dans TheDash — une frise, des couloirs, la répartition humain-agent, une carte — pour suivre la fabrication.

L’interface engendrée repose sur la bibliothèque commune : lmvi-ui →

3. Écrire : d’abord le Hub, puis les fiches

Avant d’écrire une ligne, la règle de routage s’applique, dans cet ordre :

1. Le besoin est-il déjà un service du Hub ? Annuaire, coffre, passerelle d’API, messagerie, courrier, stockage, DNS… Si oui, on le consomme. Les 46 guides pratiques du Hub disent comment.
2. Ce qui reste à écrire se cherche dans les 148 cas d’usage du framework, et l’on suit la fiche : elle dit par quel mécanisme passer, et pourquoi.
3. Rien ne couvre le cas ? On le dit avant de coder, et l’on enrichit le catalogue une fois la solution trouvée.

L’ordre compte : pris à l’envers, on réécrit un service que la plateforme rend déjà.

Le type de Worker se choisit par une question — appeler un service externe, tâche répétée, tâche à heure fixe, piloté seulement par des appels, réagir à un événement, consommer Kafka, agréger, recevoir un webhook, enchaîner des étapes, servir des pages : les types de Workers →

Les capacités métier déjà mutualisées s’embarquent par un pack : les packs →. Les données métier vont dans PostgreSQL, selon un standard maison de nommage des tables et de colonnes techniques communes.

4. Construire : le dépôt Maven embarqué

Le framework n’est publié ni sur Maven Central ni sur un dépôt public tenu à jour. Le choix fait : vendoriser. Le framework, son parent Maven, sa nomenclature de versions (BOM) et les packs sont rangés dans un dossier mvn-repo/ commité avec le code. Un clone frais compile sans rien installer ; cela a été vérifié sur un poste vierge.

Le parent Maven du socle fournit la version du framework, importe la nomenclature des versions testées, et porte une règle qui refuse une combinaison non éprouvée.

À côté de Maven, des paquets servent à démarrer ou à faire monter de version : un StarterPack pour partir de zéro (squelette, framework, pilotes, documentation), un UpgradePack qui ne porte que le différentiel pour une application existante, un paquet équivalent pour le Hub, et le cadre d’interface.

5. Publier l’image, et la décrire

L’image tourne sur GraalVM Community 21. Elle porte le jar exécutable de l’application et son dossier repository/ — les scripts compilés à chaud et les tables de décision.

Chaque application porte un manifeste de déploiement, lu par le Hub : son identifiant, son point de santé, sa base, sa connexion unique, ses rôles et portées, sa porte MCP, et les noms des variables que le Hub lui injecte — jamais leurs valeurs.

6 à 8. Recette, épreuve, production

Temps	Ce qui se fait
Situer	Relever les versions en recette et en production ; si la production est en avance, on s’arrête
Construire	Monter la version dans le pom.xml et le manifeste ensemble ; jamais un tag réutilisé
Publier	Construire l’image et la pousser vers le registre privé de la flotte
Poser en recette	Une action du Hub : installer la première fois, mettre à jour ensuite
Éprouver	Voir la fonctionnalité marcher et ranger les preuves datées
Promouvoir	Sur accord explicite, le même tag en production, et les mêmes vérifications

À la première installation, une seule action du Hub provisionne la base, crée le coffre de l’application, demande son certificat, tire l’image, démarre le conteneur, inscrit sa route et sa portée dans l’annuaire.

Le principe de la promotion est écrit en tête du script de livraison : on ne construit que pour la recette ; une promotion réutilise l’image déjà publiée — mêmes octets. Ce qui part en production est exactement ce qui a été éprouvé.

L’intégration continue construit et livre en recette à chaque envoi sur la branche principale ; la promotion se déclenche à la demande. Trois règles tiennent le tout : on prouve au lieu de supposer, on annonce avant d’agir, on rapporte les échecs tels quels.

Pour le Hub lui-même et les montées de version du framework, une étape de plus : un canary, un essai isolé d’une vingtaine de minutes contre le schéma réel de la cible, avant toute production.

9. Superviser, et savoir revenir

Chaque application expose, sur son propre port : sa santé (vivante, prête), ses métriques, son état, son tableau de bord et sa porte MCP. Le Hub en lit l’état et les journaux, et agrège ses outils MCP.

Revenir en arrière, c’est remettre l’image précédente par la même action du Hub ; la route ne bouge pas. Une migration de base, elle, ne se défait pas avec l’image : elle se pense avant la livraison.

Chaque dépôt tient enfin sa mémoire : un dossier WhoAmI — identité, architecture, journal, état du code, conventions, feuille de route, instantanés datés — mis à jour après chaque travail significatif et versionné dans notre suivi central.

• 148
  Cas d’usage, en 17 familles
• 46
  Guides pratiques des services du Hub
• 9
  Temps, de l’idée à la production
• 1
  Seule image, de la recette à la production

Ce qu’elle apporte

Un cadrage de démonstration — « développer et déployer en trente minutes » — porte sur IdéeBox. Et toutes les réalisations sont passées par cette fabrique.

Une application à construire ?

Elle passera par cette fabrique : le temps du projet ira à votre métier.

Nous écrire

Retour au socle