Google Fonts et RGPD : l’illégalité qui se corrige en dix minutes

C’est la dépendance américaine la plus répandue du web européen, et la plus absurde : pour afficher du texte, des millions de sites envoient l’adresse IP de chacun de leurs visiteurs aux serveurs de Google. La justice allemande a jugé cette pratique contraire au RGPD dès 2022. Bonne nouvelle : c’est aussi la dépendance la plus rapide à éliminer.

Ce que dit le droit

Le 20 janvier 2022, le tribunal régional de Munich (LG München I, aff. 3 O 17493/20) a condamné l’exploitant d’un site web qui chargeait ses polices depuis fonts.googleapis.com. Le raisonnement est simple : quand la police est servie par Google, le navigateur du visiteur contacte les serveurs de Google et leur transmet son adresse IP. Or l’adresse IP est une donnée personnelle. Ce transfert vers une société américaine, sans consentement et sans nécessité (les polices peuvent être hébergées localement), viole le RGPD. Le tribunal a accordé 100 euros de dommages-intérêts au plaignant, et surtout créé un précédent : des vagues de mises en demeure ont suivi en Allemagne et en Autriche.

La logique vaut au-delà du cas allemand : la CNIL a rappelé à plusieurs reprises que l’utilisation de ressources tierces transférant des données vers les États-Unis sans encadrement approprié pose problème depuis l’arrêt Schrems II. Et indépendamment du droit : chaque page vue signale à Google qui visite votre site, quand, et depuis où. Pour afficher une police.

Vérifier si votre site est concerné

Ouvrez votre site, puis l’onglet « Réseau » des outils de développement de votre navigateur, et cherchez fonts.googleapis.com ou fonts.gstatic.com. Plus simple : lancez un audit sur notre outil, la règle « Google Fonts chargé depuis les serveurs Google » retire 10 points au score et liste les requêtes exactes en preuve.

Attention aux sources indirectes : un thème WordPress, une bibliothèque d’icônes, un widget de réservation ou une iframe peuvent charger Google Fonts à votre insu. C’est souvent là que se cache la requête restante après une première migration.

Option 1 : auto-héberger vos polices (recommandé)

La solution la plus propre : servir les fichiers de polices depuis votre propre domaine, comme n’importe quel autre fichier statique. Zéro tiers, zéro requête externe, et de meilleures performances (une connexion de moins à établir pour le navigateur).

1. Téléchargez les fichiers .woff2 de vos polices. Deux outils font le travail en une minute : google-webfonts-helper (interface web qui génère l’archive et le CSS) ou Fontsource (paquets npm, un par police).
2. Placez les fichiers dans votre dossier de fichiers statiques.
3. Déclarez les polices dans votre CSS :

@font-face {
  font-family: "Ma Police";
  src: url("/fonts/ma-police-v12-latin-regular.woff2") format("woff2");
  font-weight: 400;
  font-style: normal;
  font-display: swap;
}

Supprimez ensuite la balise <link> vers fonts.googleapis.com et l’éventuel preconnect associé. Les licences des polices du catalogue Google Fonts (SIL OFL ou Apache pour l’essentiel) autorisent explicitement l’auto-hébergement.

Option 2 : laisser votre framework le faire

Les frameworks modernes ont industrialisé l’auto-hébergement. Avec Next.js, le module next/font télécharge les fichiers au moment du build et les sert depuis votre domaine : aucune requête vers Google en production, sans rien gérer manuellement.

import { Instrument_Sans } from "next/font/google";

const body = Instrument_Sans({ subsets: ["latin"] });

L’équivalent existe ailleurs : Fontsource s’intègre à n’importe quel bundler, et la plupart des générateurs de sites statiques ont un module dédié. Sur WordPress, le plugin OMGF rapatrie automatiquement les polices des thèmes et extensions.

Option 3 : Bunny Fonts, le remplacement en une ligne

Si vous ne pouvez pas auto-héberger (CMS verrouillé, site géré par un tiers), Bunny.net, société slovène, propose Bunny Fonts : une API compatible avec celle de Google Fonts, sans journalisation des adresses IP. La migration tient dans un remplacement de domaine :

<!-- Avant -->
<link href="https://fonts.googleapis.com/css2?family=Karla" rel="stylesheet">

<!-- Après -->
<link href="https://fonts.bunny.net/css?family=karla" rel="stylesheet">

Vous gardez une dépendance externe, mais européenne et conçue pour ne pas exploiter les données. C’est un bon premier pas, l’auto-hébergement restant la cible.

Les pièges classiques

• Le CSS importé : un @import vers Google Fonts peut se cacher au fond d’un fichier CSS de thème, pas dans le HTML.
• Les contenus embarqués : une vidéo YouTube ou une carte Google Maps intégrée rechargera des ressources Google, polices comprises. C’est un sujet distinct, mais le même réflexe s’applique.
• La vérification d’après : re-testez après déploiement. Une seule requête oubliée suffit à maintenir le transfert.

Dix minutes, dix points

Peu de chantiers de conformité offrent ce ratio : une demi-heure de travail au pire, un risque juridique documenté en moins, des performances en plus, et dix points gagnés sur votre score de souveraineté. Relancez l’audit après la migration : la règle doit avoir disparu du rapport.