Publier avec l'IA en cinq langues : ce qui casse vraiment, et comment l'attraper avant le lecteur

Publier en cinq langues coûte aujourd'hui ce que coûte d'en publier une. La transcréation IA — du copy réadapté pour chaque marché, pas de la traduction littérale — a fait tomber la barrière économique qui maintenait les PME italiennes à l'intérieur de leur frontière linguistique. Ce site le fait depuis des mois : chaque article de /risorse paraît simultanément en italien, anglais, français, espagnol et néerlandais, produit par une pipeline IA. Les 31 publications qui précèdent celle-ci sont toutes là, en cinq versions chacune.

Nous pouvons donc écrire une chose que presque personne n'écrit : voici le registre des défauts. Pas des hypothèses — les choses qui se sont réellement cassées, comment nous les avons trouvées et ce que nous avons changé. Cinq classes, et la cinquième est celle qu'aucun relecteur n'aurait jamais vue, parce que le texte était parfait.

Cinq choses qui se sont cassées, et comment nous les avons trouvées

Le trait commun, avant les détails : aucune n'a été interceptée avant la publication. Toutes sont apparues après, article par article, sans échantillonnage et sans termbase verrouillé sur les termes juridiques. C'est le vide de processus que le reste de cet article comble.

1. Le verbe qui transforme un fait en accusation

Une phrase italienne neutre sur une affaire judiciaire réelle, avec un nom et des parties, est arrivée en français avec un choix verbal intensifié, éditorialisant : le sens a glissé du constat à quelque chose de très proche d'une accusation. Aucune faute de langue, aucune phrase bancale — une dérive de registre sur une matière où le registre est la substance.

C'est aussi la classe la plus volumineuse que nous ayons observée : ce même article a demandé trois corrections de transcréation dans le seul français, un autre consacré au secteur du bâtiment en a demandé quatre en néerlandais. La combinaison qui les produit est toujours la même — matière juridique ou réglementaire plus traduction adaptative : la transcréation rend le texte naturel dans la langue d'arrivée, et « naturel », sur une phrase qui décrit un litige, signifie souvent « plus tranché ».

2. L'erreur identique dans les cinq langues

Un article décrivait les interdictions de l'EU AI Act comme applicables au seul secteur public. C'est faux — et comme l'erreur se situait en amont du passage par locale, dans la prémisse partagée, la transcréation l'a propagée fidèlement : fausse de façon identique en cinq langues, au même moment. Le périmètre exact des interdictions se trouve dans l'article consacré à ce qui change (et ce qui ne change pas) avec l'EU AI Act pour les PME.

Ce n'est pas une classe linguistique, et c'est pour cela qu'elle mérite sa ligne : le QA doit vérifier l'affirmation, pas la traduction de l'affirmation. Cinq relecteurs natifs vous renvoient cinq « ça correspond », et la prémisse reste fausse dans les cinq. La redondance linguistique n'est pas une redondance factuelle.

3. Les dates qu'aucune langue n'écrit vraiment ainsi

Les datelines ne sortaient pas dans le format que chaque langue emploie réellement : ordre jour/mois, séparateurs et conventions sur les noms de mois changent d'une langue à l'autre parmi les cinq. C'est un défaut mécanique, pas linguistique, mais il voyage sur la même pipeline et il est aussi visible qu'une mistranslation : un lecteur néerlandais qui voit une date écrite à l'italienne ne pense pas « bug de formatage », il pense que le site n'est pas vraiment le sien.

4. Aucun signal indiquant que le texte avait été corrigé — ce point est clos

Aucun des défauts ci-dessus ne portait de marqueur de révision visible pour le lecteur : qui avait lu la version erronée n'avait aucun moyen de savoir qu'elle avait été rectifiée entre-temps. Ce point est déjà résolu et en production : les articles corrigés affichent une date de révision visible. C'est le seul point de cette liste qui soit une mitigation achevée plutôt qu'une lacune ouverte, et c'est aussi le moins coûteux à copier.

5. Le texte est juste, c'est le code qui se trompe

C'est la meilleure, et la seule classe où le texte est correct et le défaut est dans le code. Deux composants de la page d'accueil mettaient graphiquement en valeur l'acronyme du titre par une substitution littérale : ils cherchaient la chaîne « AI » et l'enveloppaient dans un span pour l'accentuer. La transcréation avait bien fait son travail — le français et l'espagnol disent correctement « IA » — donc la recherche ne trouvait rien, ne remplaçait rien, et les deux locales rendaient un titre plat.

Le point, c'est la façon dont ça échoue : en silence, et dans un silence qui échappe à tous les garde-fous existants. Aucune erreur. Aucune clé de traduction manquante — donc un test de symétrie des clés passe, parce qu'il ne manque aucune clé : c'est le rendu qui diffère. Et aucune relecture ne le trouve, parce que le texte est juste. C'est resté en production jusqu'à ce qu'une intervention de design touche cette ligne pour d'autres raisons. La correction est banale : un match sur mot entier portant sur l'union des formes locales — l'expression régulière qui reconnaît aussi bien AI que IA comme mots autonomes, appliquée au titre déjà échappé. Mais ce n'est pas elle, la leçon.

La vraie leçon : quand on répare un pattern, on cherche le pattern — pas le fichier

Les deux composants portaient le même défaut. Le premier a été corrigé un cycle entier avant que le second ne soit seulement remarqué : la réparation avait été appliquée là où le bug avait été trouvé, pas partout où le pattern vivait. Résultat : un défaut identique, vivant, dans deux langues, ayant survécu à un tour de plus sans aucune raison. Un grep de trente secondes sur la substitution littérale les aurait refermés tous les deux d'un coup.

Cela vaut bien au-delà de ce cas. Tout token qu'une vue cherche littéralement et dont la forme change d'une langue à l'autre est candidat au même échec silencieux : acronymes (AI/IA/KI), la ponctuation inversée de l'espagnol, symboles monétaires, appellatifs. Si votre code compare une chaîne en langue source, cette comparaison est fausse dans au moins une des langues où vous publiez — et personne ne vous le dira.

La règle que nous en avons tirée, et que nous appliquons : un défaut de pattern ne se referme pas sur le fichier, il se referme sur le dépôt. Avant la correction, le grep. Toujours.

MQM : la taxonomie qui transforme « relis » en checklist

L'industrie de la localisation a déjà un nom pour chacune de ces choses, et l'avoir change la façon de travailler. MQM (Multidimensional Quality Metrics) est la taxonomie standard des erreurs de traduction, maintenue par l'organisme qui tient le framework : elle organise les défauts en sept dimensions — Exactitude, Fluidité, Terminologie, Style, Conventions locales, Véracité, Design — chacune sur trois niveaux de gravité (mineur, majeur, critique), selon les modèles de scoring publiés par le framework. C'est la structure sous les normes ISO 5060:2024 (évaluation de la qualité de traduction) et ISO 11669:2024 (projets de traduction), et un guide de vulgarisation publié par un prestataire de services linguistiques en reparcourt le dispositif en entier.

Notre registre se superpose dessus avec une fidélité presque gênante. Le cas français relève de Exactitude/Mistranslation, de gravité élevée parce que le sujet était une affaire réelle avec un nom. L'erreur de périmètre sur l'AI Act est un défaut de Véracité — la catégorie qui existe précisément pour les affirmations fausses sur le monde — qui devient aussi un défaut d'Exactitude une fois transcréé. Les dates relèvent des Conventions locales. Le titre sans accentuation graphique relève du Design. Cette cartographie, disons-le une fois, est notre lecture de nos propres défauts — pas un résultat publié par quelqu'un d'autre.

Pourquoi le nom compte-t-il ? Parce qu'une checklist se construit sur des catégories, pas sur de bonnes intentions. « Fais relire » n'est pas un processus : pas de critères de sortie, aucune donnée produite, rien qui dise au relecteur quoi chercher. « Vérifie les sept dimensions sur les trois niveaux de gravité, et consigne ce que tu trouves », si.

Back-translation : ce n'est pas la traduction aller-retour

Une confusion répandue à lever tout de suite, parce qu'elle produit une fausse sécurité. La round-trip translation — renvoyer le texte traduit dans la machine pour le ramener vers l'italien et voir s'il « retombe » — est un test de fumée sur la qualité du modèle, pas une méthode de QA. La back-translation est autre chose : un linguiste indépendant, qui n'a jamais vu l'original, retraduit le texte localisé vers la langue de départ, et le commanditaire compare les deux versions en cherchant les écarts de sens. La distinction est définitoire : le guide opérationnel d'un fournisseur de localisation se construit sur ce point, et l'entrée de glossaire d'un grand groupe de services linguistiques la définit de la même manière.

C'est le standard indiqué pour les contenus réglementés — contrats, textes juridiques, matériel critique pour la sécurité : précisément la catégorie de nos deux pires cas. Et il fonctionne là où la relecture échoue, pour une raison mécanique : il vérifie l'équivalence conceptuelle, pas la fluidité. Le verbe intensifié du cas français était parfaitement fluide ; c'est le concept qui s'était déplacé, et en colonne à côté de l'original un déplacement pareil se voit à l'œil nu.

Glossaire à trois niveaux, appliqué avant le relecteur

Le garde-fou que nous aurions dû avoir en premier est le plus ennuyeux : un termbase verrouillé. Les bonnes pratiques pour contenus réglementés l'articulent sur trois niveaux, décrits par le blog d'une plateforme de localisation :

• termes de marque et de produit — les noms qui ne se traduisent jamais, dans aucune langue ;
• termes techniques et de domaine, terminologie normative et juridique comprise, fixée langue par langue pour que le modèle ne puisse pas s'inventer un équivalent plausible mais faux ;
• termes interdits ou à risque — dénominations périmées, marques de tiers, formulations juridiquement piégeuses.

Le détail qui fait la différence tient pourtant à l'ordre d'exécution. Le glossaire doit s'exécuter comme un contrôle sur chaque segment avant ou pendant la transcréation, avec les violations signalées avant que le texte n'arrive à un relecteur : c'est le flux décrit par le guide 2026 du workflow d'enforcement terminologique d'un fournisseur du secteur, qui ajoute aussi la partie que presque tout le monde saute : un termbase a besoin d'un propriétaire identifié par son nom et d'un calendrier de révision, parce qu'un glossaire correct au lancement se dégrade tout seul avec le temps. Sur nos deux pires classes, une liste de formulations interdites — verbes qui imputent des conduites, affirmations de périmètre du type « ne s'applique qu'au secteur X » — les aurait interceptées toutes les deux avant la publication.

L'échantillon de 10 %, pondéré par le risque au lieu d'être plat

La pratique courante des opérateurs de localisation n'est pas de tout relire : on échantillonne environ 10 % du volume livré pour une relecture native a posteriori, comme le décrit le guide du localization QA d'un fournisseur de services de test. La partie qui compte vraiment est la seconde : ces 10 % sont une base, pas une règle, et sur les contenus à haut risque — juridique, réglementaire, sécurité — il faut la relever jusqu'à la relecture intégrale.

Les programmes de LQA matures structurent des niveaux de QA distincts — contrôle par échantillon, relecture standard, relecture complète en contexte — associés à la tolérance au risque de chaque type de contenu : c'est le cadrage d'un guide pratique de la language quality assurance d'un prestataire de services de localisation. D'où la conséquence inconfortable : un taux d'échantillonnage uniforme sur tous les sujets est déjà en soi un défaut de conception.

Formats locaux et pseudolocalisation : la classe qui s'automatise

Dates, nombres et devises sont désignés avec insistance comme la classe de bugs locaux la plus fréquente de toutes : les formats écrits à la main se cassent en silence dans toute langue autre que celle d'origine — mois et jour inversés, séparateurs décimaux et de milliers qui changent, le symbole monétaire du mauvais côté. La correction standard consiste à cesser d'écrire des chaînes et à passer à des formateurs conscients de la langue, vérifiés en CI, comme l'illustre le guide 2026 du formatage i18n d'une plateforme de localisation. C'est le garde-fou qui rend notre troisième classe impossible : il n'y a pas moyen de se tromper sur un format qu'on n'écrit pas.

En amont, il existe une technique qui vaut la peine d'être connue même si vous ne faites pas de logiciel : la pseudolocalisation, expliquée par le guide d'une plateforme de gestion de traductions — on rend l'interface avec des chaînes factices, allongées et accentuées, avant qu'une traduction réelle existe, si bien que les points qui cassent apparaissent pendant la construction. Elle est pensée pour les chaînes d'interface plus que pour le texte éditorial : elle couvre votre application, pas vos articles.

Trois pièges que notre pipeline est construite pour intercepter

Trois conditions qui, aujourd'hui, sur les 31 publications qui précèdent celle-ci et dans les cinq langues, ressortent cohérentes. Nous les listons quand même : c'est le genre de chose qui casse sans bruit, et un garde-fou se construit avant d'en avoir besoin.

• L'ordre des fichiers par langue n'est pas garanti. Le fichier néerlandais des descriptions d'articles liste les entrées dans un ordre différent de l'italien. Aucun problème aujourd'hui — mais toute automatisation qui suppose que « la ligne N en italien correspond à la ligne N en néerlandais » est fausse par construction. On aligne par clé, jamais par position.
• Le français écrit les pourcentages avec une espace avant le signe — « 180 % », « 70 % » — là où l'italien écrit « 180% ». Conséquence : une regex écrite en regardant le texte italien saute le français sans rien signaler. Elle ne trouve pas zéro occurrence de façon bruyante : elle en trouve moins, et tout a l'air d'aller bien. Tout sweep sur du texte multilingue doit s'écrire sur l'union des conventions.
• Notre contrôle sur le colophon est évalué langue par langue. C'est correct ainsi — mais cela signifie qu'une citation présente en italien et tombée en néerlandais casserait l'affirmation sur les sources entre deux langues sans déclencher quoi que ce soit de global. Le garde-fou existe parce que cette asymétrie est possible.

La checklist, ordonnée par risque et non au tarif unique

Traduit en opérations, pour quiconque publie des contenus multilingues générés avec l'IA :

1. Classez par risque, avant tout le reste. Les articles portant sur une matière juridique, fiscale ou réglementaire, ou qui nomment des affaires et des institutions réelles, ne reçoivent pas le même traitement qu'un guide opérationnel : contrôle façon back-translation sur les phrases qui affirment quelque chose, idéalement une lecture native complète.
2. Verrouillez la terminologie langue par langue avant la transcréation, avec la liste des formulations interdites — verbes qui attribuent des conduites, affirmations de périmètre — et les violations signalées avant que le texte n'atteigne un relecteur.
3. Séparez le fact-check de l'affirmation de la vérification de la traduction. Le fact-check se fait sur la source italienne, avant le fan-out. Ouvrez le lien et lisez la page citée contre l'affirmation : la pire classe d'erreur est celle où une donnée vérifiable et une donnée inventée cohabitent dans la même phrase, là où le spot-check « cite-t-il de vraies sources ? » passe et où l'affirmation reste fausse. Comment déclarer tout cela au lecteur est le sujet de l'article sur ce qu'il faut dire aux clients sur l'usage de l'IA.
4. Échantillonnez 10 % avec relecture native, en relevant la part sur les contenus à risque. C'est cet écart vers le haut qui rend l'échantillonnage utile au lieu de rassurant.
5. Faites passer dates, nombres et devises par un formateur conscient de la langue, contrôlé au build. Zéro chaîne de date écrite à la main par langue.
6. Grep du pattern, pas du fichier. Chaque fois que vous corrigez un défaut structurel — une comparaison avec une chaîne source, une hypothèse positionnelle, une regex calée sur l'italien — cherchez le pattern sur tout le code avant de refermer. C'est le contrôle le moins cher de la liste et c'est celui que ne pas faire nous a coûté le plus.
7. Mettez une date de révision visible sur les articles corrigés. Chez nous, c'est déjà en production : c'est la façon dont les programmes de qualité linguistique déclarent un problème au lieu de le réparer en douce, et pour qui lit c'est la différence entre un site qui se corrige et un site qui espère que personne ne s'en apercevra.

Aucune de ces cinq classes n'est un argument contre la transcréation IA : elles sont le coût de gestion d'une capacité qui, il y a peu, n'existait pas à ce prix, et ce coût se paie en processus, pas en traducteurs. La bonne question avant de publier n'est pas « la traduction est-elle bonne ? », c'est « qu'est-ce qui casserait sans que personne ne me prévienne ? » — parce que les défauts qui comptent sont là : pas dans la phrase fausse, mais dans la phrase juste rendue par un code qui ne parle qu'une seule langue.

Les sources externes citées ici sont des guides de fournisseurs de services de localisation, des blogs de plateformes i18n et la documentation de l'organisme qui maintient la taxonomie MQM, consultés le 29 juillet 2026 : ce ne sont ni de la recherche scientifique ni de la littérature évaluée par les pairs. Les normes ISO 5060:2024 et ISO 11669:2024 sont citées par leur nom sur la base de ces guides, sans consultation du texte normatif. La mise en correspondance des défauts observés sur notre pipeline avec les dimensions du framework MQM est notre propre analyse, pas un résultat rapporté par des tiers. Dans les sources consultées, il n'existe aucun taux de défaut mesuré pour la transcréation IA sur du copy juridique ou réglementaire : aucun pourcentage de ce genre n'est rapporté ici, et méfiez-vous de qui vous en propose un.