Quand la dérive d'infrastructure rend votre plan Terraform inutile

Vous lancez un pipeline pour déployer une nouvelle version d'application. Terraform plan s'exécute et le résultat montre qu'il veut redimensionner votre instance de base de données de production. Personne dans l'équipe n'avait l'intention de toucher à la base de données. Le relecteur de la pull request fixe le plan, perplexe. Est-ce un effet de bord de la nouvelle version ? Une exigence de sécurité qu'il a manquée ? Quelqu'un approuve juste pour débloquer la release, et soudain votre base de données tourne sur du matériel plus petit en plein pic de trafic.

Ce scénario n'est pas hypothétique. Il se produit quand l'infrastructure a dérivé de ce que votre code définit. Et une fois que la dérive s'installe, votre outil le plus fiable pour des changements d'infrastructure sûrs devient peu fiable.

Ce que signifie réellement la dérive

La dérive d'infrastructure est l'écart entre ce que votre code dit que l'infrastructure devrait être et ce qui existe réellement dans votre environnement cloud. Vous avez écrit du code Terraform, Pulumi ou CloudFormation qui définit vos ressources. Quelqu'un se connecte à la console cloud et modifie un type d'instance, ajoute une règle de groupe de sécurité ou ajuste un paramètre de base de données. Ce changement ne touche jamais votre dépôt de code. Il ne passe jamais par un pipeline. Il se produit simplement.

L'infrastructure fonctionne toujours. Les applications tournent toujours. Mais votre code ne décrit plus la réalité. Il décrit ce que la réalité était.

Le plan qui vous ment

Les outils d'Infrastructure as Code comme Terraform fonctionnent en comparant deux choses : vos définitions de code et votre fichier d'état (qui suit ce qui existe dans le cloud). Quand les deux correspondent, le plan que vous obtenez est précis. Il montre exactement ce qui changera en fonction de votre dernier commit de code.

Le diagramme suivant montre comment la dérive crée un décalage entre le code, l'état et l'infrastructure réelle, conduisant à un plan inexact :

La dérive brise cette comparaison. Le fichier d'état devient obsolète car l'infrastructure réelle a changé en dehors du pipeline. Quand Terraform exécute plan, il lit l'état obsolète et le compare avec votre code. Le résultat donne l'impression que Terraform veut faire des changements, mais ces changements sont en réalité des corrections pour ramener l'infrastructure à ce que votre code dit. Pas des changements que vous aviez l'intention de faire.

C'est ce qu'on appelle la dérive de plan : un plan qui reflète des différences préexistantes entre le code et la réalité, et non les changements que vous voulez réellement déployer.

Trois façons dont la dérive endommage votre pipeline

Destruction inattendue

C'est le résultat le plus dangereux. Imaginez un groupe de sécurité réseau que votre équipe de sécurité a créé manuellement pour isoler une charge de travail sensible. Cette ressource n'existe pas dans votre code IaC. Quand votre pipeline exécute terraform apply avec du code qui n'a jamais défini cette ressource, Terraform la considère comme quelque chose qui ne devrait pas exister. Il la détruit. Votre configuration de sécurité disparaît silencieusement, et personne ne s'en aperçoit jusqu'à ce que quelque chose casse.

Temps de revue gaspillé

Les relecteurs de pull request voient un plan qui montre des changements sur des ressources sans rapport avec la fonctionnalité déployée. Ils ne peuvent pas dire s'il s'agit d'effets de bord accidentels, de mises à jour nécessaires ou de quelque chose de suspect. Du temps est passé à enquêter sur des changements qui ne font pas réellement partie du travail. Les cycles de revue s'allongent. Les équipes commencent à se demander "Est-ce que quelqu'un a encore touché à la production ?" au lieu de se concentrer sur le changement de code réel.

Confiance brisée dans l'automatisation

Quand les plans montrent constamment des changements inattendus, les équipes cessent de faire confiance au pipeline. Elles effectuent des vérifications manuelles avant de déployer. Elles commencent à faire des changements directement dans la console parce que le pipeline semble peu fiable. L'ironie est brutale : plus les changements se produisent en dehors du pipeline, plus la dérive s'aggrave. Le pipeline devient moins fiable, donc les gens le contournent davantage, ce qui le rend encore moins fiable.

Pourquoi la dérive se produit dans les équipes réelles

La dérive n'est pas causée par de mauvais ingénieurs. Elle se produit parce que le travail réel crée des situations où le pipeline n'est pas le chemin le plus rapide :

• Un incident nécessite un changement immédiat. L'ingénieur d'astreinte le corrige dans la console car écrire du code, commiter et attendre un pipeline prend trop de temps.
• Un administrateur de base de données ajuste des paramètres directement dans la console cloud car il ne travaille pas quotidiennement avec les outils IaC.
• Une équipe de sécurité ajoute des règles de pare-feu temporaires lors d'un audit et oublie de les documenter.
• Un développeur a besoin de tester quelque chose rapidement et crée manuellement une ressource, prévoyant de "l'ajouter au code plus tard."

Chacune de ces actions a du sens isolément. Ensemble, elles créent un écart entre le code et la réalité qui grandit jusqu'à ce que le pipeline ne puisse plus être fiable.

Détecter la dérive avant qu'elle ne nuise

La solution n'est pas d'interdire l'accès à la console. Cette approche échoue car les urgences et les besoins opérationnels légitimes contourneront toujours les règles rigides. La solution est de détecter la dérive automatiquement et de la signaler avant que quiconque n'exécute un plan.

La plupart des outils IaC offrent des fonctionnalités de détection de dérive. Terraform Cloud et Enterprise ont une détection de dérive qui exécute des plans selon un calendrier et alerte lorsque l'infrastructure réelle diffère de l'état. OpenTofu, le fork open-source de Terraform, inclut des capacités similaires. Vous pouvez également construire votre propre détection en utilisant des exécutions planifiées de pipeline qui comparent l'état aux ressources cloud réelles.

La clé est de rendre la dérive visible. Quand un membre de l'équipe change quelque chose dans la console, la prochaine vérification de dérive planifiée devrait le signaler. L'équipe peut alors décider : mettre à jour le code pour correspondre au changement, ou revenir au changement défini par le code. Les deux choix sont valides, tant qu'ils sont intentionnels et suivis.

Une checklist pratique de détection de dérive

Si vous gérez l'infrastructure avec IaC, envisagez d'ajouter ces vérifications à votre routine :

• Planifiez une exécution hebdomadaire de détection de dérive pour les environnements de production
• Alertez l'équipe quand une dérive est trouvée, pas seulement quand elle cause des échecs
• Examinez les rapports de dérive lors de votre réunion d'équipe régulière
• Documentez un processus clair pour réconcilier la dérive : soit mettre à jour le code, soit annuler le changement
• Traitez les changements manuels dans la console comme des solutions temporaires, pas des solutions permanentes

Le vrai coût d'ignorer la dérive

La dérive ne casse pas votre infrastructure immédiatement. Elle érode lentement la fiabilité de votre pipeline. Chaque dérive non détectée rend le prochain plan moins fiable. Chaque plan qui surprend l'équipe la rend moins encline à automatiser. Finalement, votre infrastructure devient une boîte noire où personne ne sait ce qui tourne réellement, et le dépôt de code devient un document d'aspiration plutôt qu'une source de vérité.

L'objectif n'est pas d'éliminer complètement la dérive. Une certaine dérive est inévitable dans les systèmes complexes. L'objectif est de la détecter rapidement, de la rendre visible et de donner à votre équipe un chemin clair pour la réconcilier. Quand votre plan montre uniquement les changements que vous avez intentionnés, vous pouvez à nouveau faire confiance à votre pipeline.