Infrastructure as Code : reproductibilité, dérive et gestion des secrets.

L’infrastructure décrite comme du code consiste à définir les ressources d’un environnement dans des fichiers versionnés, plutôt qu’à les créer manuellement dans une console. Le bénéfice annoncé est la reproductibilité. Le bénéfice réel est plus large et moins souvent formulé : l’infrastructure devient auditable, revue comme du code, et reconstructible après un incident majeur. Cette page traite ce que la démarche apporte, les trois pièges qui la font échouer et le statut particulier de l’état de configuration, dans le prolongement de notre couverture IA, données et plateformes.

Déclaratif et impératif

Définition. L’Infrastructure as Code décrit l’état souhaité d’un environnement dans des fichiers versionnés, qu’un outil applique en calculant les opérations nécessaires pour atteindre cet état. L’approche déclarative décrit le résultat attendu, l’approche impérative décrit la suite d’opérations à exécuter.

La différence a une conséquence pratique. Un script impératif exécuté deux fois produit deux résultats différents s’il ne teste pas l’existant. Une description déclarative appliquée deux fois produit le même état, ce qui rend l’opération sûre à répéter.

C’est cette propriété qui permet les trois usages qui justifient la démarche :

• Reconstruire un environnement identique en cas de sinistre, ce qui transforme un plan de reprise théorique en procédure exécutable.
• Créer des environnements éphémères conformes à la production pour les tests, sans dérive entre eux.
• Faire relire l’infrastructure comme du code, avec revue par un pair avant application. C’est le contrôle le plus efficace contre les erreurs de configuration.

Les trois pièges

La dérive de configuration

C’est le plus fréquent. Quelqu’un modifie une ressource directement dans la console pour résoudre une urgence, et l’état réel s’écarte de l’état déclaré. À la prochaine application, l’outil écrase la correction, ou refuse de s’appliquer.

La parade tient en deux mesures : détecter la dérive automatiquement par une comparaison périodique, et surtout retirer les droits de modification manuelle en production. Tant que la console reste ouverte en écriture, la dérive revient. C’est une décision d’organisation, pas d’outillage.

L’état de configuration

L’outil conserve un fichier d’état qui associe les ressources déclarées aux ressources réellement créées. Ce fichier est doublement critique.

Il contient des données sensibles. Selon les ressources gérées, il peut inclure des identifiants, des points d’accès et des paramètres de configuration. Il doit être stocké de manière chiffrée, avec des accès restreints, et jamais dans un dépôt de code.

Sa perte est un incident majeur. Sans lui, l’outil ne sait plus quelles ressources il gère et tente de les recréer. Le stockage distant avec verrouillage et versionnement n’est pas une bonne pratique optionnelle, c’est un prérequis.

Les secrets dans le code

Une description d’infrastructure a besoin de mots de passe, de clés et de certificats. Les écrire dans les fichiers versionnés est l’erreur la plus commune et la plus coûteuse, puisqu’un secret versé reste dans l’historique. La parade est la même que sur la chaîne de livraison : coffre-fort centralisé et injection à l’exécution, traitée dans notre section CI/CD et DevSecOps.

Ce qui distingue une démarche mature

La ligne la plus discriminante est la deuxième. Une organisation qui décrit son infrastructure mais laisse la console ouverte en écriture n’a pas d’infrastructure reproductible, elle a de la documentation.

Le lien avec la sécurité et la conformité

Trois apports directs, rarement mis en avant.

L’audit. Répondre à la question « qui a modifié quoi, quand et pourquoi » devient trivial quand chaque changement passe par une demande de fusion revue et tracée. C’est un élément de preuve utile dans les périmètres soumis à obligation, notamment au titre de la conformité NIS2.

La reconstruction après incident. Une infrastructure entièrement décrite se reconstruit sur un environnement sain, ce qui change la nature d’une reprise après une attaque par rançongiciel.

Les contrôles de conformité automatisés. Vérifier avant application qu’aucune ressource n’expose un port sensible, qu’un chiffrement est activé ou qu’une politique d’accès respecte le moindre privilège. Le contrôle intervient alors avant la création, et non après un audit.

La supervision de l’état réel des environnements est traitée dans notre section observabilité et monitoring.

Explorer le cluster

Cette page fait partie de notre couverture de l’intelligence artificielle, de la donnée et des plateformes : gouvernance, socle technique et industrialisation.

iTPro+ : recevez chaque semaine les analyses plateforme et infrastructure qui concernent les équipes techniques.