L'IA parle-t-elle wolof : le test à faire chez vous

Dans son communiqué du 26 novembre 2024, Orange chiffre à 16 millions le nombre de locuteurs du wolof et à 6 millions celui des locuteurs du pulaar, et annonce l'adaptation de deux modèles ouverts à ces deux langues. À la vérification du 11 août 2026, aucun benchmark public et indépendant ne mesure la performance d'un seul grand modèle de langue en wolof, en bambara ou en dioula.

L'écart entre l'ampleur du besoin et l'absence totale de mesure explique pourquoi une réunion se partage toujours en deux camps sur ce sujet, entre ceux qui ont lu qu'un opérateur travaillait déjà sur le wolof et ceux qui ont essayé un assistant un soir sans être convaincus. Les deux ont raison, et c'est précisément le problème : la question qui décide n'est pas de savoir si un modèle parle wolof, mais s'il le parle assez bien pour une tâche donnée, sur la matière réelle d'une entreprise donnée. Aucun article ne peut répondre à cela à distance.

Cet article établit ce qui existe réellement et qui le porte, ce que personne ne publie, les quatre raisons pour lesquelles un benchmark ne trancherait de toute façon pas un cas particulier, et un protocole de test en six étapes conduit en deux séances d'une heure et demie.

L'essentiel

Des acteurs sérieux travaillent sur le wolof : Orange a annoncé fin 2024 l'adaptation de modèles d'OpenAI et de Meta au wolof et au pulaar, la communauté de recherche Masakhane produit des jeux de données ouverts pour des dizaines de langues africaines, et le CDIAL à Bamako développe des outils pour le bambara, le mooré et le wolof. Aucune de ces initiatives ne publie de taux d'erreur, et aucun benchmark indépendant ne compare les modèles commerciaux sur ces langues. La décision se prend donc sur un test interne, mené sur vingt cas réels avec une référence écrite avant l'essai, et elle ne débouche jamais sur une adoption ou un abandon mais sur un périmètre de déploiement assorti d'une règle de relecture.

Qui travaille réellement sur le wolof, et où en est ce travail ?

Trois acteurs sont identifiables et vérifiables, et aucun des trois ne publie de résultat mesuré.

Orange a publié le 26 novembre 2024 un communiqué annonçant l'intégration de langues régionales africaines dans des modèles d'intelligence artificielle ouverts, en commençant par le wolof et le pulaar. L'opération consiste à affiner le modèle de reconnaissance vocale Whisper d'OpenAI et le modèle de texte Llama 3.1 de Meta, avec pour objectif annoncé de permettre aux clients du groupe de s'adresser aux services d'assistance dans leur langue, puis de publier les modèles adaptés en accès ouvert.

Ce communiqué ne contient aucun résultat, aucun taux d'erreur et aucune mesure de qualité : c'est une annonce d'intention correctement datée, et le reproche s'adresse aux articles qui l'ont transformée en « l'IA parle désormais wolof », pas à l'opérateur. Le démarrage était annoncé pour le premier semestre 2025, et aucune publication rendant compte de l'avancement n'était accessible au 11 août 2026, ni modèle adapté publié en accès ouvert, ni résultat de qualité, ni mise en service. Rien n'est donc vérifiable de l'extérieur, ce qui interdit de citer cette annonce en réunion comme un fait acquis.

Masakhane est une communauté panafricaine de recherche en traitement automatique des langues, dont le nom signifie « nous construisons ensemble » en isiZulu, et qui publie des jeux de données et des travaux ouverts sur plusieurs dizaines de langues africaines depuis masakhane.io. Sa page publique, relevée le 11 août 2026, ne détaille ni la couverture exacte du wolof ni aucune évaluation des modèles commerciaux, ce détail vivant dans les dépôts de code plutôt que dans une page de synthèse. Le CDIAL, à Bamako, développe pour sa part des outils pour le bambara, le mooré et le wolof, applications éducatives, synthèse vocale et interfaces pour des services publics, documenté par un article de presse relevé le 11 août 2026 : faute de document primaire du centre, cette ligne se traite comme une piste et non comme une capacité disponible.

Que personne ne publie sur ces langues ?

Aucun tableau comparatif, aucun taux d'erreur par modèle, aucun protocole partagé.

Un pourcentage de maîtrise annoncé sur ces langues, du type « ce modèle maîtrise le wolof à 90 % », n'a été mesuré par personne, et personne n'a même défini ce que ces 90 % compteraient : une compréhension du sens, une justesse grammaticale, une capacité à répondre dans le registre attendu ne se mesurent pas de la même façon et ne donneraient pas le même nombre. Ce vide est de même nature que celui qui entoure les statistiques régionales d'adoption, dont la généalogie est reprise une par une dans notre article sur les chiffres de l'IA en Afrique.

Pourquoi un benchmark ne trancherait-il pas votre cas ?

Pour quatre raisons qui tiennent à l'écart entre une évaluation de laboratoire et la matière réelle d'un service client.

L'écrit et l'oral ne sont pas la même épreuve. Un modèle peut comprendre du wolof écrit et s'effondrer sur un appel téléphonique bruité, au débit rapide et capté par un micro médiocre, parce que deux technologies distinctes interviennent, la reconnaissance vocale d'un côté et la compréhension du texte de l'autre. Le test doit porter sur le canal réellement visé.

Le wolof s'écrit de plusieurs façons. Alphabet latin selon l'orthographe officielle, alphabet latin selon l'habitude de chacun, et caractères arabes dans la tradition du wolofal. Les clients écrivent comme ils parlent et non comme un manuel, ce qui rend un test conduit sur un texte proprement orthographié étranger à la situation réelle.

Les langues se mélangent dans la même phrase. Une phrase qui commence en wolof, bascule en français pour un terme technique et revient en wolof est la norme, et ces cas doivent figurer en tête d'un test plutôt qu'en marge.

Le vocabulaire métier n'est dans aucun jeu de données. Les noms d'offres, les sigles internes, les termes de la microfinance ou de l'assurance en usage local n'existent dans aucun corpus d'entraînement public, ce qui déplace la difficulté de la grammaire vers la terminologie.

Quel protocole de test conduire, et en combien de temps ?

Six étapes réparties sur deux séances d'une heure et demie, sans aucune compétence technique requise.

La première séance couvre les étapes 1 à 3, où passe l'essentiel du travail, et la seconde les étapes 4 à 6, à raison d'environ quarante-cinq minutes par modèle testé. Le matériel nécessaire tient en un tableur, un collègue qui parle wolof couramment, et si possible un second locuteur pour l'étape 5. Une limite doit être posée d'emblée : ce protocole teste l'écrit et seulement l'écrit, le canal vocal supposant des enregistrements réels et un matériel comparable à celui des agents, donc un autre dispositif.

Étape 1 : choisir une seule tâche, la plus répétitive

Le critère n'est pas le caractère démonstratif mais la fréquence : classer des messages entrants par motif, résumer un échange écrit, traduire une réponse type du français vers le wolof. Une seule tâche, selon le même principe que celui appliqué dans notre article sur les cinq usages qui rapportent à une PME.

Étape 2 : sortir vingt cas réels des archives

Vingt messages authentiques, pris au hasard sur les deux dernières semaines, anonymisés un par un en retirant noms, numéros de compte et numéros de téléphone avant toute sortie hors de l'entreprise. Comptez une bonne demi-heure pour cette étape ingrate. Vingt cas suffisent à faire ressortir un défaut qui touche un cas sur quatre, déjà rédhibitoire en relation client, et restent trop peu nombreux pour mesurer un écart fin entre deux outils proches : c'est le premier objectif qui est visé, pas le second.

Étape 3 : écrire la bonne réponse avant de tester

Le collègue wolophone note, pour chacun des vingt cas, ce qu'une bonne réponse doit contenir. Cette étape ne se saute pas : sans référence écrite à l'avance, la notation se fait au ressenti, et le ressenti est systématiquement favorable au premier essai. Comptez une heure, soit trois minutes par cas, une référence courte listant ce qui doit figurer suffisant largement.

Étape 4 : faire passer les vingt cas sans les aider

Une consigne unique, identique pour tous les cas, sans reformulation quand un cas échoue et sans correction en cours de route. Ce qui se mesure est ce que l'outil produit seul, puisque c'est ce qu'il produira en production.

Étape 5 : noter chaque cas avec la grille ci-dessous

Un second locuteur qui n'a pas vu les réponses de référence rend la notation aveugle, ce qui améliore nettement la qualité du résultat. Avec une seule personne, celle-ci note ce qu'elle a elle-même écrit à l'étape 3, la notation n'est plus aveugle, et la lecture doit alors se limiter aux colonnes factuelles de la grille.

Étape 6 : refaire l'exercice avec un second modèle

Les mêmes vingt cas, la même consigne et la même grille, pour environ quarante-cinq minutes supplémentaires. Un score isolé ne signifie rien ; un écart entre deux outils sur la matière de l'entreprise, si.

Grille de notation, une ligne par cas

Grille AI5D, version du 11 août 2026. Elle ne comporte pas de colonne « canal » : le protocole ci-dessus ne teste que des messages écrits.

Comment lire les résultats obtenus ?

Dans un ordre précis, en commençant par la colonne qui peut arrêter l'exercice à elle seule.

La colonne des erreurs graves se lit en premier. Un contresens ou un montant inventé n'est pas une imperfection que l'on corrige avec une meilleure consigne, c'est un motif de refus : une seule occurrence sur vingt cas écarte l'usage en contact direct avec le client pour l'instant.

Le temps de correction se lit ensuite, à la place de la qualité perçue. Une réponse à retoucher pendant six minutes coûte plus cher que sa rédaction directe, et le seuil se formule sans nuance : dès que le temps de correction dépasse le temps de production actuel, l'outil ralentit l'entreprise, quelle que soit l'impression qu'il donne.

La répartition par langue d'entrée se lit en dernier, et c'est elle qui dessine le périmètre. L'hypothèse que ce test sert à vérifier est qu'un outil tient sur du français, tient à peu près sur du wolof correctement orthographié, et décroche sur le mélange des deux ; aucune mesure publique ne l'établit, et le tableau interne tranchera. Une confirmation de cette hypothèse n'est pas un échec : c'est un périmètre de déploiement qui se dessine seul.

La décision issue de cet exercice n'est donc jamais une adoption ni un abandon, mais un segment précis assorti d'un humain en relecture.

Où l'usage tient-il aujourd'hui, et où faut-il s'abstenir ?

Partout où un humain voit le résultat avant le client, et nulle part ailleurs tant que les vingt cas ne sont pas concluants.

Le risque reste faible sur le classement et le routage des messages entrants, sur la préparation d'un brouillon de réponse qu'un agent valide, et sur le résumé d'un échange déjà traité pour alimenter un dossier. Il devient disproportionné dès qu'il s'agit de répondre directement à un client sans relecture, d'énoncer un montant, un délai ou un droit, ou de traiter un sujet touchant à la santé, au crédit ou à un contentieux : le coût d'une erreur y est sans commune mesure avec le temps gagné. C'est cette frontière, et non la performance du modèle, que nous faisons écrire en premier dans nos missions de conseil.

Que faire cette semaine ?

Trois gestes, dont le premier conditionne les deux autres.

Nommez la personne qui notera et bloquez ses deux créneaux d'une heure et demie, avec l'accord de son responsable. Un test lancé sans créneau réservé n'a jamais lieu : les vingt cas dorment dans un dossier, et la question revient trois mois plus tard identique.

Sortez vos vingt cas et anonymisez-les. C'est la seule étape qui demande de la discipline, et elle resservira pour tous les outils testés ensuite.

Écrivez votre règle de relecture avant le test, pas après : qui valide, sur quels cas, et ce qui ne part jamais sans relecture humaine. C'est la même logique que les trois décisions à prendre avant d'ouvrir un compte, décrites dans notre guide sur l'usage de Claude en entreprise.

Ce qui existe sur le wolof est donc réel, documenté et sans résultat publié, ce qui laisse la mesure à la charge de chaque entreprise. Vingt cas notés sur la matière interne ne constituent pas un benchmark et ne se publient pas comme tel : ils tranchent une décision, sur un périmètre, avec une règle de relecture, et c'est tout ce qui est demandé.

À lire également

• Les chiffres sur l'IA en Afrique sont faux : les cinq statistiques régionales les plus reprises et la méthode de vérification en trois questions.
• Les 5 usages de l'IA qui rapportent le plus à une PME africaine : les familles d'usage rentables, dont l'adaptation de supports en langue locale.
• Utiliser Claude depuis Dakar ou Abidjan : les six questions qu'un dirigeant se pose avant de souscrire, dont celle des langues locales.
• Les guides français sur l'IA ne marchent pas chez nous : les cinq hypothèses implicites du corpus francophone et l'ordre de décisions qui les remplace.

FAQ

L'intelligence artificielle parle-t-elle wolof ?

Aucune mesure publique ne permet de répondre par un chiffre. Des modèles produisent du wolof, et personne n'a évalué publiquement leur taux d'erreur sur cette langue. La seule réponse exploitable vient d'un test conduit sur vos propres messages, avec une référence écrite avant l'essai.

Le projet d'Orange sur le wolof est-il disponible ?

Le communiqué du 26 novembre 2024 annonce l'adaptation de Whisper et de Llama 3.1 au wolof et au pulaar, pour un démarrage au premier semestre 2025. Aucune publication rendant compte de l'avancement n'était accessible au 11 août 2026, ni modèle publié, ni résultat, ni mise en service.

Combien de cas faut-il pour tester un modèle en wolof ?

Vingt cas réels suffisent à faire ressortir un défaut qui touche un cas sur quatre, ce qui est déjà rédhibitoire en relation client. Ce nombre est trop faible pour départager deux outils proches, mais c'est le premier objectif qui compte pour une décision de déploiement.

Peut-on confier un service client en wolof à une IA ?

Pas sans relecture humaine, et pas avant d'avoir passé vingt cas réels sans erreur grave. Le classement des messages entrants, la préparation de brouillons validés par un agent et le résumé d'échanges déjà traités présentent un risque faible ; une réponse directe au client, un montant ou un délai annoncés, non.

Faut-il tester l'écrit ou l'oral ?

Celui de vos deux canaux qui porte réellement le travail, car il s'agit de deux technologies distinctes. Le protocole décrit ici teste l'écrit ; le canal vocal exige des enregistrements réels, capturés avec un matériel comparable à celui de vos agents.