Infrastructure as Code : pourquoi versionner son infrastructure change tout

Le serveur que personne ne sait reconstruire

Dans beaucoup d'organisations, il existe un serveur — parfois plusieurs — que tout le monde évite de toucher. Il a été configuré à la main, il y a des années, par quelqu'un qui n'est peut-être plus dans l'équipe. Personne ne sait exactement ce qu'il contient, ni comment le reconstruire à l'identique en cas de panne. C'est le symptôme d'une infrastructure administrée « à la main » : chaque clic dans une console, chaque commande tapée en SSH ajoute une modification qui n'est nulle part documentée ni tracée.

L'Infrastructure as Code (IaC) part d'un principe simple : décrire l'infrastructure — serveurs, réseaux, bases de données, permissions — dans des fichiers texte, et laisser un outil se charger de la créer ou de la modifier à partir de cette description. L'infrastructure devient alors un artefact versionné, relu et testé, comme n'importe quel code applicatif.

Ce que l'administration manuelle coûte réellement

Le problème central de l'administration manuelle porte un nom : la dérive de configuration (« configuration drift »). Deux serveurs censés être identiques finissent, au fil des interventions ponctuelles, par diverger légèrement — une variable d'environnement oubliée, un correctif appliqué sur l'un mais pas l'autre, une règle de pare-feu ajoutée en urgence puis jamais documentée. Cette dérive reste invisible jusqu'au jour où elle cause un incident difficile à diagnostiquer, ou empêche de reproduire un bug qui n'apparaît que sur un environnement précis.

Elle a aussi un coût direct en reprise après sinistre : reconstruire une infrastructure détruite ou compromise à partir de la mémoire d'une équipe et de captures d'écran prend des heures, voire des jours. Avec l'IaC, reconstruire un environnement identique consiste à rejouer la définition versionnée — une opération qui se compte en minutes, et qui ne dépend de la disponibilité de personne en particulier.

La revue de code s'applique aussi à l'infrastructure

Le changement le plus structurant qu'apporte l'IaC n'est pas seulement technique, il est organisationnel : une modification d'infrastructure devient une pull request, relue avant d'être appliquée — exactement comme une modification de code applicatif. Ouvrir un port, élargir une permission d'accès, ou changer la taille d'une base de données passe désormais par un diff explicite, visible par toute l'équipe, avant d'atterrir en production.

Cette revue de code de l'infrastructure change directement la posture de sécurité. Une règle de pare-feu trop permissive, un accès administrateur accordé sans expiration, un stockage exposé publiquement par erreur : ce sont des erreurs de configuration qui, dans un contexte d'administration manuelle, ne sont détectées qu'après coup — souvent lors d'un audit ou, pire, d'un incident. Décrites dans un fichier relu avant application, elles sont repérables avant même d'atteindre l'environnement réel. Des outils d'analyse statique (tfsec, Checkov, Terrascan) peuvent en plus scanner automatiquement ces définitions à chaque pull request, avant toute revue humaine.

Les outils : Terraform, OpenTofu, Ansible

Deux familles d'outils coexistent, avec des rôles complémentaires plutôt que concurrents :

• Les outils déclaratifs de provisionnement (Terraform, ou sa version communautaire OpenTofu née après le changement de licence de Terraform en 2023) décrivent l'état cible de l'infrastructure — combien de serveurs, quelle taille, quel réseau — sans détailler les étapes pour y arriver. L'outil calcule lui-même le plan d'action nécessaire pour passer de l'état actuel à l'état déclaré.
• Les outils de configuration (Ansible, Puppet, Chef) interviennent en complément, une fois les ressources créées, pour installer des paquets, déployer des fichiers de configuration ou démarrer des services sur des machines existantes.

Dans une chaîne IaC typique, Terraform ou OpenTofu créent les ressources cloud (serveurs, réseaux, bases managées), puis Ansible configure ce qui tourne à l'intérieur. Les deux approches se combinent plus souvent qu'elles ne s'excluent.

Provider par provider : ce qui change concrètement

Terraform et OpenTofu ne parlent pas directement à un hébergeur : ils passent par un provider, un plugin qui traduit la description déclarative en appels à l'API du fournisseur choisi — il existe un provider AWS, un provider Scaleway, un provider Azure, et ainsi de suite. La syntaxe du langage (HCL) est identique d'un provider à l'autre, mais le vocabulaire des ressources ne l'est pas : une instance de calcul s'écrit aws_instance chez AWS et scaleway_instance_server chez Scaleway, un compartiment de stockage objet aws_s3_bucket d'un côté et scaleway_object_bucket de l'autre. Changer d'hébergeur, en IaC, revient concrètement à remplacer le bloc provider et à remapper chaque type de ressource vers son équivalent — pas à réapprendre un nouvel outil.

C'est là que la portabilité promise par l'IaC devient tangible : ce remappage reste mécanique et localisé tant que l'infrastructure a été écrite avec des modules qui isolent les spécificités d'un fournisseur (réseau, permissions, stockage) du reste du code. Une infrastructure qui appelle directement des dizaines de ressources AWS dispersées dans tout le code, sans découpage, rend l'exercice bien plus long — sans le rendre théoriquement impossible.

Migrer d'AWS vers Scaleway suit ainsi trois volets distincts, à ne pas confondre :

1. Le code d'infrastructure — remplacer le provider et les types de ressources (instances, réseau, bases managées, stockage objet), en s'appuyant si besoin sur terraform import pour rattacher les ressources déjà créées côté Scaleway à la nouvelle définition.
2. Les données — les machines, bases de données et fichiers ne migrent pas avec le code ; ce volet se traite à part, par export, snapshot ou réplication, indépendamment de l'IaC.
3. Les spécificités du fournisseur — chaque hébergeur a ses propres limites, régions et services managés (Kubernetes Kapsule chez Scaleway, par exemple) ; une migration reste l'occasion de vérifier que ces équivalences correspondent réellement au besoin, plutôt qu'un copier-coller aveugle des paramètres AWS.

Ces spécificités — services managés, IAM, réseau — sont précisément ce que couvre la formation SOUV-011, Scaleway : fondamentaux du cloud souverain, utile pour une équipe qui envisage cette bascule sans découvrir les équivalences en production.

La portabilité, un bénéfice souvent sous-estimé

Un effet secondaire de l'IaC, moins souvent mis en avant que la fiabilité, mérite l'attention des équipes qui réfléchissent à leur hébergement : une infrastructure décrite en code, plutôt que construite à la main dans l'interface propriétaire d'un fournisseur, est structurellement plus facile à porter d'un hébergeur à un autre. Ce n'est pas une portabilité automatique — le remappage des ressources d'un provider à l'autre reste un travail réel, détaillé plus haut — mais la logique de description explicite réduit fortement la dépendance implicite qui s'accumule quand une infrastructure a été construite au clic, service propriétaire après service propriétaire.

Cet argument prend un relief particulier pour une organisation qui envisage, à terme, de migrer vers un hébergeur européen dans une logique de souveraineté numérique. Documenter son infrastructure en IaC dès aujourd'hui, même chez un hyperscaler américain, prépare une éventuelle bascule ultérieure : la définition sert de base de travail plutôt que de repartir d'une infrastructure connue seulement par la mémoire de l'équipe qui l'a construite.

Par où commencer

Adopter l'IaC ne suppose pas de tout réécrire d'un coup. Les équipes qui réussissent leur transition commencent généralement par :

1. Documenter l'existant avant de le modifier — des outils comme terraform import (ou son équivalent OpenTofu) permettent de faire correspondre une infrastructure déjà en place à une définition IaC, sans tout reconstruire.
2. Commencer par un périmètre limité et peu risqué — un environnement de test ou un service secondaire, pour apprendre les réflexes avant de toucher la production.
3. Mettre en place la revue systématique avant application — même une équipe réduite gagne à faire relire chaque changement d'infrastructure avant qu'il ne s'applique, ne serait-ce que pour détecter une erreur de syntaxe qui aurait des conséquences réelles.
4. Stocker l'état avec autant de rigueur que le code — le fichier d'état Terraform contient la cartographie exacte de l'infrastructure, parfois avec des informations sensibles ; il doit être protégé (stockage distant chiffré, accès restreint) au même titre qu'un secret.

Ce qu'il faut retenir

L'Infrastructure as Code n'est pas un effet de mode DevOps : c'est une réponse directe à deux problèmes concrets — la dérive de configuration qui s'installe inévitablement dans toute infrastructure administrée à la main, et l'absence de traçabilité qui rend les erreurs de sécurité invisibles jusqu'à l'incident. En traitant l'infrastructure comme du code versionné et relu, une équipe IT gagne en fiabilité, en auditabilité, et prépare — sans s'y engager immédiatement — une éventuelle portabilité vers un autre hébergeur, y compris souverain.