LLM local ou cloud : grille de décision entreprise
Le choix entre LLM local, cloud ou architecture hybride n’est pas un débat de posture. C’est une décision de gouvernance : quelles données entrent dans le modèle, quelle action peut en sortir, quel niveau de preuve reste disponible, et qui assume l’exploitation dans la durée.
La bonne architecture dépend d’abord des données traitées
La mauvaise question consiste à demander si un LLM local est « plus sûr » qu’un LLM cloud. La bonne question est plus exigeante : quelles données seront envoyées, quels droits d’accès seront ouverts, quelles traces seront conservées, et quelle décision pourra être influencée par la sortie du modèle ? Un même fournisseur cloud peut être raisonnable pour un assistant de rédaction interne et inadapté pour un dossier RH sensible. Un même modèle local peut rassurer sur les flux sortants tout en devenir fragile si personne ne maintient la chaîne d’inférence.
Le cadre français et européen ramène le sujet aux fondamentaux. Les fiches pratiques de la CNIL insistent sur la base légale, la minimisation, l’information des personnes et la sécurité des traitements IA [1]. L’avis de l’EDPB sur les modèles d’IA rappelle que l’anonymisation, la base légale et les données personnelles doivent être appréciées concrètement, pas par simple déclaration fournisseur [2]. Le RGPD reste le socle dès qu’un traitement implique des données personnelles, notamment pour la sous-traitance, la sécurité et les transferts [3].
Pour une entreprise, cela change la méthode. Le choix technique doit venir après la cartographie des cas d’usage. Résumer une documentation publique, interroger un référentiel client, analyser des contrats, classer des tickets support ou préparer une réponse commerciale ne relèvent pas du même niveau de sensibilité. Le modèle n’est qu’un morceau du système : il faut aussi regarder le stockage des prompts, les connecteurs, les journaux, les comptes administrateurs, la reprise humaine et la capacité à expliquer une décision.
Les cadres du NIST aident à structurer cette lecture. L’AI Risk Management Framework distingue gouvernance, cartographie, mesure et gestion du risque [5]. Le profil dédié à l’IA générative ajoute des risques spécifiques : sorties non fiables, dépendance à des modèles ou données instables, attribution insuffisante, contamination par des contenus non maîtrisés [6]. La décision local/cloud doit donc être une décision de contrôle, pas une préférence esthétique.
Cloud, local, souverain et hybride ne répondent pas au même problème
Le cloud apporte une vitesse de déploiement, des modèles performants et une capacité d’absorption du volume. Le local apporte une maîtrise plus forte du périmètre technique. Le cloud qualifié ou souverain cherche à rapprocher l’agilité cloud d’exigences de confiance plus fortes. L’hybride, souvent plus réaliste, route les cas d’usage selon la sensibilité des données. Aucune de ces options n’est premium par nature ; chacune devient bonne ou mauvaise selon son usage.
L’AI Act rappelle que les obligations ne tiennent pas seulement au modèle, mais aussi au rôle de l’organisation, au cas d’usage et au niveau de risque du système [4]. Côté cloud, l’ANSSI distingue les enjeux de confiance, de dépendance, de localisation et de qualification, avec le référentiel SecNumCloud pour les prestataires qualifiés [9] [10]. Côté fournisseurs d’IA, les engagements d’OpenAI pour l’entreprise et la documentation Azure OpenAI détaillent les garanties annoncées sur l’usage des données, l’entraînement, le stockage ou la sécurité [11] [12]. Ces garanties doivent être lues comme des éléments de dossier, pas comme un blanc-seing.
| Architecture | Quand l’envisager | Question à trancher |
|---|---|---|
| Cloud public | Cas d’usage à faible sensibilité, besoin de performance rapide, volumes variables. | Quelles données sortent, sous quelles clauses, avec quelle rétention et quelle réversibilité ? |
| Cloud qualifié ou souverain | Exigence de confiance renforcée, contraintes contractuelles ou sectorielles, besoin cloud persistant. | Le catalogue, le coût et les garanties couvrent-ils vraiment les usages visés ? |
| LLM local | Données à ne pas exposer, latence critique, environnement technique déjà maîtrisé. | L’entreprise possède-t-elle les compétences d’exploitation, de sécurité et de mise à jour ? |
| Architecture hybride | Portefeuille d’usages hétérogène, données sensibles et non sensibles, besoin de routage. | Qui décide quelle tâche va vers quel environnement, et comment ce choix est-il journalisé ? |
La décision robuste ne consiste donc pas à dire « tout local » ou « tout cloud ». Elle consiste à classer les cas d’usage. Une aide à la rédaction peut rester cloud si aucune donnée sensible n’est envoyée et si le contrat est maîtrisé. Une analyse contractuelle peut exiger un environnement plus fermé. Une synthèse commerciale peut être cloud avec anonymisation stricte. Un agent qui agit dans le SI doit être traité comme une extension du système d’information, pas comme une simple interface conversationnelle.
La règle pratique : ne jamais choisir l’architecture au niveau de l’entreprise entière. La choisir par cas d’usage, selon les données, l’action produite, le niveau de preuve requis et la capacité réelle d’exploitation.
La scorecard doit précéder tout engagement fournisseur
Le piège classique consiste à comparer des démonstrations. Une démo montre une sortie fluide, rarement le coût de supervision, la faiblesse des logs, le risque de dépendance ou l’effort de réversibilité. La scorecard doit donc être construite avant la sélection fournisseur. Elle oblige à juger l’architecture sur ce qui pèsera réellement dans l’exploitation.
Données personnelles, secrets d’affaires, RH, finance, santé ou contrats clients exigent un niveau de contrôle supérieur.
Une synthèse interne, une réponse client et une action automatisée dans un SI ne portent pas la même responsabilité.
Comparer tokens, GPU, inférence, supervision, sécurité, maintenance, montée de version et temps de reprise humaine.
Logs, sources, versions de modèles, prompts système et sorties critiques doivent rester auditables.
Le choix doit prévoir migration, changement de fournisseur, conservation des traces et continuité métier.
Le local suppose des compétences de MLOps, sécurité, supervision et optimisation que toutes les organisations ne possèdent pas.
Cette scorecard doit aussi intégrer les contrôles. La Cloud Security Alliance propose une matrice de contrôles IA qui aide à relier modèles, cloud, données, identités, sécurité et gouvernance [8]. L’OWASP rappelle de son côté que les applications LLM exposent des risques spécifiques : injection de prompt, fuite de données, supply chain, permissions excessives, sorties non contrôlées [7]. La question n’est pas seulement « quel modèle répond le mieux ? ». La question est « quel système reste contrôlable quand il répond mal ? ».
Un choix local peut obtenir une très bonne note sur les flux sortants et une mauvaise note sur l’exploitation. Un choix cloud peut obtenir une très bonne note sur la performance et une mauvaise note sur la dépendance fournisseur. Un choix hybride peut être le plus solide, mais seulement si les règles de routage sont simples, documentées et testables. Une architecture hybride mal gouvernée devient vite un compromis illisible : personne ne sait quelles données sont passées où, ni pourquoi.
La sécurité se joue dans les flux, pas dans le slogan
Le cloud exige de regarder les clauses, les sous-traitants, la localisation, l’usage éventuel des données pour l’entraînement, les mécanismes de rétention et les droits d’administration. Le local exige de regarder les accès internes, les modèles téléchargés, la chaîne d’approvisionnement, les vulnérabilités, les logs, les sauvegardes et les mises à jour. Les deux mondes ont leurs risques. Le local ne supprime pas la sécurité ; il la transfère davantage vers l’entreprise.
Le risque existe quelle que soit l’architecture si le modèle lit des documents ou agit avec des outils connectés.
Elle peut provenir d’un fournisseur, d’un mauvais paramétrage interne, d’un log trop bavard ou d’un accès trop large.
Un modèle open source, un poids téléchargé ou une dépendance d’inférence doivent être vérifiés comme un composant logiciel.
Un modèle local performant aujourd’hui peut devenir insuffisant si le coût de mise à jour et d’évaluation n’est pas prévu.
L’OWASP classe explicitement les risques LLM au niveau de l’application : injection, divulgation d’informations sensibles, chaîne d’approvisionnement, permissions excessives ou manipulation des sorties [7]. Ces risques ne disparaissent pas avec un serveur local. Ils changent de forme. Un modèle local branché sur un moteur de recherche interne peut exposer trop de documents si les droits sont mal hérités. Un modèle cloud peut rester acceptable si les données sont filtrées, contractualisées et journalisées. Un assistant connecté au CRM devient plus sensible qu’un simple outil de synthèse.
Les engagements de confidentialité des fournisseurs sont utiles, mais ils doivent être vérifiés contre le cas d’usage. OpenAI indique des garanties entreprise sur l’usage des données et l’entraînement [11]. Microsoft documente les traitements, le stockage, la journalisation et la sécurité d’Azure OpenAI [12]. Ces éléments peuvent soutenir un choix cloud, à condition de lire les paramètres, les régions, les logs, les accès et la réversibilité. La confiance ne se déduit pas du logo du fournisseur.
Inversement, l’argument souveraineté ne suffit pas. L’ANSSI rappelle que le cloud appelle une analyse de confiance, de dépendance et de qualification [9]. SecNumCloud peut être pertinent pour certains contextes, mais il ne transforme pas automatiquement une application IA en dispositif gouverné [10]. La couche modèle, les connecteurs, les comptes, les journaux et les règles d’usage restent à cadrer.
La décision robuste passe par un pilote comparatif
Le pilote utile ne compare pas des promesses commerciales. Il compare trois scénarios sur les mêmes tâches, les mêmes données fictives ou anonymisées, les mêmes critères de qualité et les mêmes contraintes de sécurité. Les résultats doivent montrer le coût, la latence, la qualité, la reprise humaine et les incidents observés. Une démonstration qui ne mesure pas les erreurs, les sorties refusées, les délais, les logs et la maintenance ne permet pas de choisir une architecture.
Choisir trois cas d’usage, classer les données et fixer les critères de réussite.
Tester cloud, local et hybride sur les mêmes tâches et les mêmes jeux anonymisés.
Mesurer qualité, latence, coûts, logs, erreurs, sécurité et reprise humaine.
Choisir l’architecture par cas d’usage, avec règles de routage et réversibilité.
Un audit IA peut établir la matrice de risques, de données et de cas d’usage avant de solliciter les fournisseurs. Le studio digital IA devient pertinent lorsque la décision doit être transformée en prototype, assistant métier ou workflow mesurable. Le bénéfice client est très concret : éviter de payer trop tôt une architecture séduisante mais difficile à exploiter, et concentrer le budget sur les usages qui supportent réellement l’activité.
Si le local est choisi uniquement pour rassurer, il est fragile. Si le cloud est choisi uniquement pour aller vite, il est fragile aussi. Le bon choix est celui dont les risques, les coûts et les contrôles sont explicitement documentés.
Questions fréquentes
Un LLM local est-il toujours plus sûr qu’un LLM cloud ?
Non. Le local réduit certains flux externes, mais il ajoute des responsabilités d’exploitation, de patching, de journalisation, de contrôle d’accès et de supervision. La sécurité dépend du dispositif complet, pas de la seule localisation du modèle. Un audit IA sert justement à qualifier les flux, les données sensibles et les contrôles avant de choisir.
Quand choisir un LLM cloud ?
Le cloud est pertinent pour démarrer vite, accéder à des modèles performants, absorber des volumes variables et bénéficier d’un cadre contractuel clair. Il exige en contrepartie une analyse des données envoyées, des sous-traitants, des transferts éventuels, des logs et des paramètres de rétention.
Quand choisir un LLM local ou souverain ?
Le local devient pertinent quand les données ne doivent pas sortir d’un périmètre maîtrisé, quand les volumes sont stables, quand la latence est critique ou quand l’organisation possède déjà les compétences d’exploitation nécessaires.
L’hybride est-il un compromis faible ?
Non. Une architecture hybride peut être plus robuste si elle route les tâches selon la sensibilité des données : cloud pour les usages généraux, environnement local ou souverain pour les données confidentielles. Le studio digital IA peut ensuite transformer ce routage en assistant, workflow ou prototype mesurable.
Quels coûts comparer ?
Il faut comparer les coûts API, infrastructure, inférence, supervision, maintenance, sécurité, montée de version et reprise humaine. Le prix au token ne suffit pas.
Quel premier livrable demander avant de choisir ?
Le premier livrable utile est une matrice de décision par cas d’usage : données traitées, niveau de sensibilité, exigence de performance, coût prévisible, contraintes de sécurité et scénario de réversibilité. Pour préparer cette décision, il est possible de décrire le contexte LLM local/cloud à farweb.fr afin de cadrer le bon niveau d’accompagnement.
Sources et références
- [1]CNIL — Les fiches pratiques IA — références françaises sur IA, données personnelles, base légale, anonymisation et sécurité.
- [2]EDPB — Opinion 28/2024 on AI models — avis européen sur modèles IA, anonymisation, base légale et données personnelles.
- [3]EUR-Lex — RGPD — texte officiel du Règlement (UE) 2016/679, notamment transferts, sécurité et sous-traitance.
- [4]EUR-Lex — AI Act — texte officiel du Règlement (UE) 2024/1689 sur les systèmes d’intelligence artificielle.
- [5]NIST — AI Risk Management Framework 1.0 — cadre de management des risques IA, gouvernance, cartographie, mesure et contrôle.
- [6]NIST — Generative AI Profile — profil dédié à l’IA générative, risques spécifiques et mesures de gouvernance.
- [7]OWASP — Top 10 for LLM Applications — référence sécurité sur prompt injection, fuite de données, supply chain et contrôle des sorties LLM.
- [8]Cloud Security Alliance — AI Controls Matrix — matrice de contrôles sécurité IA pour cloud, modèles, données et gouvernance.
- [9]ANSSI — Le cloud — ressources officielles françaises sur les usages et niveaux de confiance du cloud.
- [10]ANSSI — SecNumCloud — référentiel de qualification des prestataires de services cloud de confiance.
- [11]OpenAI — Enterprise privacy — engagements OpenAI sur confidentialité, contrôle des données et entraînement pour les offres entreprise.
- [12]Microsoft Learn — Data, privacy and security for Azure OpenAI Service — documentation officielle sur traitement des données, stockage, journalisation et sécurité Azure OpenAI.
Ce sujet concerne votre organisation ? Un premier échange de 15 minutes permet d’évaluer la situation et de décider de la suite.
Échanger avec Raphaël UhlrichSans engagement · 15 min · Strasbourg ou visio