L’Infrastructure as Code rend une intention d’infrastructure versionnable et reproductible. Le code n’est toutefois pas l’infrastructure réelle : un outil doit rapprocher cette intention de ressources existantes, avec un état, des interfaces et des contraintes d’exécution. Comprendre cette relation évite les principales fausses garanties.
Ce que la description apporte
Un changement exprimé dans des fichiers peut être relu, comparé et relié à une décision. Les paramètres communs peuvent être factorisés et les environnements reconstruits selon des règles connues. Le bénéfice est particulièrement utile lorsque plusieurs personnes doivent comprendre pourquoi une ressource existe.
La reproductibilité ne signifie pas que tous les environnements doivent être identiques. Les différences légitimes — capacité, zones, politiques — doivent être explicites. Une multiplication de conditions illisibles peut rendre une configuration partagée plus difficile à maintenir que des modules plus simples.
Distinguer code, plan et état
Le code exprime l’intention. Le plan décrit les opérations que l’outil prévoit. L’état relie les ressources suivies à leur représentation dans l’outil. Le comportement précis dépend du produit ; Terraform est pris ici comme exemple, sans supposer que tous les outils fonctionnent de manière identique.
La documentation Terraform sur l’état explique sa fonction de correspondance et de suivi. Traiter ce fichier comme un artefact secondaire exposerait la coordination du travail et la reprise à des erreurs.
| Objet | Question principale | Risque de confusion |
|---|---|---|
| Code | Que souhaite-t-on obtenir ? | Une intention peut ne pas être appliquée |
| Plan | Quels changements sont prévus ? | L’environnement peut évoluer avant l’application |
| État | Quelles ressources sont suivies ? | Un état incomplet ne décrit pas tout le parc |
| Observation réelle | Que fait le service ? | Une ressource créée peut rester inutilisable |
Examiner les remplacements, pas seulement les différences
Une modification courte peut provoquer le remplacement d’une ressource. La revue doit donc regarder la nature des actions, les dépendances et les conséquences sur les données. Compter les lignes modifiées ne mesure pas le risque.
Exemple pédagogique : changer un paramètre d’une ressource de stockage peut être traité comme une mise à jour ou comme une recréation selon l’API et le fournisseur. Le plan et la documentation du fournisseur doivent être examinés avant l’application. Aucun nom de paramètre n’est universellement sûr.
Pour les ressources critiques, définir des protections adaptées, vérifier leur comportement et documenter les procédures d’exception. Une protection qui peut être contournée sans revue ne remplace pas la gouvernance du changement.
Traiter l’état comme une donnée sensible
La documentation HashiCorp sur les données sensibles indique que plans et états peuvent contenir des valeurs sensibles. Marquer une valeur sensitive la masque dans certains affichages ; cela ne garantit pas son absence de l’état.
Restreindre les accès, protéger le stockage et empêcher l’entrée des fichiers sensibles dans le dépôt. Les possibilités de données éphémères ou de propriétés en écriture seule dépendent des versions et des fournisseurs ; vérifier leur support au lieu de supposer qu’un drapeau protège tous les secrets.
Les journaux du pipeline et les artefacts de plan méritent la même attention. Un contrôle d’accès strict au backend perd une partie de sa valeur si un export détaillé est public.
Rendre la dérive visible
Une modification manuelle peut éloigner le réel du code. La réponse n’est pas toujours de réappliquer immédiatement la configuration : la modification peut avoir été une action d’urgence justifiée, ou le code peut être devenu incorrect.
Détecter la dérive, identifier son origine, décider de l’état de référence puis réconcilier les deux permet d’éviter une annulation aveugle. Une intervention urgente doit laisser une trace et déclencher la mise à jour de la description si elle devient la nouvelle intention.
Maîtriser les opérations simultanées
Le verrouillage, lorsqu’il est supporté par le backend, aide à éviter les écritures concurrentes sur un même état. Il ne remplace pas une bonne séparation des périmètres. Un état unique immense peut rendre des changements sans rapport dépendants du même mécanisme de coordination.
Le découpage doit suivre les responsabilités et les cycles de vie, sans créer une explosion de dépendances difficiles à résoudre.
Tester ce que le plan ne prouve pas
Après l’application, un contrôle fonctionnel doit vérifier le service : connectivité autorisée, identité attendue, disponibilité et comportement utile. La création d’une ressource ne prouve pas que l’application sait l’utiliser.
Prévoir également un scénario de reprise. Revenir au commit précédent n’annule pas automatiquement une suppression de données. Selon l’opération, la réponse peut être une correction en avant ou une restauration préparée et autorisée.
Checklist pour une revue utile
- Les remplacements et suppressions sont compris.
- La portée du plan correspond à l’environnement visé.
- Les versions et dépendances sont maîtrisées.
- Les plans, états et journaux sont protégés.
- La dérive et les accès concurrents ont une procédure.
- La réussite est vérifiée depuis le service consommateur.
- La méthode de reprise correspond aux effets réels.
Pour intégrer ces contrôles à une chaîne de livraison, lire DevOps et infrastructure. Pour les jalons et décisions, consulter le pilotage d’une infrastructure critique et le dossier DevOps & Automation.