IDEMPOTENCE
Infrastructure
Propriété d'une opération qui produit le même état final qu'on l'exécute une fois ou dix : la rejouer après un plantage, une coupure ou une reprise ne change plus rien au système.
Une clé stable : Chaque action porte une clé qui ne varie pas d'une exécution à l'autre (identifiant d'alerte et type d'action, par exemple). Un registre d'état consulté avant d'agir dit si cette clé a déjà été traitée.
Décrire un état, pas un geste : « L'hôte doit être isolé » est idempotent, « basculer l'isolement » ne l'est pas. On vérifie donc l'état réel de la cible : demander l'isolement d'un hôte déjà isolé doit être un non-événement.
Condition des reprises : On ne réessaie automatiquement que ce qui est idempotent ; une action qui ne l'est pas exige une clé ou une vérification avant chaque nouvelle tentative. Vingt ans d'astreinte apprennent qu'un script relancé « juste pour voir » finit toujours par ouvrir le même ticket en quarante exemplaires, ce qui garantit au moins que l'un d'eux sera lu.
Ce qu'elle ne fournit pas : L'idempotence n'apporte pas l'atomicité : entre l'action et son inscription au registre, le script peut mourir. Un verrou reste nécessaire contre deux exécutions concurrentes de la même tâche.
Ce qui arrive si on s'en passe
Sans idempotence, rejouer une opération après un plantage, une coupure ou une reprise ne ramène pas le système au même état : chaque nouvelle exécution s'ajoute à la précédente. Un paiement relancé après un délai d'attente peut être débité deux fois. Un script de migration interrompu puis relancé peut dupliquer des lignes ou échouer sur un objet déjà créé. Une règle de pare-feu peut être insérée en double. La reprise devient un pari : faute de savoir si la première tentative a abouti, l'opérateur doit choisir entre ne rien relancer (et laisser un état incomplet) ou relancer (et risquer un doublon). Côté sécurité, une requête interceptée puis renvoyée telle quelle produit de nouveau son effet lorsqu'aucun identifiant unique ne permet de la reconnaître. Les journaux accumulent alors des effets répétés qu'il faut démêler à la main.
Explication de la marmotte
Pense au bouton d'appel d'un ascenseur. Tu appuies une fois, l'ascenseur arrive. Tu appuies dix fois parce que tu es pressé : il arrive quand même une seule fois. Appuyer encore ne change rien au résultat. C'est exactement cette idée. Pour un programme, c'est précieux : s'il s'arrête au milieu de son travail et qu'on le relance, il ne doit pas refaire deux fois la même chose, comme envoyer deux fois une commande ou payer deux fois la même facture. Avant d'agir, il regarde donc ce qui est déjà fait, et il ne touche à rien si le travail est terminé.