Faut-il consommer un modèle par API ou déployer un modèle open weights sur votre propre infrastructure ? La question revient dans presque tous les cadrages que nous menons, et elle est presque toujours mal posée. Ce n'est pas un arbitrage entre « cher mais simple » et « gratuit mais compliqué ». C'est un arbitrage entre deux structures de coût et deux répartitions de responsabilité.
Ce que l'API vous apporte, et ce qu'elle vous coûte
- Un accès immédiat à des modèles de premier plan, mis à jour sans effort de votre part
- Une facturation à l'usage, qui absorbe naturellement les volumes irréguliers
- L'infrastructure, la disponibilité et une partie de la sécurité prises en charge par le fournisseur
- Un délai de mise en service qui se compte en jours plutôt qu'en semaines
En contrepartie, vous dépendez de ses tarifs, de ses limites de débit, de ses évolutions de modèle et de ses conditions de traitement des données. Un modèle qui change de version peut modifier le comportement d'un système que vous aviez réglé finement, sans que vous ayez rien demandé. Ce risque opérationnel est réel, il se gère très bien, mais il faut l'avoir identifié avant de bâtir dessus.
Ce que l'open weights vous apporte, et ce qu'il vous coûte
- Le choix de l'hébergement, y compris sur votre propre matériel ou chez un opérateur de votre juridiction
- La maîtrise de la version : le modèle que vous avez qualifié reste celui qui tourne en production
- La possibilité de spécialiser le modèle sur vos données et votre vocabulaire métier
- Des conditions d'inférence stables et prévisibles, indépendantes d'une grille tarifaire
En contrepartie, vous prenez en charge les GPU, le déploiement, les mises à jour, la supervision, la cybersécurité et les garde-fous. Open weights ne veut pas dire gratuit. Cela veut dire que la facture change de nature : elle passe d'une ligne variable à une ligne fixe, assortie d'une responsabilité opérationnelle qui ne se délègue pas.
Qwen3.8-27B, ou pourquoi la question se pose vraiment maintenant
Pendant longtemps, un seul argument suffisait à clore le débat : les modèles ouverts étaient soit trop faibles pour un usage professionnel exigeant, soit trop lourds pour une infrastructure raisonnable. Ce n'est plus vrai.
Alibaba a publié le 14 août 2026 les poids de Qwen3.8-27B sous licence Apache 2.0. C'est un modèle dense multimodal de 27,8 milliards de paramètres, doté d'une fenêtre de contexte native de 262 000 tokens, extensible bien au-delà. Ses caractéristiques d'exécution sont ce qui intéresse une direction technique : de l'ordre de 27 Go de mémoire vidéo en FP8, autour de 15 Go en quantification 4 bits. Autrement dit un seul GPU professionnel, et du matériel nettement plus abordable dès qu'on accepte la quantification.
Concrètement, un serveur unique équipé d'une carte du marché suffit désormais à faire tourner en interne un modèle qui couvre confortablement une grande partie des besoins d'entreprise : extraction documentaire, classification, reformulation, synthèse, réponse sur base documentaire, production de sorties structurées. Ces tâches représentent l'essentiel des cas d'usage que nous déployons chez nos clients.
Restons honnêtes sur les limites. Ces modèles n'égalent pas encore les meilleurs modèles propriétaires sur les raisonnements longs et complexes, sur les tâches agentiques enchaînant de nombreuses étapes, ni sur les domaines les plus pointus. Le bon réflexe n'est donc pas de tout basculer, mais de constater qu'un seuil vient d'être franchi pour une catégorie entière de traitements, et de rouvrir le dossier.
La confidentialité ne se déduit pas du mode d'hébergement
C'est l'erreur de raisonnement la plus fréquente, et elle coûte cher dans les deux sens. « API » ne signifie pas automatiquement « données exposées », et « auto-hébergé » ne signifie pas automatiquement « données protégées ».
Un modèle open weights installé sur un serveur mal cloisonné, sans gestion fine des droits ni journalisation, protège moins bien vos données qu'une API sous contrat solide, avec traitement en Europe et absence de réutilisation pour l'entraînement. La confidentialité dépend de toute l'architecture : le contrat, la localisation du traitement, les durées de conservation, les journaux, les sous-traitants, les outils connectés et les droits d'accès. Le mode d'hébergement n'est qu'une variable parmi d'autres, et rarement la plus déterminante.
Le calcul qu'il faut vraiment faire
Avant de comparer le prix d'un million de tokens, comparez le coût complet sur trois ans. D'un côté : la consommation prévisionnelle, sa croissance attendue, et le risque d'évolution tarifaire. De l'autre : l'amortissement du matériel ou la location de GPU, l'hébergement, le temps d'ingénierie de mise en place, puis le temps récurrent de supervision, de mise à jour et de sécurisation.
Dans notre expérience, le point de bascule se situe rarement au niveau du prix brut du token. Il se situe au niveau de la régularité du volume. Tant que les volumes sont irréguliers ou modestes, l'API gagne presque toujours, et de loin. Dès qu'un traitement tourne en continu sur des flux prévisibles, l'auto-hébergement devient défendable, et il le devient d'autant plus vite que les contraintes de confidentialité sont fortes.
La règle pratique
- API pour démarrer vite, pour des volumes variables, et pour les tâches qui exigent le meilleur niveau disponible
- Open weights pour un besoin fort de contrôle, un fonctionnement local, une spécialisation métier, ou un volume stable qui justifie l'infrastructure
- Hybride lorsque certaines données doivent rester dans votre périmètre pendant que d'autres traitements profitent d'un modèle hébergé
L'architecture hybride est celle que nous recommandons le plus souvent, et ce n'est pas un compromis mou. Elle consiste à router chaque traitement vers le modèle qui lui convient, derrière une couche d'abstraction unique. Ce découplage est exactement ce qui vous permet de changer de modèle plus tard sans réécrire vos applications, et de tester une alternative sans arrêter la production.
“Le choix qui compte n'est pas API contre open weights. C'est de garder la capacité de passer de l'un à l'autre sans tout reconstruire.”
Ce qu'il faut trancher avant de choisir
- Quelles données ne doivent en aucun cas sortir de votre périmètre, et lesquelles le peuvent sous contrat
- Quel volume mensuel est réellement prévisible, et sur quelle durée
- Qui, en interne ou chez un partenaire, prendra la responsabilité opérationnelle d'une infrastructure d'inférence
- Quel niveau de qualité est exigé par chaque traitement, mesuré sur vos propres exemples et non sur des classements publics
- Combien de temps il vous faudrait pour changer de modèle si votre fournisseur modifiait ses conditions demain
Cette dernière question est celle que nous posons en premier. Elle ne concerne ni le prix ni la performance, mais elle détermine à elle seule la robustesse de l'architecture que vous vous apprêtez à construire.