Tu n’as pas à “choisir un camp”. Tu dois choisir un montage qui tient en prod.
Entre ChatGPT, Claude, Gemini, Copilot d’un côté, et les modèles “open weights” hébergés chez toi ou chez un prestataire de l’autre, le piège c’est la décision idéologique.
La réalité 2025-2026, c’est l’hybride. La plupart des boîtes mixent plusieurs fournisseurs. D’après des interviews relayées par CB Insights, 94% des entreprises utilisent 2 fournisseurs LLM ou plus. Donc la bonne question n’est pas “SaaS ou open ?”, c’est quel modèle pour quel cas d’usage, avec quel niveau de risque, et quel coût total.
Je te donne une grille de décision en 12 critères et une méthode en 60 minutes pour trancher, avec 3 scénarios typiques (cabinet, PME multi-sites, ETI réglementée). Objectif : une décision de dirigeant. Temps gagné, marge, risques, confidentialité. Pas de hype.
SaaS LLM vs modèles open : définitions rapides (pour éviter les contresens)
SaaS LLM : tu consommes un modèle via une interface ou une API opérée par un fournisseur (OpenAI, Anthropic, Google, Microsoft). Ils gèrent l’infra, les mises à jour, une partie de la sécurité. Tu gères l’usage, les données que tu envoies, les accès, la conformité côté “déployeur”.
Open source vs open weights : en entreprise, la majorité de ce qu’on appelle “open source” est en fait open weights (poids du modèle accessibles) avec une licence plus ou moins permissive. Important : open weights ne veut pas dire sans contraintes. Exemple connu : Llama 3.1 est sous Community License (conditions spécifiques). À l’inverse, certains modèles sont sous Apache 2.0 (plus simple), et d’autres ont des licences non-production qui rendent la prod impossible.
Héberger un LLM en interne : ça peut vouloir dire “dans ton infra” ou “chez un prestataire” (cloud privé, acteur souverain, infogéreur). Dans les deux cas, tu reprends du contrôle, mais tu reprends aussi une partie du boulot.
La grille de décision en 12 critères (SaaS vs modèle IA open source entreprise)
Principe : pour chaque critère, tu te poses la question “qu’est-ce qui me coûte le plus cher si je me trompe ?”. Puis tu notes SaaS et Open de 1 à 5.
1) TCO réel (pas le prix facial)
Le mot-clé ici c’est TCO IA générative. En SaaS, tu vois vite la facture (licences, tokens). En open, tu sous-estimes souvent les coûts cachés : GPU, stockage, observabilité, astreinte, incidents, optimisation d’inférence.
- SaaS : coûts variables mais lisibles. Risque de dérive si pas de garde-fous (quotas, monitoring, règles d’usage).
- Open : tu payes l’infra et l’équipe. Référence “on-demand” (oct. 2026) : H100 médian ~3,49 $/GPU-heure, H200 ~4,40 $, B200 ~6,25 $, A100 80GB ~1,75 $. Ça bouge vite. Et c’est avant le MLOps.
Point dirigeant : compare en coût par tâche et coût par token, pas “GPU vs abonnement”. NVIDIA pousse cette métrique, et sur des benchmarks relayés (SemiAnalysis, avril 2026), l’économie varie fortement selon la stack : exemple cité ~0,09 $/million tokens sur H100 (vLLM) vs ~0,02 $/million tokens sur B200 (TensorRT-LLM) sur un modèle open-weight. Morale : matériel + runtime peuvent changer le verdict.
2) Prévisibilité budgétaire
- SaaS : prévisible si tu es sur licence “par siège”. Moins si tu es sur API à forte volumétrie.
- Open : prévisible si tu réserves de la capacité, mais tu peux te faire surprendre par les pics, les projets qui s’ajoutent, ou l’optimisation qui traîne.
Si tu veux un cadrage simple côté direction sur les dérapages, tu peux t’appuyer sur ce plan : https://jimmymanin.com/blog/budgets-ia-qui-derapent-piloter-tokens-licences-et-depassements-sans-bloquer-tes-equipes.
3) Confidentialité et exposition de données (RGPD, secret, contrats)
Question simple : est-ce acceptable que des extraits de tes données sortent de ton périmètre ? Pas “tout”, juste des morceaux. Parce que dans la vraie vie, les prompts finissent par contenir du sensible.
- SaaS : tu dépends des garanties contractuelles, options “no training”, paramétrages, et du comportement utilisateur (copier-coller).
- Open : tu peux réduire l’exposition (hébergement maîtrisé, réseau, chiffrement), mais tu dois mettre les contrôles.
L’EDPB insiste sur l’analyse au cas par cas (opinion 18 déc. 2024) et publie des mitigations LLM (10 avr. 2025) orientées gestion des risques. Concrètement : minimisation, séparation des environnements, politiques de logs, filtrage des entrées/sorties, tests.
Si tu dois partager des données sans te tirer une balle RGPD : https://jimmymanin.com/blog/anonymisation-et-ia-en-entreprise-plan-terrain-en-6-etapes-pour-partager-utile-sans-risque-rgpd.
4) Souveraineté et dépendance fournisseur
- SaaS : dépendance forte (prix, conditions, disponibilité, évolution produit). Tu peux mitiger en multi-fournisseurs.
- Open : tu réduis le verrouillage, mais tu déplaces la dépendance vers l’infra, les librairies, le prestataire d’hébergement, et les compétences internes.
Pour cadrer “souveraineté” sans posture marketing : https://jimmymanin.com/blog/ia-souveraine-en-pmeeti-checklist-dachat-secnumcloud-clauses-reversibilite.
5) Latence et performance “terrain”
Question : tes équipes attendent-elles la réponse dans un flux de travail ? (support client, rédaction, analyse) ou c’est du batch ?
- SaaS : latence variable, dépend du réseau, de la charge fournisseur, des quotas.
- Open : tu peux optimiser la latence si tu maîtrises l’inférence… ou faire pire si tu dimensionnes mal.
6) Qualité utile (pas la qualité “benchmark”)
Question : sur tes documents et tes cas, est-ce fiable ? Le modèle le plus “fort” sur papier n’est pas forcément le meilleur sur ton domaine ou ton format.
- SaaS : souvent meilleur “out of the box” et plus stable sur les tâches généralistes.
- Open : très bon sur des tâches ciblées, surtout si tu ajoutes RAG, outils, ou fine-tuning… mais ça se travaille.
Et rappelle-toi : une IA peut sortir des chiffres faux avec aplomb. Pour cadrer un usage “reporting direction” : https://jimmymanin.com/blog/chatgpt-chiffres-faux-et-gemini-protocole-reporting-fiable-en-5-regles-dirigeant.
7) Mise à jour, dépréciation, continuité
En SaaS, les modèles changent. En open, les stacks changent. Dans les deux cas, tu peux te faire casser un workflow du jour au lendemain.
- SaaS : tu subis des changements de modèle, de limites, de prix. Avantage : tu n’opères pas la mise à jour.
- Open : tu choisis quand tu migres, mais tu dois le faire. Et tu dois tester.
Pour une approche “plan de continuité” : https://jimmymanin.com/blog/depreciation-des-modeles-llm-plan-de-continuite-en-10-points-pour-eviter-la-panne.
8) Auditabilité et traçabilité (ce que tu peux prouver)
Question dirigeant : si tu as un incident, peux-tu reconstituer qui a fait quoi, avec quelles données, et quel modèle ?
- SaaS : tu dépends des logs exposés par le fournisseur et de tes paramétrages.
- Open : tu peux instrumenter finement, mais il faut le faire (logs, rétention, accès, preuves).
Pour un cadrage simple sur les contrôles “auditables” : https://jimmymanin.com/blog/automatiser-un-controle-sensible-sans-deraper-la-methode-auditabile-en-4-minutes.
9) Surface d’attaque sécurité (et usage réel, pas théorie)
- SaaS : tu réduis certains risques infra, mais tu augmentes l’exposition aux risques “tiers” (compte compromis, fuite via connecteurs, politiques de partage).
- Open : tu contrôles l’environnement, mais tu dois gérer durcissement, patching, secrets, segmentation, monitoring.
Si tu connectes des agents à tes outils, lis ça avant : https://jimmymanin.com/blog/connecteurs-ia-drive-gmail-slack-eviter-la-fuite-de-donnees-quand-tu-branches-un-agent.
10) Risque supply chain (modèle, dépendances, données d’entraînement)
L’open source ne supprime pas le risque. Il le déplace.
- SaaS : risque de dépendance fournisseur + opacité partielle (tu ne sais pas tout sur l’entraînement, ni sur certains filtres).
- Open : risque sur la provenance des poids, des datasets, des librairies, et sur les modifications. Tu dois valider les sources, signer/figer les artefacts, gérer les CVE, et mettre des politiques d’update.
Le NIST AI RMF (profil GenAI) est utile ici comme langage de gestion des risques : tu identifies les risques sur tout le cycle de vie (design, entraînement, opération, entrées/sorties).
11) Charge conformité (AI Act, transparence, rôles provider vs deployer)
En UE, tes obligations varient selon ton rôle. Si tu déploies, tu as des obligations. Si tu deviens “provider” d’un système à risque, la charge peut exploser.
- SaaS : une partie de la conformité “côté modèle” est gérée par le fournisseur, mais tu restes responsable de ton usage, de l’information utilisateur, du monitoring, des incidents.
- Open : tu récupères plus de responsabilités (documentation, contrôles, monitoring). Avantage : tu peux construire une conformité plus “sur mesure”.
Pour cadrer rapidement la transparence AI Act (Article 50) : https://jimmymanin.com/blog/ai-act-article-50-la-checklist-transparence-pour-chatbots-agents-et-contenus-ia. Les guidelines indiquent une applicabilité à partir du 2 août 2026.
12) Licences et droits d’usage (le “go/no-go” caché)
Critère souvent zappé, et pourtant c’est parfois le seul qui compte.
- SaaS : tu lis des conditions de service, tu négocies parfois (ETI), tu vérifies les clauses data.
- Open : tu dois vérifier la licence modèle par modèle. Certaines sont permissives (Apache 2.0), d’autres imposent des conditions, et certaines interdisent la production.
Règle simple : pas de POC sans check licence. Sinon tu fais bosser tes équipes sur un truc que tu ne peux pas mettre en prod.
Méthode de décision en 60 minutes : scoring pondéré
Tu peux faire ça en comité court (toi + IT + DPO/RGPD si tu en as un + métier).
Étape 1 (10 min) : pose le cas d’usage, pas la techno
- Une phrase : “On veut automatiser X pour gagner Y heures / réduire Z erreurs.”
- Données manipulées : public, interne, confidentiel, données perso, données santé, juridique, etc.
- Niveau de tolérance à l’erreur : faible, moyen, élevé.
- Volume : utilisateurs, requêtes/jour, tokens estimés.
Étape 2 (10 min) : mets des poids sur les 12 critères (total = 100)
Exemple de pondération “direction” (à adapter) :
- TCO réel 15
- Prévisibilité budget 8
- Confidentialité 12
- Souveraineté 6
- Latence 6
- Qualité utile 12
- Mise à jour/continuité 8
- Auditabilité 8
- Sécurité 10
- Supply chain 5
- Conformité 7
- Licences 3
Étape 3 (25 min) : note SaaS et Open de 1 à 5, critère par critère
Règles :
- Tu notes sur ton contexte, pas sur des généralités.
- Si tu n’as pas l’info, tu mets 2 et tu écris “à vérifier”. Pas de note 5 “à l’instinct”.
- Tu notes deux options open si besoin : “open chez prestataire” et “open interne”. Ce n’est pas la même chose.
Étape 4 (10 min) : calcule, puis fais le sanity check “risque fatal”
- Score pondéré = somme (poids x note).
- Puis check “kill switch” : une seule case peut invalider (licence non-prod, données ultra sensibles sans contrôle, impossibilité d’audit, etc.).
Étape 5 (5 min) : décide un montage hybride si c’est le plus rationnel
Dans les faits, tu arrives souvent à :
- SaaS pour la bureautique, la créativité, les tâches à faible sensibilité, le prototypage rapide.
- Open hébergé pour les flux sensibles, les agents connectés à des systèmes internes, les besoins d’audit strict, ou la latence maîtrisée.
Si tu veux une logique “quoi garder en interne”, tu peux croiser avec : https://jimmymanin.com/blog/assistant-ia-hybride-local-cloud-decider-en-90-min-quoi-garder-en-interne.
3 scénarios types (et le verdict le plus probable)
Scénario 1 : cabinet (avocats, expertise comptable, conseil), 10 à 50 personnes
Objectif : gagner du temps sur rédaction, synthèse, analyse de docs, mails, CR, recherche interne. Donnée : très sensible (clients, dossiers, stratégie).
- Ce qui pèse lourd : confidentialité, auditabilité, sécurité, licences, qualité sur documents.
- Verdict fréquent : hybride. SaaS “entreprise” pour tâches génériques + RAG interne sur un modèle hébergé (prestataire ou interne) pour interroger la base documentaire sans copier-coller partout.
Action directe : monte un RAG interne cadré : https://jimmymanin.com/blog/rag-interne-en-48-heures-ton-chatbot-interne-pme-support-it-rh-sans-projet-data.
Scénario 2 : PME multi-sites (100 à 800), opérations + commerce + support
Objectif : agents qui aident sur support, qualité, logistique, ADV, RH. Donnée : mix interne et perso (clients, salariés). Risque : multiplication des outils et fuite via connecteurs.
- Ce qui pèse lourd : TCO réel, prévisibilité, sécurité, latence, continuité, gouvernance.
- Verdict fréquent : SaaS au départ (déploiement rapide), puis open hébergé pour les flux “always-on” ou sensibles, une fois que tu as prouvé le ROI et stabilisé les workflows.
Action directe : avant de laisser un agent toucher tes outils, fais un pilote contrôlé : https://jimmymanin.com/blog/agents-ia-en-entreprise-le-plan-pilote-controle-en-21-jours-sans-ouvrir-les-vannes.
Scénario 3 : ETI réglementée (industrie, santé, finance, secteur public), audit et exigences fortes
Objectif : assistance aux équipes, automatisation contrôlée, conformité, traçabilité. Donnée : sensible, parfois critique. Contrainte : audit, preuves, clauses, résidence des données.
- Ce qui pèse lourd : conformité (AI Act + RGPD), auditabilité, souveraineté, supply chain, continuité.
- Verdict fréquent : open hébergé ou “private” pour les cas critiques + SaaS pour le reste. Et surtout : gouvernance et preuves.
Action directe : prépare tes livrables d’audit IA, même si tu n’es pas “high-risk” aujourd’hui. Ça te servira le jour où un client te challenge : https://jimmymanin.com/blog/ai-act-entreprise-2-aout-2026-le-protocole-en-7-livrables-pour-passer-un-audit-ia.
Le piège classique : croire que “open” = moins cher et “SaaS” = moins risqué
La vérité :
- Open peut coûter moins cher à gros volume stable, avec une infra optimisée et une équipe qui sait opérer. Sinon, ça explose.
- SaaS peut être très sûr si tu cadres les accès, les connecteurs, les logs, et la politique data. Sinon, tu fais du Shadow AI proprement facturé.
- Le risque ne disparaît pas. Il change de place. En SaaS, risque tiers. En open, risque opérationnel.
Plan d’action immédiat (à faire cette semaine)
- 1) Prends un cas d’usage qui touche du sensible (contrats, RH, finance) et un cas “low risk” (rédaction, synthèse).
- 2) Fais le scoring pondéré 12 critères en 60 minutes, avec au moins IT + métier. Note aussi “open chez prestataire” vs “open interne” si tu hésites.
- 3) Pose 3 garde-fous quel que soit le choix : règles d’accès, logs minimaux, et plan de continuité (que faire si le modèle change, tombe, ou devient trop cher).
- 4) Décide hybride par défaut : SaaS pour vitesse, open pour contrôle sur les flux critiques. Et tu ajoutes un deuxième fournisseur si tu ne veux pas être pieds et poings liés.
Si tu ne dois lire qu’une chose de plus côté “agents + risques”, prends la checklist anti-fuite : https://jimmymanin.com/blog/agents-ia-en-entreprise-checklist-securite-en-12-points-anti-fuite-avant-deploiement.
Le bon choix, ce n’est pas “open” ou “SaaS”. C’est celui qui passe l’audit, tient le budget, et marche tous les jours sur tes cas réels.
