Modèles ouverts vs API propriétaires : quel choix pour une IA souveraine ?

« Modèles ouverts ou API propriétaires ? » Posée ainsi, la question est piégée : elle suppose un camp à choisir une fois pour toutes. La réalité est plus pragmatique. La vraie question n'est pas idéologique mais opérationnelle : quel outil pour quel usage, et quel niveau de contrôle exigez-vous sur vos données ? Une entreprise mûre utilise souvent les deux, et les route selon le contexte.

Faisons le tour des arbitrages, sans dogmatisme, pour décider en connaissance de cause.

« Ouvert » ne veut pas dire ce que vous croyez

Premier malentendu à lever : poids ouverts ≠ open source. La plupart des modèles « ouverts » publient leurs poids sous une licence qui autorise l'usage commercial, parfois avec des restrictions (seuils d'utilisateurs actifs, clauses d'usage interdit, obligation d'attribution). Ce n'est pas la même chose qu'un logiciel libre au sens strict, où code d'entraînement et données seraient également publiés. Concrètement, vous récupérez un artefact — les poids — que vous pouvez exécuter sur votre infrastructure, mais vous n'avez ni la recette d'entraînement ni la garantie de pouvoir le reproduire. Lisez les licences ligne à ligne, surtout si votre produit dépasse quelques millions d'utilisateurs ou si vous opérez dans un secteur régulé.

Cette nuance a un corollaire opérationnel important : « ouvert » vous donne le droit d'exécuter le modèle où vous voulez, et donc le contrôle sur le lieu de traitement des données. C'est précisément ce levier qui intéresse une démarche de souveraineté — bien plus que la pureté philosophique de la licence.

Le panorama 2026 des modèles à poids ouverts

Le choix est aujourd'hui solide et varié. Chaque famille a son terrain de prédilection :

• Llama 4 (Meta) — la référence généraliste. Écosystème massif (outils d'inférence, fine-tuning, quantization, communauté). C'est souvent le choix par défaut quand vous voulez un modèle polyvalent bien documenté, avec un maximum de tooling tiers compatible. Idéal pour une première mise en production auto-hébergée où vous ne voulez pas essuyer les plâtres.
• Mistral Large 2 et Mistral Small 3 — ancrage européen, excellents en multilingue (français, allemand, espagnol, italien). Large 2 pour les tâches exigeantes de génération et de raisonnement ; Small 3 quand vous cherchez un rapport qualité/coût agressif, déployable sur un GPU unique, parfait pour la génération de réponses RAG à fort volume. Atout supplémentaire pour une entreprise européenne : un fournisseur soumis au droit de l'UE, disponible aussi via une API hébergée en Europe.
• Mistral NeMo — modèle compact (autour de 12 milliards de paramètres) co-développé avec NVIDIA, taillé pour l'efficacité. Bon candidat pour des tâches cadrées (extraction, classification, réécriture de requêtes) où un gros modèle serait du gâchis.
• Qwen 3 (Alibaba) — très performant, parmi les meilleurs modèles ouverts toutes catégories, avec d'excellentes capacités multilingues et une gamme de tailles étendue (du petit modèle embarquable au très gros). Pertinent si vous avez des besoins multilingues hors Europe (chinois, arabe, langues asiatiques) ou si vous voulez ajuster finement la taille au budget GPU.
• DeepSeek-V3 et DeepSeek-R1 — V3 est un généraliste performant à architecture mixture-of-experts, économe à l'inférence rapportée à sa taille. R1 est spécialisé dans le raisonnement : il « réfléchit » avant de répondre, ce qui le rend pertinent pour les tâches d'analyse multi-étapes, de vérification ou de décomposition de problèmes complexes — au prix d'une latence et d'une consommation de tokens plus élevées.
• Gemma 3 (Google) — modèles compacts et efficaces, pensés pour tourner sur du matériel modeste. Bon choix pour des déploiements edge, des tâches d'assistance légères, ou comme modèle de premier filtre dans une cascade.

L'écart de performance avec les meilleures API fermées s'est largement résorbé pour la majorité des usages d'entreprise. Sur des tâches de RAG bien cadrées — où le modèle synthétise un contexte qu'on lui fournit plutôt que de raisonner dans le vide — un bon modèle ouvert fait souvent jeu égal.

Retenez le principe : la taille se choisit en fonction de la tâche, pas par réflexe. Un modèle de 7 à 24 milliards de paramètres suffit fréquemment pour générer une réponse RAG correcte à partir d'un bon contexte ; on ne réserve les très gros modèles qu'aux tâches qui le justifient réellement.

Ce que les API fermées apportent vraiment

Les API propriétaires (famille Claude d'Anthropic, GPT / série o d'OpenAI, Gemini 2.x de Google) gardent des atouts réels :

• Performance brute souvent en tête sur le raisonnement complexe, les tâches agentiques et les cas limites.
• Zéro infrastructure : pas de GPU à provisionner, pas de serveur d'inférence à optimiser, pas de MLOps. Vous appelez une URL, vous payez à l'usage.
• Mises à jour continues sans effort de votre part : vous bénéficiez des nouvelles versions sans réentraîner ni redéployer quoi que ce soit.
• Élasticité immédiate : un pic de trafic est absorbé par le fournisseur, là où votre cluster GPU aurait saturé.

En contrepartie : dépendance à un fournisseur (tarifs, dépréciation de modèles, disponibilité), coût au token qui grimpe linéairement avec le volume, et surtout vos données qui sortent de votre périmètre — point critique dès qu'on parle souveraineté. Même avec des engagements contractuels de non-rétention et de non-entraînement, les prompts transitent par une infrastructure tierce, souvent hors UE. Pour certains traitements (données de santé, données clients sensibles, secrets industriels), ce seul fait peut être rédhibitoire indépendamment de toute considération de coût.

Les cinq axes d'arbitrage

Pour décider, évaluez chaque option sur cinq dimensions. Aucune ne tranche seule : c'est leur combinaison qui dicte le choix.

1. Performance — le modèle répond-il assez bien pour l'usage visé ? La bonne question n'est pas « est-il le meilleur du monde » mais « passe-t-il mon golden set de questions de référence avec un taux de réponses fidèles acceptable ». Mesurez avec une méthode reproductible (par exemple RAGAS : faithfulness, answer relevancy, context precision) plutôt qu'au feeling.
2. Coût total (TCO) — au token pour les API ; en GPU + opérations + amortissement + supervision pour l'auto-hébergé. Le point de bascule dépend du volume (voir plus bas). Piège classique : comparer le prix au token d'une API au seul coût horaire d'un GPU, en oubliant les ops, la redondance et le temps ingénieur.
3. Contrôle / souveraineté — qui maîtrise le modèle, sa disponibilité, son évolution ? Avec une API, un modèle peut être déprécié ou voir son comportement changer du jour au lendemain ; avec des poids ouverts, vous figez une version aussi longtemps que nécessaire (utile pour la reproductibilité et les audits).
4. Confidentialité des données — vos prompts et documents sortent-ils de votre infrastructure ? Et si oui, vers quelle juridiction, sous quelles garanties contractuelles ? C'est ici que l'EU AI Act et le RGPD pèsent : pour un système à haut risque, la traçabilité du traitement n'est pas optionnelle.
5. Effort opérationnel — avez-vous les compétences GPU/MLOps pour auto-héberger durablement, pas juste pour une démo ? Servir un modèle en production, c'est gérer la montée en charge, les mises à jour, la supervision, les incidents la nuit.

Sur les cinq axes, l'API fermée gagne souvent sur performance, effort opérationnel et élasticité ; l'ouvert auto-hébergé gagne sur contrôle, confidentialité et TCO à fort volume. Votre décision revient à pondérer ces axes selon le cas d'usage.

Le point de bascule du TCO : un ordre de grandeur

C'est la question qui revient toujours : à partir de quel volume l'auto-hébergé devient-il rentable ? Pas de chiffre universel, mais une logique simple et un ordre de grandeur prudent.

Côté API, le coût est variable : il croît avec chaque token traité. Côté auto-hébergé, le coût est largement fixe : un GPU loué chez un hébergeur souverain européen coûte un montant à peu près constant par mois, que vous l'utilisiez à 10 % ou à 90 %. Le calcul de bascule consiste donc à trouver le volume où le coût fixe mensualisé de votre infrastructure descend sous la facture variable de l'API pour le même travail.

Raisonnons en ordre de grandeur, à dessein conservateur :

• Supposez un GPU dédié de milieu/haut de gamme chez un hébergeur EU autour de 1 500 à 2 500 € par mois, capable de servir un modèle ouvert de taille moyenne (7–24 milliards de paramètres) en continu.
• Sur ce GPU, vous pouvez raisonnablement traiter plusieurs dizaines de millions de tokens par jour une fois l'inférence optimisée (batching, quantization).
• Une API performante facture l'équivalent travail à un prix au million de tokens qui, agrégé sur ce volume, dépasse vite ce loyer mensuel dès qu'on tourne en continu.

Conclusion pratique : tant que votre usage est sporadique ou à faible volume, l'API gagne presque toujours (vous ne payez que ce que vous consommez, sans GPU dormant). Dès que vous atteignez un trafic soutenu et prévisible qui saturerait raisonnablement un GPU plusieurs heures par jour, l'auto-hébergé bascule en votre faveur — et l'écart se creuse ensuite à votre avantage à mesure que le volume monte.

Le facteur décisif n'est pas le volume brut mais le taux d'utilisation de votre matériel. Un GPU à 15 % d'occupation coûte plus cher au token utile qu'une API. Un GPU bien rempli coûte une fraction du prix. Avant d'acheter, mesurez votre charge réelle sur quelques semaines.

N'oubliez pas d'ajouter au coût fixe les postes invisibles : redondance pour la haute disponibilité (souvent un second GPU), temps ingénieur d'exploitation, et la marche du marché qui peut rendre votre modèle obsolète avant amortissement. Le bon seuil intègre ces postes, pas seulement le loyer du GPU.

Tableau de décision par usage

Usage	Recommandation par défaut
Prototypage rapide, faible volume	API fermée — vélocité maximale, pas d'infra
Volumétrie très élevée et stable	Ouvert auto-hébergé — le TCO bascule en sa faveur
Données ultra-sensibles / réglementées	Ouvert auto-hébergé ou API EU avec non-rétention contractuelle
Multilingue européen exigeant	Mistral / Qwen ouverts, très compétitifs
Raisonnement complexe ponctuel	API fermée ou DeepSeek-R1 auto-hébergé
Tâches cadrées à fort volume (extraction, classification, réécriture de requêtes)	Petit modèle ouvert (Mistral Small 3, NeMo, Gemma 3) — économique et suffisant
Pics de trafic imprévisibles	API fermée ou débordement vers l'API au-delà de la capacité du cluster

Il n'y a pas de réponse unique : il y a un arbitrage par usage. C'est précisément pour ça que le routage est la stratégie gagnante.

L'approche hybride : router selon la sensibilité

La meilleure architecture combine souvent les deux mondes via un routage. L'idée : ne pas choisir un modèle pour toute l'entreprise, mais aiguiller chaque requête vers la destination qui maximise le bon arbitrage. Concrètement, vous placez un routeur en amont qui classe la requête et décide où l'envoyer.

Une stratégie de routage réaliste s'articule en quelques règles, évaluées dans l'ordre :

1. Classifier la sensibilité des données. Si le prompt ou le contexte récupéré contient des données personnelles, de santé, ou des secrets industriels, la requête ne sort pas : elle est servie par le modèle ouvert auto-hébergé, point final. C'est une règle de conformité, pas d'optimisation.
2. Estimer la difficulté de la tâche. Réponse factuelle directe à partir d'un bon contexte ? Un modèle ouvert de taille moyenne suffit. Raisonnement multi-étapes, synthèse de sources contradictoires, tâche agentique ? On autorise la bascule vers un modèle plus capable.
3. Vérifier la charge. Si le cluster GPU est proche de la saturation et que la requête est non sensible, on déborde vers une API fermée plutôt que de dégrader la latence pour tout le monde. C'est le pattern overflow : l'API sert d'amortisseur de pics, pas de moteur principal.
4. Mesurer la qualité a posteriori. Échantillonnez les réponses, scorez-les (LLM-as-judge, golden set), et ajustez les seuils. Une requête mal traitée par le petit modèle peut être réémise vers le gros — c'est le pattern cascade (essayer le moins cher d'abord, escalader si la confiance est insuffisante).

Voici le squelette d'une telle logique de routage :

def route(requete):
    if contient_donnees_sensibles(requete):
        return modele_ouvert_local        # jamais d'externalisation

    if tache_de_raisonnement_complexe(requete):
        return api_fermee                 # premium justifié

    if cluster_gpu_sature():
        return api_fermee                 # débordement / overflow

    return modele_ouvert_local            # cas par défaut, fort volume

Le résultat : rien de critique ne sort, vous servez le gros du volume à coût marginal quasi nul sur votre infrastructure, et vous ne payez le premium des API que là où il apporte une vraie valeur — performance de pointe ou absorption d'un pic. Ce découplage est aussi une assurance : si un fournisseur déprécie un modèle ou change ses tarifs, vous rebasculez le trafic non sensible sans réécrire votre application.

Le coût caché de l'auto-hébergement

Soyons honnêtes : auto-héberger n'est pas gratuit parce que les poids le sont. Il faut :

• du GPU (achat ou location), souvent sous-utilisé hors pics ou saturé pendant les pics — d'où l'importance du dimensionnement et du batching ;
• de la disponibilité : haute dispo, montée en charge, supervision, plan de reprise ;
• des compétences d'inférence (quantization, serveurs d'inférence, optimisation mémoire, gestion de la longueur de contexte) ;
• un suivi des nouvelles versions de modèles, qui sortent vite : ce qui est l'état de l'art ouvert ce trimestre sera dépassé le suivant, et migrer a un coût.

Pour une équipe sans culture MLOps, le « gratuit » de l'ouvert peut coûter plus cher qu'une API — en temps, en fiabilité et en coût d'opportunité. À l'inverse, une équipe qui maîtrise déjà l'inférence amortit ces compétences sur plusieurs cas d'usage et fait fondre le coût au token. Le bon choix dépend de votre maturité, pas d'un principe.

Conclusion

La souveraineté n'impose pas le tout-ouvert. Elle impose de savoir ce qui sort de votre périmètre et où c'est traité. Un modèle ouvert auto-hébergé maximise le contrôle et écrase le coût à fort volume ; une API fermée maximise la vélocité, la performance brute et l'élasticité. Entre les deux, le routage par sensibilité et par difficulté offre le meilleur compromis pour la plupart des entreprises : il garde le critique à l'intérieur, sert le volume à bas coût, et réserve le premium aux cas qui le méritent. Choisissez par usage, mesurez votre TCO réel sur votre charge réelle, et gardez la main sur ce qui compte vraiment : vos données.

Pour aller plus loin

• Souveraineté de l'IA pour l'entreprise européenne : le guide stratégique 2026
• RAG souverain et conforme RGPD : le guide complet 2026