Développez intelligemment votre business en optimisant vos coûts
On en discute
Le premier article posait la différence entre open weight et open source. En comité de direction, les deux questions suivantes tombent dans l’ordre : à quoi ça sert chez nous, et combien ça coûte ? 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 exemple calculé jusqu’au bout.
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.
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 usine.
D’où la seule méthode qui vaille : vingt cas réels, tirés de vos demandes de la semaine dernière, soumis à deux ou trois modèles candidats, notés par les personnes qui font le travail aujourd’hui. Une journée suffit. Elle vous dit quel modèle, quelle taille, et souvent que le moins cher fait l’affaire.
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.
