Choisir un modèle de langage pour travailler en espagnol ne se résout pas avec un tableau de scores. La plupart des comparatifs publics se concentrent sur des benchmarks en anglais, et lorsque vous transposez ces chiffres à un cas réel en castillan, vous découvrez que le modèle qui gagnait sur MMLU perd le fil dans une conversation avec des idiotismes argentins ou mélange la terminologie catalane avec la castillane. Ce guide ne vous donne pas un classement fermé : il vous donne une procédure de configuration reproductible pour que vous mesuriez vous-même quel modèle performe le mieux dans votre cas précis, avec des tests concrets et des seuils de décision.
Étape 0 : définissez ce que signifie « performance en espagnol » pour votre projet
Avant de toucher une API ou de télécharger des poids, écrivez sur une feuille quelles tâches vous allez déléguer au modèle. Un classificateur de tickets de support n’est pas la même chose qu’un générateur de résumés juridiques. Les axes qui discriminent réellement entre les modèles en espagnol sont au nombre de quatre :
- Compréhension écrite : extraire des réponses d’un texte long sans inventer de données.
- Fluidité et registre : que le texte ne sonne pas comme une traduction automatique de l’anglais.
- Robustesse dialectale : comportement face aux variantes rioplatense, mexicaine, péninsulaire ou andine.
- Fidélité instructionnelle : respecter les formats (JSON, listes, longueurs) en castillan.
Un modèle peut être excellent sur le premier et désastreux sur le troisième. Selon la documentation officielle de plusieurs fournisseurs, leurs évaluations multilingues agrègent les résultats par langue, ce qui masque les différences régionales. C’est pourquoi l’étape 0 est indispensable.
Étape 1 : montez le banc d’essai avec vos propres textes réels
Rassemblez entre 20 et 40 exemples personnels. Des courriels de clients, des extraits de votre base de connaissances, des pages produit ou des transcriptions d’appels feront l’affaire. Étiquetez manuellement la réponse attendue dans une colonne séparée. Ce détail fait la différence : les benchmarks publics utilisent des modèles que les modèles ont vus à l’entraînement ; vos textes, non.
Ce qu’il faut inclure obligatoirement
- Au moins cinq exemples avec code-switching (castillan avec des termes en anglais, courant en technologie).
- Deux ou trois avec des chiffres et des unités (dates, montants, pourcentages) pour détecter les erreurs de format.
- Un exemple avec une instruction négative : « ne mentionne pas les prix » ou « réponds uniquement avec le tableau ».
- Des textes avec des accents, des ñ et des signes d’ouverture (¿ ¡). C’est un test peu coûteux qui élimine les modèles dotés de tokeniseurs médiocres pour l’espagnol.
Étape 2 : configurez l’environnement de comparaison
Ne comparez pas les modèles depuis des interfaces de chat différentes : elles modifient le system prompt par défaut, la température et le troncature. Utilisez un script unique qui appelle chaque endpoint avec des paramètres identiques. Un squelette en Python avec la bibliothèque standard de chaque fournisseur suffit.
params = {
«temperature»: 0.2,
«max_tokens»: 800,
«top_p»: 1.0
}
Fixez une température basse (0,1–0,3) pour les tâches d’extraction. Si votre cas est créatif, répétez la batterie avec une température de 0,8 et comparez la stabilité entre les exécutions. Un modèle qui varie beaucoup avec la même graine est difficile à intégrer en production.
L’erreur que presque tout le monde commet ici
Comparer uniquement la première réponse. Les grands modèles réussissent souvent au premier tour et se dégradent lorsque le contexte s’allonge. Ajoutez un test de deux et trois tours avec un contexte cumulé de 3 000 à 6 000 tokens en espagnol. D’après mon expérience avec les assistants de service client, la chute la plus brutale apparaît précisément là : le modèle commence à répondre en anglais ou perd l’instruction de format lorsque l’historique s’allonge. Cette limitation n’apparaît dans aucun tableau comparatif public.
Étape 3 : définissez des métriques que vous pouvez calculer sans une équipe d’annotateurs
Vous n’avez pas besoin d’un laboratoire. Avec trois métriques simples, vous obtenez un signal suffisant :
- Exactitude exacte ou par chevauchement : pour l’extraction, comparez avec la réponse étiquetée en utilisant la correspondance de mots-clés ou la similarité de chaînes.
- Taux de violation de format : pourcentage de réponses qui ne respectent pas le schéma demandé (JSON invalide, listes à puces alors que l’on demandait de la prose).
- Pénalité pour anglicismes : comptage des termes en anglais non justifiés par le domaine. Un seuil raisonnable est de plus de deux pour chaque 200 mots dans des textes de vulgarisation.
Si vous devez évaluer la fluidité, demandez à deux collègues de classer à l’aveugle des paires de réponses. Avec 30 paires, vous obtenez une préférence assez stable. Il n’en faut pas plus pour décider.
Étape 4 : exécutez la batterie et lisez les résultats avec scepticisme
Lancez chaque modèle trois fois par exemple et enregistrez la variance. Un modèle avec 85 % de réussite et une forte déviation est pire pour la production qu’un modèle avec 80 % stable. Documentez également la latence et le coût pour 1 000 tokens : en espagnol, la longueur moyenne des réponses est généralement de 10 à 20 % supérieure à celle de l’anglais pour le même contenu, ce qui renchérit l’usage réel même si le prix par token semble bas.
À quoi s’attendre selon le type de modèle
Les modèles ouverts de taille moyenne se défendent généralement bien en classification et en extraction avec des instructions claires, mais faiblissent sur les nuances dialectales et sur le maintien d’un registre formel dans des textes longs. Les grands modèles propriétaires tendent à produire un castillan plus naturel, bien qu’ils « surcorrigent » parfois et génèrent un espagnol neutre artificiel qui sonne étrange à un lecteur local. Aucun ne gagne sur tous les tableaux. Si votre produit est destiné à l’Espagne, testez explicitement avec des exemples utilisant « vosotros » et le lexique péninsulaire ; s’il est destiné à l’Amérique latine, évitez que le modèle impose « ordenador » là où votre utilisateur dit « computadora ».
Étape 5 : ajustez le prompt avant de changer de modèle
De nombreuses différences entre modèles disparaissent avec un system prompt bien rédigé en espagnol. Incluez explicitement la langue de sortie, le registre souhaité et un exemple de réponse. Les modèles interprètent mieux les instructions lorsque le prompt lui-même est dans la langue cible, même s’ils comprennent parfaitement l’anglais.
Essayez cette séquence : optimisez d’abord le prompt avec le modèle A ; appliquez ensuite le même prompt au modèle B. Si B s’améliore beaucoup, le problème venait du prompt et non du modèle. Si B continue d’échouer sur les mêmes exemples, vous avez là une limitation réelle qui justifie le changement.
Étape 6 : décidez avec une matrice, pas avec une intuition
Notez chaque candidat de 1 à 5 sur quatre critères pondérés selon votre cas : réussite sur votre batterie, stabilité entre les exécutions, coût total et latence. Multipliez par le poids et additionnez. Un modèle qui obtient 4 en réussite mais 2 en stabilité est rarement le bon choix pour un flux automatisé.
Ajoutez une colonne « risque » : si le fournisseur ne documente pas le traitement des données en espagnol ou n’offre pas de rétention zéro, ce facteur peut peser plus que deux points de précision. La transparence du fournisseur sur ses données d’entraînement est un signal de qualité, pas un ornement.
Limites que cette méthodologie ne résout pas
Elle n’évalue pas systématiquement les biais culturels, ni ne couvre les langues coofficielles (catalan, galicien, basque) sauf si vous ajoutez vos propres exemples. Elle ne prédit pas non plus le comportement après une mise à jour du fournisseur : les modèles changent sans préavis et votre batterie doit être répétée régulièrement. Et elle ne remplace pas une révision humaine dans les domaines réglementés. Si votre cas est sanitaire ou juridique, la validation par des experts est obligatoire indépendamment du score.
Enfin, gardez à l’esprit que la performance en espagnol n’est pas une propriété fixe du modèle : elle dépend du tokeniseur, de la longueur du contexte et du domaine. Un modèle qui brille en conversation générale peut échouer sur la terminologie technique de votre secteur. Le seul comparatif qui compte est celui que vous exécutez avec vos données, vos paramètres et vos critères d’acceptation. Le reste, ce sont des indices, pas des verdicts.