# Un agent IA envoie deux fois la même demande : éviter les doublons dans le CRM

Version HTML de référence : https://talkweb.fr/analyses/agent-crm-idempotence-doublons/

Publication : 2026-11-11T12:00:04+01:00. Révision : 2026-11-11T12:00:04+01:00.

Après une réponse perdue, une relance peut créer un second dossier. Définissez l’identité d’opération, les conflits et la reprise côté serveur.

## La réponse

Attribuez une identité stable à l’opération et contrôlez sa répétition côté serveur. Après une interruption, l’agent doit retrouver le résultat existant plutôt que créer une nouvelle demande à l’aveugle.

## Un délai dépassé ne dit pas si la création a échoué

La requête peut avoir atteint le CRM, créé le dossier puis perdu sa réponse sur le retour. Si l’agent recommence avec une nouvelle opération, deux dossiers apparaissent. Réduire le délai ou demander au modèle d’être prudent ne résout pas ce défaut de protocole.

Distinguez l’intention métier et ses tentatives réseau. Une demande de devis est une opération ; les relances pour obtenir son résultat sont plusieurs tentatives de cette même opération. Une nouvelle demande volontaire du client doit, au contraire, rester possible avec une identité différente.

## Exemple : la création réussit, mais l’agent ne reçoit pas la confirmation

Dans l’environnement de recette, la demande est créée puis la réponse est interrompue. L’agent relance avec la même identité d’opération. Le système doit retrouver le dossier, pas en ouvrir un second. Un autre essai réutilise la clé avec un montant modifié : le contrat doit détecter ce conflit. Enfin, deux relances arrivent simultanément pour vérifier la protection contre la concurrence. Ces cas sont documentés avec les résultats attendus avant l’implémentation. Ils permettent de discuter concrètement des garanties du CRM et des limites que l’intégration doit encore traiter.

## L’agent ne doit pas décider seul si une opération a déjà eu lieu

AgentDojo montre l’intérêt d’évaluer l’accomplissement réel des tâches agentiques, pas seulement la qualité d’un dialogue. Les principes de Saltzer et Schroeder placent les contrôles dans le système qui protège les opérations. Ces travaux ne constituent pas une démonstration d’un protocole d’idempotence ; sa mise en œuvre reste une responsabilité applicative.

Sources : [AgentDojo: A Dynamic Environment to Evaluate Prompt Injection Attacks and Defenses for LLM Agents](https://proceedings.neurips.cc/paper_files/paper/2024/hash/97091a5177d8dc64b1da8bf3e1f6fb54-Abstract-Datasets_and_Benchmarks_Track.html); [The Protection of Information in Computer Systems](https://www.cs.virginia.edu/~evans/cs551/saltzer/)

Enregistrez côté serveur une identité d’opération et son résultat. Après une interruption, permettez de consulter cet état avant de relancer. Distinguez une nouvelle intention du client d’une répétition de la même demande. Le journal doit permettre au support de savoir si le CRM a accepté l’opération, même lorsque l’agent n’a pas reçu la réponse réseau. Une formulation rassurante du modèle ne résout pas cette incertitude technique.

## L’idempotence est un contrat de l’API, pas une qualité du prompt

La documentation Stripe fournit un exemple concret de clé d’idempotence permettant de retrouver le résultat d’une requête répétée selon ses règles. Ce comportement ne peut pas être supposé dans un CRM différent. La documentation de sécurité WebMCP rappelle également que les déclarations d’outil ne remplacent pas les contrôles du service.

Sources : [Idempotent requests](https://docs.stripe.com/api/idempotent_requests); [WebMCP tool security](https://developer.chrome.com/docs/ai/webmcp/secure-tools)

Le principe à transposer est un contrat explicite : portée de la clé, durée de conservation, comparaison des paramètres et réponse en cas de concurrence. La solution doit être conçue au niveau où la création réelle est maîtrisée, pas uniquement dans la mémoire de la conversation.

## Relier la clé au dossier et à ses paramètres

Le serveur reçoit un identifiant d’opération stable, vérifie les droits et enregistre atomiquement l’état de traitement. Une répétition avec les mêmes paramètres retrouve le même résultat ; une répétition avec des paramètres différents doit être traitée explicitement. Une contrainte d’unicité et une transaction peuvent participer à cette protection selon l’architecture.

Préparez les états en cours, terminé et échec récupérable, ainsi que la manière de consulter le résultat. Si le CRM externe ne fournit pas d’idempotence native, l’intégration doit gérer le rapprochement sans prétendre garantir ce qu’elle ne contrôle pas. Les opérations externes partielles nécessitent une stratégie de reprise documentée.

![La première tentative crée le dossier. Une reprise avec la même identité retrouve le résultat conservé, selon le contrat du service.](https://talkweb.fr/charts/agent-crm-idempotence-doublons.svg)

Diagramme de protocole proposé. Atomicité, conflits et durées de conservation restent à implémenter et tester.

## Tester la panne au moment le plus gênant

Coupez la réponse après la création, relancez simultanément et envoyez la même clé avec un contenu différent dans l’environnement de test. Vérifiez le nombre de dossiers et le résultat rendu à l’agent. Un test où tout répond normalement ne vérifie pas l’idempotence.

Les journaux doivent permettre de relier opération, tentatives et dossier sans exposer inutilement les données personnelles. L’utilisateur reçoit une confirmation de résultat, pas une succession de messages « probablement envoyé ».

La prévention des doublons s’inscrit dans un contrat plus large : [les actions qu’un simulateur de devis expose aux agents avec WebMCP](https://talkweb.fr/analyses/webmcp-simulateur-devis-agent-ia/).

Une opération, plusieurs tentatives, un résultat — grille de travail TalkWeb, à adapter au service

| Situation observée | Décision ou contrôle | Responsable |

| --- | --- | --- |

| Réponse perdue | Consulter ou rejouer la même opération | Intégration |

| Même clé, autre contenu | Refuser ou traiter le conflit explicitement | Back |

| Requêtes simultanées | Vérifier unicité et atomicité | Back / qualité |

## Passer à l’action

Attribuez une identité stable à l’opération et contrôlez sa répétition côté serveur. Après une interruption, l’agent doit retrouver le résultat existant plutôt que créer une nouvelle demande à l’aveugle.

Tester une réponse perdue après création et deux relances simultanées.

Une même opération ne crée pas plusieurs dossiers et son résultat reste récupérable.

## Limites

- Ce comportement Stripe n’est pas automatiquement celui d’un CRM.

## Sources

- [Stripe. (2026). Idempotent requests. DOCUMENTATION · Stripe.](https://docs.stripe.com/api/idempotent_requests) — Documentation publique des clés et reprises de requête consultée.

- [Pagnucco, J., & Klepper, A. (2026). WebMCP tool security. DOCUMENTATION · Chrome for Developers.](https://developer.chrome.com/docs/ai/webmcp/secure-tools) — Guide de sécurité consulté : annotations, exposition entre origines et injections indirectes.

- [Edoardo Debenedetti, Jie Zhang, Mislav Balunovic, Luca Beurer-Kellner, Marc Fischer, & Florian Tramèr. (2024). AgentDojo: A Dynamic Environment to Evaluate Prompt Injection Attacks and Defenses for LLM Agents. NeurIPS Datasets and Benchmarks.](https://proceedings.neurips.cc/paper_files/paper/2024/hash/97091a5177d8dc64b1da8bf3e1f6fb54-Abstract-Datasets_and_Benchmarks_Track.html) — Résumé primaire consulté ; texte intégral non audité.

- [Jerome H. Saltzer, & Michael D. Schroeder. (1975). The Protection of Information in Computer Systems. Proceedings of the IEEE.](https://www.cs.virginia.edu/~evans/cs551/saltzer/) — Résumé et passages sur contrôle d’accès, authentification et principaux responsables consultés.