Comment faire comprendre à un chatbot IA la darija marocaine et d’autres dialectes

Ce qui s’est passé dans mon SaaS de support dentaire marocain

J’ai construit un SaaS de support client pour des cliniques dentaires au Maroc. Au début, j’ai supposé que la qualité dialectale nécessitait d’affiner un modèle local. Cela ressemblait à la réponse technique : collecter des données, entraîner un modèle, l’héberger, et faire de la darija une partie des poids. Avant de m’engager dans ce travail, j’ai essayé une intervention plus légère. Nous avons collecté de vrais exemples de support auprès d’assistantes ayant travaillé dans des cliniques dentaires. Elles connaissaient les expressions que les patients utilisent pour la douleur, les rendez-vous, les prix, les urgences, et le suivi. Nous avons placé ces exemples dans le contexte du prompt. La qualité s’est améliorée rapidement.

Les exemples faisaient plus que traduire du vocabulaire. Ils montraient le ton, l’intention, la politique de la clinique, quand poser une autre question, et quand appeler un outil de réservation. Cette distinction compte. Un dictionnaire peut expliquer qu’un mot désigne un rendez-vous. Un exemple travaillé montre comment l’assistant devrait répondre quand un patient utilise ce mot en décrivant une douleur et en demandant le premier créneau disponible.

Le même schéma s’est répété sur une construction très différente : une agence de traduction voulait que ses clients passent commande, obtiennent un devis, et paient entièrement dans une conversation de chat, sans page de dépôt de fichier, sans caisse séparée. Ses clients étaient des Marocains émigrés dispersés en France, aux États-Unis, et dans le Golfe, si bien qu’un même fil pouvait passer de la darija au français, à l’arabe égyptien, puis à l’anglais en pleine conversation. Sur une quarantaine de projets de chatbot à ce jour, la plupart pour des cliniques et cabinets dentaires au Maroc et quelques-uns pour des entreprises américaines, le problème de langue et le problème d’architecture se sont révélés être le même problème : un modèle qui comprend les mots ne suffit pas si le système autour de lui ne peut pas router, vérifier, et agir correctement sur ce qu’il a compris.

Ce que doit contenir un bon exemple few-shot

Pourquoi l’alternance de codes casse les modèles génériques, et ce qui la corrige vraiment

La darija est déjà un mélange d’arabe, de français, d’espagnol, et d’influence amazighe, si bien qu’un simple message du client mélange couramment plusieurs langues dans une seule phrase. Corriger cela ne consiste pas à trouver un modèle plus grand. C’est une couverture few-shot disciplinée de ce mélange, combinée au choix d’un modèle de base réellement solide en arabe, en français, et en anglais à la fois, plutôt qu’un modèle conçu d’abord pour l’anglais avec de l’arabe ajouté en plus. L’agent répond aussi toujours en caractères arabes, jamais en darija translittérée en alphabet latin. Les réponses en lettres arabes produisent moins d’erreurs en aval et paraissent plus naturelles à un client marocain qu’un texte translittéré.

Un échec récurrent mérite d’être nommé précisément, car ce n’est pas un problème de vocabulaire : un client tape نرف pour dire à peu près « je veux savoir » (du verbe darija عرف, savoir). En écriture Arabizi, l’orthographe correcte garde le chiffre : n3rf, où le 3 remplace la lettre arabe ع. Quand quelqu’un omet le chiffre et écrit nerf, le message devient visuellement et phonétiquement identique au mot français désignant un nerf. Un modèle multilingue sans préparation spécifique pour ce cas lit du français et répond à propos d’un nerf au lieu de reconnaître l’intention darija. La solution n’est pas un glossaire plus long. C’est de demander à l’agent de traiter exactement cette classe d’ambiguïté, un mot darija qui entre en collision avec un vrai mot d’une autre langue une fois le chiffre omis, comme un signal pour poser une brève question de clarification plutôt que de deviner. C’est la même discipline qu’applique instinctivement un assistant humain. Laissé seul, un modèle choisira avec assurance la mauvaise langue.

L’architecture derrière tout ça : un orchestrateur, pas un seul long prompt

Dès qu’un chatbot doit faire plus que répondre à des questions, un long prompt système cesse d’être un problème de langue et devient un problème d’architecture. La construction commande-et-paiement ci-dessus utilisait un orchestrateur qui route chaque tour vers un sous-agent spécialisé : l’un gère les FAQ, l’un gère la création et le statut des commandes, l’un gère le paiement, l’un gère les salutations et la conversation légère. Chaque sous-agent a un prompt étroit centré sur sa propre tâche et ses propres outils, exposés via MCP, dont certains écrivent directement dans la plateforme de commandes existante du client : créer une commande, vérifier un statut, confirmer un paiement. L’orchestrateur compose leurs sorties en une seule réponse. Cela garde chaque prompt assez court pour rester fiable, et cela signifie qu’un changement dans le comportement de l’agent de paiement ne peut pas accidentellement modifier la façon dont l’agent FAQ répond à une question de prix.

Les exemples few-shot sont injectés au moment de l’exécution à l’intérieur de cette structure, pas figés dans un seul prompt système statique. Quand un message arrive en darija, la couche de routage le détecte et injecte des exemples en darija ciblés sur le sous-agent qui gère cette intention, pas un ensemble fixe collé en haut de chaque conversation. Cela garde le contexte ciblé et permet de corriger un cas particulier dialectal sans toucher au reste du comportement du système.

L’agent de paiement reçoit le moins de confiance du système

Tout sous-agent connecté à un outil capable de créer une commande, de déplacer de l’argent, ou d’écrire dans le système en production d’un client représente une vraie surface d’attaque. L’injection de prompt occupe la première place du classement OWASP LLM Top 10 depuis chaque édition, et le risque augmente précisément quand un LLM dispose d’outils capables d’envoyer des messages, d’appeler des API, ou de faire des achats : une injection réussie permet à un attaquant d’utiliser tout ce que l’outil peut faire. En pratique, cela signifie que les agents de paiement et d’écriture de commandes reçoivent les permissions d’outils les plus étroites possibles, une validation structurée de la sortie avant toute exécution, et une étape de confirmation explicite avant qu’une action irréversible ne passe, plutôt que de faire confiance au seul jugement du modèle pour décider si une action est sûre.

Source : OWASP Top 10 pour les applications LLM

Commencer avec un taux d’escalade élevé, et mériter l’autonomie

Chacun de ces agents démarre avec un taux d’escalade vers un humain délibérément élevé. L’instinct de rendre un agent totalement autonome dès le premier jour est exactement ce qui provoque des erreurs irréversibles : une commande confirmée à tort, un rendez-vous qui n’a jamais existé, une réponse sur laquelle un patient agit. L’autonomie se mérite progressivement, un cas particulier résolu à la fois, jusqu’à ce que l’agent atteigne le taux d’autonomie le plus élevé qui tienne sous un trafic réel. Un agent qui n’escalade jamais n’est pas un signe de qualité. En 2026, je n’en ai livré aucun à qui je ferais confiance pour fonctionner ainsi.

Comment évaluer la qualité dialectale

En pratique, cela fonctionne comme un ensemble de régression qui grandit. Chaque échec réel repéré en test devient un cas de test permanent, réparti entre évaluations par agent (l’agent de paiement choisit-il le bon outil et les bons arguments) et évaluations de conversation entière (la réponse orchestrée a-t-elle du sens de bout en bout). Les cas faciles et bien compris sont notés automatiquement par un modèle juge. Tout ce qui est nouveau, ou tout ce sur quoi le juge automatique n’a pas encore fait ses preuves, est noté manuellement. Un locuteur natif ne s’assied pour vraiment parler au bot qu’après cette passe automatisée, car à ce stade la plupart des bugs évidents ont déjà été repérés, et cette relecture peut se concentrer sur le ton et le naturel plutôt que sur la chasse aux bugs.

Pour les agents spécifiques à la darija, j’ai gardé GPT-4.1 comme choix de production par défaut plutôt que de passer à une sortie plus récente, principalement pour l’efficacité de coût, avec une qualité comparable ou meilleure sur cette tâche linguistique précise. Ce n’est pas le modèle le plus fort en appel d’outils, ce qui explique justement pourquoi la responsabilité de l’appel d’outils reste confiée à des agents spécialisés étroits plutôt qu’à un seul prompt généraliste censé tout faire à la fois. Pour évaluer n’importe quel modèle sur la darija ou un autre dialecte sous-représenté, les classements généraux sont presque inutiles. Des benchmarks arabes conçus spécifiquement pour tester la variation dialectale et l’écriture sont un signal bien meilleur.

Source : Arabic LLM Broad Leaderboard (Silma AI)

Source : Awesome Arabic NLP (liste de ressources organisée)

Les exemples few-shot ne résoudront pas tout problème de langue. L’affinage peut aider quand le comportement doit rester cohérent sur un grand volume et que le prompt est devenu trop coûteux ou fragile. Mais je ne commencerais pas par là. Je prouverais d’abord que de bons exemples et un ensemble d’évaluation représentatif peuvent produire le comportement voulu. Cela vous donne des données plus propres si vous décidez ensuite d’affiner.