Héberger les polices en local : gain de vitesse et conformité

Chaque appel à fonts.googleapis.com transmet l’adresse IP du visiteur aux serveurs de Google, situés aux États-Unis. Depuis janvier 2022 et la décision du tribunal de Munich, puis les mises en demeure de la CNIL, ce simple chargement de police suffit à rendre un site non conforme au RGPD. Le correctif prend moins de trente minutes : télécharger les fichiers de polices, les placer sur votre propre serveur, et modifier quelques lignes de CSS. Ce guide détaille chaque étape, mesure le gain de vitesse réel, et couvre le cas spécifique de WordPress.

Pourquoi Google Fonts pose un problème de conformité RGPD

Quand un visiteur ouvre une page qui appelle Google Fonts via la balise <link> classique, son navigateur envoie automatiquement une requête HTTP aux serveurs de Google. Cette requête contient plusieurs informations personnelles au sens du RGPD : l’adresse IP, l’en-tête User-Agent (qui révèle le système d’exploitation, le navigateur et sa version), l’en-tête Referer (qui indique la page visitée), ainsi que des cookies éventuels liés au domaine google.com.

Le problème juridique est double. D’abord, ce transfert s’effectue sans consentement du visiteur : la requête part avant même qu’un bandeau cookie puisse être affiché. Ensuite, les données transitent vers des serveurs situés aux États-Unis, ce qui constitue un transfert hors Union européenne soumis à des garanties spécifiques depuis l’invalidation du Privacy Shield par la Cour de justice de l’UE (arrêt Schrems II de juillet 2020).

En janvier 2022, le tribunal régional de Munich a condamné un propriétaire de site à 100 euros de dommages et intérêts pour avoir utilisé Google Fonts en mode distant. Le montant paraît dérisoire, mais le précédent juridique a déclenché une vague de mises en demeure en Allemagne, puis dans d’autres pays européens. Plusieurs cabinets d’avocats ont envoyé des courriers en masse réclamant des indemnisations aux propriétaires de sites utilisant encore Google Fonts sans hébergement local.

La situation est identique pour toute ressource chargée depuis un domaine tiers : polices, scripts d’analytics, widgets de réseaux sociaux. Mais Google Fonts reste le cas le plus fréquent, car la majorité des thèmes WordPress, des templates HTML et des frameworks CSS l’intègrent par défaut. J’ai audité des dizaines de sites en agence, et plus de 70 % appelaient Google Fonts sans que le propriétaire en ait conscience.

Ce que dit la CNIL sur le transfert de données vers Google

La CNIL rappelle sur sa page dédiée aux transferts hors UE que tout transfert de données personnelles vers un pays tiers doit reposer sur un mécanisme juridique valide : décision d’adéquation, clauses contractuelles types, ou consentement explicite de la personne concernée. Le simple chargement d’une police depuis un serveur américain constitue un tel transfert.

En février 2022, la CNIL a mis en demeure un gestionnaire de site français pour son utilisation de Google Analytics, en s’appuyant sur le même raisonnement juridique. Les polices Google Fonts tombent exactement dans la même catégorie : un service gratuit qui transmet des données personnelles à Google sans base légale suffisante. La CNIL n’a pas encore rendu de décision spécifique sur Google Fonts, mais sa doctrine est claire : tout appel vers un serveur américain qui transmet une adresse IP sans consentement viole le RGPD.

Le règlement général sur la protection des données, transposé en droit français via la loi Informatique et Libertés, prévoit des sanctions pouvant atteindre 20 millions d’euros ou 4 % du chiffre d’affaires annuel mondial. Pour un site vitrine de PME, le risque concret se situe plutôt au niveau des mises en demeure individuelles et de l’atteinte à l’image. Mais pour une entreprise qui traite un volume important de visiteurs, la sanction peut devenir significative.

Il faut noter que le Data Privacy Framework adopté en juillet 2023 entre l’UE et les États-Unis a partiellement rétabli un cadre pour les transferts transatlantiques. Cependant, ce cadre reste contesté juridiquement et pourrait être invalidé comme ses prédécesseurs. Héberger les polices en local reste donc la solution la plus sûre à long terme, car elle supprime purement et simplement le transfert.

L’impact réel sur la vitesse de chargement

Au-delà de la conformité, l’hébergement local des polices améliore la performance du site. J’ai mesuré l’impact sur un site WordPress type (thème Starter, 3 polices Google Fonts, hébergeur mutualisé français) avec PageSpeed Insights et WebPageTest. Les résultats sont nets.

Avec Google Fonts en mode distant, le navigateur doit effectuer plusieurs opérations séquentielles : résolution DNS du domaine fonts.googleapis.com, connexion TLS, téléchargement du fichier CSS, puis résolution DNS du domaine fonts.gstatic.com, nouvelle connexion TLS, et enfin téléchargement des fichiers de polices. Ces étapes ajoutent entre 200 et 600 ms au temps de premier affichage, selon la qualité de la connexion.

En hébergeant les polices localement, on supprime deux résolutions DNS, deux négociations TLS et on bénéficie du même domaine que le reste du site. Le navigateur réutilise la connexion déjà établie. Le fichier CSS des polices peut même être intégré directement dans la feuille de style principale, ce qui économise une requête HTTP supplémentaire.

Sur un site déjà lent, le gain est particulièrement visible sur mobile en 3G, où chaque requête vers un domaine tiers coûte cher. Sur une connexion fibre, la différence est moindre mais reste mesurable. Voici les chiffres que j’ai relevés sur le site de test :

• First Contentful Paint : 1,8 s distant → 1,3 s local (gain de 500 ms)
• Largest Contentful Paint : 2,4 s distant → 2,0 s local (gain de 400 ms)
• Requêtes tierces : 4 requêtes supprimées
• Poids transféré : quasi identique (les fichiers WOFF2 pèsent le même poids)

Le gain principal ne vient pas de la taille des fichiers, mais de la suppression de la latence réseau vers des domaines tiers. C’est le même principe que celui décrit dans l’article sur le cache navigateur et serveur : réduire les allers-retours compte plus que réduire les octets.

Télécharger et héberger les polices étape par étape

La migration se fait en quatre étapes simples. Pas besoin d’être développeur : il suffit d’accéder aux fichiers du site via FTP ou le gestionnaire de fichiers de votre hébergeur.

Étape 1 : identifier les polices utilisées

Ouvrez le code source de votre page (Ctrl+U dans le navigateur) et cherchez fonts.googleapis.com. Vous trouverez une ou plusieurs balises <link> comme celle-ci :

<link href="https://fonts.googleapis.com/css2?family=Roboto:wght@400;700&family=Open+Sans:wght@400;600&display=swap" rel="stylesheet">

Notez les noms des polices et les graisses utilisées. Dans cet exemple : Roboto (400 et 700) et Open Sans (400 et 600).

Étape 2 : télécharger les fichiers de polices

Rendez-vous sur Google Webfonts Helper, un outil open source qui génère les fichiers de polices et le code CSS correspondant. Sélectionnez votre police, cochez les graisses dont vous avez besoin, choisissez le jeu de caractères latin (suffisant pour le français), et téléchargez l’archive ZIP.

Si vous préférez ne pas utiliser d’outil tiers, vous pouvez aussi télécharger les fichiers directement depuis le dépôt GitHub officiel de Google Fonts, puis les convertir au format WOFF2 avec un outil comme woff2_compress.

Étape 3 : placer les fichiers sur votre serveur

Créez un dossier /fonts/ à la racine de votre site (ou dans le dossier de votre thème pour WordPress). Décompressez l’archive et placez-y les fichiers .woff2 et .woff. Le format WOFF2 offre une compression environ 30 % supérieure au WOFF, mais le WOFF sert de fallback pour les très anciens navigateurs.

Vous pouvez aussi ne conserver que les fichiers WOFF2 si votre audience utilise des navigateurs récents, ce qui est le cas de plus de 98 % des visiteurs en 2026. Cela réduit le nombre de fichiers à gérer. Pour vérifier la compatibilité de votre audience, consultez les données de votre outil d’analytics ou les statistiques du navigateur dans PageSpeed Insights.

Étape 4 : supprimer l’appel distant

Retirez la balise <link> qui pointe vers fonts.googleapis.com de votre en-tête HTML. Si vous utilisez un thème WordPress, cette balise peut être générée dynamiquement par le thème ; je détaille ce cas dans la section WordPress ci-dessous.

Configurer le CSS pour les polices locales

Une fois les fichiers en place, il faut déclarer les polices dans votre feuille de style avec la règle @font-face. Voici un exemple complet pour Roboto en graisses 400 et 700 :

@font-face {
  font-family: 'Roboto';
  font-style: normal;
  font-weight: 400;
  font-display: swap;
  src: local('Roboto'),
       url('/fonts/roboto-v30-latin-regular.woff2') format('woff2'),
       url('/fonts/roboto-v30-latin-regular.woff') format('woff');
}

@font-face {
  font-family: 'Roboto';
  font-style: normal;
  font-weight: 700;
  font-display: swap;
  src: local('Roboto Bold'),
       url('/fonts/roboto-v30-latin-700.woff2') format('woff2'),
       url('/fonts/roboto-v30-latin-700.woff') format('woff');
}

Quelques points importants sur cette déclaration :

• font-display: swap : indique au navigateur d’afficher immédiatement le texte avec une police système, puis de basculer vers la police personnalisée une fois chargée. Cela évite le flash de texte invisible (FOIT) et améliore le score de performance.
• local('Roboto') : vérifie d’abord si la police est déjà installée sur l’appareil du visiteur. Si c’est le cas, aucun téléchargement n’est nécessaire.
• Ordre des formats : WOFF2 en premier car il est plus léger, WOFF en fallback.

Si vous utilisez plusieurs polices, répétez le bloc @font-face pour chacune. Placez ces déclarations en haut de votre fichier CSS principal, avant toute autre règle qui utilise ces polices. Cela permet au navigateur de découvrir les polices le plus tôt possible dans le processus de rendu.

Pour aller plus loin dans l’optimisation, vous pouvez aussi minifier le CSS qui contient vos déclarations @font-face. Le gain est modeste sur ce type de fichier, mais chaque octet compte sur mobile.

Précharger les polices critiques

Pour les polices utilisées dans le contenu visible immédiatement (au-dessus de la ligne de flottaison), ajoutez une balise <link rel="preload"> dans le <head> de votre page :

<link rel="preload" href="/fonts/roboto-v30-latin-regular.woff2" as="font" type="font/woff2" crossorigin>

L’attribut crossorigin est obligatoire même pour les polices hébergées sur le même domaine : c’est une spécificité du standard Fetch. Sans cet attribut, le navigateur téléchargera la police deux fois.

Ne préchargez que les fichiers de polices réellement utilisés au-dessus de la ligne de flottaison. Précharger trop de fichiers est contre-productif, car cela consomme de la bande passante sur des ressources qui auraient pu attendre. En général, une à deux polices préchargées suffisent.

Cas WordPress : plugins et méthode manuelle

WordPress est le CMS le plus concerné par le problème Google Fonts, car la quasi-totalité des thèmes les intègrent. Deux approches sont possibles : le plugin dédié ou la méthode manuelle via le fichier functions.php du thème enfant.

Méthode plugin : OMGF

Le plugin OMGF (Optimize My Google Fonts) automatise l’ensemble du processus. Il détecte les polices Google Fonts chargées par votre thème et vos plugins, les télécharge sur votre serveur, génère les déclarations @font-face, et supprime les appels distants. L’opération prend moins de 5 minutes.

Après installation et activation, rendez-vous dans Réglages → Optimize Google Fonts. Cliquez sur « Optimize Fonts » et le plugin fait le reste. Vérifiez ensuite dans l’onglet Network du navigateur qu’aucune requête ne part vers fonts.googleapis.com ou fonts.gstatic.com.

Un point de vigilance : certains plugins de cache comme WP Rocket ou W3 Total Cache peuvent mettre en cache l’ancienne version de la page avec les appels Google Fonts. Videz tous les caches après l’optimisation : cache plugin, cache serveur, et éventuellement le cache CDN si vous en utilisez un.

Méthode manuelle : functions.php

Si vous préférez garder le contrôle total, ajoutez ce code dans le fichier functions.php de votre thème enfant (jamais dans le thème parent, car une mise à jour écraserait vos modifications) :

// Supprimer les Google Fonts du thème
add_action('wp_enqueue_scripts', function() {
    wp_deregister_style('google-fonts');
    wp_dequeue_style('google-fonts');
}, 100);

// Charger les polices locales
add_action('wp_enqueue_scripts', function() {
    wp_enqueue_style(
        'local-fonts',
        get_stylesheet_directory_uri() . '/fonts/fonts.css',
        array(),
        '1.0'
    );
});

Le handle exact (google-fonts dans l’exemple) varie selon les thèmes. Pour le trouver, inspectez le code source de votre page et identifiez l’identifiant associé à la feuille de style Google Fonts. Certains thèmes utilisent flavor-google-fonts, theme-fonts ou d’autres noms. Vous pouvez aussi lister tous les styles enregistrés avec la fonction wp_styles().

Si vous gérez votre site avec Git, pensez à ajouter le dossier /fonts/ au dépôt pour ne pas perdre les fichiers lors d’un déploiement.

Thèmes et constructeurs de pages

Certains constructeurs de pages (Elementor, Divi, Beaver Builder) offrent une option intégrée pour désactiver Google Fonts ou les charger localement. Dans Elementor, allez dans Elementor → Réglages → Avancé, et activez l’option « Charger Google Fonts localement ». Divi propose un réglage similaire dans les options du thème.

Si votre constructeur ne propose pas cette option, la méthode plugin OMGF fonctionne dans tous les cas, car elle intercepte les appels au niveau du HTML final.

Vérifier que tout fonctionne après la migration

Après avoir effectué la migration, trois vérifications sont nécessaires pour confirmer que tout est en ordre.

Vérification 1 : aucun appel externe

Ouvrez les DevTools du navigateur (F12), allez dans l’onglet Network, rechargez la page en vidant le cache (Ctrl+Shift+R), puis filtrez par « font » ou cherchez « google » dans la barre de filtre. Aucune requête ne doit apparaître vers fonts.googleapis.com ou fonts.gstatic.com. Si vous en voyez encore, c’est qu’un plugin, un widget ou un bout de code inline charge encore les polices depuis Google.

Vérification 2 : les polices s’affichent correctement

Inspectez un élément de texte dans les DevTools, allez dans l’onglet « Computed » et vérifiez la propriété font-family. Le navigateur doit utiliser la police locale et non une police système de remplacement. Si le texte apparaît en Arial ou Times New Roman, le chemin vers le fichier WOFF2 est probablement incorrect.

Vérification 3 : performance

Lancez un test PageSpeed Insights avant et après la migration pour mesurer l’impact. Vérifiez aussi que les fichiers de polices sont bien servis avec les bons en-têtes de cache. Dans l’onglet Network, cliquez sur un fichier WOFF2 et vérifiez que l’en-tête Cache-Control indique une durée longue (au moins max-age=31536000, soit un an). Si ce n’est pas le cas, ajoutez la règle dans votre fichier .htaccess ou la configuration Nginx :

# Apache (.htaccess)
<IfModule mod_expires.c>
  ExpiresByType font/woff2 "access plus 1 year"
  ExpiresByType font/woff "access plus 1 year"
</IfModule>

Un cache long est justifié car les fichiers de polices ne changent jamais (ou très rarement). Si vous devez un jour mettre à jour une police, changez le nom du fichier pour forcer le rechargement. C’est le même principe de cache busting que celui décrit dans l’article sur le cache navigateur.

Comparatif : Google Fonts distant vs hébergement local

Pour résumer les différences entre les deux approches, voici un tableau comparatif couvrant les critères techniques, juridiques et pratiques :

L’argument historique en faveur de Google Fonts distant était le cache partagé : si un visiteur avait déjà chargé Roboto sur un autre site, le navigateur réutilisait le fichier en cache. Depuis 2020, les navigateurs ont adopté le partitionnement du cache (cache partitioning). Chrome, Firefox et Safari isolent désormais le cache par domaine d’origine. Ce qui signifie que le fichier Roboto chargé depuis le site A n’est plus réutilisé sur le site B. Cet avantage a donc totalement disparu.

L’espace disque consommé par les fichiers de polices est négligeable : un fichier WOFF2 de Roboto Regular pèse environ 25 Ko. Même avec cinq graisses et deux polices différentes, on reste sous les 300 Ko, ce qui ne représente rien sur un hébergement moderne.

La seule contrainte réelle de l’hébergement local est la mise à jour manuelle. Google améliore parfois le hinting ou ajoute des caractères à ses polices. En pratique, ces mises à jour sont rares et rarement perceptibles visuellement. La plupart des sites peuvent conserver les mêmes fichiers de polices pendant des années sans aucun impact.

Et les polices système comme alternative ?

Une troisième option existe : supprimer totalement les polices personnalisées et utiliser la pile de polices système (system-ui, -apple-system, Segoe UI, etc.). Cette approche offre les meilleures performances possibles, puisque le navigateur n’a aucun fichier de police à télécharger. Le texte s’affiche instantanément.

L’inconvénient est esthétique : vous perdez le contrôle sur le rendu typographique, qui variera selon le système d’exploitation du visiteur. Pour un blog ou un site d’information, c’est souvent acceptable. Pour un site qui doit respecter une charte graphique précise, les polices personnalisées hébergées localement restent le meilleur compromis entre performance, design et conformité.

Si la vitesse de votre site reste insuffisante après cette optimisation, pensez à vérifier d’autres facteurs : compression des images, lazy loading, ou encore la version de PHP utilisée par votre hébergeur.