L’idempotence, la convergence et la dérive décrivent trois comportements différents d’un système d’automatisation. L’idempotence dit qu’une relance ne change rien si l’état attendu est déjà atteint. La convergence dit qu’un système se rapproche de l’état voulu à chaque exécution. La dérive décrit l’écart entre l’état attendu et l’état réel. Si vous mélangez ces notions, vous aurez du mal à comprendre ce que produit vraiment votre code d’infrastructure quand vous le relancez.
Ces trois repères sont essentiels parce qu’une pratique IaC ne se juge pas seulement sur sa capacité à créer des ressources une fois. Elle se juge surtout sur sa capacité à tenir dans le temps, malgré les incidents, les changements manuels et les relances répétées.
Ce que vous allez apprendre
Section intitulée « Ce que vous allez apprendre »- distinguer clairement idempotence, convergence et dérive ;
- comprendre pourquoi ces notions comptent dans tous les projets IaC ;
- savoir réduire les écarts entre état attendu et état réel.
Définitions simples
Section intitulée « Définitions simples »| Notion | Question utile | Ce que cela signifie |
|---|---|---|
| Idempotence | ”Si je relance, que se passe-t-il ?” | Si l’état attendu est déjà atteint, la relance ne modifie rien inutilement. |
| Convergence | ”Est-ce que le système se rapproche du bon état ?” | Chaque exécution pousse l’infrastructure vers l’état voulu, même après un écart. |
| Dérive | ”Le réel correspond-il encore au prévu ?” | Un écart apparaît entre la définition attendue et ce qui existe réellement. |
Vu comme une relance dans le temps, le trio se lit simplement ainsi :
Un scénario simple pour bien les distinguer
Section intitulée « Un scénario simple pour bien les distinguer »Imaginez un serveur web qui doit contenir un fichier de configuration précis, écouter sur le bon port et garder un service actif.
- si vous relancez l’automatisation et qu’elle ne modifie rien parce que tout est déjà correct, vous observez de l’idempotence ;
- si quelqu’un modifie le fichier à la main et qu’une relance le remet dans l’état prévu, vous observez la convergence ;
- si le fichier modifié à la main n’est plus conforme à ce que décrit le dépôt, vous avez de la dérive.
Ce trio se comprend mieux avec ce fil rouge qu’avec une définition abstraite. Dans la vraie vie, les trois notions apparaissent souvent sur le même périmètre.
Pourquoi ce trio est central
Section intitulée « Pourquoi ce trio est central »Dans un projet IaC, on relance souvent les automatisations : après un changement, après un incident, après une revue, ou simplement pour vérifier que tout reste aligné. Sans idempotence, une relance peut casser ce qui fonctionnait déjà. Sans convergence, le système peut exécuter des actions sans vraiment se rapprocher de l’objectif. Et sans gestion de la dérive, l’infrastructure finit par ne plus ressembler à ce que le dépôt décrit.
Un exemple concret
Section intitulée « Un exemple concret »Imaginez un serveur web qui doit contenir un fichier de configuration précis et exposer un service actif.
- si l’automatisation est idempotente, la relancer quand tout est déjà correct ne doit pas tout réécrire ou redémarrer inutilement ;
- si elle est convergente, elle doit corriger l’écart quand le fichier a été modifié à la main ;
- s’il y a dérive, cela signifie qu’entre votre définition et le système réel, quelque chose ne correspond plus.
La pratique saine consiste donc à viser des traitements qui reconnaissent l’état existant, corrigent l’écart utile et évitent les effets de bord inutiles.
Ce que l’on voit selon les cas
Section intitulée « Ce que l’on voit selon les cas »| Situation observée | Ce que cela révèle |
|---|---|
| Une relance ne change rien quand tout est déjà bon | Bonne idempotence |
| Une relance corrige un écart manuel | Bonne convergence |
| L’infrastructure ne correspond plus au dépôt | Présence de dérive |
| Une relance recrée des changements inutiles | Idempotence faible ou logique mal cadrée |
Ce que la dérive recouvre vraiment
Section intitulée « Ce que la dérive recouvre vraiment »On réduit souvent la dérive à “quelqu’un a changé un paramètre à la main”. C’est fréquent, mais ce n’est pas le seul cas.
La dérive peut venir :
- d’une modification manuelle dans une console ou sur un serveur ;
- d’un autre outil d’automatisation qui agit sur le même périmètre ;
- d’un incident qui supprime ou altère une ressource ;
- d’un changement partiel qui a été appliqué sans mise à jour du dépôt ;
- d’une définition devenue incomplète par rapport au réel.
Exemple très fréquent
Section intitulée « Exemple très fréquent »Une équipe ouvre temporairement un port dans une console cloud pour dépanner un accès urgent. Le service repart, mais le dépôt n’est pas mis à jour. Quelques semaines plus tard, personne ne sait plus si cette ouverture était volontaire, oubliée, ou déjà corrigée ailleurs. C’est une forme classique de dérive : le réel continue de vivre, mais la source de vérité n’a pas suivi.
Ce que ces notions ne veulent pas dire
Section intitulée « Ce que ces notions ne veulent pas dire »Quelques confusions reviennent souvent.
- Idempotent ne veut pas dire “parfaitement sans risque”.
- Convergent ne veut pas dire “instantané”.
- Sans changement au dernier run ne veut pas dire “il n’y aura jamais de dérive”.
- Automatisé ne veut pas dire “protégé contre les actions manuelles hors processus”.
L’objectif n’est donc pas la pureté théorique, mais un système assez robuste pour être relancé sans surprise majeure et assez lisible pour repérer les écarts.
Comment repérer un problème dans la pratique
Section intitulée « Comment repérer un problème dans la pratique »Vous avez probablement un souci d’idempotence, de convergence ou de dérive si :
- les mêmes relances produisent sans cesse des changements inattendus ;
- l’équipe hésite avant de relancer par peur de casser l’existant ;
- des écarts sont découverts longtemps après un changement manuel ;
- deux outils agissent sur le même périmètre sans frontière claire ;
- personne ne sait dire si le dépôt reflète encore la réalité.
Réduire la dérive au quotidien
Section intitulée « Réduire la dérive au quotidien »Les pratiques les plus utiles sont simples :
- éviter les modifications hors code sur le périmètre géré ;
- séparer clairement les responsabilités entre outils ;
- relire les changements avant exécution ;
- exécuter régulièrement les plans, vérifications ou contrôles adaptés ;
- conserver un périmètre de gestion explicite ;
- documenter les exceptions au lieu de les laisser implicites.
Pourquoi ces notions comptent avant le choix d’un outil
Section intitulée « Pourquoi ces notions comptent avant le choix d’un outil »Beaucoup de débats sur les outils deviennent plus clairs quand on revient à ces trois notions. Le vrai sujet n’est pas seulement la syntaxe ou la popularité d’un produit. Il faut surtout comprendre comment l’outil raisonne sur l’état, comment il corrige un écart et ce qui se passe quand on relance.
À retenir
Section intitulée « À retenir »- L’idempotence permet de relancer sans provoquer de changements inutiles quand l’état attendu est déjà atteint.
- La convergence mesure la capacité d’un système à revenir vers l’état voulu.
- La dérive est l’écart entre ce que le code décrit et ce qui existe réellement.
- Une pratique IaC saine cherche à détecter les écarts tôt et à limiter les actions manuelles hors processus.
- Ces notions comptent autant que le choix d’un outil, car elles déterminent la fiabilité dans la durée.