Si votre site reçoit des visites mais aucun contact, ne commencez pas par acheter plus de trafic ni par refaire le design. Vérifiez que les demandes arrivent réellement, puis localisez la rupture dans ce parcours : arrivée qualifiée, compréhension de l’offre, confiance, clic, envoi et réception. Corrigez le premier maillon défaillant avec une preuve, puis mesurez à nouveau.
Diagnostic préparé en septembre 2026. Les outils, le consentement et le volume de trafic influencent les données disponibles ; aucun taux de conversion universel n’est utilisé ici.
Le formulaire transmet-il réellement les demandes ?
Le premier contrôle est un test complet, sur ordinateur et sur téléphone. Envoyez une demande avec une adresse que vous contrôlez, provoquez une erreur de saisie, puis vérifiez la confirmation, l’e-mail reçu et l’arrivée dans l’outil utilisé par l’équipe.
Un bouton qui affiche « message envoyé » ne prouve pas que la demande a atteint sa destination. Le site peut enregistrer un clic alors que l’envoi échoue, qu’une règle antispam bloque le message ou que la notification arrive dans une boîte que personne ne consulte.
Si la transmission ne fonctionne pas, restaurez-la avant toute analyse éditoriale. Vérifiez aussi le chemin de repli : numéro de téléphone utilisable sur mobile et adresse e-mail correcte.
Où peut se rompre le parcours entre une visite et un contact ?
Un site qui « ne convertit pas » peut échouer à six étapes différentes. Chacune exige un contrôle distinct.
| Étape | Signal à observer | Question de diagnostic | Première décision possible |
|---|---|---|---|
| Arrivée qualifiée | Source, requête, campagne et page d’entrée | Cette personne cherche-t-elle l’offre, une information ou tout autre chose ? | Séparer les segments avant d’acheter plus de trafic. |
| Compréhension de l’offre | Passage vers une page de service et retour d’un test lecteur | Peut-on dire pour qui est l’offre, quel problème elle traite et ce qui suit ? | Réécrire la promesse et relier le contenu à l’offre pertinente. |
| Confiance | Consultation des preuves, objections exprimées | Les éléments présentés réduisent-ils le risque propre à cette décision ? | Ajouter une preuve exacte ou expliciter une limite. |
| Intention | Clic sur l’appel à l’action, le téléphone ou l’e-mail | La prochaine étape est-elle visible, précise et acceptable ? | Clarifier l’action plutôt que multiplier les boutons. |
| Envoi | Début, erreurs et confirmation du formulaire | Les champs, formats et messages permettent-ils de terminer sur mobile ? | Retirer les demandes inutiles et corriger les erreurs. |
| Réception | Demande présente dans la boîte ou l’outil métier | L’équipe reçoit-elle une information exploitable et sait-elle qui répond ? | Réparer l’envoi ou la prise en charge. |
Corrigez la première étape faible. Si les visiteurs qualifiés n’ouvrent pas la page de service, le bouton final n’est pas prioritaire. Si les demandes sont perdues après le formulaire, la promesse ne l’est pas davantage.
Les visites proviennent-elles de personnes susceptibles de vous contacter ?
Le nombre total de visites ne dit pas ce que les visiteurs voulaient faire. Analysez au minimum la source, la page d’arrivée, l’appareil et, pour la recherche Google, les requêtes visibles.
Google distingue Search Console et Google Analytics : Search Console renseigne notamment les impressions, clics et requêtes avant l’arrivée depuis Google ; Analytics décrit les pages et actions sur le site. Les deux outils ne comptent pas de la même façon.
Regroupez ensuite les arrivées selon leur intention :
- une recherche de problème, comme « comment préparer un cahier des charges », n’annonce pas une demande immédiate ;
- une recherche de solution, comme « audit site web », se rapproche d’un choix de prestataire ;
- une recherche de marque, une campagne ou une publication sociale répondent à d’autres contextes.
Une page éditoriale peut attirer beaucoup de lecteurs sans être une mauvaise page. Vérifiez si elle répond à son intention et crée, lorsque c’est pertinent, un chemin vers l’offre. Analysez chaque page d’arrivée au lieu de mélanger guide, accueil, recrutement et service dans un taux global.
Un nouveau visiteur comprend-il l’offre et la prochaine étape ?
La compréhension se vérifie avec des personnes qui ne connaissent pas votre entreprise. Après une lecture courte, demandez-leur d’expliquer : pour qui est l’offre, quel problème elle résout et ce qu’elles feraient ensuite.
Si les réponses divergent, retravaillez le titre, l’introduction, les exemples et l’appel à l’action. « Solutions digitales innovantes » ne permet pas de savoir si vous créez un site, corrigez un logiciel ou animez une formation. Une promesse utile nomme la situation, le résultat attendu et la limite du périmètre.
« Nous contacter » décrit un bouton ; « examiner votre parcours actuel et les données disponibles » décrit l’utilité du premier échange. Affichez aussi les informations demandées et le déroulement réel de la réponse.
Quelles preuves aident réellement un prospect à décider ?
Une preuve utile répond au risque que le prospect perçoit. Pour une refonte, il peut craindre une interruption ou une perte de données. Pour un audit, il peut douter que le livrable débouche sur des priorités exécutables.
Présentez des éléments vérifiables : rôle exact dans un projet, capture autorisée avec son contexte, méthode concrète, résultat daté avec sa source ou témoignage réellement obtenu. Une rangée de logos sans explication n’éclaire pas la décision.
Sans cas publiable, détaillez la méthode et marquez les exemples fictifs comme tels. N’inventez ni résultat ni témoignage.
Quels événements faut-il mesurer dans le parcours de contact ?
Mesurez des actions reliées à une décision. Une profondeur de défilement ne prouve ni une intention commerciale ni une demande.
Pour un site de services, une chaîne minimale peut comprendre :
- affichage de la page d’arrivée ;
- consultation de la page d’offre pertinente ;
- clic sur l’appel à l’action, le téléphone ou l’e-mail ;
- début du formulaire ;
- demande confirmée ;
- demande reçue puis qualifiée par l’équipe.
Google Analytics recommande l’événement generate_lead lorsqu’un utilisateur envoie un formulaire ou une demande d’information. Le nom de l’événement n’est cependant pas la preuve finale : comparez-le aux demandes réellement reçues et documentez son déclenchement.
Si une balise manque, si le visiteur refuse la mesure ou si le formulaire change, l’absence d’événement peut signifier une absence de donnée. Notez ces limites et respectez le dispositif de consentement.
Exemple rempli : un site B2B reçoit des lecteurs mais perd les demandes
Exemple fictif : une entreprise de maintenance industrielle observe 520 sessions sur quatre semaines et aucune demande dans son outil commercial. Elle envisage une nouvelle page d’accueil et une campagne payante.
La vérification du parcours produit ce tableau :
| Observation fictive | Interprétation prudente | Test ou correction décidé |
|---|---|---|
| 360 sessions arrivent sur trois guides très généraux. | Le volume principal est informationnel, pas nécessairement acheteur. | Examiner les requêtes et ajouter un lien contextuel vers le service concerné. |
| 44 sessions consultent la page « contrat de maintenance ». | Le passage du contenu vers l’offre est faible, sans expliquer pourquoi. | Faire expliquer la page par des lecteurs externes et vérifier le chemin mobile. |
| 11 visiteurs cliquent sur « Demander un diagnostic ». | Une intention existe ; le bouton n’est pas le seul problème. | Conserver l’appel à l’action pendant le contrôle du formulaire. |
| 6 formulaires commencent, 2 affichent une confirmation. | Les champs ou les erreurs peuvent bloquer une partie des demandes. | Tester chaque règle, rendre les erreurs explicites et retirer les champs non nécessaires. |
| 1 seule demande apparaît dans l’outil commercial. | La transmission crée une perte après l’action du visiteur. | Réparer l’intégration et ajouter un contrôle de réception. |
Ces chiffres ne sont ni une référence sectorielle ni un résultat Klaapp. La priorité est de réparer la transmission, simplifier le formulaire et relier les guides à l’offre. Plus de trafic amplifierait la fuite.
La page d’accueil peut rester inchangée. L’équipe comparera les mêmes étapes sur des segments similaires, après la réparation technique.
Comment vérifier le formulaire sans le réduire à sa longueur ?
Un formulaire court reste difficile si les libellés sont ambigus ou les erreurs invisibles. Le tutoriel formulaires du W3C recommande de demander uniquement les informations nécessaires et de fournir libellés, instructions, validation et notifications compréhensibles.
Pour chaque champ, demandez si l’équipe utilise la donnée avant le premier échange. Sinon, rendez-le facultatif, reportez-le ou supprimez-le. Si l’information sert à orienter la demande, expliquez le format attendu.
Testez au clavier, sur un petit écran et avec de vraies erreurs. Corrigez aussi tout défaut reproductible de chargement, d’interactivité ou de stabilité. Les Core Web Vitals objectivent ces aspects avec des données terrain, mais un score isolé n’explique ni la qualité du trafic ni la compréhension de l’offre.
Faut-il corriger une page ou refaire tout le site ?
Une correction ciblée suffit lorsque la rupture concerne une page, un appel à l’action, un champ, un message d’erreur ou la transmission. Elle permet d’observer un effet sans changer tout le parcours.
Une refonte devient cohérente si les mêmes problèmes se répètent, si le modèle de contenu empêche de présenter les offres ou si chaque correction technique devient risquée. Comparez alors ce qu’il faut conserver, améliorer ou reconstruire avec une décision de refonte documentée.
Exigez une hypothèse pour chaque changement : observation, action, signal attendu et vérification. « Moderniser le design » n’est pas testable ; « clarifier l’offre et mesurer le passage vers la demande » l’est.
Dans quel ordre prioriser les corrections ?
Priorisez selon l’impact sur un maillon bloquant, la confiance apportée par les preuves et l’effort du test. Une panne d’envoi confirmée passe avant une réécriture intuitive. Une offre incomprise lors de plusieurs tests passe avant une animation.
Appliquez cette séquence :
- réparer ce qui empêche matériellement l’action ou la réception ;
- corriger le premier passage faible du parcours avec le plus de preuves ;
- conserver les autres éléments pour isoler l’effet ;
- vérifier les demandes reçues et leur qualité, pas seulement les clics ;
- élargir la modification seulement si le problème reste structurel.
Klaapp peut accompagner ce diagnostic dans un audit de présence en ligne. Le premier échange définit les pages, les sources et deux ou trois contrôles prioritaires. La conclusion peut être une correction ciblée réalisée par votre équipe ou un autre prestataire.
Questions fréquentes
Quel est un bon taux de conversion pour un site vitrine ?
Il n’existe pas de taux universel exploitable sans contexte. Définissez la conversion, la source, la page d’arrivée, l’appareil et la période. Comparez des segments similaires et la qualité des demandes plutôt qu’un chiffre sectoriel sans périmètre.
Faut-il plus de trafic si le site ne reçoit aucun contact ?
Pas avant d’avoir vérifié la chaîne actuelle. Plus de trafic est pertinent si les visites sont trop rares pour observer le parcours et si la cible, la promesse et la réception fonctionnent. Sinon, il rencontre le même frein.
Comment compter les appels téléphoniques et les e-mails ?
Mesurez les clics téléphone et e-mail comme des intentions, puis rapprochez-les des appels et messages reçus. Un clic ne prouve pas qu’un échange a eu lieu. Documentez aussi les contacts saisis manuellement.
Peut-on diagnostiquer le site sans Google Analytics ?
Oui. Commencez par les demandes reçues, les journaux disponibles, la source d’acquisition, les tests du formulaire et des observations utilisateurs. Un outil facilite la segmentation, mais une configuration non vérifiée donne une fausse certitude.
Sources
- Google Search Central — Utiliser les données de la Search Console et de Google Analytics pour le SEO
- Google Analytics — Événements recommandés
- W3C WAI — Forms Tutorial
- Google Search Central — Comprendre les Core Web Vitals
Valentin Merault est cofondateur de Klaapp. Il intervient sur le cadrage, le produit, l’IHM et l’expérience utilisateur. Découvrir le studio Klaapp.