Deux modèles obtiennent des scores proches dans un classement, mais l’un échoue sur les documents de l’organisation et l’autre dépasse son budget de calcul. Le classement mesure les résultats sur son propre jeu de tests. Une évaluation avec les documents, les prompts et les outils de l’application permet de mesurer les résultats dans la configuration prévue.
Le choix d’un modèle à poids ouverts examine la disponibilité des fichiers et des droits d’utilisation, les résultats des tests applicatifs, les ressources nécessaires à l’inférence et le coût d’exploitation. Des exemples comme Kimi, Soofi, Apertus et Mistral permettent de distinguer ces questions.
Vérifier la disponibilité et la portée de l’ouverture
Les poids sont les valeurs apprises pendant l’entraînement. Leur publication peut permettre de télécharger et d’exécuter le modèle, sous les conditions de sa licence. Elle ne signifie pas automatiquement que les données d’entraînement, le code et toutes les étapes de préparation sont eux aussi publics.
L’organisation examine donc une version précise. Un modèle de base, une version adaptée au dialogue et une variante quantifiée peuvent avoir des comportements et des conditions différents. La vérification porte sur les fichiers effectivement téléchargeables et leur licence, en distinguant la version publiée d’une annonce ou d’une préversion réservée à certains partenaires.
La documentation doit identifier les fichiers, leur version, la licence et les logiciels compatibles. Ces éléments permettent de préparer l’installation et de conserver une référence reproductible. Un nom de famille de modèles ne suffit pas à décrire ce que l’application utilisera.
Comparer les candidats sur des critères distincts
Les exemples suivants illustrent des choix de conception et de publication. Ils ne forment pas un classement permanent. Les fiches des éditeurs restent la référence pour la version retenue.
| Exemple | Élément à examiner | Conséquence pour le projet |
|---|---|---|
| Kimi K3 | Architecture très volumineuse et conditions de licence | Vérifier les ressources ou le service hébergé nécessaire |
| Soofi S Base | Modèle de base et statut d’accès de la version | Distinguer expérimentation, adaptation et assistant prêt à l’emploi |
| Apertus | Poids, code et documentation de l’entraînement publiés | Examiner la traçabilité et la qualité sur les langues utiles |
| Devstral Small 2 | Modèle orienté vers les tâches de code | Tester les outils, le contexte du dépôt et l’environnement d’exécution |
Le dépôt de Kimi K3 décrit 2 800 milliards de paramètres au total. Le nombre de paramètres activés pour une étape de calcul ne représente pas la totalité des poids à héberger. Une architecture de mélange d’experts demande donc de distinguer la charge de calcul et la mémoire de stockage du modèle.
La fiche de Soofi S Base décrit une version de base. Elle ne permet pas de présumer qu’une interface de conversation prête à l’emploi répondra aux mêmes évaluations. L’adaptation au dialogue et à un domaine mérite ses propres essais.
La documentation d’Apertus donne des éléments pour examiner l’ouverture et la provenance du modèle. Cette transparence est un critère distinct de la précision sur une extraction ou de la qualité d’une réponse en français.
Pour Devstral Small 2, une évaluation pertinente utilise les langages, les bibliothèques et les tâches de code du projet. Les résultats d’un autre dépôt peuvent orienter la sélection sans démontrer le comportement sur celui de l’organisation.
Évaluer la qualité sur les tâches prévues
Le jeu d’essai doit contenir des cas courants et des cas qui mettent le système en difficulté. Pour une extraction, l’équipe vérifie le traitement des pièces ambiguës ainsi que les valeurs absentes ou mal formatées. Pour une recherche documentaire, elle examine la pertinence des passages, les citations et les réponses que le système devrait refuser faute d’information.
Les critères distinguent plusieurs types d’erreurs. Une réponse incomplète n’a pas les mêmes conséquences qu’une référence inventée ou qu’une action mal autorisée. L’évaluation peut donc attribuer des seuils différents selon la tâche et prévoir une transmission à une personne lorsque le système manque d’éléments.
La comparaison conserve les prompts, les outils, les documents de contexte, les paramètres d’inférence et la version du modèle utilisés pour chaque essai. Une modification de ces composants peut changer le résultat. Les essais utilisent la configuration prévue pour l’application.
La langue mérite un essai spécifique. Un modèle performant sur des questions générales en anglais peut mal interpréter une abréviation métier ou une formulation juridique française. Les utilisateurs doivent pouvoir examiner des sorties représentatives, avec leurs sources et les cas d’erreur.
Mesurer les ressources et le coût du résultat accepté
La quantification réduit la précision numérique des poids pour diminuer leur empreinte mémoire. Elle peut modifier la qualité et les logiciels compatibles. L’équipe évalue donc la variante qu’elle compte réellement déployer, avec les ressources réservées au contexte et aux demandes simultanées.
Le test mesure le délai avant la réponse, le débit et le comportement sous charge. Un modèle plus rapide dans une requête isolée peut perdre cet avantage lorsque plusieurs utilisateurs attendent. Le système doit prévoir des limites et une gestion des files d’attente, avec une procédure pour les échecs.
Le coût complet inclut les ressources de calcul, l’énergie, l’administration, les mises à jour et la continuité. Pour une API, il comprend les entrées, les sorties, les reprises et les éventuelles fonctions annexes. Une comparaison par jeton n’exprime pas toujours le coût d’un dossier correctement traité.
L’exécution locale peut répondre à un besoin de contrôle ou à une charge soutenue. Une API peut être préférable pour un volume variable ou un modèle difficile à héberger. Le résultat dépend des hypothèses de qualité, de disponibilité et d’exploitation, pas d’un seuil universel de rentabilité.
Conserver une décision reproductible
L’organisation garde la version du modèle, sa licence, la configuration et le jeu d’essai qui ont fondé son choix. Pour un service hébergé, elle identifie également l’opérateur, les conditions de traitement et les possibilités de changement de version. La disponibilité des poids ne règle pas les accès aux données envoyées à un fournisseur.
Une mise à jour passe par le même ensemble de contrôles. L’équipe compare les résultats, examine les régressions et conserve une possibilité de retour lorsque l’architecture le permet. Cette procédure donne une valeur durable à l’évaluation initiale.
Le modèle retenu répond ainsi à un usage défini dans un environnement que l’organisation sait maintenir. Les classements servent à découvrir des candidats ; les essais et les conditions d’exploitation permettent de décider.
Pour comparer les environnements, consulter les articles sur les critères pour déployer une IA interne et dimensionner trois profils de machines.
Les exemples de modèles ont été réexaminés lors de la révision du 7 octobre 2026. Leurs licences, leur disponibilité et leurs caractéristiques doivent être vérifiées sur la version choisie avant tout déploiement.