Qu'est-ce que l'idempotence ?
L'idempotence est une propriete mathematique appliquee a l'informatique : une operation est idempotente si l'executer une fois ou plusieurs fois produit le meme resultat. Par exemple, definir une variable a la valeur 5 est idempotent (peu importe combien de fois on le fait, la valeur est 5). Incrementer un compteur n'est pas idempotent (chaque execution change le resultat).
Idempotence dans les API REST
Les methodes HTTP ont des proprietes d'idempotence definies : GET (idempotent, lecture seule), PUT (idempotent, remplace une ressource), DELETE (idempotent, supprimer une ressource deja supprimee ne change rien), PATCH (pas garanti idempotent, selon l'implementation), POST (pas idempotent, cree une nouvelle ressource). L'idempotence est cruciale pour la fiabilite : si un client envoie un PUT et ne recoit pas de reponse (timeout), il peut re-envoyer la requete en toute securite.
Implementation de l'idempotence
Pour rendre les operations POST idempotentes, la technique principale est la cle d'idempotence : le client genere un identifiant unique (UUID) et l'envoie dans un header (Idempotency-Key). Le serveur verifie si cette cle a deja ete traitee : si oui, il retourne la reponse originale sans re-executer l'operation. Stripe, PayPal et la plupart des API de paiement utilisent ce mecanisme. Le stockage des cles (Redis avec TTL) permet de gerer l'expiration.
Idempotence dans les systemes distribues
Dans les architectures distribuees et les systemes de messaging, l'idempotence est essentielle car les messages peuvent etre delivres plusieurs fois (at-least-once delivery). Les consumers doivent etre idempotents : traiter le meme message deux fois ne doit pas creer de doublon. Techniques : cle de deduplication, upsert (INSERT ON CONFLICT UPDATE) en base de donnees, verification d'etat avant action. Les systemes de paiement, les files de commandes et les pipelines de donnees doivent etre idempotents par conception.
Idempotence dans l'infrastructure
Les outils de configuration comme Ansible, Terraform et Kubernetes sont idempotents par design. Executer un playbook Ansible deux fois ne reinstalle pas un package deja present. Appliquer un manifest Kubernetes deux fois ne cree pas de doublon. Cette propriete rend les outils surs a re-executer et permet le pattern "desired state" : decrire l'etat souhaite et laisser l'outil converger vers cet etat.