États de référence et dérive de configuration : maîtriser le drift

Un serveur de production tombe en panne un vendredi soir. L’équipe de garde cherche la cause pendant des heures. Finalement, quelqu’un découvre qu’un paramètre réseau a été modifié « temporairement » il y a trois semaines, sans documentation. Personne ne savait. Le système était censé être identique aux autres, mais il avait dérivé silencieusement.

Ce guide vous explique ce qu’est la dérive de configuration, comment la détecter avant qu’elle ne cause des incidents, et comment l’empêcher de se reproduire.

Un scénario que vous connaissez peut-être

Imaginez cette situation : vous gérez un parc de 50 serveurs web. Tous sont censés être identiques, déployés à partir du même playbook Ansible. Un jour, vous devez migrer vers une nouvelle version de l’application.

Vous lancez la mise à jour. 47 serveurs se mettent à jour sans problème. Trois échouent avec des erreurs incompréhensibles. Après investigation, vous découvrez que :

• Sur le serveur 23, quelqu’un a modifié manuellement le fichier /etc/hosts pour « corriger un problème de DNS urgent » il y a six mois
• Sur le serveur 41, un collègue a installé un package de debug qui n’a jamais été retiré et qui entre en conflit avec la nouvelle version
• Sur le serveur 48, les permissions d’un répertoire ont été changées lors d’un dépannage nocturne, et le script de déploiement n’a plus les droits d’écriture

Trois serveurs, trois dérives différentes, trois heures perdues par serveur. Vous venez de découvrir le coût réel de la dérive de configuration.

Qu’est-ce que la dérive de configuration ?

L’état de référence : votre source de vérité

L’état de référence (baseline en anglais) est l’état validé et documenté d’un système. C’est la définition de « comment ce serveur devrait être configuré ».

Elle inclut généralement :

Composant	Exemples d’éléments contrôlés
Système	Version OS, paramètres noyau, utilisateurs
Packages	Liste des logiciels installés, versions
Configuration	Fichiers de conf, permissions, services actifs
Réseau	Interfaces, routes, firewall, DNS
Sécurité	Durcissement, certificats, politiques

L’état de référence peut être :

• Documenté : wiki, fichiers de référence, CMDB
• Codifiée : playbooks Ansible, manifests Terraform, Dockerfiles, configurations Rudder
• Implicite : « c’est comme ça qu’on fait » (dangereux)

La dérive : l’écart silencieux

La dérive de configuration (configuration drift) survient quand l’état réel d’un système s’écarte de son état de référence. C’est la différence entre « ce que le système devrait être » et « ce qu’il est vraiment ».

État attendu (état de référence) - État réel = Dérive

Trois analogies pour bien comprendre

Le GPS

Votre état de référence est l’itinéraire planifié. La dérive, c’est quand vous prenez des détours non prévus. Chaque détour vous éloigne de la route optimale. Sans « recalcul d’itinéraire » (détection), vous pouvez finir complètement perdu.

Un bon GPS vous alerte immédiatement si vous quittez la route. Un bon système de gestion de configuration fait pareil.

La recette de cuisine

Votre état de référence est la recette originale. La dérive arrive quand chaque cuisinier « améliore » un peu la recette sans le noter : un peu plus de sel ici, une cuisson plus longue là.

Après quelques mois, personne ne sait plus comment reproduire le plat original. Chaque restaurant de la chaîne sert une version différente.

L'orchestre

Votre état de référence est la partition. La dérive survient quand chaque musicien commence à interpréter les notes « à sa façon » sans coordination. Au début, c’est subtil. Progressivement, l’ensemble devient cacophonique.

Le chef d’orchestre (votre outil de détection) doit ramener tout le monde à la même partition.

Ce que la dérive n’est PAS

Ce n’est PAS de la dérive	Pourquoi
Un changement planifié et documenté	C’est une évolution de l’état de référence
Une mise à jour de sécurité appliquée uniformément	L’état de référence évolue de façon contrôlée
Une différence volontaire entre environnements	Dev ≠ Prod par conception
Un bug logiciel	C’est un défaut, pas un écart de configuration

Pourquoi la dérive est dangereuse

La dérive de configuration peut sembler anodine — après tout, qu’est-ce qu’un petit paramètre modifié ? Pourtant, elle est à l’origine de nombreux incidents majeurs, de failles de sécurité et de problèmes de conformité. Comprendre ses conséquences permet de prendre au sérieux sa prévention.

Les quatre cavaliers de la dérive

Conséquence	Ce qui se passe	Exemple réel
Incidents	Comportement imprévisible	Serveur 23 différent des autres → plantage lors d’une mise à jour
Failles de sécurité	Durcissement perdu	En 2020, Twilio a subi une fuite de données via un bucket S3 dont la config avait dérivé
Non-conformité	Écart aux politiques	Audit PCI-DSS échoué car des serveurs n’avaient plus les bons paramètres
Temps perdu	Debug de « snowflakes »	Chaque serveur différent = chaque incident unique à investiguer

La spirale de la dette de configuration

La dérive fonctionne comme la dette technique : elle s’accumule avec intérêts. Imaginez une boule de neige qui dévale une pente — plus elle roule, plus elle grossit et plus elle est difficile à arrêter.

1. Dérive initiale — Une petite modification manuelle « juste pour tester ». Ça semble anodin : « Je corrige vite ce paramètre en SSH, je documenterai plus tard ». Coût de correction à ce stade : quelques minutes.

2. Accumulation — D’autres modifications s’ajoutent sans documentation. Chaque membre de l’équipe fait « une petite correction ». Ces modifications s’empilent comme des couches de peinture. Coût de correction : quelques heures.

3. Divergence — Les serveurs « identiques » ne le sont plus. Le serveur de production ne se comporte pas comme celui de test. L’équipe commence à entendre : « Ça marche chez moi mais pas en prod ». Coût de correction : jours de travail.

4. Snowflake — Chaque serveur devient unique, impossible à reproduire. Le serveur 23 a des configurations que personne ne comprend. On n’ose plus y toucher. Coût de correction : semaines, avec risque d’incident.

5. Paralysie — L’équipe a peur de toucher quoi que ce soit. Toute mise à jour devient un projet risqué. L’innovation s’arrête. Coût de correction : mois de refonte, souvent après un incident majeur.

Qu’est-ce qu’un serveur « snowflake » ?

Un serveur « snowflake » (flocon de neige) est un serveur devenu tellement unique qu’il est impossible à recréer. Comme chaque flocon de neige est unique dans la nature, ce serveur a subi tellement de modifications manuelles non documentées que personne ne sait exactement comment le reproduire. Si ce serveur tombe en panne, c’est une catastrophe : il faudrait des jours (voire des semaines) pour le reconstruire, en espérant ne rien oublier.

Sources et types de dérive

La dérive ne vient pas de nulle part. Elle a toujours une cause — technique ou humaine. Comprendre ses sources est la première étape pour la prévenir efficacement.

Dérive technique : les causes opérationnelles

Ces causes sont liées aux outils et aux processus techniques. Elles sont souvent les plus faciles à résoudre car elles relèvent de l’outillage.

Source	Comment ça arrive	Pourquoi c’est dangereux
Modifications manuelles	SSH + commandes ad hoc pour « corriger vite »	Pas de trace, pas de rollback
Patchs et mises à jour	Correctif appliqué sur certains serveurs seulement	Parc hétérogène
Automatisations partielles	Playbook qui échoue à mi-chemin	État incohérent
Ressources non gérées	Création cloud via console au lieu d’IaC	Shadow IT invisible

Exemple concret — Un développeur crée un bucket S3 via la console AWS pour tester quelque chose. Il ne le supprime pas. Le bucket n’existe pas dans Terraform, donc il n’est pas audité. Six mois plus tard, il contient des données sensibles et n’a pas les bonnes politiques de sécurité.

Dérive organisationnelle : les causes humaines

Ces causes sont liées à l’organisation, aux processus et aux personnes. Elles sont souvent plus difficiles à résoudre car elles nécessitent des changements culturels.

Source	Comment ça arrive	Pourquoi c’est dangereux
Processus contournés	« Pas le temps pour le change management »	Modifications non tracées
Documentation obsolète	L’état de référence « officiel » date de 2022	On ne sait plus ce qui est correct
Silos équipes	Dev, Ops, Sécu travaillent séparément	Chacun modifie de son côté
Turnover	L’expert qui savait tout est parti	Connaissances perdues

Exemple concret — L’équipe sécurité demande l’ajout de règles firewall. L’équipe ops les applique manuellement « en attendant la prochaine release ». Un an plus tard, ces règles n’existent toujours pas dans le code. Personne ne sait pourquoi elles sont là.

Le cycle de gestion de la dérive

Gérer la dérive n’est pas un projet ponctuel qu’on coche et qu’on oublie. C’est un processus continu, comme la gestion de la dette technique ou la sécurité. Le cycle se répète en permanence : détecter, analyser, corriger, prévenir.

Étape 1 : Détecter — Comparer l’état réel à l’état de référence

La détection est la première ligne de défense. Elle consiste à identifier automatiquement les écarts entre l’état attendu (votre état de référence) et l’état réel des systèmes. Sans détection, vous naviguez à l’aveugle.

Infrastructure as Code

Si vous utilisez Terraform, Ansible ou Puppet, ces outils ont des fonctions de détection intégrées :

# Terraform : voir les différences entre état et réel
terraform plan

# Ansible : mode check (dry-run)
ansible-playbook site.yml --check --diff

# Puppet : mode noop
puppet agent --test --noop

Limitation : Ces outils ne voient que ce qu’ils gèrent. Une modification faite en dehors de l’outil reste invisible.

Outils de scan

Des outils spécialisés scannent l’état réel des systèmes :

Outil	Ce qu’il détecte	Type
AIDE, Tripwire	Changements de fichiers	On-premise
Snyk IaC	Drift cloud, ressources non gérées	Cloud
driftctl	Drift Terraform AWS/Azure/GCP	Open source
Spacelift	Drift IaC multi-cloud	SaaS

Ces outils détectent aussi les ressources « orphelines » non gérées par IaC.

Audit système

Pour les serveurs Linux, des outils d’audit comparent l’état à une baseline de sécurité :

# OpenSCAP : audit contre un état de référence CIS
oscap xccdf eval --profile cis \
  --results results.xml \
  /usr/share/xml/scap/ssg/content/ssg-rhel8-ds.xml

# Lynis : audit de sécurité
lynis audit system

OpenSCAP et Lynis génèrent des rapports montrant les écarts aux standards.

Étape 2 : Analyser — Comprendre avant de corriger

Ne corrigez jamais une dérive à l’aveugle ! Chaque dérive a une cause, et cette cause peut révéler un problème plus profond. Parfois, c’est l’état de référence lui-même qui doit évoluer.

Question à poser	Pourquoi c’est important
Qui a fait la modification ?	Identifier si c’est un problème de processus ou de compétence
Quand a-t-elle eu lieu ?	Corréler avec des incidents ou des déploiements
Pourquoi était-elle nécessaire ?	Peut révéler un problème que l’état de référence ne résout pas
Quel impact si on corrige ?	Éviter de casser quelque chose en « réparant »

Exemple : Vous détectez qu’un serveur a une règle firewall non standard. Avant de la supprimer, vérifiez qu’elle n’a pas été ajoutée pour bloquer une attaque en cours. Si c’est le cas, la bonne action est d’intégrer cette règle à l’état de référence, pas de la supprimer.

Étape 3 : Corriger — Rétablir ou faire évoluer

Une fois la cause comprise, deux choix s’offrent à vous. Le bon choix dépend de la nature de la dérive : était-ce une erreur ou une amélioration légitime ?

Option	Quand l’utiliser	Comment
Rétablir l’état de référence	La dérive était une erreur	Réappliquer le playbook, terraform apply
Mettre à jour l’état de référence	La dérive était une amélioration	Modifier l’IaC puis redéployer

Attention : Ne corrigez jamais en « bricolant » à la main. Vous ne feriez que créer une nouvelle dérive — un cercle vicieux. Toute correction doit passer par l’outil de gestion de configuration.

# ❌ Mauvais : correction manuelle
sudo systemctl enable nginx

# ✅ Bon : correction via l'outil (Ansible ici)
ansible-playbook -l serveur23 site.yml --tags nginx

Étape 4 : Prévenir — Empêcher la récidive

La meilleure dérive est celle qui ne se produit pas. La prévention est l’étape la plus importante — elle transforme un cycle de « pompier » en approche proactive.

1. Automatiser tout changement

   Si une modification doit être faite, elle doit être codifiée (IaC, playbook) et versionnée. Jamais de SSH pour « corriger vite ».

2. Détecter en continu

   Exécuter terraform plan ou un scan de drift quotidiennement, pas juste avant les déploiements. Alerter sur tout écart.

3. Bloquer les modifications manuelles

   Restreindre les accès SSH, utiliser des politiques IAM qui empêchent les modifications console sur les ressources gérées par IaC.

4. Documenter et former

   S’assurer que tout le monde comprend pourquoi la modification manuelle est interdite et comment faire correctement.

5. Tracer et auditer

   Logs d’accès, audit trail cloud. Si quelqu’un dévie, vous devez pouvoir le savoir.

Anti-patterns et bonnes pratiques

Il est facile de tomber dans certains pièges quand on gère la configuration. Cette section présente les erreurs les plus courantes et comment les éviter.

Les 10 erreurs les plus courantes

Ces anti-patterns sont observés dans la plupart des équipes. En les reconnaissant, vous pouvez les éviter :

Anti-pattern	Pourquoi c’est un problème	Que faire à la place
Modifications manuelles non documentées	Dérive invisible, pas de rollback	Tout passer par IaC
État de référence « implicite »	Personne ne sait ce qui est correct	Documenter et versionner
Détection uniquement avant déploiement	La dérive s’accumule entre-temps	Scan quotidien automatisé
Correction sans analyse	Risque de casser ce qui marchait	Comprendre avant d’agir
Documentation dans un wiki à part	Elle devient obsolète	État de référence = code versionné
Accès SSH/console pour tout le monde	Tentation de « corriger vite »	Principe du moindre privilège
Pas de responsable identifié	« C’est le problème de qui ? »	Owner par zone/service
État de référence trop complexe	Impossible à maintenir	Simplifier, modulariser
Ignorer les alertes de drift	« C’est normal, on verra plus tard »	SLA de correction (ex: 48h)
Corriger la dérive manuellement	Nouvelle dérive créée	Correction via l’outil

Le « Fix Forward » ou « Fix Backward » ?

Face à une dérive, deux philosophies s’affrontent. Le choix entre les deux dépend d’une question simple : la dérive était-elle une erreur ou une amélioration ?

Approche	Principe	Quand l’utiliser
Fix Backward	Rétablir l’état précédent (rollback)	La dérive a causé un problème
Fix Forward	Intégrer la modification à l’état de référence	La dérive était une amélioration

Règle pratique : si la dérive était intentionnelle et bénéfique, fix forward. Si elle était accidentelle ou problématique, fix backward.

Ne jamais corriger manuellement !

Quelle que soit l’approche choisie, ne corrigez jamais la dérive en vous connectant au serveur pour « arranger les choses ». Vous ne feriez que créer une nouvelle dérive. Passez toujours par vos outils de gestion de configuration (Ansible, Terraform, Puppet…).

Outils de détection par environnement

Infrastructure cloud (IaC)

Outil	Cloud	Points forts	Limites
terraform plan	Multi	Gratuit, intégré	Ne voit que le managed
driftctl	AWS, Azure, GCP	Open source, détecte les unmanaged	Projet archivé (intégré à Snyk)
Snyk IaC	Multi	Commercial, UI, couverture totale	Payant
Spacelift	Multi	Drift en temps réel, policies	Payant
Firefly	Multi	Découverte + codification auto	Payant

Serveurs Linux

Outil	Type	Points forts
AIDE	Détection changements fichiers	Léger, open source
Tripwire	Détection changements fichiers	Référence historique
OpenSCAP	Conformité SCAP/CIS	États de référence standards
Lynis	Audit sécurité	Facile à utiliser
OSSEC	HIDS avec détection de changements	Temps réel
** Rudder**	Gestion de configuration + drift	Interface web, reporting

Orchestration

Outil	Capacité
Ansible	--check --diff pour voir les écarts
Puppet	Agent détecte et corrige automatiquement
Chef	InSpec pour audit de conformité
SaltStack	Mode test=True pour dry-run

Mesurer la dérive

On ne peut pas améliorer ce qu’on ne mesure pas. Mesurer la dérive permet de savoir si la situation s’améliore ou se dégrade, et de justifier les investissements en outillage et formation.

Métriques à suivre

Ces indicateurs vous donnent une vision claire de votre « santé configuration » :

Métrique	Ce qu’elle mesure	Objectif	Pourquoi c’est important
Taux de conformité	% de ressources sans dérive	> 95%	L’indicateur principal : combien de vos systèmes sont conformes
MTTD (Mean Time To Detect)	Temps entre dérive et détection	< 24h	Plus vite vous détectez, moins la dérive s’accumule
MTTR (Mean Time To Remediate)	Temps entre détection et correction	< 48h	Mesure votre capacité à réagir
Ressources non gérées	Nombre de ressources hors IaC	Tendre vers 0	Le « shadow IT » que vous ne voyez pas
Récurrence	Dérives qui reviennent après correction	0	Si elle revient, vous n’avez pas traité la cause racine

Dashboard de suivi

Un bon dashboard de gestion de la dérive donne une vision d’ensemble en un coup d’œil. Il doit répondre à ces questions :

• Quelle est ma situation globale ? (taux de conformité)
• Où sont mes problèmes ? (environnements, systèmes concernés)
• Quelle est ma tendance ? (amélioration ou dégradation)
• Quelle est mon urgence ? (dérives critiques à traiter)

Ce type de dashboard peut être implémenté avec des outils comme Grafana, Datadog ou un simple tableau de bord interne. L’important est qu’il soit visible par toute l’équipe et mis à jour automatiquement.

Checklists opérationnelles

Checklist « Minimum viable »

Pour une équipe qui démarre la gestion de la dérive :

1. État de référence documenté

   Au minimum, un fichier décrivant la configuration attendue des serveurs critiques. Idéalement, du code IaC.

2. Détection hebdomadaire

   Exécuter un terraform plan ou un audit AIDE/OpenSCAP une fois par semaine minimum.

3. Processus de correction

   Savoir qui est responsable de corriger et sous quel délai.

4. Historique des écarts

   Conserver une trace de chaque dérive détectée et de sa correction.

5. Formation de base

   L’équipe sait pourquoi les modifications manuelles sont interdites.

Checklist « Organisation mature »

Pour une équipe qui veut industrialiser :

1. IaC à 100%

   Toute l’infrastructure est codifiée. Aucune ressource manuelle.

2. Détection continue

   Scan de drift automatisé quotidien, alertes en temps réel.

3. Blocage des modifications manuelles

   Policies IAM, accès SSH restreints, audit trail.

4. SLA de correction

   Critique : 4h. Haute : 24h. Moyenne : 48h. Basse : 1 semaine.

5. Métriques et reporting

   Dashboard de conformité, rapports hebdomadaires au management.

6. Revue post-incident

   Chaque dérive ayant causé un incident fait l’objet d’un postmortem.

7. Amélioration continue

   Rétrospectives régulières sur la gestion de la dérive.

À retenir

1. L’état de référence est votre source de vérité

   Sans état de référence clair, vous ne pouvez pas détecter la dérive. Documentez et versionnez l’état attendu de vos systèmes.

2. La dérive est inévitable

   Elle arrivera. Le problème n’est pas d’en avoir, c’est de ne pas la détecter. Automatisez la détection.

3. Détecter ≠ Corriger aveuglément

   Chaque dérive a une cause. Comprenez-la avant d’agir. Parfois, c’est l’état de référence qu’il faut mettre à jour.

4. Prévenir vaut mieux que guérir

   Automatisez les changements, bloquez les modifications manuelles, formez les équipes. Une dérive évitée coûte moins cher qu’une dérive corrigée.

5. Infrastructure as Code est votre meilleur allié

   Un système géré par IaC est plus facile à auditer, corriger et reproduire qu’un système configuré manuellement.

6. Mesurez pour progresser

   Taux de conformité, MTTD, MTTR. Ce qui se mesure s’améliore.

Liens utiles

Ces guides complètent votre compréhension de la gestion de configuration :

• Patch management — Appliquer les correctifs sans créer de dérive

Références externes

Articles fondateurs

• Configuration Drift ↗ — HashiCorp explique le concept et comment Terraform aide à le gérer
• Infrastructure as Code ↗ — Martin Fowler sur l’IaC comme solution à la dérive
• Cattle vs Pets ↗ — Le concept fondateur : serveurs jetables vs serveurs précieux

Guides pratiques

• How to Detect and Prevent Configuration Drift ↗ — Snyk, guide complet avec outils et méthodologie
• Managing Infrastructure Drift ↗ — Spacelift, bonnes pratiques et intégration CI/CD
• CIS Benchmarks ↗ — Center for Internet Security, états de référence de sécurité standards (voir aussi notre guide CIS Benchmarks)

Standards et frameworks

• NIST SP 800-128 ↗ — Guide for Security-Focused Configuration Management
• CIS Controls ↗ — Control 4 : Secure Configuration of Enterprise Assets
• ISO 27001 ↗ — Annexe A.12.5 : Control of operational software

Outils open source

• driftctl ↗ — Détection de drift pour Terraform (maintenu par Snyk)
• AIDE ↗ — Advanced Intrusion Detection Environment
• OpenSCAP ↗ — Audit de conformité contre états de référence SCAP
• Lynis ↗ — Outil d’audit de sécurité Linux