Tester un site web : comment le vérifier pour que le résultat veuille dire quelque chose

Tester un site web se termine presque toujours de la même façon : quelqu’un colle l’adresse dans un outil gratuit, obtient un chiffre, puis se réjouit — ou appelle le prestataire pour se plaindre.

Le problème, c’est que ce chiffre ne veut généralement rien dire. C’est le résultat d’une seule mesure, sur un appareil simulé, à un moment pris au hasard — et il mesure autre chose que ce sur quoi Google juge réellement votre site.

Ce texte explique comment tester pour que le résultat ait un sens. Il s’adresse à vous si vous recevez un site d’un prestataire, si vous préparez sa mise en ligne, ou si vous voulez savoir si celui que vous avez fonctionne comme vous le croyez.

Pourquoi une mesure isolée ne prouve rien

Commençons par ce qu’aucun guide avec sa liste d’outils ne dit, et qui change la lecture de chaque résultat : le même test sur la même page donne un chiffre différent à chaque fois.

L’écart n’a rien de cosmétique. Dans notre propre procédure de mesure — celle que nous appliquons pour valider chaque modification de performance sur ce site — nous partons explicitement du principe qu’un passage unique de Lighthouse varie d’une dizaine de points. Autrement dit, un score de 78 et un score de 88 peuvent décrire exactement la même page, dans exactement le même état.

D’où trois règles que nous appliquons chez nous et qu’il vaut la peine d’apporter dans la discussion avec votre prestataire :

• Cinq passages au minimum, et vous retenez la médiane — pas la moyenne. Une seule mesure aberrante suffit à déplacer une moyenne ; la médiane, non.
• Même adresse, même appareil, même moment. Comparer un score pris avant la mise en production sur un ordinateur avec un score pris après sur un téléphone, ce n’est pas une comparaison.
• Sans chiffres avant et après, ce n’est pas une amélioration de performance. Chez nous, une modification présentée comme une accélération mais sans mesure avant et après n’est pas acceptée comme une accélération.

La conséquence pour vous est immédiate. Si quelqu’un vous montre une seule capture d’écran avec un score vert pour prouver que le site est rapide — ou une seule avec un score rouge pour prouver qu’il est cassé — ce n’est pas une preuve, c’est une mesure tirée au sort. Demandez-en cinq.

Mesure de laboratoire et données des vrais visiteurs : deux choses différentes

C’est la distinction que la plupart des propriétaires de sites ne font pas, et c’est elle qui décide si votre score a le moindre rapport avec l’évaluation de Google.

La mesure de laboratoire, c’est Lighthouse et ce que vous voyez dans PageSpeed Insights sous forme de score. La page est chargée une fois, sur un appareil simulé, avec une connexion simulée. C’est un outil de diagnostic : il dit ce qui ralentit concrètement la page et par où commencer. Il est excellent pour cela, et c’est pour cela qu’il faut l’utiliser.

Les données des vrais visiteurs, c’est le Chrome UX Report — un jeu de données qui, selon la documentation de Chrome, « reflète la façon dont les utilisateurs réels de Chrome vivent les destinations populaires du web » (notre traduction). Ce n’est pas une simulation : ce sont vos visiteurs, sur leurs téléphones, avec leur réseau. Et c’est sur ces données-là que se jugent les seuils présentés plus bas — selon Google, au 75e centile des chargements, séparément pour le téléphone et pour l’ordinateur.

Le 75e centile signifie ceci : ce qui compte n’est pas la façon dont vos trois visiteurs les plus rapides voient le site, mais la façon dont le voit le quart le plus lent. Votre test sur la bonne connexion du bureau se situe, par définition, du côté rapide de la distribution.

Vient maintenant une réserve qui concerne la plupart des sites d’entreprise, et qu’on n’entend presque jamais. N’entrent dans le CrUX que les adresses qui remplissent des critères d’éligibilité : la page doit être publiquement accessible et, pour citer la documentation, avoir « un nombre de visiteurs suffisant pour constituer un jeu de données statistiquement significatif ». Google ne dit pas combien cela représente.

En pratique : si votre site a peu de trafic, les données des visiteurs n’existent tout simplement pas. PageSpeed Insights ne vous montre alors que le score de laboratoire, et rien d’autre. Ce n’est pas une panne, et cela ne veut pas dire que le site est mauvais — cela veut dire que la seule mesure dont vous disposez est la mesure de diagnostic, et qu’elle se lit comme une indication, pas comme une note.

Les trois chiffres que mesure Google, et leurs seuils

Les Core Web Vitals sont trois métriques. Leurs seuils sont précis et publiés, il n’y a donc aucune raison de deviner (web.dev, vérifié le 21 septembre 2026) :

Deux choses à retenir. L’INP a remplacé l’ancienne métrique FID et il est une métrique stable depuis 2024 — si vous voyez encore le FID dans une offre ou un rapport, ce document n’est plus à jour. Et la seconde : le CLS ne mesure pas la vitesse. Il mesure si le contenu bouge sous le doigt — la situation où vous touchez un bouton au moment précis où une bannière finit de se charger, et où vous touchez autre chose. C’est une métrique de l’agacement, pas du temps, et c’est souvent elle qui plombe le résultat des sites qui « se chargent pourtant vite ».

Chacune des trois se dégrade en général pour une raison différente, et mieux vaut le savoir avant de se mettre à deviner :

• Le LCP est le plus souvent ruiné par une seule grande photo en haut de page — celle qui doit faire impression. Elle est d’ordinaire dans le mauvais format, dans une résolution prévue pour un grand écran, et elle se charge sur un téléphone.
• L’INP souffre d’un excès de scripts : extensions, outils marketing, fenêtres de chat, bannières de consentement. Chacun est petit ; ensemble, ils occupent le processeur exactement au moment où quelqu’un essaie de cliquer.
• Le CLS est dégradé par le contenu sans place réservée — une image, une bannière ou une publicité qui arrive plus tard et pousse tout ce qui se trouve en dessous.

Remarquez que deux causes sur trois ne sont pas la faute « du site », mais de ce qu’on lui a ajouté après la mise en ligne. C’est la raison la plus fréquente pour laquelle un site ralentit avec le temps alors que personne n’y a touché.

Pour voir ces trois chiffres pour votre propre adresse, nous proposons un test de vitesse de site web qui les récupère. Quant à l’optimisation elle-même — ce qu’il faut faire quand les résultats sont mauvais — nous la traitons dans un texte à part.

Vérifier un site internet avant la mise en ligne : quatre points

La plupart des erreurs coûteuses se voient une demi-heure avant la publication, à condition de savoir où regarder. Quatre points, classés de l’erreur la plus chère à la moins chère :

1. Le site peut-il seulement être indexé ? L’erreur de mise en production la plus coûteuse de cette catégorie consiste à laisser en ligne le blocage d’indexation de la phase de test. Le site fonctionne, il est beau, et il est invisible pour le moteur de recherche. La vérification prend une minute : dans la Search Console, avec l’outil d’inspection d’URL.

2. Les adresses concordent-elles ? Si le nouveau site en remplace un ancien, chaque ancienne adresse doit mener à son équivalent. C’est le seul point de cette liste dont la négligence coûte durablement — les positions perdues ne reviennent pas toutes seules.

3. Les formulaires arrivent-ils ? Ce point a sa propre section plus bas, parce que c’est le seul test qu’aucun outil ne fera.

4. Le site fonctionne-t-il sur un téléphone, dans des conditions réelles ? Ce point aussi a sa section, parce que « fonctionne sur téléphone » ne veut pas dire la même chose dans un aperçu et dans un train régional.

La liste complète à cocher se trouve dans notre check-list de mise en ligne. Si en revanche vous examinez un site en ligne depuis longtemps et que vous voulez savoir ce qui ne va pas, c’est un autre travail — il s’appelle un audit, et nous l’avons décrit à part, y compris les cas où il ne vaut pas la peine de le commander.

Deux ou trois langues : la même liste, autant de fois

Ici, un site d’entreprise existe rarement dans une seule langue. La version française cohabite avec l’allemande, souvent avec l’anglaise — et chaque version linguistique est un site à tester, pas une traduction à relire. Les pannes de ce type se logent presque toujours dans la version que l’équipe n’utilise pas au quotidien.

Quatre vérifications à refaire pour chaque langue :

• Le blocage d’indexation est levé partout. Il arrive qu’une version linguistique ajoutée plus tard garde le réglage de la phase de test alors que la première a été ouverte depuis longtemps.
• Les redirections existent dans chaque langue. Un site qui change de structure a autant de jeux d’anciennes adresses que de langues, et ce sont les versions secondaires qu’on oublie.
• Le formulaire de chaque version arrive au bon endroit, et la confirmation part dans la bonne langue. Un client qui écrit en français et reçoit un accusé de réception en allemand se demande à juste titre si quelqu’un le lira.
• Le cache sert la bonne langue. Ouvrez chaque version dans une fenêtre de navigation privée, deux fois de suite. Si la seconde ouverture affiche la page dans une autre langue, le cache ne tient pas compte de la langue demandée — le mécanisme est expliqué dans notre texte sur l’hébergement.

Tester un site web sur un téléphone : un aperçu n’est pas un test

C’est ici que se loge l’erreur la plus fréquente, et elle est technique, pas organisationnelle : le mode appareil mobile du navigateur n’est pas un téléphone. Il change la largeur de la fenêtre et le type d’appareil déclaré, mais le calcul se fait toujours avec votre processeur, votre connexion et votre cache. Un site qui tourne sans accroc dans cet aperçu peut être tout autre chose sur un téléphone de quatre ans, avec une mauvaise réception.

Cela compte davantage qu’il n’y paraît, parce que Google indexe les sites par leur version mobile : c’est la version récupérée avec l’agent smartphone qui sert à l’indexation et au classement. La version grand écran peut donc être superbe sans que cela change quoi que ce soit.

Le test qui dit réellement quelque chose se déroule ainsi, et prend un quart d’heure :

• Prenez un vrai téléphone, de préférence pas le vôtre. C’est sur le matériel que personne dans l’équipe n’utilise — plus ancien, avec moins de mémoire — qu’on voit le plus de problèmes.
• Coupez le wi-fi. Testez sur les données mobiles, de préférence hors du bureau.
• Suivez le parcours d’un client, pas la page d’accueil. Arrivée, offre, contact, envoi d’une demande. La page d’accueil est presque toujours la plus soignée, et c’est celle qui en dit le moins.
• D’une seule main. S’il faut deux mains et un zoom pour envoyer une demande, le formulaire est à revoir, quel que soit le score affiché par n’importe quel outil.

Le formulaire : le seul test qu’aucun outil ne fera

Aucun outil ne vérifiera si la demande d’un client vous parvient. Il faut en envoyer une vraie et contrôler trois points, parce que chacun peut lâcher séparément, et en silence.

1. Le message arrive-t-il dans la boîte, et non dans les indésirables ? C’est la panne silencieuse la plus courante : le formulaire fonctionne, affiche un remerciement, et le message atterrit dans un dossier que personne n’ouvre. Contrôlez la boîte de réception et le dossier des indésirables, et si les demandes partent vers une adresse collective, vérifiez que quelqu’un la lit réellement.

2. Le client reçoit-il une confirmation ? Du point de vue de celui qui écrit, l’absence de confirmation ne se distingue pas d’une panne. Une partie des gens renvoient la demande, une autre abandonne et écrit à quelqu’un d’autre. Un accusé de réception automatique coûte peu et supprime toute cette catégorie de pertes.

3. La protection anti-spam ne bloque-t-elle pas de vraies personnes ? C’est la panne la plus difficile à remarquer, parce que chez vous, tout fonctionne — vous testez depuis votre bureau, depuis votre adresse. Des mécanismes comme reCAPTCHA ou Turnstile peuvent rejeter les demandes de personnes qui passent par un VPN, qui utilisent un navigateur plus ancien ou une connexion mobile à adresse partagée. Aucun rapport ne vous le montrera, parce qu’une demande bloquée ne laisse aucune trace de votre côté. Le test : demandez à quelqu’un d’extérieur à l’entreprise d’écrire depuis son téléphone, sur les données mobiles.

Ce contrôle mérite d’être répété régulièrement, pas une seule fois après la mise en ligne — les formulaires se cassent tout seuls, lors d’un changement d’hébergement, de l’expiration d’une clé ou de la mise à jour d’une extension. C’est précisément le rôle du monitoring.

Recevoir le site d’un prestataire : quoi vérifier avant de signer

C’est le moment où le test a le plus de valeur et la durée de validité la plus courte. Après la réception et le paiement de la dernière tranche, chaque correction devient une nouvelle discussion ; avant la réception, elle fait partie du contrat.

Six points, dans cet ordre, tous à vérifier par vous, pas par le prestataire :

• La demande envoyée par le formulaire arrive, et vous en avez la preuve. Envoyée de l’extérieur, depuis le téléphone de quelqu’un d’autre, sur les données mobiles. Les trois points de la section précédente.
• Le site est visible pour le moteur de recherche. Le blocage d’indexation de la phase de test est levé — vérifié dans la Search Console, pas sur parole.
• Les anciennes adresses mènent aux nouvelles. S’il remplace un site précédent, contrôlez à la main une quinzaine des adresses les plus importantes. Pas « y a-t-il des redirections ? », mais : ces anciennes adresses précises ouvrent-elles les bonnes nouvelles pages ?
• Cinq mesures, pas une, et leur médiane notée quelque part. C’est votre point de référence pour l’avenir — sans elle, dans un an, vous ne pourrez pas prouver que quelque chose a ralenti.
• Le parcours client a été suivi sur un vrai téléphone, hors du bureau — dans chaque langue du site.
• Les accès sont à votre nom. Domaine, hébergement, compte administrateur, licences. Ce n’est pas un test, mais cela se vérifie au même moment et pour la même raison : plus tard, cela devient parfois une négociation plutôt qu’un réglage. Nous le développons à propos de la couche d’édition.

Une chose à demander explicitement, et qui ne coûte rien : la liste de ce que le prestataire n’a sciemment pas fait. Chaque mise en production en comporte — reporté à plus tard, convenu oralement, sorti du périmètre. Écrit, c’est une information. Non écrit, cela revient dans six mois sous la forme d’un désaccord sur ce qui était compris dans le prix.

Lesquelles de vos cinquante remarques comptent vraiment

Chaque outil de diagnostic produit une longue liste, et c’est son plus grand défaut : la liste laisse entendre que tout ce qu’elle contient est à faire. Ce n’est pas le cas.

Trois questions la ramènent à l’essentiel :

Le visiteur le voit-il ? Une remarque sur le format des images de la page d’accueil concerne chaque personne qui arrive. Une remarque sur un en-tête du serveur ne concerne personne que vous connaissiez. Commencez par la première catégorie.

Cela concerne-t-il le téléphone ? Puisque l’indexation passe par la version mobile et que le quart le plus lent des visiteurs décide de l’évaluation, un problème visible seulement sur ordinateur passe après un problème visible seulement sur téléphone.

Cela se répète-t-il, ou est-ce arrivé une fois ? C’est ici que revient la règle des cinq mesures : une remarque qui apparaît dans un passage sur cinq est du bruit. Celle qui apparaît dans chacun est un défaut.

Après ce tri, il reste en général trois à cinq remarques sur cinquante qui valent d’être commandées — et c’est avec cette liste qu’on va voir le prestataire. Pas avec le rapport.

Quand vérifier soi-même, et quand confier le test

Vous en ferez vous-même davantage que vous ne le pensez, et il vaut la peine d’en profiter avant que quiconque n’établisse une facture. Les quatre points avant la mise en ligne plus cinq passages de mesure, c’est un vrai diagnostic en deux heures, sans aucune connaissance technique.

Confier le test a du sens dans trois situations : quand le site doit apporter des demandes et n’en apporte pas, sans que vous sachiez pourquoi ; quand vous recevez un projet important et qu’il vous faut quelqu’un de votre côté de la table ; et quand le résultat de la mesure est mauvais et que vous ne savez pas laquelle des causes est la plus coûteuse — parce que l’outil aligne cinquante remarques sans dire lesquelles comptent.

Ce que la sous-traitance ne réglera pas : si le problème est dans le contenu ou dans l’offre, aucun test technique ne le montrera. Un site tout vert qui n’apporte aucune demande n’a pas un problème de performance — c’est une question de mesure de ce que les gens y font, et elle commence ailleurs : par les données, pas par les outils.