La question revient dans presque tous les projets, et elle est presque toujours mal posée. « On prend un modèle open source ou une API ? » sous-entend un choix idéologique, alors qu'il s'agit d'un calcul. Un calcul qui dépend de votre volume, de vos données, de vos compétences internes, et qui donne des réponses différentes selon l'usage, parfois dans la même entreprise.
Nous prenons ici le point de vue d'une organisation qui n'a pas d'équipe d'apprentissage automatique : quelques développeurs, un budget cadré, et l'envie légitime de ne pas construire une infrastructure dont personne ne saura s'occuper dans six mois. Cinq axes suffisent à trancher.
Une précision de vocabulaire avant de commencer, parce qu'elle a des conséquences pratiques. Beaucoup de modèles présentés comme ouverts sont en réalité des modèles à poids téléchargeables, distribués sous une licence qui restreint certains usages. C'est très différent d'un modèle réellement libre au sens des définitions établies. Lisez la licence avant de bâtir un produit dessus : elle peut interdire l'usage commercial au-delà d'un seuil, ou l'entraînement d'autres modèles.
Axe 1 : le coût complet, pas le prix affiché
Le prix d'une API se lit en euros par million de jetons traités. Le prix d'un modèle auto-hébergé se lit en euros par heure de machine, plus le temps humain. Comparer les deux exige de ramener tout au coût par requête, puis d'ajouter ce que la ligne de facture ne montre pas.
Prenons un exemple. Une application interne traite 20 000 requêtes par mois, avec en moyenne 2 000 jetons en entrée et 500 en sortie, soit environ 50 millions de jetons mensuels. Avec une API de milieu de gamme, la facture se situe dans une fourchette de quelques centaines d'euros par mois, et elle est parfaitement prévisible. Sans aucune infrastructure à maintenir.
Côté auto-hébergement, il faut une machine avec accélérateur graphique. La location d'un accélérateur de génération courante se compte en euros par heure : en fonctionnement continu, on arrive vite à un montant mensuel du même ordre, voire supérieur, sans compter le temps d'installation, de mise à jour et de surveillance. À ce volume, l'API gagne largement.
Le calcul s'inverse quand le volume monte, parce que l'API croît linéairement et la machine non. Une machine louée à plein temps traite bien plus que 50 millions de jetons par mois : au-delà de quelques centaines de millions de jetons mensuels et avec un trafic régulier, l'auto-hébergement redevient compétitif. Le seuil exact dépend des tarifs du moment, mais l'ordre de grandeur est robuste : la bascule ne se joue pas à quelques milliers de requêtes, elle se joue à un ou deux ordres de grandeur au-dessus.
| Poste de coût | API propriétaire | Modèle auto-hébergé |
|---|---|---|
| Consommation | Proportionnelle à l'usage, nulle à l'arrêt | Fixe, payée même la nuit sauf extinction automatique |
| Installation | Quelques heures | Plusieurs jours à plusieurs semaines |
| Exploitation | Incluse | Mises à jour, surveillance, capacité, astreinte |
| Pic de charge | Absorbé par le fournisseur | À dimensionner et à payer d'avance |
| Compétence requise | Développement applicatif | Développement, système, et un peu d'inférence |
Axe 2 : la confidentialité, argument fort mais mal utilisé
C'est le motif le plus souvent avancé pour l'auto-hébergement, et il est légitime : les données ne sortent pas. Pour un traitement portant sur des dossiers médicaux, des données de défense ou des secrets industriels caractérisés, l'argument peut suffire à lui seul.
Il est en revanche largement surinvoqué. Beaucoup d'entreprises réclament un modèle local pour des données qu'elles hébergent déjà chez un fournisseur de messagerie ou de stockage étranger. La cohérence commande d'appliquer le même raisonnement partout : ce qui compte est la classification réelle de la donnée, la localisation du traitement et les engagements contractuels obtenus, pas le sentiment de propriété que procure une machine dans un placard. Les critères applicables sont ceux que nous détaillons dans notre article sur le RGPD appliqué à l'IA en entreprise.
Notons aussi une voie intermédiaire souvent ignorée : faire tourner un modèle ouvert chez un hébergeur européen, en infrastructure dédiée. On conserve la maîtrise du modèle et une localisation choisie, sans assumer l'exploitation matérielle. C'est le sujet de notre article sur l'hébergement d'une IA en France.
Axe 3 : la qualité, à mesurer sur vos tâches
Sur les tâches générales et le raisonnement complexe, les meilleurs modèles propriétaires conservent une avance. Sur les tâches d'entreprise les plus courantes, cette avance est souvent invisible : classer un courriel, extraire cinq champs d'une facture, résumer un compte rendu, reformuler un texte. Un modèle ouvert de taille moyenne y atteint fréquemment un niveau suffisant, et un petit modèle exécuté localement suffit parfois sur des tâches bien cadrées.
La seule mesure qui compte est la vôtre. Constituez cinquante à cent cas réels avec la réponse attendue, faites tourner deux ou trois candidats, comptez. Cette demi-journée de travail vaut tous les classements publics, dont l'interprétation demande d'ailleurs beaucoup de précautions.
Un point pratique : la qualité dépend aussi de la langue. Sur du français métier, avec du vocabulaire administratif ou juridique, les écarts entre modèles sont plus marqués que sur l'anglais. Testez en français, sur vos documents.
Axe 4 : la dépendance, dans les deux sens
L'API crée une dépendance évidente : tarifs, disponibilité, conditions d'utilisation et durée de vie des versions échappent à votre contrôle. Un modèle retiré du catalogue ou une version dépréciée impose une migration que vous n'avez pas planifiée.
Le modèle ouvert crée une dépendance moins visible mais réelle : celle envers les personnes qui savent le faire tourner. Si une seule personne maîtrise l'installation, son départ vous laisse un système que plus personne n'ose mettre à jour. Cette dépendance-là ne se règle pas par un contrat.
Deux mesures réduisent le risque quel que soit le choix : garder la couche d'appel au modèle derrière une interface interne unique, pour pouvoir changer de fournisseur sans réécrire l'application, et documenter le passage à un modèle de secours. Une entreprise capable de basculer d'un fournisseur à l'autre en une journée a résolu la question de la dépendance mieux que par n'importe quel débat de principe.
Axe 5 : la charge d'exploitation, le coût que personne ne budgète
C'est l'axe décisif pour une organisation sans équipe dédiée. Faire tourner un modèle en production suppose de surveiller la charge, de gérer la file d'attente, de suivre la consommation mémoire, d'appliquer les correctifs, de tester chaque montée de version et de disposer de quelqu'un quand le service tombe un vendredi soir.
Compté honnêtement, cela représente une fraction non négligeable d'un poste. Beaucoup de projets d'auto-hébergement sont rentables sur le papier et déficitaires dans les faits, simplement parce que ce temps n'a jamais figuré dans le calcul.
Modèle open source ou API : la règle de décision
- Commencez par une API pour tout nouvel usage. Vous validez la valeur avant d'investir, et vous obtenez en quelques jours une mesure de volume réel.
- Isolez l'appel au modèle derrière votre propre interface dès le premier jour. C'est trois heures de travail, et cela conditionne toute liberté ultérieure.
- Réexaminez au bout de trois mois avec les vrais chiffres : volume mensuel, coût, sensibilité des données, exigence de latence.
- Basculez vers un modèle ouvert si deux conditions au moins sont réunies : un volume important et régulier, une contrainte de confidentialité documentée, ou une compétence d'exploitation déjà présente en interne.
Le choix entre un modèle open source ou une API n'est donc pas un choix de camp, c'est une décision datée qui se réévalue. La plupart des organisations finissent d'ailleurs avec les deux : une API pour les usages variés et à faible volume, un modèle ouvert pour la tâche unique, massive et bien cadrée qui représente l'essentiel de la facture.
Laisser un commentaire