Les agents sont toujours des recrues de premier jour. Il est temps de concevoir en conséquence.

D’ici 2027, 74% des entreprises devraient utiliser des agents sous une forme ou une autre, selon une étude récente de Deloitte. Depuis des années, nous concevons et développons des logiciels pour améliorer l’expérience humaine de navigation dans nos applications, sites web, systèmes d’exploitation et documents. Aujourd’hui, l’utilisateur n’est plus du tout humain. Cela a des implications plus larges que le simple passage des tableaux de bord aux flux de travail contrôlés que nous concevons pour les tâches humaines. Nous vivons un moment où nous devons concevoir les environnements d’exploitation des agents, tout en également concevant les flux de travail humains pour guider efficacement l’expérience de l’agent au sein de ces environnements.  

Nous en sommes encore aux débuts de notre apprentissage sur ce dont les agents ont réellement besoin de notre part pour être régulièrement et de façon fiable performants. L’instinct est de considérer l’intégration des agents uniquement comme un problème de sollicitation ou d’interface utilisateur. Concevoir un environnement d’exécution bien gouverné représente un nouveau terrain pour nous en tant que culture. Cependant, les principes sous-jacents d’une bonne conception et d’une bonne gestion n’ont pas changé: nous devons aux agents un contexte clair, une direction sans ambiguïté et une intention explicite.

Contexte: Pourquoi le codage est venu en premier

Le contexte est sans doute l’entrée la plus importante si nous voulons que les agents livrent de façon répétée au niveau que nous visons. Le développement logiciel en consigne plus que presque aucun autre domaine: dépôts, schémas d’API, relations entre systèmes, revues de code et discussions communautaires. Il est donc logique que les laboratoires de pointe en IA aient commencé par le codage. C’est l’un des rares domaines où une bonne partie du contexte est déjà consignée. 

Mais comme le dirait tout nouveau recruté d’une équipe de développement, même avec toutes ces données, les agents manqueront toujours la mémoire institutionnelle intégrée dans les règles tacites jamais documentées. Cette lacune est répandue: 43 % des développeurs sont inquiets que les outils d’IA manquent de contexte suffisant concernant leur projet ou leur base de code spécifique. Le savoir tacite couvre tout, des conventions quotidiennes, comme les bibliothèques préférées pour certaines tâches, aux fantômes opérationnels à enjeux élevés: une correction de dernière minute qui persiste indéfiniment, ou une colonne de base de données apparemment vide qui soutient secrètement un rapport de revenus personnalisé. Ce contexte vit dans la tête d’un ingénieur senior, dans un fil Slack récent, ou nulle part. Il se trouve rarement dans le code lui‑même.  

Si cela est vrai dans le logiciel, l’un des domaines les mieux documentés, il est facile de comprendre pourquoi les agents peinent à être efficaces dès le premier jour dans de nombreux autres secteurs. Dans la santé et le droit, une grande partie du savoir institutionnel qui façonne le travail quotidien est apprise et internalisée. Il vit dans l’expérience des personnes plutôt que dans la documentation officielle. Un agent juridique peut ne pas connaître la structure, le ton ou l’argumentation préférés d’un partenaire pour un mémoire, tandis qu’un agent de santé peut ne pas comprendre les flux de travail locaux et les pratiques d’escalade qu’une clinique occupée utilise pour soutenir le triage dirigé par les cliniciens. La documentation seule ne peut combler cet écart, car le défi n’est pas simplement l’accès à l’information ; c’est le transfert de contexte. Pour fournir aux agents ce dont ils ont besoin pour réussir, nous devons les intégrer de la même manière que nous le ferions pour un nouveau recruté.

Direction: Pourquoi l’osmose ne fonctionne pas

Intégrer un nouveau coéquipier nécessite plus que fournir les bons supports et l’accès. Lorsque nous nous investissons dans la réussite de ceux qui nous entourent, nous donnons des directives claires sur ce qu’il faut faire avec les nouveaux supports et l’accès: attentes, clarté sur nos objectifs, et retours en cours de route. J’applique la même mentalité à la conception pour les agents. Je donne des directives claires et précises (par rapport à la tâche à accomplir). Cela s’applique à tout coéquipier, quel que soit son ancienneté. Cependant, dans le cas d’un nouveau recruté, les directives doivent aller plus loin, car il ne possède pas encore de contexte institutionnel.

Considérez un agent comme un nouveau recruté qui ne cesse jamais d’être nouveau. Il est enthousiaste et capable (et, franchement, déborde d’énergie), mais il ne peut pas assimiler et retenir autant de règles tacites qu’une personne le fait avec le temps. Les humains apprennent par osmose et expérience, tandis que les agents apprennent à partir d’une architecture explicitement intégrée à leur environnement de travail.

Avec un nouveau recruté, vous pouvez combler cet écart au fil du temps grâce aux questions, aux retours et aux nouvelles connaissances qu’il acquiert sur les processus et les préférences de l’organisation. Des discussions littérales autour de la machine à café ou des déjeuners d’équipe. Avec un agent, vous devez construire cette réduction d’écart directement dans la conception. Cela peut inclure: 

• Fournir à l’agent une fenêtre de contexte structurée qui sépare les règles durables, les faits spécifiques à la tâche et l’historique pertinent, plutôt que de lui déverser un tas de documents.
• Définir à l’avance ses autorisations et ses limites de décision: ce qu’il peut faire de façon autonome, ce qui nécessite une approbation, et ce qu’il ne doit jamais accéder.
• Intégrer quelques exemples concrets de résultats de haute qualité directement dans l’expérience, afin que l’agent dispose d’un modèle clair sur la manière dont le travail doit être réalisé.
• Partager les impasses précédentes que vous avez rencontrées.

Concevoir un environnement d’agent bien gouverné ne consiste pas à faciliter le travail du modèle. Il s’agit de protéger l’équipe d’ingénierie humaine de la dette technique invisible. Mais même un agent bien dirigé peut suivre les instructions à la perfection et manquer le but. La direction lui indique quoi faire, mais ne lui montre pas à quoi ressemble le « bon ». C’est là que l’intention intervient.

Intention: Pourquoi les agents dérivent vers le milieu

Il est important de se rappeler que les agents sont des machines de correspondance de motifs, entraînées sur d’immenses quantités de connaissances et naturellement enclines à fournir la moyenne statistique. Sans une intention claire et explicite, cette sortie moyenne est exactement ce qu’un agent renverra. Demandez à un agent « d’ajouter un point de terminaison d’authentification utilisateur », et il générera une route Express textbook avec un hachage de mot de passe basique. Cela fonctionne, mais cela ignore complètement le service d’authentification personnalisé de votre équipe, omet la télémétrie requise et casse votre formatage d’erreurs standardisé. C’est une fonctionnalité adéquate sur le papier, mais selon le contexte, c’est un bug architectural en pratique. La facilité avec laquelle de tels « bugs » sont introduits ne saurait être surestimée.

Pour éviter cela, la direction doit être associée à une vérification active de l’intention et à une journalisation. Les garde-fous ne doivent pas seulement vérifier si le code compile, même si c’est important. Ils doivent explicitement appliquer les standards opinionnés, les règles de cas limites et le contexte métier qui élèvent la sortie générique à un travail prêt pour la production. La journalisation compte comme indicateur d’état du système pour nous, humains. Cette traçabilité est cruciale pour la confiance. 

Dans les interactions humaines, il y a beaucoup d’espace pour l’incertitude. Quelqu’un peut partager une première version avec vous, et ensemble vous pouvez discuter de ce qui est solide et de ce qui doit être amélioré. Cela fonctionne parce que nous n’attendons pas de nos collègues humains qu’ils soient des machines autonomes. Pour réellement exploiter la puissance et la promesse des collègues agents (que nous devons faire fonctionner de façon plus autonome…), nous pouvons concevoir de nombreuses vérifications directionnelles. les allers‑retours restent nécessaires, mais ils ne peuvent pas reposer entièrement sur un effort manuel. En intégrant dès le départ des critères d’acceptation clairs et des règles de vérification, vous permettez à l’agent d’exécuter ses propres boucles de rétroaction internes. Concevoir pour la prévention des erreurs est un autre principe UX solide que nous pouvons appliquer dans ce nouveau monde: donner aux agents la capacité de signaler une faible confiance avant de s’engager dans une action, plutôt que de se rabattre silencieusement sur une supposition.

Où la métaphore se rompt

Le cadre du nouveau recruté fonctionne, jusqu’à ce qu’il ne fonctionne plus. Avec un recrutement humain, l’expérience engendre la compétence qui engendre le jugement. Observer votre nouveau recruté internaliser le « pourquoi » du contexte et de la direction est ce qui construit la confiance au fil du temps, et de façon générale, cela s’accumule. Un agent n’a nulle part où accumuler et stocker cette expérience.

La première semaine d’un nouveau recruté et la centième semaine sont différentes. La première tâche d’un agent et la millième sont identiques, à moins que vous ne conceviez et construisiez quelque chose pour les différencier. C’est notre nouveau défi de conception.

La responsabilité de l’agent dépend de la conception

Si la responsabilité ne peut pas résider dans l’agent, elle doit résider dans l’ossature qui l’entoure. Cela revient aux trois mêmes questions que je poserais avant de confier une tâche à un nouveau recruté: quel contexte possède‑t‑il ? Quelle direction lui ai‑je donnée ? Quelle est mon intention réelle ?

La prochaine fois que vous confiez une tâche à un agent, ne vous contentez pas de vérifier la sortie. Vérifiez d’abord vos propres entrées. Lui avez‑vous donné le contexte qu’un nouveau recruté aurait besoin dès le premier jour ? Votre direction était‑elle suffisamment précise pour survivre à une interprétation littérale ? Votre intention était‑elle assez claire pour que la « réponse médiane » ne soit pas la meilleure qu’il pouvait fournir ?

Avec ces consignes claires en main (en octets ?), quelque chose d’intéressant se produit: un agent n’a pas besoin d’une longue période d’apprentissage pour devenir fiable. Le contexte, la direction et la vérification que vous intégrez dès le départ définissent son mode de fonctionnement pour chaque tâche. Un nouveau recruté gagne votre confiance au fil du temps ; un agent doit la gagner à chaque fois grâce au système que vous avez conçu. La responsabilité n’est pas quelque chose qui se développe, elle est intégrée dès le départ. La question n’est pas de savoir quand votre agent sera prêt à assumer davantage de responsabilités, mais si vous l’avez conçu pour gagner cette responsabilité à chaque tâche.