🧑‍💻 L’infra-as-code reste un sujet mal compris dans les entreprises et, lorsqu’elle est présente, souvent mal utilisée.

😒 Pour beaucoup, c’est un Terraform sur le poste du technicien chargé des infrastructures IT de l’entreprise qui fait un peu ce qu’il veut, même si son code est suivi dans un dépôt de code, comme Gitlab par exemple.

🧱 Pourtant l’infra-as-code peut être beaucoup plus sécurisée et participative, avec un modèle simple et efficace.

🧠 La personne qui souhaite introduire des changements sur l’infrastructure va étudier depuis son poste de travail les différences entre l’infrastructure actuelle et celles qu’il souhaite introduire, sans changer quoi que ce soit, en simulant l’exécution de modifications. Il s’agit bien sûr en premier lieu de travailler sur un environnement de préproduction.

😮 Lorsqu’il a vaincu les différents retours en erreur, il va pouvoir tester une réelle exécution de son code en ajoutant le code des modifications en question à Gitlab.

🫂 À ce moment, une procédure de revue par un pair est possible, en soumettant l’ajout des modifications à leur validation par un ingénieur senior. Cela est très intéressant pour l’entreprise, qui peut profiter de cette fonctionnalité pour faire monter en compétence sur l’infra-as-code des profils junior en toute sécurité.

🤖 L’exécution réelle sur l’environnement visé sera gérée par Gitlab, à travers un pipeline dédié et un runner doté des autorisations nécessaires à la modification de l’infrastucture cible. L’exécution est automatisée et le retour de l’exécution est consultable, afin de comprendre les éventuelles retours d’erreurs.

📝 Pour ceux qui connaissent déjà l’infra-as-code, ils savent que beaucoup d’erreurs n’apparaissent qu’à l’application de Terraform. La personne chargée des modifications devra sûrement reprendre plusieurs fois son code en suivant ce cycle. Spoiler : il y en aura beaucoup.

🔎 Une fois les modifications appliquées sur l’environnement cible, une période de tests va viser à contrôler si les modifications introduites ont bien eu les effets attendus, au-delà des retours de l’exécution. Deux précautions valent mieux qu’une.

🚛 Une fois cette partie validée, l’on pourra sereinement envisager de reproduire l’opération, mais cette fois-ci sur l’environnement de production. Le code que l’on introduira sera ainsi solide et les risques de comportements inattendus auront été réduits autant que possible.

❓ Et vous ? Comment gérez-vous votre infra-as-code ? Mode guerrier ou une organisation d’infra-as-code cloisonnée comme celle décrite ici ? N’hésitez pas à m’en dire plus en commentaire.

L’auteur

🧑‍💻 Je suis architecte infrastructure cloud (AWS et Azure) senior freelance, adepte du télétravail et du travail en profondeur, et conçois les infrastructures dont vous avez besoin pour faire tourner les services IT de vos entreprises. Disponible pour une nouvelle mission dès mi-janvier 2026. N’hésitez pas à me contacter si je peux vous aider dans vos projets.