Morgan Dutemple
Outils Webmarketing

CRO

Comparateur de pages web

Comparez votre page à celles de deux concurrents sur une grille SEO, UX et CRO propre à son type : page d'accueil, catégorie, fiche produit, tarifs, landing page ou tunnel de commande. Choisissez le type de page, la grille et les explications s'ajustent.

Tunnel de commande : 7 critères propres à ce type de page, détaillés sous l'outil.

Cet outil analyse la structure HTML de la page (CTA, formulaires, signaux de confiance, prix, navigation) et sa performance de chargement. Il ne peut pas mesurer un taux de conversion réel : ça nécessite le tracking propre au site analysé (Contentsquare, Hotjar, GA4...), inaccessible sur une URL tierce.

🕵️

Ce que le comparateur vérifie sur un tunnel de commande

Comparez une étape de votre tunnel de commande à deux concurrentes sur des critères SEO, UX et CRO propres au checkout : signaux de confiance, HTTPS, minimisation des distractions, longueur du formulaire.

Poids de chaque critère dans le score UX/CRO

  • HTTPS actif23,5 %
  • Signaux de confiance présents17,6 %
  • Navigation minimale (pas de distraction)17,6 %
  • CTA unique ou peu nombreux (pas de concurrence)17,6 %
  • Peu de champs obligatoires11,8 %
  • Pas de popup détecté au chargement5,9 %
  • Urgence/rareté utilisée avec mesure5,9 %

Le score global mêle ce score UX/CRO (70 %) et la performance mobile mesurée par PageSpeed Insights (30 %).

Ce qui fait réussir un tunnel de commande

Le tunnel de commande est l'étape où l'abandon coûte le plus cher : chaque champ de formulaire, chaque lien de navigation superflu ou chaque signal de confiance manquant y a un impact direct et mesurable. Cet outil analyse une étape précise du tunnel (l'URL fournie), pas l'ensemble du parcours multi-pages : à répéter sur chaque étape si le tunnel en compte plusieurs.

Comment comparer un tunnel de commande

  1. 1Un tunnel de commande a souvent plusieurs étapes (panier, adresse, paiement) : analysez une URL précise à la fois, celle qui vous inquiète le plus
  2. 2Entrez cette URL et jusqu'à deux concurrentes sur la même étape
  3. 3Lancez la comparaison
  4. 4Consultez le détail des critères qui passent ou non, avec le conseil associé

Un exemple concret

Sur une page de paiement type, l'outil relève par exemple un HTTPS correct et un formulaire raisonnablement court, mais aucun logo de moyen de paiement ni mention de garantie de remboursement visible avant validation. Ce sont souvent ces signaux de réassurance de dernière seconde qui déterminent l'abandon, pas la longueur du formulaire.

Votre tunnel de commande rassure-t-il au moment où tout peut basculer ?

Au moment de payer, le visiteur a déjà choisi : il reste seulement à ne pas le perdre. Ce comparateur évalue une étape de votre tunnel face à la même étape chez deux concurrents, sur sept critères de réassurance et de concentration. Il ne mesure ni votre taux d'abandon de panier ni la conformité de votre paiement.

Le HTTPS se juge sur l'adresse que vous saisissez

Le HTTPS est le critère le plus lourd de la grille, environ 23,5 % du score UX/CRO. Il est jugé sur l'adresse saisie, pas sur la page finalement atteinte. Une adresse tapée sans protocole est complétée en https:// et passe. Une adresse collée en http:// échoue, même si le site redirige aussitôt vers la version sécurisée : si ce critère est rouge, relancez avec https:// avant de conclure. Deuxième particularité, plus gênante : l'outil arrive sans session ni cookie. Selon la boutique, une page d'adresse ou de paiement ouverte sans panier peut rediriger ailleurs ou s'afficher vide. L'analyse porte alors sur ce que le serveur renvoie à une visite anonyme, pas forcément sur l'étape que vous vouliez comparer. Choisissez de préférence une étape accessible sans connexion, et comparez des étapes équivalentes chez les concurrents, panier contre panier.

Lire la suite

« Payer » n'est pas un CTA reconnu

Cette grille n'a pas de critère « au moins un CTA » : elle demande entre un et trois CTA reconnus sur la page, pour environ 17,6 %. Or les libellés courants d'un checkout passent mal. « Commander » et « Je commande » sont reconnus, mais « Payer », « Passer la commande » ou « Procéder au paiement » ne le sont pas, et « Valider ma commande » compte comme CTA générique. Une étape de paiement où « Payer » est l'unique intitulé d'action affiche donc zéro CTA et échoue. Les champs obligatoires sont plafonnés à trois, pour environ 11,8 %. Une étape d'adresse en exige presque toujours davantage (nom, rue, code postal, ville) : ce critère y échouera souvent sans qu'il y ait d'excès, et des boutons radio de livraison marqués obligatoires comptent chacun. Enfin, des champs de carte hébergés dans l'iframe d'un prestataire de paiement ne figurent pas dans le HTML de votre page, l'outil ne les voit donc pas.

Réassurance et distractions, sans rien préjuger du paiement

Les signaux de confiance, environ 17,6 %, passent dès qu'une expression comme « paiement sécurisé », « garantie » ou « satisfait ou remboursé » figure dans le code de la page hors scripts, texte visible ou attribut comme alt. Un logo de carte ou de prestataire n'est donc reconnu que si son texte alternatif contient l'une de ces expressions. La navigation doit rester à trois liens au plus dans une balise <nav>, pour le même poids : c'est la ligne qui sanctionne un tunnel qui garde le menu complet de la boutique. Le champ secteur n'agit ici que sur l'urgence, qui pèse environ 6 %. L'outil ne contrôle ni la conformité PCI DSS, ni l'authentification forte, ni les moyens de paiement réellement proposés : un score élevé ne dit rien de ces sujets. Au global, la grille pèse 70 points sur 100, la vitesse mobile 30. Le tunnel n'est jamais parcouru en entier : chaque URL est jugée seule, sans lien avec l'étape précédente. HTTPS, CTA ou autre ligne mal évaluée selon vous : transmettez-moi l'adresse de l'étape et le critère par le formulaire « Un résultat difficile à interpréter ? », juste sous l'outil.

Questions fréquentes

Cet outil mesure-t-il un vrai taux de conversion ?

Non. Un taux de conversion réel nécessite le tracking propre au site (Google Analytics, Contentsquare, Hotjar...), inaccessible sur une URL tierce. L'outil analyse la structure de la page qui corrèle avec la conversion, sans la mesurer directement.

Quel type de page choisir pour ma comparaison ?

Celui qui correspond à la fonction de la page, pas à son modèle technique : page d'accueil pour orienter vers le reste du site, page catégorie pour explorer un catalogue, fiche produit pour vendre un article, page tarifs pour une grille de prix, landing d'inscription ou de lead magnet selon ce que la page demande en échange, tunnel de commande pour une étape du paiement. Chaque type applique sa propre grille : la navigation, par exemple, compte en positif sur une page d'accueil et en négatif sur une landing page.

Comment interpréter un écart de score important avec un concurrent ?

Regardez d'abord le détail des critères, pas seulement le score global : un concurrent peut gagner sur la clarté du CTA tout en perdant sur les signaux de confiance. L'écart pointe les priorités à traiter, pas un jugement d'ensemble sur votre page.

Que veulent dire FCP, LCP, CLS et INP/TBT ?

Ce sont les Core Web Vitals, les indicateurs que Google utilise pour évaluer l'expérience de chargement d'une page. FCP (First Contentful Paint) mesure le temps d'affichage du premier élément visible. LCP (Largest Contentful Paint) mesure le temps d'affichage du plus gros élément visible. CLS (Cumulative Layout Shift) mesure la stabilité visuelle pendant le chargement. INP (Interaction to Next Paint) mesure la réactivité réelle de la page aux interactions ; TBT (Total Blocking Time) en est l'équivalent labo.

Quelle est la différence entre PSI, Lighthouse et CrUX ?

PageSpeed Insights (PSI) est l'API Google utilisée par cet outil. Elle combine deux sources : Lighthouse, un test de laboratoire qui simule un chargement sur un appareil et un réseau standardisés, et CrUX (Chrome User Experience Report), qui agrège les mesures réelles des internautes ayant visité la page avec Chrome. Le score "Performance mobile" de cet outil vient de Lighthouse. Le bloc Core Web Vitals affiche les données CrUX quand elles existent, sinon l'estimation labo Lighthouse.

Pourquoi le bloc Core Web Vitals affiche parfois une estimation labo plutôt que des données terrain ?

CrUX ne renvoie des données que si la page a reçu un trafic Chrome suffisant sur les 28 derniers jours. En dessous de ce seuil, fréquent sur les sites à trafic modeste ou les pages récentes, aucune donnée terrain n'existe : l'outil bascule alors sur l'estimation labo Lighthouse, un test simulé plutôt qu'une mesure réelle.

Pourquoi l'indicateur devient TBT au lieu d'INP en estimation labo ?

INP mesure la réactivité réelle aux interactions des internautes : il ne peut être mesuré que sur du trafic réel, pas sur un test de laboratoire où personne n'interagit avec la page. TBT est l'indicateur labo le plus proche : il estime le temps où la page reste bloquée et incapable de répondre rapidement à une interaction.

Quels critères comptent le plus sur une homepage ?

La présence d'une navigation claire vers les sections clés, un CTA principal identifiable, des signaux de confiance et une lisibilité correcte. Contrairement à une landing page, une navigation présente est ici un signe positif, pas une distraction.

Que faire si ma homepage sert plusieurs audiences différentes ?

C'est un cas fréquent (B2B et B2C, ou plusieurs personas). L'outil ne peut pas juger la pertinence du ciblage, mais il vérifie que chaque parcours proposé reste clair : trop de CTA concurrents pour des audiences différentes dilue l'attention de tous, quel que soit le persona.

Pourquoi la navigation compte-t-elle autant sur une page catégorie ?

Contrairement à une landing page où la navigation est une distraction, une page catégorie doit au contraire faciliter l'exploration et le filtrage : son absence est ici un vrai frein à la conversion.

L'outil détecte-t-il des filtres gérés en JavaScript ?

Non directement : l'analyse porte sur le HTML brut renvoyé par le serveur, pas sur le DOM après exécution du JavaScript. Un système de filtres entièrement dynamique peut donc apparaître comme un manque de navigation alors qu'il fonctionne bien pour l'utilisateur.

La pagination ou le scroll infini sont-ils évalués ?

L'outil ne juge pas ce choix en soi, mais un scroll infini mal implémenté peut réduire le nombre de liens de navigation détectables dans le HTML initial, ce qui peut apparaître comme un signal de navigation faible sans que ce soit toujours le cas en pratique.

Pourquoi vérifier les données structurées sur une fiche produit ?

Les balises Product, Offer et Review/AggregateRating permettent à Google d'afficher des extraits enrichis (prix, note, disponibilité) directement dans les résultats de recherche, ce qui améliore le taux de clic.

L'outil peut-il détecter un prix qui varie selon les options (taille, couleur) ?

Il détecte la présence d'un prix affiché sur la page telle qu'elle est chargée, pas les variantes chargées dynamiquement après un clic. Si vos prix ne s'affichent qu'après sélection d'une option, testez l'URL avec l'option par défaut sélectionnée.

Les avis clients comptent-ils comme signal de confiance ?

Oui, l'outil recherche des mentions d'avis, de notes ou de témoignages dans le contenu de la page. Leur absence n'est pas éliminatoire, mais c'est l'un des signaux de confiance les plus efficaces sur une fiche produit e-commerce.

Que faire si mes prix ne sont pas publics ?

L'outil signale l'absence de prix comme un frein potentiel, mais certains modèles B2B complexes justifient un prix sur devis : à évaluer selon votre contexte commercial, pas comme une règle absolue.

L'outil compare-t-il la pertinence de mes formules entre elles ?

Non, il vérifie la clarté d'affichage (prix, formules, signaux de confiance), pas la stratégie de pricing elle-même. Le choix du nombre de formules et leur positionnement relèvent d'un audit CRO plus poussé.

Sur une page tarifs, l'outil détecte-t-il un toggle mensuel/annuel ?

Il détecte le prix tel qu'il s'affiche au chargement de la page, généralement l'option par défaut du toggle. Si votre page bascule dynamiquement entre mensuel et annuel, le résultat reflète l'état par défaut, pas les deux vues.

Pourquoi la navigation est-elle pénalisée sur une landing page ?

Une landing page d'inscription a un seul objectif de conversion. Une navigation complète offre des échappatoires qui réduisent le taux de complétion du formulaire.

Sur une landing page, le header et le footer du site comptent-ils comme de la navigation ?

Oui, l'outil compte tous les liens de la page, y compris ceux hérités du template global du site. C'est justement l'angle mort le plus fréquent : une landing page dédiée qui garde malgré tout le menu principal du site.

L'outil vérifie-t-il la page affichée après l'inscription ?

Non, l'analyse porte uniquement sur l'URL fournie, donc sur la landing page elle-même. La page de confirmation qui suit la soumission du formulaire (souvent décisive pour la suite du parcours) n'est pas dans le périmètre de cet outil.

Combien de champs un formulaire de lead magnet devrait-il avoir ?

Idéalement un seul (l'email), deux au maximum. Chaque champ supplémentaire réduit mesurablement le taux de conversion sur ce type de page.

Pourquoi pas demander directement plus d'infos pour qualifier le lead ?

C'est un arbitrage légitime, mais chaque champ supplémentaire a un coût en volume de leads. La bonne pratique est de qualifier après coup (email de suivi, scoring comportemental), pas au moment du premier échange contre le contenu.

L'outil évalue-t-il la qualité du contenu proposé en échange de l'email ?

Non, il ne peut pas juger la valeur perçue du livrable lui-même (guide, checklist, webinar). Il vérifie uniquement les critères structurels de la page qui l'entoure : formulaire, CTA, absence de distraction.

Pourquoi le HTTPS est-il vérifié spécifiquement sur un tunnel de commande ?

Sur un tunnel de commande, l'absence de HTTPS est rédhibitoire pour la confiance : la plupart des visiteurs abandonnent immédiatement s'ils voient une alerte de connexion non sécurisée au moment de payer.

Mon tunnel de commande a plusieurs étapes, comment faire ?

Analysez chaque étape séparément (panier, adresse, paiement) en changeant l'URL entrée. L'outil évalue une page à la fois, il ne peut pas reconstituer l'ensemble d'un parcours multi-pages à partir d'une seule URL.

L'outil vérifie-t-il les moyens de paiement proposés ?

Non, il ne peut pas détecter quels moyens de paiement sont réellement intégrés (souvent chargés en JavaScript). Il vérifie en revanche la présence de logos ou mentions de paiement sécurisé dans le contenu de la page, un signal de réassurance distinct.