Choisir un LLM en entreprise en 2026 : modèles ouverts, propriétaires ou souverains ?

Choisir un LLM en entreprise en 2026 ne revient plus à désigner « le meilleur modèle ». La bonne réponse dépend de la sensibilité des données traitées, du niveau de contrôle exigé sur l'hébergement, des conditions de licence et du coût total d'exploitation. Un même groupe peut légitimement utiliser une API propriétaire pour des tâches sans données sensibles, un modèle à poids ouverts hébergé en interne pour des documents confidentiels, et une offre de cloud de confiance lorsque son exposition juridique l'impose.

La décision se prend donc cas d'usage par cas d'usage, à partir d'une classification des données et d'une grille de critères partagée entre DSI, RSSI, DPO et juristes. Surtout, le choix d'un modèle est moins structurant que la capacité à en changer : les modèles se succèdent en quelques mois, alors que les contrats, les architectures et les habitudes des utilisateurs restent.

Cet article propose une grille pragmatique pour comparer modèles propriétaires, ouverts et dits souverains sur cinq axes : confidentialité, licences et réglementation, performance, coût et hébergement.

Modèles propriétaires, ouverts, souverains : de quoi parle-t-on ?

Un modèle propriétaire n'est accessible que par l'API ou l'application de son éditeur. Vous ne voyez ni les poids ni l'infrastructure, et vous dépendez de ses conditions contractuelles pour la conservation, la localisation et la réutilisation des données. En contrepartie, l'éditeur porte l'exploitation, la montée en charge et les mises à jour.

Un modèle à poids ouverts (open-weight) peut être téléchargé et exécuté sur votre propre infrastructure ou chez l'hébergeur de votre choix. Le contrôle sur les données augmente, mais la responsabilité de l'exploitation, de la sécurité et des performances vous revient entièrement.

Attention au vocabulaire : poids ouverts ne signifie pas open source. L'Open Source Initiative a publié en octobre 2024 la version 1.0 de sa définition de l'IA open source. Elle exige les libertés d'utiliser, d'étudier, de modifier et de partager le système, ainsi que la mise à disposition d'informations suffisantes sur les données d'entraînement, du code complet d'entraînement et d'inférence, et des paramètres 1. Beaucoup de modèles diffusés librement ne remplissent pas ces conditions, notamment parce que leur licence restreint certains usages ou que les données d'entraînement ne sont pas documentées.

Quant au modèle souverain, ce n'est pas une propriété technique du modèle. C'est une combinaison de facteurs : juridiction de l'éditeur, lieu d'hébergement, nationalité de l'opérateur de l'infrastructure, exposition aux lois extraterritoriales. Un modèle ouvert d'origine non européenne exécuté sur une infrastructure qualifiée en France peut offrir davantage de maîtrise qu'un modèle européen consommé via une API hébergée hors de l'Union.

Confidentialité : partir de la classification des données

Le premier filtre est la nature des données que le modèle verra réellement : prompts saisis par les utilisateurs, documents injectés dans le contexte, réponses générées, journaux techniques. C'est souvent dans les documents injectés automatiquement, bien plus que dans les questions, que se trouvent les informations les plus sensibles.

Dans ses questions-réponses de juillet 2024 sur l'utilisation d'un système d'IA générative, la CNIL estime qu'il est plus opportun et plus sécurisé de privilégier un déploiement sur site pour traiter des données confidentielles. En cas d'usage via une API, elle recommande d'éviter autant que possible les données personnelles, de vérifier les clauses relatives aux transferts hors de l'Union, de refuser la réutilisation des données par le fournisseur lorsque c'est possible et de désactiver l'historique 2.

L'ANSSI va dans le même sens dans ses recommandations de sécurité pour un système d'IA générative, publiées en avril 2024 : elle proscrit l'utilisation d'outils d'IA générative sur Internet pour un usage professionnel impliquant des données sensibles, et recommande de privilégier un hébergement SecNumCloud lorsqu'un système d'IA est déployé dans un cloud public 3. En pratique, trois niveaux suffisent souvent à structurer la décision :

• Données publiques ou internes non sensibles : une API propriétaire est envisageable, sous réserve d'un contrat qui encadre la conservation, la réutilisation et la localisation des données.
• Données confidentielles ou personnelles : modèle hébergé dans un environnement que vous contrôlez (on-premise ou cloud de confiance), avec cloisonnement et journalisation.
• Données sensibles au sens réglementaire ou stratégique : hébergement qualifié, opérateur soumis au seul droit européen, aucune dépendance à un service grand public accessible depuis Internet.

Licences et AI Act : lire avant de télécharger

Les licences des modèles ouverts sont hétérogènes, y compris chez un même éditeur. La licence communautaire de Llama 3.3, par exemple, impose de demander une licence spécifique à Meta au-delà de 700 millions d'utilisateurs actifs mensuels, d'afficher la mention « Built with Llama » en cas de distribution, de faire commencer par « Llama » le nom de tout modèle dérivé distribué et de respecter une politique d'usage acceptable ; elle est régie par le droit californien 4. Le catalogue de Mistral AI mêle, à la date de rédaction, des modèles sous Apache 2.0, sous une licence MIT modifiée, sous licence non commerciale CC BY-NC 4.0, et des modèles accessibles uniquement via son offre commerciale 5.

Ces nuances ont des conséquences concrètes : droit d'affiner le modèle et de redistribuer le résultat, usage commercial, obligations d'attribution, juridiction compétente en cas de litige. Une revue juridique de la licence doit précéder tout prototype destiné à passer en production, et la licence retenue doit être enregistrée dans l'inventaire des composants logiciels au même titre qu'une bibliothèque.

Ce que l'AI Act change pour le choix du modèle

Les obligations des fournisseurs de modèles d'IA à usage général s'appliquent depuis le 2 août 2025. Les pouvoirs d'exécution de la Commission, amendes comprises, démarrent le 2 août 2026, et les modèles mis sur le marché avant août 2025 ont jusqu'au 2 août 2027 pour se mettre en conformité. Les lignes directrices de la Commission précisent notamment dans quels cas les fournisseurs de modèles open source bénéficient d'exemptions 6. Pour l'entreprise utilisatrice, ces obligations sont un argument de négociation : la documentation technique que l'éditeur doit produire est une pièce utile de votre propre analyse de risques.

Côté déployeur, le règlement est applicable depuis le 2 août 2026, avec des exceptions : le règlement omnibus (UE) 2026/1744, entré en vigueur le 27 juillet 2026, a reporté au 2 décembre 2027 les règles applicables aux systèmes à haut risque de l'annexe III 7. Si vous envisagez d'affiner lourdement un modèle ouvert avant de le diffuser, faites vérifier par vos juristes si cette modification peut vous faire endosser des obligations de fournisseur.

Performance, coût et exploitation : mesurer sur vos cas

Les classements publics mesurent des capacités générales sur des jeux de tests connus, parfois présents dans les données d'entraînement des modèles. Ils renseignent peu sur la performance avec vos documents, votre vocabulaire métier et vos formats de sortie. La seule mesure qui compte est un jeu d'évaluation construit à partir de cas réels, annotés par les métiers, sur lequel chaque modèle candidat est comparé à configuration égale : même prompt, même contexte, mêmes paramètres de génération.

Le coût obéit à deux logiques différentes. Une API facture à l'usage, en jetons d'entrée et de sortie : le coût est variable, nul au repos, mais difficile à prévoir quand l'usage décolle. Un modèle auto-hébergé transforme ce coût en charge fixe (GPU, énergie, exploitation, compétences) dont la rentabilité dépend directement du taux d'utilisation. Entre les deux existent des offres de modèles ouverts servis par un hébergeur, facturées à l'usage dans un périmètre contractuel et géographique maîtrisé.

Deux règles évitent la plupart des dérives. D'abord, dimensionner le modèle à la tâche : classer, extraire ou résumer ne demande pas forcément le modèle le plus grand, et l'écart se vérifie sur le jeu d'évaluation. Ensuite, comparer les coûts au volume cible réaliste, avec les pics prévisibles, et non sur les quelques centaines de requêtes d'un pilote.

Le choix d'un modèle est moins structurant que la capacité à en changer.

Hébergement et réversibilité : qui opère quoi ?

Choisir un modèle, c'est aussi choisir un mode d'exploitation. Une API propriétaire délègue tout à l'éditeur, y compris les montées de version, qui peuvent modifier le comportement d'une application si le contrat ne permet pas de figer une version pendant une durée connue. Un modèle auto-hébergé exige une chaîne complète : registre de modèles, serveur d'inférence, supervision, gestion des correctifs, plan de capacité et astreinte.

Quelle que soit l'option retenue, trois dispositifs protègent l'entreprise contre l'enfermement :

• Une passerelle d'accès unique aux modèles (authentification, quotas, journalisation, routage) qui découple les applications du fournisseur et permet de basculer d'un modèle à l'autre sans modifier le code métier.
• Des prompts, jeux d'évaluation et configurations versionnés, pour rejouer les tests sur un nouveau modèle en quelques jours plutôt qu'en quelques mois.
• Un mode dégradé sans IA pour les services métier critiques, comme le recommande l'ANSSI 3, complété par une clause de réversibilité dans les contrats.

Grille de décision : huit questions pour choisir un LLM en entreprise

Ces questions se posent pour chaque cas d'usage, et leurs réponses doivent être consignées pour être revues à chaque changement de modèle ou de fournisseur :

• Quelle est la classification la plus élevée des données que le modèle verra, y compris dans les documents injectés automatiquement ?
• Les données peuvent-elles quitter votre périmètre, et vers quelle juridiction ?
• Le fournisseur conserve-t-il ou réutilise-t-il prompts et réponses, et pouvez-vous l'exclure contractuellement ?
• La licence autorise-t-elle l'usage commercial, l'affinage et la redistribution envisagés ?
• Le modèle atteint-il le seuil de qualité défini sur votre propre jeu d'évaluation ?
• Quel est le coût mensuel au volume cible, à l'usage comme en auto-hébergement ?
• Disposez-vous des compétences pour exploiter un serveur d'inférence en production, ou d'un partenaire qui le fera ?
• Pouvez-vous changer de modèle en quelques semaines sans réécrire les applications ?

Conclusion

Il n'existe pas de modèle idéal, mais un portefeuille cohérent : quelques modèles évalués, classés selon le niveau de sensibilité qu'ils sont autorisés à traiter, servis derrière une passerelle commune et réévalués à chaque nouvelle version. La souveraineté se joue moins dans le nom du modèle que dans la maîtrise de l'hébergement, des contrats et de la réversibilité. DATASWING accompagne ces choix de bout en bout, du cadrage des cas d'usage à l'intégration, l'hébergement et la sécurisation du modèle retenu.

— Questions fréquentes

Ce qu'on nous demande souvent

Quelle différence entre un LLM open source et un LLM open-weight ?+

Un modèle open-weight met ses poids à disposition, ce qui permet de l'exécuter sur sa propre infrastructure. Un modèle open source au sens de la définition publiée par l'Open Source Initiative en 2024 doit en plus garantir les libertés d'utiliser, d'étudier, de modifier et de partager, avec le code d'entraînement et des informations suffisantes sur les données. Beaucoup de modèles dits ouverts sont seulement open-weight, avec des restrictions de licence.

Peut-on envoyer des données personnelles à une API de LLM ?+

C'est possible juridiquement mais à encadrer strictement. La CNIL recommande d'éviter autant que possible les données personnelles avec une API, de conclure un contrat de sous-traitance, de vérifier les transferts hors Union européenne et de refuser la réutilisation des données par le fournisseur. Pour des données confidentielles, elle considère un déploiement sur site comme plus sécurisé.

Qu'est-ce qu'un LLM souverain ?+

Le terme ne désigne pas une technologie particulière. Un usage souverain combine un modèle dont la licence est maîtrisée, un hébergement localisé dans l'Union européenne, un opérateur non soumis à des lois extraterritoriales et des contrats réversibles. Un modèle européen consommé via une API hébergée hors de l'Union n'est pas souverain pour autant, alors qu'un modèle ouvert exécuté sur une infrastructure qualifiée peut l'être.

Faut-il choisir un seul LLM pour toute l'entreprise ?+

Rarement. La plupart des organisations ont intérêt à maintenir un petit portefeuille de modèles évalués, chacun autorisé pour un niveau de sensibilité de données et un type de tâche. Une passerelle commune applique l'authentification, les quotas et la journalisation, et permet de remplacer un modèle par un autre sans modifier les applications qui le consomment.

— Sources

Références citées

Les textes réglementaires et documentations évoluent : vérifiez la version en vigueur avant toute décision. Cet article n'est pas un avis juridique.

1. [1]
   The Open Source AI Definition 1.0 ↗

   Open Source Initiative · 2024-10
2. [2]
   Les questions-réponses de la CNIL sur l'utilisation d'un système d'IA générative ↗

   CNIL · 2024-07
3. [3]
   Recommandations de sécurité pour un système d'IA générative ↗

   ANSSI · 2024-04
4. [4]
   Llama 3.3 Community License Agreement ↗

   Meta (dépôt GitHub meta-llama) · 2024-12
5. [5]
   Models overview ↗

   Mistral AI (documentation officielle) · 2026
6. [6]
   Guidelines for providers of general-purpose AI models ↗

   Commission européenne · 2025-07
7. [7]
   AI Act – Regulatory framework on AI ↗

   Commission européenne · 2026-08