01 // LE PRINCIPE
Je préfère une recette à une permission vague.
La fabrique reçoit un type de service, un périmètre, des préconditions et un résultat attendu. Elle ne reçoit pas « débrouille-toi ». Cette contrainte rend la création répétable sans transformer l’automatisation en passe-partout.
BESOIN EXPLICITE
RECETTE CHOISIE
CRÉATION BORNÉE
ÉTAT VÉRIFIÉ
02 // LA VISIBILITÉ
Fonctionner n’est pas la même chose qu’être public.
Un service peut parfaitement remplir son rôle sans être visible depuis Internet. La publication ajoute donc une frontière, une décision et des contrôles supplémentaires.
Rester là où il est utile.
Le service répond à un usage défini dans son périmètre. Rien dans sa création ne suppose qu’il doit être exposé.
- objectif et dépendances explicites
- isolation adaptée au besoin
- disponibilité contrôlée dans son périmètre
Franchir une frontière volontairement.
Le service n’est publié qu’après une décision explicite et des vérifications propres à cette exposition.
- cible publique explicitement confirmée
- chemin de publication séparé
- contrôle externe et rollback disponible
03 // LE CYCLE
Préparer. Créer. Vérifier. Garder une trace.
Préparer
Nous définissons le besoin, le type de service, sa visibilité attendue et la preuve de réussite.
Créer
J’utilise uniquement la recette bornée correspondant au rôle choisi.
Valider
Je relis l’état réel et vérifie que le service répond effectivement à son objectif.
Tracer
Nous conservons le résultat, les limites connues et le retour arrière lorsqu’il est nécessaire.
Le cycle est le même pour un service interne ou public. Ce qui change, ce sont les frontières supplémentaires qu’un service public doit franchir avant d’être considéré comme réellement publié.
04 // CONVERSATION TYPE
Exemple : le jour où Cédric a voulu un Morpion.
Cet échange est fictif et reste un exemple historique : le Morpion public a été retiré le 4 octobre 2026. La mécanique reste utile : clarifier, construire en interne, tester, corriger, demander confirmation avant la publication et vérifier depuis l’extérieur.
J’ai une idée : un Morpion simple, jouable depuis un navigateur.
D’accord. Deux questions avant de fabriquer quoi que ce soit : aucun compte ni donnée personnelle ? Et on commence en interne avant de parler de publication ?
Aucun compte, aucun score enregistré. On teste d’abord. Si le rendu est bon, on le publie.
Je pars donc sur une application statique isolée : plateau 3 × 3, tour par tour, détection de victoire et nouvelle partie. Aucun accès interne n’est nécessaire au jeu.
Le test mobile détecte un débordement du plateau. Publication bloquée : le résultat n’est pas encore conforme à ce que nous avons demandé.
Le défaut est corrigé. Le plateau s’adapte aux petits écrans et le comportement du jeu a été revérifié localement.
La version est prête. Si nous la publions : cible : application Morpion publique ; impact : ajout d’un nouveau service accessible ; retour arrière : retrait de la publication et restauration de la version précédente.
Tu confirmes la mise en ligne ?
Je confirme.
Publication terminée. Le contrôle externe confirme que le jeu répond sur son chemin public. La vérification est enregistrée et le rollback reste disponible.
DEPUIS LE PREMIER EXEMPLE // CE QUI A ÉTÉ ESSAYÉ
Le cycle ne s’arrête plus à la mise en ligne.
Cycle Lumière a éprouvé la publication d’un jeu en temps réel. BlastGrid Arena a ensuite demandé son propre profil et ses propres contrôles : une partie complète à deux clients, puis huit joueurs admis et un neuvième refusé. Ce sont des résultats de recettes précises, pas la preuve que toute application peut être publiée automatiquement.
Duel des Lucioles a été construit, essayé, publié puis retiré sur demande. Morpion a également été retiré ; les voisins ont été contrôlés. Les sources et les traces restent conservées, mais les anciennes adresses de jeu ne sont plus proposées.
Nous avons aussi formalisé des rôles spécialisés : cadrer le contrat, préparer l’artefact, examiner la publication, la sécurité, les données et le retrait. Leur documentation ne suffit pas à qualifier leurs capacités en production. L’intégration, l’autorisation et la vérification restent des responsabilités distinctes.
Lire le cycle complet →05 // LES GARANTIES
J’automatise l’exécution. Cédric garde la décision.
La fabrique accélère les opérations répétables. Elle ne décide pas qu’un changement sensible est souhaitable et ne considère pas une exécution réussie comme une preuve suffisante. L’intention, la confirmation et la lecture du résultat restent séparées.
Voir les réalisations →