Intégration du site au CRM : vérifier la réception des demandes
Neaptide · 7 septembre 2026 · 6 min de lecture · Mis à jour: 3 octobre 2026
Comment relier les formulaires au CRM, garder la source des demandes et éviter les doublons. Avec un exemple de panne et les vérifications avant lancement.
Dans cet article
Un message de remerciement ne prouve pas que la demande est arrivée dans le CRM. Avant de valider le site, demandez à voir l’envoi enregistré, la fiche correspondante et le nom du commercial chargé du suivi. Et si le traitement s’arrête en route, l’équipe doit pouvoir retrouver à quelle étape.
L’intégration transmet les données du formulaire au système commercial et applique les règles convenues : elle crée la demande, la rattache au contact et l’attribue à un commercial. Un formulaire natif du CRM ou un connecteur existant peut suffire. Dans d’autres cas, il faut un développement spécifique via l’API. Tout dépend de vos règles de traitement.
Définir ce que signifie « demande reçue »
Il y a trois étapes à distinguer : l’enregistrement sur le site, la confirmation du CRM et l’attribution d’une tâche au commercial. Une notification par courriel ou Telegram ne prouve pas qu’elles ont abouti toutes les trois.
Quand le CRM est indisponible, le site peut conserver la demande de manière fiable pour la transmettre plus tard, et dans ce cas confirmer sa réception au visiteur. Si cet enregistrement échoue lui aussi, pas question d’afficher un succès. Proposez une nouvelle tentative ou un autre moyen de contact.
Choisir un raccordement adapté
Regardez d’abord si un formulaire natif ou un connecteur existant transmet les bons champs, attribue les demandes aux bonnes personnes et reprend l’envoi après une erreur. Demandez à le voir sur des demandes de test. Un développement spécifique n’est pas plus fiable du seul fait qu’il est sur mesure.
Une file d’attente sépare la réception du traitement, mais quelqu’un doit alors surveiller les messages en attente ou en échec. Pour un petit volume régulier, un service de file distinct est souvent superflu. Au moment de décider, mettez dans la balance le travail d’exploitation, en plus de la mise en place.
Définir les informations à transmettre au CRM
Préparez un tableau qui associe chaque champ du formulaire à son champ dans le CRM. Ajoutez-y les informations que le site fournit lui-même, comme la page, l’identifiant du formulaire, l’heure et la source connue de la visite. Vérifiez ensuite quels champs sont obligatoires et quelles valeurs ils admettent, en particulier pour les listes de choix.
Décidez si vous conservez la première source connue, celle de la demande actuelle ou les deux. L’absence de paramètres UTM ne permet pas de conclure à une visite directe. Il se peut simplement que la source soit inconnue.
Les identifiants secrets du CRM restent côté serveur. Quant aux journaux, limitez-en l’accès et évitez d’y recopier sans nécessité les messages des clients.
Une nouvelle tentative n’est pas une nouvelle demande
Prenons un exemple fictif. Le site enregistre la demande S-104 et le CRM crée la fiche C-208, mais la confirmation se perd en chemin. Le site, lui, ne constate qu’un délai dépassé. S’il relance la création sans rien vérifier, il risque de produire un doublon.
Gardez le même identifiant lors du renvoi. Si l’API propose l’idempotence, plusieurs tentatives peuvent être traitées comme une seule action. Sinon, il faut prévoir un mécanisme adapté pour associer et vérifier les enregistrements. Rechercher une fiche avant de la créer ne suffit pas, puisque deux requêtes peuvent arriver en même temps. Rappelez-vous aussi qu’un délai d’attente dépassé ne prouve pas que le premier enregistrement a échoué.
Si le client demande un autre service le lendemain, c’est une nouvelle demande, S-105. On peut la rattacher au contact existant tout en conservant son contenu. En supprimant toutes les demandes associées au même numéro de téléphone, on ferait disparaître de vraies demandes.
Tester aussi les échecs
Cette grille décrit les résultats attendus dans un environnement de test. Elle ne rend pas compte d’essais menés sur un CRM précis. Appliquez-la à chaque formulaire et à chaque version linguistique, en relevant les identifiants, ce qui permet de rapprocher les mêmes demandes d’un système à l’autre.
| Cas de test | Vérification attendue |
|---|---|
| Demande ordinaire | Champs, source, fiche et responsable corrects. |
| CRM indisponible | Demande conservée, attente visible, transmission reprise. |
| Délai dépassé après création | Aucune seconde demande ; rapprochement par identifiant. |
| Champ obligatoire invalide | Erreur visible, sans répétitions infinies. |
| Nouvelle demande, même téléphone | Contenu conservé selon les règles convenues. |
| Aucun paramètre UTM | Aucune campagne inventée pour remplacer une source inconnue. |
Préparer l’exploitation
À la livraison, demandez le tableau des champs, les règles de traitement des nouvelles demandes d’un contact existant et les instructions pour consulter les erreurs. Il faut aussi désigner un responsable et convenir du délai de transmission acceptable. Enfin, faites-vous montrer comment le traitement reprend après un incident sans créer de doublons.
Le nombre de nouvelles affaires ne suffit pas pour contrôler la réception, car certaines demandes rejoignent un contact ou une affaire existante. Mieux vaut rapprocher les identifiants et les statuts, en tenant compte des tests, du spam et des demandes en attente.
Pour discuter d’un projet web avec Neaptide, envoyez l’adresse du site, le nom du CRM, la liste des formulaires et un exemple de fiche sans données personnelles. Précisez comment traiter les nouvelles demandes d’un client connu et quel commercial vérifiera le résultat.