Agent IA open source: lire la licence avant le README

« Open source » ne dit pas toujours ce que tu crois

Le terme a une définition précise, tenue par l'Open Source Initiative, et elle porte sur ce que la licence autorise: utiliser le logiciel pour n'importe quel usage, y compris commercial, le modifier, et le redistribuer. Une licence qui restreint l'un de ces trois points n'est pas open source, quelle que soit la visibilité du code.

La nuance a l'air théorique jusqu'au jour où elle décide de ce que tu as le droit de facturer. Prenons le cas le plus courant en automatisation française: n8n. Le dépôt affiche « n8n is fair-code distributed under the Sustainable Use License and n8n Enterprise License ». Code visible, auto-hébergeable, extensible. Et pas approuvé par l'OSI, parce que le modèle fair-code se place volontairement entre l'open source et le propriétaire: la source reste lisible, certains usages commerciaux ne sont pas ouverts.

Ça ne fait pas de n8n un mauvais choix, et une PME qui l'auto-héberge pour ses propres flux ne rencontrera probablement jamais la limite. Mais une agence qui revend l'hébergement de n8n à ses clients pose une question de licence, pas de technique. C'est la première chose à lire, avant les fonctionnalités.

Le réflexe qui évite l'essentiel des surprises: ouvrir le fichier de licence du dépôt et chercher le nom exact. MIT et Apache 2.0 ne posent aucune question. Un nom que tu ne reconnais pas, avec les mots « sustainable », « fair », « business source » ou « commons clause » dedans, mérite dix minutes de lecture.

Quatre projets, relevés à la source

Ce tableau ne classe pas, il situe. Les licences ont été lues sur les dépôts eux-mêmes le 3 août 2026, parce que c'est exactement le genre d'information qu'on recopie de mémoire et qui a changé entre-temps.

Trois des quatre sont sous MIT, donc sans question à se poser. Le quatrième est le seul du lot qui ne soit pas open source au sens de l'OSI, et c'est aussi celui que le marché français cite le plus souvent comme tel.

Une deuxième colonne mérite attention, celle de l'offre payante. Un projet MIT adossé à un produit commercial n'est pas suspect, c'est le modèle économique le plus sain du secteur. Ce qu'il faut regarder est ailleurs: quelles fonctions vivent du côté payant, et est-ce que celles dont tu as besoin en font partie. L'observabilité et la gouvernance, chez LangGraph comme chez CrewAI, sont du côté produit. Sur Hermes Agent il n'y a pas de côté produit du tout, ce qui veut dire que ces briques-là, quelqu'un doit les construire.

Divulgation, puisque le tableau ci-dessus contient un projet que nous déployons: kengdev vend l'installation et l'exploitation de Hermes Agent sous le nom Hermès. Le logiciel est gratuit et téléchargeable, et une équipe avec des ops n'a aucune raison de nous payer pour ça.

Le coût réel n'est pas dans la licence

Une licence à zéro euro déplace la facture, elle ne la supprime pas. Quatre lignes la composent, et la première pèse plus que les trois autres réunies dès que l'agent tourne vraiment.

• Les tokens. Un agent autonome consomme sans que personne regarde. Un ordonnanceur qui déclenche une tâche toutes les heures produit une facture pendant que tu dors, et c'est la ligne qui explique la plupart des mauvaises surprises du premier mois.
• L'hébergement. Modeste dans l'absolu, cinq à vingt euros par mois pour un usage personnel, davantage dès qu'il faut de la disponibilité. Sur les architectures qui hibernent entre les sessions, le coût suit l'usage au lieu de suivre le calendrier.
• L'exploitation. Mises à jour, secrets, sauvegardes, surveillance. C'est du temps humain, et c'est la ligne que les comparatifs oublient parce qu'elle ne figure sur aucune grille tarifaire.
• La reprise après incident. Un agent qui écrit dans tes outils métier peut se tromper. Ce que ça coûte de revenir en arrière dépend entièrement de ce que tu as posé avant, pas du projet que tu as choisi.

Ces quatre lignes existent quelle que soit la licence. C'est pour ça que la question « combien ça coûte » n'a pas de réponse tant qu'on n'a pas dit ce que l'agent fait, à quelle fréquence, et qui le répare.

Choisir selon ce que tu as déjà

La question utile n'est pas quel projet est le meilleur, elle est lequel correspond à l'équipe et au besoin. Voici la grille qu'on applique en cadrage.

La quatrième ligne est celle qui coûte le plus cher quand on la découvre tard, parce qu'elle se règle en amont du contrat et pas après.

La dernière n'est pas un argument commercial déguisé. Un agent qui écrit dans des outils métier sans personne pour surveiller ses actions est un incident en attente, que tu l'aies déployé toi-même ou fait déployer.

Trois pièges de lecture

Le nombre d'étoiles ne dit rien de la maintenance. Un dépôt à cent mille étoiles peut avoir trois commits sur les six derniers mois, et un dépôt à deux mille peut bouger toutes les semaines. Regarde la date du dernier commit et le rythme des versions, pas le compteur social.

Un projet qui bouge vite coûte à suivre. C'est une qualité et une charge en même temps. Sur un dépôt qui publie chaque semaine, la mise à jour devient une tâche récurrente et pas un événement, et il faut décider tout de suite qui s'en occupe.

« Auto-hébergeable » et « open source » ne sont pas synonymes. Beaucoup de projets source-available sont parfaitement auto-hébergeables tout en restreignant certains usages commerciaux. Les deux propriétés se vérifient séparément, et c'est la seconde qui décide de ce que tu peux facturer.