Choisir un modèle de langage pour son entreprise : les critères qui comptent

Partir de l'usage avant de regarder les classements

Chaque mois apporte un nouveau modèle, un nouveau classement et une nouvelle promesse. Pour une entreprise qui démarre un projet, la tentation est de choisir le modèle en tête du dernier comparatif et de construire autour. C'est le raccourci le plus coûteux : le classement mesure des tâches génériques, et votre projet n'en est pas une.

Le bon point de départ est une description précise de ce que le modèle devra faire. Lire des bons de commande et en extraire des lignes. Répondre à des questions de collaborateurs depuis une base documentaire. Rédiger une première version de compte rendu à partir de notes. Classer des demandes entrantes et les router vers le bon service. Chacune de ces tâches sollicite des qualités différentes, et un modèle excellent sur l'une peut être surdimensionné, ou insuffisant, sur l'autre.

La documentation d'Anthropic sur le choix d'un modèle résume l'arbitrage en trois termes : les capacités dont vous avez besoin, la vitesse de réponse attendue et le budget, en développement comme en production. Nous y ajoutons quatre critères qui pèsent autant dans un projet d'entreprise : la taille du contexte, le mode d'accès au modèle, la localisation des données avec le contrat qui l'encadre, et la continuité dans le temps.

Cet article traite du choix initial. Si vous avez déjà un agent en production et vous demandez s'il faut passer à un modèle plus récent, notre article sur ce que change Claude Opus 5.5 détaille la méthode de bascule.

La qualité se mesure sur vos cas, pas sur ceux des autres

Un modèle est bon ou mauvais sur une tâche donnée : la vôtre, avec vos documents, votre vocabulaire métier, vos abréviations maison et vos cas tordus. La seule façon de le savoir est de l'essayer sur un échantillon de ces cas.

Anthropic le dit sans détour dans sa propre documentation : avoir un bon jeu d'évaluation est l'étape la plus importante du processus de choix. Ce jeu contient des cas réels, avec la réponse attendue validée par quelqu'un du métier, y compris des cas difficiles et des demandes hors périmètre. On y passe les modèles candidats, avec les mêmes consignes, et on compare.

Quelques précautions rendent la comparaison honnête :

• Adapter les consignes à chaque modèle. Une consigne écrite et affinée pour un modèle avantage ce modèle. Donnez à chaque candidat une vraie chance, avec un minimum de réglage.
• Comparer à coût égal ou à qualité égale. Un modèle plus capable qui coûte beaucoup plus cher n'est un bon choix que si l'écart de qualité compte pour l'usage.
• Regarder les erreurs, pas seulement le score. Deux modèles au même score peuvent se tromper sur des cas très différents. Une erreur sur un cas sensible pèse plus lourd qu'une erreur sur un cas bénin.

Ce travail sert longtemps : le même jeu servira ensuite à chaque changement de consigne, de modèle ou de données. C'est le socle de tout le reste.

Le coût : lire au-delà du prix affiché

Les éditeurs affichent un prix par million de jetons, en entrée et en sortie. Ce chiffre sert à comparer des modèles entre eux. Il ne dit presque rien de votre facture. Celle-ci dépend de la longueur des consignes envoyées à chaque appel, de la quantité de documents rappelés, du nombre d'échanges par utilisateur, de la part de contexte mise en cache, et des appels invisibles que fait le système, pour vérifier une réponse ou découper une tâche.

Deux conséquences pour le choix :

• Un modèle moins cher à l'unité peut coûter plus cher au final s'il a besoin de plus d'étapes, de plus de relances ou de consignes plus longues pour atteindre la même qualité.
• Le coût se mesure pendant le prototype, sur un échantillon réaliste, jamais sur une estimation de tableur. Notre article sur le coût d'un agent IA en production liste les postes à suivre.

La documentation d'Anthropic propose deux points de départ. Le premier privilégie l'efficacité : commencer avec un modèle rapide et économique, tester, et ne monter en gamme que si un écart de capacité l'impose. Le second privilégie la capacité : partir du modèle le plus fort pour la tâche, puis chercher à réduire le coût une fois que le système fonctionne. Le premier convient aux tâches simples à fort volume. Le second aux tâches complexes où l'exactitude prime. Dans les deux cas, c'est le jeu d'évaluation qui décide de la suite.

Une troisième voie existe : combiner les modèles. La même documentation décrit deux schémas, un modèle économique qui fait l'essentiel du travail et remonte les décisions difficiles à un modèle plus fort, ou un modèle fort qui orchestre et délègue les tâches de volume à des modèles moins chers. C'est souvent là que se trouvent les meilleurs équilibres. Le pilotage de ces arbitrages dans la durée fait l'objet de notre cadre CADRE sur les coûts de l'IA.

La latence : qui attend la réponse ?

La vitesse d'un modèle compte différemment selon la personne qui attend. Un visiteur devant un chat abandonne si la réponse tarde. Un commercial qui prépare un rendez-vous tolère quelques secondes si le résultat est bon. Un traitement de nuit sur un lot de documents n'attend personne.

Posez la question pour chaque parcours du projet, pas pour le projet entier. Un même système peut utiliser un modèle rapide pour ce qui s'affiche à l'écran et un modèle plus lent, plus capable, pour ce qui tourne en arrière-plan. La latence dépend aussi de la construction : longueur des consignes, quantité de contexte, nombre d'étapes enchaînées. Un modèle rapide noyé sous un contexte trop long peut répondre plus lentement qu'un modèle plus lourd bien alimenté.

Certains éditeurs proposent aussi un réglage d'effort, qui arbitre entre qualité de raisonnement, vitesse et coût au sein d'un même modèle. Anthropic indique que régler ce paramètre est souvent un meilleur levier que changer de modèle. C'est une raison de plus pour tester avant de trancher.

La taille du contexte : une capacité à utiliser avec discernement

Le contexte est la quantité de texte que le modèle peut prendre en compte en une fois : consignes, historique de la conversation, documents fournis. Les modèles récents en acceptent beaucoup. La documentation d'Anthropic indique par exemple une fenêtre d'un million de jetons pour plusieurs de ses modèles actuels, et de deux cent mille pour le plus léger.

Une grande fenêtre ouvre des usages : analyser un dossier complet, comparer plusieurs contrats longs, garder l'historique entier d'une affaire. Elle ne dispense pas de réfléchir à ce que l'on envoie. Chaque jeton envoyé se paie, et un contexte encombré de documents peu pertinents peut dégrader la réponse autant qu'un contexte trop pauvre. Pour un agent qui répond depuis une base documentaire, la recherche des bons passages reste en général plus efficace que l'envoi de tout le corpus.

Le critère à retenir : la fenêtre du modèle doit couvrir le plus gros cas réaliste de votre usage, avec une marge. Au-delà, une fenêtre plus grande n'apporte rien de mesurable à votre projet.

Modèle par API ou modèle à poids ouverts hébergé chez vous

C'est souvent le choix le plus structurant, et il se pose tôt.

Le modèle accessible par API

Vous appelez le modèle d'un éditeur, directement ou via une plateforme cloud. Vous n'avez rien à installer ni à maintenir. Vous bénéficiez des modèles les plus capables du marché et de leurs mises à jour. En contrepartie, vos données transitent par l'infrastructure du fournisseur, selon les conditions de son contrat, et vous dépendez de son calendrier : un modèle peut être retiré, un tarif peut changer.

Le modèle à poids ouverts

Certains éditeurs publient les poids de leurs modèles sous licence ouverte. Mistral AI, par exemple, distribue plusieurs de ses modèles sous licence Apache 2.0. Vous pouvez alors les faire tourner sur votre propre infrastructure ou chez un hébergeur de votre choix. Les données ne quittent pas l'environnement que vous contrôlez, et le modèle ne disparaît pas du jour au lendemain.

Le prix de cette maîtrise est réel. Il faut des serveurs équipés de processeurs graphiques, dimensionnés pour la charge de pointe, une équipe pour les exploiter, les sécuriser et les mettre à jour, et accepter que les modèles ouverts les plus accessibles à héberger ne soient pas toujours au niveau des meilleurs modèles fermés sur les tâches complexes. Vérifiez aussi la licence de chaque modèle : elles ne se valent pas toutes, et certaines restreignent l'usage commercial.

Comment trancher

La question utile est : quelle contrainte rend l'hébergement interne nécessaire ? Une exigence contractuelle ou réglementaire sur la localisation des données, un volume très élevé et régulier qui rentabilise une infrastructure dédiée, un besoin de fonctionnement hors connexion. Sans une de ces contraintes, un modèle par API hébergé en Europe est généralement plus simple et plus capable. Avec l'une d'elles, le modèle ouvert devient un choix sérieux, à évaluer sur le même jeu de cas que les autres.

Les deux options ne s'excluent pas : un même projet peut traiter les données les plus sensibles avec un modèle hébergé en interne, et le reste avec un modèle par API. Concevoir cette architecture est le travail d'un ingénieur IA, en lien avec vos équipes infrastructure.

Localisation des données et contrat

Où sont traitées les données envoyées au modèle ? Combien de temps sont-elles conservées ? Servent-elles à entraîner les modèles du fournisseur ? Qui peut y accéder, et sous quelle juridiction ? Ces questions trouvent leur réponse dans le contrat et la documentation du fournisseur, pas dans la fiche technique du modèle.

Le même modèle peut d'ailleurs être disponible par plusieurs chemins, avec des garanties différentes. Anthropic indique par exemple que ses modèles sont accessibles directement et via plusieurs grandes plateformes cloud, dont certaines proposent des points d'accès régionaux qui garantissent la zone de traitement des données. Pour une entreprise française, le choix du chemin d'accès compte donc autant que le choix du modèle. Notre article sur l'hébergement d'un projet IA en France compare les options.

Points à vérifier avant de signer :

• la région de traitement et de stockage, et la possibilité de l'imposer ;
• la durée de conservation des requêtes et des réponses ;
• l'usage éventuel de vos données pour l'entraînement ;
• les sous-traitants du fournisseur ;
• les engagements de disponibilité et le support en cas d'incident ;
• les obligations d'information et de transparence qui vous incombent selon l'usage, détaillées dans notre article sur l'AI Act pour les PME.

La continuité : un modèle a une date de fin

Un modèle accessible par API a une durée de vie limitée. Les éditeurs retirent régulièrement leurs anciens modèles pour faire place aux nouveaux. Anthropic publie ainsi le cycle de vie de chacun, du statut actif au retrait, avec une date de retrait minimale pour les modèles actuels, et s'engage à prévenir les clients concernés au moins soixante jours avant le retrait d'un modèle publié. Passé cette date, les appels au modèle retiré échouent. L'éditeur précise aussi que les plateformes cloud partenaires fixent leurs propres calendriers.

Pour un projet d'entreprise, cela a trois conséquences :

• Le modèle est un paramètre. Le système doit pouvoir changer de modèle par configuration, sans réécriture. C'est une décision d'architecture à prendre dès le départ.
• Le jeu d'évaluation est permanent. Il servira à valider le remplaçant le jour où le modèle actuel sera retiré. Anthropic recommande de tester le nouveau modèle bien avant la date de retrait.
• La dépendance se mesure. Si votre système repose sur une capacité propre à un seul fournisseur, notez-le et identifiez une solution de repli, même moins bonne.

Les modèles à poids ouverts échappent à ce calendrier imposé, puisque vous gardez les poids. Ils y substituent un autre travail : suivre vous-même les versions, les correctifs et la sécurité de ce que vous hébergez.

Une grille de décision en pratique

Pour un premier projet, voici l'ordre dans lequel nous posons les questions avec nos clients :

• Contraintes éliminatoires. Y a-t-il une exigence sur la localisation des données, un secteur réglementé, un besoin hors connexion ? Elles réduisent la liste avant tout test.
• Tâche et volume. Quelle tâche, combien de fois, avec quelle exigence d'exactitude ? Cela oriente vers un départ par l'efficacité ou par la capacité.
• Temps d'attente acceptable. Pour chaque parcours, qui attend et combien de temps peut-il attendre ?
• Taille du plus gros cas. Le contexte nécessaire tient-il dans la fenêtre des candidats, avec marge ?
• Évaluation sur vos cas. Deux ou trois candidats, les mêmes cas, les mêmes critères, le coût réel mesuré.
• Contrat et continuité. Conditions de traitement des données, calendrier de retrait, solution de repli.

Cette grille se déroule pendant le prototype, et ses réponses font partie des prérequis de mise en production. Nous avons détaillé ces prérequis dans notre article sur le passage d'un POC métier à la production.

Les erreurs fréquentes

• Choisir sur la réputation. Le modèle dont tout le monde parle n'est pas forcément le meilleur pour votre tâche, ni le plus rentable.
• Figer le choix dans le code. Un nom de modèle écrit en dur un peu partout dans le code transforme chaque changement en chantier.
• Sous-estimer l'hébergement interne. Faire tourner un modèle ouvert est simple en démonstration. L'exploiter de façon fiable, sécurisée et dimensionnée pour la charge est un métier.
• Oublier le contrat. La question des données se règle avant la mise en production, pas après la première question d'un client ou d'un auditeur.
• Tester sans le métier. Un informaticien juge la forme d'une réponse. Seul le métier juge si elle est juste.

Si vous démarrez un projet et voulez cadrer ce choix sur vos propres cas, notre diagnostic IA permet de poser les contraintes, le périmètre et le protocole d'évaluation avant d'engager un développement.

Sources

• Documentation Claude, Choosing the right model
• Documentation Claude, Models overview
• Documentation Claude, Model deprecations
• Documentation Claude, Define success criteria and build evaluations
• Mistral AI, Models overview

Questions fréquentes

Faut-il choisir un seul fournisseur de modèles ?

Pas nécessairement. Un système bien conçu traite le modèle comme un paramètre et peut en utiliser plusieurs selon les tâches. Garder deux fournisseurs évalués sur vos cas réduit aussi la dépendance, au prix d'un peu plus de tests.

Un modèle français ou européen est-il obligatoire pour être conforme ?

La question porte d'abord sur les conditions de traitement des données : région, conservation, sous-traitants, usage pour l'entraînement. Un modèle étranger accessible depuis une région européenne avec un contrat adapté peut convenir, un modèle européen mal encadré peut poser problème.

Combien de modèles faut-il tester au départ ?

Deux ou trois candidats suffisent en général, choisis après avoir écarté ceux qui ne respectent pas vos contraintes. Tester davantage coûte du temps sans beaucoup d'information en plus, surtout si le jeu d'évaluation est bien construit.

Peut-on changer de modèle en cours de projet ?

Oui, et il faut le prévoir. Si le modèle est un paramètre de configuration et que le jeu d'évaluation existe, un changement se teste et se déploie comme n'importe quelle évolution. Sans ces deux conditions, il devient une opération risquée.

Un modèle à poids ouverts est-il gratuit ?

La licence peut l'être, l'exploitation ne l'est jamais. Il faut des serveurs adaptés, leur supervision, leur sécurité et leurs mises à jour. Le calcul se fait sur le coût total, à comparer avec celui d'un modèle par API pour le même volume.