Sommaire8
Un serveur installé il y a trois ans a vécu : un paquet ajouté un soir de panne, un réglage changé pour un client, un service lancé à la main et jamais documenté. Il tourne, et personne ne saurait le refaire à l’identique. Le jour où il disparaît, la reconstruction commence par une enquête. L’infrastructure as code part de l’autre bout : le serveur est décrit dans des fichiers, et c’est la description qu’on modifie, pas la machine. Elle fait partie des briques de notre guide du socle d’infrastructure cloud.
En bref
L’infrastructure as code décrit l’infrastructure dans des fichiers versionnés, relus et rejouables, au lieu de la configurer à la main.
Microsoft la présente comme la réponse à la dérive des environnements : des serveurs « flocons de neige », uniques et impossibles à reproduire.
Pour l’entreprise, elle sert d’abord la reprise après sinistre, la traçabilité des changements et la liberté de changer d’hébergeur.
Les outils se rangent par couche : les ressources (Terraform, OpenTofu, Pulumi), la configuration des machines (Ansible, cloud-init), les services (Docker Compose).
Elle reconstruit la machine, pas les données : les sauvegardes et le coffre-fort de secrets restent indispensables.
Ce que veut dire « infrastructure as code »
Définition
L’infrastructure as code
La pratique qui consiste à décrire serveurs, réseaux, droits d’accès et services dans des fichiers texte, rangés dans un dépôt comme du code, puis à laisser un outil appliquer cette description.
Microsoft résume le principe dans sa présentation de l’infrastructure as code :
De même qu’un même code source produit toujours le même binaire, un modèle d’infrastructure as code produit le même environnement à chaque déploiement.
Le même texte nomme le problème qu’elle résout : sans elle, chaque environnement devient avec le temps un « flocon de neige », une configuration unique qu’on ne sait plus reproduire automatiquement. Il insiste sur l’idempotence : une commande de déploiement amène toujours l’environnement au même état, quel que soit son point de départ. Et sur la méthode : pour changer quelque chose, l’équipe modifie la source, pas la cible.
Ce que ça change pour l’entreprise
Le bénéfice n’est pas technique. Il se lit dans quatre situations que toute entreprise finit par vivre.
- Le serveur perdu. Panne matérielle, erreur de manipulation, compte suspendu : avec une description à jour, la reconstruction suit une recette au lieu d’une mémoire. C’est la partie « relancer » du plan de reprise après sinistre.
- Le changement relu. Une modification de l’infrastructure passe par le même chemin qu’une modification de code : proposée, relue, appliquée, conservée dans l’historique. On sait qui a ouvert quel port, quand, et pourquoi.
- La copie de test. Le même fichier crée un environnement d’essai identique à la production, le temps de tester une mise à jour, puis le supprime.
- La porte de sortie. Une infrastructure décrite se déplace plus facilement chez un autre hébergeur : on sait exactement ce qu’il faut recréer. C’est un atout dans une migration cloud sans tout casser comme dans une réflexion sur la dépendance au cloud américain.
Le chemin d’un changement d’infrastructure
- La proposition
La modification est écrite dans le fichier.
- La relecture
Une autre personne la lit, et l’outil montre ce qui va changer.
- L’application
L’outil amène l’infrastructure à l’état décrit.
- L’historique
La modification reste datée, signée, réversible.
Les administrateurs systèmes ne disparaissent pas dans l’affaire : ce sont eux qui écrivent la description, la relisent et décident de ce qu’elle contient. Leur savoir cesse simplement de vivre dans une seule tête.
Les outils, couche par couche
Aucun outil ne fait tout. On les range selon ce qu’ils décrivent.
- Les ressources. Machines, réseaux, enregistrements DNS, comptes de stockage, chez un ou plusieurs fournisseurs. Terraform est l’outil le plus répandu ; OpenTofu en est un dérivé libre ; Pulumi décrit les mêmes ressources dans un langage de programmation. Chaque grand cloud a aussi son format, comme les modèles ARM et Bicep chez Microsoft Azure ou CloudFormation chez AWS.
- La configuration des machines. Paquets, utilisateurs, règles de pare-feu, fichiers de configuration : Ansible applique ces réglages à une ou plusieurs machines, cloud-init les pose au premier démarrage.
- Les services. Sur un serveur qui fait tourner des conteneurs, un fichier Docker Compose décrit chaque service, ses volumes de données, son réseau et sa politique de redémarrage.
La licence compte dans le choix, parce qu’elle a déjà changé une fois :
- 10 août 2023
HashiCorp annonce que ses produits, dont Terraform, passent de la licence MPL 2.0 à la Business Source License, qui interdit aux fournisseurs de services concurrents d’intégrer les versions suivantes.
- Après l’annonce
Des éditeurs créent OpenTofu, un dérivé de Terraform placé sous l’égide de la Linux Foundation, présenté comme son remplaçant direct.
Pour une entreprise qui utilise Terraform pour son propre compte, rien n’interdit de continuer. Le choix entre les deux se fait sur la gouvernance et les fournisseurs pris en charge, pas sur la peur d’un procès.
Ce que ça ne reconstruit pas
Attention
La machine, pas les données
L’infrastructure as code recrée un serveur vide et bien configuré. Les clients du CRM, les factures, les fichiers déposés par les utilisateurs viennent des sauvegardes, et seulement d’elles. Les mots de passe et les clés d’API, eux, n’ont rien à faire dans les fichiers de description : ils vivent dans un coffre-fort, que la description référence sans les contenir.
Reconstruire vite ne sert à rien si les données ne suivent pas. Notre guide des sauvegardes d’un serveur à soi détaille comment vérifier qu’une restauration fonctionne vraiment, et notre article sur Postgres géré ou auto-hébergé traite le cas de la base de données. Pour les secrets, voir le coffre-fort de secrets et les clés d’API volées.
Ce que nous avons appris
Sur le terrain
Le 5 juillet 2026, une commande de nettoyage mal ciblée a détruit d’un coup les conteneurs de dix services sur notre serveur. Les données, rangées dans des volumes, ont été sauvées ; nos règles d’exploitation sont désormais écrites. La leçon : ce qui est décrit et séparé des données se refait, ce qui ne vit que sur la machine se perd. Le site que vous lisez applique la même idée : sa configuration d’hébergement, ses redirections et ses en-têtes sont des fichiers de son dépôt, et l’envoi en ligne refuse de partir si une page vit sous une adresse redirigée.
Par où commencer, sans tout réécrire
Personne n’a besoin de décrire toute son infrastructure en une fois. L’ordre qui rapporte le plus vite :
- Inventorier.
Chaque serveur, chaque service, chaque enregistrement DNS, et où vivent leurs données.
- Décrire les services d’abord.
Un fichier par service, avec ses volumes de données séparés : c’est ce qu’on recrée le plus souvent.
- Puis la machine.
Paquets, utilisateurs, pare-feu, proxy inverse, dans un outil de configuration.
- Tester la reconstruction.
Sur une machine neuve, avec une sauvegarde réelle : le chronomètre dit si la recette tient.
- Faire passer chaque changement par la description.
Une modification faite à la main sur le serveur est une dette ; on la reporte dans les fichiers le jour même.
Le reste du chantier
L’infrastructure as code s’applique quel que soit le lieu d’hébergement (serveur dédié, VPS ou cloud) et n’impose pas Kubernetes (quand une PME n’en a pas besoin). Elle rend visibles les ressources qui coûtent (les postes qui gonflent une facture cloud), décrit le proxy placé devant les services (ce que Cloudflare protège) et se double d’une supervision qui prévient avant les clients. Elle s’applique aussi aux outils auto-hébergés (n8n en production, les outils à sortir du SaaS en premier, le coût d’une sortie du SaaS sur trois ans) et aux serveurs d’IA (le matériel qu’il faut). Les accès de l’équipe (un gestionnaire de mots de passe), la messagerie (Google, Microsoft ou hébergeur européen) et les obligations de résilience (NIS2 en France) complètent le socle.
Notre sortie du SaaS livre vos outils installés sur un serveur à vous, avec des sauvegardes hors serveur à la restauration testée et une documentation d’exploitation : 5 500 € et trois semaines.
Questions fréquentes
L’infrastructure as code est-elle utile pour un seul serveur ?
Oui, et c’est souvent là qu’elle rapporte le plus vite. Un serveur unique est un point de panne unique : s’il disparaît, tout ce qui tournait dessus doit être refait. Décrire ses services et sa configuration dans des fichiers transforme cette reconstruction en procédure connue, testable à l’avance sur une machine neuve. Le gain ne dépend pas du nombre de machines.
Terraform ou OpenTofu : lequel choisir ?
Les deux décrivent les mêmes ressources avec le même langage, OpenTofu étant né d’un dérivé de Terraform après le changement de licence de 2023. Une entreprise qui décrit sa propre infrastructure peut utiliser l’un ou l’autre. Le choix se fait sur la gouvernance du projet, les fournisseurs pris en charge et les habitudes de l’équipe ou du prestataire qui l’exploitera.
Faut-il tout décrire avant de commencer ?
Non. Commencez par les services, avec leurs données séparées, puis la configuration de la machine, puis les ressources chez le fournisseur. Chaque étape a sa valeur seule. L’important est de tester la reconstruction sur une machine neuve dès la première étape, et de faire passer ensuite chaque changement par les fichiers plutôt que par le serveur.
L’infrastructure as code remplace-t-elle les sauvegardes ?
Non. Elle recrée une machine configurée, mais vide. Les données de vos outils, comme les fiches clients, les factures ou les fichiers déposés, ne reviennent que par les sauvegardes, à condition qu’une restauration ait été testée. Les deux se complètent : la description refait le serveur, la sauvegarde remet son contenu, et le plan de reprise dit dans quel ordre.
Sources
- Microsoft Learn, qu’est-ce que l’infrastructure as code ? (nouvel onglet)learn.microsoft.com
- HashiCorp, annonce du 10 août 2023 (nouvel onglet)hashicorp.com
- OpenTofu, site du projet (nouvel onglet)opentofu.org
Microsoft Learn, qu’est-ce que l’infrastructure as code ?
Lire sur learn.microsoft.com(nouvel onglet)Jim · fondateur de Brain Plus AI
À lire aussi en infrastructure et cloud
Guide pratique8 min
Plan de reprise après sinistre : ce qu'il faut écrire
Le jour où un serveur, un centre de données ou un compte disparaît, il est trop tard pour décider de l'ordre des choses. Ce qu'un plan de reprise après sinistre doit contenir, les deux chiffres que la direction doit fixer, et comment savoir qu'il marche.
Guide pratique8 min
Sauvegarder un serveur à soi : ce qui casse vraiment
La règle 3-2-1, tout le monde la connaît, mais ce qui fait perdre des données est plus banal : une sauvegarde jamais restaurée, un volume oublié, une commande de nettoyage global lancée en production. Voici ce que nous avons appris en exploitant notre propre serveur.
Guide pratique14 min Le guide du sujet
Infrastructure cloud : le socle commun à tous vos projets
Avant le premier projet, un socle d'infrastructure cloud règle une fois pour toutes les comptes, les accès, les sauvegardes et le budget, et chaque projet suivant en hérite. Ce qu'il contient, où le poser, ce qu'il coûte et pourquoi son exploitation compte plus que son installation.