Étude de cas
Coordination Hub
Un espace pour coordonner le travail avec plusieurs IA et comprendre ce que chacune a proposé, ce qui a été revu et quelle décision m’appartient.
Je l’ai commencé pour résoudre un problème de mon propre travail : en passant d’une IA à l’autre, je perdais le contexte et devais reconstituer les décisions. Le Hub, dont l’interface expérimentale s’appelle Testigo, réunit projets, conversations et mémoire revue. Mon objectif est de suivre le travail sans confondre une proposition avec un résultat vérifié.
Expérimental
- Pilote
- produit personnel en développement
- L0–L3
- autonomie sous autorité humaine
- MCP
- coordination entre sessions séparées
Collaboration : J’ai travaillé avec Claude et Codex pour implémenter et revoir le système. Je conserve la direction du produit, les critères d’acceptation et les décisions qui nécessitent une autorisation.
Interface réelle avec des données de démonstration. Ces captures proviennent du développement de Testigo et ne contiennent ni conversations de travail ni informations de LALIGA. Les fournisseurs apparaissent déconnectés dans cette session isolée ; les écrans montrent le design de la supervision, pas une exécution autonome en cours.
Le projet, couche par couche
De petites décisions construisent le système.
J’organise le contexte par projet et conversation. Chaque intervention conserve son auteur et je peux vérifier la disponibilité des outils sans quitter l’espace de travail. Interface réelle avec des données de démonstration.
La mémoire distingue les contenus reçus des connaissances revues. Je souhaite que la personne puisse consulter et examiner les informations réutilisées, au lieu de supposer que tout ce qui est écrit est valide. Interface réelle avec des données de démonstration.
Créer un espace séparé rend explicite le point de départ de chaque projet. Je continue à tester cette partie de l’accueil pour réduire la configuration et éviter de mélanger les contextes. Interface réelle avec des données de démonstration.
Recherche
Le problème est apparu pendant mon travail. Je copiais les réponses entre assistants, répétais le contexte et perdais du temps à vérifier ce qui avait réellement été fait. J’ai voulu séparer trois choses souvent confondues : la demande, la proposition et la preuve du résultat.
J’ai défini des niveaux d’autonomie pour qu’une recommandation ne devienne pas, à elle seule, une autorisation. L0 permet d’observer ; L1 et L2 encadrent les actions selon leur portée ; L3 réserve les décisions à plus fort impact à la personne.
Méthodes :Diagnostic du coût réel de l’intermédiation humaine · Comparaison avec les cadres existants et décision de construire sur mesure · Modèle d’autonomie L0–L3, avec L3 réservé à la personne · Critères de réussite mesurables avant d’écrire le code.
Prototype
J’ai organisé l’interface autour d’une tâche précise : comprendre ce qui requiert mon attention. À gauche, je place le contexte ; au centre, la conversation ; à droite, l’état des outils. La mémoire se consulte au besoin, sans occuper en permanence l’espace de lecture.
Le journal d’événements conserve la trace des opérations. Les vues construites sur cette base permettent de lire une conversation et d’en examiner les décisions sans parcourir l’intégralité du journal technique.
L’IA dans le processus
Dans ce projet, j’utilise l’IA pour construire un outil qui doit aussi m’aider à la superviser. J’alterne implémentation et revue avec Claude et Codex et confronte leurs conclusions au code et aux tests. Deux réponses concordantes ne me suffisent pas pour considérer un résultat comme validé.
- Outil
- Claude · Codex, coordonnés entre eux par le Hub lui-même
- Phase
- Cycle complet : spécification, implémentation, revue croisée et vérification
- Contribution humaine
- Problème, critères d’acceptation, architecture de décision, priorités et toute approbation irréversible
- Résultat de l’IA
- Implémentation, tests, revues indépendantes avec constats hiérarchisés et éléments probants
- Critères de sélection
- Preuves vérifiables, réversibilité, isolation des projets, absence de secrets et tests réussis
- Limites identifiées
- Aucune IA n’étend ses propres permissions, ne clôt une décision irréversible ni ne déclare un consensus sans revue indépendante
- Décision finale
- Autorité humaine sur tout ce qui est irréversible. Les IA décident des actions réversibles et en laissent la trace
Développement
Le Hub propose, via MCP, des opérations pour consulter les messages, enregistrer les réponses et apporter des preuves depuis des outils compatibles. Le contrat distingue envoyer, recevoir, traiter et vérifier : ce sont des états différents et je veux que l’interface les traite comme tels.
J’ai mis l’accent sur la récupération, les renvois et la séparation entre projets. Ces situations sont peu spectaculaires, mais décisives pour qu’un outil de coordination n’ajoute pas davantage d’incertitude qu’il n’en résout.
Validation
Une revue a détecté un problème révélateur : un sujet pouvait être clos par consensus sans vérifier l’existence d’une revue indépendante. Nous avons corrigé le contrat pour exiger cette revue et conserver la preuve. Cette découverte a changé mon jugement de design : un état positif doit expliquer ce qui le justifie.
La version initiale documentait 95 tests automatisés. C’est un élément historique du développement, pas une garantie que le produit actuel soit terminé. Le Hub reste en phase pilote et sa facilité d’utilisation doit encore être évaluée avec des personnes ; ni une capture ni un test de code ne remplacent cette validation.
Du prototype au composant
Organisation du système
- foundations / niveaux d’autonomie · états de disponibilité · classes de visibilité
- organisms / file d’attention · chronologie de conversation · panneau de consensus
- organisms / registre des décisions · inventaire des agents · chaîne de preuves
Code · preuve d’implémentation
const requiredReviewers = [
...new Set(target.to.filter((agent) => agent !== parsed.from)),
]
if (requiredReviewers.length === 0) {
throw new Error('Consensus requires an independent review')
}
const reviewedBy = requiredReviewers.filter((reviewer) =>
events.some(
(event) =>
event.correlationId === target.id &&
event.from === reviewer &&
['review', 'objection', 'result'].includes(event.messageKind),
),
)
if (reviewedBy.length !== requiredReviewers.length) {
throw new Error('Consensus requires an independent review from: ...')
}
const level =
parsed.reversibility === 'irreversible' ? 'L3' : topicLevel
if (level === 'L3' && parsed.from !== 'manuel') {
throw new Error('L3 consensus may only be resolved by Manuel')
}src/store.mjs · resolveTopic()
Le cœur du système : la porte de consensus. Auparavant, la déclaration d’un agent suffisait ; désormais, une revue indépendante de tous les réviseurs requis est exigée et le niveau est déduit plutôt que fixé.
consensusState = 'reviewed' | 'provisional' | 'lapsed' ← déduit des revues enregistrées, et non déclaré par l’agent qui tranche
Enseignements
Séparer l’intelligence de l’autorité : qu’une partie propose et qu’une autre, déterministe, autorise empêche de confondre une recommandation avec une décision.
Un accord sans revue indépendante n’est pas un consensus, mais une opinion estampillée. Si le système ne le vérifie pas, cela finira par se produire.
L’indisponibilité due aux quotas n’est pas exceptionnelle, mais habituelle : le design doit se dégrader explicitement plutôt que se bloquer.
J’ai appris à consigner les décisions pendant le travail : reconstituer leur contexte après coup coûte davantage et peut laisser des lacunes.
Question ouverte :Que doit voir une personne pour superviser avec confiance le travail de plusieurs agents autonomes sans lire tout ce qu’ils produisent ?
Contact
Parlons-en.
Si ma façon de travailler vous semble adaptée à votre équipe, ou si vous souhaitez développer un produit ou un projet de recherche, je serais heureux d’en savoir plus. Dites-moi ce dont vous avez besoin et où vous en êtes. Je lirai votre message personnellement.
Vous pouvez aussi me retrouver sur LinkedIn