Faut-il toujours privilégier un modèle open source pour des raisons de coût ?

Non. L’open source ne devient moins cher que l’API propriétaire qu’à partir d’un volume d’usage soutenu, une fois les coûts d’hébergement et de maintenance comptés. En dessous de ce seuil, l’API propriétaire reste souvent l’option la plus économique en coût total.

Combien de temps faut-il pour comparer plusieurs modèles sérieusement ?

Comptez une à deux semaines pour constituer un jeu de cas réels, tester trois à quatre modèles candidats dessus et chiffrer le coût au volume projeté. C’est le délai que nous appliquons avant chaque choix de modèle en production.

Un modèle plus performant sur les benchmarks généraux est-il toujours le meilleur choix ?

Pas nécessairement. L’écart entre les meilleurs modèles propriétaires et ouverts est aujourd’hui inférieur à deux points sur les benchmarks de référence, contre plus de quinze points en 2023. Un score élevé sur vos cas d’usage réels compte davantage qu’un classement général.

Peut-on changer de modèle après avoir construit le produit dessus ?

Oui, si la portabilité a été vérifiée dès le départ : format des prompts, absence de dépendance à des fonctions propriétaires spécifiques. C’est pour cela que la clause de portabilité fait partie des cinq étapes de la méthode, avant la signature.

Faut-il choisir un modèle différent pour chaque fonctionnalité IA d’un même produit ?

Souvent oui. Un assistant de support et un moteur de résumé de documents n’ont pas les mêmes exigences de latence ni le même profil de coût. Tester chaque cas d’usage séparément évite de sur-payer un modèle puissant pour une tâche simple.

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

Le mauvais réflexe : chercher « le meilleur modèle »

Un client demande presque toujours la même chose en premier : « quel est le meilleur modèle IA en ce moment ? ». La question part d’un bon réflexe mais mène rarement à une bonne décision. Le classement des modèles change toutes les six à huit semaines, et le modèle le plus performant sur un benchmark généraliste n’est pas forcément le plus adapté à votre cas d’usage, votre budget ou vos contraintes de données.

La question qui compte réellement est différente : parmi les modèles disponibles aujourd’hui, lequel répond le mieux aux six critères qui déterminent si un projet IA tient en production, et pas seulement en démonstration ? C’est cette question que nous posons avec chaque client avant d’écrire la première ligne de code, et elle change presque toujours la réponse initiale, parfois radicalement.

Les six critères qui déterminent le bon choix

Aucun de ces critères n’est à lui seul décisif. C’est leur combinaison, pondérée selon votre projet, qui tranche. Un assistant de support facturé au ticket n’a pas la même hiérarchie de critères qu’un moteur de résumé juridique interne.

Critère	Ce qui compte concrètement	Piège fréquent
Coût total	Prix par token à volume réel, pas au tarif catalogue d’un test ponctuel	Comparer un prix API à un coût d’hébergement sans compter la maintenance
Latence et fiabilité	Temps de réponse sous charge, pas en test isolé, et existence d’un SLA	Ignorer la variabilité de latence des fournisseurs d’inférence tiers
Confidentialité des données	Où les données transitent et sont conservées, contractuellement	Supposer qu’un modèle « open source » garantit à lui seul la confidentialité
Capacité de personnalisation	Fine-tuning possible ou seulement prompt engineering et RAG	Fine-tuner un modèle propriétaire fermé sans clause de portabilité
Dépendance fournisseur	Facilité à changer de modèle si le fournisseur change ses prix ou ses conditions	Construire toute la couche produit autour d’une API propriétaire unique
Écart de qualité brute	Score sur vos cas d’usage réels, pas sur un benchmark général	Choisir sur la réputation plutôt que sur un test avec vos propres données

L’écart de performance s’est effondré, le reste n’a pas changé

Sur les benchmarks de référence, l’écart entre le meilleur modèle propriétaire et le meilleur modèle ouvert est passé de plus de quinze points en 2023 à moins de deux points début 2026. Concrètement, la performance brute ne suffit plus à trancher, sauf pour une minorité de tâches de raisonnement extrême, comme la preuve mathématique formelle ou la planification à très long horizon. Les cinq autres critères du tableau ci-dessus pèsent donc davantage qu’il y a deux ans, et c’est une bonne nouvelle : ce sont les critères les plus faciles à mesurer objectivement, contrairement à une impression de qualité.

Autre repère utile côté coût : un modèle ouvert déployé sur une infrastructure dédiée revient généralement cinq à dix fois moins cher qu’un modèle propriétaire consommé via API, à volume comparable, mais ce calcul s’inverse en dessous d’un certain seuil d’usage quotidien. En dessous, les coûts fixes d’hébergement, de supervision et de gestion des pannes dépassent la facture API. La bascule se situe le plus souvent entre quelques centaines et quelques milliers de francs de consommation API mensuelle, selon la charge d’exploitation que l’équipe peut absorber en interne sans embaucher une personne dédiée.

Confidentialité : une question contractuelle, pas seulement technique

Un modèle ouvert hébergé chez soi ne garantit rien par construction : ce qui protège les données, c’est l’endroit où elles sont stockées et le contrat qui l’encadre, pas l’étiquette « open source ». Si vos clients ou votre secteur exigent que certaines données restent en Suisse ou dans l’Union européenne, cette contrainte réduit la liste des fournisseurs candidats avant même de comparer les scores de performance. Trois questions concrètes à poser dès le premier appel avec un fournisseur : où les données sont-elles physiquement stockées, combien de temps sont-elles conservées après l’appel, et servent-elles à ré-entraîner le modèle par défaut ou seulement sur option explicite. Mieux vaut vérifier ces trois points avant de signer un contrat annuel qu’après.

Lire un benchmark public sans se faire avoir

Les classements publics de modèles sont utiles pour se faire une première idée, pas pour trancher. Trois biais reviennent régulièrement. D’abord, la contamination : une partie des questions de test a pu fuiter dans les données d’entraînement de certains modèles, ce qui gonfle artificiellement leur score sans refléter une vraie capacité de généralisation. Ensuite, le choix du prompt : un fournisseur qui publie son propre score choisit souvent le prompt le plus favorable à son modèle, rarement un prompt neutre. Enfin, la nature de la tâche : un modèle excellent en génération de code peut être médiocre en extraction d’information structurée, et un classement généraliste moyenne les deux.

Un cas fréquent illustre ce piège : un modèle affiche un score impressionnant sur un test de codage général, mais s’avère nettement moins fiable une fois confronté à une base de code interne avec ses conventions et son historique propres. Le classement public mesurait une compétence générique, pas la tâche réelle. C’est exactement ce que le test sur vos propres cas, décrit ci-dessous, permet de détecter avant de signer un contrat plutôt qu’après trois mois de production.

La conséquence pratique : un classement public sert à présélectionner trois ou quatre candidats plausibles, jamais à choisir directement le modèle final. Ce choix final doit venir du test décrit plus bas, sur vos propres cas.

La méthode en cinq étapes pour trancher

Écrivez le cas d’usage en une phrase testable. Pas « un chatbot plus intelligent », mais « répondre à une question de facturation en moins de trois secondes avec la bonne réponse neuf fois sur dix ».
Constituez un jeu de vingt à cinquante cas réels, tirés de vraies conversations ou de vrais documents, pas de cas inventés pour l’occasion. Un jeu de cas fabriqué de toutes pièces donne systématiquement des scores plus flatteurs que la réalité.
Testez trois à quatre modèles candidats sur ce même jeu, avec le même prompt et la même méthode d’évaluation, pour isoler la variable qui compte. Mélanger les prompts entre modèles invalide la comparaison.
Chiffrez le coût à votre volume réel projeté, pas au volume du test, en intégrant l’hébergement, la supervision et la marge d’erreur si l’auto-hébergement est envisagé.
Vérifiez la clause de portabilité des données avant de signer quoi que ce soit, pas après avoir construit six mois de produit dessus. Un format de prompt propriétaire ou une fonction spécifique au fournisseur suffit à bloquer une migration future.

Cette méthode prend une à deux semaines. C’est peu, comparé au coût de refaire l’intégration six mois plus tard parce que le premier choix a été fait sur la réputation d’un fournisseur plutôt que sur un test avec vos propres données.

Quand cette question ne mérite pas encore une réponse

Avant un produit qui a trouvé son marché, passer deux semaines à comparer des modèles est souvent un mauvais calcul. Un prototype qui doit valider une hypothèse en quinze jours peut tourner sur un seul modèle propriétaire générique, choisi par défaut, sans arbitrage formel. Le risque n’est pas de se tromper de modèle à ce stade : c’est de perdre deux semaines sur une décision que le prototype rendra peut-être caduque.

Le bon moment pour appliquer la méthode en cinq étapes ci-dessus, c’est au moment de passer de la démonstration à la production, quand le coût d’un mauvais choix se compte en mois de retard plutôt qu’en heures de test. De la même façon, si votre volume d’usage reste sous quelques dizaines de requêtes par jour, l’auto-hébergement d’un modèle ouvert coûte presque toujours plus cher en temps d’équipe que ce qu’il fait économiser en facturation API. Ce n’est un bon calcul qu’à partir d’un volume soutenu et prévisible, pas d’un usage sporadique.

Ce que le choix du modèle ne règle pas

Un bon choix de modèle ne compense pas une évaluation absente. Le forward deployed engineering consiste justement à tester un système sur des données réelles avant la démonstration, quel que soit le modèle retenu en dessous : la grille d’évaluation, le jeu de tests et le circuit de correction comptent souvent davantage que le choix initial entre deux modèles aux scores proches. Deux équipes qui partent du même modèle obtiennent des résultats très différents en production selon la rigueur de leur méthode de test, pas selon leur choix de fournisseur.

Ce point revient souvent en fin de mission : une équipe qui a choisi un modèle solide mais n’a jamais formalisé sa grille d’évaluation découvre les régressions en production, par les retours clients, plutôt qu’avant la mise en ligne. Une équipe qui a formalisé cette grille dès le départ détecte la même régression en quelques minutes, sur son jeu de tests, avant qu’un seul utilisateur ne la voie.

Retrouvez nos formules et nos prix pour un accompagnement sur ce type de décision, ou consultez les questions fréquentes si vous démarrez tout juste ce chantier. Vous pouvez aussi parcourir tous les articles du blog pour creuser les sujets voisins, notamment la méthode d’évaluation avant démonstration.