Modèles open source ou fermés pour vos agents ?

Choisissez un modèle ouvert si vous devez maîtriser son hébergement, conserver ses fichiers ou adapter son fonctionnement, et disposez des moyens de l’exploiter. Un modèle fermé accessible par API convient lorsque vous privilégiez une infrastructure gérée par un fournisseur, sous réserve de conditions acceptables pour vos données. Pour un agent, départagez surtout les solutions sur la réussite des tâches, le coût complet et les permissions nécessaires. Pour le même arbitrage côté logiciel d’agent, voir agent IA open source ou propriétaire ; pour un éditeur qui mêle les deux, voir Mistral AI.

LLM open source : distinguer ouverture et accès aux poids

L’expression llm open source recouvre des situations différentes. Un modèle peut proposer ses fichiers à télécharger sans publier le code d’entraînement ni permettre tous les usages. Les poids ouverts désignent l’accès aux paramètres appris ; ils ne garantissent ni une licence libre ni la possibilité de reproduire l’entraînement.

La définition de l’IA open source de l’Open Source Initiative exige des libertés d’utilisation, d’étude, de modification et de partage. Elle demande aussi les paramètres, le code nécessaire et des informations suffisamment détaillées sur les données d’entraînement. Publier seulement les poids ne satisfait donc pas automatiquement cette définition.

Avant de retenir un modèle, examinez la licence de sa publication exacte : usage commercial, modification, redistribution, obligations d’attribution et restrictions éventuelles. Vérifiez séparément les conditions du modèle, du logiciel qui l’exécute et du service qui l’héberge. Une interface libre peut appeler un modèle fermé ; un modèle ouvert peut être servi par une infrastructure propriétaire.

Enfin, ouvert et local ne sont pas synonymes. Vous pouvez louer un service distant exécutant des poids ouverts. À l’inverse, télécharger un modèle ne signifie pas que votre ordinateur peut l’exécuter dans des conditions acceptables. Les fiches des modèles de langage permettent de repérer les candidats ; la licence et les conditions d’exploitation restent à lire à la source.

Comparer aussi le mode d’hébergement

Le choix comporte deux axes : ce que vous pouvez faire du modèle et qui fait fonctionner les machines. Comparer une API fermée à un modèle ouvert auto-hébergé mélange ces deux décisions. Une offre hébergée à poids ouverts constitue une option intermédiaire.

Critère	Modèle fermé par API	Poids ouverts chez un hébergeur	Poids ouverts auto-hébergés
Exploitation des machines	Fournisseur	Hébergeur	Votre organisation
Accès aux paramètres	Généralement absent	Disponible selon la publication	Disponible selon la publication
Parcours des données	Infrastructure du fournisseur	Infrastructure de l’hébergeur	Infrastructure que vous configurez
Adaptation des poids	Selon l’offre	Selon l’offre et la licence	Selon la licence et vos moyens
Dépenses à suivre	Usage et services associés	Usage ou capacité réservée	Matériel, énergie, exploitation
Continuité	Dépend du service	Dépend du service et des fichiers disponibles	Dépend de vos capacités d’exploitation

L’hébergement géré ne supprime pas vos responsabilités : vous configurez toujours les accès, les outils et les règles de l’agent. L’auto-hébergement vous donne davantage de contrôle sur le déploiement, mais vous confie aussi la disponibilité, les mises à jour et la surveillance.

La documentation de configuration des points de terminaison de Hugging Face illustre cette distinction : elle prévoit notamment des choix de matériel, d’authentification, de réseau et d’ajustement de capacité. Ces paramètres décrivent le service d’exécution, indépendamment du degré d’ouverture des poids.

Pour préparer un déploiement sur votre matériel, le guide des LLM en local détaille les contraintes à examiner. Commencez par votre charge réelle : documents longs, utilisateurs simultanés et délai acceptable.

Pour un agent, mesurer les actions plutôt que la conversation

Un modèle qui rédige correctement peut échouer lorsqu’il doit sélectionner un outil, renseigner ses arguments ou reprendre après une erreur. La qualité de l’appel d’outils compte donc autant que celle des réponses. Le statut ouvert ou fermé ne donne aucune garantie sur ce point.

Construisez un jeu de tâches représentatif de votre usage. Pour un agent documentaire, vérifiez la recherche des bonnes pièces, la fidélité des réponses et le refus de conclure lorsque l’information manque. Pour un agent qui modifie des fichiers, examinez le résultat obtenu et les changements indésirables.

Observez également les trajectoires : outil inutile, boucle répétitive, erreur ignorée, validation humaine contournée. Une tâche réussie après de nombreuses reprises peut rester trop lente ou trop chère pour votre activité.

Le guide d’Anthropic sur l’évaluation des agents distingue notamment les vérifications par code, par modèle et par humain. Il souligne l’intérêt d’évaluer le résultat ainsi que les traces d’exécution. Cette méthode s’applique à une comparaison entre modèles ouverts et fermés.

Les résultats du Labo des benchmarks servent à présélectionner des candidats. L’article Comprendre les classements de modèles aide à interpréter leurs limites. Pour décider, rejouez vos propres tâches avec le modèle et la configuration que vous comptez réellement déployer.

Calculer le coût par tâche réussie

Un téléchargement gratuit n’équivaut pas à une exploitation gratuite. En auto-hébergement, comptez la capacité disponible, son utilisation effective, le stockage, la surveillance et le temps consacré aux incidents. Une machine peu sollicitée représente une dépense même lorsque votre agent ne travaille pas.

Une API transforme une partie de ces charges en dépenses liées à l’usage. Cependant, une tâche agentique peut multiplier les appels, transmettre un historique croissant et recommencer des étapes. Le tarif affiché pour les tokens ne suffit donc pas à prédire la facture.

Comparez les solutions sur un même périmètre :

• les tâches terminées correctement et acceptées ;
• les appels, reprises et échecs consommant des ressources ;
• les outils externes éventuellement facturés ;
• le temps humain de contrôle et de correction ;
• la capacité nécessaire pendant les périodes chargées.

Le coût par tâche réussie rapporte ces dépenses aux résultats utiles. Un modèle moins cher à chaque appel peut devenir plus coûteux s’il exige davantage d’essais ou de corrections. Un modèle plus lent peut aussi empêcher de respecter le délai attendu.

Le calculateur de prix LLM aide à estimer la composante API. Pour l’auto-hébergement, établissez un budget comparable incluant l’exploitation. N’affirmez pas qu’un volume donné rend systématiquement le local rentable : le seuil dépend du modèle, du matériel, de la concurrence entre requêtes et de votre organisation.

Confidentialité : suivre tout le parcours des données

L’ouverture des poids ne dit pas où partent vos documents. Un modèle ouvert exécuté chez un prestataire reçoit les données que vous lui transmettez. Un modèle local peut rester dans votre infrastructure, tandis que son agent envoie ensuite des extraits à une recherche web ou à un outil distant.

Dessinez le parcours complet : entrée utilisateur, préparation des documents, modèle, outils, journaux et sauvegardes. Identifiez les destinataires de chaque contenu et les accès administratifs possibles. Examinez les engagements de conservation et d’utilisation des données pour chaque service concerné.

La documentation de sécurité des points de terminaison de Hugging Face distingue par exemple les charges utiles des journaux et décrit plusieurs modalités d’accès. Cet exemple montre pourquoi une déclaration générale sur la confidentialité ne remplace pas la lecture des conditions du service choisi.

L’article sur les données des agents IA et le RGPD approfondit cette analyse. Pour votre choix technique, formulez d’abord des exigences concrètes : catégories de données autorisées, destinataires acceptables, accès restreints et procédure d’effacement à vérifier.

Enfin, aucun mode d’hébergement ne dispense de limiter les permissions. Un agent local peut supprimer un fichier ou transmettre un secret si ses outils le permettent. Gardez les validations sensibles dans le programme qui exécute les actions, plutôt que dans les seules instructions adressées au modèle.

Choisir une architecture que vous pourrez maintenir

Pour un premier déploiement sans équipe d’infrastructure, une API gérée peut réduire le travail d’exploitation. Ce choix reste conditionné par vos exigences de confidentialité, de disponibilité et de budget. Prévoyez la conduite à tenir si le service devient indisponible ou si ses conditions changent.

L’auto-hébergement mérite d’être étudié lorsque la maîtrise du déploiement constitue une exigence explicite. Désignez alors une personne responsable des mises à jour, des incidents et des évaluations après changement. Posséder les fichiers permet de conserver un modèle ; cela ne garantit pas de pouvoir maintenir durablement son service.

Une architecture hybride peut réserver certaines tâches à un modèle local et d’autres à une API. Toutefois, le passage vers le service distant doit respecter vos règles de données. Une panne locale ne doit pas déclencher automatiquement l’envoi de documents confidentiels vers une destination non autorisée.

Anthropic présente le routage entre traitements spécialisés comme un schéma d’architecture possible. Son intérêt doit être mesuré : ajouter une décision de routage apporte aussi des erreurs potentielles et du travail de maintenance. Gardez cette complexité seulement si elle améliore vos résultats.

Le guide pour choisir un modèle de langage complète cette démarche. Pour une confrontation entre candidats précis, utilisez les comparatifs de modèles : ce guide traite des critères de décision communs.

À retenir

• Distinguez licence, accès aux poids et lieu d’exécution avant de comparer les offres.
• Évaluez l’agent sur des tâches complètes, avec ses outils, ses erreurs et ses validations.
• Comparez le coût des résultats acceptés, en intégrant les reprises et l’exploitation.
• Choisissez une architecture dont vous pouvez vérifier le parcours des données et assurer la maintenance.

Questions fréquentes

Un LLM open source fonctionne-t-il sans Internet ?

Il peut fonctionner hors ligne si les fichiers nécessaires sont disponibles sur la machine et si son environnement le permet. Toutefois, un agent qui utilise une recherche web ou un logiciel distant aura toujours besoin du réseau pour ces actions. Vérifiez séparément les connexions du modèle et celles des outils.

Peut-on utiliser commercialement un modèle à poids ouverts ?

L'accès aux fichiers ne suffit pas à déterminer les droits commerciaux. Consultez la licence de la publication exacte, ses éventuelles restrictions et les obligations associées à une redistribution. La licence du logiciel qui exécute le modèle ne remplace pas celle des poids.

Faut-il entraîner son propre modèle pour avoir un agent local ?

Non : vous pouvez exécuter un modèle déjà entraîné et lui fournir des instructions ainsi que des outils. Un entraînement supplémentaire répond à un besoin distinct, qui doit être évalué après avoir vérifié les limites du modèle existant. Il ne constitue pas un préalable à l'auto-hébergement.

Peut-on changer de modèle sans reconstruire son agent ?

Une couche d'accès commune peut limiter les modifications du programme. Elle ne garantit pas un comportement identique : formats des appels, gestion du contexte et réactions aux erreurs doivent être revérifiés. Conservez des tests de référence pour décider si le remplacement est acceptable.