Unicode et encodage des caractères : pourquoi votre application casse dans d'autres langues

Unicode est le standard qui donne à chaque caractère de chaque système d'écriture, de « A » à « あ » en passant par « 🚀 », un numéro unique. L'encodage des caractères est l'étape distincte qui transforme ces numéros en octets qu'un ordinateur peut stocker et transmettre. La plupart des logiciels qui « cassent dans d'autres langues » n'échouent pas à la traduction. Ils échouent à cette couche antérieure, invisible, et l'échec porte un nom : le mojibake, le texte brouillé que l'on obtient quand les octets sont relus avec le mauvais encodage.

Nous avions promis un examen rapproché de cet échec dans le développement de logiciels multilingues et dans l'internationalisation (i18n), expliquée, où un client nommé José se transforme en « José » sur une étiquette ou une facture. Voici la dissection exacte de ce qui se passe, les endroits où les bugs d'encodage coûtent réellement de l'argent à une entreprise, et ce qu'exige « UTF-8 partout » dans un système réel.

Unicode et UTF-8 ne sont pas la même chose

Les deux termes s'emploient de manière interchangeable, et cette habitude est à la racine de l'essentiel de la confusion.

Unicode est une carte. Il attribue à chaque caractère un point de code : un numéro, écrit U+XXXX. La lettre « A » est U+0041. Le caractère chinois « 中 » est U+4E2D. La carte seule ne dit pas comment stocker ce numéro en octets sur un disque ni comment l'envoyer sur un réseau.

UTF-8 est une façon d'encoder cette carte en octets. C'est la façon dominante : UTF-8 porte aujourd'hui 99 % de tous les sites web dont l'encodage est connu (W3Techs, 2026). Il représente chaque point de code sur 1 à 4 octets : les lettres et chiffres non accentués tiennent sur 1 octet (identique au vieil ASCII, ce qui explique la rétrocompatibilité d'UTF-8 avec lui), les caractères latins accentués (l'essentiel d'un texte français, donc) prennent en général 2 octets, la plupart des caractères chinois, japonais et coréens en prennent 3, et les emojis en prennent 4.

Les encodages plus anciens font correspondre les mêmes valeurs d'octets à des caractères entièrement différents. Windows-1252 et Latin-1 (ISO-8859-1), courants tous deux sur les vieux systèmes Windows et les bases de données héritées, utilisent un seul octet par caractère et ne couvrent que les écritures d'Europe occidentale. Donnez des octets UTF-8 à un logiciel qui attend du Windows-1252, ou l'inverse, et vous obtenez une sortie d'apparence valide mais discrètement fausse. Ce décalage, c'est le mojibake, et il est entièrement mécanique : rien n'est « corrompu » au sens de données perdues, les mêmes octets sont simplement relus avec le mauvais manuel de règles.

Le mojibake, expliqué : comment « José » devient « José »

Parcourez les octets réels et l'échec cesse d'avoir l'air mystérieux.

En UTF-8, le caractère accentué « é » s'encode sur deux octets : 0xC3 0xA9. « José » en UTF-8, c'est donc la séquence d'octets pour J, o, s, puis 0xC3 0xA9, puis le caractère de fin.

Supposez maintenant que cette séquence d'octets soit remise à un système qui la lit comme du Windows-1252 au lieu d'UTF-8, un décalage qui se produit constamment quand des données passent entre une application moderne et une base de données, un outil d'export ou un système partenaire plus anciens. Windows-1252 ne sait pas que ces deux octets forment un seul caractère. Il les lit comme deux caractères séparés : 0xC3 s'affiche « à » et 0xA9 s'affiche « © ». La seule lettre « é » devient la séquence de deux caractères « é », et « José » devient « José » sur l'écran, l'étiquette ou la facture.

Le même mécanisme produit tous les autres motifs de mojibake que vous avez sans doute croisés : des guillemets typographiques qui se changent en chaînes comme “ et â€\x9d, ou un tiret long qui devient â€". Chaque cas, ce sont les octets d'un encodage lus à travers le manuel d'un autre. Une fois que vous savez nommer les deux encodages en conflit, le correctif est généralement un changement de configuration, pas une réécriture.

Où les bugs d'encodage mordent réellement une entreprise

Le mojibake à l'écran est le symptôme visible, et le français, truffé d'accents, le révèle plus vite que la plupart des langues. Les échecs les plus coûteux se produisent en dessous.

• Des noms corrompus sur des documents destinés aux clients. Étiquettes d'expédition, factures et contrats où le nom d'un client s'affiche « José » au lieu de « José » paraissent négligés au mieux, et arrivent à la mauvaise adresse au pire, un risque réel dans les documents douaniers et données transporteurs de la logistique, où un nom ou une adresse doit correspondre exactement à un dépôt officiel.
• Recherche et consultations cassées. Si un nom est stocké avec un encodage et cherché avec un autre, les séquences d'octets ne correspondent pas, et une fiche client bien réelle renvoie zéro résultat. Les équipes de support apprennent à contourner le problème à la main bien avant que quiconque diagnostique le décalage d'encodage derrière.
• Troncature silencieuse des données. Une colonne de base de données dimensionnée en octets, pas en caractères, peut couper un caractère multi-octets en deux en pleine insertion, corrompant le dernier caractère d'un nom ou laissant une séquence d'octets cassée qui échoue à la validation plus tard, souvent dans une tout autre partie du système.
• Emojis et caractères CJC qui disparaissent purement et simplement. Le jeu de caractères historiquement nommé utf8 de MySQL n'a jamais stocké que 3 octets par caractère au maximum, assez pour la plupart des caractères latins, cyrilliques et CJC courants, mais pas pour les emojis ni certains caractères d'extension CJC, qui en demandent 4. Le texte qui en contenait n'était pas brouillé ; il était rejeté ou tronqué en silence, tant que la vraie option UTF-8 complète de MySQL, utf8mb4, n'était pas utilisée à la place.
• Des exports hérités qui empoisonnent les systèmes modernes. Un flux CSV ou EDI venu d'un vieil ERP ou d'un système partenaire, qui émet encore du Windows-1252 par défaut, s'importe proprement au premier coup d'œil et corrompt chaque nom accentué dès que quelqu'un l'ouvre dans un outil nativement UTF-8.

Le piège propre aux équipes francophones est plus retors qu'il n'y paraît. Le français, lui, passe : Latin-1 et Windows-1252 couvrent é, è, à, ç et compagnie, si bien qu'une application franco-française tourne des années sur un encodage hérité sans que personne ne remarque quoi que ce soit. La facture arrive au premier client nommé Wojciech, Öztürk ou 田中, au premier fournisseur qui envoie un flux en cyrillique, ou au premier emoji dans un champ de commentaire. C'est exactement pour cela que les bugs d'encodage se découvrent si souvent en production plutôt qu'en recette.

Les encodages hérités qui posent encore problème

Trois encodages expliquent presque chaque décalage qu'un système métier rencontre encore : l'ASCII pur (lettres anglaises, chiffres et ponctuation de base seulement, aucun accent ni écriture non latine), Latin-1 / ISO-8859-1 (un octet par caractère, accents d'Europe occidentale uniquement), et Windows-1252 (le quasi-sur-ensemble de Latin-1 de Microsoft, défaut des vieux logiciels Windows et source fréquente du motif de mojibake des guillemets typographiques ci-dessus).

Latin-1 mérite une note à part quand on écrit en français, parce qu'il ne couvre même pas le français en entier. Il lui manque la ligature « œ » et le symbole « € », deux caractères difficiles à éviter sur un devis ou un catalogue. C'est précisément la raison d'être de Latin-9 (ISO-8859-15), révision qui les a ajoutés. Un système hérité qui avale le « œ » d'« œuvre » ou retombe sur « EUR » là où vous attendiez « € » ne fait pas une coquille : il annonce son encodage.

Ils persistent à des endroits précis et prévisibles : des bases de données créées il y a des années avec un jeu de caractères par défaut que personne n'a revu, des exports CSV de vieux systèmes comptables ou d'ERP, des messages EDI de partenaires logistiques et de fret tournant sur des formats vieux de plusieurs décennies, et des bibliothèques de génération de PDF qui supposent un jeu de caractères étroit sauf instruction contraire. Chacun de ces endroits est une frontière où les données passent d'un système à un autre, et les frontières sont exactement là où les hypothèses d'encodage restent tues et désaccordées.

Ce qu'exige réellement « UTF-8 partout »

« Utilisez UTF-8, c'est tout » est un conseil juste qui sous-estime le travail. Un support UTF-8 complet signifie le déclarer explicitement à chaque couche, pas supposer qu'il se propage tout seul.

1. Jeu de caractères et collation de la base de données. UTF-8 déclaré sur la base, chaque table et chaque colonne, pas seulement sur la connexion. Sur MySQL en particulier, cela veut dire utf8mb4, pas l'alias hérité utf8.
2. En-têtes HTTP et de fichiers. Chaque réponse d'API et chaque export de fichier annonce son encodage explicitement (Content-Type: text/html; charset=utf-8), au lieu de laisser les clients deviner.
3. Des exports CSV avec BOM quand Excel est la destination. Excel lit souvent un CSV UTF-8 nu comme du Windows-1252 si aucun indicateur d'ordre des octets (BOM) n'est présent, le ticket de support « pourquoi mon export est cassé dans Excel » le plus courant qui soit.
4. Couverture des glyphes de la police. Un caractère cyrillique ou CJC correctement encodé s'affiche quand même comme un carré vide (« tofu ») si la police choisie n'a pas de glyphe pour lui. C'est un problème de design, pas d'encodage, mais pour l'utilisateur c'est identique.
5. Validation à chaque frontière. Les téléversements, les entrées d'API et les flux de données partenaires voient leur encodage vérifié et normalisé en UTF-8 à l'entrée, pour que des octets brouillés n'atteignent jamais le stockage.

Réglez les cinq une bonne fois, au niveau de l'architecture, et l'encodage des caractères cesse d'occuper qui que ce soit. Manquez-en un, et il ressurgit en ticket de support chaque fois qu'un nom accentué, un emoji ou une écriture non latine atteint cette frontière-là.

Questions fréquentes sur Unicode et l'encodage des caractères

Qu'est-ce qu'Unicode ?

Unicode est un standard qui attribue un numéro unique, appelé point de code, à chaque caractère de chaque grand système d'écriture. C'est une carte des caractères vers des numéros. Il ne définit pas, à lui seul, comment ces numéros sont stockés en octets.

Quelle est la différence entre Unicode et UTF-8 ?

Unicode est la carte des caractères ; UTF-8 est un encodage qui transforme les points de code Unicode en octets, sur 1 à 4 octets par caractère. UTF-8 est l'encodage dominant du web actuel, portant 99 % des sites dont l'encodage est connu (W3Techs, 2026).

Qu'est-ce que le mojibake ?

Le mojibake est le texte brouillé produit quand des octets encodés dans un jeu de caractères sont relus avec un autre. Il est mécanique, pas aléatoire : le même décalage d'encodage produit toujours le même motif brouillé, comme « José » qui devient « José ».

Pourquoi mon logiciel affiche-t-il des caractères bizarres comme « é » à la place des lettres accentuées ?

Un composant du système, souvent une base de données, un outil d'export ou un flux partenaire plus ancien, lit des octets UTF-8 comme du Windows-1252 ou du Latin-1. Le correctif consiste à repérer où se produit le décalage et à régler ce composant explicitement sur UTF-8, pas à ressaisir les données.

Comment corriger les problèmes d'encodage dans un logiciel existant ?

Auditez chaque frontière : jeu de caractères et collation de la base, exports de fichiers, en-têtes d'API et flux de données partenaires, et réglez chacun explicitement sur UTF-8 (utf8mb4 si la base est MySQL). Nous menons cet audit dans le cadrage de chaque construction multilingue ; demandez un devis à prix fixe et il est inclus.

Obtenez un logiciel qui gère chaque caractère correctement

Dites-nous ce que votre logiciel doit prendre en charge, y compris les noms, les écritures et les flux de données partenaires qu'il doit traiter correctement. Nous répondons avec un périmètre fixe, un prix fixe et une date de livraison.

Demander un devis à prix fixe →