Automatiser en arabe, en français, en Darija et en amazighe : une machine peut-elle vraiment nous comprendre ?

Il suffit d’écouter une conversation au Maroc pour comprendre que la langue n’est jamais un simple code.

Une personne peut commencer en Darija, introduire un mot français, utiliser un terme anglais lié à son travail, puis reformuler sa demande en arabe classique lorsqu’elle s’adresse à une administration. Dans une autre situation, elle pourra s’exprimer en amazighe, changer de registre selon son interlocuteur et adapter son vocabulaire au contexte. Dans le Nord, elle peut aussi glisser un mot ou une tournure espagnole dans une phrase en Darija ; ailleurs, le même besoin sera formulé avec un vocabulaire et un rythme différents.

C’est cette réalité linguistique que les technologies d’intelligence artificielle veulent désormais automatiser.

Un assistant vocal pour les services publics. Un chatbot pour l’université. Une application agricole capable de répondre aux exploitants. Un outil de santé qui oriente les patients. La promesse est attractive : une machine disponible à toute heure, capable de répondre à chacun dans la langue qu’il maîtrise le mieux.

Mais une question demeure : une machine qui reconnaît quelques mots comprend-elle réellement la personne qui les prononce ?

Il faut distinguer trois capacités que les discours commerciaux mélangent souvent : reconnaître les mots, interpréter l’intention et agir correctement. Un système de speech recognition peut transcrire une phrase avec une bonne précision et se tromper sur la demande. Un modèle peut identifier « rendez-vous » sans comprendre s’il faut prendre, déplacer ou confirmer ce rendez-vous. Et même lorsqu’il comprend l’intention, il doit encore savoir s’il a le droit d’agir ou s’il doit passer la main à un humain.

Une phrase n’est jamais seulement une phrase

Dans les laboratoires d’intelligence artificielle, on parle de multilingual NLP, c’est-à-dire le traitement automatique de plusieurs langues. On développe des modèles capables de traduire, résumer, transcrire ou classer des textes.

Ces tâches sont importantes, mais elles ne suffisent pas.

Comprendre une demande exige aussi d’identifier l’intention, le niveau de politesse, le contexte social, l’urgence et parfois l’ironie. Les chercheurs parlent d’intent detection pour la détection de l’intention et de context understanding pour la compréhension du contexte.

Or, ces éléments ne sont pas toujours écrits explicitement.

Une personne qui dit en Darija qu’elle veut « voir ce qui est possible » ne demande pas forcément une liste de possibilités. Elle peut chercher une autorisation, un conseil ou simplement un interlocuteur capable de l’écouter. Une demande formulée avec humour peut dissimuler une inquiétude. Une réponse techniquement correcte peut être socialement inadaptée.

La machine aura peut-être compris les mots. Elle n’aura pas nécessairement compris la situation.

Le véritable test n’est donc pas de demander à une IA de réciter une phrase dans quatre langues. C’est de lui confier une situation réelle, avec ses hésitations, son urgence et son contexte, puis de vérifier si la personne obtient effectivement le bon service.

La Darija n’est pas une erreur à corriger

La Darija est parfois traitée comme une version informelle ou incomplète de l’arabe. Dans certaines interfaces, elle apparaît comme une langue qu’il faudrait « nettoyer » avant de pouvoir la traiter correctement.

Cette vision est dangereuse.

La Darija possède ses propres usages, ses expressions, ses nuances, ses variations régionales et ses règles implicites. Il n’existe donc pas une Darija marocaine parfaitement homogène que l’on pourrait enregistrer une fois pour toutes dans un modèle.

Dans le Nord, notamment dans les zones où les échanges avec l’Espagne sont fréquents, le code-switching peut associer Darija, espagnol, français et anglais technique. Une demande comme « bghit nconfirmi la cita » ne doit pas être considérée comme une phrase mal écrite : elle porte une intention compréhensible, un contexte administratif et une habitude linguistique locale. Le système doit reconnaître ce mélange sans effacer la partie espagnole ni la forcer vers une traduction approximative.

Les différences ne sont pas seulement géographiques. Le vocabulaire, la prononciation et le degré de mélange peuvent varier entre une grande ville, une petite commune, un quartier populaire, un milieu universitaire, un environnement professionnel ou une famille. Une personne peut parler différemment selon qu’elle s’adresse à un proche, à un médecin, à un enseignant ou à une administration. Les appartenances locales, les réseaux sociaux et les trajectoires migratoires ajoutent encore d’autres nuances. Il faut parler de variétés et de répertoires linguistiques, plutôt que de caricaturer une région ou de prétendre qu’une seule transcription représente tous ses habitants.

Cette diversité a une conséquence technique directe : entraîner un modèle sur quelques locuteurs urbains, jeunes et très connectés ne suffit pas pour représenter les usages du pays. Les jeux de données doivent documenter, de manière volontaire et anonymisée, la région, le contexte d’usage, le canal et le registre lorsque ces informations sont pertinentes. Elles ne doivent jamais servir à déduire automatiquement une identité sociale ou à enfermer un utilisateur dans une catégorie.

Un utilisateur peut écrire en alphabet arabe, en alphabet latin, avec des chiffres pour représenter certains sons, avec des mots espagnols, français ou anglais et avec une orthographe phonétique variable. Ce mélange n’est pas nécessairement un problème de l’utilisateur. C’est souvent le fonctionnement naturel de la communication numérique. Une normalisation utile doit conserver le message original, signaler les passages incertains et permettre de comparer plusieurs transcriptions sans imposer une orthographe artificielle.

Il faut aussi résister à la tentation de déduire l’identité d’une personne à partir de sa manière d’écrire. Un mot espagnol ne prouve pas qu’elle vient du Nord ; un accent ne résume pas un milieu social ; une forme amazighe ne permet pas de conclure sur son parcours. Ces indices peuvent aider à améliorer un système, mais ils ne doivent pas devenir des critères cachés pour accorder un service, évaluer un dossier ou prédire une compétence.

L’amazighe pose d’autres défis : diversité des variantes, choix de transcription, disponibilité des données, reconnaissance vocale et représentation des usages locaux. Dans les technologies linguistiques, une langue disposant de peu de ressources numériques est souvent qualifiée de low-resource language.

Cela signifie qu’elle dispose de moins de textes annotés, de moins d’enregistrements vocaux et de moins d’outils spécialisés. Le risque est alors que le système fonctionne correctement dans les langues les mieux représentées et devienne approximatif pour les autres.

Le risque d’une nouvelle inégalité

Imaginons un assistant administratif capable de traiter parfaitement une demande en français, correctement une demande en arabe classique et de manière hésitante une demande en Darija.

Officiellement, le service est multilingue.

Dans les faits, les citoyens ne bénéficient pas du même niveau d’accès. Les uns obtiennent une réponse précise et immédiatement exploitable. Les autres doivent reformuler, passer à une autre langue ou demander l’aide d’un proche.

C’est une forme de language bias, un biais linguistique. Le système ne refuse pas explicitement une langue, mais il lui accorde moins de précision, moins de contexte ou moins de confiance.

Ce biais peut avoir des conséquences concrètes : mauvaise orientation dans une démarche administrative, erreur dans une demande de bourse ou d’inscription, réponse médicale mal comprise, mauvaise classification d’un problème agricole ou exclusion de personnes peu à l’aise avec le français ou l’arabe formel.

L’automatisation risque alors de réduire le temps de traitement pour certains tout en ajoutant une nouvelle barrière pour d’autres.

Un chatbot ne doit pas être un traducteur amélioré

La solution ne consiste pas simplement à ajouter quatre langues dans un menu.

Un système sérieux doit distinguer plusieurs étapes :

Message de l’utilisateur
        ↓
Détection de la langue et du registre
        ↓
Identification de l’intention
        ↓
Recherche dans une source vérifiée
        ↓
Génération de la réponse
        ↓
Contrôle linguistique et métier
        ↓
Validation humaine si nécessaire

La language identification détecte la langue ou le mélange de langues. Le RAG (Retrieval-Augmented Generation) recherche des documents avant que le modèle ne formule sa réponse. Les guardrails limitent les réponses ou les actions dangereuses. Le human-in-the-loop permet à une personne de vérifier ou d’interrompre les situations sensibles.

Le système doit également prévoir un fallback, c’est-à-dire une procédure alternative lorsque la compréhension est insuffisante : demander une précision, proposer un autre canal ou transférer la demande à un agent humain.

Cette possibilité de s’abstenir est essentielle. Une IA qui répond toujours n’est pas forcément plus intelligente. Elle peut simplement être plus imprudente.

Le défi commence par les données

Les modèles ne comprennent pas spontanément les réalités marocaines. Ils apprennent à partir de données.

La question devient donc : quelles données voulons-nous utiliser ? Des conversations anonymisées ? Des documents administratifs ? Des enregistrements vocaux ? Des interactions universitaires ? Des échanges agricoles ? Qui les sélectionnera ? Qui les annotera ? Comment vérifiera-t-on qu’une expression a été correctement comprise ?

Il faut également documenter les données avec une véritable data governance, c’est-à-dire une gouvernance qui précise leur origine, leur finalité, les personnes autorisées à les consulter, les méthodes d’anonymisation et les procédures de correction ou de retrait.

La qualité d’un modèle dépendra autant de cette organisation que de la puissance de son architecture. Un jeu de données linguistique peut sembler représentatif tout en excluant certains accents, certaines régions ou certains usages sociaux.

Une évaluation sérieuse doit donc tester plusieurs contextes, plusieurs niveaux de langue et plusieurs manières d’écrire une même expression. Il faut mesurer les erreurs par langue, mais aussi par situation : demande urgente, conversation orale, texte court, formulaire administratif ou échange pédagogique.

Au Maroc, le protocole devrait aussi comparer plusieurs profils d’usage : Darija principalement arabophone, Darija mêlée d’espagnol dans le Nord, Darija fortement francisée dans certains contextes professionnels, variétés amazighes et formes de transcription en alphabet arabe ou latin. Il ne s’agit pas d’établir un classement entre les locuteurs. Il s’agit de vérifier que la performance ne s’effondre pas dès qu’un utilisateur sort de la variété la plus représentée dans les données d’entraînement.

Un jeu de tests peut reprendre la même intention — prendre rendez-vous, demander un document, signaler une panne — en faisant varier la région, le registre, la langue dominante et le canal. Les évaluateurs doivent noter l’intention reconnue, la politesse, la conservation des termes importants, la pertinence de la réponse et la capacité du système à demander une clarification. Un bon modèle n’a pas besoin de deviner l’origine de la personne ; il doit comprendre la demande et reconnaître honnêtement ce qui lui manque.

Construire avec les locuteurs, pas seulement pour eux

La qualité d’un modèle linguistique ne se mesure pas uniquement au nombre de milliards de paramètres. Elle dépend aussi des personnes qui ont produit les exemples, de celles qui les ont annotés et de celles qui ont le droit de corriger le système.

Un projet marocain sérieux devrait réunir des locuteurs de plusieurs régions, générations et contextes d’usage : habitants des grandes villes et des petites communes, étudiants, agriculteurs, commerçants, agents publics, professionnels de santé et personnes moins habituées aux interfaces numériques. Il devrait documenter les situations de parole plutôt que coller une étiquette définitive à chaque personne. Une même voix peut utiliser un registre à la maison, un autre au travail et un troisième devant une administration.

La collecte doit être fondée sur un consentement clair, une anonymisation réelle et une possibilité de retrait. Les personnes qui annotent les données devraient pouvoir signaler plusieurs interprétations lorsqu’une expression est ambiguë, au lieu d’être obligées de produire une traduction unique. Ce désaccord est une information utile : il révèle les endroits où le modèle doit demander une précision.

On peut commencer par une expérimentation limitée et vérifiable : choisir quelques intentions à faible risque — suivre un dossier, demander un horaire, signaler une panne —, les faire formuler dans plusieurs répertoires linguistiques, puis comparer trois systèmes : texte original, texte normalisé et réponse avec human-in-the-loop. Les indicateurs ne seraient pas seulement le word error rate, qui mesure les erreurs de transcription, mais aussi la réussite de la tâche, le taux de mauvaise orientation, le nombre de clarifications nécessaires et la satisfaction des locuteurs. Le résultat devrait être publié avec ses limites, par variété et par contexte, plutôt que résumé par un score moyen flatteur.

Des cas d’usage qui méritent une vraie prudence

Dans l’éducation, un assistant pourrait aider un étudiant à comprendre une notion en français, en arabe ou en Darija. Mais il devrait aussi indiquer ses sources, distinguer une explication d’une réponse officielle et éviter de remplacer l’enseignant.

Dans l’agriculture, un service vocal pourrait aider à interpréter une alerte météo ou à identifier un problème de culture. Mais une réponse incertaine devrait être transmise à un technicien plutôt que présentée comme un diagnostic.

Dans les services publics, un chatbot pourrait expliquer une procédure. Il ne devrait pas décider seul de l’éligibilité d’une personne ni empêcher un recours.

Dans la santé, les exigences devraient être encore plus fortes : incertitude explicite, données minimisées, transfert rapide vers un professionnel et aucune illusion de diagnostic autonome.

Dans chaque cas, la question n’est pas uniquement : « Le modèle répond-il ? » Il faut aussi demander si la réponse est comprise, correcte dans le contexte local, vérifiable, contestable et rattachée à une responsabilité identifiable.

Un protocole d’évaluation pourrait faire relire les mêmes demandes par des locuteurs de plusieurs langues et comparer non seulement la traduction, mais aussi l’intention reconnue, la pertinence de la réponse et le nombre de demandes de clarification. Les résultats devraient être publiés par langue et par type de situation, sans masquer les cas où le modèle échoue.

Il faudrait également distinguer une langue et un registre. Une réponse en arabe classique n’a pas le même effet qu’une réponse en Darija dans un service de proximité. La meilleure sortie n’est pas toujours celle qui ressemble le plus à la langue de la requête ; c’est celle qui est comprise et appropriée au contexte.

L’inclusion linguistique est un choix politique

La question des langues dans l’intelligence artificielle n’est donc pas seulement une question de performance technique. Elle concerne la place accordée aux citoyens dans les systèmes numériques.

Une langue peut être reconnue officiellement et pourtant rester pratiquement absente des interfaces, des jeux de données ou des tests. Une autre peut être disponible dans le menu mais mal prise en charge par le modèle.

On objectera qu’il est coûteux de développer et d’évaluer plusieurs variantes linguistiques. C’est exact, mais le coût ne disparaît pas lorsqu’on l’ignore : il revient sous la forme de reformulations, d’appels au support, d’erreurs de dossier et de perte de confiance. Une automatisation multilingue doit donc commencer par les situations où l’inclusion apporte un bénéfice réel, puis élargir progressivement son périmètre.

L’inclusion ne consiste pas à afficher plusieurs drapeaux ou à traduire quelques boutons. Elle consiste à offrir un niveau comparable de compréhension, d’accès et de recours.

La feuille de route devrait être progressive : commencer par des démarches réversibles, afficher clairement la langue et le registre pris en charge, conserver une trace de la décision, offrir un bouton ou un numéro de recours humain, puis élargir seulement après un audit indépendant. Dans une administration, une erreur de formulation peut être corrigée ; une mauvaise décision automatisée peut, elle, priver une personne d’un droit ou d’une opportunité.

Je préfère un système qui reconnaît ses limites à un assistant qui prétend parler toutes les langues. Une machine qui dit « je n’ai pas compris, pouvez-vous préciser ? » est parfois plus utile qu’une machine qui produit immédiatement une réponse élégante mais fausse.

Le véritable progrès ne sera pas de faire parler les machines en arabe, en français, en Darija et en amazighe. Il sera de leur apprendre à écouter sans effacer les nuances, à expliquer leurs incertitudes et à laisser une place à l’humain lorsque la technologie atteint ses limites.

Au Maroc, l’IA multilingue ne devrait pas commencer par la question : « Combien de langues notre modèle peut-il générer ? »

Elle devrait commencer par celle-ci : dans quelle langue une personne peut-elle être comprise, respectée et correctement servie ?