Quand votre infrastructure dérive du code

Vous avez défini toute votre infrastructure dans Terraform. Chaque groupe de sécurité, chaque taille d'instance, chaque paramètre de base de données est écrit en code et déployé via un pipeline. Vous êtes confiant que ce qui se trouve dans votre dépôt correspond à ce qui tourne en production. Puis un jour, vous lancez un plan et voyez des modifications que vous n'aviez jamais anticipées. Des ressources que vous n'avez pas touchées vont être modifiées. Quelque chose est différent entre votre code et la réalité.

Cette différence a un nom : la dérive (drift).

Ce que la dérive signifie réellement

La dérive est l'écart entre ce que votre code d'infrastructure dit devoir exister et ce qui existe réellement chez votre fournisseur cloud ou sur votre serveur. Vos fichiers Terraform ou Pulumi définissent l'état souhaité. Les ressources qui tournent sur AWS, Google Cloud ou Azure représentent l'état réel. Quand les deux ne correspondent pas, vous avez de la dérive.

Cela semble simple, mais les implications sont profondes. L'Infrastructure as Code repose sur une hypothèse critique : que votre code est la source unique de vérité pour toute la configuration. Cette hypothèse tient uniquement si chaque modification de l'infrastructure passe par votre pipeline. Dès qu'un changement se produit en dehors de ce pipeline, l'hypothèse s'effondre.

Trois façons dont la dérive s'infiltre

La dérive n'apparaît pas parce que quelqu'un a fait une erreur. Elle apparaît parce que l'infrastructure est gérée par des personnes réelles sous pression réelle.

Le diagramme ci-dessous montre comment chaque chemin contourne le pipeline IaC prévu et mène à la dérive.

flowchart TD A[Chemin prévu : pipeline IaC] --> B[État souhaité dans le code] C[Modification manuelle via la console] --> D[Modification directe] D --> E[Dérive] F[Réponse à incident] --> G[Modification d'urgence] G --> E H[Outils externes / Autoscalers] --> I[Modification automatisée hors pipeline] I --> E B -.->|Pas de dérive| J[État réel = Code] E --> K[État réel != Code]

Modifications manuelles

Quelqu'un se connecte à la console cloud et effectue une modification directement. Peut-être ajoute-t-il une règle de groupe de sécurité pour que son équipe puisse accéder à un serveur depuis une nouvelle IP de bureau. Peut-être redimensionne-t-il une instance parce qu'une démo approche et qu'il a besoin de plus de capacité. La modification prend trente secondes dans la console. Mettre à jour le code Terraform, créer une pull request, attendre la revue, exécuter le pipeline — cela prend beaucoup plus de temps. Alors, ils sautent cette étape.

Ce n'est pas de la paresse. C'est une réponse rationnelle à un système qui rend les petites modifications coûteuses. Mais chaque modification directe dans la console crée un écart entre votre code et la réalité.

Réponse aux incidents

Quand la production est en panne, personne n'ouvre d'abord une pull request. L'équipe se connecte à la console ou au CLI et effectue les modifications nécessaires pour rétablir le service. Ils augmentent la capacité des instances. Ils modifient les limites de connexion à la base de données. Ils désactivent un feature flag via le tableau de bord cloud.

Ces modifications d'urgence sont opérationnellement correctes. La priorité est de rétablir le service, pas de maintenir la pureté de l'infrastructure. Mais après l'incident, le code IaC est rarement mis à jour pour refléter ce qui s'est passé. L'équipe passe au prochain incendie, et la dérive persiste.

Outils et processus externes

Toute la dérive ne vient pas d'actions humaines. Les autoscalers ajoutent et suppriment des instances en fonction de la charge. Les outils de sécurité appliquent des politiques via des mécanismes séparés. Les systèmes de gestion des secrets font tourner les identifiants automatiquement. Les outils de gestion de configuration mettent à jour des paramètres en dehors de votre pipeline IaC.

Ce sont des processus automatisés légitimes. Ils maintiennent votre infrastructure opérationnelle et sécurisée. Mais ils créent aussi un écart entre ce que votre code Terraform définit et ce qui tourne réellement.

Pourquoi la dérive est importante

Un peu de dérive peut ne pas causer de problèmes immédiats. Votre application continue de fonctionner. Vos utilisateurs ne remarquent rien. Mais la dérive s'accumule, et cette accumulation crée des risques réels.

Le problème le plus immédiat est la confiance. Quand vous exécutez un plan Terraform, vous vous attendez à ne voir que les modifications que vous avez prévues. Mais si de la dérive existe, le plan montre des modifications inattendues. Des ressources que vous n'avez pas touchées vont être ramenées à l'état défini par le code. Cette règle de sécurité que quelqu'un a ajoutée manuellement ? Elle est supprimée lors du prochain apply. Ce redimensionnement d'instance fait lors de l'incident ? Il est annulé.

C'est dangereux car vous ne savez peut-être pas ce que vous allez casser. Un plan qui montre des modifications sur des ressources que vous n'aviez pas l'intention de modifier devrait vous arrêter. Mais en pratique, les équipes sous pression peuvent approuver le plan quand même, en supposant que les modifications sont inoffensives. Parfois elles le sont. Parfois non.

Le problème plus profond est que la dérive rend votre infrastructure imprévisible. Vous ne pouvez pas effectuer de modifications en toute confiance car vous ne connaissez pas l'état réel actuel. Chaque déploiement devient un pari. Le pipeline fonctionnera-t-il correctement ? Va-t-il annuler une modification critique effectuée lors d'un incident ? Va-t-il casser quelque chose qui fonctionne parfaitement depuis des mois ?

La dérive n'est pas un signe d'échec

Il est important de comprendre que la dérive n'est pas la preuve d'une équipe négligente. C'est une conséquence naturelle de la gestion d'une infrastructure avec plusieurs personnes, des priorités concurrentes et des pressions temporelles variables. Chaque équipe qui gère une infrastructure de production fait l'expérience de la dérive. La différence entre les équipes qui la gèrent bien et celles qui luttent n'est pas l'existence de la dérive. C'est de savoir si elles savent qu'elle existe et si elles ont un moyen de la détecter.

Une équipe qui ignore la dérive finit par perdre confiance dans l'ensemble de son pipeline de déploiement. Elle cesse de faire confiance aux plans. Elle commence à faire plus de modifications manuelles parce qu'elle ne fait pas confiance à l'automatisation. L'infrastructure devient une boîte noire que personne ne veut toucher.

Une équipe qui reconnaît la dérive intègre la détection dans son workflow. Elle effectue des vérifications régulières de la dérive. Elle a des processus pour réconcilier le code avec la réalité. Elle traite la dérive comme une partie normale de la gestion de l'infrastructure, pas comme un échec à cacher.

Une checklist pratique pour la détection de la dérive

Si vous gérez une infrastructure avec IaC, voici une courte checklist pour commencer à gérer la dérive :

  • Exécutez un plan contre votre environnement de production au moins une fois par semaine, même lorsque vous ne déployez rien. Examinez la sortie pour détecter des modifications inattendues.
  • Mettez en place une détection automatisée de la dérive. La plupart des outils IaC ont des fonctionnalités ou des intégrations qui peuvent vous alerter lorsque l'état réel diffère de l'état souhaité.
  • Après chaque incident, planifiez du temps pour mettre à jour votre code IaC afin qu'il corresponde aux modifications d'urgence effectuées.
  • Documentez quels outils et processus externes modifient l'infrastructure en dehors de votre pipeline. Sachez ce qui change automatiquement et pourquoi.
  • Lorsque vous voyez de la dérive dans un plan, enquêtez avant d'appliquer. Comprenez ce qui a causé la différence et s'il est sûr de la ramener en arrière.

La suite

La dérive ne crée pas seulement des maux de tête opérationnels. Elle rend les résultats de vos outils de planification IaC peu fiables. Lorsque vous exécutez un plan sur une infrastructure en dérive, les résultats peuvent être trompeurs. Vous pourriez voir des modifications qui semblent sûres mais qui en réalité annulent des configurations critiques. Ou vous pourriez manquer des modifications qui auraient dû être faites parce que le plan n'affiche pas ce que vous attendez.

Le vrai danger est que la dérive érode la base de confiance qui rend l'Infrastructure as Code précieuse. Sans confiance dans votre pipeline, vous perdez la capacité à effectuer des modifications rapidement et en toute sécurité. Et cette confiance est l'objectif même de l'automatisation de votre infrastructure.