Le choix entre un LLM à poids ouverts et un service propriétaire dépend de la tâche, des données, de la qualité attendue et de votre capacité d’exploitation. Il n’existe pas de pourcentage d’économie valable pour tous les projets. Comparez un service complet, avec ses contrôles et sa maintenance, sur les mêmes cas d’usage.
Une bonne décision produit trois éléments : une évaluation reproductible, un coût d’exploitation explicite et un plan de remplacement du modèle. Le nom du fournisseur devient alors une conséquence de ces critères.
Distinguer les poids ouverts, la licence et le service
Pouvoir télécharger des poids ne signifie pas disposer de tous les éléments d’un système open source. La définition de l’Open Source Initiative inclut des exigences sur les libertés d’utilisation et de modification, les informations relatives aux données, le code et les paramètres. Il faut donc lire la licence et les éléments disponibles pour la version exacte considérée. Définition Open Source AI de l’OSI.
Un modèle peut être utilisé via plusieurs modes d’hébergement. À l’inverse, un service managé peut proposer des modèles de familles différentes. Séparez donc trois décisions : le modèle, le lieu d’exécution et le contrat d’exploitation.
| Option | Ce que l’équipe doit examiner | Conséquence opérationnelle |
|---|---|---|
| API managée | Traitement des données, limites de service, versions et prix | Une partie de l’exploitation est assurée par le fournisseur |
| Modèle déployé dans un environnement dédié | Licence, infrastructure, sécurité et charge | L’équipe choisit davantage de paramètres et assume davantage d’exploitation |
| Combinaison de plusieurs modèles | Routage, droits d’accès, évaluations et observabilité | La flexibilité augmente avec la complexité du système |
La documentation des fiches de modèles Hugging Face décrit les informations qu’une model card peut fournir : usages, limites, données et résultats d’évaluation. Une fiche constitue un point de départ à vérifier sur vos propres tâches.
Comparer sur un jeu de cas métier
Préparez les entrées que le futur système recevra, les réponses ou actions attendues et les critères qui permettent de juger le résultat. Incluez des cas difficiles : information absente, demande ambiguë, document contradictoire, droits insuffisants et dépassement du périmètre.
Conservez les versions du modèle, des instructions et des sources. Testez les solutions dans des conditions comparables : même accès aux outils, même jeu documentaire et même budget de temps. Un modèle peu coûteux peut nécessiter davantage de tentatives ou de relecture ; cette différence doit apparaître dans l’évaluation.
Pour un assistant documentaire, examinez les citations et la capacité à reconnaître qu’une réponse n’est pas disponible. Pour une extraction structurée, mesurez les champs corrects et les erreurs qui passent les contrôles. Pour un agent, observez aussi les actions exécutées et la possibilité de les interrompre.
Calculer le coût du service rendu
Le coût à comparer est celui d’une tâche traitée avec le niveau de qualité requis. Un prix au token seul ne couvre pas les documents à préparer, la recherche, les appels d’outils, les reprises ni le temps de validation.
Une feuille de calcul peut distinguer :
- Les ressources de calcul ou appels facturés.
- Le stockage, l’indexation et les transferts nécessaires.
- La mise en œuvre des accès, de l’observabilité et des sauvegardes.
- L’exploitation, les mises à jour et les nouvelles évaluations.
- La correction ou la validation humaine des résultats.
Avec un hébergement dédié, partez d’un volume et d’une concurrence de requêtes définis. Avec une API, conservez la date du tarif et les conditions utilisées pour le calcul. Présentez plusieurs scénarios d’usage au lieu d’un coût unique supposé permanent.
Définir le périmètre privé
Le mot privé doit correspondre à un périmètre documenté. Précisez où transitent les prompts, les documents, les réponses, les journaux et les sauvegardes. Identifiez les personnes et services qui peuvent y accéder. Une installation locale ne remplace pas une gestion des droits et des mises à jour.
Les risques d’une application IA dépassent le modèle lui-même. L’OWASP GenAI Security Project rassemble des travaux sur ces risques, notamment ceux qui concernent les entrées, les sorties et les actions autorisées. Utilisez-les pour préparer des scénarios de test correspondant à votre architecture.
Prévoir l’exploitation et la réversibilité
Demandez qui traite les incidents, comment une version est remplacée et ce qu’il faut refaire lorsqu’un modèle change. Conservez votre jeu d’évaluation et la description des outils indépendamment du fournisseur. L’architecture doit permettre de comparer une nouvelle option avant de lui transférer un trafic réel.
L’approche hybride n’est utile que si elle résout une contrainte identifiée : confidentialité, qualité sur une tâche ou exploitation. Elle demande ses propres tests, notamment pour éviter qu’un routage envoie une donnée vers un environnement non autorisé.
Préparer une décision pour votre entreprise
Réunissez un échantillon de tâches, les règles d’accès et une hypothèse de volume. Pour un LLM privé en entreprise, le cadrage doit transformer ces éléments en architectures comparables et en critères de recette. Le guide sur les LLM et données privées développe le volet documentaire.
À RETENIR
- Lire la licence de la version exacte du modèle.
- Distinguer modèle, hébergement et contrat d’exploitation.
- Comparer les résultats sur des tâches représentatives.
- Intégrer maintenance et validation humaine dans les coûts.
LE CONSEIL À APPLIQUER Avant de demander un comparatif de fournisseurs, écrivez les critères d’acceptation d’une tâche et rassemblez ses exceptions. Cette base permet d’écarter une solution qui répond bien à une démonstration mais ne satisfait pas les exigences de votre service.