IA open source entreprise : choisir entre open source et propriétaire

Open source, open weights, propriétaire : de quoi parle-t-on exactement ?

Un modèle open weight, un modèle dit open source et un modèle propriétaire se distinguent par ce que l'éditeur remet à l'entreprise : le modèle lui-même, ses recettes d'entraînement, ou seulement un accès par API.

Open weight : le modèle se télécharge

Un modèle open weight est téléchargeable et exécutable sur une infrastructure personnelle ou cloud [35]. Concrètement, l'entreprise peut l'installer sur ses propres serveurs et l'utiliser sans passer par l'API d'un fournisseur externe [34].

Open source : les pondérations, et souvent les recettes

Les modèles dits open source fournissent leurs pondérations et, généralement, leurs recettes d'entraînement [24]. Cette ouverture rend possibles l'auto-hébergement et une personnalisation poussée [24]. Meta, avec Llama, et Mistral AI, avec Mistral 7B et Mixtral, se revendiquent de cette catégorie [37].

Propriétaire : un seul éditeur garde la main

Un modèle propriétaire est contrôlé par une seule entreprise. Il est accessible généralement via une API, sans que l'utilisateur puisse voir ou modifier le code sous-jacent [23]. La littérature juridique parle aussi de modèles « fermés » ou propriétaires [9].

Deux précautions de lecture

• Les exemples de la source [24] sont datés. Elle cite Llama 3, Mistral 7B et Qwen2 côté ouvert, GPT-4o et Claude 3.5 côté propriétaire [24]. Ils illustrent les catégories, pas l'état actuel de l'offre.
• L'étiquette « open source » est une revendication d'éditeur [37], et l'ouverture réelle varie d'un modèle à l'autre. La section consacrée aux licences détaille ce point.

Quelles sont les différences de fond entre les deux familles ?

Les deux familles diffèrent par ce que l'entreprise peut voir, modifier et héberger : le propriétaire s'utilise comme un service prêt à l'emploi, l'open source se déploie et s'adapte. Un modèle open source (Mistral 7B, Llama 3, Qwen2 par exemple) fournit ses pondérations, et généralement ses recettes d'entraînement, en libre accès. Les modèles propriétaires (GPT-4o, Claude, Gemini) sont proposés sous forme d'API ou de SaaS [24].

Une lecture à nuancer

Plusieurs des sources de ce tableau sont des blogs d'agences ou d'éditeurs, pas des textes institutionnels ni des travaux de recherche. Leurs descriptions sont cohérentes entre elles, mais elles ne reposent sur aucune mesure. Deux cases restent vides faute d'information fiable : la standardisation côté open source et le support côté open source. Ces points se vérifient auprès du fournisseur ou de l'hébergeur retenu.

Ces différences structurent les sections suivantes : le coût, la protection des données et la dépendance au fournisseur découlent de l'endroit où tourne le modèle et de ce que l'on peut en modifier. Oupi permet d'utiliser les deux familles dans le même outil, ce qui évite de trancher a priori entre elles (voir le produit).

Les modèles open weights rattrapent-ils les modèles propriétaires en performance ?

Oui, l'écart se réduit, mais le dossier ne permet pas de conclure à une équivalence générale entre modèles open weights et modèles propriétaires. Trois constats sont établis.

• Le niveau atteint : des modèles open source comme Llama-3 de Meta atteignent l'état de l'art fixé par les modèles propriétaires [1].
• Le poids sur le marché : l'essor des modèles open source est un facteur important du marché des IA génératives [9].
• L'offre : des acteurs chinois rendent leurs modèles plus accessibles, parfois jusqu'à l'open source [3].

Des modèles que l'on peut héberger soi-même

Llama (Meta) et Mistral comptent parmi les modèles les plus utilisés de la catégorie que l'on peut installer sur ses propres serveurs, sans passer par l'API d'un fournisseur externe [34]. Meta avec Llama, et Mistral AI avec Mistral 7B et Mixtral, se revendiquent comme proposant des modèles open source [37]. Le terme est discuté : la section 1 distingue open source et open weights, et la section 6 traite des licences.

Ce que le dossier ne dit pas

L'affirmation sur Llama-3 [1] est un constat qualitatif. Le dossier ne contient aucun benchmark comparatif chiffré. Il ne permet donc pas de dire, tâche par tâche (rédaction, extraction, code, français), quel modèle l'emporte ni de quelle marge. « Atteindre l'état de l'art » ne signifie pas être équivalent partout, et un modèle précis peut rester en retrait sur un cas d'usage précis.

La conséquence pratique : tester sur ses propres cas

La seule démarche défendable consiste à évaluer les candidats des deux familles sur ses propres données. Un protocole minimal tient en quelques points :

1. constituer un jeu de requêtes réelles et représentatives, dans la langue de travail ;
2. soumettre les mêmes requêtes à un modèle propriétaire et à un modèle open weights ;
3. faire noter les réponses par les métiers concernés ;
4. relever la latence et le coût observés, car la performance seule ne tranche pas.

Oupi permet d'utiliser les deux familles de modèles dans le même outil, ce qui facilite ce type de comparaison sur des requêtes identiques (voir le produit).

Combien coûte vraiment un modèle d'IA : API ou auto-hébergement ?

Le coût d'un modèle d'IA dépend du volume traité et des compétences disponibles en interne : les sources ne s'accordent pas sur l'option la moins chère.

Deux lectures qui s'opposent

Selon Tizy, un modèle open source auto-hébergé reviendrait 5 à 10 fois moins cher qu'un modèle propriétaire en API, à volume comparable [10]. Ce chiffre est cité d'après « Tech Insider », une source secondaire. Aucun détail de calcul n'est fourni dans le dossier, et Tizy est un acteur commercial : il faut le traiter avec prudence. Un autre contenu en nuance la portée : l'open source offre des économies significatives surtout aux entreprises qui disposent d'une expertise technique interne [13].

D'autres sources rappellent que les modèles sont gratuits à télécharger, mais que le calcul et le stockage restent à la charge de l'entreprise [11]. Pour un usage standard, une API propriétaire, ou un modèle open source chez un fournisseur d'inférence, resterait souvent plus économique et plus fiable [22].

Ces positions ne se contredisent pas frontalement : elles décrivent des situations différentes (gros volumes et équipe technique d'un côté, usage courant de l'autre).

Les postes de coût à intégrer

L'auto-hébergement suppose de compter [12] :

• une infrastructure de calcul adaptée ;
• la gestion des mises à jour ;
• le suivi des performances ;
• la sécurisation du pipeline IA.

Les trois derniers postes mobilisent du temps d'équipe, qui n'apparaît pas dans un tarif au token.

Raisonner en coûts complets

Comparer le prix par token d'une API au coût d'un serveur ne suffit pas : il faut raisonner en coûts complets [40]. Pour une API, cela revient à projeter la consommation réelle. Pour l'auto-hébergement, on additionne le matériel ou la location de GPU, l'exploitation et les compétences.

Ce qu'il faut retenir

Les sources du dossier ne permettent pas de fixer un seuil de rentabilité universel. Tout dépend du volume et des compétences : l'auto-hébergement devient pertinent quand les volumes sont élevés et que l'équipe sait l'exploiter, l'API reste le choix le plus simple pour un usage standard. Pour trancher, chiffrez ces deux scénarios sur vos propres volumes et cas d'usage.

Open source ou propriétaire : lequel protège le mieux les données et la souveraineté ?

Un modèle installé sur ses propres serveurs offre la maîtrise des données la plus directe. L'open source ne garantit pourtant pas la souveraineté à lui seul, et un modèle propriétaire n'est pas exclu par principe.

Ce que change l'auto-hébergement. Une entreprise peut installer un modèle open source sur ses propres serveurs et l'utiliser sans passer par l'API d'un fournisseur externe [34]. Cette configuration permet de conserver la maîtrise des données [18]. Avec un modèle propriétaire, l'entreprise envoie ses données via une API et n'a aucune visibilité sur le fonctionnement interne du modèle [21].

Pourquoi la souveraineté pèse dans le choix. La souveraineté numérique et la conformité, accentuées par l'AI Act européen, poussent les entreprises à chercher des solutions où elles contrôlent leur infrastructure et évitent la dépendance aux géants américains ou chinois [31]. Cette source est un blog d'agence : elle décrit une tendance du marché, pas une analyse juridique.

Le modèle européen ne suffit pas. Choisir un modèle européen ne règle qu'une partie de la question, car la souveraineté dépend aussi d'autres facteurs, comme l'hébergement [22]. Un modèle ouvert exploité chez un fournisseur d'inférence n'offre donc pas le même niveau de maîtrise qu'un modèle exécuté sur sa propre infrastructure. Il faut vérifier où tourne réellement le modèle.

Ce que l'AI Act change selon la famille de modèle. Le règlement (UE) 2024/1689, en vigueur depuis le 1er août 2024, introduit une différence entre open source et propriétaire [26]. Pour un usage purement interne, sans mise à disposition d'utilisateurs extérieurs, l'obligation indiquée se limite à informer les collaborateurs qu'ils interagissent avec une IA [26]. Cet exemple vaut pour des outils comme ChatGPT, Claude ou Mistral [26].

À vérifier : cette affirmation vient d'un blog qui renvoie à service-public.fr [26]. Avant toute décision de conformité, confrontez-la au texte officiel du règlement.

Une décision par usage. Les exigences de confidentialité varient selon les cas d'usage. Dans Oupi, les deux familles de modèles s'utilisent dans le même outil (voir le produit), ce qui évite d'imposer un seul choix à toute l'entreprise.

« Open source » signifie-t-il toujours libre d'usage ? Ce que disent les licences

Non : « open source » ne dit pas, à lui seul, ce que l'entreprise a le droit de faire d'un modèle. C'est la licence qui le fixe, et elle varie d'un modèle à l'autre. Selon un panorama de Lebigdata, aucune licence ne s'impose [33] :

Les conditions peuvent aussi changer d'une version à l'autre. Meta a ainsi choisi Apache 2.0 pour Muse Glimmer, en délaissant sa licence communautaire historique [33].

L'étiquette « open source » ne tranche pas toujours. Une publication de recherche pose la question de savoir quand on peut parler de licence open source, y compris à propos de Mistral 7B [2]. Pour un DSI, la mention commerciale d'un éditeur ne remplace donc pas la lecture du texte de la licence.

Un projet ouvert peut aussi changer de cap. Une publication de recherche rappelle qu'il peut prendre un virage propriétaire [4]. Conserver la licence applicable à la version réellement déployée est un réflexe prudent, car les conditions d'une version ultérieure peuvent différer.

Les modèles conformes à l'OSAID sont présentés comme plus sûrs juridiquement. Selon ZDNET, ils offrent aux organisations transparence, sécurité juridique et fonctions de personnalisation complètes [20]. Le critère reste un filtre de départ, pas une garantie : il ne dispense pas de vérifier la licence du modèle retenu.

À l'inverse, les modèles dits fermés ou propriétaires ne donnent pas accès à leur code source [9]. Leurs conditions d'usage passent alors par le contrat de l'éditeur.

Avant tout usage commercial, lisez la licence du modèle, version par version, et faites valider ses conditions par votre service juridique. Oupi permet d'utiliser les deux familles de modèles dans le même outil, ce qui facilite la comparaison sur vos cas d'usage (voir le produit). La vérification des licences reste à faire de votre côté.

Quel risque de dépendance fournisseur (lock-in) selon le choix de modèle ?

Le risque de dépendance fournisseur existe avec les deux familles de modèles, mais il ne prend pas la même forme. Le lock-in désigne la situation où changer de fournisseur coûte trop cher en temps, en développement ou en organisation.

Le risque côté modèle propriétaire

Une fois qu'un modèle propriétaire est profondément imbriqué dans les flux de travail et les API, il devient difficile à remplacer [7]. Plus l'intégration avance, plus la sortie coûte cher. C'est surtout au moment de la conception qu'il faut s'en préoccuper.

Le risque est particulièrement net pour les PME : celle qui bâtit une offre sur un modèle d'IA propriétaire s'expose à ce risque [3]. Les entreprises dont l'activité repose sur des API propriétaires doivent donc en évaluer le risque [5].

Le contexte commercial joue aussi. Selon l'analyse de l'Autorité de la concurrence, certains fournisseurs peuvent inciter les jeunes entreprises de l'IA à choisir leurs services [6]. Une offre d'entrée attractive ne dit rien du coût d'un changement ultérieur.

Le risque côté open source et offres mixtes

Choisir un modèle ouvert ne supprime pas toute dépendance. Certains éditeurs associent des briques d'IA propriétaires à des plateformes open source. Cette approche facilite le déploiement et garantit un accompagnement technique solide, mais elle crée une dépendance vis-à-vis du fournisseur, sur les coûts comme sur la compréhension réelle du fonctionnement des modèles [27]. Cette source est un média spécialisé, non une étude, mais le mécanisme décrit est clair : l'étiquette « open source » de la plateforme n'empêche pas le verrouillage par les briques qui l'entourent.

Questions à poser avant de s'engager

• Le modèle est-il remplaçable sans réécrire les flux de travail et les intégrations API ?
• Quelles briques de l'offre restent propriétaires, même sur une plateforme ouverte ?
• Que coûterait la sortie, en développement comme en compétences internes ?

Limiter le lock-in revient surtout à garder la possibilité de changer de modèle. Oupi permet d'utiliser les deux familles de modèles, open source et propriétaires, dans le même outil (voir le produit). L'usage n'est donc pas attaché à une seule famille.

Comment décider concrètement : propriétaire, open weights ou hybride ?

Le choix entre propriétaire et open weights n'est ni binaire ni définitif : il dépend du niveau de maturité technologique de l'entreprise et de ses besoins [15][29]. Une décision prise aujourd'hui peut donc être revue quand les volumes, les compétences ou les contraintes changent.

Grille de décision

L'hybride consiste à répartir les usages entre les deux familles, tâche par tâche. Il reste réaliste côté offre : certains acteurs proposent déjà à la fois des modèles propriétaires et open source [6].

Une architecture simple pour démarrer

Une source commerciale, gensai.ai, avance qu'un modèle open weight bien choisi, un RAG sur ses propres documents et une mémoire applicative couvrent l'immense majorité des besoins, pour une fraction du coût d'un développement propriétaire [30]. Cette affirmation vient d'un acteur qui vend ce type de solution : elle donne un point de départ, pas une preuve.

Comparer sur ses propres cas d'usage

Oupi permet d'utiliser les deux familles de modèles dans le même outil. Une équipe peut ainsi soumettre un même cas d'usage à un modèle propriétaire et à un modèle open weights, sans changer d'interface, et comparer les résultats (voir le produit).

Tester sur ses volumes réels

Les chiffres génériques ne remplacent pas une mesure. Avant d'arbitrer, il est recommandé de :

1. retenir deux ou trois cas d'usage représentatifs ;
2. les faire tourner dans les deux familles sur des volumes proches de la production ;
3. comparer la qualité des réponses, le coût complet (infrastructure et temps d'exploitation compris) et le délai de mise en œuvre ;
4. revoir l'arbitrage à intervalles réguliers, puisque le choix n'est pas définitif [15].