Il ne suffit pas de fournir aux agents d’intelligence artificielle un modèle plus puissant pour qu’ils gèrent l’infrastructure cloud de manière autonome. Le problème mis en avant par un article sponsorisé par env zero est l’absence de contexte opérationnel reliant ce qui est censé exister, tel que le décrivent les outils d’infrastructure en tant que code (IaC), à ce qui fonctionne réellement dans le cloud.
Lorsqu’un agent travaille sur des fichiers IaC ou sur une source d’information unique, il peut voir une ressource isolée sans connaître sa relation avec l’application, la politique de gouvernance ou les exigences de sécurité et de coût. L’agent peut alors proposer une modification qui semble localement correcte, mais qui crée une non-conformité ou affecte d’autres composants qui n’apparaissent pas dans le contexte dont il dispose.
La taxe des interfaces de programmation d’applications
Les agents doivent interroger en permanence les interfaces de programmation des applications cloud afin d’explorer l’état actuel. Mais ce mode de fonctionnement impose ce que l’article appelle une « taxe API » : des limites de débit, l’échec de chaînes de requêtes, une hausse de la latence et des coûts, ainsi que le risque d’affecter des opérations sensibles telles que les pipelines CI/CD ou la mise à l’échelle automatique lorsque les outils se disputent la même capacité.
Le mode de fonctionnement d’un agent diffère de celui d’un utilisateur humain ; l’être humain tend à poser des questions précises, tandis qu’un agent peut explorer une longue série de requêtes. L’article cite Steve Corndell, directeur général de l’entreprise, qui donne l’exemple d’un agent ayant effectué 90 requêtes avant d’échouer à la 91e, ce qui l’a contraint à recommencer toute la série. Dans ce cas, le préjudice ne se limite pas à la requête ayant échoué : il est amplifié par la répétition du travail déjà accompli.
L’idée ne consiste pas à supprimer les requêtes en direct, mais à les répartir intelligemment. Il est possible de conserver des informations relativement stables, comme la propriété, dans un contexte synchronisé et mis à jour selon une fréquence appropriée, tout en limitant les requêtes directes aux questions nécessitant de connaître l’état actuel. L’objectif est de réduire les demandes répétées tout en maintenant l’exactitude des informations opérationnelles.
De l’intention déclarée à la réalité opérationnelle
L’article décrit une couche de contexte qui rassemble les données d’infrastructure déclarées et la découverte des ressources réelles, et les relie aux applications, aux politiques, à la propriété et aux frontières entre les environnements. Une couche d’ontologie ou un graphe de connaissances est censé contribuer à unifier des informations habituellement dispersées entre les fichiers d’état, les étiquettes, les feuilles de calcul, les modifications effectuées directement depuis les tableaux de bord et les connaissances non documentées.
Un cas hypothétique explique qu’un outil comme Wiz peut imposer une politique de haute disponibilité exigeant plusieurs instances, tandis qu’un agent reposant uniquement sur l’IaC ne voit qu’une seule instance et ne détecte donc pas la non-conformité. Relier ces données au contexte de l’application et de la politique permet à l’agent d’évaluer l’impact avant de proposer une remédiation.
Une boucle de contrôle complète
env zero propose un modèle qui commence par la capture de l’intention déclarée, puis la découverte de l’état réel, le rapprochement des deux états, le contrôle des politiques, la proposition de modifications sous forme de demandes de fusion destinées à la revue et à l’exécution, et enfin une nouvelle vérification visant à confirmer la disparition de la dérive ou du problème. La couche de données peut être reliée à des outils d’exécution tels que Terraform, OpenTofu et Pulumi.
L’entreprise présente EZ Control comme une boucle de contrôle autonome reliant l’état déclaré à l’état découvert, proposant ou exécutant la remédiation dans le respect des contrôles de politique, puis vérifiant la réussite de la modification. Le produit est en accès anticipé et l’entreprise vise une disponibilité générale d’ici la fin du mois de décembre 2026 ; certains éléments de la boucle décrite sont donc encore des fonctionnalités qu’env zero est en train de développer.
Pourquoi ce modèle est-il important ?
La valeur pratique de cette approche ne réside pas uniquement dans la découverte du problème, mais dans l’achèvement du processus jusqu’à la vérification de sa résolution. Un outil qui s’arrête à l’alerte laisse les étapes les plus difficiles aux ingénieurs, tandis que l’article mesure la réussite par le délai de remédiation, c’est-à-dire la durée entre l’identification d’un problème nécessitant une intervention et la confirmation que la modification l’a corrigé.
Cette vision reste toutefois liée aux affirmations de l’entreprise sponsor et à un produit encore à un stade précoce, et la source ne fournit pas de chiffres indépendants sur les performances chez les clients ni sur l’ampleur de la réduction des coûts et de la latence. De même, l’existence d’une couche de contexte n’élimine pas la nécessité de contrôles de revue et de politiques ; elle en fait au contraire un élément central de toute automatisation capable d’exécuter des modifications réelles dans un environnement cloud.