Du formulaire web au CRM : éviter les demandes perdues et les doublons

Un visiteur remplit votre formulaire, voit « Merci! » et part. Trois jours plus tard, personne ne l'a rappelé : la demande n'a jamais atteint le CRM. Dans l'autre cas de figure, il a cliqué deux fois sur « Envoyer » et votre équipe a maintenant deux fiches pour la même personne, chacune traitée par quelqu'un de différent.

Ces deux problèmes ont peu à voir avec le choix du logiciel. Ils tiennent à l'ordre dans lequel les choses se produisent et à ce qui est prévu quand l'une d'elles échoue. Cet article présente des principes, pas une recette : le détail dépend de votre formulaire, de votre CRM et de la façon dont votre équipe travaille. Il ne décrit aucun montage que nous aurions testé ou livré, et il ne promet aucun résultat.

Le succès affiché n'est pas la demande reçue

Le message de confirmation à l'écran prouve seulement que le navigateur a reçu une réponse. Il ne dit rien de ce qui a été conservé. Nous proposons donc une définition plus exigeante : une demande est reçue lorsque sa conservation fiable est confirmée, c'est-à-dire qu'elle est enregistrée à un endroit durable, retrouvable par une personne même si tout le reste échoue ensuite.

Trois conséquences pratiques :

• Le message de succès ne s'affiche qu'après cette confirmation. Si l'enregistrement échoue, le visiteur le voit et peut réessayer, ou utiliser une autre voie de contact.
• La création de la fiche dans le CRM vient après la conservation, pas à sa place. Si le CRM est indisponible, la demande existe quand même et peut être transmise plus tard.
• Le courriel de confirmation ne conditionne pas la réception. Un accusé qui échoue ne doit pas faire disparaître une demande valide.

Le principe vaut aussi pour le courriel en général : le protocole SMTP prévoit qu'un serveur qui confirme avoir accepté un message assume la responsabilité de le livrer ou de signaler l'échec (RFC 5321, section 6.1). Autrement dit, la confirmation d'une étape doit correspondre à une responsabilité réellement prise. Un formulaire devrait suivre la même logique.

Les étapes, ce que chacune prouve et comment reprendre

Le tableau suivant est illustratif : il décrit un raisonnement général, pas un montage précis ni un résultat mesuré.

La colonne de droite compte autant que les autres. Une demande qui échoue à l'étape 4 est un incident à traiter, pas une demande perdue : elle est encore à l'étape 2.

Éviter les doublons

Les doublons viennent de deux sources : le visiteur qui envoie deux fois, et votre propre automatisation qui réessaie après une erreur.

Pour les envois répétés du système, une technique courante est la clé d'idempotence : un identifiant unique attaché à chaque demande, qui permet au destinataire de reconnaître une reprise et de ne pas refaire l'opération. À titre d'exemple documentaire seulement (ce n'est pas une recommandation d'outil), l'API de Stripe enregistre le résultat de la première requête portant une clé donnée et le renvoie aux requêtes suivantes avec la même clé; elle compare aussi les paramètres et signale une erreur s'ils diffèrent (Stripe, Idempotent requests). Stripe précise qu'elle peut supprimer ces clés après au moins 24 heures : une reprise tardive ne peut donc pas reposer uniquement sur la mémoire du fournisseur. Un brouillon de l'IETF, expiré et non adopté comme norme, décrit un en-tête HTTP du même genre (Idempotency-Key HTTP Header Field); nous le mentionnons comme piste, pas comme règle.

Pour les personnes déjà connues, il faut décider d'une règle d'identité avant de brancher quoi que ce soit : la même adresse courriel désigne-t-elle le même contact? Que fait-on si la personne écrit pour une autre entreprise, ou avec une nouvelle adresse? Une règle simple (par exemple, mettre à jour la fiche existante plutôt que d'en créer une) est préférable à une règle sophistiquée que personne ne comprend. Gardez une trace de ce qui a été fusionné, et prévoyez qu'une personne tranche les cas ambigus.

Qui voit quoi, et pour combien de temps

Un formulaire transporte des renseignements personnels. Deux questions d'organisation s'imposent avant la mise en service.

L'accès. Qui peut lire les demandes conservées, et qui peut modifier ou supprimer les fiches du CRM? Limitez aux personnes qui en ont besoin, et évitez de multiplier les copies : chaque courriel de notification qui reproduit le contenu du formulaire est une copie de plus à protéger. Les clés d'accès entre le site et le CRM méritent le même soin que n'importe quel mot de passe.

La conservation. Gardez les renseignements aussi longtemps que nécessaire pour la finalité annoncée, puis détruisez-les. C'est un principe qu'on retrouve dans les exigences de la LPRPDE résumées par le Commissariat à la protection de la vie privée du Canada (page en anglais) : limiter la conservation et protéger les renseignements de façon proportionnée à leur sensibilité. Au Québec, la Commission d'accès à l'information regroupe l'information destinée aux entreprises privées, notamment sur le consentement, les mesures de sécurité et la conservation. Nous ne donnons pas d'avis juridique : validez vos obligations précises et votre politique de confidentialité avec les ressources appropriées.

Un dernier point : les renseignements du formulaire n'ont pas leur place dans vos outils de mesure. Pour suivre les formulaires envoyés sans y transmettre de données personnelles, voir notre article sur les rôles de GA4 et de Google Tag Manager et notre page Mesure et analyse.

Garder une personne dans la boucle

L'automatisation couvre bien les cas prévus. Prévoyez donc ce qui est mis de côté pour qu'une personne s'en occupe : une fiche qui n'a pas pu être créée, un doublon possible, une demande sans responsable. Une liste d'exceptions que quelqu'un consulte à un rythme fixe vaut mieux qu'une alerte que personne ne lit.

Le même raisonnement s'applique aux réponses : un accusé de réception standard peut partir automatiquement; une réponse personnalisée, une proposition ou un engagement de prix devrait être relu avant l'envoi. Pour le choix des tâches à automatiser et des points de contrôle, voir Quoi automatiser en premier dans une PME.

Questions fréquentes

Faut-il changer de CRM pour connecter mon formulaire?

Pas forcément. Les principes ci-dessus s'appliquent quel que soit l'outil. Ce qui varie, ce sont les possibilités de votre CRM (connexions offertes, limites d'utilisation, gestion des doublons), à vérifier dans sa documentation.

Un module de connexion suffit-il?

Il peut convenir à un besoin simple, mais vérifiez ce qu'il fait quand le CRM est indisponible et quand la même demande arrive deux fois. Si la réponse est « rien » ou « on ne sait pas », la demande n'est pas protégée.

Comment vérifier que rien ne se perd?

Comparez périodiquement le nombre de demandes conservées avec le nombre de fiches créées, et examinez les écarts. Faites aussi un essai volontaire d'échec : si le CRM est coupé quelques minutes, que devient la demande?

Prochaine étape

Dessinez votre parcours actuel en cinq étapes (saisie, réception, accusé, fiche, suivi) et notez, pour chacune, ce qui se passe en cas d'échec. Les trous apparaissent souvent à ce moment. Pour examiner le besoin avec nous, consultez notre page CRM et intégrations.

Décrivez votre parcours de demandes