Inutile de spammer ce bouton d'ascenseur.

Imaginez que vous attendez un ascenseur au rez-de-chaussée d'un immeuble. Vous êtes en retard, et nerveusement, vous appuyez plusieurs fois sur le bouton d'appel. Est-ce que trois ascenseurs vont arriver ? Bien sûr que non !

C'est exactement ce qu'est l'idempotence en informatique, un concept fondamental qui garantit qu'effectuer une même action plusieurs fois ne produit le même résultat qu'une seule fois.

Ce principe, né des mathématiques du 19 ème siècle avec les travaux d'un certain Benjamin Peirce, est aujourd'hui l'un des piliers qui maintiennent la stabilité du web. Sans lui, vous pourriez par exemple être facturé plusieurs fois pour le même achat en ligne, ou voir vos données corrompues à cause d'un simple timeout réseau.

Pourquoi cette propriété apparemment anodine révolutionne la façon dont nous concevons les systèmes informatiques, et comment elle résout des problèmes que vous n'imaginez même pas rencontrer au quotidien ?

Au-delà de ces analogies quotidiennes, l'idempotence cache en fait une sophistication technique assez remarquable. Elle représente un pont entre théorie mathématique et ingénierie, permettant de construire des applications robustes dans un monde où les pannes réseau et les retries sont de plus en plus inévitables.

D'une idée mathématique à une révolution informatique.

L'histoire commence en 1870, quand Benjamin Peirce, mathématicien américain à Harvard, invente le terme "idempotent" dans son œuvre Linear Associative Algebra. Le mot vient en fait du latin "idem" qui signifie même et "potence" qui signifie puissance, signifiant donc littéralement "de même puissance". Sans entrer en profondeur dans les détails mathématiques qui, très honnêtement, me dépasse légèrement, Peirce travaillait sur un objectif précis : classifier tous les éléments mathématiques qui restent identiques lorsqu'on les élève à n'importe quelle puissance entière positive.

Ce qui rend cette histoire fascinante au delà de l'aspect mathématique, c'est que Peirce n'avait évidemment aucune idée que son concept mathématique deviendrait crucial pour l'informatique plus d'un siècle plus tard. Il publiait modestement ses travaux en seulement 100 copies qu'il distribuait aux mathématiciens du monde entier, car l'Académie nationale des sciences manquait de budget pour l'impression.

Quand l'informatique adopte l'idempotence.

Le passage des mathématiques vers l'informatique s'est cependant fait graduellement dans les années 1990-2000, avec l'émergence du Web. Les informaticiens ont réalisé que l'idempotence résolvait un problème fondamental. Que dans un monde où les connexions réseau peuvent échouer n'importe quand, il fallait garantir qu'une opération ne s'exécute qu'une seule fois, même si elle est demandée plusieurs fois.

L'idempotence d'un point de vue informatique élargit cependant quelque peu la définition mathématique. Une opération est idempotente si plusieurs exécutions identiques ont le même effet sur l'état du système qu'une seule exécution. Cette nuance est cruciale car elle concerne un état finalement observable du système, et non pas nécessairement la réponse réellement reçue à chaque fois.

Si vous demandez à votre banque en ligne de connaître le solde de cotre compte (une opération de lecture finalement), peu importe combien de fois vous posez la question, votre solde ne change pas et vous obtenez la même réponse. C'est idempotent. En revanche, si vous demandez à transférer 50€ vers un ami, répéter cette opération plusieurs fois viderait votre compte ! Ce n'est pas idempotent.

L'analogie de l'interrupteur qui illumine tout.

Avec l'interrupteur électrique de votre salon, deux types de commandes sont possibles, et une seule est idempotente.

La première possibilité est que vous avez deux boutons distincts, Allumer et Éteindre. Si la lumière est déjà allumée et que vous appuyez sur Allumer, rien ne change. Elle reste allumée. Même chose si elle est éteinte et que vous appuyez sur Éteindre. Ce type de configuration d'interrupteur est idempotente car l'état final ne dépend pas du nombre d'actions répétées, mais uniquement de la dernière commande donnée.

La seconde possibilité est que vous avez un unique bouton Toggle qui alterne entre les états allumé et éteint à chaque pression. Ici, le nombre de pressions change tout. Une fois allume, deux fois éteint, trois fois allume, etc... Cette configuration n'est pas idempotente car le résultat dépend directement du nombre d'exécutions.

Cette distinction se retrouve partout dans ce que vous utilisez.

Le bouton Play de votre lecteur vidéo ? Idempotent (S'il y a un bouton stop dédié, et non pas un même bouton permettant le lancement et l'arrêt d'une vidéo.). Appuyer plusieurs fois ne relance pas la vidéo plus vite. Le bouton de volume + ? Non idempotent, chaque pression augmente le son.

La révolution des méthodes HTTP.

Le protocole HTTP, colonne vertébrale du Web, a formalisé l'idempotence dans ses spécifications officielles. Chaque méthode HTTP a été soigneusement conçue avec une sémantique précise concernant l'idempotence.

GET (récupérer des données) est parfaitement idempotente. Demander 100 fois la page d'accueil de votre site préféré n'affecte pas le serveur et retourne le même contenu.

PUT (remplacer complètement) est idempotente... mais pas sûre. Si vous envoyez 10 fois l'instruction "remplacer les informations de l'utilisateur 123 par { nom: 'Alice', email: 'alice@example.com' }", le résultat final sera identique à un seul envoi. L'utilisateur 123 aura ces informations, point. PUT écrase complètement la ressource par la nouvelle version fournie.

DELETE (supprimer) est idempotente... mais de manière subtile. La première demande de suppression de l'utilisateur 123 retourne "200 OK - Supprimé". Les suivantes retournent "404 Not Found - N'existe plus". Les réponses diffèrent mais l'état du serveur reste identique. L'utilisateur 123 n'existe plus. C'est ça, l'idempotence en informatique.

POST (créer ou traiter) est la brebis galeuse du groupe. POST n'est délibérément pas idempotent car il est conçu pour créer de nouvelles ressources ou déclencher des traitements. Envoyer 5 fois "créer un nouvel utilisateur avec {nom: 'Bob'}" pourrait créer 5 utilisateurs différents nommés Bob, chacun avec un identifiant unique.

PATCH (modifier partiellement) est le cas complexe. Il peut être rendu idempotent selon son implémentation. Si vous demandez "changer l'email en alice@example.com", c'est idempotent. Si vous demandez "incrémenter le compteur de connexions", ça ne l'est plus.

Les drames cachés du quotidien.

Vous ne vous en rendez probablement pas compte, mais l'absence d'idempotence provoque des incidents quotidiens qui affectent des millions de personnes. Les cas les plus spectaculaires touchent au domaine financier, où les conséquences sont immédiatement visibles et très douloureuses de par la sensibilité de ce secteur.

Imaginez encore une fois que vous achetez un livre à 20€ sur un site e-commerce. Votre connexion Wifi est instable et la page met du temps à charger après avoir cliqué sur Payer. Impatient, vous cliquez une nouvelle fois pensant que c'est la solution pour débloquer la situation. Sans idempotence, vous pourriez être facturé deux fois 20€, alors que le marchand n'a reçu finalement qu'un seul paiement. Vous voilà avec 40€ débités, une dispute avec votre banque, et un vendeur perplexe.

Ce scénario est d'ailleurs si fréquent que Stripe, l'un des leaders du paiement en ligne, a fait de l'idempotence une fonctionnalité centrale de son API. Leur documentation consacre des sections entières à expliquer comment leurs clés d'idempotence protègent et évitent aux marchands et acheteurs des accidents de ce type.

Les systèmes informatiques actuels communiquent constamment entre eux. Un simple timeout peut déclencher des retries automatiques qui, sans idempotence, transforment un micro-incident en catastrophe. Il y a encore seulement quelques années, AWS (Amazon Web Services) a subi une panne majeure d'un de ses services après qu'une commande mal saisie ait supprimé plus de serveurs que prévu. Les services dépendants ont tenté de se reconnecter en masse, mais se faisant ont créer un problème de surcharge que l'on nomme d'ailleurs un problème de ruée sauvage (ou thundering herd) qui n'a fait qu'aggravé et prolongé encore plus la panne.

L'idempotence aurait permis aux services de retenter leurs connexions en toute sécurité, sans aggraver la situation. À la place, chaque retry a ajouté de la charge sur des systèmes déjà surchargés.

L'art de l'idempotence.

Face à ces défis, l'industrie a développé des patterns d'implémentation qui transforment des opérations naturellement non-idempotentes en opérations sûres.

Comme dit précédemment, Stripe a popularisé le concept de clé d'idempotence. Elles sont basiquement un identifiant unique que le client génère et joint à sa requête. Si le serveur reçoit plusieurs requêtes avec la même clé, il retourne le résultat de la première exécution sans réexécuter l'opération.

Première requête :
POST /paiements
Idempotency-Key: 550e8400-e29b-41d4-a716-446655440000
montant=2000&devise=EUR
→ Traitement normal, création du paiement, réponse "200 OK"

Deuxième requête identique (retry après timeout) :
POST /paiements  
Idempotency-Key: 550e8400-e29b-41d4-a716-446655440000
montant=2000&devise=EUR
→ Clé déjà vue, retour de la réponse précédente "200 OK"

Cette approche transforme la nature première du POST non-idempotent en une opération effectivement idempotente.

Une technique encore plus robuste consiste à concevoir les opérations comme des transitions dans une machine à états.

Un paiement suit par exemple typiquement une séquence Créé → Autorisé → Capturé → Finalisé. Demander plusieurs fois de passer de Autorisé à Capturé n'a d'effet que la première fois. Les tentatives suivantes sont ignorées car le paiement est déjà dans l'état Capturé.

Cette approche garantit l'idempotence par construction plutôt que par ajout de mécanismes externes.

Avant d'exécuter une action, vérifiez si elle est nécessaire. Avant de supprimer un utilisateur, vérifiez s'il existe encore. Avant de créer un compte, vérifiez qu'il n'existe pas déjà. Cette approche, elle, transforme des opérations potentiellement destructives en opérations conditionnelles et donc idempotentes.

L'écosystème des objets idempotents du quotidien.

Une fois que vous comprenez le principe d'idempotence, vous commencez à le voir partout dans votre environnement quotidien.

Comme énoncé dans l'analogie d'ouverture, le bouton d'appel d'ascenseur est un chef-d'œuvre d'ingénierie idempotente. Il enregistre une demande (quelqu'un veut monter ou descendre à cet étage) sans se soucier du nombre de pressions. Le système d'ascenseur traite cette demande exactement une fois.

Imaginez un peu l'alternative non-idempotente. Chaque pression appellerait une cabine d’ascenseur supplémentaire. En heures de pointe, vous auriez 20 ascenseurs qui arrivent simultanément ! Cette conception serait dangereuse, inefficace et frustrante. Pour dire vrai, elle serait même impossible et irréalisable. Si on y pense bien, La LED souvent présente sur le bouton d'ascenseur fournit même un feedback visuel de l'idempotence. Elle s'allume au premier appui (demande enregistrée) et reste allumée malgré les pressions répétées, jusqu'à ce que la demande soit satisfaite.

Le bouton pour traverser au feu rouge fonctionne sur le même principe. Il enregistre votre intention de traverser et l'intègre dans le cycle suivant des feux. Appuyer frénétiquement ne change rien, vous traverserez simplement au prochain cycle vert, ni plus tôt ni plus tard. Encore une fois, cette idempotence évite bien des maux que créerait un système non-idempotent où chaque pression prolongerait le feu vert piéton mais créerait forcément des embouteillages pour les voitures.

Enfin, votre télécommande de garage a elle aussi deux approches possibles. La conception moderne privilégie l'idempotence. Un bouton Ouvrir et un bouton Fermer. Appuyer sur Ouvrir quand c'est déjà ouvert n'a aucun effet. Cette approche évite les accidents, vous ne risquez pas de refermer par inadvertance en pensant ouvrir. Les anciennes conceptions avec un seul bouton Toggle était non-idempotente et plus dangereuse. En cas de doute sur l'état actuel, vous risquiez l'inverse de ce que vous vouliez.

Nuances et subtilités de l'implémentation.

L'idempotence informatique révèle sa sophistication dans ses détails d'implémentation. Plusieurs nuances distinguent l'idempotence pratique de la définition purement mathématique de son inventeur.

Ce que l'on appelle l'idempotence forte exige que tout soit strictement identique à chaque exécution. Pas de logs supplémentaires, pas de métadonnées modifiées, pas de compteurs incrémentés. C'est l'idéal mathématique. La pureté théorique.

L'idempotence dite faible, elle, se contente que l'état fonctionnel soit identique. Vous pouvez logger chaque tentative, mettre à jour un timestamp, ou incrémenter un compteur de vues. L'important est que le résultat métier, le résultat observable reste le même.

La plupart des systèmes réels implémentent l'idempotence faible. Quand vous rechargez une page web, elle peut mettre à jour ses statistiques de visite tout en restant fonctionnellement idempotente.

Un piège classique concerne les champs "updated_at" automatiques. Si votre base de données met à jour automatiquement un timestamp à chaque modification, alors une opération PUT identique produit techniquement des résultats différents à chaque fois. Est-ce que ça viole l'idempotence ? La réponse pragmatique est non. Encore une fois, l'idempotence d'un point de vue informatique concerne l'état fonctionnel observable par l'utilisateur, pas les métadonnées internes. Un utilisateur mis à jour garde le même nom et email, même si le timestamp système change.

Beaucoup d'applications modernes utilisent aussi le concept de soft delete. Au lieu de supprimer physiquement une donnée, on la marque comme supprimée. Cette approche facilite l'idempotence de DELETE car la ressource existe toujours techniquement, elle est juste marquée comme supprimée. Première suppression, mise à jour du champ. Suppressions suivantes, aucun changement, la ressource est déjà marquée comme supprimée. L'état final est identique pour l'utilisateur.

L'architecture des systèmes distribués modernes.

Dans l'ère des microservices et du cloud computing dans laquelle nous résidons désormais, l'idempotence devient un pilier architectural finalement non-négociable. Les systèmes distribués, bien qu'offrant de merveilleux avantages, amplifient forcément toutes les problèmatiques réseau.

Les transactions dans les architectures distribuées utilisent souvent un pattern que l'on nomme très simplement Saga.

C'est le principe d'une séquence d'opérations avec des actions de compensation en cas d'échec. Chaque étape d'une saga doit être idempotente pour permettre les retries. Plus crucial encore, les actions de compensation doivent elles aussi être idempotentes.

Par exemple, réserver un voyage nécessite de débiter la carte pour payer, de réserver l'hôtel pour loger, et de réserver l'avion pour se rendre à la destination désirée. Mais si l'étape avion échoue, la compensation doit annuler l'hôtel et rembourser la carte car elles n'ont plus lieu d'être. Ces compensations doivent être re-lançable si nécessaire sans risquer de rembourser plusieurs fois ou d'annuler des réservations déjà annulées.

Les limites philosophiques de l'idempotence.

Malgré son utilité, l'idempotence a des limites fondamentales qui sont relatives à la complexité de notre monde informatique actuel.

L'idempotence et le temps ont par exemple une relation compliquée, conflictuelle. En effet, demander l'heure actuelle (GET /api/time) est-il idempotent ? Mathématiquement non, car chaque appel retourne une valeur différente vu que du temps s'est ecoulé entre deux appels. En pratique cependant, c'est considéré idempotent car l'opération elle-même ne modifie pas l'état du serveur.

Encore une fois, cette subtilité révèle que l'idempotence informatique est plus pragmatique que mathématique. Elle concerne la stabilité du système plutôt que l'identité parfaite des résultats.

Nos systèmes aujourd'hui sont aussi conditionné pour tracer au maximum des métriques, des traces, des audits, etc... Mais ces logs sont-ils aussi des effets de bord qui violent l'idempotence ? Si chaque requête génère une ligne de log supplémentaire, alors répéter une requête change l'état du système car elle ajoute de nouveaux logs.

La vérité est qu'il semble être admis assez majoritairement dans le domaine de l'informatique que les effets de bord dit d'observabilité ne comptent pas pour l'idempotence. Ils sont considérés comme externes à la logique métier. Cette décision pragmatique permet d'avoir le meilleur des deux mondes : systèmes observables ET idempotents.

L'idempotence, notre ange silencieux.

L'idempotence représente un cas où une abstraction mathématique résout élégamment des problèmes pratiques majeurs. De la définition de Benjamin Peirce en 1870 aux architectures cloud d'aujourd'hui, ce concept a traversé pas moins de 150 ans d'évolution technologique en restant tout aussi pertinent.

"Faire plusieurs fois la même chose a le même effet que le faire une seule fois"

L'idempotence améliore votre expérience quotidienne d'utilisateur de manière invisible.

Dans un monde informatique de plus en plus complexe et distribué, l'idempotence n'est plus un luxe mais une nécessité. Elle permet de construire des systèmes robustes qui fonctionnent bien même quand les choses vont mal. Et en informatique, les choses vont toujours mal de temps en temps.

La prochaine fois que vous appuierez nerveusement plusieurs fois sur le bouton d'ascenseur, souriez. Vous expérimentez 150 ans d'évolution conceptuelle, une idée simple qui rend le monde pourtant plus prévisible et plus sûr.