Développez intelligemment votre business en optimisant vos coûts
On en discuteL’IA open weight, ce sont des modèles que l’on télécharge et que l’on fait tourner où l’on veut : chez un hébergeur européen, sur un serveur loué, ou dans vos murs. Ils promettent des prix au token divisés par dix et des données qui ne quittent pas l’entreprise. Deux questions restent : à quoi servent-ils dans votre entreprise, et combien coûtent-ils réellement, tout compris ? Voici six usages où un modèle open weight a du sens, trois où il n’en a pas, les quatre postes de coût, dont un seul figure sur la facture, et une méthode pour chiffrer votre cas en dix minutes, avec un simulateur et un exemple calculé jusqu’au bout. Si la différence entre open weight et open source vous échappe encore, notre premier article l’explique en quatre questions.
Six usages courants, et une règle. L’open weight a du sens quand au moins une de ces conditions est réunie : les données ne doivent pas sortir de l’entreprise, le volume est élevé et les tâches répétitives, le modèle doit apprendre un vocabulaire maison, l’usage doit fonctionner sans connexion à un service externe, ou l’entreprise refuse de dépendre d’un seul éditeur et de ses changements de prix. Les six usages qui suivent cochent au moins une case.
Trois cas. Le prototype : pour savoir en deux semaines si une idée tient, une API propriétaire évite de monter une infrastructure pour un projet qui n’existera peut-être plus. Le faible volume avec des données sans sensibilité : la facture d’API se compte en dizaines d’euros, le temps d’un ingénieur en milliers. Les tâches au plafond, agents autonomes sur des heures, raisonnement difficile, où les modèles propriétaires les plus récents gardent quelques points d’avance qui, là, se voient.
Un quatrième cas se déguise en question technique : personne dans l’entreprise pour surveiller et mettre à jour le modèle dans six mois. Ce n’est pas un argument contre l’open weight, c’est un argument pour le consommer chez un hébergeur plutôt que sur son propre serveur.
Trois tailles, trois machines. Les petits modèles, de 2 à 9 milliards de paramètres, tournent sur un ordinateur portable et suffisent pour classer, extraire des champs simples ou répondre court. Les modèles moyens, de 25 à 30 milliards, comme Qwen3.8-27B, Gemma 4 ou Mistral Small 3.2, tiennent dans une carte graphique de 24 Go en précision réduite et couvrent l’essentiel des usages d’entreprise. Les géants, de plusieurs centaines à plusieurs milliers de milliards de paramètres, se consomment par API chez un hébergeur : personne ne les gare dans une PME.
La règle pratique : choisissez le plus petit modèle qui réussit vos vingt cas de test, pas le plus gros que vous pouvez vous offrir. Un modèle moyen bien alimenté en documents pertinents bat un géant qui devine. Et la taille se paie deux fois, à l’achat de la machine et à chaque requête.
Quatre postes, dont un seul sur la facture. Le modèle lui-même est gratuit quand sa licence est libre, Apache 2.0 ou MIT. L’infrastructure se paie de trois façons : à la requête chez un hébergeur, de 1 à 15 dollars le million de tokens produits en septembre 2026 ; à l’heure pour un serveur GPU loué, à partir de 1,46 euro l’heure chez Scaleway pour une L40S, soit un peu plus de 1 000 euros par mois en continu ; ou à l’achat pour une machine chez vous. Le troisième poste, le temps d’équipe, est le plus lourd. Le quatrième, qualité et conformité, est celui qu’on oublie.
Sous licence libre, il ne coûte rien, ni à l’usage ni au nombre d’utilisateurs. Sous licence maison, lisez les conditions : seuils d’utilisateurs, mentions obligatoires, exclusions géographiques. Le premier article détaille le cas de Llama, interdit aux entreprises européennes dans sa dernière version.
Trois options, du plus simple au plus autonome. L’API chez un hébergeur, européen si vos données l’exigent, Scaleway par exemple, qui sert les grands modèles open weight depuis Paris : vous payez au token, sans machine à gérer. Le serveur GPU loué à l’heure, à partir de 1,46 euro pour une L40S et 2,86 euros pour une H100 chez le même hébergeur : coût fixe, données dans votre périmètre, mais quelqu’un doit l’administrer. La machine achetée, une station avec une ou deux cartes graphiques : quelques milliers d’euros une fois, pour les sites sans connexion ou les données qui ne sortent sous aucun prétexte.
C’est le poste qui n’apparaît sur aucune facture cloud et qui décide du budget. Un assistant documentaire sérieux, c’est quelques semaines d’un binôme, un développeur et une personne du métier, pour connecter les sources, écrire les consignes, tester sur des cas réels et corriger. Puis quelques heures par mois pour surveiller les réponses, mettre à jour les documents et le modèle. Chez un hébergeur, la moitié de ce temps disparaît. Sur votre propre serveur, il double.
Un modèle qui répond faux avec assurance coûte plus cher qu’un modèle qui ne répond pas. Prévoyez un jeu de cas de test, une relecture humaine des réponses sensibles et un suivi des usages. Et depuis le 2 août 2026, l’article 50 du règlement européen impose d’informer une personne qu’elle échange avec une IA : une ligne à ajouter à l’écran, à ne pas oublier au cahier des charges. Le RGPD, lui, s’applique comme avant à toute donnée personnelle qui passe par le modèle.
Comptez vos requêtes par jour et estimez leur longueur : un token vaut environ trois quarts de mot en français. Multipliez par les prix de trois options, une API propriétaire, un modèle open weight chez un hébergeur, un serveur GPU loué, puis ajoutez le temps d’équipe. Le résultat surprend souvent : à volume modeste, l’API la plus chère coûte moins qu’un serveur, et seule la confidentialité justifie le serveur. À fort volume, la hiérarchie s’inverse. Le simulateur ci-dessous fait le calcul avec vos nombres.
Pour estimer votre usage. Une personne qui s'appuie sur un assistant toute la journée envoie de 20 à 40 requêtes ; une équipe de dix, de 200 à 400. Une requête, c'est une question avec son contexte, quelques centaines de mots, et une réponse de 100 à 300 mots. Une automatisation compte une requête par document traité. Partez d'un scénario, puis ajustez.
9 000 requêtes par mois, soit environ 3,6 M tokens envoyés et 1,8 M reçus.
Vous payez des tokens au fournisseur du modèle (Anthropic, OpenAI, Google), qui le fait tourner chez lui. Rien à gérer ; vos données passent par ses serveurs.
Vous payez des tokens à un hébergeur, européen si vous voulez, qui fait tourner un modèle gratuit sur ses machines partagées. Rien à gérer ; le modèle ne coûte rien.
Vous payez des heures de machine, que le serveur travaille ou non, et vous y installez un modèle gratuit. Vos données restent chez vous ; quelqu’un doit l’administrer.
À 300 requêtes par jour, open weight chez un hébergeur est l'option la moins chère : 252 € par mois, soit 28 € pour 1 000 requêtes. Le serveur est compté allumé 220 h par mois, 1 machine pour ce volume. Le serveur loué ne passe jamais devant l'API dans cette plage de volumes.
| Option | Infrastructure | Équipe | Par mois | Pour 1 000 requêtes |
|---|---|---|---|---|
| API propriétaire | 23 € | 240 € | 263 € | 29 € |
| Open weight chez un hébergeur | 12 € | 240 € | 252 € | 28 € |
| Serveur GPU loué | 325 € | 960 € | 1 285 € | 143 € |
Le repère que tout le monde connaît : 10 abonnements individuels coûtent 200 € par mois. Ils servent une personne devant son écran ; ils ne traitent pas les demandes tout seuls, ne s'intègrent pas dans vos outils et n'offrent aucune garantie sur vos données. Les trois options ci-dessus, elles, font tourner un usage dans votre entreprise, sans limite de personnes.
Ordre de grandeur, pas un devis : les prix changent chaque trimestre, la capacité d'un serveur est une hypothèse à vérifier par un test de charge, et la qualité comme la conformité restent à évaluer sur vos propres cas.
Prenons un service client qui traite 500 demandes par jour ouvré. Chaque demande envoie au modèle environ 3 000 tokens, l’historique et les documents utiles, et en reçoit 500. Sur 22 jours, cela fait 33 millions de tokens en entrée et 5,5 millions en sortie par mois. Aux tarifs de septembre 2026 :
| Option | Tarif retenu | 500 demandes par jour | 5 000 demandes par jour |
|---|---|---|---|
| API propriétaire, gamme courante (Claude Sonnet 5) | 2 $ en entrée, 10 $ en sortie, par million de tokens | ≈ 120 $ par mois | ≈ 1 200 $ par mois |
| API propriétaire, haut de gamme (Claude Fable 5.1) | 10 $ et 50 $ | ≈ 600 $ par mois | ≈ 6 000 $ par mois |
| Open weight chez un hébergeur (classe GLM-5.2) | ≈ 1,40 $ et 4,40 $ | ≈ 70 $ par mois | ≈ 700 $ par mois |
| Open weight chez un hébergeur (classe DeepSeek V4) | ≈ 0,50 $ et 1 $ | ≈ 20 $ par mois | ≈ 220 $ par mois |
| Serveur GPU loué, modèle moyen (L40S, 24 h sur 24) | 1,46 € l’heure | ≈ 1 050 € par mois, fixe | ≈ 1 050 € par mois, fixe |
Lecture. À 500 demandes par jour, le serveur dédié coûte dix fois plus que l’API courante et presque le double de l’API la plus chère : on ne le choisit que pour garder les données chez soi. À 5 000 demandes, il devient moins cher que toute API propriétaire, et l’open weight chez un hébergeur reste l’option la plus économique si la confidentialité est acceptable. Dans tous les cas, ajoutez le temps d’équipe, qui pèse plus que la ligne cloud dès la première année. Les prix des API varient d’un mois à l’autre et baissent avec la mise en cache des entrées : refaites le calcul le jour où vous décidez, pas celui où vous lisez.
Sur les six usages du début, la différence de quelques points entre les modèles de tête et les bons modèles open weight ne se voit pas. Ce qui se voit, c’est la qualité des documents que vous donnez au modèle et la précision de vos consignes. Un modèle moyen nourri de vos procédures répond mieux à vos opérateurs qu’un géant qui n’a jamais vu votre entreprise.
D’où une méthode simple : prenez vingt demandes réelles, celles de la semaine dernière, et soumettez-les à deux ou trois modèles. Les personnes qui font ce travail aujourd’hui notent les réponses. En une journée, vous savez quel modèle et quelle taille conviennent, et souvent que le moins cher suffit.
Chez NATIVBIZ, ce calcul et ce test sont la première semaine de tout projet d’application métier qui embarque un modèle : un design sprint pour cadrer l’usage et la taille, puis un plan de tracking pour mesurer, une fois en production, ce que le modèle fait gagner et ce qu’il coûte vraiment.
