Systems Design Meditation · Edition 1
L'agent n'est pas le système
Pourquoi l'IA devient un problème d'infrastructure
Edward Calderón
Architecte Logiciel
L'IA commence à disparaître dans l'infrastructure.
Pas parce qu'elle importe moins. Parce qu'elle s'enfonce plus profondément dans la pile.
Pendant plusieurs années, la conversation publique s'est concentrée sur le modèle. Quel modèle raisonne le mieux ? Quel modèle a le contexte le plus large ? Quel modèle écrit le meilleur code ? Ces questions restent utiles. Mais elles ne suffisent plus.
Un modèle répond. Un agent peut agir. Dès que le système peut agir, l'architecture devient aussi importante que l'intelligence.
L'unité d'analyse a changé
Un modèle de langage associe une entrée à une sortie probabiliste. Un agent opérationnel entoure ce modèle de mémoire, d'outils, d'identité, de politiques, de files d'attente, de bases de données et de retours d'information. Il peut lire un ticket, interroger la télémétrie de production, modifier une configuration et notifier un client. Chaque étape franchit une frontière de confiance. La qualité de la phrase générée n'est qu'une petite partie du résultat.
C'est pourquoi le modèle n'est pas le système. Le modèle est un participant au sein du système.
Les questions utiles ressemblent désormais à celles que connaît toute personne ayant exploité une infrastructure cloud ou distribuée : à quoi l'agent peut-il accéder ? Qui lui a délégué son autorité ? Que peut-il modifier ? Quel état maintient-il ? Comment l'action est-elle observée ? Que se passe-t-il si elle est erronée ? L'action peut-elle être annulée ? Qui est responsable ?
L'accès aux outils transforme une erreur de raisonnement en une transition d'état possible. Si un chatbot invente une politique de remboursement, la sortie est erronée. Si un agent exécute le remboursement, met à jour le registre et clôture le dossier, l'organisation environnante a changé. Le modèle de défaillance n'est plus confiné au texte.
Concevoir pour une action délimitée
Une infrastructure d'agents fiable nécessite plusieurs limites. L'identité devrait être propre à chaque charge de travail plutôt qu'une clé d'API partagée. L'autorisation devrait être restreinte, de courte durée et explicite quant aux ressources et aux actions autorisées. Les opérations à fort impact nécessitent des portes d'approbation. Chaque invocation d'outil nécessite des données d'audit structurées : acteur, délégant, entrée, décision de politique, sortie et état résultant.
L'observabilité doit également dépasser le traçage ordinaire des requêtes. Une trace peut nous indiquer qu'un appel a réussi alors que l'action métier était incorrecte. Nous devons relier les décisions du modèle aux appels d'outils, et les appels d'outils aux effets durables. La mesure pertinente n'est pas seulement la latence ou l'utilisation de jetons. C'est de savoir si l'invariant visé tient toujours.
Le rollback est tout aussi concret. Certaines actions peuvent être compensées : un déploiement peut revenir à une révision antérieure. D'autres ne peuvent pas vraiment être annulées : un e-mail a été envoyé, un secret a été exposé, un paiement a été réglé. L'architecture devrait classer les actions avant qu'un agent ne les reçoive, et non après un incident.
Imaginons un agent qui assiste les changements d'infrastructure. Il peut inspecter les métriques et proposer un correctif en toute sécurité. Appliquer ce correctif dans un bac à sable peut nécessiter un identifiant à portée limitée. La production nécessite une évaluation des politiques, une approbation humaine pour les changements risqués, un déploiement progressif, des contrôles de santé et une condition d'arrêt automatique. L'agent peut participer à chaque étape sans devenir un administrateur sans limites.
Ce schéma ressemble au DevSecOps mature, car le problème sous-jacent est familier : faire passer le changement dans un système sans perdre le contrôle du risque. Les agents rendent l'interface plus flexible, mais la flexibilité ne supprime pas la discipline opérationnelle.
La capacité n'est pas la fiabilité
Un modèle très performant au sein d'une infrastructure mal conçue donne un produit fragile. Un modèle un peu moins performant au sein d'une architecture excellente peut donner un système bien plus fiable. Le second système peut contenir l'incertitude, détecter les défaillances et se rétablir.
C'est aussi pourquoi l'adoption en entreprise sera inégale. Les démonstrations sont optimisées pour la capacité visible. Les systèmes de production, eux, doivent gérer le cycle de vie des identités, les frontières des données, la réponse aux incidents, les contrôles des coûts, les preuves réglementaires et les dépendances dégradées. Ces couches ne sont pas une simple plomberie périphérique. Elles déterminent si l'on peut confier du travail à l'intelligence.
Les standards d'agents émergents sont utiles, mais aucun protocole ne se substitue à l'architecture. Un framework d'agents ne peut pas décider de la tolérance au risque d'une organisation. Un fournisseur de modèles ne peut pas définir quelles transitions d'état sont réversibles. Ces décisions relèvent du système qui entoure le modèle.
La direction pratique n'est donc pas l'autonomie partout. C'est une autonomie graduée : observer, recommander, agir au sein d'un périmètre étroit, gagner une autorité plus étendue grâce à une fiabilité mesurée. Cela donne aux équipes un moyen d'apprendre sans prétendre que des composants probabilistes sont déterministes.
L'intelligence seule ne crée pas une infrastructure fiable.
L'architecture, oui.