Idempotence des agents IA en assurance : reprendre sans créer de doublons

Considérons une situation hypothétique dans un service de gestion en assurance. Un agent IA prépare une demande de justificatif, les contrôles prévus la valident et le connecteur transmet le message. La réponse du prestataire n’arrive pas avant le délai fixé. L’agent reprend le travail et envoie une seconde demande.

Il n’a pas nécessairement mal compris le dossier. La panne se situe entre l’action et la connaissance de son résultat. Pour le destinataire, le problème est pourtant concret : deux demandes peuvent laisser croire que la première pièce n’a pas été reçue, multiplier les réponses ou déclencher un appel au gestionnaire.

L’idempotence sert à organiser cette reprise : répéter une commande protégée doit conserver l’effet attendu d’une seule exécution, dans un périmètre défini. Le sujet concerne les reprises ordinaires, les appels concurrents et les réponses perdues. Il commence dès qu’un assistant est autorisé à créer une tâche, transmettre une demande ou modifier un état métier.

Le délai est dépassé : que sait réellement le système ?

Après un appel sans réponse, plusieurs histoires restent possibles. La requête n’a jamais atteint le service. Elle est arrivée et attend son traitement. Elle a été exécutée, mais l’accusé de réception s’est perdu. Elle a produit une partie des effets d’une opération composée. Le même message technique, « délai dépassé », recouvre donc des situations métier différentes.

La règle de départ est de conserver cette incertitude. Le statut « inconnu » décrit ce que l’on sait de l’effet, tandis que « tentative expirée » décrit le déroulement d’un appel. Transformer automatiquement le second en « action non réalisée » ouvre la porte aux doublons.

La RFC 9110, section 9.2.2, définit l’idempotence par l’effet voulu de requêtes identiques. Elle n’impose pas des réponses identiques ni l’absence de nouvelles traces. Elle déconseille de répéter automatiquement une requête non idempotente sans connaître une sémantique qui le permet ou pouvoir détecter sa non-application.

Une requête de création envoyée en POST peut donc disposer d’un contrat applicatif de reprise. Il faut lire ce contrat et vérifier son application par le connecteur. Le seul choix d’une méthode HTTP, d’une file de messages ou d’un framework d’agents ne décrit pas toutes les conséquences métier d’une commande.

Décision, commande, tentative et effet : quatre objets à séparer

Dans un parcours agentique, le raisonnement est susceptible de varier. Si l’on relance le modèle après une panne, il peut modifier la liste des pièces, choisir un autre destinataire ou créer une tâche supplémentaire. Cette nouvelle proposition doit suivre son propre parcours de validation. Elle ne constitue pas une répétition fidèle de ce qui avait été autorisé.

Une architecture de reprise exploitable sépare quatre objets :

1. La décision validée : demander une pièce précise pour une étape identifiée du dossier, sur la base d’un contexte et de contrôles enregistrés.
2. La commande : traduire cette décision en une action déterminée, avec sa cible, son contenu figé, sa version et son identifiant.
3. La tentative : appeler le service chargé d’exécuter cette commande. Chaque tentative possède son propre identifiant technique.
4. L’effet observé : retrouver la tâche effectivement créée, le message accepté ou l’état enregistré dans le système qui fait autorité.

Une décision peut entraîner plusieurs commandes : créer une tâche et notifier son propriétaire, par exemple. Chacune appelle une protection adaptée à son effet. Le succès de la création ne permet pas de déclarer la notification réussie ; l’échec de la notification ne justifie pas de recréer la tâche.

Cette séparation est une recommandation d’architecture à adapter au processus. Elle évite de demander au modèle de reconstituer, à partir de son historique conversationnel, ce qui a probablement déjà été fait. À la reprise, le système relit la commande conservée et son état ; il ne réinvente pas l’action.

Quatre notions à distinguer dans le cahier des charges

Notion	Question traitée	Limite à garder visible
Idempotence	La répétition de cette commande préserve-t-elle l’effet prévu d’une seule exécution ?	Le périmètre et les conditions du contrat doivent être définis.
Déduplication	Reconnaît-on une commande ou un message déjà rencontré ?	Reconnaître un doublon ne garantit pas que l’effet initial a réussi.
Cohérence du contenu	La même clé accompagne-t-elle toujours la même commande ?	Une empreinte ne décide pas si deux besoins métier sont identiques.
Convergence	Le parcours progresse-t-il vers un état cible acceptable malgré les reprises ?	Un système peut converger après avoir produit des effets indésirables.

Le contrat d’une commande que l’on peut reprendre

La bonne unité dépend du métier. « Demander une pièce dans ce dossier » est trop vague si plusieurs étapes peuvent légitimement nécessiter des demandes similaires. À l’inverse, prendre comme clé l’identifiant de la tentative rend chaque nouvel appel différent : la protection disparaît précisément lors d’une reprise.

On peut attribuer un identifiant opaque à une occurrence métier validée, puis conserver les commandes qui en découlent. Deux événements techniques portant cette même occurrence doivent retrouver le même identifiant. Une nouvelle occurrence légitime en reçoit un autre. Les règles qui distinguent ces situations relèvent du propriétaire du processus.

Le dossier technique Making retries safe with idempotent APIs, publié par AWS, explique l’intérêt d’un identifiant explicite fourni par l’appelant : deux requêtes aux paramètres identiques peuvent exprimer deux intentions distinctes. Il traite également l’enregistrement atomique du jeton avec les mutations et les requêtes tardives.

Élément du contrat	Décision attendue	Erreur à prévenir
Périmètre de la clé	Définir organisation, type d’opération et occurrence métier ; associer la clé à la commande.	Fusionner deux dossiers ou deux cycles légitimes.
Décision et contenu	Conserver la décision validée, la version du format et une empreinte canonique des champs opérants.	Réutiliser une clé avec un autre destinataire ou une autre action.
Tentatives	Créer un identifiant technique par appel, relié à la commande stable.	Perdre la corrélation ou changer la clé à chaque reprise.
Concurrence	Définir le mécanisme atomique au point qui applique l’effet et le comportement des autres appels.	Laisser deux processus chargés d’exécuter les commandes (« workers ») créer chacun leur résultat.
Résultat	Conserver une référence issue du système qui fait foi et distinguer réussite, non-application prouvée et incertitude.	Confondre une trace locale avec la preuve d’un effet distant.
Horizon de protection	Documenter expiration, conservation, requêtes tardives et limites de chaque dépendance.	Rejouer après purge en supposant la protection intacte.
Résolution	Nommer le service ou la personne qui réconcilie les états inconnus et les preuves nécessaires.	Laisser une file d’inconnus sans propriétaire.

La clé reste stable ; le contenu ne peut pas changer silencieusement

L’identifiant et l’empreinte ont des fonctions différentes. Le premier reconnaît l’occurrence de la commande. La seconde détecte une variation de ses données opérantes. Le calcul doit utiliser une représentation canonique : réordonner des champs techniques sans changer leur sens ne devrait pas fabriquer artificiellement une commande différente.

La canonicalisation doit aussi préserver les différences significatives. Deux destinataires, deux références de pièces ou deux versions de document ne deviennent pas équivalents parce qu’une normalisation les a effacés. Définir les champs inclus, la version du calcul et le comportement en cas de désaccord fait partie du contrat.

Évitez d’inscrire directement un nom, une adresse électronique ou un numéro de contrat dans une clé qui circulera dans les journaux. Une clé opaque et un rapprochement contrôlé suffisent généralement au besoin de corrélation. La règle métier d’unicité reste conservée dans le système autorisé à la porter.

La concurrence se règle au point qui produit l’effet

Le schéma « chercher la clé ; si elle est absente, créer » reste vulnérable si ces opérations sont séparées. Deux workers peuvent constater l’absence avant que l’un d’eux ait terminé. Une contrainte d’unicité, une transaction ou une primitive équivalente doit arbitrer ce moment dans le système responsable de la création.

Pour une tâche interne, la base qui enregistre la tâche peut parfois appliquer elle-même cette contrainte. Pour un message envoyé par un prestataire, la transaction locale ne couvre généralement pas l’envoi distant. Il faut alors s’appuyer sur le contrat du prestataire ou traiter l’incertitude comme telle.

Un verrou local ou un bail de worker constitue une protection utile, mais son expiration ne retire pas une requête déjà partie. Si un ancien worker poursuit son appel pendant qu’un nouveau reprend, la cible doit pouvoir empêcher le second effet. Un mécanisme de rejet des anciens détenteurs d’un bail n’est efficace que là où il est effectivement contrôlé.

La durée de protection découle des reprises possibles

Déterminez l’horizon à partir des files d’attente, des interruptions, des reprises manuelles et des traitements différés que le parcours autorise. Comparez-le ensuite aux capacités de chaque service. Conserver localement une clé plus longtemps ne prolonge pas la garantie du fournisseur.

À titre d’exemple spécifique, Stripe documente la mémorisation du premier résultat, y compris une erreur 500, et le contrôle des paramètres. Les clés peuvent être supprimées après au moins 24 heures ; une réutilisation après purge peut créer une nouvelle requête. Les erreurs de validation ou certains conflits concurrents avant le début de l’exécution ne sont pas mémorisés. Ces conditions décrivent cette API, pas une durée de rétention universelle pour l’assurance.

À l’expiration, la règle doit être explicite : consulter l’état distant, vérifier une autre preuve ou orienter vers une résolution humaine. Régénérer une clé pour « débloquer » une commande encore incertaine transforme sa reprise en nouvelle action potentielle.

Deux scénarios assurance pour éprouver le contrat

Scénario hypothétique 1 : la demande de justificatif dont l’envoi est incertain

Reprenons l’exemple d’ouverture. La demande validée porte sur une pièce donnée, pour une étape donnée. La commande conserve le destinataire, le contenu et l’identifiant de cette occurrence. Le connecteur reçoit un délai dépassé.

Si le prestataire accepte une clé d’idempotence selon un contrat encore applicable, la reprise utilise cette clé et le même contenu. Si le prestataire permet une lecture fiable par référence de commande, le système recherche son résultat. Une recherche qui ne voit pas encore un message dans un index mis à jour avec retard ne prouve toutefois pas qu’il n’existe pas.

Si aucune de ces possibilités n’existe, la commande reste « effet inconnu ». Le gestionnaire chargé de la résolution dispose de la référence et des éléments utiles pour vérifier l’envoi. Une relance ne part pas automatiquement pour faire disparaître l’alerte technique.

Le résultat doit rester précis : « accepté par le prestataire » ne signifie ni « reçu par le destinataire » ni « lu ». Le choix de la pièce et la pertinence de la demande relèvent d’un autre travail, développé dans l’analyse des relances documentaires et des pièces manquantes. Ici, on protège l’exécution d’une demande déjà validée.

Scénario hypothétique 2 : la tâche de contrôle créée avant la panne

Un autre parcours demande un contrôle documentaire avant la poursuite du dossier. Le CRM crée la tâche, puis le worker s’arrête avant de conserver sa référence. Un second worker reprend la commande.

Si le CRM associe atomiquement une commande unique à sa tâche, il retrouve la création initiale et retourne cette référence. La recette attend une tâche et plusieurs tentatives corrélées. Si le connecteur propose seulement une recherche puis une création sans garantie de concurrence, ce résultat n’est pas acquis : la capacité doit être renforcée ou le périmètre automatique réduit.

La protection ne doit pas supprimer les demandes légitimes. Un nouveau cycle de contrôle peut nécessiter une tâche au même libellé dans le même dossier. Son occurrence métier est différente. Le test utile vérifie donc à la fois l’absence de doublon pour une commande et la possibilité de créer deux tâches réellement distinctes.

Ces deux scénarios sont des supports de conception, pas des incidents observés chez un assureur ni des résultats de tests réalisés. Ils ne portent aucune décision automatique d’indemnisation ou de souscription.

Les pannes à injecter avant d’activer les reprises

Une recette d’idempotence doit observer les effets dans les systèmes qui font autorité. Compter les appels HTTP réussis ou lire le dernier message de l’agent ne suffit pas. Pour chaque commande testée, rapprochez les tentatives, les références de résultats et les effets réellement présents.

Panne injectée	Résultat attendu	Preuve à conserver	Règle de reprise
Arrêt avant émission, établi par le dispositif de test	Aucun effet	Commande persistée et point d’arrêt contrôlé	Reprendre la commande existante.
Réponse perdue après création distante	Un effet retrouvé, ou un état encore inconnu	Référence issue du système qui fait foi et tentatives corrélées	Rejeu sous contrat applicable ou réconciliation.
Deux workers appellent ensemble	Un effet pour la même commande	Résultat de l’arbitrage atomique côté cible	Retrouver le résultat existant.
Même clé avec un contenu différent	Conflit explicite	Versions et empreintes	Refuser ; faire valider le changement.
Effet réussi, acquittement de file perdu	Une redélivrance sans second effet protégé	Message et référence métier	Reconnaître la commande déjà traitée.
Reprise après expiration de la clé	Aucune garantie présumée	Horizon du fournisseur et état distant	Réconcilier avant toute nouvelle action.
Ancien worker actif après expiration de son bail	Concurrence maîtrisée ou incertitude visible	Historique des détenteurs et résultat côté cible	Appliquer les barrières prévues ; ne pas assimiler bail expiré et appel annulé.
Prestataire sans idempotence ni lecture fiable	Effet inconnu affecté à un responsable	Tentatives et éléments de vérification	Bloquer la répétition automatique.
Arrêt après écriture métier et outbox validées	Événement restant à transmettre	Transaction locale validée et ligne outbox	Reprendre le relais ; traiter ses éventuels doublons côté consommateur.
Échec d’une compensation	Correction incomplète visible	Étapes confirmées et commande de correction distincte	Reprendre selon le contrat propre à la compensation ; escalader les effets irréversibles.

Ajoutez un test où deux commandes légitimes contiennent des données identiques, puis un autre où un événement métier est livré deux fois. Le premier doit permettre deux effets autorisés ; le second doit retrouver la même commande. Ces tests éprouvent la définition métier de l’unicité.

Pour les preuves techniques, le cadre présenté dans l’article sur l’observabilité des systèmes génératifs permet d’organiser les traces. Le critère d’acceptation reste ici la correspondance entre commandes et effets, ainsi que le traitement explicite des inconnus.

Ce que l’outbox, la file et la compensation laissent à votre charge

Une outbox conserve l’événement à transmettre dans la même transaction que l’écriture métier locale. Elle permet de reprendre sa distribution après une panne du relais. La documentation AWS sur ce pattern rappelle cependant que des messages peuvent être dupliqués et que le consommateur doit les traiter en conséquence.

Une inbox côté consommateur peut conserver les identifiants déjà traités. Lorsque cet enregistrement partage une transaction avec l’effet local, il protège cette frontière. S’il est suivi d’un appel non transactionnel à un prestataire, une nouvelle frontière d’incertitude apparaît : enregistrer « traité » trop tôt risque de perdre l’action ; l’enregistrer après l’appel laisse une fenêtre de répétition.

Les garanties d’une file doivent être lues dans leur périmètre. Amazon SQS documente une fenêtre de déduplication FIFO de cinq minutes. Sa documentation décrit aussi la remise à disposition d’un message après expiration du délai de visibilité. Ces mécanismes ne certifient pas, à eux seuls, qu’un envoi externe ou une création métier ne sera jamais répété.

Enfin, corriger un effet indésirable demande une opération métier distincte. Fermer une tâche créée en trop peut être envisageable ; faire oublier un message déjà lu ne l’est pas. Le pattern de transaction compensatoire décrit par Microsoft souligne que la correction dépend du contexte, peut échouer et ne restaure pas nécessairement l’état initial. Sa propre exécution a besoin d’un suivi et d’une politique de reprise.

Choisir les conditions de mise en service

Avant d’autoriser les reprises automatiques, le responsable métier et l’équipe technique doivent pouvoir répondre ensemble à quelques questions concrètes : quelle occurrence la clé représente-t-elle ? Où le contenu validé est-il conservé ? Qui empêche deux créations concurrentes ? Quel système confirme l’effet ? Jusqu’à quand la protection tient-elle ? Qui résout ce qui reste inconnu ?

La mise en service peut alors être conditionnée à des preuves : les pannes prévues n’ont pas produit de second effet dans le périmètre testé ; les intentions distinctes restent exécutables ; les variations de contenu sont refusées ; aucun résultat inconnu n’est transformé en réussite ou rejoué sans règle ; les cas hors garantie rejoignent une résolution opérationnelle.

Ces critères ne prouvent pas l’absence de toute erreur métier. Une commande peut être parfaitement protégée contre les répétitions et demander la mauvaise pièce. L’évaluation de la décision et celle de son exécution doivent donc rester complémentaires. Le guide de construction d’un jeu d’évaluation IA en assurance propose un cadre pour organiser cette recette.

À mesure que plusieurs agents et services partageront un dossier, le contrat de commande deviendra un point d’intégration essentiel. Un bon premier exercice consiste à choisir une seule action déjà déléguée, puis à simuler sa réponse perdue. Le parcours sait-il retrouver l’effet, ou seulement recommencer ? La réponse détermine les travaux à mener avant d’élargir son autonomie.

Pour partir d’un parcours concret, échangeons sur une action déléguée et les preuves nécessaires à sa reprise. L’objectif est de définir un contrat testable avant d’étendre l’automatisation.

Sources et références

Sources primaires consultées le 10 septembre 2026. Les conditions des services cités sont à vérifier de nouveau avant toute mise en œuvre.

• AWS Builders Library — Making retries safe with idempotent APIs
• Stripe documentation — Idempotent requests
• RFC Editor / IETF — RFC 9110 §9.2.2, Idempotent Methods
• AWS Prescriptive Guidance — Transactional outbox pattern
• Microsoft Azure Architecture Center — Compensating Transaction Pattern
• AWS SQS documentation — Preventing duplicate processing in a multiple-producer/consumer system
• AWS SQS documentation — Amazon SQS FIFO queue key terms