Pourquoi dans ChromeOS 149, Google a glissé un test « Google Services » dans Diagnostics

Vous avez déjà eu ce moment de solitude ? En étant connecté au Wi-Fi, le petit symbole en bas à droite est tout vert, vous arrivez à charger la page d’accueil de votre site d’actualité préféré  ou YouTube sans souci… mais Google Drive refuse de se synchroniser, Google Meet plante au lancement, et Classroom si vous l’utilisez tourne en rond. Vous regardez votre Chromebook, votre Chromebook vous regarde, et personne ne sait quoi faire.

C’est exactement ce trou noir que Google vient de combler avec ChromeOS 149. À partir de cette version, l’application Diagnostics intègre un nouveau test baptisé « Google Services » qui ne se contente plus de vérifier « Internet ou pas Internet », mais qui va beaucoup plus loin : il vérifie si les serveurs de Google sont effectivement joignables depuis votre machine. La nuance est énorme. Et elle explique pourquoi vous galérez parfois alors que tout semble vert.

A retenir :

Découvrez pourquoi ChromeOS 149 intègre le test « Google Services » dans l’app Diagnostics pour identifier les blocages réseau spécifiques vers Drive, Meet ou Classroom.

Pourquoi ce test débarque maintenant ?

La question est légitime. Pendant des années, on s’est contenté du bon vieux test « Internet connecté » et basta. Si ça pingait Google, c’est que tout allait bien. Sauf que l’écosystème ChromeOS a beaucoup changé ces derniers mois, et l’ancien diagnostic ne suffit plus. Voici les trois raisons qui ont poussé Google à ajouter ce nouveau test.

Les pare-feu d’entreprise et d’école : le casse-tête numéro un

C’est de loin la raison principale. Dans une école, dans une entreprise, ou même chez vous derrière un routeur trop zélé, un appareil peut très bien être « connecté au Wi-Fi », afficher fièrement son symbole vert, accéder à des sites web classiques… et être totalement incapable de charger Google Classroom ou Google Drive. Pourquoi ? Parce que l’administrateur réseau a bloqué certains ports ou domaines spécifiques. Genre accounts.google.com, ou les ports UDP nécessaires à Google Meet pour la visio.

Sans le nouveau test, vous tournez en rond. Vous appelez le support, le support vous demande « est-ce que vous avez Internet ?« , vous répondez « oui », et tout le monde reste bloqué. Avec le test « Google Services », on vérifie la portée de ces end-points critiques un par un. Et hop, la conversation devient utile : « Le test DNS passe, le test TLS passe, mais accounts.google.com retourne une erreur. C’est un blocage côté réseau. » Le technicien sait quoi faire.

La dépendance aux micro-services explose (Lacros, Gemini, ARCVM)

Avec la versions 149, ChromeOS a finalisé des changements structurels profonds qui rendent la connectivité aux serveurs Google encore plus critique qu’avant. Trois piliers à connaître :

• Lacros : le navigateur Chrome est désormais séparé de l’OS lui-même. Cette séparation, qui est une excellente nouvelle pour les mises à jour de sécurité, nécessite des connexions constantes pour la synchronisation et la validation. Si la connexion aux serveurs Google se dégrade, c’est tout le navigateur qui devient bancal.
• Gemini Nano : les fonctionnalités d’IA locales (Help me write, résumés, etc.) ont l’air de tourner en local, mais elles dépendent en réalité de vérifications de licence et de téléchargements de modèles via des services Google spécifiques. Pas de connexion au bon endpoint = pas d’IA.
• ARCVM : le conteneur Android (qui fait tourner les applis du Play Store) a besoin d’une connectivité fluide aux serveurs Google Play pour fonctionner correctement. Une interruption mal détectée et vos applis Android se mettent à freezer mystérieusement.

Bref, vérifier qu’on a « Internet » en 2026 sur un Chromebook, c’est comme vérifier qu’une voiture a de l’essence sans regarder l’huile, le liquide de refroidissement et la pression des pneus. Insuffisant.

La consolidation des outils de diagnostic

Auparavant, pour creuser ce genre de problème, il fallait passer par chrome://network (très austère, plutôt réservé aux techos) ou installer l’extension Chrome Connectivity Diagnostics. Deux outils différents, deux interfaces différentes, et le grand public dans les choux.

Google centralise désormais tout dans l’application Diagnostics, accessible directement via Paramètres > À propos de ChromeOS > Diagnostics. Une interface unifiée, lisible, qui parle aussi bien à l’utilisateur final qu’au technicien support. Bonne nouvelle pour tout le monde.

Concrètement, le test vérifie quoi ?

Là où c’est intéressant, c’est que le test ne se contente pas d’un simple « ping » comme on pouvait le craindre. Il effectue des requêtes HTTPS réelles sur une liste pré-définie d’end-points Google. Trois vérifications principales :

• HTTPS Reachability : on vérifie que les certificats TLS peuvent être validés correctement. C’est essentiel contre les attaques « Man-in-the-middle », mais aussi contre des problèmes plus bêtes comme une horloge système déréglée — ouais, une simple date et heure fausses peuvent casser TLS.
• DNS Resolution : on s’assure que votre serveur DNS renvoie les bonnes adresses IP pour les domaines Google. Si vous avez un Pi-hole agressif ou un DNS d’opérateur capricieux, ça se voit ici.
• Latency (RTT) : on mesure le temps de réponse aller-retour. Au-delà de 300 ms, les services comme Google Meet basculent automatiquement en mode dégradé, même si la connexion vous semble « active ». Vous croyez que c’est Meet qui rame, en fait c’est votre latence qui est cuite.

Comment l’utiliser ?

Rien de plus simple. Sur votre Chromebook à jour en ChromeOS 149 ou supérieur :

1. Ouvrez l’application Diagnostics (vous pouvez la chercher dans le launcher, ou passer par Paramètres > À propos de ChromeOS > Diagnostics).
2. Allez dans l’onglet Connectivité.
3. Lancez le test « Google Services ».

Quelques secondes plus tard, vous obtenez un verdict clair pour chaque vérification : Échec ou Réussi.

Note technique importante : si ce test « Google Services » échoue alors que le test « Internet connecté » réussit, le problème ne vient quasiment jamais de Google. Il vient presque systématiquement de votre routeur, de votre VPN, ou d’un filtrage DNS (type Pi-hole, NextDNS, contrôle parental Free, etc.). C’est le premier endroit où aller fouiller. Prochainement un article sur le sujet est à venir.

Cas d’usage concrets

Vous avez un Chromebook en école ou en boîte qui ne synchronise pas Drive ? Lancez le test, vous saurez tout de suite si c’est un blocage admin réseau ou un vrai problème côté Google. Vous avez monté un Pi-hole à la maison¹ pour bloquer la pub et soudain Google Meet ne marche plus ? Le test vous le dira en 5 secondes. Vous êtes derrière un VPN et vos fonctionnalités Gemini Nano ne s’activent pas ? Idem, le test pointera direct vers le bon coupable.

Pour le support technique, c’est une mine d’or. Plus besoin de demander à l’utilisateur de pianoter dans chrome://network en ne comprenant rien,  un test, un screenshot, et le diagnostic est fait.

1. Pi-hole, c’est quoi en deux phrases ?
   
   Pi-hole, c’est un bloqueur de publicité qui fonctionne au niveau du réseau entier de votre maison, et pas juste dans un navigateur. Vous l’installez une fois sur un petit ordinateur (typiquement un Raspberry Pi à 35-50 €), et tous les appareils connectés à votre Wi-Fi en profitent automatiquement : votre Chromebook, votre smartphone, votre télé connectée, votre console, votre tablette, même les appareils des invités. Sans avoir à installer quoi que ce soit dessus.
   
   Comment ça marche, concrètement ?
   
   L’idée est simple et géniale à la fois.
   Quand un appareil veut charger un site web, il commence par demander à un serveur DNS (l’annuaire d’Internet) : « c’est quoi l’adresse IP de google.fr ? ». Le DNS répond, et hop, l’appareil se connecte.
   Pi-hole se met à la place du DNS habituel. Donc maintenant, quand votre Chromebook demande une adresse, c’est Pi-hole qui répond. Et là, deux cas :
   Si le domaine demandé est un site normal (google.fr, lemonde.fr, youtube.com) → Pi-hole renvoie l’adresse comme un DNS classique, le site se charge normalement.
   Si le domaine demandé est un serveur de pub ou de tracking (doubleclick.net, googleadservices.com, googletagmanager.com, facebook.com/tr, etc.) → Pi-hole répond « ce domaine n’existe pas ». Du coup la pub ne se charge jamais. Le site se charge, mais sans ses pubs.
   Pi-hole s’appuie sur des listes de blocage maintenues par des communautés (genre StevenBlack hosts) qui répertorient des dizaines de milliers de domaines connus pour servir de la pub ou du tracking.
   
   Pourquoi les gens en mettent un chez eux ?
   
   Quatre raisons principales :
   Ça bloque la pub partout, sans installer d’extension. Sur votre télé connectée Samsung où vous ne pouvez pas mettre uBlock Origin, Pi-hole bloque les pubs des apps. Sur le smartphone de votre fille qui ne veut pas qu’on touche à son téléphone, Pi-hole bloque les pubs aussi. Sur votre Chromebook, sur la console, partout.
   Ça réduit le tracking. Toutes les pubs et trackers analytics qui chargent en arrière-plan sur les sites web ne se chargent plus. Donc Google Analytics, Facebook Pixel, Criteo et compagnie ne savent plus que vous êtes passé sur tel ou tel site.
   Ça accélère la navigation. Une page web moderne charge souvent 30-50% de son poids en pubs et trackers. Sans tout ça, les pages s’affichent beaucoup plus vite.
   Ça donne des stats marrantes. Pi-hole vous montre un dashboard avec le pourcentage de requêtes bloquées sur votre réseau. Spoiler : c’est entre 15 et 30% en moyenne. Vous découvrez que votre télé « appelle » les serveurs de Samsung 200 fois par jour pour rien.
   
   Ce qu’il faut pour en monter un ?
   
   Pas grand-chose, et c’est ça qui est cool :
   Un Raspberry Pi (modèle 4 ou 5) avec sa carte SD : compter 50-80 € en kit complet.
   Un câble Ethernet pour le brancher à votre box.
   Une prise électrique pour l’alimenter en USB-C.
   Un week-end pour la première install (en réalité 2 heures top chrono pour quelqu’un de débrouillard).
   Une fois installé, ça consomme moins de 3 watts en permanence (genre 5 € d’électricité par an), et ça tourne sans surveillance pendant des années.
   Le souci avec Pi-hole, c’est que les listes de blocage par défaut bloquent parfois trop large. Certains domaines bloqués sont en fait nécessaires au fonctionnement de votre Chromebook (synchronisation Chrome, sécurité Safe Browsing, services Play, Gemini, etc.). Du coup, on peut se retrouver avec un Chromebook qui marche bizarrement sans comprendre pourquoi — alors que c’est juste Pi-hole qui bloque par erreur.
   
   C’est pour ça que dans un prochain article je vous expliquerais :
   
   La liste des listes de blocage modérées à utiliser (et celles à éviter)
   La whitelist Google précise à appliquer (25 domaines à ne pas bloquer)
   La méthode pour diagnostiquer quand Pi-hole casse un service Google
   Bref : Pi-hole, c’est un super outil quand on prend 30 minutes à le configurer proprement. Mal configuré, c’est la galère. ↩︎

Foire Aux Question

Pourquoi mon Chromebook indique-t-il que je suis connecté à Internet mais que Google Drive ne se synchronise pas ?

Il est possible que votre connexion Internet générale fonctionne, mais que des endpoints spécifiques de Google soient bloqués par un pare-feu d’entreprise, d’école, ou un filtrage DNS (comme un Pi-hole ou un contrôle parental). Le nouveau test « Google Services » dans ChromeOS 149 permet de détecter précisément ce type de blocage.

Que vérifie concrètement le test « Google Services » dans ChromeOS 149 ?

Le test effectue des requêtes HTTPS réelles pour vérifier trois points clés : la joignabilité HTTPS (validation des certificats TLS), la résolution DNS (pour s’assurer que les domaines Google pointent vers les bonnes IP), et la latence (le temps de réponse aller-retour) vers une liste définie de services Google.