Relier un formulaire à son CRM permet d’éviter la copie manuelle des demandes. Pour éviter les doublons, il faut distinguer l’identité du contact et celle de chaque demande, conserver l’état du traitement et vérifier le résultat dans le CRM. Un simple envoi de données entre deux outils ne suffit pas.
Le CRM est l’outil de gestion de la relation client. Ce guide décrit un parcours à faire adapter à vos applications ; ce n’est pas un connecteur prêt à installer. Le scénario et les identifiants d’exemple sont fictifs. Aucun formulaire réel n’a été envoyé pour préparer cet article.
Une personne peut envoyer plusieurs demandes légitimes
Un contact et une demande sont deux objets différents. Une personne peut demander un devis aujourd’hui, puis un autre pour un second établissement demain. Vous pouvez souhaiter une seule fiche de contact tout en conservant deux dossiers commerciaux.
À l’inverse, une même soumission peut être transmise plusieurs fois après une panne ou un nouvel essai. La répétition technique ne doit pas créer un deuxième dossier. Le navigateur peut désactiver le bouton après le clic, mais cela ne protège pas contre les répétitions entre serveurs.
Avant le développement, convenez du comportement attendu pour chaque situation. Une fusion automatique de contacts peut écraser une information correcte. Deux demandes similaires ne sont pas forcément un doublon.
Décrire les champs avant de connecter les outils
Un connecteur peut recevoir des données valides tout en les enregistrant au mauvais endroit. Faites correspondre chaque champ du formulaire à sa destination, puis définissez les valeurs obligatoires et la règle de mise à jour.
| Information | Destination envisagée | Contrôle à prévoir |
|---|---|---|
| Identifiant de soumission | Référence de la demande | Stable lors d’une nouvelle tentative |
| Adresse de contact | Fiche contact | Format accepté et ambiguïtés examinées |
| Type de prestation | Dossier commercial | Valeur appartenant à une liste connue |
| Message libre | Description de la demande | Taille limitée ; texte traité comme une donnée |
| Date de réception | Historique de traitement | Fuseau et format documentés |
| Préférence de communication | Champ prévu par le CRM | Ne pas la déduire d’un autre champ |
Ne recopiez pas automatiquement tous les champs. Collectez ceux nécessaires au traitement et définissez leur durée de conservation selon vos obligations et usages. Un identifiant technique ne devrait pas contenir une adresse e-mail ou un secret.
L’adresse e-mail peut servir de critère de rapprochement, mais elle n’est pas une identité universelle : boîte partagée, adresse modifiée ou erreur de saisie rendent certains cas ambigus. Ne fusionnez pas des fiches sur la seule ressemblance des noms. Un cas incertain peut rester en contrôle manuel.
Le parcours : recevoir, vérifier, enregistrer, confirmer
Le formulaire envoie la demande à un service de réception contrôlé par votre intégration. Les clés d’accès au CRM restent côté serveur ; elles ne sont pas incorporées au code livré au navigateur. Les contrôles sont refaits côté serveur, même si le formulaire les propose déjà.
- Recevoir. Conserver un identifiant stable et un état récupérable.
- Vérifier. Contrôler les champs et la répétition éventuelle.
- Enregistrer. Retrouver le contact selon les règles, puis créer ou relier la demande.
- Confirmer. Enregistrer la référence CRM et le résultat vérifié.
L’accusé de réception affiché doit correspondre à ce qui est acquis. Si la demande est sauvegardée dans une file mais pas encore transmise au CRM, indiquez qu’elle est reçue. Ne promettez pas qu’un devis est créé ou qu’une équipe l’a examinée.
Le choix entre connecteur natif et développement par API dépend des opérations disponibles. La documentation Contacts de HubSpot illustre les opérations possibles sur des fiches de contact. Pour votre CRM, vérifiez sa documentation, sa version et l’offre souscrite ; les mêmes fonctions ne sont pas garanties partout.
Empêcher deux exécutions de créer deux dossiers
L’idempotence désigne ici la capacité à rejouer une même demande sans répéter son effet métier. Donnez à la soumission un identifiant conservé lors des tentatives. Une nouvelle demande légitime reçoit un autre identifiant.
Imaginons la soumission fictive demande-demo-042. Le traitement note qu’il a commencé, puis conserve la référence obtenue dans le CRM. Une répétition retrouve cet état avant de décider quoi faire. Elle ne doit pas repartir systématiquement par une création.
Deux exécutions peuvent arriver en même temps. Un simple « chercher puis créer » ne suffit pas si chacune cherche avant que l’autre ait écrit. Il faut un mécanisme cohérent avec l’infrastructure : contrainte d’unicité, verrou ou opération atomique, et gestion explicite des conflits.
Certaines API offrent des clés d’idempotence, comme le montre l’exemple documenté par Stripe. C’est une illustration du principe, pas une recommandation d’utiliser Stripe pour le CRM. Vérifiez les garanties et la durée de conservation des clés de votre fournisseur. Sans support adapté, l’intégrateur doit prévoir son propre suivi et les cas où une réconciliation humaine sera nécessaire.
Traiter le cas difficile : le CRM a peut-être déjà écrit
Une coupure peut se produire après la création d’un dossier, avant que votre service reçoive la réponse. L’absence de réponse ne prouve pas l’échec de l’écriture. Relancer une création sans vérifier peut fabriquer un doublon.
Conservez alors un état « résultat à vérifier ». Recherchez l’opération à partir de la référence externe si le CRM le permet. Si aucune vérification fiable n’est possible, bloquez la répétition automatique et faites examiner le cas. Un statut explicite vaut mieux qu’une suite de tentatives dont personne ne connaît l’effet.
Distinguez également les erreurs : une donnée invalide demande une correction ; une permission retirée demande de rétablir l’accès ; une limite temporaire demande une stratégie d’attente conforme au fournisseur. Les tentatives doivent être bornées et laisser les demandes récupérables.
Exemple fictif : un contact, deux besoins, une répétition
Une personne remplit le formulaire pour l’entretien d’un premier local. Le CRM conserve un contact et une demande A. Une panne provoque la retransmission de la même soumission : la référence A est retrouvée, sans nouvelle demande.
La semaine suivante, cette personne décrit un autre local. La nouvelle soumission possède un autre identifiant. Elle crée une demande B, liée au même contact si le rapprochement est confirmé. La demande B ne doit pas être éliminée au motif que l’adresse e-mail existe déjà.
Si la nouvelle saisie change le téléphone du contact, la règle doit dire quoi faire : proposer la mise à jour, conserver l’ancien numéro, ou remplacer un champ dont le formulaire est la source de référence. Ce choix appartient au fonctionnement de l’entreprise.
Exemple avec bexio : du contact au brouillon de devis
bexio est une suite de gestion qui réunit notamment contacts et documents commerciaux. Sa documentation API officielle décrit la recherche de contacts, la création de devis et une opération distincte d’envoi par courriel. Ces possibilités permettent de cadrer le parcours suivant ; elles ne prouvent pas qu’un connecteur existant réalise tous les contrôles nécessaires.
Le scénario est fictif, sans appel à un compte bexio réel : une demande d’entretien arrive depuis un formulaire, puis un brouillon de devis est préparé pour vérification.
| Étape proposée | Contrôle à prévoir |
|---|---|
| Rechercher le contact dans bexio | Confirmer le bon contact ; arrêter si plusieurs fiches correspondent |
| Relier la soumission au contact | Conserver identifiant de demande et référence bexio dans le suivi de l’intégration |
| Préparer le devis | Employer les prestations, quantités, tarifs, devise et règles fiscales validés par l’entreprise |
| Contrôler le document obtenu | Conserver la référence du devis et vérifier lignes, montants et destinataire |
| Faire valider | Garder l’envoi hors du pilote ; une personne approuve le document avant transmission |
Ne placez pas une clé bexio dans le formulaire public. La documentation distingue des droits de lecture et d’écriture pour les contacts et les devis : demandez seulement ceux nécessaires au parcours retenu. Un droit d’écriture n’est pas un mécanisme d’approbation métier ; le contrôle de l’envoi doit être prévu séparément.
La référence de soumission doit rester suivie par l’intégration. Ne supposez pas qu’un champ bexio impose son unicité ou qu’une création de devis peut être rejouée sans effet : vérifiez les garanties de l’opération choisie. Si la réponse se perd après création, recherchez le document ou faites examiner le résultat avant de relancer.
Avant une mise en service, vérifiez l’offre souscrite, les permissions, les champs et les statuts effectivement obtenus. Testez avec des données fictives : un client connu, un contact ambigu, une quantité absente et une soumission répétée. Cet exemple illustre le premier processus boîte mail ou formulaire → CRM → brouillon de devis ; il ne désigne pas bexio comme le CRM le plus utilisé en Suisse romande.
Les essais à exiger avant la mise en service
Utilisez un compte de test et des données fictives. Comparez les résultats dans le CRM, pas uniquement les messages du connecteur.
| Essai | Résultat attendu |
|---|---|
| Nouvelle demande valide | Une demande et une référence CRM enregistrée |
| Répétition du même identifiant | Aucun deuxième effet métier |
| Deux exécutions simultanées | Une création, conflit pris en charge |
| Même contact, nouveau besoin | Nouvelle demande conservée |
| Champ obligatoire absent | Exception visible, aucune valeur inventée |
| Réponse perdue après écriture | Vérification de l’état avant nouvelle création |
| Accès au CRM refusé | Alerte et demandes récupérables |
Conservez le résultat, la date et la version testée. La recette doit aussi examiner le texte affiché au visiteur, les permissions des comptes et les informations conservées dans les journaux. Évitez d’y enregistrer les messages clients complets lorsqu’une référence suffit.
Prévoir l’entretien dès le départ
Désignez la personne qui vérifie les demandes bloquées et celle qui entretient la connexion. Un changement de champ, de permission ou de version d’API peut interrompre le parcours. Le guide de surveillance des applications web et API décrit les contrôles utiles.
Pour choisir le périmètre initial, utilisez la grille du premier processus à automatiser. Si vous souhaitez interpréter le texte libre avec un modèle, ajoutez les contrôles du dossier Agents IA pour PME ; le transfert de champs seul ne nécessite pas d’IA.
Pour préparer une demande d’aide, décrivez le formulaire, le CRM et les erreurs constatées, sans transmettre de clé d’accès ni de données clients.