Un visiteur peut ouvrir votre page de contact et repartir sans avoir pu vous écrire. Pour savoir où il a été bloqué, vérifiez trois choses dans l’ordre : la page répond, le formulaire devient utilisable, puis la demande arrive chez la personne chargée de la traiter. Chaque résultat oriente vers une correction différente.
Le parcours de demande sur WebOptimizer
Sur la page de demande de WebOptimizer, la page du site charge un script du CRM d’EPNB pour afficher le formulaire. Le 9 novembre 2026, nous avons vérifié les deux adresses publiques. La page et le script ont répondu HTTP 200. Pour vérifier que le formulaire fonctionne, il faut ensuite l’ouvrir dans le navigateur, envoyer une demande d’essai et confirmer sa réception.
Trois contrôles pour localiser le blocage
| Contrôle | Quoi relever | Que vérifier si le test échoue ? |
|---|---|---|
| Accès à la page | Le code HTTP, l’heure et l’adresse testée. | Si la page est inaccessible, vérifier l’hébergement et le dernier déploiement. |
| Chargement du formulaire | Sur mobile, le délai entre l’ouverture de la page et le moment où le premier champ peut être utilisé. | Si le texte apparaît avant le formulaire, examiner le chargement du script et des ressources du service de contact. |
| Réception de la demande | Avec une adresse de test, l’heure d’envoi, la confirmation affichée et l’heure de réception dans la destination prévue. | Si la confirmation apparaît mais que le message manque, vérifier l’acheminement vers la boîte ou l’outil de suivi. |
Pour comparer le chargement avant et après une correction, utilisez la même page et des conditions similaires. Notez l’appareil et la connexion. Faites plusieurs passages et gardez une mesure représentative, par exemple la médiane. Pour le test de réception, utilisez un environnement de test s’il existe. Sinon, convenez d’un créneau avec la personne qui reçoit les demandes et identifiez clairement le message d’essai.
Le guide sur la surveillance des applications web et des API explique comment transformer ces contrôles en alertes. La grille de maintenance du site aide à décider quand refaire les essais, notamment après une mise à jour.
Vérifier la vitesse avec PageSpeed Insights
- Ouvrez PageSpeed Insights, collez l’adresse publique
https://www.weboptimizer.ch/devis/et cliquez sur Analyser. Choisissez l’onglet Mobile. Vous pouvez ensuite refaire la lecture sur ordinateur si ce public compte pour votre site. - Si Google affiche des données de visiteurs réels, vérifiez si elles concernent cette URL ou l’ensemble du site. Elles couvrent les 28 derniers jours. Regardez le LCP (affichage de l’élément principal), l’INP (réactivité aux interactions) et le CLS (déplacements inattendus du contenu). Si les données de cette URL sont insuffisantes, appuyez-vous sur le test simulé pour chercher des pistes.
- Dans le rapport de diagnostic Lighthouse, commencez par le LCP et les ressources chargées au démarrage. Si le texte est visible alors que le formulaire tarde, cherchez le script du CRM d’EPNB et ses requêtes dans le panneau Réseau des outils de développement du navigateur. Vous pourrez voir quand ces ressources se chargent et si l’une d’elles échoue. Le LCP peut correspondre au titre ou à un autre élément de la page, indépendamment du moment où le formulaire devient utilisable.
- Après une correction, relancez l’analyse sur la même URL, dans le même mode. Comparez plusieurs passages Lighthouse et notez la médiane. Reprenez aussi le délai jusqu’au premier champ utilisable, puis faites le test de réception décrit plus haut. Les données des visiteurs réels évoluent au fil de leur fenêtre de 28 jours.
Documentation Google sur les données et diagnostics PageSpeed Insights.
Estimer l’impact avec les données disponibles
Commencez par noter l’heure du premier échec observé et celle du retour à la normale. Si vous disposez de statistiques, relevez les visites de la page de contact et les demandes réellement reçues sur la période. Comparez ces chiffres à des créneaux similaires en tenant compte des différences de trafic. Les visites donnent une idée du nombre de personnes exposées au problème. L’écart entre périodes reste une estimation, car on ignore combien de visiteurs auraient envoyé une demande.
Ce que Vodafone a mesuré
Vodafone a réparti le trafic à parts égales entre deux versions d’une même page. Sur la version optimisée, le LCP mesuré auprès de visiteurs réels est passé de 8,3 à 5,7 secondes. Cette version a enregistré 8 % de ventes supplémentaires et un taux de conversion des visiteurs en prospects supérieur de 15 % par rapport à l’autre version. Étude de cas Vodafone publiée sur web.dev.
Pour le formulaire de WebOptimizer, l’indicateur comparable serait le nombre de demandes effectivement reçues pour 100 visites de la page de devis. Les gains de Vodafone correspondent à son test. Pour estimer l’effet sur WebOptimizer, il faudrait mesurer ce taux sur le parcours de demande.
Pour le référencement, les Core Web Vitals de Google aident à évaluer le chargement, la réactivité et la stabilité visuelle. Le délai avant que le formulaire soit utilisable est une mesure complémentaire pour ce parcours. Une amélioration de ces mesures permet de comparer l’expérience avant et après une correction. Les explications de Google sur l’expérience sur la page précisent la place de ces mesures dans le classement.
Si les demandes n’arrivent plus, rétablissez d’abord leur réception et vérifiez le parcours jusqu’au destinataire. Si elles arrivent mais que le formulaire tarde à devenir utilisable, mesurez ce délai avant et après avoir corrigé la ressource qui le ralentit.