Intégration du site au CRM : vérifier la réception des demandes
Neaptide · 7 septembre 2026 · 6 min de lecture
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 commercial chargé du suivi. En cas d’arrêt du traitement, l’équipe doit pouvoir retrouver l’étape en cause.
L’intégration transmet les données du formulaire au système commercial et applique les règles convenues : création de demande, rattachement au contact et attribution. Un formulaire natif, un connecteur ou une intégration spécifique peuvent convenir.
Définir ce que signifie « demande reçue »
Distinguez 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 que ces trois étapes ont abouti.
Si le CRM est indisponible, le site peut conserver la demande de manière fiable pour la transmettre ensuite. Il peut alors confirmer sa réception. Si cet enregistrement échoue aussi, il faut proposer une nouvelle tentative ou un autre moyen de contact, sans afficher un succès.
Choisir un raccordement adapté
Vérifiez d’abord les formulaires et connecteurs existants : champs, attribution et reprise après erreur. Demandez une démonstration. Un développement spécifique n’est pas automatiquement plus fiable.
Une file d’attente sépare réception et traitement, mais impose de surveiller les messages bloqués. Un service de file distinct peut être superflu pour un faible volume stable. Comparez aussi les contraintes d’exploitation.
Définir les informations à transmettre au CRM
Préparez un tableau associant chaque champ du formulaire à son champ dans le CRM. Ajoutez les informations fournies par le site : page, identifiant du formulaire, heure et source connue de la visite. Vérifiez les champs obligatoires et les valeurs admises, notamment 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 : la source peut être inconnue.
Les identifiants secrets du CRM doivent rester côté serveur. Limitez l’accès aux journaux et évitez d’y recopier inutilement les messages des clients.
Une nouvelle tentative n’est pas une nouvelle demande
Exemple fictif : le site enregistre S-104 et le CRM crée C-208, mais la confirmation se perd. Le site constate un délai dépassé. Une nouvelle création sans vérification 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 lorsque deux requêtes arrivent en même temps. 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, il s’agit d’une nouvelle demande S-105. On peut la rattacher au contact existant tout en conservant son contenu. Supprimer toutes les demandes portant le même numéro ferait disparaître de vrais besoins.
Tester aussi les échecs
Cette grille décrit des résultats attendus dans un environnement de test, pas les performances observées d’un CRM. Appliquez-la à chaque formulaire et version linguistique. Relevez les identifiants pour rapprocher les mêmes demandes.
| 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 numéro | 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. Désignez un responsable, convenez du délai de transmission acceptable et faites montrer la reprise après incident sans création de doublons.
Le nombre de nouvelles affaires ne suffit pas pour contrôler la réception : certaines demandes rejoignent un contact ou une affaire existante. Rapprochez 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.