Local ou cloud : comment arbitrer source par source

Le local n’est pas une option par principe

L’article précédent décrivait un pipeline documentaire entièrement local : OCR, classement, recherche, le tout sans sortie réseau. C’est une architecture valide. Ce n’est pas la seule, et ce n’est pas toujours la plus pertinente.

Beaucoup de structures arrivent avec une idée fixe : « nos données sont sensibles, donc tout doit rester chez nous ». Parfois c’est exact. Souvent c’est plus nuancé : seule une partie des documents pose problème, le volume d’usage ne justifie pas une machine dédiée, ou la contrainte porte sur la traçabilité plutôt que sur l’interdiction totale de modèle externe.

L’enjeu n’est pas de choisir un camp, local ou cloud. C’est de décider source par source ce qui peut sortir, ce qui doit rester, et comment le prouver.

Trois questions avant d’acheter une machine

1. Quelles données sont réellement sensibles ?

Tout un dossier n’est pas toujours au même niveau. Un contrat client avec clauses tarifaires n’a pas la même contrainte qu’un dossier médical ou qu’un courrier couvert par le secret professionnel. Commencer par cartographier les jeux de données, pas par choisir une technologie.

2. Quel volume et quelle régularité d’usage ?

Un modèle local a un coût fixe : matériel, électricité, maintenance, mises à jour. Une API cloud a un coût variable : facturation au token ou à la requête. Les grilles publiques des fournisseurs majeurs (OpenAI, Anthropic, Mistral, etc.) montrent des ordres de grandeur très différents selon le modèle : les variantes « mini » ou compactes restent à bas coût unitaire, les modèles les plus capables coûtent nettement plus cher.

À faible volume (quelques centaines de requêtes par jour, usage ponctuel, équipe restreinte), une API bien choisie reste souvent moins chère qu’un serveur GPU sous-utilisé. À volume élevé et régulier, l’amortissement du local devient compétitif. Le point de bascule dépend du modèle, du contexte envoyé à chaque requête et du taux d’utilisation réel de la machine, pas d’une règle universelle.

3. Qui doit pouvoir auditer quoi est allé où ?

Même avec un modèle externe, on peut documenter : quelles sources ont été interrogées, quels extraits ont été transmis, qui a lancé la requête. Sans cette trace, « on utilise l’IA en interne » devient impossible à défendre devant un DPO, un auditeur ou un client.

Ce qui part vraiment vers un modèle externe

Une confusion revient souvent : « on fait du RAG, donc on n’envoie pas nos documents ».

En pratique, le RAG indexe vos documents chez vous, puis, à chaque question, envoie au modèle les passages retroués et la formulation de la question. Ce n’est pas la base entière, mais ce peut être des extraits nominatifs, des clauses contractuelles, des éléments de santé. Si ces passages contiennent des données personnelles, le RGPD s’applique comme pour tout autre transfert vers un sous-traitant.

La CNIL rappelle que le déploiement d’une IA générative doit être précédé d’une analyse des risques, d’une gouvernance claire (usages autorisés, usages interdits), et, selon les cas, d’une analyse d’impact (AIPD). L’organisme qui déploie le système reste responsable du traitement, pas le salarié qui saisit un prompt ni seulement le fournisseur du modèle.

Pour un modèle hébergé hors Union européenne, le chapitre V du RGPD impose un mécanisme de transfert valide (décision d’adéquation, clauses contractuelles types, etc.) et, depuis l’arrêt Schrems II, une évaluation des garanties effectives dans le pays destinataire. Le cadre EU-US Data Privacy Framework permet des transferts vers certaines entités américaines certifiées, mais ce mécanisme fait l’objet de contestations juridiques : la prudence consiste à ne pas s’y fier comme unique ligne de défense pour des données très sensibles.

Grille d’arbitrage type

Jeu de données	Exemple	Traitement typique	Périmètre
Documents nominatifs ou secrets	dossiers patients, contrats clients, pièces d’identité	RAG local, modèle sur site	LOCAL
Documentation interne non sensible	procédures génériques, modèles de courrier	LLM externe possible, avec DPA	AUTORISÉ SOUS CONDITIONS
Données publiques ou déjà publiées	textes officiels, open data, jurisprudence publique	API cloud	AUTORISÉ
Données métier transactionnelles	ERP, CRM, tickets	agent ou API contrôlée, droits par rôle	CONTRÔLÉ

« Autorisé » ne veut pas dire « sans précaution ». Cela suppose au minimum : contrat de sous-traitance (article 28 RGPD), minimisation des données envoyées, traçabilité, et interdiction d’entraînement du modèle sur vos contenus lorsque le fournisseur le permet contractuellement.

Quand le cloud reste le bon choix

• Usage faible ou irrégulier : pas de GPU à amortir, pas de veille matérielle.
• Données peu sensibles : pas de secret professionnel, pas de catégorie particulière au sens du RGPD.
• Besoin de modèles très capables ponctuellement : synthèse complexe, raisonnement long, là où un modèle local plus petit peinerait.
• Prototypage : tester un cas d’usage avant d’investir dans une infrastructure.

Dans ces situations, prétendre que le local est « plus sûr » sans analyser le flux réel peut conduire à sur-investir pour un gain de conformité illusoire, ou au contraire à exposer des données sensibles faute de garde-fous contractuels.

Quand le local se justifie vraiment

• Obligation réglementaire ou contractuelle de non-transfert, ou réseau isolé sans sortie Internet.
• Volume soutenu : la machine tourne à un rythme qui amortit son coût.
• Traçabilité stricte : savoir qu’aucun extrait n’a quitté le périmètre, sans dépendre des politiques d’un tiers.
• Données qui ne doivent pas transiter, même sous forme d’extraits, vers un modèle externe.

Les modèles quantifiés (formats GGUF, déployés via Ollama ou llama.cpp) permettent des installations sur GPU grand public pour des tailles modérées : un modèle compact tient souvent sur 8 à 16 Go de VRAM, tandis qu’un modèle plus large exige du matériel dédié. Le dimensionnement reste un préalable, pas une conséquence du choix « local » en lui-même.

L’architecture hybride, cas le plus fréquent

En production, beaucoup de structures combinent les deux :

• Local pour les jeux sensibles : index vectoriel, RAG, modèles sur site.
• Cloud autorisé pour les tâches sur données publiques ou faiblement sensibles : reformulation, traduction, brouillon à partir de sources déjà anonymisées.
• Passerelle de routage qui choisit le modèle selon la classification de la source, pas selon l’humeur de l’utilisateur.

L’objectif est explicit : même application, flux différents selon la sensibilité. Sans cette séparation, tout finit par passer par le chemin le plus simple, souvent le cloud par défaut.

L’erreur classique : tout local « par sécurité »

Acheter un serveur GPU, l’installer, puis découvrir que :

• l’usage réel est trop faible pour justifier le coût ;
• personne ne met à jour les modèles ni les dépendances ;
• les utilisateurs contournent l’outil faute de qualité suffisante sur leur cas métier ;
• la conformité n’est pas mieux traitée qu’avec une API, faute de gouvernance (charte, droits d’accès, journaux).

Le local n’exempte pas du RGPD. Il déplace la sous-traitance vers votre propre infrastructure, ce qui simplifie certains dossiers de transfert, pas la gouvernance ni la sécurité opérationnelle.

Ce qu’il faut retenir

• L’arbitrage se fait par jeu de données, pas par slogan « 100 % local » ou « 100 % cloud ».
• Le RAG n’envoie pas toute la base, mais les extraits transmis peuvent suffire à déclencher RGPD et transferts internationaux.
• À faible volume, le cloud reste souvent compétitif ; à volume élevé et régulier, le local peut l’emporter, sous réserve d’un dimensionnement réaliste.
• Local et conformité ne sont pas synonymes : charte d’usage, AIPD si nécessaire, traçabilité et contrats restent obligatoires dans les deux cas.

FAQ

Faut-il choisir entre 100 % local et 100 % cloud ? Rarement. La plupart des structures sensibles adoptent une architecture mixte : local pour le sensible, voie autorisée pour le reste, avec des règles écrites et vérifiables.

Un modèle externe voit-il mes documents entiers en RAG ? Non, sauf mauvaise configuration. Il reçoit typiquement la question et les passages retrouvés. Si ces passages contiennent des données personnelles, le transfert reste soumis au RGPD, même sans export de la base complète.

Le cadre EU-US Data Privacy Framework suffit-il pour envoyer des données sensibles aux États-Unis ? C’est un mécanisme reconnu pour certaines entités certifiées, pas une garantie absolue. Pour des données de santé, des secrets professionnels ou des contraintes contractuelles fortes, le local ou un hébergement et un traitement dans l’UE restent en pratique les options les plus simples à défendre.

Peut-on commencer en cloud et basculer en local plus tard ? Oui, si l’architecture le prévoit : formats ouverts, index réutilisable, séparation entre couche documentaire et couche modèle. Un prototype cloud bien cadré peut valider le cas d’usage avant un investissement matériel.

Qui doit valider l’arbitrage : le DSI, le DPO, le métier ? Les trois. Le métier identifie la sensibilité réelle, le DSI ou l’intégrateur trace les flux techniques, le DPO (ou un conseil RGPD) qualifie les transferts et les bases légales. Une décision technique seule, sans relecture juridique sur les jeux sensibles, est un risque inutile.

Comment savoir si mon usage est « à faible volume » ? Mesurez sur une période représentative : nombre de requêtes par jour, taille moyenne du contexte envoyé, nombre d’utilisateurs simultanés. Comparez ensuite le coût API estimé (grilles publiques des fournisseurs) au coût d’un serveur dédié incluant maintenance et électricité. Si la machine serait idle plus de 80 % du temps, le calcul penche souvent vers l’API, sauf contrainte de non-transfert non négociable.

---

Cet article présente une grille de décision type à titre illustratif. Il ne remplace ni un audit juridique, ni un dimensionnement sur votre volumétrie réelle.

Sources consultées pour la rédaction : FAQ et recommandations CNIL sur l’IA générative (cnil.fr), chapitre V RGPD et arrêt Schrems II (CJUE C-311/18), grilles tarifaires publiques des API LLM, documentation technique sur le déploiement de modèles quantifiés (GGUF, Ollama, llama.cpp).