L'infrastructure en tant que code, du script maison au libre-service industrialisé
Bien que les origines de l'infrastructure en tant que code (IaC) puissent être retracées jusqu'aux outils de gestion de configuration très précoces, le concept a réellement pris la forme qu'il a aujourd'hui avec l'émergence du cloud. Les équipes d'ingénierie ont dû faire face à des défis d'échelle sans précédent. Au cours des deux dernières décennies, il a évolué rapidement, restant synchronisé avec les nouvelles approches technologiques et les besoins organisationnels.
Peu de professionnels sont mieux placés pour parler de ces évolutions que Kief Morris, expert Adservio. En 2016, il a littéralement écrit le livre de référence sur le sujet pour O'Reilly. Près d'une décennie plus tard, il publie une troisième édition de son ouvrage. Nous l'avons rencontré pour comprendre comment l'infrastructure a évolué ces dernières années et pour expliquer pourquoi une nouvelle édition était nécessaire en 2025.
Pourquoi une troisième édition changeait la donne
Des workflows pilotés par l'application
Michel S. : Pourquoi une troisième édition d'Infrastructure en tant que code ? Qu'est-ce qui manquait ? Qu'y avait-il à dire ?
Kief Morris : L'automatisation de l'infrastructure a considérablement évolué au cours des cinq années depuis la sortie de la deuxième édition. Il y a un besoin croissant de comprendre les résultats métier que l'infrastructure doit soutenir, plutôt que de concevoir à partir d'une perspective purement technologique. On observe un intérêt croissant pour les approches permettant d'offrir une mise à disposition libre-service de l'infrastructure aux équipes de développement, dans le cadre de stratégies d'ingénierie de plateforme. La troisième édition s'appuie sur les modèles de conception d'infrastructure décrits dans les deux premières éditions, en ajoutant des recommandations pour la création de composants d'infrastructure pouvant être construits, livrés, déployés et configurés dans le cadre de workflows pilotés par l'application.
Le poids croissant du déploiement automatisé
En lien avec la facilitation de la consommation de l'infrastructure par les équipes logicielles, on observe une croissance des techniques et outils de déploiement d'infrastructure au cours des dernières années. Cette édition comprend donc davantage de contenu sur les services de déploiement d'infrastructure automatisés et les workflows d'équipe, catalogues de composants réutilisables, portails internes de demande de ressources, et intégration plus fine entre le code applicatif et le code d'infrastructure qui le porte.
Le fossé persistant entre les outils du marché et les besoins réels
Le modèle hérité : spécialistes contre développeurs en silos
MS : Avez-vous été surpris par la façon dont l'espace de l'infrastructure en tant que code a évolué au cours des neuf années depuis la rédaction de votre premier ouvrage ?
KM : Je suis quelque peu déçu que la plupart des fournisseurs d'outils et de technologies n'aient pas dépassé les modèles mentaux hérités concernant la construction et la gestion de l'infrastructure. La majorité des outils et services destinés à aider les équipes d'infrastructure encouragent toujours des workflows où les spécialistes de l'infrastructure définissent et mettent à disposition manuellement l'infrastructure pour les développeurs en silos.
Les symptômes : transferts, environnements flocon de neige, goulots d'étranglement
Nous rencontrons toujours des transferts de responsabilité, des environnements « code flocon de neige » fortement personnalisés, et l'infrastructure qui devient un goulot d'étranglement pour la livraison. En pratique, cela se traduit par des tickets de demande qui s'accumulent, des environnements de préproduction qui divergent silencieusement de la production, et des équipes applicatives qui contournent le processus officiel avec des modifications manuelles dans la console cloud, recréant exactement le désordre que l'infrastructure en tant que code était censée éliminer.
Les compétences fondamentales ont-elles changé ?
MS : Comment les compétences requises pour relever les défis de l'infrastructure en tant que code ont-elles évolué ?
KM : Je ne suis pas certain que les compétences fondamentales aient beaucoup changé au cours des dernières années. Il y a plus de services et de technologies cloud à suivre. L'orchestration de conteneurs (« cloud native ») est au cœur de la plupart des plateformes de nos jours. Mais les principes fondamentaux restent valables.
Plus de services cloud à suivre, des principes qui tiennent bon
Ce qui change concrètement, c'est le volume : une équipe plateforme doit désormais arbitrer entre des dizaines de services managés, plusieurs fournisseurs cloud dans les organisations multi-cloud, et des couches d'abstraction supplémentaires comme les modules partagés ou les composants de plateforme interne. La compétence de conception, savoir découper un système en composants cohérents, versionnés et testables, reste néanmoins identique à celle qu'il fallait déjà maîtriser il y a dix ans.
L'orchestration de conteneurs au cœur des plateformes actuelles
L'essor des plateformes de développement internes (Internal Developer Platforms) construites au-dessus de l'orchestration de conteneurs a changé la manière dont les équipes consomment l'infrastructure, sans changer la nature du problème à résoudre : offrir des chemins balisés sûrs et reproductibles, plutôt que de la liberté totale sans filet.
Rester agnostique face à la prolifération des outils
MS : Est-il difficile de donner des conseils face à une telle diversité d'outils et de différentes approches possibles ? En tant qu'auteur et conseiller, à quel point est-il facile d'être agnostique vis-à-vis des outils ?
KM : Je concentre mon attention sur les principes, les pratiques et les modèles qui s'appliquent à travers les outils et les plateformes. Je constate que certaines personnes demandent des exemples de code, mais mon expérience montre que la fourniture d'exemples dissuade les lecteurs lorsque les exemples utilisent un langage ou un cloud différent du leur.
Principes transférables plutôt que recettes figées
Quand j'explique un concept qui bénéficie d'un exemple au niveau du code, j'utilise du pseudo-code pour le rendre accessible à la plus large gamme d'utilisateurs. Cependant, la majorité de mes exemples et illustrations se situent au niveau du design et peuvent être implémentés dans pratiquement n'importe quel outil.
Un problème très concret : la gestion des états et des configurations partagées
Cette recherche de principes transférables se heurte parfois à des détails d'implémentation qui varient énormément d'un outil à l'autre, la manière de gérer un état d'infrastructure partagé entre plusieurs équipes ou plusieurs environnements en est un bon exemple, avec des approches très différentes selon l'outil choisi et des pièges classiques qui reviennent d'une organisation à l'autre.
Les exigences de jour deux : le vrai défi de l'infrastructure moderne
MS : Vous avez parlé des exigences de jour deux lors d'une interview donnée à un podcast technique avec Ken Mugrage. Pouvez-vous expliquer ce que c'est et pourquoi c'est important maintenant ?
KM : La plupart des recommandations concernant l'infrastructure en tant que code se concentrent sur la conception et la construction d'une nouvelle infrastructure. Mais où la plupart des équipes rencontrent des difficultés, c'est dans la gestion et la maintenance de l'infrastructure à long terme. Comment s'assurer que, à mesure que vos systèmes croissent, chaque nouvel environnement n'est pas construit différemment des environnements plus anciens, afin d'éviter de créer un fouillis de différentes versions et configurations ? Comment mettre à jour les anciens environnements ? Comment apporter des modifications à l'infrastructure en production ?
Consolider, nettoyer, maîtriser les coûts
Cela est important car le problème que les équipes affrontent actuellement est moins lié à la migration vers le cloud pour la première fois. Les équipes ont besoin de consolider et de nettoyer les désordres chaotiques, de maîtriser les coûts, d'éviter d'accumuler de la dette technique dans leurs environnements et de suivre l'évolution des technologies. La détection de dérive entre l'état déclaré dans le code et l'état réel constaté sur le cloud, longtemps traitée comme un sujet secondaire, est devenue une brique aussi centrale que le provisionnement initial.
Faire évoluer l'infrastructure en production sans tout casser
Faire évoluer une infrastructure vivante suppose des garde-fous que la conception initiale néglige souvent : politiques as code pour bloquer les changements à risque avant qu'ils n'atteignent la production, boucles de réconciliation continue façon GitOps pour ramener automatiquement l'état réel vers l'état désiré, et pipelines capables de détecter puis corriger eux-mêmes certaines classes de dérive sans attendre une intervention humaine.
Vers une bonne infrastructure : ce que nous ne savons pas encore
MS : Vous avez également déclaré au Technology Podcast : « nous, les humains, ne savons pas encore ce que représente une bonne infrastructure ». Pensez-vous que nous le saurons un jour ?
KM : Bien sûr, nous le devons ! Je pense qu'avec de nombreuses nouvelles technologies, il faut plusieurs générations pour cesser de reproduire les approches que nous utilisions avec les anciennes technologies et découvrir comment tirer pleinement parti des opportunités que les nouvelles technologies offrent.
Plusieurs générations pour changer de logiciel mental
Ce constat se vérifie à chaque saut technologique : les premières générations de systèmes cloud ont d'abord reproduit les habitudes du datacenter physique, serveurs nommés individuellement, changements manuels documentés a posteriori, avant que l'infrastructure en tant que code n'impose une nouvelle discipline. La génération actuelle est en train de reproduire, avec les plateformes internes et l'orchestration de conteneurs, certains réflexes hérités de l'infrastructure en tant que code elle-même, avant de trouver son propre équilibre.
L'ingénierie de plateforme comme étape suivante
C'est précisément le rôle de l'ingénierie de plateforme que d'accélérer cette maturation : en transformant l'infrastructure en un produit interne consommé en libre-service plutôt qu'en un service sur ticket, elle force les organisations à expliciter ce qu'elles considèrent comme une « bonne » infrastructure, sécurisée par défaut, observable, facilement récupérable, au lieu de le découvrir au hasard des incidents.
Conclusion : ce qui ne change pas, ce qui change
Merci à Kief pour ce temps accordé. Ce qui ressort de cet échange, c'est une forme de stabilité rassurante au milieu d'un paysage d'outils en perpétuel mouvement : les principes de conception de l'infrastructure en tant que code n'ont guère changé depuis dix ans, mais leur mise en œuvre s'est déplacée du script individuel vers le produit de plateforme, et le centre de gravité du travail s'est déplacé de la construction initiale vers la maintenance de jour deux. Vous pouvez en savoir plus en écoutant Kief sur un podcast technique reconnu ou en explorant son ouvrage, vous trouverez un chapitre gratuit sur la page du livre sur ce site.
Avertissement : Les déclarations et opinions exprimées dans cet article sont celles de l'auteur(s) et ne reflètent pas nécessairement les positions d'Adservio.
RÉCUPÉRER CET ARTICLE
Téléchargez l'article complet en PDF pour le lire hors ligne ou le partager.
RESTER INFORMÉ
Recevez nos prochaines analyses et retours d'expérience directement dans votre boîte mail.
