Les agents IA passent à l'acte : appels réels, effets de bord et gouvernance

💡 En résumé

Pendant longtemps, la démonstration d’agent consistait à montrer un modèle raisonner. Cette semaine, la démonstration consiste à le laisser agir sur des systèmes réels : Google autorise Gemini à téléphoner à des commerces avec le numéro personnel de l’utilisateur, une startup lève 20 M$ pour donner aux agents leur propre boîte de réception dans une messagerie d’entreprise, et une série de papiers arXiv explique où placer les garde-fous maintenant que l’écriture, la réservation et le paiement ne sont plus des simulations.

Le message de fond est net : la fiabilité d’un agent ne se joue plus dans le modèle, mais dans le contrat qui l’entoure. Sur 25 930 épisodes de test, la duplication d’effets de bord — un second paiement, une seconde annonce, un second déploiement — dépend du modèle quand un simple retour de lecture révèle ce qui s’est passé, et du contrat d’outil quand ce n’est pas le cas (56 % et 74 % de duplications chez des modèles frontière dans ce second régime). Autrement dit : demander au modèle d’être prudent ne suffit pas ; il faut concevoir l’outil pour qu’un doublon soit impossible.

🔥 Tendances : l’agent quitte la démo et entre dans les systèmes

Gemini téléphone pour vous

Google teste « Call for Me », une fonction qui permet à Gemini d’appeler réellement des commerces à la place de l’utilisateur. Le déploiement initial est restreint aux propriétaires de Pixel 11 abonnés à Gemini aux États-Unis, avec la version bêta de l’application Téléphone — un lancement volontairement prudent, l’entreprise rappelant que « les conversations du monde réel sont nuancées ».

Le saut qualitatif par rapport aux fonctions précédentes (« Ask for Me », « Hold for Me », « Talk to a Live Rep », « Direct My Call ») tient à trois choses :

l’agent peut partager des informations personnelles approuvées par l’utilisateur, ce qui élargit considérablement l’espace d’action ;
il utilise le numéro personnel de l’utilisateur, l’appel étant composé directement depuis le téléphone — pas de numéro intermédiaire, donc pas de filtre protecteur ;
l’utilisateur peut suivre l’appel en direct via une transcription et reprendre la main à tout moment.

Les tâches annoncées sont banales mais ce sont exactement celles qui coûtent du temps : vérifier un stock, réserver une table, décaler un rendez-vous, mettre un article de côté. L’agent se présente, navigue les serveurs vocaux, attend en ligne, puis négocie avec l’humain au bout du fil.

Une messagerie conçue pour les agents, pas adaptée aux agents

Ando, la startup de Sara Du, sort de stealth avec une plateforme de messagerie d’équipe conçue dès le départ pour des participants mixtes humains/agents, et 20 M$ levés auprès d’Accel, Index Ventures et Emergence. La thèse de la fondatrice mérite d’être citée parce qu’elle formule un problème réel : dans Slack ou Teams, « les agents étaient traités comme des applications que l’on installe, alors qu’ils devenaient des participants de l’équipe ».

Le symptôme qu’Ando attaque, Du l’appelle les « meat proxies » — ces humains transformés en relais : quelqu’un doit recopier le travail de l’agent pour que l’organisation le voie. Dans Ando, les agents ont leur propre identité et boîte de réception, peuvent parcourir les canaux, en rejoindre un sans être mentionnés, et alerter un humain de leur propre initiative, sans validation préalable. La fonctionnalité qui a convaincu les premiers clients : un agent repère deux conversations parallèles sur le même problème dans deux canaux différents, crée un groupe, explique le contexte et propose une décision — sans qu’on le lui demande.

Le point intéressant pour les architectes : Du admet que les premiers retours étaient tièdes (« juste une messagerie un peu plus bancale ») et que la valeur n’apparaît qu’au bout de quelques semaines d’usage. Le coût, lui, est assumé : les fonds levés serviront notamment à « brûler plus de tokens ». C’est un modèle économique où le budget d’inférence est un poste de croissance, pas un coût à minimiser.

🤖 Nouveaux outils : les garde-fous deviennent exécutables

LIMBO : où doit vivre l’exactement-une-fois ?

C’est probablement le papier le plus opérationnel de la semaine. LIMBO est un bac à sable déterministe de six services dotés de contrats réalistes (clés d’idempotence optionnelles, cohérence à terme, chemins de lecture manquants) et de douze modes de panne injectés à la frontière du service : validations tardives, redélivrances, lots partiels. Chaque épisode est noté contre un registre des effets réellement validés.

Résultats sur 25 930 épisodes, neuf modèles récents, trois harnais de production, deux variantes de contrat et quinze conditions de reprise :

Régime de panne	Qui décide ?	Taux de duplication
Un retour de lecture immédiat révèle ce qui s’est passé	le modèle	0,5 % (frontière) — le modèle explique 53 % de la variance expliquée
Requête encore en vol, ou transport ayant livré deux fois	le contrat	56 % et 74 % (modèles frontière) — le contrat explique 81 %

Le papier démontre en outre qu’aucune politique de vérification seule ne garantit l’exactement-une-fois sous validation tardive, sans borne sur le temps de vol. Attendre fonctionne si cette borne est courte et connue — mais avec des délais à queue lourde, même une heure d’attente par épisode ne suffit pas à offrir une garantie d’idempotence.

La leçon pratique pour toute équipe qui branche un agent sur un système de paiement, de facturation ou de publication : la clé d’idempotence n’est pas une option de confort, c’est la seule barrière qui tient quand le réseau ment. Et l’attente, présentée comme une parade robuste, ne l’est pas.

Contrôler le harnais, c’est contrôler la facture

Le second papier répond à une question que beaucoup d’entreprises découvrent trop tard : qui décide de ce que coûte un agent de code ? Réponse : le harnais — le produit qui exécute l’agent. C’est lui qui choisit quel modèle répond, ce que le modèle lit, comment le cache de prompt est utilisé et quels sous-agents tournent. Il choisit donc le tarif de la grille et le volume acheté à ce tarif.

Les auteurs construisent un routeur où un classifieur calibré (Jev) étiquette chaque prompt selon une taxonomie d’applications agentiques « bring-your-own ». Contrainte technique essentielle : comme un tour utilisateur est en réalité une multitude de requêtes sur un cache de prompt appartenant à un seul modèle, le routeur ne déplace le travail que là où aucune conversation en cours ne doit reconstruire son cache — au démarrage de session, dans les voies latérales et au lancement des sous-agents.

Deux résultats à retenir :

la dérivation du point de bascule montre qu’en session longue et dense en outils, le modèle le plus cher revient moins cher que le palier inférieur — contre-intuitif, mais cohérent avec la reprise de cache ; la conclusion tient après re-tarification d’environ 10 000 sessions réelles issues de jeux de données publics ;
dans une entreprise émulée de 10 000 sièges, le routeur récupère 14 à 21 % de la dépense modèle aux tarifs Anthropic du 21 septembre 2026, soit 3,3 à 5,0 M$ par an.

Le papier cartographie aussi les risques sur vingt harnais et chiffre la dépendance aux modèles d’un fournisseur unique. C’est la partie la plus stratégique : acheter un harnais propriétaire non personnalisé, c’est hériter de ses choix — et de sa facture.

Le contrôle d’accès par les compétences (skilder)

skilder propose une réponse structurelle au problème du « trop d’outils ». Donner à un agent l’accès à l’ensemble du catalogue interne produit trois dégâts simultanés : fenêtres de contexte surdimensionnées, sélection d’outils dégradée, et failles de gouvernance — car une politique écrite dans un prompt reste un conseil probabiliste, pas une contrainte dure.

Le cadre empaquette les capacités en rôles : des ensembles de compétences, d’outils et d’instructions, accompagnés des limites qui les bornent. L’agent démarre avec un catalogue minimal, apprend les rôles qu’exige la tâche, et reçoit les compétences et outils de chaque rôle via un serveur MCP unique. Comme les outils n’atteignent l’agent que dans le cadre de compétences apprises, le même serveur applique déterministement le périmètre de ce qui a été appris.

Évaluation sur 13 tâches et six modèles (10 exécutions chacun), comparée à la sélection d’outils à contexte plat et à l’orchestration multi-agents : quand les modèles accomplissent la découverte et émettent un appel gouverné, la couche d’autorisation simulée n’a laissé passer aucun appel non autorisé ni violation de paramètre (par exemple un dépassement de plafond de dépense). Les échecs restants portent sur le respect du protocole de découverte et la qualité des réponses, pas sur l’autorisation.

La mémoire d’agent doit être bornée dans son périmètre

Troisième mécanisme de contrôle, plus subtil. Scope Before You Persist montre que la mémoire persistante d’un agent — qui permet d’améliorer prompts et compétences sans toucher aux poids — devient nuisible quand le périmètre de récupération ne correspond pas au périmètre de certification de la modification.

Sur ProcStream-RSI, un flux de réparation de code en 12 tours, un gate nommé ORC (Orthogonal Regression Control) fondé sur l’exécution décide quelles éditions persistantes sont acceptées. Dans une intervention où propositions et décisions du gate sont figées, restreindre la récupération de chaque compétence acceptée à sa famille d’origine fait passer l’utilité moyenne de trajectoire cachée de 0,713 (mémoire globale) à 0,816, et les déploiements nuisibles de six sur huit à zéro.

Sur 27 flux randomisés par paires, Scoped-ORC améliore l’utilité de trajectoire de +0,063 [0,037 ; 0,094] par rapport à Global-ORC, accepte 63 mises à jour au lieu de 12, et produit des acceptations multiples dans 19 flux sur 27 — avec 0 acceptation nuisible sur 63. Le contrôle global, lui, descend à 0,713, en dessous de l’agent statique (0,775) : des éditions localement valides interfèrent avec des familles sans rapport.

La formule à retenir : la certification détermine si une modification est étayée ; le périmètre de récupération détermine où cette preuve autorise son usage.

Auto-réparation des pannes grises (MeshHeal)

MeshHeal s’attaque aux « pannes grises » : un agent reste réactif mais sa qualité de résolution se dégrade durablement. Dans un système multi-agents décentralisé, il faut protéger les tâches en cours avant d’avoir les preuves nécessaires pour modifier le routage, tout en permettant le retour des agents rétablis.

Le cadre couple une revue par les pairs appariés en compétence sur deux échelles de temps : rapide (escalade d’une sortie incertaine ou mal notée vers une délibération de comité, puis correction avant usage) et lente (détecteur de dégradation persistante par rapport aux pairs, conditionné à la tâche et à la compétence, déclenchant revue obligatoire puis exclusion du routage ordinaire, avec sondes de récupération pour la réintégration).

Résultats sur BBH, MATH et MMLU-Pro : 0,839 de précision en phase dégradée pour 51 000 tokens modèle par tâche, contre 0,807 pour la meilleure référence (Symphony) à 115 000 tokens par tâche. Moins de la moitié du coût pour un meilleur résultat — l’argument le plus vendeur en production. Les auteurs introduisent au passage Model-Backed MAS Evaluation, qui lie les attributions de compétence à des modèles exécutés, parce que des attributions purement déclaratives dans un prompt laissent les erreurs de routage invisibles.

Ce qui compte : RLVR sur petits modèles, et le harnais comme programme

Deux résultats plus spécialisés valent d’être signalés.

RLVR pour petits agents de recherche : le « reason-over-search » (raisonnement entrecoupé de recherche) n’avait été démontré que sur de gros modèles, ou sous un milliard de paramètres uniquement par distillation d’un enseignant. En entraînant Qwen3.5-0.8B avec GRPO et un outil de recherche Wikipédia, les auteurs obtiennent 0,352 de correspondance exacte moyenne contre 0,092 pour le modèle non entraîné, soit un gain d’un facteur 3,8, sans aucune distillation. Détail contre-intuitif : la récompense « exact-match » fidèle à Search-R1 est la pire des trois formes testées à chaque graine — y compris sur la métrique qu’elle optimise directement. Conclusion : le petit RLVR a besoin de sa propre étude de conception de récompense, pas d’une copie réduite de la recette des grands modèles.

Policy as Code : sur CAR-bench, un harnais où l’unique action du modèle est d’émettre un programme Python qui bloque et reprend à chaque échange d’outil découple l’invocation du modèle des allers-retours d’outils. Médiane de deux appels modèle contre sept tours d’agent par tâche, tâche multi-tours résolue en 1,8 s de latence modèle sur Cerebras gpt-oss-120b. Comme la surface d’action est du code exécutable, les politiques déterministes du banc sont encodées directement dans la couche d’outils au lieu d’être écrites dans le prompt — conformité appliquée à coût de raisonnement nul. Sur l’évaluation officielle cachée : victoire du Track 2 avec 60,0 % de Pass^3, 4,5 fois la référence des organisateurs, au coût estimé le plus bas et à la latence médiane la meilleure (3,14 s) parmi les entrées au-dessus de cette référence. Le même harnais inchangé reproduit 60,0 % Pass^3 sur GPT-5.5. Et le prompt de soumission statique a servi 78 % de ses tokens d’entrée depuis le cache (86,6 % sur sa queue chaude).

📊 Analyse : trois déplacements à intégrer

1. Le modèle n’est pas le bon endroit pour la garantie. Les chiffres de LIMBO sont sans ambiguïté. Quand un retour de lecture suffit, un modèle frontière duplique 0,5 % du temps : la prudence du modèle fonctionne. Quand la requête est en vol ou livrée deux fois, le même modèle duplique dans 56 % à 74 % des épisodes, et c’est le contrat qui explique 81 % de la variance. Toute architecture qui repose sur « l’agent fera attention » avec un système de paiement est donc mal fondée. La clé d’idempotence, le registre d’effets validés et le bornage du temps de vol sont des éléments de conception, pas des consignes.

2. Le harnais est une surface de gouvernance et de coût. Là où l’entreprise croit acheter un outil, elle achète un ensemble de décisions — modèle, contexte, cache, sous-agents — qui fixent la facture et le périmètre de risque. Les 14-21 % de dépense récupérables sur 10 000 sièges ne viennent pas d’une négociation tarifaire mais du routage informé. Et le fait qu’en session dense le modèle le plus cher devienne le moins cher relativise fortement les arbitrages « petit modèle contre gros modèle » menés à la main.

3. La preuve doit être attachée au bon périmètre. C’est le fil commun de skilder, Scope Before You Persist et MeshHeal : une politique écrite dans un prompt est un conseil probabiliste, une compétence livrée par un serveur MCP est une contrainte, une modification certifiée sur une famille de tâches n’est valide que là où la preuve a été produite. Le contrôle global de la mémoire, dans Scope Before You Persist, finit en dessous de l’agent qui n’apprend rien : la mémoire non bornée n’est pas neutre, elle est activement nuisible. Et MeshHeal rappelle qu’il existe une classe de pannes — les pannes grises — que les métriques d’uptime ne verront jamais.

Reste la question que pose l’actualité industrielle : cette fiabilité coûte du temps d’ingénierie. Or la pression commerciale va dans l’autre sens — on annonce l’agent qui téléphone à votre place, avec votre numéro, sans intermédiaire. Le décalage entre la vitesse de mise sur le marché et la mise en place des contrôles est, à ce stade, le vrai sujet.

🎯 À retenir

Gemini « Call for Me » utilise le numéro personnel de l’utilisateur, peut partager des informations approuvées et se laisse interrompre en direct — un agent qui parle au nom de son utilisateur, sans filtre intermédiaire.
LIMBO (25 930 épisodes) : la duplication d’effets de bord dépend du contrat d’outil (81 % de la variance) quand un retour de lecture ne peut pas révéler ce qui s’est passé — 56 % à 74 % de duplications chez des modèles frontière dans ce régime.
Aucune politique de vérification seule ne garantit l’exactement-une-fois sous validation tardive sans borne sur le temps de vol ; l’attente échoue avec des délais à queue lourde.
Contrôler le harnais, c’est contrôler la facture : 14-21 % de dépense modèle récupérables sur 10 000 sièges (3,3-5,0 M$ par an) et, en session longue, le modèle le plus cher peut devenir le moins cher.
skilder : les compétences livrées par un serveur MCP transforment une politique de prompt (probabiliste) en contrainte appliquée déterministement — aucun appel non autorisé passé en évaluation.
Mémoire d’agent : récupérer une compétence hors de sa famille d’origine fait baisser les performances sous celles d’un agent statique (0,713 contre 0,775).
MeshHeal : 0,839 de précision en phase dégradée pour 51 000 tokens par tâche, contre 0,807 pour 115 000 — les pannes grises se traitent moins cher que les baselines ne les détectent.
RLVR à 0,8 milliard de paramètres : 3,8x le plancher non entraîné sans distillation, à condition de choisir une récompense adaptée — la récompense « exact-match » par défaut est la pire des trois.