Infrastructure as code : les Ops se méfient encore des agents IA

Chez TD Bank, « ce n’est pas la saison » des agents IaC

Lors d’une session du Red Hat Summit le 13 mai 2026, des représentants de TD Bank ont présenté une analyse approfondie d’un ambitieux projet d’automatisation du réseau propulsé par la plateforme d’automatisation Ansible. Ce projet, lancé l’année dernière, repose sur 12 850 lignes de code visant à reconfigurer le réseau, sans interruption, en 90 minutes dans chacune des 1 300 agences de la banque au Canada. Selon cette présentation, la mise en place du projet a nécessité environ 3 mois et demi de travail pour trois ingénieurs et a permis d’économiser 1 360 heures de travail.

Au cours du projet, les ingénieurs de TD Bank ont utilisé Copilot pour les aider dans des tâches IaC répétitives telles que la génération de tests. Ils l’ont seulement fait après s’être assurés que les agents ont pour référence un code écrit de la main de l’homme et respectueux de normes strictes. C’est en tout cas ce qu’affirme Jade Wu, co-présentatrice de la session et ingénieure réseau senior chez TD Bank.

« Nous avons consacré beaucoup de temps à mettre en place ce cadre et à veiller à toujours respecter le même style de programmation, ce qui nous a été extrêmement utile lorsque Copilot est arrivé », affirme-t-elle. « Nous pouvons former l’agent à rédiger des tests qui respectent en tout point nos exigences ».

Copilot s’est révélé utile pour ce type de tâches répétitives et à faible risque. Toutefois, ce sont toujours les ingénieurs humains qui contrôlent le cœur du système et la logique du code, a-t-elle précisé lors d’une interview après la session. Copilot a été intégré relativement tard dans le projet, et elle a estimé qu’il représentait environ 15 % du travail global, toujours sous étroite supervision humaine.

Lorsqu’on lui a demandé quel degré d’autonomie la banque accorderait à l’avenir aux agents IaC, le co-présentateur Drew Yates, vice-président de l’infrastructure, du réseau et du centre de données chez TD Bank, a répondu que celle-ci serait à court terme limitée.

« Ce n’est pas la saison », lance-t-il. « Je ne vais pas lui faire exécuter des playbooks d’exécution. […] Disposer d’un agent IA pour aider à déterminer la voie à suivre associée aux mécanismes d’automatisation existants a beaucoup de sens. Et ce sera probablement l’une des premières mesures que nous envisagerons de prendre plutôt que d’utiliser les agents IA de manière systématique ».

EY intègre IBM Bob, avec des garde-fous

Les environnements de développement de la plateforme fiscale mondiale d’EY intègrent désormais l’IDE agentique IBM Bob et son ensemble d’outils. Ils servent à la modernisation du code .NET, le développement d’applications et l’infrastructure as code. IBM Bob est couplé avec HashiCorp Terraform et d’autres librairies, selon Christopher Aiken, directeur des services technologiques fiscaux chez EY. Cette plateforme s’adresse aux clients de la société de conseil en matière de fiscalité des entreprises ainsi qu’à ses propres experts internes.

EY a également co-développé en 2025 un assistant nommé EY.ai. Celui-ci s’appuie sur les modèles IBM Watsonx et Granite AI. EY.ai est utilisé par le service fiscal interne d’IBM. IBM Bob a séduit Christopher Aiken en raison de sa mémoire intégrée et de ses fonctionnalités de routage de modèles, qui lui ont valu une certaine autonomie en interne.

« Au début, j’étais un peu réticent à l’idée de ne pas garder un contrôle total sur les modèles utilisés par Bob », a-t-il déclaré lors d’une table ronde de la conférence IBM Think à Boston, le 5 mai. « Nous avons en fait découvert qu’il fallait laisser Bob prendre les commandes. »

En ce qui concerne le déploiement de logiciels en production, y compris l’IaC, Bob n’a toutefois pas encore les rênes, a-t-il précisé lors d’une interview accordée à l’issue de la table ronde.

« Nous accordons à Bob un niveau raisonnable d’autonomie pour apporter des modifications au code », poursuit-il. « Mais bien sûr, tout ce code passe par notre processus de révision de pull requests. Nous ne mettons donc en production aucun code produit par Bob qui n’ait pas été soumis à une révision humaine ».

Le code IaC généré par l’IA est soumis à plusieurs types de contrôles avant son déploiement. Il est régulé à l’aide de garde-fous au sein des plateformes des fournisseurs de cloud tels qu’AWS afin d’éviter les dépassements de coûts d’infrastructure et d’autres problèmes de qualité.

« Nous définissons ces garde-fous chez nos fournisseurs de cloud sous-jacents », souligne Christopher Aiken. « Nous pouvons demander à Bob de respecter ces limites. Mais bien sûr, vos instructions ont leurs limites ».

« Ça ne fonctionnera pas. Et ça ne vous le dira pas ».

Un article de blog publié le 15 avril par un ingénieur DevOps travaillant pour une entreprise de dispositifs médicaux a examiné en détail ce qui est exactement attendu de l’humain dans la boucle IaC générée par l’IA. Cela va au-delà des tests automatisés et de la révision de code habituels.

Si les gains de productivité liés à l’utilisation d’un agent Claude Code pour rédiger du code OpenTofu pendant trois mois étaient réels, les raisons d’être prudent l’étaient tout autant, selon l’article.

« [La détection d’un bug dans le code AWS] nous a probablement évité un incident de production pénible et un constat de non-conformité. Nous livrons les modules plus rapidement. Je ne reviendrai pas en arrière », écrit Heinan Cabouly, chef d’équipe DevOps et architecte chez ce fabricant de dispositifs médicaux basée en Israël et aux États-Unis. Il a demandé que le nom ne soit pas divulgué en raison de politiques lui interdisant de la représenter dans la presse.

Selon Heinan Cabouly, les agents se sont montrés efficaces pour détecter les bugs, générer des structures de modules OpenTofu telles que des définitions de variables et des blocs de sortie, ainsi que de rédiger des règles de validation. Cependant, ils ont également créé à plusieurs reprises des variables d’infrastructure qui n’existaient pas. Problème, ces variables auraient passé avec succès les tests de validation standard. Les agents IA se sont également révélés peu aptes à faire la distinction entre le code applicatif et le code de configuration de l’infrastructure.

Heinan Cabouly admet que le fait d’opérer dans un environnement hautement réglementé rend cela particulièrement délicat. Des entreprises d’autres secteurs auraient peut-être pris cela avec plus de philosophie. Néanmoins, à l’avenir, chaque ingénieur de l’équipe de M. Cabouly devra « expliquer le comportement de chaque argument de ressource au regard du fonctionnement réel des services AWS. La réponse ne pourra pas être “c’est l’IA qui l’a dit” », selon l’article.

« La question n’est pas de savoir si l’IA remplacera les ingénieurs DevOps. Il s’agit de savoir si vous comprenez suffisamment bien vos systèmes pour savoir quand elle se trompe », conclut l’article. « Elle se trompera. Ça ne fonctionnera pas. Et elle ne vous le dira pas ».

Un ingénieur de plateforme évalue l’IA pour la refonte de l’IDP

Vega, une autre entreprise évoluant dans un secteur réglementé, avance prudemment, mais sûrement dans l’utilisation d’agents IA pour l’IaC.

Depuis l’année dernière, Vega essaye « Intent » de Spacelift. Cette preuve de concept vise à aider les utilisateurs de sa plateforme de développement interne (IDP) à tester le code OpenTofu dans un environnement AWS Playground avant de le déployer en production.

« C’est vraiment très puissant, et nous n’exploitons pas pleinement le potentiel du produit. C’est là que j’aimerais essayer de trouver un moyen sûr de le faire à l’avenir », a témoigné Joe Hutchinson, de Vega, lors d’un entretien avec Informa TechTarget le 29 avril. « Intent peut vous aider à conceptualiser et itérer [les configurations IaC] dans votre premier environnement. Une fois que vous êtes satisfait du résultat, vous pouvez le transposer dans l’environnement suivant. Et il déploiera les ressources de manière déterministe. »

À long terme, Joe Hutchinson espère que des outils basés sur des agents IA, tels que Spacelift Intent, formeront un nouveau type d’interface permettant aux développeurs d’interagir avec l’IDP de l’entreprise. Il souhaiterait ainsi remplacer les portails de développeurs statiques sur mesure créés à l’aide d’outils tels que Backstage.

« Backstage sert de passerelle vers tout : vos déploiements, votre catalogue de logiciels, votre radar technologique, votre documentation technique, le tout intégré », rappelle Joe Hutchinson. « Mais les projets Backstage, même dans les petites entreprises, peuvent représenter des coûts de développement à six chiffres, voire plus. […] Je ne pense pas que ce soit la voie que prend le monde ».

Les agents IA : nouvelle expérience développeur pour l’IaC ?

Les agents IA, en tant que nouvelle forme d’interface de haut niveau permettant une automatisation plus poussée et déterministe de l’infrastructure, constituent l’approche adoptée par Red Hat avec Ansible Automation Platform (AAP).

La version 2.7 d’AAP introduit en premier lieu un serveur Model Context Protocol et un plugin d’extension de code. Ces capacités permettent de connecter la plateforme aux IDE agentiques préférés des ingénieurs.

Lors d’un keynote, l’éditeur a toutefois dévoilé Automation Orchestrator, une interface qui relie l’automatisation basée sur les tâches, les événements et l’IA. Elle illustre la manière dont Red Hat envisage l’intégration des agents IA dans la gestion des infrastructures à long terme.

« L’orchestrateur d’automatisation vous offrira un plan de contrôle visuel unique pour concevoir, gouverner et exécuter des workflows à travers les trois modes d’automatisation », a assuré Ashesh Badani, directeur des produits chez Red Hat, le 13 mai. « Le tout avec des portails de validation et des pistes d’audit cohérentes, quel que soit le déclencheur du flux de travail ». Ces trois modes d’automatisation correspondent à « des actions individuelles approuvées par l’homme, des workflows supervisés par des agents IA, et enfin, pour les systèmes appropriés ayant fait leurs preuves, des opérations entièrement autonomes ».

Si les agents IA ne remplacent peut-être pas les flux de travail déterministes pour l’IaC, ils sont susceptibles d’y ajouter une nouvelle couche d’abstraction, anticipe Rob Strechay, analyste chez TheCube Research et Smuget Consulting.

« Je reconnais à Red Hat le mérite d’avoir axé son approche sur les tâches […]. Il cherche à orchestrer les playbooks plutôt que de se contenter d’encapsuler des API, et en intégrant également une automatisation pilotée par les événements », affirme-t-il. « À terme, Ansible ne sera-t-il donc pas, en quelque sorte, simplement un moteur de playbooks, déclenché par d’autres agents [et] chargé de gérer les tâches en arrière-plan ? », s’interroge-t-il. « Je pense que c’est la direction que la plupart des gens vont prendre ».