Ce que révèle le malaise autour de l’IaC

Insatisfaction généralisée face aux implémentations de l’IaC

L’Infrastructure as Code, ou IaC, était censée changer la donne. Automatiser l’infrastructure, tout définir dans des fichiers lisibles par l’humain, traiter l’infrastructure comme du code applicatif, et laisser le DevOps en tirer parti. Telle était la promesse. Mais au vu des chiffres, nous sommes encore loin de la concrétiser.

Presque toutes les entreprises qui utilisent l’IaC signalent des problèmes. Une enquête menée en 2024 par Dimension Research, commandée par StackGen, montre que 97 % des répondants disent avoir rencontré de sérieux défis avec leurs déploiements IaC. Plus révélateur encore, 87 % affirment que leur organisation n’a pas atteint la maturité dans sa mise en œuvre. Il ne s’agit pas de petits faux pas. Ce sont les signes d’un décalage systémique entre la philosophie de l’IaC et son exécution dans les environnements métier du quotidien.

Pour les équipes de direction, voici l’essentiel : les outils sont peut-être modernes, mais les processus et les structures qui les entourent ne suivent pas. Si presque toutes les organisations rencontrent des difficultés, le problème ne vient pas des capacités des équipes, mais de la compatibilité structurelle. L’IaC a besoin de maturité dans la pratique, pas seulement dans la documentation. Elle a besoin d’adhésion à tous les niveaux, techniques comme managériaux. Sans cela, on se contente d’écrire des fichiers YAML en espérant que tout fonctionne.

Il ne s’agit pas d’abandonner l’IaC, loin de là. Il s’agit d’être lucide sur ses points de défaillance et de comprendre comment avancer plus vite, avec moins de blocages. Les équipes de la direction générale devraient pousser vers des frameworks qui comblent l’écart entre l’intention et l’exécution. Disposer d’automatisation ne signifie pas que vous avez rationalisé vos opérations, surtout lorsque cette automatisation ralentit les équipes à cause de défauts de conception et d’un manque d’alignement.

Flexibilité et agilité limitées dans des environnements cloud dynamiques

C’est là que les choses commencent à se compliquer. L’IaC fonctionne bien dans des environnements structurés. Elle donne de bons résultats lorsque les workflows sont prévisibles et évoluent peu. Mais les environnements cloud réels sont tout l’inverse : désordonnés, rapides, dynamiques. Et c’est précisément là que l’IaC traditionnelle commence à vous ralentir.

Les développeurs ont souvent besoin d’apporter rapidement des changements à l’infrastructure. Imaginons qu’un serveur ait besoin de plus de capacité immédiatement. Avec l’IaC, quelqu’un doit extraire un fichier Terraform du contrôle de source, effectuer les modifications, tester, commit, push, et ce n’est qu’ensuite que le changement sera pris en compte. Ce processus est trop lent pour des opérations soumises à une pression en temps réel.

Joey D’Antoni, Principal Cloud Architect chez DesignMind, a partagé un exemple typique. Un client devait redimensionner une ressource d’infrastructure en charge. On pourrait penser que c’est simple, mais non. Cela nécessitait des modifications manuelles dans le code d’infrastructure, en passant par la gestion du changement et le contrôle de version. Ce délai aurait pu être évité en se connectant simplement à la console du fournisseur cloud, mais cela va à l’encontre de la philosophie qui consiste à tout imposer via le code.

Arvind Rongala, PDG d’Edstellar, l’a bien résumé : l’IaC fonctionne très bien lorsque votre environnement est stable. Mais lorsque la vitesse compte, et c’est souvent le cas dans les environnements cloud, elle vous freine.

Imaginez maintenant cette friction multipliée à l’échelle de dizaines d’équipes, chacune gérant des actifs en évolution rapide. Cela crée un système lent dans un monde qui exige de l’accélération. Pour les dirigeants, le point est simple : ne considérez pas l’IaC comme une solution universelle. Elle est excellente dans des contextes stables, mais à elle seule, elle n’est pas conçue pour l’agilité en temps réel.

Si vos équipes sont contraintes de choisir entre vitesse opérationnelle et conformité des processus, quelque chose dysfonctionne, et ce n’est pas l’équipe. Corriger cela commence au niveau du système, pas de l’individu. Repensez le workflow pour soutenir la vélocité sans sacrifier la structure. C’est là que se trouve la prochaine évolution.

Les contournements sapent la cohérence et la sécurité

La vitesse, c’est bien, nécessaire même. Mais la vitesse sans structure crée du risque. C’est ce qui se produit lorsque les développeurs contournent les standards IaC pour aller plus vite. Ils récupèrent des templates sur des sites comme Stack Overflow ou s’appuient sur des outils d’IA non pris en charge pour déployer l’infrastructure. L’intention est d’avancer rapidement. Le résultat, ce sont des systèmes fragmentés avec une propriété floue, des templates incohérents et des failles de sécurité.

Asif Awan, cofondateur et CPO de StackGen, met bien ce problème en lumière : les développeurs veulent de la flexibilité, mais ils ne disposent pas toujours d’une connaissance approfondie de l’infrastructure. Cet écart conduit à des raccourcis, des scripts non pris en charge, des templates maison et du code de configuration généré par l’IA que personne ne comprend ni ne révise vraiment en profondeur. Avec le temps, cela crée une dérive entre ce qui figure dans la source de vérité et ce qui tourne réellement en production.

Du point de vue de la direction, ce n’est pas seulement un problème technique. C’est un risque opérationnel. Lorsque les équipes travaillent en dehors de standards partagés, vous ne faites plus évoluer une infrastructure unifiée. Vous faites évoluer le chaos. Les erreurs mineures de configuration s’accumulent, les audits deviennent pénibles et la réponse aux incidents ralentit.

La standardisation ne doit pas forcément signifier rigidité, mais elle doit être appliquée avec le bon équilibre entre contrôle et flexibilité. Cela signifie donner aux développeurs des outils qui permettent d’aller vite avec des garde-fous, et non les enfermer dans des workflows fragiles qu’ils se sentent obligés d’éviter. Si les équipes doivent contourner l’IaC pour rester productives, la stratégie qui sous-tend l’IaC doit être revue. La solution n’est pas de durcir davantage les règles, mais de construire quelque chose qui soutienne réellement la manière dont les équipes modernes travaillent.

Les défis interdomaines créent inefficacité et frustration

L’IaC part du principe que les personnes maîtrisent plusieurs domaines : développement, configuration réseau, politiques de sécurité. Cela fonctionne dans quelques entreprises, celles qui disposent de profils très spécialisés formés sur plusieurs verticales. Mais la plupart des organisations répartissent ces responsabilités entre plusieurs équipes. Mettre en place l’IaC sans tenir compte de cette répartition crée des frictions inutiles et pousse les personnes à intervenir sur des périmètres pour lesquels elles n’ont pas été recrutées.

Avec l’IaC, les développeurs configurent des pare-feu. Les équipes sécurité révisent du YAML. Les opérations déboguent du code qu’elles n’ont pas écrit. Cela entraîne des erreurs, des doublons et de la frustration. Selon l’enquête 2024 de Dimension Research, 75 % des professionnels de l’infrastructure sont frustrés lorsque d’autres équipes modifient les configurations. Les développeurs, de leur côté, déclarent consacrer plus de 20 % de leur temps à gérer l’infrastructure, un temps qu’ils préféreraient utiliser pour se concentrer sur le produit et les fonctionnalités.

Joey D’Antoni l’a dit clairement : demander à des non-développeurs d’adopter des pratiques complètes de développement logiciel, ou à des développeurs de gérer des questions d’infrastructure complexes, est excessif pour la plupart des entreprises. Il existe un écart entre les responsabilités et l’expertise. L’ignorer conduit à l’inefficacité et à l’épuisement.

Les dirigeants devraient prendre cela au sérieux. L’IaC était censée rapprocher les équipes, pas brouiller les frontières au point de créer de la confusion. Quand trop d’équipes partagent la responsabilité sans périmètre défini, plus personne n’est réellement responsable. C’est là que les erreurs s’infiltrent et que l’élan s’essouffle.

La solution n’est pas une clarté artificielle, mais la conception de systèmes IaC pensés en fonction des rôles et des capacités. Laissez les développeurs intervenir au niveau de la couche applicative. Laissez les équipes ops et sécurité construire la structure sous-jacente avec les outils et la supervision appropriés. Considérez l’accès transverse comme une capacité, pas comme une exigence par défaut. Donnez aux personnes les moyens d’agir là où elles sont les plus fortes, et le système sera globalement plus performant.

Les dépendances externes et l’instabilité des fournisseurs compliquent l’IaC

L’efficacité de l’IaC dépend d’outils fiables capables de suivre l’évolution des plateformes cloud. Le problème, c’est que beaucoup des outils tiers dont dépendent les entreprises, en particulier les principaux, deviennent plus difficiles à considérer comme fiables. Les changements de licence, les désaccords philosophiques et les opérations de fusion-acquisition créent des frictions au sein des équipes d’ingénierie comme parmi les dirigeants. L’adoption d’un outil qui semblait stable il y a un an peut désormais comporter des risques.

Prenons Terraform, par exemple. Pendant des années, c’était l’outil dominant dans l’univers de l’IaC. Au départ open source, largement adopté et bien documenté. Mais après le changement de modèle de licence opéré par HashiCorp, la confiance de la communauté a été ébranlée. Ce changement, combiné à sa fusion en cours avec IBM, a introduit une incertitude stratégique pour les équipes fortement investies dans cet écosystème. Les entreprises ont raison d’être prudentes face à des stratégies fournisseurs qui déplacent les objectifs en cours de route.

En réponse, de nombreuses organisations diversifient leurs approches. Selon le rapport 2024 de Dimension Research, 54 % des entreprises interrogées utilisent désormais plusieurs outils IaC. C’est une démarche défensive : plus d’outils, plus d’options, plus de résilience. Mais c’est aussi plus de complexité, ce qui signifie davantage de choses à gérer et un risque accru d’échec d’intégration.

Pour les équipes de direction, l’enseignement est le suivant : même lorsque votre philosophie IaC est bien définie, les outils qui la sous-tendent peuvent manquer de stabilité. L’enfermement fournisseur, les roadmaps imprévisibles et les modèles open source fragmentés placent la stabilité de votre infrastructure hors de votre contrôle. Les dirigeants ont besoin d’agilité à long terme, pas seulement d’une bonne connaissance des outils. Cela peut aussi signifier privilégier des outils agnostiques vis-à-vis des plateformes, des stratégies de migration claires et des contrats qui favorisent la prévisibilité plutôt que l’effet de mode.

La stabilité ne se résume pas à la disponibilité, elle concerne aussi la continuité sur plusieurs années de croissance et de changement. Cela exige de bâtir une stratégie autour de la gestion des fournisseurs, et pas seulement de s’appuyer sur l’enthousiasme pour l’open source ou sur la notoriété d’une marque.

L’IA générative améliore les workflows mais ne résout pas les problèmes fondamentaux de l’IaC

L’IA commence à combler certaines lacunes de l’IaC, mais elle ne remplace pas le besoin d’une véritable expertise en infrastructure. Des outils comme GitHub Copilot et des assistants personnalisés basés sur l’IA peuvent générer des fichiers Terraform, signaler des erreurs de configuration et même suggérer des paramètres sécurisés par défaut. Ils font gagner du temps et rendent l’IaC plus accessible, en particulier pour les équipes qui n’ont pas une grande expérience. C’est important. Les solutions de productivité qui réduisent les barrières méritent leur place dans la stack.

Arvind Rongala, PDG d’Edstellar, a expliqué comment les équipes intègrent l’IA dans leurs plateformes, non seulement comme assistants de codage, mais aussi comme outils d’application des politiques. À partir de déploiements réussis antérieurs, des interfaces enrichies par l’IA peuvent identifier des risques comme des autorisations mal configurées ou des ressources en conflit avant le déploiement. C’est précieux, et cela aide à garantir la conformité sans revue manuelle permanente.

Cela dit, les outils d’IA ne suppriment pas la nécessité de prendre de bonnes décisions d’ingénierie. Asif Awan, cofondateur et CPO de StackGen, a souligné que l’IA générative ne peut pas évaluer si le code qu’elle génère est contextuellement valide. Si un développeur ne comprend pas en profondeur le domaine de l’infrastructure, en particulier le réseau, la sécurité ou l’orchestration cloud, il ne détectera pas les défauts subtils dans ce que l’IA produit. Le résultat ? Davantage de cycles de revue, une dépendance accrue envers les opérations, et un ticket de plus dans le backlog de quelqu’un.

D’Antoni a ajouté une autre mise en garde : même une automatisation réussie a besoin de garde-fous. Déléguer la logique d’infrastructure à l’IA ne dispense pas les équipes de tester, réviser et vérifier. Ce travail doit toujours être fait, simplement par moins de personnes, avec peut-être un risque plus élevé de centralisation des connaissances clés.

Pour les dirigeants, l’opportunité est claire. Utilisez l’IA pour accroître la vitesse et la scalabilité, mais ne confondez pas vitesse et sécurité. Le principal gain ne réside pas dans le remplacement des équipes, mais dans le fait de rendre l’infrastructure plus exploitable entre les fonctions, sans créer de nouveaux points de défaillance. L’IA soutient la livraison lorsqu’elle est associée à la bonne structure de responsabilité. Sans cela, elle ne fait qu’accélérer des erreurs potentielles.

Les approches émergentes visent à compléter ou remplacer l’IaC traditionnelle

De nouvelles idées arrivent dans l’espace de la gestion de l’infrastructure, et c’est une bonne chose. Les frictions et les inefficacités mises en évidence par les implémentations actuelles de l’IaC stimulent le développement de solutions plus intelligentes et plus adaptables. Il ne s’agit pas de simples améliorations marginales. Elles repensent la manière dont l’infrastructure est exprimée, gérée et transmise entre les équipes sans obliger tout le monde à devenir expert en configuration.

System Initiative, dirigée par le cofondateur Adam Jacob, ancien CTO de Chef, propose une approche d’abord visuelle qui supprime par défaut la nécessité d’écrire du code d’infrastructure. Les équipes voient ce qu’elles construisent et apportent directement des modifications via une UI conçue pour la collaboration. C’est rapide, transparent, et cela élimine une complexité inutile sans supprimer le contrôle. L’objectif n’est pas d’éliminer l’IaC, mais de la rendre utilisable à grande échelle par les personnes qui en ont besoin, qu’elles écrivent ou non du code d’infrastructure au quotidien.

StackGen, cofondée par Asif Awan, emprunte une autre voie. Ils appellent cela « Infrastructure from Code ». L’outil analyse le code applicatif et génère automatiquement les configurations d’infrastructure requises. Cela signifie que les équipes DevOps reçoivent des artefacts IaC prêts à l’emploi qu’elles peuvent gérer, tandis que les développeurs bénéficient de configurations d’infrastructure alignées sans avoir besoin de devenir des experts Terraform. C’est de l’automatisation qui respecte les frontières entre domaines, quelque chose que l’IaC traditionnelle n’a pas su résoudre proprement.

Pulumi, un fournisseur IaC établi, intègre directement l’IA générative dans sa plateforme. Les résultats ont été mitigés jusqu’à présent, mais l’intention est claire : simplifier la création et la gestion de l’infrastructure grâce à des outils alimentés par le machine learning et des prompts en langage naturel. À mesure que ces approches gagnent en maturité, nous verrons davantage de convergence entre Dev, Ops et Platform Engineering, sans imposer des workflows artificiels ni une compression forcée des compétences.

Pour les dirigeants seniors, ce n’est pas le moment de s’accrocher au statu quo. Regardez où votre processus actuel crée des frictions. Si les ingénieurs perdent du temps simplement à gérer des templates ou restent bloqués à attendre que le DevOps provisionne des environnements, votre architecture d’infrastructure ne soutient pas la vélocité de votre entreprise. Les outils évoluent, votre stratégie doit évoluer aussi.

L’IaC peut être excessive pour des déploiements à petite échelle

Toutes les organisations n’ont pas besoin de déployer une Infrastructure as Code à grande échelle, en particulier celles qui ont une empreinte cloud limitée. Si votre entreprise gère 20 à 30 ressources d’infrastructure, des processus de templating lourds peuvent davantage ralentir qu’aider. Imposer l’IaC à de petites opérations conduit souvent à de la complexité sans les bénéfices en scalabilité ou en auditabilité qui la justifieraient.

Joey D’Antoni l’a formulé clairement : l’IaC présente de réels avantages, mais pour des déploiements légers, elle peut constituer une surcharge inutile. Dans ces contextes, les équipes constatent souvent qu’il est plus rapide et plus efficace de gérer simplement les ressources cloud via l’interface graphique intégrée du fournisseur. Cette méthode n’offre ni contrôle de version ni automatisation, mais pour certains cas d’usage, ce ne sont pas des obstacles rédhibitoires.

Ce qui importe pour les dirigeants, c’est de s’assurer que la stratégie d’infrastructure est alignée sur l’échelle, le stade de développement et les ressources humaines disponibles. Les petites équipes avec une capacité DevOps limitée ne peuvent pas se permettre de perdre des heures à écrire, tester et déboguer du code d’infrastructure à moins qu’il y ait un retour qui le justifie. Le provisionnement par clic n’est pas un manque de discipline, c’est une décision de rester agile lorsque c’est ce dont l’entreprise a besoin.

L’essentiel est d’évaluer si la couche infrastructure favorise la vélocité, ou si elle ne fait qu’ajouter une structure dont personne ne tire profit. À mesure que l’entreprise grandit, la flexibilité reste essentielle. Les décisions d’infrastructure que vous prenez au départ ne doivent pas vous enfermer dans la complexité, mais vous donner des options pour monter en charge lorsque cela a un sens stratégique. À partir d’un certain point, l’IaC devient essentielle. Mais ce point n’est pas le même pour tout le monde.

En conclusion

L’IaC n’est pas défaillante, mais la manière dont la plupart des organisations l’utilisent est désalignée par rapport à la réalité. Les idées fondamentales restent pertinentes : automatiser les tâches d’infrastructure répétables, rapprocher l’infrastructure du code, et aligner dev et ops. Ce qui manque, c’est un système conçu autour de la manière dont les équipes travaillent réellement aujourd’hui.

La plupart des échecs liés à l’IaC ne viennent ni de mauvais outils ni de mauvaises intentions. Ils proviennent de la mise à l’échelle de processus rigides dans des environnements dynamiques, de l’attribution de responsabilités à des profils aux compétences mal assorties, et de l’imposition de workflows qui ralentissent davantage qu’ils ne rationalisent. Le résultat, c’est de la frustration, de l’inefficacité et des contournements réactifs qui introduisent du risque.

C’est un problème de direction, pas seulement un problème technique. Si vos équipes contournent vos systèmes pour rester productives, il est temps de repenser le système. Des outils intelligents aident, mais ils ne remplaceront jamais la valeur qui consiste à donner aux bonnes personnes le bon niveau de responsabilité, soutenu par des processus qui s’adaptent à mesure que l’organisation grandit.

Les dirigeants doivent se concentrer sur l’adéquation. Où l’IaC aide-t-elle ? Où crée-t-elle des frictions ? De quoi l’équipe a-t-elle besoin pour aller plus vite sans compromettre la sécurité ? La suite consiste moins à renforcer encore les templates et la conformité qu’à favoriser la vélocité, la spécialisation et la visibilité sur l’ensemble de la stack.

Si vous voulez un véritable impact de l’automatisation de l’infrastructure, tout commence par une conception pensée pour la manière dont les personnes travaillent, et non pour la manière dont les outils ont été conçus à l’origine.