Test mobile 2026 : outils gratuits et PageSpeed

Google a retiré son test autonome adapté au mobile en décembre 2023, mais vous pouvez encore vérifier l’utilisabilité mobile gratuitement. Utilisez PageSpeed Insights et Lighthouse pour les diagnostics de performance, Chrome DevTools pour les vérifications de mise en page, et un vrai téléphone pour la navigation et les formulaires. Ces vérifications répondent à des questions différentes. Une page rapide peut encore avoir des boutons que vous ne pouvez pas atteindre, et une page utilisable peut encore charger lentement.

Vous voulez le verdict en 20 secondes? Faites tourner notre test adapté au mobile gratuit : collez une URL et obtenez les vérifications de viewport, de largeur fixe, de texte minuscule, de poids et de crawl notées, avec la réparation pour chacune. Aucun courriel.

Quels vérificateurs adaptés au mobile fonctionnent encore en 2026

Le conseil de « faire tourner le test adapté au mobile de Google » est mort. Google a annoncé qu’il mettait fin au rapport d’utilisabilité mobile de Search Console, à l’outil Mobile-Friendly Test et à l’API Mobile-Friendly Test à partir du 1er décembre 2023, et le retrait a été confirmé dans la couverture publique le 4 décembre 2023. La raison énoncée de Google dans cette annonce : l’utilisabilité mobile reste une partie de ses conseils d’expérience de page, mais d’autres ressources ont émergé depuis 2015, « including Lighthouse from Chrome ».

Google a aussi effacé chaque mention de l’outil des documents d’aide Search le 1er décembre 2023 et redirigé les URL d’utilisabilité mobile de Search Console vers l’aperçu de la propriété. Dans l’annonce d’avril 2023, Google pointe les gens vers Lighthouse comme remplacement. Un guide qui offre encore l’outil retiré comme option en direct est périmé.

Un vérificateur séparé reste disponible : le Mobile Friendliness Test Tool de Bing. Il vérifie comment Bing voit la page sur mobile, y compris la configuration du viewport, la largeur du contenu, la lisibilité et l’espacement des tap. Son verdict n’établit pas comment Google ou un assistant IA classera ou citera la page.

L’utilisabilité mobile et l’indexation mobile d’abord sont des vérifications différentes

Google utilise la version mobile du contenu d’une page pour l’indexation et le classement. Ses conseils d’indexation mobile d’abord soutiennent la conception adaptative, le service dynamique et des URL mobiles séparées. La conception adaptative est l’option recommandée parce qu’elle est plus facile à mettre en œuvre et à entretenir.

Vérifiez que Googlebot peut accéder au contenu, aux images et aux métadonnées sur mobile. Puis vérifiez à quel point une personne peut les utiliser facilement. Une page mobile bloquée est un problème de crawl; un bouton à l’étroit est un problème d’utilisabilité. Ni un score Lighthouse ni une mesure de cible de tap seuls ne vous disent si une page sera indexée.

Vous voulez des yeux experts sur votre site plutôt qu’un autre onglet d’audit? Voyez nos services d’optimisation de site.

Faites un audit mobile avec PageSpeed Insights et Lighthouse

Commencez par PageSpeed Insights. Collez une URL, lancez-la, et lisez l’onglet Mobile avant l’onglet Desktop.

Le rapport se scinde en deux moitiés que les gens confondent constamment :

• Données de terrain en haut : de vraies mesures d’utilisateurs Chrome du Chrome UX Report, mises à jour quotidiennement sur une fenêtre glissante de 28 jours. C’est ce que les signaux d’expérience de page de Google utilisent vraiment.
• Données de laboratoire en bas : une seule course Lighthouse simulée sur les serveurs de Google. Utile pour les diagnostics, pas un verdict sur les utilisateurs réels.

Pour passer une évaluation Core Web Vitals complète à trois métriques, une page a besoin du seuil bon au 75e centile pour les trois métriques. Des données de terrain manquantes signifient que le rapport ne peut pas fournir cette évaluation complète; ce n’est pas une preuve que la page a échoué. Lighthouse ne peut pas mesurer l’INP de terrain à partir d’une seule course de navigation.

Source : seuils Core Web Vitals de web.dev, actuels en 2026. L’INP a remplacé First Input Delay (FID) comme Core Web Vital le 12 mars 2024, donc ignorez toute liste qui vous dit encore d’optimiser le FID.

Deux changements de PageSpeed Insights qui ont déplacé les poteaux

Le 5 décembre 2024, PageSpeed Insights a ajusté à quel point il étrangle le processeur, ce qui a généralement augmenté le Total Blocking Time dans les courses de laboratoire mobile. Les résultats de terrain et bureau n’ont pas été touchés. Si votre score de laboratoire mobile a chuté et que rien n’a été livré, c’est une cause plausible.

PageSpeed Insights (PSI) et son API sont passés à Lighthouse 13.0 le 20 octobre 2025. Les versions peuvent changer quels diagnostics vous voyez, donc enregistrez la version Lighthouse avec chaque résultat. Pour une surveillance continue des utilisateurs réels, Google recommande l’API CrUX ou l’API CrUX History : il prévoit de cesser d’inclure les données de terrain CrUX dans l’API PSI.

Y a-t-il un remplacement pour l’API Mobile-Friendly Test?

L’ancienne API Mobile-Friendly Test a été retirée avec l’outil. L’API PageSpeed Insights peut automatiser une course Lighthouse mobile, mais elle ne reproduit pas l’ancien résultat réussi/échoué adapté au mobile. Vous avez encore besoin de vérifications de mise en page et d’interaction.

Cette requête demande des diagnostics de performance, d’accessibilité et de SEO mobile. Remplacez l’URL d’exemple par une page publique que vous voulez tester :

curl --get \
  'https://www.googleapis.com/pagespeedonline/v5/runPagespeed' \
  --data-urlencode 'url=https://example.com/' \
  --data-urlencode 'strategy=mobile' \
  --data-urlencode 'category=performance' \
  --data-urlencode 'category=accessibility' \
  --data-urlencode 'category=seo'

Le guide de démarrage de Google permet d’essayer l’API sans clé et recommande une clé pour les requêtes automatisées fréquentes. Vérifiez le quota actuel de votre projet avant de programmer un lot. Si la réponse est HTTP 429, enquêtez le quota plutôt que de le traiter comme un résultat pour la page testée. La référence de l’API documente les paramètres et les champs de réponse.

Lisez lighthouseResult.categories pour les scores de catégorie et lighthouseResult.audits pour les résultats individuels. Les scores utilisent une échelle de zéro à un; 0,92 correspond à 92 sur 100. Enregistrez fetchTime et lighthouseVersion avec l’URL testée pour que les comparaisons plus tard utilisent une course connue. Traitez les erreurs HTTP et runtimeError avant de traiter une réponse comme un audit.

Pour la performance de terrain, utilisez l’API CrUX ou l’API CrUX History. Une URL peut avoir des données d’utilisateurs réels insuffisantes. Gardez cet état séparé d’un résultat pauvre, et ne rapportez pas un score de laboratoire comme une réussite Core Web Vitals de terrain.

Faire tourner Lighthouse localement

Lighthouse est livré à l’intérieur de Chrome DevTools. Ouvrez votre page, cliquez droit, choisissez Inspect, ouvrez le panneau Lighthouse, sélectionnez Mobile, puis cliquez Generate report. Il tourne contre votre Chrome installé et n’envoie jamais de résultats à un serveur distant, donc vous pouvez auditer les constructions de mise en scène et protégées par mot de passe que PSI ne peut pas atteindre.

Le préréglage mobile n’est pas une conjecture. Lighthouse applique un multiplicateur de ralentissement processeur de 4x pour traîner un processeur de bureau dans la fourchette mobile de milieu de gamme, plus un préréglage réseau « Slow 4G » qui représente le quart inférieur des connexions 4G. L’émulation d’appareil utilise un profil Moto G Power à un viewport de 412 par 823 avec un facteur d’échelle d’appareil de 1,75, mobile et toucher activés, selon le propre constants.js de Lighthouse (une version plus ancienne de cet article citait 2,625, le facteur d’échelle de l’ancien profil Moto G4 que Lighthouse a retiré, pas la valeur actuelle).

Lighthouse 13 a remplacé beaucoup d’audits de performance par des perspectives alignées sur DevTools, gardant unsized-images et non-composited-animations comme diagnostics. Il a aussi retiré l’ancien audit de taille de police. Un diagnostic retiré ne rend pas le texte illisible acceptable; vérifiez le vrai texte de la page sur un téléphone.

Parcours d’émulation d’appareil de Chrome DevTools

Les scores vous disent la vitesse. L’émulation vous dit si la page est utilisable. Faites tourner les deux.

1. Ouvrez la page dans Chrome et appuyez sur le raccourci Inspect, puis basculez la barre d’outils Appareil.
2. Choisissez d’abord un viewport étroit. Testez à 360 par 800 et 390 par 844, puis montez à travers les largeurs de tablette.
3. Réglez l’étranglement à Mid-tier mobile ou appliquez Slow 4G plus processeur 4x manuellement pour correspondre au profil Lighthouse.
4. Tournez en paysage. Ouvrez votre navigation principale, un formulaire, et une étape de paiement ou de contact dans chaque orientation.
5. Regardez le panneau Elements pendant que vous redimensionnez pour trouver quel contenant déborde.

Ce que l’émulation attrape qu’un score n’attrapera jamais :

• De petites cibles de tap entassées contre un voisin, y compris les cas couverts par l’audit tap-targets de Lighthouse
• Un débordement horizontal d’un tableau à largeur fixe, d’un intégration ou d’une image trop grande
• Des en-têtes collants et des bannières de témoins qui mangent la moitié du viewport sur un écran court
• Des fenêtres modales avec un bouton de fermeture poussé hors toile
• Des champs qui déclenchent le mauvais clavier ou un zoom au foyer

Pour des contrôles tactiles confortables, visez 48 par 48 pixels CSS là où la mise en page le permet. La règle documentée de Lighthouse considère à la fois la taille de la cible et le chevauchement avec les cibles voisines; elle ne fait pas échouer chaque contrôle plus petit. Le critère de taille de cible WCAG 2.2 AA séparé utilise 24 par 24 pixels CSS avec l’espacement et d’autres exceptions. Ni l’un ni l’autre n’est un seuil de classement Google universel.

Sachez le plafond. L’émulation redimensionne un navigateur de bureau et feint un processeur lent. Elle ne reproduit pas la latence tactile réelle, les bizarreries de Safari iOS, la portée du pouce, ni la façon dont un Android de milieu de gamme gère un script lourd sous étranglement thermique. Terminez chaque audit sur un vrai téléphone.

Lire les données mobiles Core Web Vitals dans Search Console

L’ancien rapport d’utilisabilité mobile est parti. Utilisez le rapport Core Web Vitals de Search Console pour la performance des utilisateurs réels, puis inspectez la mise en page et les interactions séparément.

Ouvrez Search Console, allez à Core Web Vitals, et travaillez le rapport Mobile. Google scinde l’aperçu par appareil, groupe les URL qui livrent des expériences similaires, et assigne à chaque groupe le statut de sa métrique la moins performante. Donc une mauvaise métrique sur un modèle traîne chaque URL de ce modèle dans Pauvre.

Comment nous le lisons :

• Cliquez Open report à côté du graphique mobile, puis basculez les onglets Poor, Needs improvement et Good.
• Lisez le tableau « Why URLs aren’t considered good ». Il nomme la métrique qui échoue et le seuil franchi.
• Réparez le modèle, pas l’URL. Le statut au niveau du groupe signifie qu’une réparation de modèle déplace beaucoup de pages.
• Utilisez Start Tracking après le déploiement. Google fait tourner une session de surveillance de 28 jours et marque le problème réparé seulement s’il reste absent pendant toute la fenêtre.

Deux mises en garde. Les données sont un agrégat glissant de 28 jours, donc une réparation livrée mardi ne se montrera pas mercredi. Et Google affirme clairement que les données de PageSpeed Insights peuvent varier du rapport Core Web Vitals, parce que l’un est une course de laboratoire sur un profil d’appareil et l’autre est des milliers de vraies sessions. Quand ils ne s’accordent pas, faites confiance aux données de terrain et utilisez la course de laboratoire pour trouver la cause. web.dev explique la scission laboratoire contre terrain plus en profondeur. Les mêmes métriques siègent à l’intérieur de comment nous abordons l’optimisation de site.

Échecs mobiles les plus courants et réparations

Ce sont les échecs que les outils ci-dessus sont bâtis pour attraper, avec le seuil ou la règle que chacun utilise.

Remarquez quel outil détecte quoi. Aucun vérificateur unique ne couvre la liste, c’est exactement pourquoi l’ancien badge unique réussi ou échoué n’a jamais suffi.

L’audit que nous faisons tourner, étape par étape

Voici la séquence que nous utilisons sur notre propre site et sur les sites clients, dans l’ordre.

1. Choisissez trois URL, pas une. Page d’accueil, une page de service ou de produit principale, et un billet de blogue. Les modèles échouent différemment.
2. Search Console d’abord. Core Web Vitals, vue Mobile. Notez quels groupes d’URL siègent dans Pauvre ou Needs improvement et quelle métrique est nommée. Ce sont de vrais utilisateurs, donc ça fixe la priorité.
3. PSI sur une URL de chaque groupe qui échoue. Comparez les données de terrain aux données de laboratoire. Si le terrain dit Pauvre et le laboratoire dit bien, cherchez des scripts tierce, des états connectés, ou des origines lentes qu’une course de laboratoire propre ne voit jamais.
4. Lighthouse localement sur les mêmes trois URL. Préréglage Mobile. Lisez les diagnostics tap-targets et unsized-images, et le panneau Accessibilité pour les échecs de contraste.
5. Mode appareil DevTools à 360 par 800. Ouvrez la navigation, un formulaire, et l’étape de conversion principale. Tournez. Cherchez le débordement et le contenu bloqué.
6. Le test d’adaptation au mobile de Bing sur les mêmes URL pour le verdict d’un second robot d’indexation sur le viewport, la largeur, la lisibilité et l’espacement des tap.
7. Un vrai téléphone, Android de milieu de gamme si vous en avez un. Chargez sur le cellulaire, pas le Wi-Fi de bureau. Complétez l’action de conversion de bout en bout.
8. Livrez les réparations de modèles, puis Start Tracking dans Search Console et attendez 28 jours avant que la validation se vide.

Pourquoi les données de terrain et de laboratoire ne s’accordent pas

Google est explicite que les données de PageSpeed Insights peuvent varier du rapport Core Web Vitals. Les données de laboratoire sont une course simulée sur un profil d’appareil. Les données de terrain sont un agrégat glissant de 28 jours d’utilisateurs Chrome réels. Le guide de web.dev sur les données de laboratoire contre de terrain nomme les causes habituelles : les vrais appareils et réseaux varient plus que le laboratoire, les scripts tierce se comportent différemment pour les utilisateurs réels, le cache et le cache arrière-avant changent les visites de retour, et CrUX ne rapporte que les URL avec assez de trafic. Quand ils ne s’accordent pas, traitez les données de terrain comme le verdict et la course de laboratoire comme le diagnostic.

Quand nous passons en revue un site, nous regardons d’abord les données de terrain de Search Console, puis utilisons PSI et Lighthouse pour nommer l’élément ou le script. Les propres guides d’optimisation de Google sont les playbooks :

• LCP lent : optimiser Largest Contentful Paint. Compressez le héros, servez un format moderne, préchargez l’élément LCP, et ne le chargez pas paresseusement.
• INP élevé : optimiser Interaction to Next Paint. Cassez les longues tâches et différez ou retirez le JavaScript tierce qui bloque le fil principal.
• CLS élevé : optimiser Cumulative Layout Shift. Réglez width, height ou aspect-ratio sur les images et les intégrations pour que la mise en page ne saute pas quand elles chargent.

Search Console groupe les URL qui livrent des expériences similaires et assigne à chaque groupe le statut de sa métrique la moins performante. Une réparation de modèle, comme les dimensions d’image sur un composant de carte partagé, peut déplacer beaucoup d’URL à la fois. Après que vous livrez, utilisez Start Tracking et attendez la fenêtre complète de 28 jours avant que Google marque le problème réparé.

Répétez la séquence en huit étapes après les changements de thème, les installations de plugiciels ou d’applis, et tout déploiement de gestionnaire de balises, plus une passe trimestrielle programmée. Les scripts tierce sont un risque INP documenté dans les conseils INP de Google, c’est pourquoi l’étape 3 compare les données de terrain à une course de laboratoire propre. Pour le crawl, l’indexation et le travail sur la page autour de cette vérification mobile, voyez notre service de référencement.

Et si vous utilisez WordPress ou Shopify

Les deux plateformes vous amènent la plupart du chemin avec de la configuration plutôt que du code :

• Un thème adaptatif, testé à 360 px avant de vous y engager
• Un chargement paresseux natif partout sauf l’image LCP
• Des formats d’image modernes servis aux bonnes dimensions, pas des fichiers bureau rétrécis avec CSS (feuilles de style en cascade)
• Des modèles Shopify Online Store 2.0 et un dimensionnement d’image au niveau de la section
• Un audit des applis et plugiciels installés, puisque chacun ajoute d’habitude du JavaScript qui bloque le rendu

Relancez Lighthouse après chaque changement de thème ou d’appli. C’est là que les scores mobiles glissent silencieusement. Si le thème lui-même est le plafond, la réparation est une reconstruction sur un cadre moderne avec la performance et le SEO conçus dès le départ, c’est ce que notre service de développement de site livre.

Foire aux questions

Comment vérifier l’adaptation au mobile maintenant que le test de Google est parti?

Faites tourner Lighthouse dans Chrome DevTools sur le préréglage Mobile, vérifiez l’onglet Mobile dans PageSpeed Insights, lisez le rapport Core Web Vitals mobile dans Search Console, puis confirmez sur un vrai téléphone. Le test d’adaptation au mobile de Bing donne encore un verdict réussi ou échoué si vous en voulez un.

Quelle est la différence entre adapté au mobile et adaptatif?

Adapté au mobile signifie que la page est utilisable sur un téléphone. La conception adaptative adapte la même page à différents viewports avec des mises en page fluides et des requêtes média CSS. Google recommande la conception adaptative pour un entretien plus facile, mais soutient aussi le service dynamique et des URL mobiles séparées.

Ai-je besoin d’un site mobile séparé?

Non. Une seule URL adaptative est plus simple à entretenir, évite la gestion de contenu en double, et donne un seul ensemble de signaux pour le SEO et l’optimisation pour les moteurs génératifs.

Google pénalise-t-il les sites non adaptés au mobile?

Vérifiez l’accès au contenu et l’expérience utilisateur séparément. Google a besoin d’accéder et de rendre votre contenu mobile pour l’indexation. Les Core Web Vitals sont utilisés dans le classement, mais Google cherche encore du contenu pertinent même quand l’expérience de page est sous la barre. Un score mobile pauvre ne prouve pas à lui seul une désindexation, une pénalité ou une perte particulière de classements.

Pourquoi PageSpeed Insights et Search Console ne s’accordent-ils pas?

Google affirme que les deux peuvent différer. Les données de laboratoire PSI sont une course simulée sur un profil d’appareil. Search Console rapporte un agrégat glissant de 28 jours d’utilisateurs Chrome réels à travers un groupe d’URL. La documentation du rapport Core Web Vitals de Google et l’article laboratoire contre terrain de web.dev vous disent tous deux de traiter les données de terrain comme le verdict et les données de laboratoire comme le diagnostic.

Quatre outils ont remplacé le badge unique

Le badge unique réussi ou échoué est parti et il ne revient pas. Ce qui l’a remplacé est meilleur : la mesure de terrain des utilisateurs réels, un audit de laboratoire que vous pouvez faire tourner en mise en scène, l’émulation de viewport pour la mise en page, et le verdict d’un second robot d’indexation de Bing. Bâtissez votre processus autour de ces quatre, priorisez par ce que Search Console dit que les utilisateurs réels vivent, et réparez les modèles plutôt que les URL individuelles.

Nous gérons cela depuis Vancouver comme optimisation de site. Si la performance mobile vous coûte des classements ou des conversions, un audit de croissance est l’endroit pour commencer.