Qu'est-ce que l'idempotence ?
L'idempotence est une propriété mathematique appliquee à l'informatique : une opération est idempotente si l'exécuter une fois ou plusieurs fois produit le même résultat. Par exemple, définir une variable à 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 exécution change le résultat).
Idempotence dans les API REST
Les méthodes HTTP ont des propriétés d'idempotence définies : GET (idempotent, lecture seule), PUT (idempotent, remplace une ressource), DELETE (idempotent, supprimer une ressource déjà supprimee ne change rien), PATCH (pas garanti idempotent, selon l'implémentation), POST (pas idempotent, cree une nouvelle ressource). L'idempotence est cruciale pour la fiabilité : si un client envoie un PUT et ne reçoit pas de réponse (timeout), il peut re-envoyer la requête en toute sécurité.
Implémentation de l'idempotence
Pour rendre les opérations 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 vérifie si cette cle a déjà été traitee : si oui, il retourne la réponse originale sans re-executer l'opération. Stripe, PayPal et la plupart des API de paiement utilisent ce mécanisme. Le stockage des clés (Redis avec TTL) permet de gérer l'expiration.
Idempotence dans les systèmes distribues
Dans les architectures distribuees et les systèmes de messaging, l'idempotence est essentielle car les messages peuvent être delivres plusieurs fois (at-least-once delivery). Les consumers doivent être idempotents : traiter le même message deux fois ne doit pas créer de doublon. Techniques : cle de deduplication, upsert (INSERT ON CONFLICT UPDATE) en base de données, vérification d'état avant action. Les systèmes de paiement, les files de commandes et les pipelines de données doivent être idempotents par conception.
Idempotence dans l'infrastructure
Les outils de configuration comme Ansible, Terraform et Kubernetes sont idempotents par design. Exécuter un playbook Ansible deux fois ne reinstalle pas un package déjà présent. Appliquer un manifest Kubernetes deux fois ne cree pas de doublon. Cette propriété rend les outils surs a re-executer et permet le pattern "desired state" : décrire l'état souhaite et laisser l'outil converger vers cet état.