Choisir un modèle d'IA : la grille de décision par cas d'usage

« Quel modèle IA choisir ? » est la question la plus posée dans les comités de projet, et l'une des plus mal formulées. Elle suppose qu'il existe un meilleur modèle, stable dans le temps, valable pour tous les usages de l'entreprise. Aucune de ces trois hypothèses ne tient.

Un modèle qui excelle sur du raisonnement long coûte dix à trente fois plus cher qu'un petit modèle sur une tâche de classification, où il ne fera pas mieux. Un modèle rapide gagne un usage conversationnel et perd un usage d'extraction fine. Et le classement des meilleurs modèles se réécrit plusieurs fois par an, ce qui rend toute décision définitive dangereuse.

Cet article propose une grille à cinq entrées, applicable en réunion, et la déroule sur six cas d'usage courants. Sa thèse : on ne choisit pas un modèle, on définit une politique de modèles, documentée, mesurée et révisable à date fixe.

Quel modèle IA choisir : les cinq entrées de la grille

1. La latence acceptable

Combien de temps l'utilisateur peut-il attendre ? Un assistant conversationnel exige les premiers mots en moins de deux secondes. Un traitement nocturne par lots peut attendre huit heures. Entre les deux, tout est possible. Cette entrée est la plus discriminante et la plus facile à trancher, alors qu'elle est souvent laissée en dernier.

2. Le coût par unité utile

Ne raisonnez jamais en prix au million de jetons : raisonnez en coût par document traité, par ticket classé, par compte rendu produit. Le calcul intègre la longueur réelle du contexte, les tentatives ratées et les appels d'outils. Un modèle deux fois plus cher au jeton mais qui réussit du premier coup peut revenir moins cher. Notre article sur le coût d'un projet d'IA générative en entreprise détaille ce calcul.

3. La qualité sur votre tâche

C'est l'entrée la plus mal traitée. Les classements publics, qu'il s'agisse de comparateurs de performance et de coût ou d'arènes de préférence, indiquent une tendance générale ; ils ne disent rien de votre extraction de champs sur vos contrats. Constituez un jeu de 50 à 100 exemples avec la réponse attendue, et mesurez. La méthode de lecture des classements publics est détaillée dans notre article sur la manière de lire un benchmark de modèle IA.

4. La confidentialité exigée

Quelles données entrent dans le prompt ? Données personnelles, secrets industriels, informations couvertes par un contrat client ? Cette entrée décide souvent à elle seule entre API publique, offre hébergée dans l'Union européenne et modèle ouvert exécuté chez soi. Le débat est posé dans notre comparaison entre modèles ouverts et API propriétaires.

5. La réversibilité

Combien de temps faudrait-il pour changer de modèle ? La réponse dépend de vos choix d'architecture, pas du fournisseur. Une couche d'abstraction, des prompts versionnés et un jeu de tests automatisé ramènent le changement à quelques jours. À l'inverse, des prompts optimisés pour un modèle unique, des appels dispersés dans le code et aucun test de non-régression rendent tout changement risqué. Le règlement européen sur l'IA, qui impose une documentation des systèmes selon leur niveau de risque, va d'ailleurs dans le même sens : savoir ce que l'on utilise et pouvoir le justifier.

La grille appliquée à six cas d'usage

Le tableau suivant donne, pour chaque cas, l'entrée dominante et le profil de modèle qui en découle. « Petit modèle » désigne un modèle rapide et économique, « modèle de tête » un modèle généraliste haut de gamme.

Une lecture s'impose : dans quatre cas sur six, le modèle le plus performant n'est pas le bon choix. La performance brute ne décide que pour l'agent outillé et la rédaction publiée.

Ce qu'il faut mesurer soi-même, et comment

Trois mesures suffisent à trancher entre deux ou trois candidats, en une journée de travail.

1. Le taux de réussite sur votre jeu de tests. Cinquante à cent exemples réels, avec la réponse attendue et un critère de succès explicite. C'est l'investissement le plus rentable de tout le projet, et il reste utilisable à chaque changement de modèle.
2. Le coût par unité utile, mesuré et non estimé. Relevez la consommation réelle sur cent exécutions, tentatives ratées comprises, puis extrapolez à votre volume mensuel.
3. Le temps de réponse au 95e centile. La moyenne ment. Ce sont les 5 % de réponses lentes qui provoquent l'abandon des utilisateurs.

Ajoutez une mesure qualitative, sans tableur : faites tester les deux finalistes par trois utilisateurs métier sur une demi-journée, sans leur dire lequel est lequel. Le résultat contredit parfois les chiffres, et il faut alors comprendre pourquoi avant de trancher.

Trois erreurs de raisonnement fréquentes

1. Choisir sur une démonstration. Une démonstration teste la fluidité de la réponse, jamais la régularité. Un modèle qui réussit neuf fois sur dix impressionne en réunion et devient ingérable sur dix mille exécutions mensuelles, où le dixième cas représente mille incidents.
2. Confondre modèle et système. La plupart des mauvaises réponses viennent du contexte fourni, du découpage des documents ou de la formulation de la consigne, pas du modèle. Changer de modèle pour corriger un problème de contexte revient à changer de voiture parce que la route est mauvaise. La méthode de formulation est détaillée dans notre article sur la manière d'écrire un bon prompt.
3. Négliger la variabilité dans le temps. Un même modèle peut voir son comportement évoluer au fil des versions du service. Sans jeu de tests rejoué régulièrement, cette dérive se découvre par une plainte utilisateur, plusieurs semaines après.

Une politique de modèles, pas un choix de modèle

La conclusion pratique de cette grille est qu'une entreprise n'a pas besoin d'un modèle, mais d'une politique tenant sur une page. Elle liste, pour chaque famille d'usage, le modèle par défaut, le modèle de repli, les données autorisées et la date de la prochaine revue.

• Par défaut : un modèle généraliste pour la rédaction et les usages conversationnels, un petit modèle pour les traitements de volume.
• Repli : un modèle d'un autre fournisseur, testé au moins une fois par trimestre sur le jeu de tests. Sans exercice réel, le repli est une fiction.
• Données autorisées : trois niveaux suffisent (public, interne, confidentiel), chacun associé à un mode d'exécution.
• Revue : tous les six mois, ou à chaque sortie majeure susceptible de changer le rapport qualité-prix. La revue consiste à rejouer le jeu de tests, pas à lire des annonces.
• Journalisation : quel modèle a produit quelle réponse, à quelle date. Indispensable pour comprendre une régression, et attendu par les cadres de gestion des risques comme celui publié par le NIST.

Cette politique s'articule naturellement avec la charte d'usage de l'IA en entreprise, qui traite du côté humain quand la politique de modèles traite du côté technique.

Ce qu'il faut retenir

Pour savoir quel modèle IA choisir, cessez de chercher le meilleur et commencez par qualifier l'usage : latence acceptable, coût par unité utile, qualité mesurée sur votre tâche, confidentialité exigée, effort de réversibilité. Ces cinq entrées éliminent la plupart des candidats en une réunion.

Trois actions concrètes pour la semaine qui vient : constituez un jeu de 50 exemples avec les réponses attendues, isolez vos appels de modèle derrière une seule couche technique, et écrivez la page de politique de modèles avec sa date de revue. Vous aurez alors la seule chose qui compte dans un domaine qui bouge vite : la capacité de changer d'avis sans tout reconstruire.