StratégieJuin 20267 min de lecture
GPT, Claude ou open-source : comment choisir son modèle en entreprise
On me demande quel est le meilleur modèle. C'est presque toujours la mauvaise question : le modèle change tous les deux mois, votre architecture reste des années.
Je vais être direct : le modèle que vous choisissez aujourd'hui ne sera pas le meilleur dans six mois, et ce n'est pas grave. Ce qui compte, c'est de choisir de façon à pouvoir en changer sans tout refaire. Voici le cadre que j'applique en mission, celui qui ne vieillit pas à chaque nouvelle sortie.
Pourquoi un comparatif de benchmarks vieillit en deux semaines
Un classement de modèles a une durée de vie de quelques semaines. Un fournisseur publie une nouvelle version, les scores bougent, le podium se réorganise. Si vous choisissez sur ce podium, vous choisissez une photo déjà périmée le jour où vous déployez. Pire : les benchmarks publics mesurent des tâches génériques, pas la vôtre. Un modèle premier au classement peut être médiocre sur vos documents, votre jargon, vos cas limites. Je ne choisis donc jamais un modèle sur un score global. Je choisis une manière de brancher un modèle, n'importe lequel, et de le remplacer quand un meilleur arrive.
Le modèle est rarement le facteur décisif. La tuyauterie autour de lui l'est presque toujours.
Les vrais critères, au-delà du classement
Quatre critères survivent aux sorties de modèles, parce qu'ils touchent à votre contexte, pas au leur. Aucun ne se lit dans un classement, tous décident du succès en production.
- Où finissent vos données : qui les voit, où elles sont stockées, ce que vous devez pouvoir prouver.
- Le coût au volume : pas le prix affiché, mais ce que ça coûte à votre trafic réel.
- L'adéquation à la tâche : le plus petit modèle qui fait le travail, pas le plus impressionnant.
- La réversibilité : pouvoir changer de modèle sans réécrire votre produit.
Où finissent vos données : API fermée ou open-source hébergé chez vous
C'est le premier tri, et souvent le plus contraignant. Avec une API fermée (GPT ou Claude via leur cloud), vos données transitent chez un tiers. Pour beaucoup d'usages c'est parfaitement acceptable, à condition de lire les engagements : rétention, absence d'entraînement sur vos données, localisation. Pour des données sensibles, réglementées ou souveraines, la contrainte peut imposer autre chose : un modèle open-source que vous hébergez, dans votre cloud ou sur vos serveurs, où la donnée ne sort jamais de votre périmètre. C'est le sujet de héberger l'IA dans votre cloud ou sur site : ce n'est pas « installer un modèle », c'est décider où vit la donnée avant de choisir le reste.
Le coût au volume
Le prix au token ne veut rien dire tant que vous ne le multipliez pas par votre trafic. Un modèle deux fois moins cher au token peut coûter plus cher au total s'il faut lui envoyer trois fois plus de contexte, ou relancer les réponses ratées. Je raisonne toujours en coût par requête réelle, pas en tarif de grille. À faible volume, une API fermée est presque toujours la moins chère : rien à héberger, vous payez à l'usage. À fort volume et usage stable, un modèle open-source hébergé peut devenir plus rentable, parce que le coût devient celui de votre infrastructure, pas d'un compteur. Le point de bascule dépend de vos chiffres, pas d'une règle générale. Avant de changer de modèle pour économiser, je regarde d'abord comment réduire la facture existante : sur les factures que j'audite, 30 à 70% d'économies sont possibles à qualité égale, sans changer de fournisseur.
L'adéquation à la tâche : quand un petit modèle suffit
La plupart des tâches en entreprise ne demandent pas le plus gros modèle. Classer un message, extraire quelques champs d'un document, router une demande, résumer un ticket : un modèle petit et rapide fait le travail, pour une fraction du coût et de la latence. Le gros modèle se justifie sur le raisonnement complexe, la rédaction longue et les cas ouverts. Mon réflexe : partir du plus petit modèle qui passe mes tests, pas du plus capable. On peut toujours monter en gamme sur les cas qui le méritent. L'inverse, brancher le modèle le plus cher partout par défaut, est la première source de gaspillage que je trouve en audit.
La réversibilité : le rôle du MCP
Le vrai risque n'est pas de choisir le mauvais modèle. C'est de construire tout votre produit autour d'un fournisseur, au point de ne plus pouvoir en changer. C'est là que le MCP (Model Context Protocol) aide directement. C'est désormais un standard ouvert, adopté par Anthropic, OpenAI, Google et Microsoft, et confié à la Linux Foundation fin 2025. Concrètement : vous branchez vos outils et vos données une fois, derrière une interface standard, et le modèle devient une pièce remplaçable. Vous testez Claude, puis GPT, puis un modèle open-source sur le même socle, sans rien recâbler. C'est le contraire du lock-in.
Open-source : ce que ça apporte, ce que ça exige
L'open-source apporte trois choses réelles : vos données restent chez vous, aucun fournisseur ne peut couper le service ou changer les prix du jour au lendemain, et le coût devient prévisible à fort volume. Pour des données souveraines ou réglementées, c'est parfois la seule option acceptable. En échange, il exige ce que l'API vous fournissait gratuitement : l'exploitation. Héberger, mettre à l'échelle, surveiller, mettre à jour, sécuriser. Un modèle open-source « gratuit » mal exploité coûte plus cher qu'une API. Je ne recommande l'open-source que quand une raison claire le justifie (données, volume, souveraineté), jamais par principe.
Une architecture multi-modèles simple
- Une couche de routage qui envoie chaque requête au plus petit modèle capable de la traiter.
- Un modèle petit et rapide (souvent open-source, hébergé chez vous) pour la classification, l'extraction et le tri de masse.
- Un grand modèle (souvent une API) réservé au raisonnement complexe et aux cas ouverts.
- Une interface commune (MCP) pour que chaque modèle voie les mêmes outils et les mêmes données, et reste remplaçable.
Le même principe vaut pour vos données : un système de recherche augmentée (RAG) branché derrière cette interface commune sert une réponse sourcée en 2s, avec 70% de recherche en moins pour vos équipes, quel que soit le modèle en dessous. Le modèle redevient un détail d'implémentation. C'est exactement ce que vous voulez : pouvoir changer d'avis dans six mois sans rien jeter.