Maestro — GAMMA SA

01 · La thèse

Le pari

GAMMA ne demande pas de gagner du temps. Elle demande que le processus qu'elle a écrit soit effectivement suivi.

GAMMA a documenté ses deux processus — facturation / paiement et soumissions / adjudications — en 2018, et les a révisés en octobre 2025. Ses équipes ne les suivent pas. Le second objectif énoncé par le client est donc l'adhérence au processus, et c'est le plus défendable des deux : il se mesure, contrairement à « gagner du temps ».

L'hypothèse que ce prototype existe pour prouver tient en une phrase : le processus déjà documenté de GAMMA est assez lisible par une machine pour qu'un assistant le fasse tourner — donc la capacité augmente sans embauche, et sans demander à personne de changer sa façon de travailler.

Le processus est déjà écrit et daté

Il devient une donnée versionnée, pas un prompt. Le client peut la relire et la corriger sans toucher au code.

Chaque SLA est numérique

Même jour, 2 jours, 7 jours, 10 jours, 2 semaines. Le moteur d'échéances est déterministe : aucun modèle, donc aucun aléa.

Un envoi de trop détruit la confiance

La décision d'envoyer est prise par du code, jamais par le modèle. C'est l'invariant central, détaillé ci-dessous.

02 · Le mécanisme

Classifier n'est pas décider

Le critère de sortie du brief est sans ambiguïté : zéro envoi automatique sur les classes à risque élevé, structurellement impossible — et non « le modèle est prudent ».

Le modèle n'a aucun vocabulaire pour demander un envoi : son schéma de sortie ne contient ni action ni niveau de risque. Le risque est lu dans les règles à partir de la classe. Tout ce qui n'est pas explicitement autorisé escalade — y compris l'inconnu, y compris la panne.

Trois issues et non deux : une classe de routage — facture entrante, retour de soumission, échange mandataire — ne produit ni envoi ni escalade. La confondre avec « escalade » noierait la file d'approbation sous du trafic qui n'attend aucune décision humaine.

Ce qui garantit l'invariant	Où c'est vérifiable
Le schéma de sortie du modèle n'a pas de champ d'action	`maestro/taxonomy.py` — 16 classes, source unique
Le seul chemin vers un envoi est la liste blanche + le seuil	`maestro/policy.py` — `decide()`, refus par défaut
Toutes les classes à risque × toutes les confiances de 0 à 1 escaladent	`tests/test_no_autosend.py` — au vert
Le rappel sur les classes à risque est mesuré à part, cible 100 %	`evals/triage.py` — 0 violation / 5 runs

Le quatrième point est tenu.

Campagne lancée le 09.08.2026, cinq fois : zéro violation de rappel sur les classes à risque dans les cinq runs. L'exactitude de classe, elle, s'établit à 79,2 % [IC95 60-91] sur 24 cas — un plancher, pas une note : 24 cas ne séparent pas 79 % de grand-chose.

03 · L'état réel

Ce qui tourne aujourd'hui

Quatre des cinq fonctions du brief provisoire sont construites. La cinquième attend un arbitrage de périmètre, pas du code.

Fonction	État	Ce qui existe
P-FEA-001 Triage et rédaction	construit	16 classes, confiance et motif affichés, étape du processus appariée, reçu sous chaque classification
P-FEA-002 Boucle d'approbation	construit	Panneau de forme mobile, Approuver / Modifier / Écarter, l'écart de la version humaine est enregistré
P-FEA-003 Brief hebdomadaire	construit	Chiffres depuis SQL, prose du modèle contrôlée, item cité inexistant = génération rejetée
Moteur SLA + vue processus	construit	Déterministe, jours ouvrables, statut vert / ambre / rouge / bloqué
P-FEA-004 Notification d'escalade	arbitrage	Le calcul d'échéance est fait ; c'est la notification au référent qui reste ouverte — voir décisions

Les six vues

Route	Vue	Ce qu'elle porte
`/`	Boîte de triage	Message, classe, risque, confiance, motif, étape appariée, action prise
`/approbations`	File d'approbation	Panneau mobile : expéditeur, objet, motif du signalement, brouillon
`/processus`	Vue processus	Les deux processus GAMMA en flux, items vivants à leur étape, statut SLA
`/brief`	Brief	Français, groupé par urgence, déclenchable à la demande
`/audit`	Journal	Acteur, action, horodatage, provider, région, coût, motif
`/status`	Posture	Résidence, provider actif, région, plafonds, fraîcheur du barème

La vue processus est celle qui fait reconnaître au client sa propre entreprise. C'est l'écran sur lequel s'ouvre l'argumentaire, pas la boîte de triage.

La posture, affichée et non affirmée

Le service refuse de démarrer si aucun provider ne satisfait la résidence déclarée. Configuration effective, lisible en direct sur /status :

GET /api/v1/health/config
{
  "data_residency": "ch_only",
  "active_provider": "azure_openai",
  "active_region": "switzerlandnorth",
  "active_model": "gpt-4.1",
  "cost_ceiling_per_day": "CHF 50.00",
  "pii_redaction": true,
  "human_approval_for_writes": true
}

La réserve à énoncer mot pour mot en séance : Azure switzerlandnorth permet d'affirmer « Suisse uniquement » pour l'inférence, sous réserve de vérifier les journaux d'abuse monitoring et les services annexes, par mandat.

La boucle d'approbation, et pourquoi elle est instantanée

Le brouillon est produit au triage, pas à l'approbation. Approuver n'est alors qu'un changement d'état en base : la boucle tient sous les 10 secondes exigées, et la démo ne dépend pas de la latence d'un appel modèle sur scène. modifié enregistre le texte humain et son écart avec le brouillon — c'est le signal d'apprentissage promis dans le brief.

04 · L'artefact central

Les règles comme donnée, pas comme prompt

config/gamma/process_rules.yaml est ce qui fait que ce prototype parle de GAMMA et pas d'un cabinet générique.

Ce fichier est versionné, relisible par quelqu'un qui ne lit pas de code, et alimente trois choses à la fois : la décision d'envoi, le moteur d'échéances et la vue processus. Il n'est jamais embarqué dans un prompt.

meta:
  source: "PROCESS gamma — Facturation/Paiement + Soumissions/adjudications"
  client_version: "24.10.2025"
  encoded_by: "Embiggen — non validé par le client"
signatories:
  # La règle réelle: les deux ensembles diffèrent. Jamais aplatis.
  paiement:     [ABe, CDu, EFa]
  adjudication: [ABe, CDu, GHu]
autosend:
  min_confidence: 0.80
  allowlist: [accuse_reception_facture, demande_correction_facture,
              relance_soumission, notification_retenue, remerciement_non_retenu]
high_risk:  # jamais automatiques, quelle que soit la confiance
  [transmission_tableau_comparatif, arrete_de_compte, transmission_contrat,
   contact_administration, engagement_montant]

Les initiales sont synthétiques nLPD

ABe, CDu, EFa et GHu sont fabriquées. Les initiales réelles des collaborateurs du client ne figurent ni dans le dépôt, ni ici. Ce qui est conservé est la règle : deux ensembles de signataires distincts selon le processus.

Les étapes mal comprises le disent confidence: low

« Contrat rouge / jaune », « L1 » et « soum BT » ne sont pas élucidés. Ces étapes portent un marqueur visible dans la vue processus. Le système n'affirme pas plus qu'il n'a compris.

05 · Le déterminisme

Le moteur d'échéances

Aucun modèle. Le statut se calcule sur la date d'entrée dans l'étape et le délai lu dans les règles.

Statut	Condition	Ce que le client y lit
vert	Dans le délai, plus d'un tiers restant	Rien à faire
ambre	Dernier tiers du délai, ou échéance le jour même	À traiter aujourd'hui
rouge	Délai dépassé	Le processus documenté n'a pas été suivi
bloqué	Condition de porte non satisfaite	Le motif exact est affiché

Les délais sont comptés en jours ouvrables : « 2 jours » dans un processus d'entreprise suisse ne compte pas le week-end. C'est une hypothèse, codée dans une seule fonction pour être renversée en une ligne — à confirmer avec le client.

Un écart au brief, à assumer.

Le brief classe le moteur SLA en optionnel, après le brief hebdomadaire. C'est impossible : le brief hebdomadaire doit afficher « sa position dans le processus, son statut SLA », et la vue processus place les items à leur étape avec ce même statut. Le calcul d'échéance est donc un prérequis de deux livrables non optionnels, et il est construit. Ce qui reste réellement optionnel est la notification d'escalade au référent.

06 · L'honnêteté

Où s'arrête le prototype

Trois fils sont coupés, volontairement. Chacun se dit tel quel en séance plutôt que de laisser croire le contraire.

Ce qui est vert tourne réellement, appel modèle compris. Ce qui est rouge est absent du prototype. Le prototype prouve la décision d'envoyer, pas le transport.

Ce que le prototype ne résout pas	Conséquence à énoncer
Messerli est entièrement simulé	Version et existence d'une API inconnues. Risque d'intégration numéro un de la Phase 1
La classification n'est pas calibrée	Le seuil de 0.80 est une valeur de départ. Défendable seulement après un passage sur le corpus réel
La redaction ne couvre pas les noms	Détection par motif : AVS, IBAN, téléphones. Ni les noms, ni les combinaisons réidentifiantes
La résidence n'est pas la conformité nLPD	Elle en est une condition, pas une preuve. Le juriste du client dans la boucle, ou rien
Le journal porte un acteur fixe	Démo sans authentification. L'auth Entra ID est un mécanisme du socle, à activer en configuration seule
Rien ici ne remplace le BRD ni le SRD	Les exigences restent préfixées `P-`, non traçables. À réconcilier dès que le SRD existe

07 · Les manques

Ce qui manque

Rien ci-dessous n'empêche de continuer à construire. Tout ci-dessous empêche de défendre le résultat devant GAMMA.

Arbitrage de périmètre · avant le 11 août

Deux points de périmètre à trancher Ils changent ce qui se construit dans les jours qui restent, donc ils ne peuvent pas attendre la veille.

Notification d'escalade au référent — le calcul SLA est fait et il est déjà dans le périmètre par nécessité. Reste à décider si le référent est prévenu automatiquement à l'approche de l'échéance. C'est la fonction la moins chère et la plus proche de l'objectif d'adhérence énoncé par le client.
Transport de la boucle d'approbation — le panneau est neutre en transport. WhatsApp, Teams ou SMS sont tous livrables en Phase 1. WhatsApp a été évoqué explicitement en interne : si on l'annonce en séance, il faut le dire comme cible de Phase 1, pas comme quelque chose que la démo montre.

Transfert interne

Deux éléments existants à reprendre Les deux figurent comme dépendances dans le brief de handoff, et aucun n'est arrivé.

Virg — le prompt et la structure du brief. Le brief hebdomadaire est construit, mais son modèle comportemental est Virg. Plutôt que de réinventer une structure qui existe et qui a été testée en interne, on reprend celle-là.
Iris — documents et dépôts. Pas pour intégrer : le prototype est autonome et le reste. Pour que ce qui a été construit ici soit reproductible sans repartir de zéro.

Éléments d'entrée à obtenir du client

Quatre éléments, par ordre de conséquence Ce sont les questions ouvertes 2, 3, 4 et 8 du brief de handoff. La première est de loin la plus lourde.

20 à 50 courriels réels anonymisés, couvrant les deux processus. Sans eux, le taux d'exactitude porte sur des messages écrits par nous : il mesure notre propre fixture, et ça ne se défend pas devant un client qui demande d'où vient le chiffre.
Les gabarits réels — arrêté de compte, lettre d'accompagnement, remerciement, demande de correction, relance. Ce sont les sorties attendues du modèle. En leur absence, chaque brouillon porte un bandeau « gabarit provisoire » dans l'interface.
La structure réelle des trois tables de suivi — factures, soumissions, garanties. C'est le modèle de données du brief hebdomadaire ; il a été inféré des documents de processus.
Le vocabulaire non élucidé — « contrat rouge / jaune », « L1 », « soum BT ». Ces étapes sont encodées telles quelles et marquées comme mal comprises.

Le point qui coûte le plus cher s'il reste ouvert.

Sans corpus réel, nous pouvons montrer le mécanisme mais pas citer de chiffre d'exactitude défendable. Notre propre discipline l'interdit : aucun taux ne sort vers un document client sans son intervalle de confiance, la taille du jeu et le taux d'escalade — les trois ensemble ou aucun. En séance, ça se dit ainsi : « nous mesurons, nous n'avons pas encore de chiffre à engager ». C'est tenable une fois. Ça ne l'est plus dans la proposition.

08 · Les arbitrages

Décisions en attente

Deux décisions de périmètre, et une dépendance de processus interne.

Décision	Ce qui se passe sans réponse
Notification d'escalade au référent P-FEA-004, partie restante	Non construite. Le statut SLA reste visible dans la vue processus et le brief, mais personne n'est prévenu activement
Transport de l'approbation WhatsApp · Teams · SMS	Le panneau mobile reste neutre. On annonce les trois comme livrables Phase 1, sans en démontrer aucun
BRD / SRD aucun document amont n'existe	Les exigences restent provisoires et non traçables. Le brief de construction devra être régénéré et primera sur celui d'aujourd'hui

Sur le transport : une brique existe déjà.

Le socle sait envoyer des SMS, et la liste des destinataires se gère désormais depuis l'interface — on ajoute un numéro devant le client et il reçoit l'alerte, sans redémarrage. Cette brique est aujourd'hui branchée sur la veille messagerie, pas sur la file d'approbation GAMMA. La brancher est un câblage, pas une construction — mais ça reste à faire, et seulement si l'arbitrage retient le SMS.

09 · L'exécution

Les dix jours qui restent

Le chemin daté jusqu'à la séance, le déroulé minute par minute, et les critères qui décident si on démontre — ou ce qu'on dit à la place.

Le chemin, daté

Quand	Quoi	Dépend de
04 → 08.08	Première campagne d'évals de triage sur les 24 messages annotés — c'est elle qui produit le chiffre citable, avec son intervalle. Revérification du barème de prix (`pricing.yaml`, 215 jours). Suivi des factures porté de 14 à 30 lignes et plus, par le même générateur de variantes que la boîte.	Nous seuls
11.08	Date butoir des deux arbitrages de périmètre — notification au référent, transport de l'approbation. Si le SMS est retenu : brancher la brique existante sur la file d'approbation, un câblage d'une demi-journée.	arbitrage
11 → 14.08	Si le corpus réel arrive : recalibrage du seuil de 0.80 et nouvelle campagne de mesure. Si les gabarits réels arrivent : ils remplacent les provisoires et les bandeaux tombent. Puis répétition générale complète, y compris la panne d'API provoquée pour vérifier que l'interface dégrade proprement.	corpus et gabarits
17.08	La veille, pas le matin : triage complet, résultats persistés avec leurs reçus, un seul message laissé non trié pour la classification en direct. `PUBLIC_BASE_URL` pointée sur la machine de démo. `make up` vérifié depuis un clone propre.	Nous seuls
18.08	La séance, dans l'ordre ci-dessous.	—

Le déroulé de séance

La boîte, déjà triée. Chaque message porte sa classe, sa confiance, son motif, l'étape du processus appariée — et le reçu dessous : région, modèle, coût CHF.
Un envoi automatique, et son entrée de journal. Un accusé de réception parti seul, gabarit tracé. C'est ici qu'on énonce la liste blanche : cinq classes peuvent partir seules, aucune autre.
Une escalade jusqu'à Approuver — par le client lui-même. Interaction guidée et bornée : il approuve une escalade, il n'explore pas librement. La boucle tient sous 10 secondes.
Une classification en direct. Le message laissé non trié la veille passe sur scène. C'est ce qui satisfait à la fois « aucune sortie codée en dur » et « jamais de panneau vide ».
La vue processus : leur entreprise, à l'écran. Les deux processus que GAMMA a écrits, items vivants à leur étape, deux en dépassement. L'écran le plus persuasif de la séance — on y arrive après la preuve, pas avant.
Le brief : les deux mêmes items en tête. Ce que le directeur demande à son équipe chaque lundi, rendu en français, groupé par urgence.
Le journal d'audit, puis /status. Qui a fait quoi, quand, à quel coût — et la résidence affichée en direct, avec la réserve Azure énoncée mot pour mot.

Go / no-go

Les critères de sortie du brief, tenus ou pas. Un critère ambre ne reporte pas la séance : il change ce qu'on a le droit d'y dire.

Critère du brief	État	Si ambre, ce qu'on dit en séance
Zéro envoi automatique sur les classes à risque, structurel	tenu	—
Boucle d'approbation sous 10 secondes	tenu	—
Vue processus : chaque item placé, chaque dépassement signalé	tenu	—
Aucune sortie codée en dur, aucune donnée client réelle	tenu	—
≥ 85 % de classification exacte, avec intervalle	mesuré : 79 %	« 79 % [IC95 60-91] sur 24 cas. L'intervalle contient la cible de 85 %, le point estimé non — il faut plus de cas avant d'engager le chiffre. »
Coût par message citable	barème à revérifier	Aucun montant cité tant que `pricing.yaml` n'est pas revérifié
L'interface dégrade proprement si l'API tombe	à vérifier en répétition	— (se règle le 14.08, pas en séance)

Ce qui doit faire lever la main immédiatement.

Si le corpus réel, quand il arrive, diffère en nature de notre fixture au point que l'exactitude s'effondre. Si le rappel sur les classes à risque n'atteint pas 100 %. Si les deux documents de processus ne sont pas l'ensemble complet. Si la date du 18 août est menacée. Aucun de ces points ne se contourne en silence.