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

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. (Edoardo Debenedetti et al., 2024)(Jerome H. Saltzer et al., 1975)

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. (Stripe, 2026)(Pagnucco et al., 2026)

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.

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.

Les limites de cette analyse

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

Sources et résultats utilisés dans cet article

Les passages et le périmètre de lecture sont consultables ci-dessous. L’accès à un texte intégral ne signifie pas que chaque résultat a été audité.