Le langage d'un modèle n'est pas le langage d'une société.

Un modèle multilingue n’est pas équitable parce que son interface liste de nombreuses langues. La couverture linguistique est une question institutionnelle,...

Le langage d'un modèle n'est pas le langage d'une société.

Seize langues, c’est un début, pas un verdict

Le 22 juillet 2026, la Direction générale de la traduction de la Commission européenne a publié EU MMLU, un banc d’essai destiné à évaluer les grands modèles de langage dans les contextes linguistiques et culturels européens. Cette publication était d’une honnêteté inhabituelle sur l’écart qu’elle cherchait à combler. De nombreux jeux de données d’évaluation ont été conçus en anglais. Un modèle peut y obtenir de bons résultats et échouer pourtant en français, en hongrois ou en maltais. Le nouveau jeu de données commence avec seize langues officielles de l’UE, sept domaines thématiques et plus d’un millier de questions traduites et révisées par près de 250 étudiants issus de 21 universités européennes.

La partie la plus importante de cette annonce n’est pas la liste des langues. C’est la phrase qui la suit : le comportement d’un modèle ne peut pas être déduit de la langue dans laquelle il semble le plus à l’aise. Cela devrait être une évidence. C’est pourtant l’hypothèse qui sous-tend une grande partie des appels d’offres, de la recherche et du débat public. Nous parlons encore d’un modèle de langage comme s’il avait un seul esprit, puis nous lui demandons de porter différentes langues comme des manteaux. Le manteau change. L’esprit, les preuves, les angles morts et le contexte social sont, eux, considérés comme stables.

Ils ne le sont pas. La langue est le lieu où une personne rencontre une institution. Elle porte les termes d’une prestation, le ton d’un recours, la différence entre un conseil et une instruction, la forme d’une plaisanterie, le nom d’un lieu et les présupposés d’un formulaire. Lorsqu’un système maîtrise une langue mieux qu’une autre, il ne produit pas seulement une phrase moins élégante. Il peut changer qui est compris, qui est cru, qui peut contester un résultat et qui abandonne avant d’avoir trouvé la bonne porte.

La conclusion pratique est limpide. L’IA multilingue n’est pas une fonction de traduction à ajouter une fois le modèle construit. C’est une question d’accès, de preuves et d’autorité. Le travail européen sur les technologies linguistiques, les données langagières et l’évaluation multilingue est précieux parce qu’il traite le problème comme une infrastructure. Ce travail reste inachevé. Un banc d’essai n’est pas une garantie, et seize langues ne représentent pas toute l’Europe. Mais la direction est la bonne : cessons de demander si un modèle parle une langue et commençons à demander ce qu’il peut faire en toute sécurité dans cette langue, pour qui, à quelles conditions et avec quelles preuves.

La couverture linguistique n’est crédible que si les affirmations concernant la source, le contexte, la révision et le service restent liées.

La langue est une frontière d’accès

L’Europe a fait de la langue un fait institutionnel, et non une préférence privée. L’article 22 de la charte des droits fondamentaux dispose que l’Union respecte la diversité culturelle, religieuse et linguistique. La politique de l’Union en matière de technologies linguistiques place cette obligation à côté d’un avertissement pratique : ces technologies doivent être utilisées de manière impartiale si l’on veut que les droits et les principes survivent au contact des logiciels. Il ne s’agit pas d’engagements décoratifs. Ils décrivent la limite qu’un système public rencontre lorsqu’un résident ne peut pas lire un avis, ne peut pas comprendre pourquoi une décision a été prise ou ne peut pas exprimer un fait pertinent dans la langue dans laquelle ce fait existe.

Cette limite est facile à manquer lorsqu’une équipe mesure seulement si une traduction a été produite. Une phrase peut arriver dans la langue demandée et échouer quand même auprès de la personne qui en a besoin. La traduction peut aplatir une distinction juridique, modifier le niveau de politesse qui indique si un agent demande ou ordonne, ou employer un terme qui a un sens courant mais aussi un sens spécialisé dans un service particulier. Un système de reconnaissance vocale peut transformer une prononciation régionale en un autre mot. Un système de résumé peut supprimer la réserve qui porte la responsabilité. La fluidité ne nous dit pas si la transaction est restée intacte.

Imaginons un service public d’information qui propose la même explication d’éligibilité en néerlandais, en français et dans une langue régionale. Les deux premières voies ont été entraînées et testées avec des documents administratifs, des lettres de recours et des conversations avec des experts du domaine. La troisième voie produit d’excellents textes généraux, mais n’a fait l’objet d’aucune évaluation significative sur la terminologie propre du service. Un tableau de bord peut afficher trois voyants verts pour les langues. Les résidents ne reçoivent pas pour autant trois services équivalents. Un groupe reçoit une explication ; un autre reçoit une approximation ; le troisième reçoit une incertitude policée qui semble officielle parce qu’elle porte le bon logo.

L’exemple est volontairement hypothétique. Il ne s’agit pas d’une affirmation sur une municipalité ou un fournisseur particulier. Son but est de mettre au jour une erreur de conception. Le soutien linguistique est souvent compté à l’interface, alors que l’obligation réelle se situe plus loin dans la chaîne. Le système doit savoir quelles données soutiennent la langue, quelles tâches ont été évaluées, qui a relu les erreurs, comment les utilisateurs peuvent les corriger et quand la voie doit refuser de répondre. Si ces détails manquent, le sélecteur de langue est une promesse sans contrat.

La carte d’un modèle n’est pas la carte de la société

Un modèle apprend à partir d’une carte de la langue que ses données et son processus d’entraînement rendent disponible. Une société vit dans une carte beaucoup plus vaste. La carte du modèle contient les textes, les enregistrements, les étiquettes, les traductions et les évaluations qui ont été admis. La carte de la société contient des personnes qui parlent différemment à la maison et au travail, qui changent de registre sans l’annoncer, qui empruntent des mots de l’autre côté d’une frontière, qui utilisent une langue minoritaire dans une institution locale ou qui écrivent dans une écriture qu’un banc d’essai n’a pas incluse. L’une est un artefact technique. L’autre est un arrangement de vies, de droits et d’obligations.

La différence compte même pour les langues disposant de grands corpus publics. Une langue nationale n’est pas un flux uniforme. Les formulaires administratifs, les décisions de justice, la parole en classe, les conseils de santé, les messages texte et une conversation entre voisins utilisent des vocabulaires différents et des tolérances différentes à l’ambiguïté. Un modèle peut être compétent sur les textes de presse et faible sur un recours de prestations. Il peut gérer l’orthographe standard et échouer avec un dialecte. Il peut traduire une phrase littérale et manquer le sens pragmatique porté par une formule de courtoisie. Qualifier la langue entière de prise en charge masque la limite de la tâche.

La technologie linguistique a donc besoin d’un vocabulaire plus précis. Il faut distinguer le fait qu’une langue soit présente dans les données d’entraînement de celui qu’une tâche soit évaluée dans cette langue. Il faut distinguer une traduction de référence d’un item de test rédigé indépendamment. Il faut distinguer la lecture d’un système d’écriture de la compréhension du registre d’une communauté. Il faut distinguer la capacité d’un système à générer du texte de son autorité à conseiller, classer ou décider. Chaque distinction est une petite pièce de travail administratif. Ensemble, elles empêchent qu’une affirmation générale soit assemblée à partir de preuves étroites.

Il existe une raison institutionnelle d’être strict. Les services publics ne sont pas libres de choisir la langue la plus facile et de qualifier le résultat d’efficace. Une banque, un hôpital, un employeur ou un fournisseur de logiciels peut avoir des obligations légales différentes, mais chacun décide de la quantité de friction qu’une personne doit absorber pour être comprise. Un parcours multilingue qui échoue silencieusement transfère le coût à l’utilisateur. L’utilisateur doit trouver un traducteur, répéter son histoire, accepter un résultat moins bon ou abandonner la démarche. Le système déclare un succès parce qu’il a renvoyé une chaîne de caractères. La personne vit une exclusion avec une grammaire excellente.

Ce que signifie réellement « faiblement doté »

Le terme « faiblement doté » est souvent traité comme une propriété d’une langue, comme si certaines langues arrivaient à la porte du modèle avec moins de ressources et devaient s’excuser du dérangement. Il est plus utile de le traiter comme une propriété d’une tâche, d’un ensemble de données et d’une décision de gouvernance. Une langue peut disposer d’un matériel littéraire substantiel mais de peu de données étiquetées pour un classifieur médical. Elle peut avoir des textes parallèles mais presque aucun enregistrement de parole. Elle peut être représentée dans un corpus sans les droits ou les métadonnées nécessaires à un déploiement particulier. Elle peut avoir des données sous une forme standard tandis que les personnes concernées utilisent une variété régionale.

La politique de technologie linguistique de la Commission européenne nomme cela clairement. Les données linguistiques sont le fondement des outils linguistiques, et l’expertise humaine est une composante nécessaire au succès du développement. Un modèle a besoin de texte ou de parole, d’algorithmes, de calcul et de personnes qui comprennent la langue et le domaine. Retirer l’un de ces éléments modifie le système. Davantage de calcul ne peut pas créer une conversation manquante. Davantage d’exemples ne peuvent pas réparer une étiquette qui confond deux catégories juridiques. Un modèle plus grand ne peut pas décider quelle source une communauté considère comme faisant autorité.

Le travail sur les langues faiblement dotées n’est donc pas une invitation à abaisser le niveau. C’est une raison de rendre le niveau visible. Si une tâche dispose de peu de matériel d’évaluation, dites-le. Si une métrique est instable pour une paire de langues, signalez cette instabilité. Si l’examen humain était limité, précisez la portée de cet examen au lieu de le présenter comme une garantie générale. Si un parcours est utile pour la rédaction mais pas pour les décisions, placez cette limite là où un acheteur et un utilisateur peuvent la voir. Une pénurie honnête est plus sûre qu’un silence qui semble abondant.

Le paysage linguistique européen rend cette discipline inévitable. La Commission décrit un ensemble complexe de langues officielles, régionales et minoritaires et a soutenu des initiatives telles que le European Language Grid, le programme European Language Equality et l’Espace commun européen des données linguistiques. Ces projets ne constituent pas une solution unique et ne doivent pas être présentés comme tels. Ce sont des éléments d’un écosystème dans lequel les données, les outils, les droits, l’expertise et les institutions publiques peuvent se rencontrer. La forme institutionnelle est aussi importante que le modèle qui se trouve à l’intérieur.

La couche des droits arrive avant le référentiel d’évaluation

Il est tentant de parler des modèles de langage comme si la langue était un canal d’entrée neutre. Elle ne l’est pas. L’entrée peut contenir des données personnelles, une caractéristique protégée, un nom de lieu local, un détail médical ou l’enregistrement d’une personne demandant de l’aide. La source peut être protégée par le droit d’auteur ou soumise à une réserve. Une sortie traduite peut être utilisée dans une décision alors même que le parcours de traduction n’a jamais été évalué pour ce contexte. Le problème de langue du modèle est déjà un problème de droits avant même que quiconque ne choisisse un score.

Les orientations de la Commission sur les technologies linguistiques relient les données linguistiques à la fois au droit d’auteur et à la protection des données. Ce lien devrait modifier la manière dont les équipes conçoivent les pipelines. Un corpus n’est pas simplement un tas de phrases. Il possède une identité de source, des conditions d’acquisition, un statut de licence ou de droits, des métadonnées de langue et d’écriture, des signaux de qualité, une finalité et des règles de conservation. Si un élément est corrigé ou retiré, l’organisation doit savoir quels artefacts dérivés ont été affectés. Sinon, un modèle ultérieur peut répéter une ancienne erreur avec l’assurance d’un formulaire fraîchement imprimé.

C’est ici que l’expression provenance gagne ses lettres de noblesse. La provenance n’est pas une note de bas de page indiquant que les données viennent de quelque part. C’est l’ensemble des relations qui permet à un relecteur d’aller d’un résultat aux éléments de preuve pertinents, puis de revenir en arrière. Dans le travail multilingue, ces relations doivent survivre à la traduction, à la transcription, à la normalisation, à la segmentation et à l’évaluation. Une phrase traduite pour un banc d’essai n’est pas interchangeable avec la phrase source. Une étiquette créée par un relecteur n’est pas interchangeable avec une étiquette héritée d’une autre langue. La transformation fait partie des éléments de preuve.

Il n’est pas exigé que chaque utilisateur voie un registre de recherche. Il est exigé qu’une organisation puisse répondre à une question sérieuse lorsqu’elle se présente. Quelle version de la ressource linguistique a été utilisée ? Quelle tâche a-t-elle prise en charge ? Quels experts linguistiques l’ont examinée ? Qu’a fait le système lorsque la confiance était faible ? Une plainte a-t-elle été traitée comme une correction apportée à une seule réponse ou comme une classe possible de défaillances ? Le parcours linguistique devient digne de confiance lorsque ces questions ont des responsables et des enregistrements.

L’Europe construit une infrastructure linguistique, pas seulement des boutons de traduction

La description de l’Espace européen commun de données linguistiques par la Commission européenne est utile car elle ne réduit pas le projet à une publication de modèle. L’objectif est une plateforme et un marché pour collecter, partager et réutiliser des données linguistiques multilingues et multimodales, tout en laissant le contrôle aux organisations et aux personnes qui génèrent les données. Cette formulation oriente vers une autre idée du progrès. Le travail ne consiste pas seulement à produire une meilleure phrase. Il consiste à rendre les ressources linguistiques découvrables, respectueuses des droits, réutilisables et responsables dans l’administration publique, la recherche et l’industrie.

La Grille européenne des langues a fait un pas similaire en rassemblant des outils et des ressources spécialisés en technologies linguistiques dans un catalogue commun. Un catalogue ne prouve pas que chaque service fonctionne pour chaque tâche. Il rend toutefois une dépendance cachée plus facile à inspecter. Une équipe peut demander ce que fait l’outil, quelle langue il prend en charge, d’où proviennent ses données et si la licence correspond à l’usage prévu. C’est une infrastructure sans éclat. C’est aussi ainsi qu’un continent comptant de nombreuses institutions évite de reconstruire la même capacité linguistique dans des pièces déconnectées.

L’infrastructure compte parce que la longue traîne du travail linguistique n’est pas résolue par un seul modèle phare. Un organisme public peut avoir besoin de reconnaissance vocale pour un accent régional, d’extraction terminologique pour un domaine spécialisé, de mémoire de traduction pour la législation, de reconnaissance d’entités nommées pour les noms de lieux, ou d’un moyen de comparer deux versions d’un document sans perdre les diacritiques. Une entreprise peut avoir besoin d’un déploiement local parce que les documents ne peuvent pas quitter sa juridiction. Un groupe de recherche peut avoir besoin d’un jeu de données à la provenance claire plutôt que d’un autre score anonyme.

Il y a un choix politique discret dans cette approche. Les données et les outils sont traités comme des capacités que l’Europe devrait pouvoir inspecter et façonner, et non comme un service qui arrive d’un ailleurs invisible. Cela ne signifie pas que les systèmes européens sont automatiquement bons ou que les fournisseurs commerciaux d’ailleurs ne peuvent pas être utiles. Cela signifie qu’une langue est trop importante pour rester sans vocabulaire public pour ses données, ses lacunes et son évaluation. La souveraineté commence par savoir ce que le système ne peut pas voir.

La traduction n’est pas une simple tuyauterie neutre

La traduction est souvent placée entre deux composants dans un schéma d’architecture, comme si elle était un tuyau qui transporte le sens d’un côté à l’autre. La traduction réelle est une séquence de décisions. Quel texte source fait autorité ? Quels mots doivent rester exacts ? Quelle ambiguïté doit être préservée ? Quelle référence culturelle nécessite une explication ? Quel registre convient à un avis public ? Quelle entité ne doit pas être traduite ? Quelle date, quel nombre ou quelle unité doit être rendu selon la convention du lecteur ? Un modèle peut prendre ces décisions rapidement. La rapidité ne les rend pas invisibles.

Considérez la différence entre traduire une phrase météorologique et traduire un avis concernant une échéance. Dans le premier cas, une petite erreur de style peut être agaçante. Dans le second, un nombre ou un verbe modal peut modifier ce qu’une personne croit devoir faire. Le modèle de langue sous-jacent peut avoir le même budget de jetons et la même affichage de confiance. Les conséquences sociales ne sont pas les mêmes. L’évaluation doit donc suivre la tâche, et ne pas s’arrêter à un score de langue général.

La page de la Commission sur son propre usage des langues fait le point sans drame. La traduction automatique peut donner une idée de base, mais la qualité et la précision varient considérablement d’un texte à l’autre et entre les paires de langues. C’est une phrase publique utile parce qu’elle refuse de transformer un service en oracle. Elle donne au lecteur la permission d’utiliser une traduction comme une orientation tout en conservant une raison de rechercher une version humaine ou faisant autorité lorsque les conséquences le justifient.

Pour les équipes produit, l’implication est un ensemble de parcours explicites. Une traduction à faible conséquence peut être renvoyée directement avec un statut clair. Un parcours juridique ou médical peut exiger une relecture humaine, un lien vers la source ou un refus. Un brouillon interne peut conserver la source à côté de la traduction. Une interface vocale peut répéter un nom critique et demander une confirmation. Le choix n’est pas entre automatisation complète et absence d’automatisation. Il est entre un pipeline qui déclare ses transferts et un qui les cache derrière un paragraphe fluide.

La phrase survit, la situation non

Les modèles travaillent sur des représentations. Les sociétés travaillent sur des situations. Lorsqu’une traduction passe de l’une à l’autre, de petits détails peuvent devenir tout le sens. Une phrase polie dans une langue peut sembler évasive dans une autre. Un terme qui distingue un droit légal d’un service discrétionnaire peut être réduit à un mot générique pour aide. Une expression idiomatique peut être traduite littéralement et devenir un non-sens, ou traduite librement et perdre la référence qui identifie une communauté. Aucun de ces échecs ne nécessite une sortie absurde. La réponse dangereuse est celle qui semble ordinaire.

La publication EU MMLU cible exactement ce territoire. Ses critères de qualité demandent aux référentiels multilingues de tester non seulement le sens et la difficulté, mais aussi les expressions idiomatiques, l’humour, les références culturelles, les formats de date et de nombre, et les différences de ton ou de politesse attendues. C’est un élargissement important de la cible d’évaluation. On ne demande pas seulement à un modèle de langue s’il peut produire une phrase grammaticale. On lui demande si la phrase appartient à la situation où une personne agira en conséquence.

La mention de l’humour n’est pas une invitation à rendre le benchmark divertissant. Elle reconnaît que l’humour est un test de résistance pour le contexte. Une traduction littérale peut préserver les mots et détruire la blague. Une traduction culturellement adaptée peut préserver l’effet tout en changeant la référence. Dans un service d’information publique, le même mécanisme apparaît sans rire. Un proverbe, un nom de lieu local ou une salutation formelle peut signaler qui parle et quelle relation le message établit.

Lorsque les équipes disent qu’un modèle comprend une langue, elles devraient se demander de quelle couche elles parlent. Reconnaît-il l’écriture ? Segmente-t-il correctement les mots ? Identifie-t-il les entités ? Traduit-il la proposition ? Préserve-t-il la force juridique ? Suit-il une convention locale ? Maintient-il le degré de certitude du locuteur ? Gère-t-il une orthographe non standard ? Répond-il dans le registre approprié ? Ce sont des capacités distinctes. Une seule étiquette appelée multilingue masque le travail nécessaire pour établir chacune d’elles.

Pourquoi l’évaluation doit voyager avec la langue

L’évaluation est souvent ajoutée à la fin parce que les équipes veulent un chiffre à associer à un modèle. Les systèmes multilingues rendent cet ordre impossible. Les données de test déterminent ce qui compte comme une erreur. La langue détermine comment une phrase peut échouer. Le domaine détermine quelle défaillance importe. L’utilisateur détermine si la réponse du système est une aide ou un obstacle. L’évaluation doit voyager avec ces quatre éléments.

Le document de recherche européen Towards Multilingual LLM Evaluation for European Languages démontre l’ampleur du problème. Les auteurs évaluent 40 modèles de langage dans 21 langues européennes, examinent des versions traduites de cinq benchmarks largement utilisés et publient un cadre incluant EU20-MMLU, EU20-HellaSwag, EU20-ARC, EU20-TruthfulQA et EU20-GSM8K. Le document ne prétend pas que traduire un benchmark existant le rend automatiquement équitable. Il traite les services de traduction, la construction des benchmarks et la comparabilité interlinguistique comme des sujets à étudier.

C’est la bonne posture. Un élément de test traduit peut hériter d’un changement de difficulté, d’une hypothèse culturelle ou d’un indice qui n’existait pas dans l’original. Un modèle peut obtenir un score plus élevé parce que la formulation traduite rend la réponse plus facile, et non parce que le modèle est devenu plus performant. Il peut obtenir un score plus faible parce qu’une construction grammaticale est peu naturelle dans la langue cible, même si le raisonnement sous-jacent est solide. Ces deux résultats sont des preuves concernant le test autant que le modèle.

La revue humaine reste nécessaire, mais elle aussi a besoin d’un cadre. Qui a examiné l’élément ? Les examinateurs étaient-ils des locuteurs natifs, des spécialistes du domaine, ou les deux ? Ont-ils examiné des phrases isolées ou la tâche en contexte ? Les désaccords ont-ils été enregistrés ? Le benchmark a-t-il préservé les réponses alternatives acceptables ? Un expert en langue peut nous dire qu’une phrase est incorrecte. Un expert du domaine peut nous dire pourquoi l’erreur change une décision. Une évaluation crédible nécessite souvent les deux et doit préciser lequel était présent.

Le but n’est pas de faire passer chaque système par un examen sans fin avant que quiconque puisse l’utiliser. Il est d’empêcher qu’un test étroit soit confondu avec une affirmation large. Si un modèle a été évalué sur des questions factuelles courtes en langue écrite standard, dites-le. Ne laissez pas le résultat devenir silencieusement une affirmation sur l’interaction orale, la rédaction juridique, l’administration locale, les enfants, les personnes âgées ou chaque registre de la langue.

Un score devient utile lorsque les limites de sa tâche, de sa langue, de son contexte et de sa relecture restent visibles.

La leçon du maltais et du basque

Un article présenté à la conférence LREC-COLING 2024 a étudié l'évaluation de la traduction automatique de l'anglais vers le maltais et de l'espagnol vers le basque. Les auteurs ont examiné la métrique d'évaluation COMET, recueilli des évaluations humaines directes et testé le comportement de la métrique lorsqu'elle est adaptée à ces deux paires de langues. Leur conclusion est modeste mais lourde de conséquences : les performances de la métrique peuvent s'améliorer avec un réglage fin, et elle peut être très sensible à la distribution des scores dans ses données d'entraînement, en particulier dans les contextes à faibles ressources.

Ce n'est pas l'histoire d'une métrique qui échoue. C'est l'histoire de ce dont dépend un score. Une métrique entraînée sur une distribution peut se comporter différemment lorsqu'on lui demande d'en juger une autre. Une paire de langues disposant de moins de matériel d'évaluation peut donner l'impression que le score est plus décisif qu'il ne l'est. Un système qu'il est pratique de comparer peut néanmoins être un mauvais indicateur de ce que les locuteurs considèrent comme une bonne traduction. Les jugements humains ne rendent pas l'évaluation parfaite, mais ils révèlent les endroits où une mesure automatique fait des suppositions.

Une autre étude de 2024, Benchmarking Low-Resource Machine Translation Systems, compare des systèmes disponibles publiquement sur quatre ensembles de données et 26 langues, et publie les résultats via BENG, une plateforme FAIR de référencement pour la génération en langage naturel. Là encore, la contribution n'est pas un classement universel. C'est une comparaison plus inspectable. L'efficience et l'efficacité sont considérées ensemble, et la liste des langues est visible. Le lecteur peut se demander si le référentiel inclut la voie qui compte, plutôt que d'accepter un seul chiffre global.

Ces études offrent une leçon européenne de retenue. La difficulté ne consiste pas à inventer un autre score. Elle consiste à construire une évaluation qui permette au lecteur de voir quelle langue, quelle tâche et quelle définition de la qualité ont produit le score. Lorsque ce contexte manque, un nombre devient un passage de frontière sans passeport. Il peut passer l'étape de la présentation, mais personne ne peut établir d'où il vient.

La couverture linguistique peut être une propriété de sécurité

Les discussions sur la sécurité portent souvent sur les contenus qu'un système doit refuser, les attaques qu'il doit repousser ou les erreurs qu'il doit détecter. La langue ajoute une autre question : le système peut-il reconnaître quand il est hors de sa compétence ? Une voie qui fonctionne dans une langue peut échouer plus souvent dans une autre tout en conservant le même ton assuré. Si l'interface ne révèle pas la différence, les utilisateurs ne peuvent pas calibrer leur confiance.

Cet aspect est particulièrement important lorsque la langue fait partie d’une interaction critique pour la sécurité. Un patient peut décrire un symptôme dans une variété régionale. Un travailleur peut signaler un danger en utilisant un terme local. Un résident peut soumettre un recours avec une convention orthographique qu’un normalisateur considère comme du bruit. Un modèle peut être techniquement précis sur son benchmark et opérationnellement dangereux pour ce parcours. La question pertinente n’est pas de savoir si le système peut générer une réponse plausible. Elle est de savoir si les contrôles de sécurité ont été évalués sur la langue et la situation qui se présentent à lui.

La sécurité n’exige pas de traiter chaque parcours linguistique comme une urgence particulière. Elle exige d’adapter le contrôle à la conséquence. Un résultat de recherche à faible risque peut exposer ses sources et inviter à une correction. Une interface de triage médical peut orienter une saisie linguistique incertaine vers un professionnel formé. Un flux de travail de documents juridiques peut conserver la source et la traduction côte à côte et exiger une approbation avant publication. Un système vocal peut demander à l’utilisateur de répéter un nom plutôt que de sélectionner silencieusement l’entité familière la plus proche. Ce sont des choix d’ingénierie ordinaires lorsque la langue est traitée comme faisant partie de la frontière du système.

Le refus lui-même nécessite une conception linguistique. Dire à un utilisateur qu’un système ne peut pas répondre ne suffit pas si le refus est opaque, condescendant ou indisponible dans la langue de l’utilisateur. Le système devrait indiquer ce qu’il n’a pas pu établir, quelles informations seraient utiles et quelle voie humaine ou faisant autorité est disponible. Sinon, un contrôle de sécurité devient une autre barrière d’accès. Le principe linguistique de l’Europe est testé le plus clairement lorsqu’un système ne peut pas fournir la réponse demandée.

La conception opérationnelle d’un service multilingue

Un service multilingue digne de confiance a une forme opérationnelle facile à décrire et étonnamment difficile à maintenir. Premièrement, il nomme la tâche. La traduction, la transcription, la classification, la recherche, la synthèse et la génération ne sont pas interchangeables. Deuxièmement, il nomme le parcours linguistique, y compris l’écriture et toute frontière régionale ou de domaine pertinente. Troisièmement, il enregistre le matériel source et les transformations qui lui sont appliquées. Quatrièmement, il définit le parcours de révision et d’escalade. Cinquièmement, il indique à l’utilisateur ce que le système peut et ne peut pas affirmer.

Ces étapes ne sont pas une exigence de bureaucratie géante. Elles constituent le minimum nécessaire pour rendre une promesse linguistique testable. Si un fournisseur affirme qu’un modèle prend en charge le finnois, un acheteur devrait pouvoir demander si cela signifie la génération de texte, la reconnaissance vocale, la traduction depuis quelles langues, ou tout cela à la fois. Si une équipe produit affirme prendre en charge une langue régionale, elle devrait préciser si cette prise en charge repose sur des données natives, des données traduites, un petit ensemble d’évaluation ou une révision par des experts. Si la réponse est inconnue, inconnu est un statut valide.

Le service a également besoin d’une politique de changement. Un nouveau matériel de formation, un nouveau tokeniseur, un nouveau modèle de traduction, une nouvelle liste de terminologie ou une nouvelle population d’utilisateurs peuvent modifier le comportement linguistique. Une version qui améliore un parcours peut en régresser un autre. Un résultat de benchmark de l’année dernière ne décrit pas automatiquement le système d’aujourd’hui. Les enregistrements de versions, les tests comparatifs et un parcours pour signaler les erreurs spécifiques à une langue rendent le service maintenable plutôt que cérémoniel.

La maintenance a un côté humain. Les experts linguistiques ont besoin d’un moyen de voir les erreurs qui affectent leurs communautés. Les équipes de domaine ont besoin d’un moyen de distinguer une erreur de traduction d’une ambiguïté politique. Les opérateurs ont besoin d’un moyen de suspendre un parcours sans attendre qu’un fournisseur de modèles interprète une plainte. Les utilisateurs ont besoin d’un moyen de dire que le système a mal compris un mot, un contexte ou le nom d’une personne. Un service multilingue n’est pas complet lorsque le modèle est déployé. Il est suffisamment complet pour être responsable lorsque le prochain problème linguistique survient.

Provenance à travers un pipeline linguistique

La provenance devient concrète lorsque l’on suit un élément de sens à travers un système. Commencez par un paragraphe source. Enregistrez sa langue, son écriture, son auteur ou son institution lorsqu’ils sont connus, ses droits et sa finalité. S’il est segmenté, préservez la relation avec l’original. S’il est traduit, conservez la source ainsi que le traducteur ou le processus de traduction. Si un relecteur modifie le texte, enregistrez cela comme un nouvel état, et non comme un remplacement silencieux. Si le paragraphe devient un élément de référence, faites suivre la tâche, le corrigé, la langue et le compte rendu de relecture.

Au moment de l’exécution, la même discipline s’applique en sens inverse. Enregistrez quelle voie linguistique a traité la requête, quelle version du modèle ou de l’outil a été utilisée, quelles preuves sources ont été récupérées, quel état d’incertitude ou de refus a été atteint, et quelle action humaine a suivi. L’enregistrement n’a pas besoin d’exposer le contenu privé à chaque opérateur. Il doit rendre les faits matériels accessibles à un relecteur autorisé. Sans eux, un incident linguistique devient un débat sur des impressions.

C’est ici que la provenance multilingue diffère d’un journal d’audit générique. Un horodatage et un nom de modèle nous disent que quelque chose s’est produit. Ils ne nous disent pas si la source a été traduite, si la réponse a modifié un format de nombre, si une entité nommée a été normalisée, ou si le relecteur travaillait dans la langue cible. Le chemin de transformation est la preuve. Une réponse courte peut cacher une longue chaîne de décisions.

Il y a une petite vertu néerlandaise dans cette approche : gardez le registre assez ennuyeux pour que quelqu’un puisse l’utiliser un mardi après-midi. Un enregistrement de provenance ne doit pas être une étiquette de musée rédigée pour un audit qui n’arrivera peut-être jamais. Il doit aider un opérateur à répondre à la question suivante, à arrêter la bonne voie et à expliquer le résultat à une personne qui ne s’intéresse pas à votre schéma d’architecture. Une bonne gouvernance linguistique est légèrement terne. C’est ainsi que l’on sait qu’elle pourrait survivre au contact du travail.

Les choix cachés dans une traduction

Chaque système de traduction porte des choix qui méritent d’être nommés. La segmentation décide comment l’entrée est divisée. La normalisation décide quelles distinctions sont préservées ou écartées. L’alignement décide quelles parties de deux textes sont traitées comme équivalentes. La terminologie décide quels mots sont stables. Le décodage décide comment la sortie est sélectionnée. Le post-traitement décide ce que le lecteur voit. Aucune de ces étapes n’est intrinsèquement erronée. Chacune peut créer une défaillance spécifique à une langue, invisible dans une démonstration générale.

Prenons un nom propre. Un système peut le traduire, le translittérer, le préserver ou le remplacer par une orthographe familière. Pour un poème, plusieurs choix peuvent être défendables. Pour un document d’identité, un seul peut être acceptable, et celui-ci peut dépendre de l’autorité émettrice. Prenons une unité ou une date. Les valeurs peuvent rester mathématiquement équivalentes tandis que la forme devient ambiguë pour un lecteur. Prenons un nom ou un pronom genré. Une traduction peut introduire une information que la source a omise, ou effacer une distinction que la source a faite délibérément.

La réponse conceptuelle n’est pas de figer la langue. Elle consiste à énoncer la politique et à rendre l’exception visible. Une liste terminologique peut protéger les termes juridiques. Une règle sur les entités nommées peut empêcher une ville de devenir une personne. Une vue préservant la source peut permettre à un relecteur de comparer l’original et la sortie. Une escalade humaine peut être déclenchée par un nom à faible confiance, un désaccord entre les voies ou une tâche classée à haute conséquence. Le modèle reste utile parce que ses limites font partie du flux de travail.

Les grands modèles de langage rendent les choix plus difficiles à voir parce que la sortie est fluide. Une sortie fluide est une interface merveilleuse et une explication peu fiable. Le système peut produire une phrase qui semble naturelle tout en sélectionnant le mauvais sens d'un mot. Il peut préserver le sujet général tout en omettant une négation. Il peut traduire une expression locale en une formulation standard qui modifie la position de l'interlocuteur. C'est pourquoi la qualité linguistique ne peut pas être représentée par la seule grammaire. Le sens a une forme sociale.

Scripts, dialectes, registres et institutions

La prise en charge linguistique est souvent annoncée au niveau du nom d'une langue, mais les lecteurs rencontrent des scripts, des variétés et des registres. Un système qui gère l'orthographe standard moderne peut avoir du mal avec les documents historiques. Un système de reconnaissance vocale peut gérer l'audio en studio et échouer dans une gare bondée. Un chatbot destiné au public peut répondre dans un registre formel alors que l'utilisateur a besoin d'un langage simple. Une institution peut utiliser un terme qui diffère du langage courant pour une raison juridiquement importante.

Ce ne sont pas des cas limites au sens péjoratif. Ce sont les endroits où la langue rencontre le monde. Un nom régional peut faire la différence entre une adresse correcte et une livraison échouée. Un mot dialectal peut être le seul mot qu'une personne connaît pour un symptôme. Une phrase formelle peut signaler qu'un message a un effet juridique. Une variante de script peut déterminer si un document est consultable. Si un benchmark exclut ces voies, il peut encore être utile, mais il ne peut pas se substituer à l'ensemble de la langue.

Tester toutes les variétés n'est pas toujours possible. La réponse honnête consiste à décrire le sous-ensemble pris en charge et à inviter à fournir des preuves sur le reste. Un système peut publier qu'il a été évalué sur le néerlandais écrit standard pour la synthèse d'informations publiques, sans prétendre quoi que ce soit sur la reconnaissance vocale régionale. Il peut ajouter un test pour le frison ou le basque sans prétendre que cet ajout règle toutes les questions régionales et relatives aux langues minoritaires. La spécificité n'est pas une faiblesse. Elle indique aux utilisateurs où se trouve le plancher.

Les institutions devraient également résister à l'idée qu'une voie linguistique nationale unique est automatiquement neutre. Le langage administratif peut être inaccessible aux locuteurs de la même langue. L'accessibilité et le multilinguisme se recoupent parce que tous deux demandent si le lecteur peut comprendre et agir. Le travail linguistique de la Commission comprend des outils de simplification et de textes accessibles précisément pour cette raison. Une phrase peut être linguistiquement correcte et néanmoins institutionnellement inutilisable.

Quand l'interface est fluide mais erronée

Les échecs linguistiques les plus difficiles ne sont pas spectaculaires. Ce sont des réponses qui passent le test de l'œil. Un résumé inclut les bons noms mais change qui est responsable. Une traduction préserve les noms mais transforme une recommandation en instruction. Un classificateur comprend le sujet mais manque une négation. Un système vocal reconnaît les mots mais pas l'hésitation de l'interlocuteur. Un utilisateur lit la sortie dans sa propre langue et suppose que la fluidité est un signe de soin.

Nous devrions concevoir pour cette classe d'erreurs au lieu d'attendre qu'un exemple bizarre fasse la une. Comparez la source et la sortie pour les contenus à fort enjeu. Préservez les marqueurs d'incertitude. Gardez les citations ou les références documentaires attachées. Demandez une confirmation lorsqu'un nombre, un nom ou une échéance est central. Rendez la voie visible pour l'opérateur. Proposez un mécanisme de correction qui n'exige pas que l'utilisateur sache quel composant a échoué. Ces contrôles sont modestes, mais ils transforment une traduction en une transaction inspectable.

La relecture humaine ne doit pas être décrite comme une ligne de défense magique. Les relecteurs ont des contraintes de temps, des angles morts et leurs propres présupposés linguistiques. Une interface de relecture utile leur donne la source, la sortie, le contexte et la raison de l’escalade. Elle consigne les désaccords au lieu de les gommer. Si les relecteurs corrigent systématiquement un même terme, l’organisation peut améliorer la terminologie ou redéfinir le périmètre de la tâche. Si le désaccord révèle que la source elle‑même est ambiguë, la bonne action peut être de demander à l’auteur, pas d’entraîner le modèle plus durement.

Les opérateurs ont aussi besoin de voir les preuves négatives. Quelles langues n’ont pas été évaluées ? Quelles tâches n’ont pas de relecture humaine ? Quelles demandes ont été refusées ? Quels utilisateurs ont quitté le parcours après une traduction ? Une absence peut être un signal. Un tableau de couverture vert qui omet les chemins en échec est une carte de la surface marketing, pas du service.

L’expertise humaine n’est pas un bouton de secours

La politique européenne des technologies linguistiques met linguistes, data scientists, ingénieurs informatiques et spécialistes de domaine dans la même phrase. C’est une exigence de conception, pas une liste de professions à inviter à une réunion de lancement. Chacun voit un échec différent. Le linguiste voit une construction peu naturelle ou une distinction perdue. L’ingénieur voit un problème de segmentation ou de routage. Le spécialiste de domaine voit une erreur de catégorie dangereuse. L’opérateur voit une file d’attente dont personne ne veut s’occuper. La personne qui utilise le service vit une décision qui n’a plus de sens.

L’expertise humaine devrait intervenir avant que le référentiel ne soit figé. Un expert en langue peut aider à sélectionner des matériaux de test qui représentent des registres réels, pas seulement des phrases propres. Un expert de domaine peut identifier les termes qui ne doivent pas dériver. Un représentant de la communauté peut dire à une équipe quelle formulation semble officielle, familière ou insultante. Un gestionnaire de données peut expliquer quelle provenance est disponible et laquelle ne l’est pas. Ces apports façonnent le contrat du système. Ils ne sont pas une décoration après que les choix techniques ont été faits.

Il y a un coût, bien sûr. Une bonne relecture prend du temps et rémunère des savoirs souvent traités comme invisibles. Ce coût fait partie du support linguistique. L’alternative est de l’externaliser vers les utilisateurs, qui paient avec de la confusion et des recours, ou vers le personnel, qui traduit et répare le parcours de manière informelle. Un système qui semble économique parce qu’il ignore l’expertise linguistique n’est pas efficace. Il a simplement déplacé la facture.

Ce qu’un référentiel équitable doit exposer

Un référentiel multilingue devrait commencer par une affirmation assez restreinte pour être testée. L’affirmation pourrait être qu’un système peut répondre à des questions d’information publique dans un ensemble de langues, préserver les dates et les nombres, et refuser lorsque la preuve source manque. Elle pourrait être qu’un parcours de traduction gère une paire et un domaine donnés à un niveau de qualité défini. Elle pourrait être qu’un système de reconnaissance vocale peut transcrire une variété spécifiée dans des conditions acoustiques spécifiées. Le référentiel est un contrat pour cette affirmation.

Le contrat a besoin de plus qu’une liste de langues. Il devrait exposer la tâche, la source, le domaine, le registre, l’écriture, la direction, la longueur du contexte, les conditions d’entrée, les réponses de référence, les variantes acceptables, les métriques, la relecture humaine et l’incertitude. Il devrait indiquer si les éléments ont été rédigés à l’origine dans chaque langue ou traduits. Il devrait consigner qui les a révisés et quels désaccords subsistaient. Il devrait séparer les résultats agrégés des résultats par langue. Il devrait montrer assez d’exemples pour qu’un lecteur puisse comprendre ce que le score mesure.

The EU MMLU criteria are useful because they widen the word fair. Balanced representation across the EU’s official languages is one part. Retaining meaning, difficulty and testing value across languages is another. Testing EU values and cultural contexts, including idioms, humour, references, date and number formats, tone and politeness, makes the benchmark a social instrument as well as a technical one. The criteria do not remove judgement. They make the judgement inspectable.

Benchmark designers should publish failure slices, not only averages. A model can have a good mean score while failing every item involving a particular register or type of number. A route can be efficient in one direction and slow or expensive in another. A metric can correlate with human judgement in one language and become unstable in another. Per-language and per-task views are not a luxury. They are how a buyer avoids purchasing the average while deploying the exception.

Finally, a benchmark should state what it cannot tell us. A written test does not establish speech performance. A translation score does not establish legal reliability. A set of official languages does not establish support for regional or minority languages. A high score does not establish that a person can challenge a decision. The limitation is not an embarrassment. It is the edge of the map, and users need to see it before they sail.

A score is a map legend, not the territory

Numbers are useful because they force a comparison. They are dangerous because they invite a conclusion larger than the measurement. A score can tell us how a system behaved on a defined sample under a defined method. It cannot tell us how a community will experience the system without a bridge of assumptions. The bridge may be sound. It must be named.

Suppose a system improves on a multilingual benchmark after fine-tuning. That is evidence of improved performance on that evaluation. It is not automatically evidence that the system is safer in a public service. The service may use different terminology, longer context, speech input, a different register or a downstream workflow that turns a suggestion into a decision. The benchmark can still be valuable. It becomes more valuable when the organisation says which part of the service it represents.

The same discipline applies to energy, speed and cost. A low-resource language route may require more human review or a larger retrieval context. That is not a defect to conceal in an average. It is a property of the service that should inform design. European institutions have spent decades building translation and language services because the practical cost of linguistic diversity is real. An AI system does not abolish that cost by emitting text quickly.

There is no shame in choosing a narrower route. A team can support fewer tasks well, publish the boundary and add languages as evidence grows. That is better than claiming every language and asking users to discover the gaps. The European instinct for a standard is strongest when it is paired with the Dutch instinct to check whether the thing works on an ordinary Wednesday.

Build for 24, test beyond 24

The European Union has 24 official and working languages, and the Commission’s translation service operates across them. That number creates a useful baseline for public infrastructure. It does not define Europe’s linguistic life. Regional, minority, non-territorial and migrant languages also shape communities and institutions. A system built for 24 can still exclude people who do not use one of those routes, or who use an official language in a form the system did not evaluate.

Construire pour 24 est donc une responsabilité de rendre la base réelle, pas une permission de s'arrêter. Une voie linguistique doit porter ses propres preuves. Un organisme public doit pouvoir dire quelles langues officielles sont couvertes pour quelles tâches, quel examen humain existe et où les utilisateurs peuvent obtenir une version faisant autorité. Il doit aussi avoir un moyen d'apprendre des langues hors de l'ensemble initial sans transformer la communauté en laboratoire d'essai bénévole.

Tester au-delà de 24 signifie plus qu'ajouter une langue de nouveauté à une démonstration. Cela signifie travailler avec des locuteurs, des institutions et des chercheurs pour décider ce qu'est la tâche, à quoi le matériel source peut servir et ce qui compte comme une erreur nuisible. Le processus peut produire une capacité restreinte et soigneusement délimitée. C'est toujours un progrès. Une voie modeste avec un contrat clair peut valoir plus qu'une affirmation impressionnante qu'aucun opérateur ne peut défendre.

Ce que nous cherchons à rendre explicite

Chez Dweve, nous abordons ce sujet du côté de l'infrastructure. Loom est décrit dans nos documents publics comme un modèle cognitif compilé par tâches dont les composants linguistiques rendent un graphe de résultats gouverné, tandis que l'apprentissage de contraintes, la composition de graphes, les solveurs et la vérification portent l'autorité de décision. C'est une position architecturale, pas une affirmation de performance multilingue. Cela ne rend pas une voie linguistique correcte. Cela rend une obligation difficile à cacher : la sortie linguistique ne devrait pas être le seul endroit où existent le raisonnement et les preuves du système.

Notre travail Ground Truth fait le même point à une échelle plus humaine. Les gens ont besoin d'assez de langage partagé pour distinguer un modèle d'un flux de travail, une prédiction d'une preuve et une réponse fluide d'un résultat vérifié. Dans les systèmes multilingues, ce vocabulaire a besoin d'un mot de plus : voie. Une réponse en néerlandais, une réponse en français et une réponse en basque ne sont pas de simples rendus d'un seul événement interne si les preuves, la terminologie, l'examen et le comportement en cas d'échec diffèrent. La voie fait partie de l'affirmation.

Cette position est délibérément moins excitante que de dire qu'un modèle comprend l'Europe. Elle est aussi plus utile. Nous voulons qu'un système montre ce qu'il a reçu, quelles sources et contraintes il a pu utiliser, ce qu'il n'a pas pu établir et quand un humain devrait prendre le relais. La langue est une surface à travers laquelle une personne rencontre ce travail. La surface doit être claire, mais elle ne doit pas être autorisée à effacer la structure en dessous.

Nous ne sommes pas exemptés des normes décrites ici. Un champ de provenance ne répare pas des données manquantes. Un chemin déterministe ne prouve pas qu'une traduction est équitable. Une frontière de traitement européenne ne confère pas de compétence linguistique. La seule façon honnête de faire une affirmation multilingue est de continuer à tester, de publier les limites et de laisser les experts linguistiques contester la voie. Le nom du produit n'est pas une preuve. Le dossier l'est.

Une norme pratique pour les équipes

Les équipes qui décident d'introduire une fonctionnalité d'IA multilingue peuvent commencer par une courte série de questions. Que doit exactement faire le système dans chaque langue ? Quelles personnes sont affectées s'il se trompe ? Quel matériel source fait autorité ? Comment les éléments de test ont-ils été créés, et par qui ? Quels registres, écritures, dialectes et domaines sont inclus dans l'affirmation ? Que fait le système lorsqu'il ne peut pas établir le sens ? Qui peut mettre la voie en pause ? Comment un utilisateur peut-il corriger une réponse sans devenir le linguiste bénévole du projet ?

Les questions deviennent concrètes lorsqu'elles sont attachées à des artefacts. Tenez une fiche de voie linguistique avec la tâche, les variétés linguistiques prises en charge, les familles de sources, le statut des droits, les versions du modèle et des outils, les résultats d'évaluation, les modes d'échec connus et le responsable de l'examen. Conservez des exemples d'erreurs avec leur contexte, pas seulement un score. Gardez la source à côté d'une traduction à enjeu élevé. Conservez une raison d'escalade qu'un opérateur peut comprendre. Tenez un registre des modifications lorsqu'un tokeniseur, une liste de terminologie, un banc d'essai ou un modèle change.

Les équipes d’achat peuvent demander aux fournisseurs des résultats par langue et par tâche plutôt qu’une moyenne multilingue unique. Elles peuvent demander si un benchmark a été traduit ou rédigé en langue native, si des jugements humains sont disponibles, comment les parcours à faibles ressources sont traités, et si le fournisseur peut exporter les éléments de preuve nécessaires à une revue. Elles peuvent demander ce qui se passe lorsqu’une langue n’est pas prise en charge, car un refus et un repli silencieux ont des conséquences très différentes.

Les équipes produit peuvent concevoir l’interface pour afficher le parcours et la confiance sans prétendre qu’un score de confiance est une probabilité de vérité. Elles peuvent conserver les liens sources, utiliser un langage clair dans les refus et rendre les actions de revue visibles. Elles peuvent éviter l’expression « prend en charge toutes les langues » à moins de pouvoir définir le verbe. « Prendre en charge » peut signifier afficher du texte, accepter une saisie, traduire, résumer, répondre, classer, parler ou gérer un flux de travail réglementé. Un sélecteur de langue n’est pas une spécification.

Les équipes de recherche peuvent publier des jeux de données avec leur provenance et des parcours de correction. Elles peuvent inclure des résultats négatifs et signaler lorsqu’une métrique ne se transpose pas bien. Elles peuvent inviter les communautés linguistiques à participer à l’évaluation avant qu’un modèle ne soit déclaré prêt, et rémunérer cette expertise. Elles peuvent résister à la pression de transformer un résultat étroit en affirmation universelle. Le benchmark le plus précieux est peut-être celui qui amène une équipe à retirer une phrase de sa page produit.

La société derrière le modèle

Un modèle de langue peut être très bon pour produire du langage sans savoir ce que le langage fait dans une société. Il peut prédire une phrase, traduire un paragraphe et répondre à une question tout en manquant la relation institutionnelle portée par les mots. Cet écart n’est pas la preuve que le modèle est inutile. C’est la preuve que le langage est plus qu’un type de données.

La réponse de l’Europe ne devrait pas être une compétition pour compter les langues dans une fiche de modèle. Elle devrait être un effort soutenu pour faire de la donnée linguistique, des droits, de l’expertise, de l’évaluation et du contrôle public une même infrastructure. Les travaux de la Commission sur les technologies linguistiques, l’Espace européen des données linguistiques, la Grille européenne des langues et le benchmark EU MMLU vont tous dans cette direction. Les chercheurs européens testent ce qui se passe lorsque des benchmarks traduits sont traités comme des questions de recherche plutôt que comme des instruments incontestés. Ces travaux méritent l’attention parce qu’ils rendent techniquement visible un vieux fait politique : les citoyens ne vivent pas l’Union dans une seule langue.

La prochaine fois qu’un fournisseur dira qu’un modèle est multilingue, demandez ce que contient cette affirmation. Quelles langues ? Quelles tâches ? Quelles communautés ? Quelles sources ? Quelle revue ? Quel refus ? Quel historique de modification ? La question n’est pas hostile. C’est le commencement ordinaire de la responsabilité.

Une société ne devient pas juste parce qu’une machine peut répéter ses mots. Elle devient plus juste lorsque les gens peuvent entrer dans ses institutions, comprendre ce qui se passe, contester un résultat et être entendus dans la langue qui porte leur vie. Un modèle peut aider à ce travail. Il ne peut pas le définir. La langue d’un modèle est une capacité technique. La langue d’une société est une responsabilité partagée.

Sources