Formulaire WordPress : éviter les demandes en double dans le CRM

Commencer par définir ce qui constitue une demande

Un contact, une demande et une tentative d’envoi ne sont pas la même chose. Une personne peut poser une question aujourd’hui puis demander un autre devis la semaine suivante. Fusionner automatiquement tous les messages associés à son adresse email ferait disparaître des besoins réels. À l’inverse, conserver chaque clic comme une nouvelle opportunité surcharge le suivi commercial.

Prenez un exemple fictif : une entreprise demande un devis pour la référence A10. Le visiteur clique deux fois parce que la confirmation tarde. Il faut une seule demande avec son contenu, éventuellement deux tentatives enregistrées dans le suivi technique, et un message compréhensible à l’écran. Si ce même visiteur revient pour la référence B20, il peut s’agir d’une autre demande légitime.

Ces règles doivent être définies avec la personne qui traite les messages. Elles complètent la conception d’un formulaire de devis utile au premier échange. Un bon formulaire ne se juge pas seulement à ses champs ; il faut aussi savoir ce qui arrive au message après le clic.

Repérer où le doublon est créé

Reproduisez le problème avant de changer les réglages. Le site peut enregistrer un seul message mais envoyer deux notifications. Un connecteur peut créer deux fiches dans le CRM. Deux automatisations actives peuvent aussi surveiller le même événement. Ces situations donnent parfois l’impression d’un même bug alors qu’elles demandent des corrections différentes.

Notez une référence de test dans le message et suivez-la dans les différents outils. Regardez l’heure, la demande enregistrée, les échanges avec le CRM et les emails de notification. Travaillez avec des données de démonstration, sur un environnement adapté, et évitez de déclencher de vraies relances commerciales pendant le diagnostic.

Ce tableau propose des pistes, pas un diagnostic automatique. Une installation peut cumuler plusieurs causes. Corrigez une couche à la fois, puis rejouez le même scénario pour vérifier si le résultat a changé.

Soigner l’attente sans compter uniquement sur le bouton

Après un envoi, le bouton peut annoncer « Envoi en cours » et empêcher un second clic tant que l’opération est en attente. Cette mesure améliore la compréhension, mais ne constitue pas une garantie côté serveur. Le JavaScript peut ne pas fonctionner, le visiteur peut recharger la page et un autre service peut répéter la requête.

Le guide W3C sur les notifications de formulaire recommande un retour compréhensible après une soumission. Appliquez cette idée avec des états précis : validation des champs, enregistrement réussi, transmission en attente ou erreur connue. Évitez d’annoncer qu’un commercial a reçu et lu le message si seule sa création dans le site est confirmée.

En cas de délai dépassé, ne poussez pas immédiatement le visiteur à envoyer de nouveau toutes ses informations. Si le site connaît déjà la référence de sa demande, il peut permettre d’en retrouver le résultat. La solution dépend de l’outil utilisé et des précautions nécessaires pour ne pas exposer le contenu d’un autre visiteur.

Rendre une nouvelle tentative sans effet supplémentaire

Le principe technique s’appelle l’idempotence : répéter une opération donnée ne produit pas un effet métier supplémentaire. MDN rappelle notamment que POST n’est pas garanti idempotent. Le fait d’utiliser une requête POST pour un formulaire ne protège donc pas automatiquement contre la création de doublons.

Une mise en œuvre peut associer un identifiant stable à une soumission logique. Si la même opération revient avec les mêmes données, le serveur retrouve son résultat au lieu de créer une nouvelle demande. Si les données diffèrent avec cet identifiant, le cas doit être traité explicitement plutôt que d’écraser silencieusement le premier message.

Un simple contrôle « chercher puis insérer » peut rester insuffisant : deux requêtes simultanées peuvent chercher avant que la première écriture soit terminée. Le développement doit prévoir une règle d’unicité et une opération de réservation ou d’enregistrement cohérente. Cette décision relève de la conception du stockage et doit être testée sous concurrence, pas seulement par deux clics espacés.

L’identifiant d’opération ne remplace ni la validation des champs, ni les contrôles d’accès, ni la protection antispam. Il ne doit pas contenir le récit du visiteur ou ses coordonnées. Définissez aussi sa durée de conservation et la manière dont une nouvelle demande volontaire obtient sa propre référence.

Séparer l’enregistrement, le CRM et les notifications

Un parcours simple comporte plusieurs états : la demande est enregistrée sur le site, sa transmission au CRM est en attente, puis cette transmission réussit ou nécessite une intervention. L’envoi d’un email peut avoir son propre résultat. Si le serveur email est indisponible, cela ne signifie pas nécessairement que la demande a disparu.

Pour un traitement différé, conservez une référence permettant de relier le message d’origine et la fiche distante. Avant de rejouer une création après un délai, vérifiez si le CRM dispose déjà de l’objet correspondant ou s’il offre son propre mécanisme de dédoublonnage. Tous les connecteurs ne proposent pas les mêmes garanties. Il faut lire leur documentation et tester le comportement réellement observé.

La présentation du CRM AtaWay réalisé par Blue Strat montre un exemple d’outil métier ; elle ne constitue pas la preuve que toutes ces protections sont présentes dans un connecteur donné. Le besoin de transmission fiable doit être cadré séparément lors du développement d’un module WordPress, avec ses règles et ses tests.

Préparer une recette qui couvre les cas difficiles

Une recette utile commence par un envoi normal : les données sont enregistrées une fois, la référence est retrouvable et la confirmation correspond au résultat. Rejouez ensuite une tentative identique. Le nombre de demandes métier doit rester stable, tout en conservant les informations techniques nécessaires pour expliquer le second traitement.

1. Tester deux clics rapides et deux requêtes concurrentes sur une même soumission.
2. Couper la connexion après l’enregistrement, puis relancer l’opération avec la même référence.
3. Simuler un CRM indisponible, puis vérifier la reprise sans seconde création.
4. Simuler une erreur d’email et confirmer que la demande reste retrouvable.
5. Soumettre volontairement un autre besoin avec la même adresse email et vérifier qu’il n’est pas supprimé comme doublon.
6. Vérifier les erreurs, les messages d’attente et le retour au formulaire au clavier.

Ces tests sont des simulations à organiser avec le développeur. N’altérez pas une installation de production pour reproduire une coupure et n’envoyez pas de demandes réelles à un client. Conservez pour chaque essai le résultat attendu, le résultat observé et la référence technique, en limitant les données personnelles dans les journaux.

Garder un suivi exploitable après la correction

Le tableau de suivi doit distinguer une nouvelle demande, une transmission en attente et une erreur à examiner. Une alerte ne devient utile que si une personne sait quoi regarder et quand intervenir. Évitez les notifications répétées pour une même panne : elles peuvent masquer une nouvelle demande réellement bloquée.

Après une mise à jour du formulaire ou du connecteur, rejouez les scénarios importants. Intégrez cette vérification à la maintenance du site plutôt que d’attendre le prochain signalement. Un suivi technique ne garantit pas que chaque contact sera traité commercialement ; cette responsabilité reste à organiser dans l’équipe.

Pour commencer, choisissez un formulaire et un seul parcours jusqu’à son outil de destination. Dessinez les états, identifiez les reprises possibles et définissez ce qui prouve la réussite de chaque étape. L’accompagnement WordPress peut alors être cadré sur des actions concrètes : diagnostic, correction et recette documentée, sans promettre un connecteur universel ou une absence définitive d’incident.