Le déterminisme, et ce qu'il veut vraiment dire

Le contrat de nœud#

Chaque étape d'un workflow déclare ce qu'elle accepte en entrée et ce qu'elle doit produire en sortie. Ces deux schémas sont vérifiés à l'exécution, pas dans la documentation.

Si la sortie du modèle ne respecte pas le schéma, elle est refusée. Le nœud relance l'appel en transmettant l'erreur de validation, puis échoue si le modèle n'y arrive toujours pas. Il n'y a aucun chemin par lequel du texte libre serait découpé à la main pour en extraire un montant ou une adresse.

Entrée

Un message reçu : expéditeur, objet, corps, pièces jointes

→

Sortie

Une catégorie parmi une liste fermée, un niveau d'urgence, et la justification

Trois invariants s'appliquent à chaque appel au modèle :

• Les outils sont sur liste blanche par nœud. La liste effective est l'intersection de ce que l'agent peut faire et de ce que ce nœud-là autorise. Elle est calculée avant l'appel et écrite dans la trace.
• La sortie est forcée par schéma. Échec de validation, nouvelle tentative avec le message d'erreur, puis échec du nœud. Jamais de texte libre interprété.
• Aucune lecture implicite. Ce que le nœud n'a pas déclaré n'entre pas dans le contexte du modèle. Pas de mémoire qui s'invite, pas de document qui traîne.

Le journal fait autorité#

Dans la plupart des outils, l'exécution produit un résultat, et des logs sont écrits à côté pour qu'on puisse regarder après coup. Chez EchoBrain, c'est l'inverse : le journal est la vérité, l'état courant n'en est qu'une projection.

Chaque événement de nœud porte l'empreinte de son entrée, la sortie validée, la version exacte du package et du prompt utilisés, l'empreinte de la mémoire lue, et chaque appel au modèle avec sa requête et sa réponse intégrales. Dix-huit types d'événements couvrent le cycle de vie complet d'une exécution — du démarrage à l'expiration, en passant par l'ouverture d'un point de validation humaine et par l'enregistrement d'une décision en observation.

Cette inversion a une conséquence directe : il n'existe pas d'événement survenu mais non écrit. Un comportement qu'on ne retrouve pas dans le journal n'a pas eu lieu.

Deux façons de rejouer#

Le rejeu strict rejoue les réponses du modèle telles qu'elles ont été enregistrées. La reproduction est exacte. C'est ce qu'on montre à un auditeur, à un client mécontent, ou à un juge : voilà l'entrée, voilà la décision, voilà pourquoi.

Le rejeu vivant rejoue le même journal d'entrée en refaisant réellement les appels au modèle. C'est ce qu'on utilise pour tester une nouvelle version de prompt, un nouveau modèle ou un skill modifié avant de le déployer : on mesure l'écart sur des cas réels au lieu de le découvrir en production.

Le même mécanisme donne deux propriétés supplémentaires, gratuites : un worker qui meurt ne perd rien, puisque l'état est une projection reconstructible ; et un nœud déjà exécuté avec la même entrée n'est pas rejoué inutilement.

Le problème du mail parti deux fois#

C'est l'incident que tout le monde rencontre, et qu'aucune trace d'observation ne résout.

Un nœud envoie un mail, puis le processus meurt avant d'avoir écrit qu'il l'avait envoyé. Au redémarrage, le système croit l'étape inachevée. Le mail part une seconde fois.

EchoBrain enregistre l'intention avant l'acte. Avant l'appel, un événement dédié inscrit une clé d'idempotence dérivée de l'exécution, du nœud, de la tentative et de l'empreinte de l'entrée. Cette clé accompagne l'appel jusqu'au système distant. Au redémarrage, une intention sans confirmation correspondante est réconciliée avant tout rejeu : soit en interrogeant le système distant, soit en ouvrant une tâche pour un humain. Jamais de rejeu à l'aveugle.

Chaque connecteur déclare sa classe d'idempotence, et cette déclaration est vérifiée :

Un connecteur de classe aucune ne se rejoue jamais tout seul. C'est une contrainte assumée : il vaut mieux une tâche à traiter qu'un virement en double.

Le point de validation humaine#

Un nœud humain arrête le processus et attend une décision. Deux propriétés le rendent utilisable en production :

Il ne mobilise aucune ressource pendant l'attente. Une exécution peut rester bloquée trois semaines sur une validation sans qu'aucun worker ne soit immobilisé — la portée d'exécution est le nœud, pas le processus entier. C'est ce qui permet de mettre des validations partout au début, sans craindre d'engorger le système.

Tout ce qui se passe autour est enregistré : le contexte présenté à la personne, l'information qu'elle a demandée en plus, sa décision, son délai, son identité, la discussion associée. Ce n'est pas de la surveillance : c'est le matériau de l'étape suivante.

L'autonomie progressive {#autonomie-progressive}#

La question n'est pas « faut-il faire confiance à l'IA », c'est « comment décide-t-on de lui confier quelque chose ». EchoBrain répond en quatre étapes, et l'humain garde la barrière.

1. Observation. Le nœud reste humain. Le système accumule les décisions réelles.
2. Proposition. Au-delà d'un échantillon minimal — trente décisions par défaut — le système propose une règle déterministe et affiche son taux de reproduction sur l'historique passé, écarts compris. En dessous du seuil, il ne propose rien.
3. Ombre. Le nœud reste bloquant, mais l'interface affiche ce que la règle aurait décidé. L'humain valide comme avant ; le système mesure l'accord sur des décisions fraîches.
4. Promotion. Le franchissement obéit à une politique versionnée, réglable nœud par nœud. Par défaut : 95 % d'accord minimum, au moins vingt décisions fraîches, et l'approbation nominative d'un administrateur.

Ce qui est promu n'est pas un modèle : c'est une règle explicite, lisible, rejouable. Et elle s'arrête d'elle-même dès qu'elle sort du terrain connu.

L'escalade se fait sur la couverture, pas sur un score de confiance. Une règle déclare le domaine sur lequel elle a été apprise : pour chaque champ qu'elle lit, les valeurs observées ou l'intervalle observé. Une entrée située hors de ce domaine rouvre le point de validation humaine, et le journal en nomme le motif. Une règle apprise sur des mails étiquetés devis et facture escalade tout mail étiqueté support — sans qu'aucun seuil arbitraire n'ait été réglé à la main.

Un nœud promu conserve enfin un arrêt d'urgence qui le rend bloquant instantanément.

Les budgets sont des objets, pas des vœux#

Un plafond de dépense s'applique à trois niveaux — le client, le processus, l'invocation — et le plus restrictif tranche. Alerte à 80 %, refus ferme à 100 %. Au refus, l'étape échoue avec un code explicite et une tâche est ouverte.

Jamais de repli silencieux vers un modèle moins cher. Un système qui dégrade sa qualité sans le dire est un système dont on ne peut plus rien affirmer.

Ce que cela change concrètement#

• Un client conteste une décision : vous rejouez l'exécution devant lui, à l'identique.
• Un auditeur demande sur quelle base une étape a été franchie : le journal porte la version exacte du prompt, du package et du modèle utilisés ce jour-là.
• Vous voulez changer de modèle : vous rejouez cent exécutions réelles sur le nouveau et vous mesurez l'écart avant de basculer.
• Un comportement anormal apparaît : vous le reproduisez au lieu de le supposer.

Comment tout cela tourne chez vous · Voir les packs métier et leur processus complet