L’infrastructure as code décrit les ressources cloud dans des fichiers versionnés. Elle rend les changements lisibles et reproductibles, mais le modèle perd sa valeur si des modifications manuelles restent inconnues. Une PME peut limiter ce risque avec un état clair, des revues et des contrôles réguliers.
Définir ce qui est géré
Inventoriez les réseaux, comptes de stockage, bases, certificats, règles d’accès et services utilisés en production. Pour chaque ressource, indiquez le module ou le fichier qui la décrit, son propriétaire et la méthode de modification autorisée. Une ressource créée à la main doit être importée, remplacée ou documentée comme exception.
Séparez les environnements avec des variables et des états distincts. Un état de préproduction ne doit pas pouvoir modifier une ressource de production par une mauvaise sélection de compte ou de projet. Ajoutez une vérification explicite de l’environnement dans le pipeline.
Protéger le fichier d’état
L’état permet à l’outil de relier une définition à une ressource réelle. Il peut contenir des noms, des identifiants et parfois des valeurs sensibles. Stockez-le dans un backend prévu pour le partage, limitez les droits et activez le verrouillage lorsque plusieurs personnes peuvent lancer un changement.
Conservez l’historique des états selon une politique de rétention. Testez une récupération sur un environnement isolé. Un fichier d’état absent ou corrompu peut empêcher un plan de changement, même si l’infrastructure fonctionne encore.
Revoir le plan avant application
Un pipeline devrait produire un plan lisible avant de modifier le cloud. La revue vérifie les créations, suppressions, changements de réseau et permissions. Un changement qui remplace une ressource doit expliquer les données concernées et la possibilité de retour.
Ajoutez des règles pour bloquer les valeurs dangereuses : ouverture générale d’un port d’administration, suppression d’une sauvegarde ou absence de chiffrement. Ces contrôles doivent être testés sur des exemples valides et invalides afin d’éviter de bloquer chaque évolution.
Détecter la dérive
Une dérive apparaît lorsqu’une ressource réelle diffère de sa définition. Elle peut venir d’un dépannage urgent, d’un réglage du fournisseur ou d’un changement réalisé dans une console. Lancez régulièrement un plan en lecture seule et examinez les différences. Ne les acceptez pas automatiquement, car une modification peut avoir une raison métier ou de sécurité.
Pour chaque dérive, choisissez une action : reporter la modification dans le code, rétablir l’état déclaré ou garder l’exception avec une date de révision. Cette décision doit être visible dans le ticket associé. Les exceptions sans propriétaire deviennent rapidement permanentes.
Gérer les secrets et les modules
Ne placez pas les clés dans les fichiers d’infrastructure ou leurs sorties. Référencez un gestionnaire de secrets et réduisez les droits du compte qui exécute le pipeline. Vérifiez aussi les modules externes, leurs versions et leurs sources avant une mise à jour.
Un module partagé doit avoir une documentation courte, des exemples et des tests. Une modification de sa valeur par défaut peut toucher plusieurs services. Publiez une nouvelle version et testez-la sur un environnement avant de mettre à jour les consommateurs.
Planifier le retour
L’infrastructure as code facilite la reproduction, mais elle ne remplace pas un plan de restauration des données. Identifiez les ressources dont la suppression est irréversible et traitez leurs sauvegardes séparément. Les changements de base de données, DNS et permissions peuvent nécessiter des étapes manuelles coordonnées.
Le guide sur le retour arrière d’un déploiement aide à relier code, infrastructure et données. Sky Vaults peut aussi vous accompagner sur l’infrastructure cloud au Maroc.
Sources : Terraform, state, AWS Well-Architected, operations.