Comment éviter la rupture des glyphes lors de l’optimisation des polices d’un site web en arabe

L’apparition de « ruptures de glyphes » sur une page web en arabe n’est généralement pas due à l’endommagement d’un seul fichier de police, mais au repli de police, à l’absence de capacité de mise en forme des glyphes (shaping) ou à un processus de traitement du texte qui rompt les relations contextuelles de l’écriture arabe. Les caractères arabes changent de forme selon qu’ils se trouvent au début, au milieu ou à la fin d’un mot, ou qu’ils sont isolés ; si le navigateur ne traite pas les caractères consécutifs avec la même police, la même direction et les règles de rendu appropriées, les lettres peuvent apparaître séparées, les ligatures être interrompues, la position de la ponctuation devenir anormale et même l’ordre des chiffres être perturbé.

Par conséquent, l’optimisation des polices d’un site en arabe ne doit pas seulement vérifier si la page peut afficher des caractères arabes, mais aussi si la police, le CSS, le système de contenu et les appareils cibles prennent conjointement en charge la liaison normale de l’écriture arabe. Lors de l’évaluation technique, il est généralement plus efficace de vérifier en priorité la couverture des polices et la chaîne de repli, puis la mise en page RTL et le processus de sortie du texte, plutôt que de simplement remplacer la police.

Distinguer d’abord : caractères manquants dans la police ou problème de mise en forme du texte

Les manifestations des ruptures de glyphes arabes sont similaires, mais les méthodes de traitement diffèrent. Lorsqu’une police ne contient pas certains caractères, le navigateur utilise automatiquement une police système pour les compléter ; si les caractères d’un même mot sont répartis entre différentes polices, leurs formes de liaison peuvent ne pas être cohérentes. Dans un autre cas, la police contient les caractères arabes, mais ne dispose pas des règles typographiques OpenType appropriées, ou l’environnement de la page n’exécute pas correctement la mise en forme des glyphes : les caractères existent alors, mais ne peuvent pas être liés selon le contexte.

Un point facile à mal interpréter est le suivant : une capture d’écran qui « ressemble à de l’arabe » ne signifie pas que la page peut être mise en ligne. Les mots de test ne doivent pas se limiter à des mots courts ou à des caractères isolés ; ils doivent inclure des mots courants avec différentes positions de liaison, au début, au milieu et à la fin, tout en couvrant les contenus mixtes avec voyelles diacritées, chiffres arabes, modèles en anglais, parenthèses et symboles monétaires. Les paramètres produits, tableaux de devis et champs de formulaire des sites de commerce extérieur sont précisément les zones où les problèmes apparaissent le plus facilement.

Le choix d’une police doit se fonder sur une prise en charge linguistique complète, et pas seulement sur le style visuel

De nombreux projets partent d’une police latine, puis confient les caractères arabes à la police par défaut du navigateur. Cette approche passe facilement inaperçue sur les pages en anglais, mais peut entraîner des ruptures, des variations de graisse et des hauteurs de ligne incohérentes après le passage à l’arabe. La police principale utilisée pour les pages arabes doit au minimum couvrir les glyphes arabes courants, les chiffres, la ponctuation et les symboles nécessaires, et disposer de règles normales de liaison, de glyphes alternatifs et de positionnement.

Concernant les formats de fichiers de police, privilégiez WOFF2, bien pris en charge par les navigateurs modernes, et conservez WOFF comme complément de compatibilité. Ne terminez pas l’évaluation après avoir uniquement téléversé un « Arabic.ttf » d’origine inconnue : le chargement d’un fichier ne garantit ni l’exhaustivité du jeu de caractères ni que son périmètre de licence correspond au scénario d’utilisation du site. Si la charte de marque exige une cohérence de style entre les caractères latins et arabes, vous pouvez choisir une famille de polices couvrant les deux systèmes d’écriture ; si deux polices doivent impérativement être combinées, vérifiez spécifiquement leur graisse, la taille apparente des caractères, la ligne de base et la hauteur de ligne, au lieu de comparer uniquement leurs noms.

En CSS, déclarez clairement l’ordre de repli applicable à l’arabe afin d’éviter que les caractères manquants basculent aléatoirement vers la police par défaut de l’appareil. Par exemple, la pile de polices doit d’abord inclure une police Web arabe validée, puis une police arabe système fiable, et seulement ensuite une famille de polices générique. Parallèlement, la séparation du unicode-range de @font-face par langue peut réduire le téléchargement de caractères non pertinents, mais la configuration des plages doit couvrir les intervalles de caractères nécessaires à l’arabe ; un sous-ensemble incorrect est justement une cause fréquente de « rupture soudaine d’une partie du texte ».

Les attributs de direction doivent s’appliquer au contenu linguistique lui-même

Les pages en arabe se lisent de droite à gauche, mais direction: rtl ne suffit pas à tout résoudre en l’ajoutant une seule fois au conteneur de la page. L’approche la plus fiable consiste à définir lang="ar" et dir="rtl" dans le document arabe ou la zone correspondant à cette langue, afin que le navigateur, les technologies d’assistance et le rendu des polices reçoivent tous les bonnes informations de langue et de direction.

Au niveau de la mise en page, les équipes techniques devraient privilégier les propriétés logiques, telles que margin-inline-start, padding-inline-end et text-align: start, plutôt que de remplacer mécaniquement left par right à grande échelle dans les styles arabes. Les premières s’adaptent à la direction du texte, tandis que la seconde approche laisse plus facilement des oublis dans les composants responsives, fenêtres pop-up, carrousels et messages de validation de formulaire.

Les contenus mixtes nécessitent un traitement supplémentaire. Les modèles de produits, e-mails, URL, numéros de téléphone, SKU, pourcentages et prix utilisent généralement des caractères latins ou des chiffres ; lorsqu’ils sont directement intégrés dans un texte RTL, leur ordre visuel peut être décalé. Ces segments indépendants peuvent être entourés d’un élément doté de dir="ltr" ; pour les contenus de langue inconnue saisis par l’utilisateur ou renvoyés par une interface, dir="auto" est souvent plus approprié. N’essayez pas de résoudre le problème par tâtonnement avec des espaces, des traits d’union ou des caractères invisibles : ces corrections temporaires résistent difficilement aux mises à jour de contenu et au rendu sur plusieurs appareils.

Les ruptures de glyphes peuvent aussi provenir du système de contenu, et non du CSS

L’écriture arabe dépend du contexte des caractères adjacents. Si un éditeur de texte enrichi, un plug-in de traduction, un composant de mise en évidence côté front-end ou une logique d’interpolation dynamique divise un mot entre plusieurs span, nœuds de texte, voire plusieurs composants, le navigateur peut ne pas pouvoir mettre en forme l’ensemble du mot comme prévu. Les fonctionnalités telles que les animations caractère par caractère, la mise en évidence de mots-clés, la séparation des prix et unités, l’ajout automatique de liens ou le marquage des résultats de recherche interrompent souvent involontairement les séquences de caractères.

La méthode de vérification est très directe : examinez le DOM du mot anormal dans les outils de développement du navigateur. Si un mot normal est divisé en plusieurs nœuds, rétablissez d’abord un nœud de texte continu, puis déterminez s’il est réellement nécessaire de conserver la segmentation de style. Lorsqu’il faut effectivement insérer une variable dans une phrase arabe, la variable doit rester un segment complet, et l’ordre visuel des caractères et de la ponctuation avant et après la variable doit être testé. Le serveur, le CMS, la base de données et l’API doivent également utiliser UTF-8 de manière uniforme afin d’éviter que le contenu soit remplacé par des caractères incompatibles lors de l’importation, du transcodage ou du nettoyage.

Avant la mise en ligne, testez selon le « parcours de contenu » plutôt que de vérifier uniquement la page d’accueil

Dans une évaluation technique, la bannière de la page d’accueil contient généralement peu de texte et ne peut pas représenter la qualité d’un site arabe. Il est plus utile de couvrir le parcours de conversion réel : options de filtrage des pages de catégories, longues descriptions des fiches produit, tableaux de paramètres, formulaires de demande de renseignements, abonnements par e-mail, résultats de recherche internes, champs de paiement ou de règlement, ainsi que pages de destination publicitaires. Différents modules peuvent être générés par des composants et scripts différents ; l’héritage des polices et les règles de direction peuvent également varier.

1. Préparez un ensemble de textes de test en arabe comprenant des mots liés, des mots avec symboles, des chiffres arabes, des modèles en anglais et des liens.
2. Vérifiez le chargement effectif des polices dans les principaux navigateurs de bureau et mobiles afin de confirmer qu’aucun repli inattendu ne se produit.
3. Basculez entre différentes conditions réseau et observez si la police de substitution, avant le chargement complet des polices, provoque des sauts de mise en page ou des ruptures temporaires.
4. Vérifiez la direction du texte après copie, collage, recherche interne et soumission de formulaire, afin d’éviter le cas où « l’affichage est correct, mais le contenu devient désordonné à l’envoi ».
5. Faites vérifier l’ordre de lecture, l’orthographe des termes et la signification des boutons par un relecteur de contenu arabe ; l’exactitude technique ne garantit pas un langage naturel.

Pour les sites indépendants multilingues, la version arabe ne doit pas simplement reprendre un modèle anglais en remplaçant les textes. La capacité d’une plateforme de création de sites à gérer de manière stable les lang, dir et les ressources de polices dans les versions linguistiques, la hiérarchie des composants, les champs de formulaire et les pages SEO influencera directement les coûts de maintenance ultérieurs. Lors de l’évaluation de plateformes telles que Yiyingbao, destinées à la création de sites multilingues et au marketing international, vous pouvez vérifier en priorité leur pack linguistique arabe, l’adaptation RTL des composants, les autorisations de configuration des ressources de polices et la possibilité d’effectuer de nouveaux tests par page et par appareil après la publication du contenu. L’élément déterminant ici n’est pas le nom de la plateforme, mais sa capacité à éviter le recours à un grand nombre de surcharges CSS manuelles pour maintenir les pages arabes.

Quelques pratiques apparemment simples, mais très coûteuses par la suite

Premièrement, convertir les textes arabes en images. Cette solution peut temporairement contourner les problèmes de police, mais elle réduit la possibilité de copier le texte, l’accessibilité et la capacité de compréhension des moteurs de recherche ; elle exige également de recréer les images à chaque mise à jour produit. À moins qu’il ne s’agisse d’éléments visuels de marque fixes, cette méthode ne doit pas être utilisée pour le corps du texte.

Deuxièmement, dépendre uniquement des polices système présentes sur les appareils des utilisateurs. Les polices disponibles varient selon les régions, les versions de système et les navigateurs ; il peut donc arriver que les appareils de test fonctionnent correctement tandis que les appareils réels des visiteurs utilisent une police de repli. Les contenus principaux et les zones de conversion doivent charger une police Web validée.

Troisièmement, insérer manuellement des caractères de contrôle de direction dans le contenu afin de « corriger » les contenus mixtes. Cela peut résoudre un texte précis, mais crée des problèmes cachés pour l’édition dans le CMS, la copie de contenu et les traductions ultérieures. Il convient de privilégier une résolution fondée sur les balises sémantiques, l’attribut dir et les règles de sortie des composants.

Enfin, faites évoluer le critère de validation de « les caractères arabes peuvent s’afficher » vers « le contenu arabe peut être lu de manière continue sur les pages de conversion réelles, saisi de façon stable et affiché sur différents appareils ». Dès lors qu’un décalage existe entre les fichiers de police, la mise en page RTL et la sortie du contenu, les ruptures de glyphes peuvent réapparaître après la mise en ligne. Identifiez d’abord, à l’aide d’un texte de test complet, si le problème relève de la police, de la direction ou de la fragmentation du DOM, puis traitez-le de manière ciblée ; cela permet généralement d’éviter de remplacer sans cesse les polices sans résoudre la cause fondamentale.