Votre infrastructure cloud dérive de votre code. Voici comment la rattraper.

Vous avez écrit votre infrastructure en tant que code. Vous avez exécuté terraform plan, examiné la sortie et appliqué les modifications. Les ressources apparaissent dans la console cloud. L'équipe célèbre un autre déploiement réussi. Le travail est terminé.

Mais l'est-il vraiment ?

Une semaine plus tard, une personne disposant d'un accès administrateur se connecte à un serveur et modifie une configuration pour résoudre un problème urgent. L'équipe de sécurité ajoute une règle de pare-feu via le tableau de bord cloud sans en informer personne. Votre fournisseur cloud déprécie un point de terminaison API, et la configuration qui fonctionnait parfaitement le mois dernier ne fait plus rien d'utile en silence.

Aucune de ces modifications n'a touché votre dépôt. Aucune n'est passée par une revue de code. Aucune n'est enregistrée là où votre équipe pourra la retrouver plus tard. Votre infrastructure est désormais différente de ce que décrit votre code. Vous avez un problème.

Cette situation a un nom : la dérive. Cela signifie que l'état réel de votre infrastructure ne correspond plus à l'état souhaité défini dans votre code. La dérive est dangereuse car elle brise silencieusement la promesse de l'infrastructure en tant que code. Si vous devez recréer un environnement à partir de zéro, le résultat sera différent. En cas d'incident, vous ne pouvez pas être sûr que l'exécution du même code restaurera un état sûr. Vous avez perdu la capacité de reproduire votre infrastructure de manière fiable.

Comment la dérive se produit en pratique

La dérive n'est pas causée par des acteurs malveillants ou des équipes incompétentes. Elle survient à la suite d'actions normales et bien intentionnées qui contournent le pipeline.

Un développeur a besoin de tester quelque chose rapidement et modifie manuellement une règle de groupe de sécurité. Un administrateur de base de données ajuste un paramètre pour gérer un pic de charge soudain. Un ingénieur plateforme corrige un serveur directement parce que le processus de correctif automatisé prend trop de temps. Chacune de ces actions a du sens sur le moment. Chacune crée un écart entre ce que dit votre code et ce qui est réellement en cours d'exécution.

Le problème s'aggrave avec le temps. Une modification manuelle devient deux, puis dix. Après quelques mois, l'infrastructure exécutée en production ressemble peu au code de votre dépôt. La prochaine fois que quelqu'un exécute terraform apply en s'attendant à un état propre, il obtient une longue liste de modifications inattendues. Personne ne sait quelles modifications sont intentionnelles et lesquelles sont des accidents. La confiance dans le code d'infrastructure s'érode.

Détecter la dérive avant qu'elle ne cause des problèmes

La solution n'est pas d'interdire les modifications manuelles. Parfois, vous devez agir vite, et le pipeline est trop lent. La solution est de détecter la dérive automatiquement et régulièrement, afin d'en être informé avant qu'elle ne provoque un incident.

La détection de dérive est un processus qui compare l'état réel de votre infrastructure à l'état souhaité dans votre code. Elle s'exécute selon un planning ou est déclenchée par des événements spécifiques. Lorsqu'elle trouve des différences, elle enregistre les détails : quelle ressource a changé, quelle partie de la configuration est différente et quelle devrait être la valeur correcte.

La plupart des outils d'infrastructure en tant que code prennent en charge la détection de dérive de manière native. Terraform a terraform plan qui montre les différences entre l'état et la configuration. Pulumi a des commandes de prévisualisation. AWS CloudFormation a une détection de dérive intégrée au service. La clé est d'exécuter ces vérifications automatiquement, pas seulement quand quelqu'un se souvient de le faire.

Voici une commande simple que vous pouvez exécuter dans votre pipeline CI pour détecter automatiquement la dérive :

#!/bin/bash
# Exécute terraform plan et se termine avec un code non nul si une dérive est détectée
terraform init -input=false
terraform plan -detailed-exitcode -input=false -out=tfplan
PLAN_EXIT_CODE=$?

if [ $PLAN_EXIT_CODE -eq 2 ]; then
  echo "Dérive détectée ! L'infrastructure ne correspond pas au code."
  # Envoyer une alerte à Slack ou à votre outil de gestion des incidents
  curl -X POST -H 'Content-type: application/json' \
    --data '{"text":"Dérive détectée dans l'environnement de production. Exécutez terraform apply pour réconcilier."}' \
    YOUR_SLACK_WEBHOOK_URL
  exit 1
elif [ $PLAN_EXIT_CODE -eq 1 ]; then
  echo "Erreur lors de l'exécution de terraform plan."
  exit 1
else
  echo "Aucune dérive détectée. L'infrastructure correspond au code."
fi

Ce script utilise -detailed-exitcode pour distinguer un état propre (code de sortie 0), une erreur (code de sortie 1) et une dérive (code de sortie 2).

Intégrer la détection de dérive dans votre pipeline

Un pipeline pratique de détection de dérive ressemble à ceci :

Voici un aperçu visuel du pipeline de détection de dérive :

flowchart TD A[Commit de code] --> B[Plan] B --> C[Apply] C --> D{Vérification de dérive} D -- Périodique ou déclenché par événement --> E{Dérive trouvée ?} E -- Non --> D E -- Oui --> F[Alerter l'équipe] F --> G{Décision} G -- Revenir --> H[Réconcilier] G -- Accepter --> I[Mettre à jour le code] H --> D I --> D

  1. Planifiez des vérifications régulières. Exécutez la détection de dérive toutes les quelques heures ou quotidiennement, selon la criticité de votre infrastructure. Pour les environnements de production, des vérifications plus fréquentes sont préférables. Pour les environnements de staging, des vérifications quotidiennes peuvent suffire.

  2. Déclenchez sur des événements suspects. Certains fournisseurs cloud émettent des événements lorsque des ressources sont modifiées en dehors de votre pipeline. Utilisez des webhooks ou des journaux d'événements pour déclencher une vérification de dérive lorsque ces événements se produisent.

  3. Rapportez les résultats. Lorsqu'une dérive est détectée, envoyez une notification à l'équipe. Utilisez Slack, un e-mail ou créez un ticket dans votre outil de suivi. La notification doit inclure les ressources qui ont dérivé et les valeurs attendues.

  4. Laissez l'équipe décider quoi faire. Toute dérive n'est pas mauvaise. Une modification manuelle peut être légitime et doit être intégrée dans le code. Une autre modification peut être accidentelle et doit être annulée. L'équipe doit voir la dérive et prendre une décision éclairée.

Réconciliation automatique : procédez avec prudence

Certaines équipes vont plus loin dans la détection de dérive et automatisent la correction. Lorsque le pipeline détecte une dérive, il exécute immédiatement apply pour ramener l'infrastructure à l'état souhaité. Cette approche fonctionne bien pour les environnements qui doivent rester cohérents, comme le staging ou les systèmes de production strictement contrôlés.

Mais la réconciliation automatique comporte des risques. Prenons l'exemple de l'auto-scaling : votre infrastructure en tant que code définit un nombre minimum et maximum d'instances. Un groupe d'auto-scaling ajoute des instances en fonction de la charge. Une exécution de détection de dérive considère les instances supplémentaires comme une dérive et les supprime. Vos utilisateurs subissent une interruption de service parce que le système faisait exactement ce qu'il était censé faire.

La règle générale est la suivante : n'automatisez la réconciliation que pour les ressources qui ne doivent jamais changer en dehors du pipeline. Pour tout le reste, notifiez l'équipe et laissez-la décider.

Une liste de contrôle pratique pour la détection de dérive

Voici une courte liste de contrôle pour vous aider à démarrer avec la détection de dérive :

  • Choisissez un planning pour les vérifications de dérive (toutes les 6 heures pour la production, quotidiennement pour le staging)
  • Configurez les notifications vers le bon canal (Slack, e-mail ou outil de gestion des incidents)
  • Décidez quels environnements bénéficient d'une réconciliation automatique et lesquels nécessitent une révision manuelle
  • Testez le processus de détection de dérive en effectuant une petite modification manuelle et en vérifiant l'alerte
  • Examinez les rapports de dérive chaque semaine en équipe pour identifier des schémas ou des problèmes récurrents

Ce que la détection de dérive vous apporte

La détection de dérive n'empêche pas les modifications manuelles. Elle n'élimine pas le besoin de réponse aux incidents. Ce qu'elle fait, c'est vous donner une visibilité sur l'écart entre votre code et la réalité. Lorsque vous êtes informé de la dérive, vous pouvez décider de l'accepter, de l'annuler ou de mettre à jour votre code pour la refléter.

Sans détection de dérive, votre infrastructure en tant que code est une fiction. Vous pouvez croire que votre système est reproductible, mais vous n'avez aucun moyen de le vérifier. Avec la détection de dérive, votre code reste la source unique de vérité parce que vous maintenez activement cette vérité.

La prochaine fois que quelqu'un dira « nous utilisons l'infrastructure en tant que code », demandez-lui : « Comment savez-vous que votre infrastructure correspond toujours à votre code ? » S'il ne peut pas répondre, il a de la dérive. Et la dérive est une bombe à retardement qui attend de exploser lors du prochain incident.