Le modèle se télécharge gratuitement. La facture, elle, commence ensuite. Pour une entreprise qui veut résumer ses contrats, assister ses développeurs ou interroger sa documentation, les modèles d’IA à poids ouverts offrent une promesse séduisante : reprendre la main. Mais remplacer une API par un modèle hébergé chez soi ne supprime pas les dépendances. Cela les déplace vers les puces, les logiciels et les équipes. À l’horizon de septembre 2026, cette question mérite mieux qu’un duel entre ouverture vertueuse et cloud captif. Les faits historiques présentés ici servent de socle ; les évolutions envisagées restent prospectives.
Des poids ouverts, pas nécessairement un logiciel libre
Premier piège : le vocabulaire. Un modèle à poids ouverts permet de récupérer les paramètres appris pendant son entraînement et, selon sa licence, de l’exécuter ou de l’adapter. Cela ne signifie pas que ses données d’entraînement, son code et sa recette de fabrication sont intégralement accessibles. Ni que tous les usages sont autorisés.
Les sorties de 2024 ont installé cette diversité. Meta a publié Llama 3 puis Llama 3.1 sous une licence communautaire comportant des conditions spécifiques. Mistral AI a distribué certains modèles, dont Mixtral 8x22B, sous licence Apache 2.0. Deux téléchargements peuvent donc conduire à des obligations très différentes, même lorsque les deux modèles sont présentés comme « ouverts ».
La vérification doit porter sur la version exacte. Usage commercial, redistribution, adaptation, attribution, restrictions sectorielles éventuelles : le service juridique doit lire la licence, pas seulement la fiche marketing. Et l’accès aux poids ne garantit ni l’absence de contenus protégés dans l’entraînement ni une indemnisation en cas de litige. Côté API, les protections contractuelles varient également selon le fournisseur et l’offre.
Hébergement : le GPU n’est que le début
Imaginons un distributeur qui déploie un assistant pour ses équipes commerciales. Avec une API, il achète principalement des requêtes ou des jetons, ces fragments de texte traités par le modèle. Avec un déploiement autonome, il doit dimensionner une capacité : mémoire des accélérateurs, débit, temps de réponse et nombre d’utilisateurs simultanés. Le modèle qui fonctionne pendant une démonstration peut saturer à l’ouverture des bureaux.
Un petit modèle spécialisé peut tourner sur une infrastructure relativement modeste. Un grand modèle, ou un contexte très long, change l’équation. Réduire la précision des poids, par quantification, économise de la mémoire, mais ses effets sur la qualité doivent être mesurés. S’ajoutent stockage, réseau, supervision, sauvegardes et redondance. Louer des GPU évite l’achat initial, pas les dépenses récurrentes.
La comparaison pertinente n’est donc pas « gratuit contre payant », mais coût complet par tâche correctement réalisée. Une réponse peu chère qui doit être corrigée par un salarié peut coûter davantage qu’une réponse facturée plus cher. Inversement, un modèle compact et bien adapté peut devenir avantageux sur un volume élevé, régulier et prévisible.
Ce qu’un devis oublie facilement
- La capacité inutilisée entre deux pics de trafic et la réserve nécessaire pour absorber les pointes.
- Le temps des ingénieurs consacré au déploiement, aux évaluations et aux incidents.
- Les traitements annexes : recherche documentaire, filtrage, journalisation et contrôle humain.
- Le coût d’une indisponibilité ou d’une dégradation silencieuse des réponses.
L’API mutualise une partie de ces charges chez le fournisseur. En contrepartie, elle expose aux tarifs, quotas et décisions de gamme de celui-ci. L’auto-hébergement donne plus de leviers, mais oblige à savoir les actionner.
Sécurité : garder les données ne suffit pas
L’argument le plus solide en faveur d’un hébergement maîtrisé concerne souvent les données. Des contrats sensibles ou des dossiers internes peuvent rester dans un environnement choisi. Encore faut-il vérifier où passent les journaux, les sauvegardes, les outils de supervision et les éventuelles télémétries. Un modèle installé dans un cloud externe n’est pas automatiquement synonyme de souveraineté.
Une API professionnelle peut, de son côté, proposer des engagements sur la conservation, la localisation ou la non-utilisation des données pour l’entraînement. Ces dispositions doivent être vérifiées contractuellement, sans les extrapoler depuis une offre grand public. Le choix oppose donc deux architectures et deux chaînes de responsabilité, pas mécaniquement confidentialité et exposition.
Dans les deux cas, les risques propres aux assistants demeurent. Un document malveillant peut contenir une instruction destinée à détourner le modèle : c’est l’injection de prompt. Si l’assistant peut envoyer des courriels ou modifier une base, les conséquences dépassent une mauvaise réponse. Il faut limiter ses droits, isoler les outils et imposer une validation humaine pour les actions sensibles.
L’hébergement autonome ajoute une chaîne logicielle à sécuriser : provenance des fichiers, bibliothèques, conteneurs et mises à jour. Certains dépôts proposent du code à exécuter avec le modèle ; l’accepter sans audit crée un risque distinct de celui des poids eux-mêmes. L’ouverture facilite l’inspection, elle ne la remplace pas.
Maintenance : posséder une version, c’est aussi l’entretenir
Une équipe peut conserver longtemps une version téléchargée, avantage réel face à une API susceptible de retirer un ancien modèle. Mais cette stabilité a un envers. Les moteurs d’inférence évoluent, les pilotes changent et des vulnérabilités apparaissent. Même sans réentraîner le modèle, il faut maintenir son environnement et vérifier ses performances.
Changer de modèle n’est pas davantage un simple échange de fichier. Format des messages, comportement des outils, longueur de contexte et qualité en français peuvent varier. Une consigne efficace sur une version peut devenir fragile sur la suivante. Chaque migration appelle des tests sur de vrais dossiers, avec des critères métier, pas seulement un classement généraliste.
Avec une API, le fournisseur prend en charge une grande partie de l’exploitation. L’entreprise conserve néanmoins la responsabilité de son application : autorisations, qualité des sources documentaires, contrôle des réponses et suivi des erreurs. Externaliser l’inférence ne revient pas à externaliser toute la fiabilité.
Moins de dépendance, ou d’autres dépendances ?
Les poids ouverts offrent une possibilité importante : changer d’hébergeur sans abandonner nécessairement le modèle. Cette portabilité reste conditionnée par la licence, le matériel disponible et la compatibilité logicielle. Une optimisation très liée à un accélérateur peut recréer une dépendance technique. Le verrou fournisseur devient parfois un verrou de compétences internes.
Pour choisir, mieux vaut tester un périmètre précis pendant plusieurs semaines. Mesurer la qualité réelle, les délais, le coût total et l’effort d’exploitation révèle davantage qu’une comparaison de prix affichés. Un montage hybride peut aussi être pertinent : modèle maîtrisé pour certaines données, API pour des besoins ponctuels, sous réserve de règles de routage explicites.
Et maintenant ? À l’horizon de septembre 2026, il paraît plausible que l’amélioration des petits modèles et des outils de déploiement élargisse les usages de l’auto-hébergement. Ce n’est pas la promesse d’une autonomie gratuite. Les organisations les mieux placées seront celles capables de documenter leurs dépendances, de tester une solution de remplacement et de financer l’exploitation quotidienne. Le vrai pouvoir de négociation n’est pas seulement de posséder les poids : c’est de pouvoir changer de solution sans mettre son activité à l’arrêt.
