Revue immuable
Chaque proposition reçoit un identifiant unique et une empreinte de son instantané action-paramètres. Toute divergence ou altération est refusée.
AGENT DE WORKFLOW IA SOUMIS À VALIDATION HUMAINE / MVP LOCAL
RELAINEWORKFLOWS AGENTIQUES. DÉCISIONS HUMAINES. EXÉCUTION VÉRIFIABLE.
Laisser l’IA proposer. Garder la décision et l’action sous contrôle humain.
RELAINE transforme une demande métier formulée en langage naturel en proposition de tâche validée, suspend le workflow jusqu’à une décision explicite, puis exécute exactement l’action examinée via des outils SQLite persistants.
01 / PROBLÈME ET SOLUTION
L’autonomie n’a de valeur que si l’exécution reste maîtrisée.
LE PROBLÈME MÉTIER
Un modèle de langage peut interpréter une demande. Le laisser écrire directement dans les systèmes métier rend toutefois la validation, la traçabilité et la gestion des échecs dangereusement floues.
LA SOLUTION PROPOSÉE
Dissocier proposition et exécution. RELAINE valide la demande, sollicite un modèle local pour une action strictement structurée, persiste un instantané immuable, puis attend une validation humaine.
LE PÉRIMÈTRE DU MVP
Deux actions réelles—create_task et update_task—démontrent toute la boucle de contrôle, sans faire passer le projet pour un agent généraliste ou une plateforme de production.
02 / PARCOURS RÉEL
Une demande. Cinq états explicites. Aucune exécution silencieuse.
Le navigateur ne fournit jamais de nouveaux arguments à l’outil. La validation désigne l’identifiant et l’empreinte de la proposition persistée ; le backend exécute l’instantané de référence conservé côté serveur.
- 01→
DEMANDE
Une personne décrit le résultat attendu en langage courant.
- 02→
PROPOSITION IA
LangGraph valide la demande et Ollama retourne une proposition create_task ou update_task contrainte par Pydantic.
- 03→
REVUE HUMAINE
Action, paramètres, justification, identifiant et empreinte sont visibles avant toute écriture métier.
- 04→
EXÉCUTION
Seule une validation exacte peut réclamer la proposition et appeler l’outil SQLite correspondant.
- 05✓
AUDIT
Soumission, décision, exécution et récupération restent consultables dans un historique en ajout seul.
03 / ARCHITECTURE
Des composants locaux aux responsabilités volontairement limitées.
LangGraph orchestre les états ; Pydantic porte les contrats ; le service d’approbation applique les contrôles de confiance ; SQLite conserve propositions, tâches, reçus, checkpoints et audit. Le modèle propose, mais ne dispose d’aucun chemin d’exécution directe.
REQUEST→LANGGRAPH + OLLAMA→HUMAN GATE→SQLITE TOOL→AUDIT
- Workflow
- LangGraph enchaîne validation, génération structurée, contrôle de la proposition, interruption pour approbation et reprise maîtrisée.
- Inférence locale
- Ollama avec le modèle gpt-oss:20b déjà installé, via la sortie structurée ChatOllama en mode JSON Schema.
- Contrats
- Des modèles Pydantic stricts valident actions, paramètres, justification, états du workflow et réponses de l’API.
- Application
- FastAPI expose soumission, inspection, validation, rejet, liste des tâches et historique d’audit en lecture seule sur loopback.
- Persistance
- Le module sqlite3 de Python stocke tâches, propositions, checkpoints, reçus d’exécution et événements d’audit dans une base locale.
- Interface
- HTML, CSS et JavaScript natifs présentent la proposition, la décision explicite, le résultat d’exécution, les tâches et l’historique.
04 / SÉCURITÉ, IDEMPOTENCE ET RÉCUPÉRATION
L’effet métier est protégé avant, pendant et après l’exécution.
RELAINE rend les échecs visibles. Demandes non prises en charge, paramètres manquants, réponse malformée du modèle, indisponibilité d’Ollama et erreurs de base ne sont jamais transformés en faux succès.
Réclamation atomique
La transition pending-to-executing est protégée dans SQLite pour empêcher deux validations simultanées de réclamer la même proposition.
Écriture idempotente
La mutation métier et un reçu d’exécution unique, indexé par l’identifiant de proposition, sont validés dans la même transaction SQLite.
Récupération après crash
La récupération finalise un reçu déjà validé sans rejouer l’écriture et ne retente que lorsque l’absence d’effet persistant peut être prouvée.
Ambiguïté bloquée
Une proposition rejetée, non approuvée, terminée, altérée ou issue d’un ancien état ambigu n’est jamais réexécutée automatiquement.
Preuves en ajout seul
Les événements d’audit accompagnent les changements d’état dès que possible, tandis que des triggers SQLite interdisent leur modification ou suppression.
05 / RÉSULTATS VÉRIFIÉS
Un MVP réellement vérifié, sans le présenter comme un service de production.
La release a validé 103 tests de régression hors Ollama, puis une véritable inférence locale avec le modèle gpt-oss:20b configuré. Les deux tests Ollama réels couvrent un smoke test et un workflow HTTP de bout en bout sur serveur actif.
- Tests de régression hors Ollama
- 103 réussis
- Tests Ollama réels
- 2 réussis
- Actions métier
- 2 contrôlées
- Démo hébergée
- Aucune
Ces résultats vérifient les parcours implémentés et le packaging de la release. Ils ne démontrent ni une sécurité de production, ni un comportement multi-utilisateur, ni la qualité du modèle sur toute demande, ni une fiabilité opérationnelle à grande échelle.
06 / CAPTURES RÉELLES
La vraie interface, avant et après la décision.
Les deux captures proviennent de l’application locale en fonctionnement avec des données de démonstration synthétiques. La première s’arrête à l’attente de validation ; la seconde montre le résultat persisté et la piste d’audit après approbation.
07 / LIMITES