La thèse en une phrase : le choix entre IA open source et API fermée ne se joue presque jamais là où on le croit. Ce n’est pas une bataille de principes entre « liberté » et « lock-in ». C’est une décision d’ingénierie avec deux horloges —le coût à l’échelle et la sensibilité de la donnée— et pour l’immense majorité des entreprises, la bonne réponse le premier jour n’est pas l’idéologique. Cet article parle de quand ça compte vraiment et quand, honnêtement, ça n’a aucune importance.
IA open source vs API fermée en entreprise : la plupart pose la question à l’envers
La conversation arrive presque toujours viciée. Quelqu’un de l’équipe a lu que Llama, Mistral ou DeepSeek sont des modèles ouverts, qu’on peut les télécharger et les faire tourner « chez soi », et d’un coup la question n’est plus « de quoi mon business a-t-il besoin ? » mais « on est du genre à dépendre d’OpenAI, ou du genre à s’auto-héberger ? ». Ça, ce n’est pas une décision technique : c’est une identité. Et les décisions d’identité, on les défend avec fierté, pas avec des données.
La question utile est bien plus ennuyeuse : pour le problème précis que tu veux résoudre, qu’est-ce que chaque option t’apporte et qu’est-ce qu’elle te coûte —en argent, en temps de ton équipe, en risque ? Posée ainsi, le drapeau tombe tout seul et ce qui décide vraiment apparaît : le volume auquel tu vas appeler le modèle et à quel point la donnée que tu vas lui donner est sensible.
Ce que chaque option t’apporte vraiment (sans le drapeau)
API fermée : vitesse et zéro maintenance
Une API fermée —OpenAI, Anthropic, Google— c’est un appel réseau. Tu ne provisionnes pas de GPU, tu ne patches pas de drivers, tu ne t’inquiètes pas que le modèle tombe à 3h du matin. Tu paies au token, tu démarres en quelques minutes, et le fournisseur améliore le modèle en dessous sans que tu touches à rien. En échange, la donnée sort de ton périmètre vers le sien (contrat à l’appui), c’est un autre qui fixe le coût unitaire, et tu es lié à sa feuille de route et à sa politique de prix. Tu achètes de la vitesse et de la tranquillité ; tu loues le contrôle.
Open source : contrôle et coût à l’échelle, contre de la plomberie
Un modèle ouvert que tu fais tourner toi-même —dans ton cloud ou sur ton matériel— te donne l’inverse : la donnée ne bouge pas d’où tu dis, le coût par million de tokens à fort volume peut s’effondrer, et personne ne te déprécie le modèle par surprise. Le prix de ça, c’est que l’infrastructure est désormais la tienne : servir le modèle, le scaler, le monitorer, le mettre à jour et répondre quand il casse, c’est le boulot de ton équipe, pour toujours. Ce n’est pas « moins cher » : tu échanges une facture de fournisseur contre une masse salariale d’ingénierie. Pour qui a du volume et du personnel, c’est rentable ; pour qui n’en a pas, c’est un gouffre.
| Axe | API fermée | Open source (auto-hébergé) |
|---|---|---|
| Démarrage | Quelques minutes | Des semaines de setup |
| Où vit la donnée | Chez le fournisseur (sous contrat) | Où tu décides |
| Coût | Au token, fixé par le fournisseur | Fixe (infra + équipe), bon marché à l’échelle |
| Maintenance | Zéro, s’améliore seul | La tienne, pour toujours |
| Contrôle / lock-in | Peu de contrôle, fort lock-in | Fort contrôle, sans lock-in |
| Pour qui c’est rentable | Presque tout le monde au début | Fort volume ou donnée sensible |
Pourquoi pour 90% des PME la réponse est de démarrer avec une API fermée
Ce n’est ni de la paresse ni un pragmatisme timoré : c’est de l’arithmétique. La plupart des projets d’IA d’une PME meurent non pas d’avoir choisi le mauvais modèle, mais de n’avoir jamais atteint la production. Et tout ce qui allonge le chemin vers la production augmente la probabilité de mort. Auto-héberger un modèle ouvert ajoute, d’emblée, un projet d’infrastructure entier avant même d’avoir validé que l’idée fonctionne. C’est optimiser le coût par token de quelque chose dont tu ne sais pas encore si tu vas t’en servir.
- Ton volume est faible au début. L’économie au token de l’open source ne compense qu’à partir de beaucoup de trafic. Avec quelques appels par jour, ton infrastructure propre coûte plus cher que l’API, pas moins.
- Tu n’as —ni ne veux— d’équipe MLOps. Servir un modèle en production en haute disponibilité est un métier. Si tu ne l’as pas en interne, ce que tu économises en tokens tu le paies en recrutements ou en pannes.
- Le modèle ouvert d’aujourd’hui n’est pas ton avantage. Ton différenciateur, ce n’est pas quels poids tu fais tourner, c’est ton process et ta donnée. Démarrer sur une API te laisse te concentrer là-dessus plutôt que sur des drivers de GPU.
- Migrer plus tard est bon marché ; se tromper au départ est cher. Si tu conçois l’appli découplée du fournisseur, passer d’une API fermée à ton propre modèle plus tard est un changement de config, pas une réécriture.
Le coup sensé est de démarrer avec une API fermée, de valider que le cas fonctionne dans ton opération et de laisser la porte ouverte pour descendre vers l’open source le jour où les chiffres le demandent. Si le projet est sérieux et va croître, cette architecture —découplée, avec routage de modèles et la donnée sous ton contrôle— c’est exactement ce qu’on monte en infrastructure d’IA en entreprise : pas pour te marier à un fournisseur, mais pour pouvoir en changer sans douleur.
Quand descendre vers l’open source a du sens
La règle n’est pas « jamais d’open source ». C’est « open source quand un vrai déclencheur le justifie », pas quand la fierté le réclame. Voici les déclencheurs qui font vraiment pencher la balance :
- La donnée ne peut pas sortir de ton périmètre. Santé, banque, juridique, secret industriel : si par contrat ou par réglementation la donnée ne peut toucher un serveur tiers, l’auto-hébergement cesse d’être une préférence pour devenir une exigence. Avant de tenir pour acquis que c’est ton cas, mets au clair ce qui peut et ne peut pas sortir avec une politique d’usage de ChatGPT et des modèles externes en entreprise ; souvent la donnée sensible n’est qu’une petite fraction et le reste passe très bien par API.
- Le volume est grand et soutenu. Quand tu appelles le modèle des millions de fois par mois de façon stable, le coût au token de l’API commence à faire mal et ton propre modèle s’amortit. Là, oui, l’arithmétique favorise l’open source —à condition d’avoir déjà quelqu’un pour l’opérer—.
- Tu as besoin d’affiner le modèle avec ton savoir. Si ton cas exige un modèle spécialisé dans ton domaine et tes données, contrôler les poids aide. Attention toutefois : avant le fine-tuning, le vrai remède est presque toujours la récupération sur ton information, ce qu’on décortique dans entraîner l’agent avec ta propre information.
- Latence ou hors-ligne. Si tu as besoin d’une réponse locale, sans réseau, ou d’une latence minimale garantie, le modèle doit vivre près de là où on l’utilise. Là, aucune API fermée ne tient.
Le coût que personne ne te dit : maintenir n’est pas gratuit
L’erreur classique en comparant, c’est de ne regarder que le prix au token et de conclure que l’open source est « gratuit ». Il ne l’est pas. Un modèle auto-hébergé a un coût qui n’apparaît sur aucun tarif : quelqu’un doit le servir en haute disponibilité, veiller à ce qu’il ne se dégrade pas, le mettre à jour quand une meilleure version sort, et être d’astreinte quand il tombe. Ce coût est une masse salariale, pas une ligne de facture, et il est récurrent. L’API fermée cache ce coût dans le prix au token ; l’open source le refile entier à ton équipe.
C’est pourquoi la comparaison honnête n’est pas « API chère contre open source bon marché ». C’est « coût variable que tu ne gères pas contre coût fixe que tu gères ». Pour un volume faible ou moyen, le variable gagne presque toujours. Pour un fort volume avec équipe dédiée, le fixe. La même logique de fond qui sépare acheter de construire pour n’importe quelle brique d’IA, qu’on a déjà défendue dans acheter ou construire des agents IA.
Que faire lundi
- Démarre avec une API fermée et valide que le cas fonctionne dans ton opération réelle, pas dans une démo. Optimiser le coût au token avant ça, c’est optimiser quelque chose qui n’existe pas.
- Découple dès le premier jour. Conçois l’appli pour que le fournisseur de modèle soit de la config, pas du câblage. Ainsi migrer plus tard coûte un après-midi, pas un trimestre.
- Marque tes déclencheurs. Écris, noir sur blanc, quelle donnée ne peut pas sortir et à quel volume la facture commencerait à faire mal. Le jour où l’un se réalise, tu as ton signal pour descendre vers l’open source —et seulement ce jour-là—.