Prévenir et corriger la dérive d'infrastructure dans Terraform pour Azure

By Mirko Peters · 2026-10-28

Découvrez comment la dérive d'infrastructure apparaît dans Terraform et Azure, comment les correctifs d'urgence appliqués dans le portail corrompent les fichiers d'état, et comment détecter et corriger les écarts en toute sécurité.

Automatically translated with AI from the original post. Read the English original

La dérive d'infrastructure fait partie des dangers silencieux les plus courants et les plus redoutables des environnements cloud modernes. Lorsque les ingénieurs effectuent des ajustements manuels directement dans le portail Azure en situation d'urgence, leurs actions rompent discrètement la synchronisation avec les dépôts de code. Ce guide complet explique comment la dérive se produit, les risques qu'elle fait peser sur vos fichiers d'état, et comment détecter et corriger méthodiquement les écarts sans provoquer d'interruption de production.

Points clés

• La dérive d'infrastructure apparaît lorsque les modifications manuelles effectuées dans la console cloud divergent du code Terraform déclaré.
• Les correctifs d'urgence appliqués directement en production contournent le contrôle de version et préparent des échecs silencieux lors des exécutions de plan ultérieures.
• Les fichiers d'état Terraform jouent le rôle de mémoire intermédiaire : ils permettent de comparer votre configuration écrite, l'état précédent et les ressources cloud réellement déployées.
• Détecter la dérive au plus tôt suppose des exécutions de plan automatisées et régulières, ainsi qu'une stratégie stricte interdisant les modifications manuelles non documentées dans le portail.
• Résoudre une dérive implique de choisir entre ramener l'environnement en production à la configuration du code ou mettre à jour votre configuration pour refléter la réalité.

Qu'est-ce que la dérive d'infrastructure et pourquoi se produit-elle ?

Même les équipes d'ingénierie cloud les plus rigoureuses finissent par subir la dérive d'infrastructure. On désigne ainsi toute modification non autorisée, non documentée ou effectuée en urgence sur des ressources cloud, qui fait évoluer leur état en dehors de vos pipelines automatisés. Imaginons un ingénieur appelé en pleine nuit pour un incident. Sous pression, il se connecte à la console Azure, augmente une limite de mise à l'échelle automatique de cinq à dix instances, résout le problème et retourne se coucher.

Le problème, c'est que le fichier de configuration versionné dans votre dépôt indique toujours cinq. L'environnement cloud réel en indique dix. Comme personne n'a documenté la modification ni mis à jour le code, un écart important s'installe entre l'architecture prévue et la réalité. Cet écart reste invisible pendant des semaines, jusqu'à ce qu'une exécution de plan Terraform de routine, pour une mise à jour sans rapport, fasse apparaître un avertissement : Terraform s'apprête à ramener ces instances à cinq.

La dimension humaine et la pression opérationnelle

La dérive est rarement malveillante ; elle naît presque toujours de l'urgence opérationnelle. Lorsque les environnements de production tombent en panne, l'instinct pousse les ingénieurs à colmater la brèche au plus vite, avec les outils les plus rapides à leur disposition. Le provisionnement par clics dans le portail Azure est rapide, tangible et immédiat. Pourtant, chaque fois qu'un ingénieur corrige un problème depuis le portail sans le reporter dans le code, il contracte une dette technique qu'il faudra rembourser plus tard, avec intérêts.

Comment l'état Terraform identifie les écarts

Pour comprendre comment Terraform détecte la dérive, il faut examiner de près son mécanisme de mémoire : le fichier d'état. Le fichier d'état de Terraform fait office de source de vérité, en faisant correspondre vos ressources cloud à vos fichiers de configuration. Lorsque vous exécutez une commande, Terraform ne transmet pas aveuglément des fichiers vers le cloud. Il effectue à la place une comparaison en trois volets.

D’abord, il lit ce que vous avez écrit dans vos fichiers de configuration. Ensuite, il inspecte ce qu’il a enregistré dans le fichier d’état lors du dernier apply réussi. Enfin, il interroge l’API du fournisseur cloud via les plugins et vérifie ce qui existe réellement dans votre abonnement à cet instant. Lorsque ces trois éléments ne concordent pas, Terraform détecte que la réalité a discrètement changé.

Le danger des avertissements ignorés

Lors de l’exécution d’un plan, Terraform génère une sortie détaillée présentant les ajouts, les mises à jour et les suppressions. En présence d’une dérive, vous verrez souvent des avertissements indiquant qu’une ressource doit être modifiée, voire entièrement remplacée. Les débutants paniquent fréquemment face aux avertissements de remplacement forcé de ressources. Cet avertissement n’est pas une erreur : Terraform vous signale que la ressource réelle a été modifiée au point de ne plus être reconnaissable et que, pour la remettre en conformité avec votre code, elle doit être détruite puis recréée.

Bonnes pratiques pour détecter et prévenir la dérive

Prévenir la dérive exige à la fois des garde-fous organisationnels et des contrôles techniques automatisés. Si vous laissez la détection de la dérive entièrement aux vérifications manuelles, vous subirez inévitablement des interruptions de production douloureuses. Voici les stratégies fondamentales qu’utilisent les équipes pour maintenir leurs environnements cloud alignés :

• Appliquer un accès en lecture seule : Retirez les droits d’écriture en production aux utilisateurs humains. Faites transiter toutes les modifications d’infrastructure par vos pipelines CI/CD et par des revues de pull requests.
• Planifier des exécutions automatisées de plan : Configurez des pipelines d’intégration continue pour exécuter régulièrement la commande « terraform plan » sans l’appliquer. Analysez la sortie pour repérer les modifications inattendues.
• Découper les fichiers d’état monolithiques : Répartissez les grands environnements en composants plus petits et modulaires. Des fichiers d’état plus petits facilitent l’isolation, la revue et la correction de la dérive.
• Mettre en place le verrouillage de l’état distant : Assurez-vous que votre équipe utilise des backends distants sécurisés avec verrouillage de l’état afin d’empêcher les exécutions concurrentes de corrompre les enregistrements d’état.

Comment corriger la dérive lorsqu’elle survient

Lorsque vous constatez que votre infrastructure réelle a dérivé de votre configuration, vous vous trouvez face à un choix stratégique. Deux voies principales s’offrent à vous pour la corriger :

La première option consiste à laisser Terraform écraser l’environnement réel. En exécutant votre commande « terraform apply » habituelle, vous forcez Azure à revenir à l’état décrit dans votre code. C’est la voie à suivre lorsque la dérive résulte d’une modification manuelle non autorisée ou d’un paramètre de débogage temporaire qui ne devrait plus exister.

La seconde option consiste à mettre à jour votre configuration Terraform pour refléter la réalité. Choisissez cette voie lorsque le correctif d’urgence appliqué manuellement pendant un incident s’est révélé nécessaire, stable et bénéfique pour la production. En mettant à jour votre code pour refléter le nouvel état, vous comblez l’écart et garantissez que les exécutions automatisées futures préserveront la configuration nécessaire.

Conclusion

La dérive de l’infrastructure est un défi inévitable dans les environnements cloud dynamiques, mais elle ne doit pas nécessairement tourner à la catastrophe pour votre équipe. En comprenant comment le fichier d’état de Terraform suit les modifications, en mettant en œuvre des contrôles d’accès stricts et en faisant de la détection de la dérive une habitude opérationnelle régulière, vous pouvez garder un contrôle total sur votre architecture cloud. Pour explorer plus en détail les mécanismes fondamentaux de l’infrastructure as code, des fournisseurs et de la gestion de l’état, écoutez l’épisode complet et découvrez toutes les analyses d’experts pour faire progresser votre stratégie d’automatisation cloud.

Questions fréquentes

Qu’est-ce qui provoque la dérive de l’infrastructure dans Terraform ?

La dérive est causée par des modifications effectuées hors bande directement sur les ressources cloud, via le portail, des commandes CLI ou des scripts qui contournent le pipeline Terraform.

Comment Terraform détecte-t-il la dérive de configuration lors d’une exécution de plan ?

Terraform compare le contenu de son fichier d’état avec les ressources cloud réelles, interrogées via les API des fournisseurs, ainsi qu’avec vos fichiers de configuration locaux.

Que se passe-t-il si quelqu’un modifie manuellement une ressource Azure gérée par Terraform ?

Lors de la prochaine exécution d’un plan Terraform, celui-ci signalera l’écart et tentera de rétablir la ressource conformément à votre code déclaré, sauf si la configuration est mise à jour.

Dois-je mettre à jour mon code Terraform ou annuler la modification effectuée dans le portail Azure ?

Si la modification manuelle était un correctif d’urgence devenu indispensable à la stabilité, mettez à jour votre configuration Terraform. Si elle était non autorisée ou accidentelle, laissez Terraform la rétablir.