Des agents réactifs aux agents plus autonomes : le chaînon manquant est l’état du travail
Résumé Un agent réactif attend une instruction et un contexte fournis à la main. Un agent plus autonome doit savoir ce qui a déjà été fait, ce qui reste attendu et jusqu’où il peut agir. Cet écart n’est pas un problème de modèle : c’est un problème d’état.
Deux mots qu’il faut séparer avant tout le reste
On parle d’« agents » pour désigner deux choses très différentes. Avant d’aller plus loin, posons ce que chacune veut dire.
Un agent réactif attend une demande. On lui donne l’instruction, on lui donne le contexte, par exemple un fichier, un extrait de conversation ou un lien, et il produit un résultat. Entre deux sollicitations, il ne sait rien. Ce n’est pas un défaut : c’est son mode de fonctionnement.
Un agent plus autonome enchaîne plusieurs étapes sans qu’on lui redonne le contexte à chaque fois. Il peut décider d’attendre, de reprendre, de relancer, de s’arrêter. Pour cela, il lui faut une représentation de la situation qui survive entre deux exécutions.
La différence n’est donc pas d’abord une différence de puissance du modèle. C’est une différence de mémoire de la situation.
Le contexte fourni à la main a une limite naturelle
Tant qu’un humain assemble le contexte à chaque demande, l’agent hérite de la qualité de cet assemblage. Cela fonctionne bien pour une tâche isolée : rédiger, résumer, comparer, reformuler.
Cela tient beaucoup moins bien dès que la tâche s’étale dans le temps et traverse plusieurs personnes. La raison est simple : entre deux sollicitations, le travail a continué ailleurs. Une décision a été prise en réunion, une échéance a bougé dans un outil, un arbitrage est arrivé par e-mail. L’agent, lui, reprend à partir de ce qu’on lui a redonné, c’est-à-dire à partir d’une photographie déjà périmée.
Le coût n’est pas seulement une réponse imprécise. C’est le retour du travail de reconstruction chez l’humain : rouvrir les fils, retrouver ce qui a changé, réassembler le contexte avant de pouvoir déléguer à nouveau.
Trois niveaux qu’un système confond souvent
La plupart des outils connaissent bien un seul de ces trois niveaux, rarement les trois.
| Niveau | Ce que c’est | Ce qui le porte aujourd’hui |
|---|---|---|
| Travail attendu | Ce qui devait être fait : tâches, engagements, échéances, livrables | To-do, outil de gestion de projet, planning |
| Travail observé | Ce qui s’est réellement passé : réunions, messages, fichiers, actions dans les outils | Les traces dispersées dans chaque outil |
| État courant | Ce qui a avancé, ce qui a changé, ce qui reste ouvert, et sur quelles preuves | Le plus souvent : la tête de quelqu’un |
Un outil de gestion de projet décrit surtout le premier niveau. Un système de traces décrit surtout le deuxième. Le troisième, celui dont un agent a réellement besoin pour agir sans tout redemander, n’est presque jamais maintenu quelque part.
Ce que « pouvoir agir » exige en plus de savoir
Donner à un agent la capacité d’agir dans les outils déplace la question. Il ne s’agit plus seulement de savoir ce qui est vrai, mais de savoir jusqu’où il peut engager quelque chose.
Quatre éléments deviennent alors nécessaires :
- Un état sourcé : chaque affirmation renvoie à ce qui l’a produite, et reste contestable.
- Un mandat explicite : ce que l’agent peut faire seul, ce qui demande une validation, ce qui lui est interdit.
- Un point de reprise humain : pouvoir comprendre ce qui a été fait et reprendre la main sans reconstruire l’histoire.
- Une trace exploitable : non pas pour surveiller les personnes, mais pour expliquer une décision après coup.
Aucun de ces quatre points ne se résout en changeant de modèle.
L’hypothèse que je teste
Je construis Private Twin pour confronter une hypothèse précise : si l’on rapproche le travail attendu et les signaux du travail observé, on peut maintenir automatiquement un état courant suffisamment fiable pour qu’un humain ou un agent reprenne le travail sans en reconstruire l’histoire.
C’est bien une hypothèse, pas un résultat démontré. Ce qui est construit aujourd’hui : un prototype complet et un banc d’évaluation qui rejoue des journées figées pour détecter les régressions. Ce qui reste ouvert : l’évaluation sur davantage de situations réelles, et la validation de la valeur perçue par les utilisateurs.
Ce que cela change concrètement
Pour une organisation qui déploie des agents aujourd’hui, la conséquence pratique est simple à formuler : la question n’est pas seulement « quel agent construire », mais « quel état ce travail doit-il conserver pour qu’une personne ou un système puisse le reprendre ».
Un agent qui fonctionne en démonstration sur un cas isolé prouve une capacité. Un agent qui reprend un dossier trois jours plus tard, sans qu’on lui réexplique où on en est, prouve une infrastructure.