Un agent qui tourne sur votre serveur n’est pas moins cher parce que son code est gratuit. Il coûte autre chose : du temps, des compétences, de la vigilance. Deux factures, donc, et le choix se joue sur celle que votre organisation sait payer.
Choisir un agent IA open source plutôt qu’un service en ligne se décide sur trois lignes qui ne figurent sur aucune page tarifs : les données qui sortent de chez vous, la dépendance à un fournisseur qui peut changer ses règles du jour au lendemain, et le coût à l’usage qui grimpe exactement au rythme de votre succès. Le reste, les étoiles sur GitHub et la mode du moment, ne vous coûtera rien dans dix-huit mois. Ces trois lignes, si.
Une boucle, quatre briques, trois licences
Un agent ne se limite pas à répondre à une question. Il tourne en boucle : un modèle de langage reçoit un objectif, décide d’une action, appelle un outil (une recherche, une base, une API interne, un script), observe le résultat, et recommence jusqu’à un critère d’arrêt. Ce qui le distingue d’un simple prompt, c’est cette capacité à agir plusieurs fois de suite sans qu’on lui tienne la main.
Autour de cette boucle, il y a toujours quatre briques : le modèle, l’orchestration (qui gère les étapes, les erreurs, les reprises), les outils exposés à l’agent, et l’état persistant (mémoire, historique, traces). Dire d’un agent qu’il est open source ne dit rien de la brique concernée. C’est précisément là que se logent les mauvaises surprises.
Deux notions se confondent en permanence. Une licence libre au sens classique, MIT ou Apache 2.0, vous autorise à lire, modifier, redistribuer, exploiter commercialement. Les poids ouverts (open-weight) sont autre chose : un modèle téléchargeable, parfois sous licence restrictive, sans jamais donner accès aux données d’entraînement. Enfin le « source-available » n’est pas de l’open source : le code est visible, l’usage est encadré. Lisez la licence avant l’argumentaire.
L’ouverture ne se joue pas au même étage
Un framework d’orchestration peut porter une licence permissive et vous laisser malgré tout pieds et poings liés. LangGraph en donne un bon exemple : la bibliothèque est sous licence MIT, mais le serveur qui la fait tourner en production, langgraph-api, relève de l’Elastic License 2.0 et réclame une clé commerciale. Auditer le code, oui ; l’exploiter chez vous sans rien signer, pas tout à fait. Et si les appels de raisonnement partent vers une API propriétaire, vos données sortent quand même, et votre facture reste indexée sur le tarif d’un tiers. Le code ouvert n’a jamais fermé un tuyau.
L’inverse existe aussi : un modèle à poids ouverts servi par un client fermé, ou une interface libre qui n’accepte qu’un seul fournisseur. D’où l’intérêt des projets qui affichent explicitement leur indépendance de modèle. Hermes Agent, publié par Nous Research en février 2026 sous licence MIT, est de ceux-là : il se revendique déployable sur un VPS (un serveur virtuel loué à la demande) à quelques dollars comme sur un cluster de GPU, et branchable indifféremment sur un portail hébergé, un agrégateur, une API commerciale ou un endpoint maison. Ce découplage compte davantage que la popularité du projet.
Le contraste est net avec les kits publiés par les éditeurs de modèles : l’Agents SDK d’OpenAI est distribué sous licence MIT, l’Agent Development Kit de Google sous Apache 2.0, et tous deux restent taillés d’abord pour le modèle et le cloud de leur auteur. Licence permissive ne veut donc pas dire fournisseur interchangeable.
Un test simple pour situer un agent, quel que soit l’outil : si votre fournisseur de modèle coupait l’accès ce soir, qu’est-ce qui continuerait de tourner demain matin ?
- Les poids sont-ils téléchargeables et exécutables hors du fournisseur ?
- L’orchestration accepte-t-elle un autre modèle par simple changement de configuration ?
- Les prompts, les outils et l’état vivent-ils dans votre dépôt, ou dans la console d’un éditeur ?
- Les traces d’exécution sont-elles exportables dans un format que vous savez relire ?
Quatre « oui » et vous êtes portable. Un seul « non » sur les poids, et vous êtes locataire.
Données qui sortent, dépendance, coût à l’usage
Premièrement, les données qui sortent. Chaque appel vers une API tierce, c’est un transfert : le prompt, les documents joints, parfois les logs de la boucle entière. Dans un contexte de plus en plus normé, entre le règlement européen DORA sur la résilience opérationnelle des acteurs financiers, la résidence des données de santé et les clauses de souveraineté des marchés publics, cette sortie devient une question contractuelle avant d’être une question technique. Auto-héberger fait rentrer le flux dans votre périmètre. Attention au raccourci : héberger soi-même ne produit pas de la conformité, cela déplace la charge de la preuve sur vos épaules. Chiffrement, cloisonnement des accès, rétention des traces : c’est désormais votre travail.
Deuxièmement, la dépendance. Une condition d’utilisation se modifie plus vite qu’une architecture. L’écosystème en a eu une démonstration nette au printemps 2026 : OpenClaw, client agentique très populaire, a vu les abonnements grand public d’Anthropic cesser de couvrir le modèle qu’il exploitait, et ses utilisateurs ont dû basculer sur une facturation à l’usage ou sur leur propre clé API. Le code n’avait pas disparu, la licence n’avait pas changé : ce sont les conditions d’accès au modèle qui ont bougé. La dépendance ne se mesure donc pas en pages de contrat, mais en heures de travail nécessaires pour changer de fournisseur. Si personne dans l’équipe ne sait chiffrer ce délai, la réponse est probablement « beaucoup ».
Troisièmement, le coût à l’usage. Une API facture au token : coût marginal faible, croissance linéaire, aucun engagement. L’auto-hébergement inverse la courbe : investissement fixe (GPU réservé ou loué, stockage, supervision), coût marginal proche de zéro ensuite. Les comparaisons publiées sur les modèles à poids ouverts auto-hébergés annoncent une inférence jusqu’à 90 % moins chère que les API propriétaires équivalentes. L’écart existe, mais il n’a de sens qu’à taux d’occupation élevé : un GPU exploité à 20 % coûte plus cher que l’API qu’il devait remplacer.
Comptez donc le coût par tâche réussie plutôt que le coût par million de tokens. Un modèle deux fois moins cher qui échoue une fois sur trois et qu’il faut relancer finit par coûter davantage.
Les cas où l’auto-hébergement ne tient pas la charge
Il y a des situations où le calcul penche franchement de l’autre côté, et il vaut mieux les reconnaître tôt.
Le trafic irrégulier, d’abord : si votre charge fait des pointes de un à cinquante, vous dimensionnez pour la pointe et vous payez le vide le reste du temps. Payer à l’appel, c’est acheter cette élasticité, et elle vaut son prix.
Les tâches qui exigent le haut du panier, ensuite : raisonnement long, contexte très large, qualité de code. L’écart entre modèles ouverts et modèles de frontière se resserre sans disparaître, et il se rouvre à chaque génération. Sur ces usages précis, l’API reste souvent la bonne réponse.
Le coût humain, enfin, et c’est le plus sous-estimé. Un agent en production, cela veut dire des mises à jour de sécurité, une astreinte, de la supervision à construire, des évaluations à maintenir pour détecter les régressions. Une demi-personne mobilisée en permanence efface des dizaines de milliers d’euros d’économie d’API. Le calcul n’est pas faux, il est incomplet.
Garder la main sur les couches qui comptent
La bonne stratégie n’est presque jamais binaire. Elle consiste à garder la main sur les couches qui vous appartiennent et à louer celles qui bougent trop vite.
- Isolez l’appel au modèle derrière une interface unique dans votre code. Changer de fournisseur doit être une modification de configuration, jamais un chantier.
- Gardez prompts, définitions d’outils et schémas d’état versionnés dans votre dépôt. C’est votre actif, pas celui de l’éditeur.
- Mesurez avant d’optimiser : coût, latence et taux de réussite par tâche. Sans ces trois courbes, tout arbitrage relève de la conviction.
- Commencez en service géré sur les usages incertains, rapatriez ce qui devient stable, répétitif et volumineux. C’est là que l’auto-hébergement paie.
- Vérifiez la licence, la gouvernance du projet et la fréquence des contributions avant de bâtir dessus. Un projet à un seul mainteneur est une dette différée.
Un routage hybride règle beaucoup de cas : un modèle ouvert auto-hébergé pour le volume et les données sensibles, une API de pointe pour les 5 % de requêtes qui l’exigent réellement. Cela suppose de savoir classer ses requêtes, ce qui est un exercice de produit avant d’être un exercice d’infrastructure.
L’open source ne vous affranchit de rien : il déplace le point de contrôle. Vous échangez une facture prévisible et une dépendance contractuelle contre une charge d’exploitation et une liberté de manœuvre. Aux volumes faibles, l’échange est mauvais. Aux volumes stables, sur des données que vous n’avez pas le droit d’exporter, il devient évident. Reprenez donc l’inventaire de votre pile chaque trimestre : ce qui ne vous appartient toujours pas, et le temps qu’il faudrait pour vous en passer. Le jour où ce délai devient inchiffrable, la décision ne vous appartient déjà plus.
Questions frequentes
Un agent IA open source est-il gratuit ?
Le logiciel l’est, pas son exploitation. Il faut compter le calcul (GPU ou serveur), le stockage, la supervision et le temps d’ingénierie nécessaire pour maintenir l’agent en production.
Quelle différence entre open source et open weights ?
Une licence open source (MIT, Apache 2.0) porte sur le code et autorise lecture, modification et redistribution. Les open weights désignent des poids de modèle téléchargeables, parfois sous licence restrictive, sans accès aux données d’entraînement.
Auto-héberger un agent suffit-il à être conforme au RGPD ?
Non. L’auto-hébergement évite le transfert des données vers un tiers, mais la responsabilité du chiffrement, des accès, de la rétention des logs et de la documentation du traitement reste entièrement à la charge de l’organisation qui héberge.
À partir de quel volume l’auto-hébergement devient-il rentable ?
Quand la charge est suffisamment régulière pour maintenir un taux d’occupation élevé du matériel. Un GPU réservé et peu utilisé revient plus cher qu’une API facturée à l’appel : le point de bascule dépend du volume stable, pas du volume total.
Comment éviter d’être enfermé par un fournisseur de modèle ?
En isolant l’appel au modèle derrière une interface unique, en gardant prompts, outils et état versionnés dans son propre dépôt, et en testant régulièrement le basculement vers un autre modèle pour mesurer le délai réel de migration.
