Conception d’agents d’IA ambiantes : canaux de réveil, sommeil peu coûteux et réveils sécurisés.

La plupart des écrits sur les agents d’IA partent du moment où une demande arrive et où le cycle commence à fonctionner. Un agent environnemental, celui qui surveille automatiquement les boîtes de réception, les files d’attente et les tableaux de bord, passe presque tout son temps dans un état opposé : rien ne se produit, et le système doit décider, encore et encore, si quelque chose vient de commencer. Ce guide porte sur ce temps d’inactivité. À la fin, vous serez en mesure de concevoir le mécanisme qui détermine quand un agent se réveille, de maintenir le coût du sommeil proche de zéro, d’assurer que chaque réveil soit sécurisé contre les doublons, la désuétude et les injections, ainsi que de mesurer si l’ensemble de cette organisation aide réellement les personnes qu’elle interrompt.

Un scénario d’avertissement : payer pour chaque « non »

Imaginez une équipe qui crée un agent pour surveiller sa boîte de réception d’assistance et son canal de disponibilité. L’objectif est simple : signaler tout ce qui nécessite une intervention humaine avant que quiconque ne s’en aperçoive. Le prototype est impressionnant lors des démonstrations. Puis arrive la première facture mensuelle, dont le montant dépasse celui des licences d’IDE, du temps consacré aux tests continus et des outils d’observabilité de l’équipe réunis, pour un agent qui n’a effectué qu’environ onze actions utiles en trente jours.

La raison en est une architecture que personne n’a écrite. Pour « surveiller » la boîte de réception, une tâche planifiée s’exécutait toutes les deux minutes, collectait les messages récents et demandait à un modèle spécialisé s’il y avait quelque chose nécessitant une attention particulière. Au cours du mois, cela s’est produit environ vingt-deux mille fois. Presque toutes les réponses étaient un « non » soigneusement argumenté. Les onze réponses « oui » étaient excellentes, mais la facture était dominée par les réponses négatives. La chose la plus coûteuse que le système ait faite, de l’ordre de trois ordres de grandeur, était de confirmer que rien n’avait changé.

Ailleurs dans cette même infrastructure se trouvait une ancienne tâche cron qui vérifiait un seuil de disque toutes les minutes. Au cours de son existence, elle n’a pratiquement coûté rien. La différence constitue la leçon de tout ce sujet : l’attente est quelque chose que l’on conçoit, et non quelque chose qui se produit par défaut.

L’idée à retenir est la suivante : un agent environnemental est défini bien plus par ce qui le met en activité que par ce qu’il fait une fois actif. La véritable étape technique consiste en un mécanisme qui détermine, au moindre coût possible, lequel des milliers d’événements entrants mérite l’attention d’un modèle, associé à un état dormant qui ne coûte rien tant qu’aucun événement n’est traité. Les agents de chat ne font jamais face à ce problème, car une personne a déjà jugé que le message valait la peine d’être envoyé avant même de le taper. En supprimant cette personne du processus déclencheur, c’est à vous de faire le tri. Si vous résolvez ce problème avec le grand modèle lui-même, c’est en fait comme si vous engageiez votre spécialiste le plus coûteux pour trier les messages.

Cela s’appuie sur quelques idées qui méritent un traitement distinct : une exécution durable (un processus capable de rester actif pendant des jours sans consommer de ressources de calcul), un ancrage temporel (ce qu’un agent doit réapprendre au sujet du « maintenant » lorsqu’il se réveille), ainsi que le décalage des objectifs chez les agents à longue durée de vie. Ces éléments sont abordés plus loin, là où ils revêtent de l’importance.

Chaque demande était déjà un événement

Une requête de chat semble être le point de départ naturel pour un agent, mais elle cache en réalité beaucoup de travail préalable. La personne qui l’a envoyée a effectué trois actions avant même que le moindre token ne soit traité : elle a décidé que la situation justifiait une action, ce qui constitue un tri ; elle l’a résumée en quelques phrases, ce qui correspond à la constitution du contexte ; et elle l’a envoyée à un moment précis, ce qui relève de la gestion du timing. Un agent de chat n’est en fait qu’un agent fonctionnant au-dessus d’une couche d’événements générée par un humain.

Les agents environnementaux, terme popularisé par LangChain pour désigner des agents qui consomment un flux d’événements et y répondent, pouvant gérer plusieurs événements en même temps, éliminent l’intervention humaine. Les trois services gratuits disparaissent. Ce qui reste est un problème d’ingénierie avec cinq types d’entrées distincts, chacun se comportant différemment :

• Messages. Une personne écrit à l’agent. Ceux-ci sont rares, déjà filtrés par le jugement humain, et pleins d’intention. C’est le cas le plus simple.
• Calendriers. Cron et tous les systèmes qui en dérivent. Un calendrier déclenche une action que ce soit en cas d’événement ou non. Cela est utile, car il capture ce que les flux d’événements manquent, mais c’est gaspilleur, car la plupart des déclenchements ne produisent aucun résultat.

Événements. Webhooks, messages en file d’attente, nouvelles lignes dans une table. Le monde extérieur vous les envoie. Ils arrivent en grand nombre, par vagues, sans aucune sélection préalable, et sont générés par d’autres systèmes ou des tiers plutôt que par votre utilisateur.

Surveillances. Conditions relatives à l’état : une demande de fusion est devenue applicable, un document a été modifié, un client a cessé de répondre. Rien ne vous les transmet automatiquement. Quelqu’un doit s’en apercevoir, et cette surveillance a un coût.

Seuils. Une métrique a dépassé une limite. C’est le déclencheur le plus ancien en matière d’opérations, et il s’accompagne de décennies de connaissances acquises sur les alertes, concernant la fatigue, les fluctuations et les marges d’erreur, que les concepteurs d’agents redécouvrent aujourd’hui.

Concevoir un agent inactif signifie décider de la manière dont ces éléments s’assemblent. Lequel d’entre eux peut réveiller l’agent ? Qu’y a-t-il entre le signal brut et le modèle ? Que reconstruit l’agent au sujet du monde lorsqu’il se réveille ? Une erreur dans une direction conduit au scénario décrit ci-dessus, où le modèle interprète le silence toutes les deux minutes. Une erreur dans l’autre direction fait en sorte que l’agent reste endormi pendant toute la durée de l’événement qu’il est censé détecter.

Le funil de réveil : le triage en tant qu’escalier

Le fait économique essentiel est qu’une requête vers un modèle représente la conditionnelle la plus coûteuse que l’on puisse écrire. Demander à un modèle de frontière « Est-ce important ? » coûte environ cinq à sept ordres de grandeur plus cher qu’un filtre de base de données qui répond à la même question pour des données structurées. Par conséquent, l’architecture de fonctionnement n’est jamais une ligne directe allant d’un événement à un modèle. Il s’agit plutôt d’un entonnoir : une série d’étapes, chacune étant moins coûteuse que la suivante et éliminant la majeure partie de ce qui lui parvient.

Étape un : règles structurelles

La première étape ne coûte pratiquement rien. Il s’agit de code simple qui examine la nature d’un événement : son type, son expéditeur, ses étiquettes, ainsi que le répertoire ou la file d’attente d’où il provient. Les newsletters, les notifications automatisées, les commentaires de bots et les événements relatifs à des projets que l’agent ne possède pas peuvent tous être traités ici sans aucune critique. Dans une boîte de réception typique, une grande partie du trafic brut n’a jamais besoin d’aller plus loin. Si moins de la moitié de vos événements bruts est éliminée à ce stade, vos règles sont probablement trop strictes.

Deuxième étape : atténuation des réponses et fusionnement

Les événements arrivent par vagues ayant une cause commune : des dizaines d’e-mails dans un même fil de discussion, une requête contenant trente modifications, des centaines d’alertes provenant d’un commutateur défaillant. L’unité appropriée pour attirer l’attention de l’agent n’est pas l’événement individuel mais la situation qui le sous-tend. C’est pourquoi cette étape définit une courte fenêtre de temps, regroupe les événements entrants selon une clé de corrélation telle que le fil de discussion, la demande de fusion ou l’incident, et transmet un seul signal combiné pour chaque situation.

La patience est également nécessaire à ce stade. Un document qui a été modifié une fois risque de l’être plusieurs fois encore dans les minutes qui suivent. Si vous effectuez des vérifications à intervalles réguliers après la dernière modification plutôt qu’immédiatement, vous réduisez considérablement le nombre de vérifications et chaque une d’elles permet d’avoir une vision plus complète. Le même principe s’applique chaque fois que plusieurs utilisateurs modifient un état partagé : une série de quarante événements décrit généralement un seul fait.

Une remarque sur les mécanismes de surveillance : polling et diff, jamais polling et jugement

Les mécanismes de surveillance impliquent une décision liée aux coûts que les autres déclencheurs ne comportent pas. Il faut bien que quelque chose détecte les changements, et il existe exactement trois façons de le faire :

• La source envoie une notification. Un webhook ou une abonnement vous informe lorsque l’état change. Lorsque c’est possible, utilisez-le.

Vous effectuez des sondages et des comparaisons. Selon un calendrier prédéfini, vous récupérez l’état actuel, le comparez à la capture d’écran précédente, et émettez un événement uniquement lorsque des différences sont détectées.

Vous effectuez des sondages et prenez une décision. Selon un calendrier prédéfini, vous récupérez l’état et interrogez un modèle à son sujet. C’est exactement ce qui a mal tourné dans le scénario initial.

Le sondage mérite en réalité une meilleure réputation que ne le suggère ce scénario. Le sondage est peu coûteux ; c’est le jugement qui est onéreux. Une tâche planifiée qui récupère une page, la hache et la compare à la hachure précédente ne coûte qu’une somme négligeable par an. De nombreux systèmes ne proposent pas de webhooks, donc la règle « jamais effectuer de sondage » n’est pas réaliste. La vraie règle est qu’un sondage doit se terminer par une comparaison des différences, et non par une appel au modèle. Il suffit de prendre un instantané, de le comparer, et de ne laisser entrer dans le processus que les changements détectés en tant qu’événements, qui seront soumis aux mêmes règles et au même classificateur que tout le reste. Le fait qu’un changement ait eu lieu relève d’une fonction de hachage ; le fait que ce changement soit important est la question pour laquelle vous utilisez le modèle.

Étape trois : classification à bas coût

Tout ce qui survit aux règles et à la consolidation est acheminé vers un modèle petit, rapide et peu coûteux, doté d’une instruction délibérément restreinte, du type « répondez par un mot : urgent, pertinent ou ignorer ». Il s’agit de la cascade de routage des modèles bien connue, appliquée aux alertes : le niveau bon marché absorbe l’ambiguïté que des règles fixes ne pouvaient pas exprimer, et seuls les résultats « pertinents » et « incertains » sont transmis en haut de la chaîne. Un modèle petit qui a raison dans 92 % des cas, placé devant un modèle plus grand coûtant trente fois plus cher, constitue l’ensemble du raisonnement économique derrière ce niveau de service. Pour une vue d’ensemble plus large sur l’origine des dépenses liées aux agents, consultez un modèle de coûts basé sur l’architecture pour l’IA agente.

Étape quatre : l’agent

C’est seulement à ce stade que commence véritablement l’ensemble du processus, avec l’assemblage dans un contexte réel, les outils nécessaires et un budget défini. Dans un funnel sain, seule une infime partie du trafic brut parvient jusqu’ici, et chaque événement qui arrive est déjà présenté sous forme de situation concrète plutôt que simplement en tant qu’événement isolé.

Étape cinq : l’être humain

Le funnel continue au-delà de l’agent, car celui-ci agit également comme un filtre : il choisit quels résultats méritent que quelqu’un y consacre du temps. C’est à cette dernière étape que les systèmes environnementaux réussissent ou échouent, et elle fait l’objet d’une section distincte ci-dessous.

L’arithmétique d’une refonte

Appliquez cela à l’équipe dès le début. Supposons qu’ils passent du mode de consultation par courrier électronique au mode webhooks et qu’ils ajoutent des règles structurelles, ce qui élimine environ 70 % des événements bruts, car il s’agit de newsletters et d’e-mails automatisés. Le regroupement par fil de discussion élimine à son tour environ 60 % de ce qui reste. Un petit classificateur marque ensuite environ 85 % du reste comme « ignorer ». Le modèle de frontière s’exécute désormais environ trente fois par mois, contre vingt-deux mille auparavant, tout en maintenant les mêmes onze actions utiles. Le coût par réveil utile diminue de plus d’un ordre de grandeur.

La partie surprenante, c’est que la précision s’améliore également. Chaque réveil examine désormais une situation cohérente plutôt que n’importe quel fragment arbitraire tombant par hasard dans une fenêtre de deux minutes, ce qui donne au modèle des éléments plus pertinents sur lesquels raisonner.

Dormir paisiblement : comment un agent inactif ne coûte rien

Au milieu des périodes d’inactivité, l’agent environnemental idéal n’existe tout simplement pas. Il ne fonctionne pas en arrière-plan de manière silencieuse ; il n’y a ni processus, ni conteneur, ni contexte actif. Toute son existence se résume à une entrée dans un stockage : une identité, une configuration, un pointeur vers sa mémoire et une liste de abonnements. C’est l’idée d’une exécution durable selon laquelle « attendre, c’est simplement être dans un état donné », poussée à son extrême logique. Une exécution en pause représente des données au repos, et le stockage de données au repos fait partie des services les moins chers proposés par un fournisseur cloud.

Cela signifie que le réveil de l’agent constitue un acte de reconstruction. Tout ce qui s’applique à la reprise d’un flux de travail interrompu s’applique ici avec encore plus de force, car personne ne surveille ce qui se passe.

Rétablir l’horloge

Lorsqu’un agent se réveille après six jours, il doit être informé de l’heure actuelle et doit recalculer toutes les références relatives qu’il possède. Une note indiquant « la date limite est vendredi », écrite un mardi, est simplement fausse dès le lundi suivant. Donnez à l’agent l’heure actuelle dans la zone horaire de son responsable, ainsi que l’heure de son dernier réveil, afin qu’il sache depuis combien de temps il était en sommeil.

Considérer la mémoire comme potentiellement obsolète

Le monde a continué de bouger pendant l’absence de l’agent. Les informations stockées en mémoire doivent être accompagnées d’une date et d’une heure de mise à jour, et être révalidées avant utilisation ; en outre, le contexte de réveil doit privilégier les données fraîchement lues par rapport aux valeurs mémorisées. C’est la même discipline que celle appliquée lorsque l’approbation d’un humain suspend un flux de travail : lier les décisions à un instantané, puis les révalider lorsque l’exécution reprend.

Se réorienter vers l’objectif

Dans les agents qui fonctionnent sur le long terme, l’objectif est reconstruit en fonction du contexte à chaque tour, c’est pourquoi il évolue au fil des semaines. Un « wake » assemble son contexte à partir de zéro, ce qui en fait soit le moment le plus risqué pour des déviations, soit la meilleure opportunité de les corriger. Fait correctement, chaque « wake » relit la définition de l’objectif. Si un agent est reconstruit deux cents fois par an, cela représente deux cents occasions de le ramener à sa finalité sans aucun coût supplémentaire.

C’est pourquoi les conceptions qui lancent une nouvelle session à chaque réveil, en conservant la continuité dans la mémoire externe et les fichiers plutôt qu’en accumulant un transcript toujours plus volumineux, durent bien mieux qu’une seule session éternelle qui accumule des mois de données résiduelles. Les fonctionnalités d’agent planifié dans les outils de codage actuels, dont les routines de Claude Code constituent un exemple bien connu au moment où cet article est écrit, suivent pour l’essentiel ce modèle de nouvelle session à chaque exécution. C’est un choix judicieux pour quiconque a vu l’effet que peut avoir un contexte ancien de plusieurs semaines sur le comportement d’un agent.

Ce qu’un bon contexte de réveil doit contenir

« Reconstruction » semble abstrait tant que l’on n’en a pas écrit un. Un prompt de réveil bien conçu ressemble à une note d’information que l’outil assemble section par section :

• Le fichier d’objectifs, non modifié. La raison d’existence de cet agent ainsi que les limites de ses actions.

L’horloge. L’heure actuelle dans le fuseau horaire du responsable, ainsi que la date et l’heure de la dernière activation.

La situation. Le résumé synthétisé qui a déclenché cette activation. Il ne s’agit pas de quarante événements bruts, mais d’une description de leur structure.

État actuel. Les valeurs actuelles de tout ce que la situation concerne, récupérées au moment de l’activation et marquées d’une date de référence.

Mémoire pertinente. Un petit ensemble de notes durables laissées par des activations antérieures, telles que « ce client préfère les appels en soirée » ou « la dernière fois que cet alerte s’est déclenchée, la cause était le cache ». Elles sont consultées selon les besoins, sans être accumulées.

Le budget. Les limites de tokens, les outils disponibles et le plafond d’autonomie pour cette activation en particulier.

Remarquez ce qui manque : les transcriptions des phases de réveil précédentes. Leurs conclusions survivent, car chaque phase de réveil synthétise ce qu’elle a appris en mémoire avant de se terminer, mais les données résiduelles de chaque session sont éliminées. Ce compromis permet à la deux-centième phase de réveil d’être aussi précise que la deuxième. Cela permet également d’économiser des ressources, puisque un résumé de quelques milliers de tokens remplace une transcription qui pourrait atteindre des centaines de milliers.

Garanties de livraison, avec une touche d’LLM

Le processus de réveil implique également l’héritage des problèmes classiques des systèmes distribués.

La livraison a lieu au moins une fois, donc chaque appel de réveil doit être idempotent. Les files d’attente et les services webhook se réservent tous le droit de vous envoyer le même message deux fois. Pour un notificateur sans état, une duplication n’est qu’un bruit de fond. Pour un agent disposant d’outils, une duplication peut signifier l’exécution deux fois de la même action irréversible. La solution est standard : dériver une clé d’idempotence à partir de l’événement et la vérifier avant que l’appel de réveil ne réalise quoi que ce soit qui ne puisse être annulé. Si vous avez besoin de vous rafraîchir les idées sur ce mécanisme, consultez comment fonctionnent les clés d’idempotence dans les endpoints POST de Node.js.

Les agents environnementaux ont également besoin d’une deuxième vérification au niveau de la situation. Un agent qui se réveille parce que « PR #482 est fusionnable » doit s’assurer que la demande de fusion reste encore possible avant d’intervenir. Le réveil peut remonter à quelques minutes, et un autre acteur, qu’il s’agisse d’une personne ou d’un autre agent, a déjà pu s’en occuper. Les concurrences au moment du réveil sont des concurrences sur un état partagé ordinaires, avec un délai plus long entre la cause et l’effet.

Les flux présentent des failles, ce qui exige une vérification périodique pour chaque suivi. Les points d’entrée subissent des pannes, les abonnements expirent et les fournisseurs interrompent parfois la livraison sans en avertir. Un suivi basé uniquement sur la réaction aux événements finira par en manquer un sans que personne ne s’en aperçoive ; de l’extérieur, un agent silencieux parce que rien ne s’est produit ressemble à un agent silencieux parce qu’il est devenu inopérant. La solution est ancienne et peu attrayante : une vérification planifiée lente qui compare l’état réel à ce que le flux d’événements a signalé, de manière similaire aux systèmes de paiement qui concilient ce qui était prévu, ce qui a été facturé et ce qui a été livré. Utilisez le mécanisme push pour gérer la latence et cette vérification pour obtenir la vérité.

Problématiques avancées : adversaires, attention, concurrence et tempêtes

Le déclencheur est la surface d’attaque

Reconsidérez les cinq types d’entrée avec une perspective de sécurité. Quiconque peut envoyer un événement peut, en fait, déclencher un agent environnemental. Les charges utiles de webhook, les corps d’e-mails et les commentaires relatifs aux problèmes capables de provoquer un réveil sont tous des textes non fiables, et ils arrivent devant un modèle disposant d’accès à des outils. Contrairement aux conversations, il n’y a personne présent au moment du réveil pour remarquer qu’il y a un problème. Un e-mail soigneusement conçu comme étant « urgent » ne se contente pas de gaspiller un réveil ; il détermine ce que l’agent va penser, et c’est le premier pas de presque toutes les chaînes d’injection de commandes.

Toutes les mesures d’atténuation standard s’appliquent. Traitez le contenu des événements strictement comme des données. Isolez davantage l’agent environnemental que vous ne le feriez pour un agent de chat. Séparez bien les trois capacités dangereuses : l’accès aux données privées, l’exposition à du contenu non fiable et la capacité de communiquer en externe ; un agent qui surveille les boîtes aux lettres et dispose d’outils étendus ainsi que de la possibilité d’envoyer des messages possède ces trois capacités en plus d’une fonction supplémentaire. Ajoutez une règle spécifique aux systèmes environnementaux : l’autonomie doit être proportionnelle au degré de confiance que vous accordez au déclencheur. Un déclenchement causé par votre propre planning peut entraîner une action, tandis qu’un déclenchement provoqué par du contenu provenant d’une tierce partie devrait principalement servir à avertir.

L’être humain est la ressource la plus rare dans ce cycle

La plupart des actions produites par un agent environnemental consistent en interruptions pour les personnes, et ces interruptions sont une sorte de « monnaie » dont la valeur diminue lorsqu’elles sont trop fréquentes. Un modèle utile, bien décrit par le système de boîte aux lettres des agents de LangChain, consiste en une échelle à trois étapes pour définir ce qu’un agent peut demander à une personne :

• Informer. Seulement pour fournir des informations ; aucune action n’est requise.
• Poser une question. L’agent a besoin d’un fait précis avant de pouvoir continuer.
• Présenter pour examen. L’agent a préparé une action et souhaite obtenir l’approbation.

L’idée clé liée au contexte est que cet outil double également en tant que métrique de qualité. Enregistrez la manière dont les personnes réagissent à chaque interruption : en y répondant, en l’ignorant ou en la mettant de côté. Cela vous permet d’obtenir une mesure précise pour l’ensemble du processus. Un agent dont les notifications sont ignorées 80 % du temps représente non seulement 80 % de ressources gaspillées, mais cela incite aussi les utilisateurs à les désactiver ; une fois ce fait, les 20 % utiles disparaissent également. La fatigue due aux alertes a entravé le déploiement des systèmes de surveillance pendant des décennies, bien avant l’apparition des modèles linguistiques, et des textes d’alerte élégants ne changent rien à cela.

Concurrence : un superpouvoir accompagné d’un risque

La définition d’un agent ambiant inclut l’action simultanée sur plusieurs événements, et ce détail est facile à manquer. Un agent de chat gère une seule conversation. Un agent ambiant pourrait avoir quarante instances actives en même temps, chacune dans un contexte propre distinct, chacune possédant une vision partielle de la réalité partagée. Vous avez ainsi acquis un système multi-agents sans l’avoir décidé, avec ses problèmes liés à l’état partagé. Deux instances générées par des événements liés pourraient s’emparer du même ticket, écrire des réponses contradictoires dans un même thread ou prendre la même tâche, sans que l’une ou l’autre ne puisse s’en rendre compte, car les contextes propres ne partagent rien entre eux.

Les solutions, dans un ordre approximatif de préférence :

• Partitionner les instances selon une clé de corrélation afin que chaque situation possède son propre état. Le regroupement réalisé à l’étape deux fonctionne également comme règle de propriété : chaque situation obtient exactement une instance et aucun double parallèle.

L’écriture sur le réseau s’effectue via un seul écrivain lorsque le partitionnement ne suffit pas.

Utilisez la concurrence optimiste lorsque deux événements doivent réellement toucher le même objet, et traitez un conflit comme une erreur afin que le deuxième écrivain réévalue sa décision au lieu d’écraser celle du premier.

Si le système est bien conçu, la plupart de ces solutions sont obtenues gratuitement, et ce n’est pas un hasard. Les clés de corrélation qui regroupent les événements et les clés de propriété qui protègent l’état ont naturellement tendance à être les mêmes clés.

Mode tempête

Un seul incident en amont peut générer dix mille événements corrélés. Un système naïf transforme cela en dix mille événements distincts, entraînant une forte augmentation de la consommation de ressources et quarante notifications qui provoquent le mutage du canal au milieu de l’incident. Les équipes opérationnelles ont résolu une version de ce problème il y a longtemps grâce à la détection des fluctuations et au regroupement des incidents.

L’équivalent agent est un détecteur d’ouragan qui compare le taux d’événements actuel à une valeur de référence et, lorsqu’il augmente brusquement, passe le système en un mode différent. En mode ouragan, tout ce qui est corrélé est regroupé en une seule situation : un seul agent est réveillé avec un résumé des informations, et il reçoit des instructions précises : il s’agit d’une tempête ; qu’il en fasse un résumé, identifie la cause la plus probable et envoie une notification. Le contrôle des coûts est important, car c’est à la fin de la charge de travail que les budgets sont épuisés, mais l’aspect lié à l’attention l’est encore plus. Lors d’un incident, la capacité d’une personne à gérer les interruptions diminue précisément au moment où le taux d’événements augmente. Le mode ouragan permet au système de tenir compte de cette inversion.

Évaluer l’agent inactif comme un produit

Deux chiffres sont les plus importants :

• Cost par réveil utile. Le coût total divisé par le nombre de réveils que la personne, à posteriori, juge utiles. Il s’agit d’une analyse économique appliquée à votre propre système.
• Précision et rappel du triage. Ces critères peuvent être évalués de manière très efficace hors ligne. Faites passer trente jours d’événements passés par le système de filtrage et comparez les réveils qu’il aurait déclenchés avec la manière dont les gens ont réellement réagi.

Cette suite d’outils de relecture fait partie des rares évaluations qui peuvent être créées presque gratuitement, car les étiquettes existent déjà dans l’historique des tickets. Elle transforme les modifications apportées au système de filtrage en différences mesurables.

Autonomie dépendante de l’horloge

Un autre schéma, peu coûteux à mettre en œuvre mais étrangement rare, consiste à faire dépendre le plafond d’autonomie d’un système de surveillance du moment où il est activé et des personnes qui peuvent être atteintes. Une découverte qui justifie une correction automatique à 11 heures un mardi, lorsque les gens sont en ligne, qu’un bouton d’arrêt est à portée de main et que le rayon d’action de l’explosion est bien connu, ne mériterait peut-être qu’une alerte dans les premières heures d’un dimanche.

Ce n’est pas une prudence excessive. Il s’agit d’une décision basée sur la valeur attendue, où le temps constitue un paramètre clé. Le coût de demander une intervention est faible pendant les heures de travail et très élevé la nuit. En même temps, l’avantage d’une surveillance humaine – la probabilité que quelqu’un repère une erreur multipliée par le coût de cette erreur – diminue la nuit car personne n’est présent pour surveiller. Ainsi, le terme d’erreur prend le dessus et le seuil devrait se déplacer vers la demande d’intervention, ce qui, en pratique, signifie différer l’action, puisqu’il n’y a personne éveillé pour y répondre.

Encodez ceci comme une recherche dans le système qui combine la fiabilité du déclencheur, la gravité de l’action et la disponibilité humaine, pour les associer à l’un de trois résultats : agir immédiatement, être mis en file d’attente pour le matin ou être notifié aussitôt. L’option mise en file d’attente pour le matin est l’héros discret. La plupart des éléments que remarque un agent environnemental à 3 heures du matin peuvent très bien attendre d’être examinés à 8h55, déjà accompagnés de l’action proposée par l’agent, arrivant à peu près au moment où le premier café est prêt.

Modèles dans les systèmes réels

Un assistant par e-mail disposant d’une boîte de réception pour ses utilisateurs humains

L’agent environnemental de référence de LangChain gère les e-mails : il rédige des réponses, enregistre les messages et procède à l’escalade. Sa conception d’interaction est plus pédagogique que sa fonction de rédaction. L’équipe qui le développe considère l’intervention humaine non pas comme une concession, mais comme un élément qui diminue les risques, facilite le déploiement, renforce la confiance et alimente la mémoire à long terme. Leur Agent Inbox, une interface unique permettant de consulter tous les échanges en cours entre une personne et ses agents, incarne concrètement la hiérarchie des notifications, des questions et des revues. Une blague récurrente de ce projet, selon laquelle si l’on est ignoré, c’est sûrement la faute de l’agent, illustre parfaitement l’économie de l’attention : l’agent existe pour utiliser plus judicieusement l’attention d’une personne, et les blagues naissent lorsque cela ne se produit pas.

Agents planifiés dans les outils de codage

Les principales plateformes de codage ajoutent progressivement des agents qui s’exécutent selon des plannings ou des événements de répertoire plutôt que sur demande ; les routines de Claude Code et les exécutions déclenchées par GitHub en sont des exemples que de nombreux développeurs ont déjà rencontrés. Vérifiez la documentation actuelle, car ces fonctionnalités évoluent rapidement. Deux choix de conception se retrouvent dans tous ces systèmes, et tous deux soutiennent l’argument présenté ici. Chaque exécution démarre une session propre, la continuité étant conservée dans les fichiers et la mémoire plutôt que dans un transcript infini. De plus, le niveau de déclenchement repose sur des infrastructures classiques telles que les expressions cron, les filtres webhook et le YAML conditionnel, sans aucun modèle intervenant dans le processus. L’intelligence artificielle est coûteuse tandis que les mécanismes de déclenchement sont peu onéreux, c’est pourquoi ces produits les maintiennent séparés.

Observateurs de l’infrastructure

Les fournisseurs de services cloud ont décrit des modèles d’agents environnementaux qui surveillent l’infrastructure et signalent proactivement les anomalies détectées. Ceux qui sont bien conçus ressemblent à la mise en pratique de ce guide. Les événements proviennent du bus d’événements natif de la plateforme, ce qui permet un filtrage structurel gratuit. Les événements sont corrélés avant que tout agent ne soit activé. Et pour toute situation importante, les agents génèrent des rapports à examiner plutôt que d’appliquer des correctifs de leur propre chef. Le principe intéressant à retenir est le gradient de confiance : plus une action proposée a d’impact, plus elle monte haut dans la hiérarchie des étapes de notification, de questionnement et d’examen. L’observation peut se faire de manière autonome ; l’intervention nécessite une supervision.

L’équipe de surveillance, un quart d’année plus tard

Retournez à l’équipe après la mise en place définitive de la nouvelle conception. Leur processus comprend désormais des webhooks, un regroupement des threads avec une période de silence de dix minutes, un petit classificateur dont l’ensemble des instructions tiendrait sur une carte index, ainsi que près de trente activations de modèles avancés par mois. Deux résultats se détachent : le coût par activation utile diminue d’environ quarante fois, et, de manière inattendue, le taux de reconnaissance augmente. La conception initiale divisait les situations en tranches arbitraires de deux minutes, ce qui a conduit, à au moins deux reprises, à rejeter une vue partielle de quelque chose qui, dans son ensemble, méritait clairement un « oui ».

Ainsi, la nouvelle conception a permis bien plus que simplement de réduire les coûts. Le regroupement des événements a amélioré la qualité des jugements, car le modèle évaluait enfin des situations complètes plutôt que de simples fragments arbitraires. Le problème ne résidait jamais dans le job planifié ; c’était plutôt demander à un modèle d’évaluer chaque instant de ce job qui posait problème.

Choisir vos éléments de base

La majeure partie de cette pile logicielle devrait être achetée ou réutilisée plutôt que développée de zéro.

• Infrastructure de déclenchement. Cron et ses équivalents gérés ; des bus d’événements et des files d’attente tels que EventBridge, Pub/Sub, Kafka ou des webhooks classiques ; ainsi que des planificateurs et des signaux dans des moteurs de workflow comme Temporal, Restate ou Inngest, qui offrent également un stockage fiable. Les étapes un et deux du processus correspondent directement aux fonctionnalités déjà présentes dans ces outils.

Structure d’agent environnemental. LangGraph, avec fonctionnalités de persistance, d’interruption et de planification via cron, ainsi que l’Agent Inbox open source ; les modes planifiés et déclenchés des principaux agents de codage, tels que les routines Claude Code et les intégrations GitHub Actions ; et un ensemble croissant de connecteurs qui transforment des e-mails ou des webhooks en exécutions d’agents. Évaluez-les tous selon trois critères : l’endroit où a lieu le tri (il devrait se faire avant le modèle), ce que reconstruit le mécanisme de réactivation, et ce que voit finalement l’utilisateur.

Niveau de tri. N’importe quel modèle petit et rapide fera l’affaire. La clé réside dans une instruction précise et dans une évaluation par rejouement hors ligne, et non dans le choix du modèle.

L’boîte de réception. Utilisez l’Agent Inbox de LangChain si vous souhaitez une interface existante, ou les canaux actuels de votre équipe tels que Slack, l’e-mail ou les tickets, en veillant à ce que les trois actions soient clairement définies et mesurées.

Consacrez votre budget dédié aux nouveautés au funnel et à la reconstruction du contexte post-activité, puis achetez tout le reste. Les planificateurs sont un problème déjà résolu, éprouvé au fil de décennies d’essais pratiques. Un boucle maison qui interroge un modèle toutes les deux minutes ne l’est pas.

Toute la conception tient en quelques lignes de pseudocode. Lisez-le de haut en bas comme le funnel : une vérification de règles gratuite, qui se transforme progressivement en évaluation de la situation (sans retourner de résultat tant que l’incident est encore en cours), une classification peu coûteuse, une protection contre les livraisons dupliquées grâce à l’idempotence, la reconstruction du contexte post-activité à partir de l’heure actuelle, le fichier des objectifs et de nouvelles lectures, l’exécution d’un agent selon un budget prédéfini, et enfin la livraison via l’un des trois verbes de boîte de réception.

async def on_event(evt):
    if not rules_pass(evt):            return                  # stage 1: free
    sit = coalesce(evt, window="10m")                          # stage 2: situations, not events
    if sit is None:                    return                  # burst still settling
    if triage_small_model(sit) == "ignore": return             # stage 3: cheap
    if seen(sit.idempotency_key):      return                  # at-least-once armor
    ctx = rebuild(now(), goal_file, fresh_reads(sit))          # stage 4: wake = reconstruction
    outcome = await agent.run(sit, ctx, budget=WAKE_BUDGET)
    inbox.deliver(outcome.verb, outcome.summary)               # notify | question | review

Notez où se trouve la vérification d’idempotence : après les filtres peu coûteux mais avant toute opération coûteuse ou irréversible. Elle pourrait également être placée plus tôt ; ce qui compte, c’est qu’aucun doublon n’atteigne jamais agent.run. Dans un système réel, c’est aussi dans la fonction rebuild que doit avoir lieu la vérification avant action, car c’est le premier moment où un état frais est disponible.

Guide des modes de défaillance

• Le bûcher des requêtes de sondage. Un modèle coûteux est demandé à plusieurs reprises d’inspecter rien du tout. Solution : appliquer des règles et effectuer un regroupement des données avant toute appel au modèle, puis utiliser un modèle peu coûteux avant le modèle coûteux.
• La horde tonitruante. Une seule panne se propage et provoque des milliers d’effets secondaires. Solution : mode tempête, avec un détecteur de fréquence, regroupement complet des données, un seul agent et une seule notification.

L’onde double. Un événement réexpédié parvient à un agent capable de prendre des actions concrètes. Solution : clés d’idempotence sur les ondes et vérification de la situation avant toute action.

L’onde obsolète. Les décisions se basent sur une capture d’écran du moment où le déclencheur a fonctionné, alors que la réalité a évolué depuis. Solution : chaque onde lit à nouveau l’heure, récupère un état mis à jour et révérifie les faits avant d’agir.

L’onde injectée. Le contenu fourni par un tiers décide de ce à quoi votre agent autonome prête attention. Solution : traiter le contenu des événements comme des données, ajuster le degré d’autonomie en fonction du niveau de confiance dans les déclencheurs, et soumettre plus strictement les agents environnementaux à un environnement isolé que les agents de chat.

La boîte de réception silencieuse. La précision des interruptions diminue progressivement jusqu’à ce que les gens cessent d’écouter. Solution : suivre les notifications traitées, ignorées ou écartées, et considérer un taux de traitement inférieur à 50 % comme une panne.

L’écart silencieux. Un webhook a cessé de fonctionner il y a des mois sans que personne ne s’en aperçoive, jusqu’à ce qu’une renouvellement soit manqué. Solution : mesurer la latence, vérifier la situation réelle, et effectuer un rapprochement progressif en partant du principe que le flux fourni est erroné.

Le daemon immortel. Une session reste active pendant des mois et s’éloigne progressivement de son objectif. Solution : créer une nouvelle session à chaque démarrage, en conservant la continuité dans des fichiers et de la mémoire plutôt que dans un transcript.

La surprise de minuit. Les actions les plus dangereuses ont lieu au milieu de la nuit parce qu’il n’y a personne pour s’y opposer. Solution : faire passer les actions conséquentes par une étape de validation, faire dépendre les seuils d’autonomie de l’heure, et conserver à portée de main un mécanisme d’annulation fonctionnel.

Un plan sur une semaine pour commencer

1. Faites un audit de vos déclencheurs. Notez chaque chemin qui peut activer votre agent aujourd’hui et le coût de chaque déclenchement. Marquez tout chemin correspondant à un « appel à un modèle selon un horodatage » comme étant la première chose à corriger.
2. Construisez la première étape. Mettez des filtres structurels devant chaque déclencheur et mesurez le taux de rejet. S’il est inférieur à la moitié, vos règles sont trop prudentes.

Fusionner les données. Choisissez des clés de corrélation telles que le thread, la demande de pull request, l’incident ou le client, ajoutez un mécanisme d’attente à la fin du traitement, et changez la définition de l’entrée de votre agent de « un événement » en « une situation ».

Ajouter le niveau de triage. Utilisez un petit modèle produisant une réponse composée d’un seul mot. Ensuite, créez une évaluation basée sur les événements du mois dernier et les réponses réellement données par les utilisateurs, afin d’évaluer la précision et le taux de rappel du processus avant de vous en fier à lui.

Rendre les opérations sécurisées. Ajoutez des clés d’idempotence, un mécanisme de vérification avant action, ainsi qu’une routine de reconstruction : horloge, lectures fraîches, fichier cible.

Installer l’échelle de gestion. Définissez clairement les types de sortie pour les actions de notification, de questionnement et d’examen, assurez-vous qu’elles soient envoyées dans un endroit où vous pouvez les suivre, et commencez à enregistrer si chacune a été traitée, rejetée ou ignorée.

Exécutez deux exercices. Rejouez une séquence pour confirmer que le mode tempête la regroupe, et désactivez un webhook pendant une heure pour vérifier que le système de balayage détecte l’espace vide. Enfin, calculez pour la première fois le coût par effet utile et affichez-le à côté de la consommation de tokens.

En résumé : perception ambiante, engagement humain

Il existe un véritable débat sur l’orientation des interfaces d’agents. D’un côté, on affirme que le chat constitue une interface transitoire et que les agents vivront de plus en plus au sein des flux d’événements, détectant les problèmes avant les humains. L’attention est la ressource la plus rare pour les travailleurs du savoir, et un logiciel qui consacre son propre temps à l’observation, tout en n’utilisant le vôtre que lorsque c’est nécessaire, est simplement un meilleur logiciel.

L’autre camp souligne qu’un agent disponible en permanence doté d’outils combine précisément les risques évoqués ci-dessus : des déclencheurs non fiables, l’absence de personne présente au moment du déclenchement et une autonomie en pleine nuit. Selon cette perspective, la demande n’a jamais été une charge supplémentaire ; il s’agissait d’un consentement, et chaque étape qui retire une personne du processus déplace le risque du moment de l’action vers la qualité des mécanismes de contrôle mis en place.

Les deux parties ont raison, et le funnel représente le point où elles se rencontrent. Il est possible d’observer tout ce qui se passe, mais notez que ce qui a permis aux exemples ci-dessus de réussir, c’est l’ingénierie traditionnelle : le filtrage, la suppression des signaux parasites, une gestion idempotente, des tâches de conciliation et une attention portée à la fatigue due aux alertes. Tout engagement nécessite néanmoins un consentement, ce que représente précisément l’échelle « notifier, interroger et examiner » : autonomie pour observer, escalade pour agir. La solution consiste en des agents qui observent de manière large, se réveillent rarement et cherchent une approbation avant de modifier quoi que ce soit d’important.

Un exercice utile ne prend qu’une soirée. Choisissez le flux d’alertes le plus intense de votre journée de travail et élaborez un funnel pour lui : quelles règles simples pourraient en filtrer le contenu, ce qui pourrait être regroupé, quel petit modèle pourrait trier les informations et ce qui mériterait réellement une attention immédiate. Vous aurez conçu votre premier agent inactif avant même d’écrire le moindre code pour lui.

Lectures associées