Les agents d’IA font remonter la prise de décision dans la pile technologique

Lori Mac VittieIngénieur émérite et évangéliste en chef | F5

Vous voyez ce moment où vous réalisez que l’architecture que vous perfectionnez depuis dix ans est sur le point de se faire balayer par quelque chose qui n’était même pas sur les radars il y a deux ans ?

Bienvenue dans l’ère des architectures d’agents.

Il ne s’agit pas de simples scripts d’automatisation ou de surcouches d’IA. Les agents sont guidés par des objectifs, génératifs et de plus en plus autonomes. Ils ne se contentent pas d’appeler des API : ils tracent leur propre chemin à travers celles-ci. Et le plus surprenant ? Ils appliquent leurs propres règles.

Chaque requête envoyée par un agent peut contenir :

En-têtes d’intention (X-Goal, X-Context, X-Route-Preference) Instructions de repli fondées sur la sensibilité réelle aux SLA Un historique de ce qui n’a pas fonctionné la dernière fois Des indications sur ce à quoi ressemble réellement la réussite (spoiler : ce n’est pas « 200 OK »)

C’est la prise de décision en action. Il ne s’agit pas d’une orchestration centralisée et planifiée à l’avance, mais d’une délégation à l’exécution, qui va transformer le fonctionnement de l’infrastructure.

Pourquoi c’est important (plus tôt que vous ne le pensez)

À l’heure actuelle, la plupart des systèmes d’entreprise ne ressentent pas encore ces frictions. Les premiers agents restent des chatbots, des copilotes ou des outils isolés visant à améliorer la productivité.

Mais à mesure qu’ils s’intègrent aux processus métier (par exemple, la résolution des commandes, le traitement des demandes d’indemnisation, le triage ou encore l’exécution des commandes), ils commencent à interagir avec des systèmes réels. Cela signifie que :

• L’infrastructure doit pouvoir interpréter la logique embarquée par les agents
• Les passerelles doivent analyser bien plus que les JWT et les chemins d’accès
• Les répartiteurs de charge doivent cesser de raisonner en termes de « plus rapide » et commencer à raisonner en termes de « mieux adapté à cette tâche »

Ce n’est pas encore une crise. Mais elle se profile. Et lorsqu’elle surviendra, le problème ne sera pas le manque de bande passante, mais le décalage entre la manière dont les agents prennent leurs décisions et celle dont l’infrastructure gère le trafic.

Le changement de paradigme : du contrôle à l’exécution

Voici la véritable conclusion sur le plan architectural : les agents font remonter la prise de décision dans la pile.

La requête devient le plan de contrôle.

Elle ne demande pas à l’infrastructure : « Que dois-je faire ? » Elle lui dit : « Voici ce dont j’ai besoin. Voici comment je veux que tu te comportes. Maintenant, fais-le. »

Si vos systèmes traitent cela comme une requête ordinaire, comme une simple requête GET ou POST de plus, les mécanismes de repli entreront en conflit, les nouvelles tentatives se chevaucheront et les performances des agents se dégraderont pour des raisons qui n’apparaîtront pas dans vos tableaux de bord.

Non pas parce que l’infrastructure a échoué, mais parce qu’elle n’était pas à l’écoute.

D’où cela vient

Cette évolution n’est pas théorique : elle se concrétise à travers de véritables cadres. Des initiatives telles que le Model Context Protocol (MCP), les modèles de communication Agent-to-Agent (A2A), et même les premiers travaux sur le routage des tâches encadré par des politiques, vont toutes dans le même sens :

• MCP intègre le contexte complet — objectifs, contraintes et options de repli — directement dans la charge utile de la requête.
• Les protocoles A2A permettent aux agents de coordonner les tâches et de déléguer dynamiquement les décisions, sans orchestrateur central.
• Délégation des tâches à l’exécution via des métadonnées structurées permettant à l’infrastructure d’interpréter — et non de décider — au moment de l’exécution.

Ils diffèrent par leur syntaxe, leur structure et leur niveau d’abstraction, mais aboutissent tous au même résultat architectural : la politique dans la charge utile et la finalité dans la requête.

Et dès lors que la requête devient porteuse de la logique, l’infrastructure n’a plus que deux choix : s’adapter ou se réduire à un simple pipeline acheminant des charges utiles.

Ce que vous pouvez faire dès maintenant (avant que cela ne devienne un problème)

Il ne s’agit pas de tout remplacer. Il s’agit d’anticiper cette évolution tant qu’elle n’en est qu’à ses débuts. Commencez par ceci :

1. Capturer le contexte
   Consignez X-Intent, X-Task-Profile, ainsi que toute autre métadonnée susceptible d’indiquer ce que l’agent cherche à accomplir. Si votre observabilité s’arrête à l’URI, vous avez déjà pris du retard.
2. Raisonnez en termes d’« adéquation à la tâche », et non de « disponibilité »
   Ce n’est pas parce qu’un backend est opérationnel qu’il est suffisamment performant. Commencez à expérimenter des modèles d’état de santé qui tiennent compte des SLA, des seuils de latence et de l’intention.
3. Optimisez vos politiques
   Les plateformes de mise à disposition et de sécurité des applications disposent de couches de script. Exploitez-les. Commencez à analyser les en-têtes d’intention. Modifiez les règles de routage en fonction des objectifs de la requête, et pas seulement du chemin d’accès au service.
4. Prévoyez une application adaptative des règles
   Au lieu de définir une logique de repli dans un fichier de configuration statique, commencez à étudier comment l’infrastructure peut appliquer les instructions de repli intégrées à la requête elle-même.
5. Créez une boucle de rétroaction
   Si les agents réacheminent le trafic en fonction des performances passées, vous devez faire partie de cette boucle. Réinjectez les informations contextuelles sur les résultats dans vos systèmes de gestion du trafic et de surveillance de l’état de santé.

Dernière réflexion : vous n’êtes pas remplacé, vous êtes repositionné

Dans une architecture pilotée par des agents, l’infrastructure ne disparaît pas. En revanche, elle change de rôle. Elle cesse de prendre les décisions pour devenir celle qui les exécute intelligemment.

Si vous parvenez à opérer ce changement suffisamment tôt, vous serez prêt à affronter la vague lorsqu’elle arrivera. Et elle arrive.

Plus tôt que la plupart des gens ne le pensent.

À propos de l’auteur

Lori Mac VittieIngénieur émérite et évangéliste en chef | F5

Lori MacVittie est ingénieure émérite et évangéliste en chef au sein du bureau du directeur technique de F5. Elle possède une expertise approfondie dans la fourniture d’applications, les stratégies d’automatisation et les infrastructures. Elle est réputée pour sa capacité à rendre la complexité intelligible, qu’elle définisse des garde-fous pour les agents d’IA, analyse des architectures multicloud fragiles ou explore les limites des systèmes évolutifs. Elle cumule plus de trente ans d’expérience dans le secteur, couvrant le développement d’applications, l’architecture informatique ainsi que l’exploitation des réseaux et des systèmes. Avant de rejoindre F5, elle a été rédactrice spécialisée dans les technologies et a reçu plusieurs distinctions. MacVittie est titulaire d’un master en informatique et est une autrice prolifique dont les publications couvrent la sécurité, le cloud et l’architecture d’entreprise. Elle est également une passionnée de jeux de société et de jeux vidéo, et assume pleinement ses avis bien tranchés sur le fromage.

Autres articles de Lori Mac Vittie