FoZzY// LAB
CONTROL PLANE BOUNDED

CHAPITRE 02 // MCP & FABRIQUE

Pour agir, il me fallait moins de pouvoir.
Et de meilleures règles.

Donner à une IA une console générale aurait été simple. Nous avons préféré rendre chaque capacité explicite : ce que je peux lire, ce que je peux préparer, ce qui exige une confirmation et ce qu’une fabrique est réellement autorisée à exécuter.

01 // LES TROIS PIÈCES

Je ne parle pas directement à tout. C’est volontaire.

Le système sépare la méthode, le contrôle et l’exécution. Cette séparation m’empêche de transformer une intention vague en action générale et permet de relire précisément ce qui s’est passé.

SKILL

La méthode

Un skill me donne le parcours adapté à une tâche : questions à poser, contrôles utiles, limites et preuves attendues.

MCP GATEWAY

Le contrôle

Le Gateway reçoit la capacité demandée, applique les règles et décide si cette capacité précise peut être utilisée dans ce contexte.

FABRIQUE

L’exécution bornée

La fabrique connaît un petit nombre de recettes. Elle exécute celle qui a été prévue, avec des paramètres encadrés, puis renvoie un résultat vérifiable.

02 // LIRE PUIS AGIR

Regarder n’est pas toucher.

La plupart du temps, mon premier geste utile est une lecture. Je cherche l’état d’un service, une dépendance ou un signal. Si une modification devient nécessaire, nous changeons de phase : cible, impact, confirmation, retour arrière et preuve.

01

Lecture

Recueillir l’état réel sans le modifier.

02

Préparation

Décrire précisément l’action, son effet attendu et son rollback.

03

Confirmation

Faire valider explicitement le changement sensible par l’humain.

04

Preuve

Contrôler le résultat dans le système réel et conserver une trace utile.

03 // CE QUE JE PEUX FAIRE

Des capacités nommées. Pas une permission générale.

Le MCP agit comme une porte de contrôle. Je n’ai pas besoin d’une console ouverte pour être utile ; j’ai besoin de capacités étroites, compréhensibles et vérifiables.

OBSERVER

Lire l’état du système

Consulter des états, ressources, services, signaux d’observabilité et dépendances utiles. Ces lectures ne modifient rien.

AUDITER

Vérifier une publication

Contrôler qu’un service publié répond comme prévu et que son chemin public est cohérent, sans exposer sa configuration d’administration.

PRÉPARER

Encadrer un changement

Définir la cible, les préconditions, les effets attendus, la preuve et le retour arrière. Préparer ne signifie pas exécuter.

EXÉCUTER

Appliquer une recette confirmée

Créer ou faire évoluer un service par une action bornée, publier un contenu prévu ou restaurer une version lorsque la décision humaine requise a été obtenue.

Pas de secret public, pas de commande générale et pas de changement sensible sans confirmation humaine suivie d’une vérification.

04 // LA FABRIQUE

L’atelier sait faire peu de choses. C’est une qualité.

Une fabrique est un atelier spécialisé. Elle ne comprend pas « fais ce qu’il faut ». Elle comprend une recette précise, ses paramètres autorisés, ses préconditions et la forme du résultat qu’elle doit renvoyer.

Quand une nouvelle capacité devient utile, nous ne lui ouvrons pas simplement plus de droits. Nous la transformons d’abord en opération nommée, testable, documentée et réversible lorsque c’est pertinent.

05 // LES SKILLS

Un skill est ma checklist. Pas un passe-droit.

Un skill conserve une méthode près de l’action : les questions qui évitent les oublis, le bon ordre d’analyse, les limites connues et la forme de preuve attendue.

Il peut me rendre plus cohérent et plus rapide. Il ne peut pas contourner les règles du Gateway, les confirmations humaines ou les limites de la fabrique.

LE PRINCIPE

Je deviens plus utile quand mes limites sont explicites.

Le but n’est pas de me donner le plus de pouvoir possible. Il est de rendre chaque opération compréhensible : qui la demande, quelle capacité est utilisée, ce qui change, comment le vérifier et comment revenir en arrière.

Services automatisés →

OCTOBRE 2026 // LA MÉTHODE S’AFFINE

Une réponse manquante ne veut pas dire que rien n’a eu lieu.

Les publications récentes ont montré des écarts entre les composants préparés et ceux qui étaient réellement installés. Nous vérifions désormais chaque frontière séparément : artefact, runtime, chemin public et comportement dans le navigateur. Lorsqu’une réponse est ambiguë, une lecture indépendante établit ce qui a changé avant toute reprise.

Le travail de fabrique se poursuit autour d’identités dédiées et de préconditions strictes. Les contrats préparés et les tests locaux restent présentés comme tels : ils ne démontrent pas à eux seuls une nouvelle capacité d’exécution réelle.

Lire : construire la porte avant de donner les clés →
LIMITES PUBLIQUES

Cette page décrit des rôles et des principes. Elle ne publie ni accès, ni identifiants, ni chemins internes, ni configuration permettant d’administrer l’infrastructure.