2025-07-02 · Rédaction Baduno · 10 blog.readMin · Blog & Savoir
Polices web pour 24 langues : choix de police, sous-ensemble, performance
Une police qui porte l'allemand, le grec, le maltais et l'arabe ? C'est rare – et quand elle existe, elle est lourde. Stratégies pour un multilinguisme rapide et élégant.
Le problème de couverture
Latin avec tous les diacritiques de l'UE, grec, cyrillique, plus l'écriture arabe : presque aucune famille de polices ne couvre tout correctement. La solution pragmatique est une paire de polices – une famille latin/grec/cyrillique plus une police RTL spécialisée, harmonisées en valeur de gris et en hauteur.
Le subsetting économise massivement
Les polices Unicode complètes pèsent des centaines de kilo-octets. Les sous-ensembles par système d'écriture – chargés uniquement là où nécessaire – les réduisent à des fractions : la version RTL charge la police RTL, la version allemande non.
Chargement sans sauts
font-display:swap affiche immédiatement le texte avec une police système puis échange – les sauts de mise en page sont évités par des fallbacks métriquement compatibles et size-adjust. Hébergé soi-même plutôt que depuis un CDN externe : plus rapide et plus respectueux de la vie privée.
Typographie par système d'écriture
L'écriture arabe nécessite plus de hauteur de ligne et souvent un point de plus ; l'espacement des capitales ne fonctionne qu'en latin. Un système de design qui connaît ces règles par système d'écriture fait d'une mise en page 24 langues – au lieu de 25 compromis.
Polices variables : flexibilité avec obstacles
Les polices variables promettent un nombre réduit de fichiers en regroupant plusieurs variantes (gras, italique, etc.) dans un seul fichier. Pour les sites multilingues avec 24 langues, c'est tentant : au lieu de 24 × 4 = 96 fichiers statiques, seulement 24 variables ? Mais attention : les polices variables couvrant un large éventail de langues (latin, grec, cyrillique, arabe) sont rares et souvent volumineuses. Le subsetting devient en outre plus complexe, car les axes de variation influencent le jeu de caractères. Une police variable subsetée peut nécessiter différents glyphes selon l'expression des axes, ce qui vous oblige soit à conserver tous les subsets, soit à les générer dynamiquement. L'utilisation de polices variables pour une famille de systèmes d'écriture (par exemple latin + grec) et de polices statiques pour l'autre (par exemple arabe) est une approche pratique pour maîtriser la taille des fichiers. Chargez les polices variables via font-weight: 100 900 et font-stretch: 75% 125% au lieu de variantes individuelles – mais testez le rendu dans toutes les langues et tous les navigateurs, car les polices variables peuvent parfois donner des résultats inattendus lors du subsetting et du rastering.
Utilisation conforme des licences de polices dans 24 langues
L'aspect juridique est souvent sous-estimé. Une licence de police couvre généralement un nombre déterminé de visites de pages Web ou un domaine ; avec 24 variantes linguistiques, vous pouvez rapidement atteindre des limites selon la licence. Certains fournisseurs interdisent explicitement le subsetting ou l'intégration dans du contenu dynamique. Assurez-vous que la licence couvre toutes les langues – en particulier les caractères spéciaux comme le İ turc, le Ș roumain ou le Ħ maltais sont souvent considérés comme un jeu de caractères étendu et ne sont pas toujours inclus dans le package standard. Pour les projets européens, une licence Unlimited ou Enterprise est recommandée, qui autorise également le subsetting et l'utilisation multi-domaines. Vérifiez également que la licence de police est valide pour la technologie de police que vous utilisez (par exemple WOFF2). Un outil de conseil en licence (comme Fontstand) peut aider à éviter les conflits – notez les conditions de licence par police dans votre guide de style pour éviter d'avoir à apporter des modifications ultérieures.
Compétition des formats : WOFF2, polices variables subsetées et Unicode-Range
Le choix du format de fichier influence le temps de chargement et la compatibilité. WOFF2 est aujourd'hui la norme et offre une compression environ 30 à 50 % meilleure que WOFF. Si vous utilisez des polices variables, vérifiez que votre navigateur cible prend en charge WOFF2 avec des axes variables (actuellement tous les navigateurs modernes). Pour les navigateurs plus anciens (IE11), vous devez prévoir des fichiers WOFF statiques comme solution de repli. Une astuce efficace : utilisez Unicode-Range dans @font-face pour ne charger que le jeu de caractères réellement nécessaire – similaire au subsetting, mais contrôlé côté serveur. Combinez cela avec font-display: swap ; vous pouvez soutenir l'optimisation du chargement via preload pour les variantes de police critiques (par exemple la police de base pour le latin). Un exemple pratique : pour la page allemande, chargez uniquement le subset latin+umlauts (environ 30 Ko), pour la page grecque le subset latin+grec (environ 50 Ko), pour la page arabe le subset latin+arabe (environ 80 Ko). Ainsi, même avec 24 langues, les téléchargements totaux par visiteur restent inférieurs à 100 Ko de données de polices.
Une police qui porte l'allemand, le grec, le maltais et l'arabe ? C'est rare – et quand elle existe, elle est lourde. Stratégies pour un multilinguisme rapide et élégant.
Assurance qualité automatisée du rendu typographique
Pour éviter que des glyphes ne manquent ou ne soient tronqués dans les 24 variantes linguistiques, intégrez des tests automatisés dans votre pipeline CI/CD. Des outils comme FontProof, Wakamai Fondue ou le script Python fontdiff comparent les captures d'écran rendues de chaque version linguistique avec une capture de référence. Ou utilisez Puppeteer pour ouvrir chaque page, charger la police et vérifier les lacunes (via la propriété CSS font-family: …; font-unicode-range). Plus systématiquement : extrayez tous les points de code Unicode présents dans le HTML par version linguistique et comparez-les aux glyphes du sous-ensemble. Si un caractère manque, le build est interrompu ou un avertissement est émis. Ces tests doivent également vérifier la lisibilité des ligatures ou des caractères alternatifs (par exemple les formes initiales arabes). Intégrez aussi un contrôle du budget de performance : la taille de police par langue ne doit pas dépasser un certain seuil. Ainsi, vous garantissez que le multilinguisme ne se fait pas au détriment du temps de chargement.
Sous-ensemble assisté par IA : efficacité grâce à l'automatisation avec assurance qualité
Gérer manuellement le sous-ensemble pour 24 langues est fastidieux et source d'erreurs. Des outils de build modernes comme glyphhanger ou HarfBuzz peuvent générer automatiquement des sous-ensembles en fonction des caractères réellement présents dans le contenu. Le processus devient encore plus efficace si vous utilisez des modèles d'IA qui prédisent les blocs Unicode nécessaires à partir des versions linguistiques. Un réseau neuronal, entraîné sur des sites web multilingues, peut déterminer avec une grande précision les glyphes requis pour une langue donnée – des caractères latins de base aux extensions cyrilliques en passant par les ligatures arabes. Le sous-ensemble généré automatiquement est ensuite soumis à une vérification manuelle par un locuteur natif pour s'assurer qu'aucun caractère rare mais important (par exemple, citations historiques, caractères spéciaux dans les noms d'entreprise) ne manque. Cette combinaison d'accélération par l'IA et de contrôle humain réduit la création de sous-ensembles de quelques jours à quelques heures, tout en maintenant une qualité élevée. Intégrez le script dans votre pipeline CI/CD afin que les sous-ensembles soient automatiquement régénérés et testés à chaque mise à jour de contenu. Vous assurez ainsi que les fichiers de polices sont toujours à jour sans compromettre les performances de chargement.
Stratégies de repli spécifiques à la langue pour une typographie cohérente
Même avec un sous-ensemble optimal, un fichier de police peut ne pas se charger – en raison d'une erreur réseau, d'une incompatibilité de navigateur ou de restrictions de licence. C'est alors que la pile de repli entre en jeu. Pour 24 langues, une pile de polices globale ne suffit pas : une police système qui convient à l'allemand peut être inadaptée à l'arabe. Définissez donc des piles de repli distinctes pour chaque version linguistique, adaptées aux polices système typiques de la région cible. Utilisez pour cela la fonction CSS @font-face avec unicode-range afin de charger uniquement les caractères réellement nécessaires pour chaque famille de polices. Pour la version arabe, vous pouvez spécifier 'Traditional Arabic' ou 'Tahoma' comme police de repli, pour la version grecque 'GFS Didot' ou 'Times New Roman'. Veillez à la compatibilité métrique : à l'aide de size-adjust et ascent-override, ajustez visuellement la police de repli sur la police principale afin de minimiser les sauts de mise en page. Testez ces polices de repli dans toutes les langues avec une comparaison automatisée de captures d'écran pour garantir la lisibilité même en cas d'erreur. Ainsi, vous évitez les surprises et assurez une expérience utilisateur cohérente sur toutes les variantes linguistiques.
Optimisation côté serveur : auto-hébergement, mise en cache et stratégies CDN
La livraison de polices web via des services externes comme Google Fonts ou Adobe Fonts est pratique, mais présente des inconvénients pour les projets multilingues : premièrement, avec 24 variantes linguistiques, vous devez souvent envoyer plusieurs requêtes à différents serveurs, ce qui augmente le temps de chargement. Deuxièmement, vous ne connaissez pas la stratégie de mise en cache du fournisseur et n'avez aucun contrôle sur les pannes ou la protection des données. C'est pourquoi nous recommandons l'auto-hébergement de tous les fichiers de polices sur votre propre serveur ou sur un CDN dédié. Grâce à l'auto-hébergement, vous pouvez adapter précisément les sous-ensembles de polices à vos versions linguistiques et prioriser les polices critiques à l'aide de HTTP/2 Server Push ou de Preload-Hints. De plus, la mise en cache peut être contrôlée via les en-têtes Cache-Control afin que les polices ne soient chargées qu'une seule fois pour tous les visiteurs d'une version linguistique. Un CDN avec des serveurs Edge proches de vos utilisateurs réduit la latence. Pour 24 langues avec différentes régions cibles, un CDN est essentiel : les utilisateurs en Finlande chargent le sous-ensemble de polices finlandaises depuis un nœud Edge proche, les utilisateurs à Malte de même. Important : mettez en place une règle de cache distincte pour chaque version linguistique, de sorte que, par exemple, le fichier de sous-ensemble allemand soit mis en cache avec une longue durée de validité (p. ex. un an), tandis que vous invalidez le cache lors des mises à jour de polices en modifiant le nom du fichier (empreinte numérique). Vous garantissez ainsi que les polices sont livrées rapidement et sont toujours à jour, sans que les utilisateurs aient à attendre les mises à jour.
Accessibilité et lisibilité : choix de polices pour tous les groupes d'utilisateurs
Le multilinguisme ne se limite pas à afficher correctement les caractères : il faut aussi que la police soit lisible pour tous les utilisateurs, indépendamment de leur acuité visuelle, de la taille de l'écran ou du terminal. Lors du choix de la police, veillez à une différenciation suffisante des lettres, en particulier pour les caractères similaires comme 'rn' vs 'm' ou '0' vs 'O'. Pour les écritures latines, privilégiez les polices sans empattement avec une grande hauteur d'x et des formes ouvertes ; pour les écritures arabes, les polices avec des connexions claires et un espace intérieur suffisant sont importantes. Assurez-vous que la police ne s'effiloche pas et que l'espacement des caractères ne se dégrade pas lors d'un agrandissement à 200%. Utilisez en CSS font-size-adjust: from-font ou définissez des polices de secours explicites avec des proportions similaires pour éviter les sauts de mise en page lors du zoom. Un autre aspect est le niveau de contraste : le texte sur l'arrière-plan doit respecter au moins WCAG-AA (4,5:1), et pour les petites polices, de préférence AAA (7:1). Pour 24 langues, cela signifie : testez chaque version linguistique avec un vérificateur de contraste, car certaines polices perdent du contraste avec certaines épaisseurs de trait ou en italique. La longueur de ligne et l'interligne doivent également être adaptés à chaque langue – les textes arabes nécessitent souvent une hauteur de ligne plus grande que les textes latins. Intégrez ces tests dans votre assurance qualité automatisée (voir section 4) pour garantir que tous les utilisateurs – y compris les personnes âgées ou malvoyantes – puissent saisir optimalement vos contenus.
blog.faqT
Puis-je utiliser Google Fonts pour des sites multilingues destinés à l'UE ?
Techniquement oui, mais problématique sur le plan de la protection des données, car Google collecte les adresses IP des visiteurs. Pour les sites destinés à l'UE, il est recommandé d'utiliser une police auto-hébergée. De plus, Google Fonts ne propose qu'une sélection limitée de polices multilingues ; vous devrez peut-être combiner plusieurs familles, ce qui augmente la charge de chargement.
Comment vérifier si ma police couvre tous les glyphes nécessaires ?
Utilisez des outils comme GlyphChecker ou le test de plage Unicode de Wakamai Fondue. Saisissez les caractères de vos langues cibles (par exemple, le İ turc, le Ș roumain). Alternativement, analysez votre système de gestion de contenu et extrayez tous les points de code Unicode par page linguistique pour les comparer à la police. Vous découvrirez ainsi les lacunes avant la mise en ligne.
