Les agents d’intelligence artificielle et les opérateurs Kubernetes ne devraient pas être considérés comme des équivalents interchangeables au sein de la boucle de contrôle. Un opérateur est conçu pour surveiller l’état réel, le comparer à l’état souhaité, puis appliquer des règles déterminées de manière reproductible afin de rapprocher le système du résultat déclaré. L’agent, quant à lui, est plus utile lorsque le résultat est connu, mais que le chemin pour y parvenir nécessite une investigation, une collecte d’informations et une mise en balance des compromis.
L’article, parrainé par la Cloud Native Computing Foundation (CNCF), indique que l’introduction d’agents dans l’infrastructure cloud native fait de la définition des limites de privilèges une question de conception, et non une simple convention. La formule la plus sûre consiste à laisser à l’agent la responsabilité du raisonnement, du contexte et des propositions, tandis que les opérateurs, les moteurs de politiques et les systèmes déterministes conservent le pouvoir d’exécution.
Une boucle opérationnelle qui sépare le raisonnement de l’exécution
Ce modèle propose une séquence pratique en six étapes : observation, diagnostic, proposition, approbation, mise en conformité, puis vérification. Lors des premières étapes, l’agent peut examiner les ressources, les journaux, les événements, les métriques et la documentation, mais il n’obtient pas automatiquement l’autorisation d’appliquer des changements, de modifier des ressources ou de les supprimer. Les opérations de lecture non sensibles peuvent être automatisées, tandis que les changements ayant un impact passent par une approbation explicite ou une passerelle de politiques.
Le projet kagent, un projet open source au sein de la CNCF Sandbox, en fournit un exemple. Il exécute des agents sous forme de ressources Kubernetes et les relie à Kubernetes, Helm, aux outils de supervision et à des outils personnalisés, ce qui permet d’enquêter sur les problèmes ou de coordonner des agents spécialisés sans supprimer les barrières entre l’analyse et l’exécution.
Pourquoi ne faut-il pas remplacer les opérateurs par un modèle de langage ?
Le cas de Karpenter illustre clairement la différence. Karpenter est un opérateur qui gère les contraintes de planification et met en correspondance les ressources NodePools et NodeClaims. Si des nœuds restent inutilisés, si les ressources Spot fluctuent ou si des pods sont en attente de planification, un agent opérationnel peut examiner la configuration de NodePool et d’EC2NodeClass, ainsi que les événements, les journaux, les Pod Disruption Budgets et les métriques Prometheus afin d’en rechercher la cause.
L’investigation peut révéler qu’une politique de désactivation de l’éviction empêche la consolidation, qu’un budget de perturbation entrave l’éviction ou que la valeur consolidateAfter entraîne des fluctuations évitables dans une charge variable. Toutefois, le résultat attendu n’est pas une recommandation générale telle que « optimisez le NodePool », mais un correctif de configuration précis qui explique les éléments probants et le compromis, indique le nombre de nœuds susceptibles d’être affectés et précise la durée de surveillance de la stabilité.
Après approbation, Karpenter exécute le changement selon sa logique existante de planification et de perturbation. L’agent surveille ensuite le résultat et vérifie que la consolidation s’est améliorée sans augmenter le temps d’attente des pods ni provoquer de perturbation nuisible. Si les critères d’acceptation ne sont pas remplis, il peut proposer une réversion par le même chemin.
Autre exemple : Argo CD et les mises à niveau de Helm
Lors d’une mise à niveau d’un chart Helm gérée par Argo CD, modifier la version dans Git est relativement simple, mais évaluer son impact sur l’application en cours d’exécution est plus difficile. L’agent peut comparer les notes de version, les valeurs actuelles et les données générées afin de détecter, par exemple, qu’un nouveau nom de valeur utilisé pour régler la readiness probe pourrait entraîner un retour silencieux à une valeur par défaut.
Ce résultat doit être transformé en demande de fusion ciblée qui met à jour la version et les valeurs concernées, explique le risque opérationnel et définit les contrôles préalables au déploiement. Après examen et fusion, Argo CD génère les données et les synchronise conformément à la politique de l’application. La réussite de la synchronisation ne suffit pas à prouver la sûreté de la mise à niveau ; il faut examiner les indicateurs de latence, les taux d’erreur et la disponibilité. Si les contrôles échouent, l’agent peut proposer d’annuler le changement ou de suivre un plan de reprise, en tenant compte du fait que les modifications des données ou du schéma peuvent ne pas être entièrement réversibles.
L’autonomie s’acquiert progressivement
L’article recommande de commencer par un agent limité à la lecture et à l’investigation, puis de l’autoriser à créer des correctifs ou des demandes de fusion, avant de lui permettre d’exécuter des changements à faible risque et de portée limitée, avec des conditions de réversion clairement définies. Une action ne devient autonome que lorsqu’elle est compréhensible et mesurable.
Lecture éditoriale : le véritable changement ne consiste pas ici à ajouter un agent capable d’appeler kubectl ou Helm, mais à redessiner la boucle de contrôle afin que le raisonnement probabiliste ne se transforme pas en pouvoir d’exécution illimité. La valeur pratique du modèle dépend de l’existence d’une délégation auditable, d’un périmètre limité, d’une surveillance et de la possibilité d’inverser les effets. La responsabilité humaine demeure dans la définition de la vitesse de passage de la proposition à l’autonomie ; de même, l’article ne démontre pas que cette approche élimine les risques d’erreur ou rende la réversion possible dans tous les cas.