Une zone de chat vierge est un mauvais endroit pour mener un travail conséquent. Elle réduit cinq questions très différentes —que voulez-vous, que regardez-vous, sur quoi cela repose-t-il, qu’avez-vous le droit de faire et que s’est-il déjà passé— à un seul flux indifférencié. Pour des tâches anodines, cela convient. Pour des opérations gouvernées, où les actions touchent des systèmes d’enregistrement et où les décisions doivent être défendables, cet effondrement est précisément ce que vous ne pouvez pas vous permettre.
L’espace de travail de Threada est délibérément décomposé en cinq surfaces. Chacune répond à l’une de ces questions, et les garder distinctes est ce qui rend le travail vérifiable.
1. La barre d’intention : que voulez-vous ?
Le travail dans Threada démarre depuis une barre d’intention persistante plutôt que par une navigation profonde. Vous énoncez le résultat en langage naturel, éventuellement avec des commandes structurées, et le runtime le transforme en un artefact structuré et exécutable : un WorkItem avec des entités extraites, un score de confiance et des indicateurs de risque.
Il s’agit d’une interaction centrée sur l’intention. Au lieu de forcer l’opérateur à savoir quel formulaire, quelle file et quel flux de travail s’applique avant de pouvoir commencer, le système capture l’objectif et assemble le chemin. Lorsqu’il manque une information, il demande exactement ce dont il a besoin plutôt que de présenter un long assistant statique d’emblée.
2. Le canevas adaptatif : sur quoi travaillez-vous ?
Le canevas est l’endroit où le WorkItem vit et prend forme. Il est adaptatif : l’interface peut assembler des formulaires temporaires, des comparaisons et des panneaux de décision pour recueillir le contexte manquant et achever la tâche, plutôt que d’afficher une mise en page fixe pour chaque type de travail.
La sortie générée prend par défaut la forme d’un brouillon modifiable, et non d’un changement validé. L’opérateur examine, modifie et décide. Les affordances de contrôle sont explicites —zones de verrouillage et d’absence de changement, comparaison côte à côte, annulation rapide et retour à une version antérieure— de sorte que le canevas est un lieu de délibération, et non un lieu où la première supposition du modèle devient vérité.
3. Le tiroir de preuves : sur quoi cela repose-t-il ?
Toute sortie conséquente devrait pouvoir montrer son raisonnement. Le tiroir de preuves contient les citations, les traces de récupération et l’attribution des sources qui ancrent le WorkItem. Lorsque le système ne peut pas ancrer une réponse, il le dit explicitement avec une raison de repli plutôt que d’inventer une confiance.
C’est la surface qui transforme « faites confiance à l’IA » en une affirmation inspectable plutôt qu’en un acte de foi. Un opérateur n’a pas à croire un brouillon ; il peut ouvrir le tiroir et vérifier sur quoi il s’appuyait, à quel point les sources étaient récentes et d’où provenait chaque affirmation.
4. Les contrôles d’action : que pouvez-vous faire ?
Lire et rédiger est sans danger. Agir sur le monde ne l’est pas —c’est pourquoi la surface des contrôles est gouvernée. C’est là que les propositions deviennent des approbations et que les approbations deviennent des actions exécutées contre des systèmes externes : un remboursement, un ticket, une mise à jour d’enregistrement, un octroi d’accès.
La gouvernance s’exprime ici sous forme de politique —permissions, seuils, portes d’approbation et lignes rouges— et non sous forme de réglages dispersés. Les actions à haut risque progressent selon une progression explicite proposée, approuvée, en exécution, et ne s’auto-exécutent que là où une politique l’autorise. Un coupe-circuit au niveau du service peut arrêter l’exécution avant qu’un connecteur ne soit appelé tout en préservant l’état pour révision. La surface des contrôles est l’endroit où la prudence du système se concrétise.
5. Le journal d’exécution : que s’est-il passé ?
Le journal d’exécution est la chronologie du WorkItem : chaque transition, chaque approbation, chaque action, chaque événement de participant IA, dans l’ordre. C’est la surface où les reçus s’accumulent en historique.
De façon cruciale, les actions de l’IA apparaissent comme des événements d’acteur distincts, et non fondues dans l’activité humaine. Lorsque vous lisez le journal d’exécution, vous pouvez dire qui a proposé, qui a approuvé et ce qui a été exécuté —humain ou agent— sans deviner. Le journal d’exécution est ce qu’un auditeur lit à la fin du trimestre et ce qu’un opérateur lit pour comprendre le dossier qu’il a devant lui aujourd’hui.
Pourquoi la séparation est l’essentiel
Il serait plus simple de construire une seule surface et de laisser tout se confondre. La raison de ne pas le faire est que le travail conséquent exige que vous gardiez ces questions séparées.
Si l’intention, la preuve et l’action partagent une surface, il devient facile d’agir sur quelque chose que vous n’avez jamais ancré, ou d’approuver quelque chose dont vous n’avez jamais vu le fondement. En donnant à chacune sa propre surface, Threada fait du chemin prudent le chemin naturel : énoncez l’intention, façonnez le brouillon sur le canevas, vérifiez la preuve, puis agissez via des contrôles gouvernés —le journal d’exécution enregistrant tout cela.
Les cinq surfaces restent constantes à travers les packs et les rôles ; ce qui les remplit s’adapte. Cette stabilité est délibérée. Un opérateur qui apprend la forme d’un espace de travail a appris la forme de tous, qu’il mène un provisionnement d’accès informatique, une revue de sécurité d’un fournisseur ou une approbation d’achat. Le travail change. La manière dont vous raisonnez à son sujet, non.