IA locale ou IA dans le cloud : quelles différences pour vos données ?

Vous ouvrez un document — un contrat, un compte rendu, un dossier professionnel ou de simples notes — et vous demandez à une intelligence artificielle de le résumer. La question spontanée est : « quelle IA est la meilleure ? » Il en existe une autre, moins visible et souvent plus déterminante : où ce document est-il traité, quelles données quittent votre appareil, et qui contrôle l’infrastructure qui les reçoit ?

C’est l’objet de l’opposition entre « IA locale » et « IA dans le cloud » : utile, mais trompeuse dès qu’on la réduit à un slogan. Voici ce que ces mots désignent, ce qui arrive concrètement aux données, et les questions à se poser avant de confier un fichier à un outil.

IA locale et IA cloud : de quoi parle-t-on ?

Derrière ces deux étiquettes se cachent au moins trois architectures différentes.

IA exécutée sur l’appareil

Le modèle — ou une partie significative du traitement — fonctionne directement sur votre ordinateur ou votre smartphone, en mobilisant sa mémoire et ses puces de calcul : certains traitements sont donc réalisés sans envoyer le contenu à un serveur distant. C’est ce que désigne l’expression IA locale.

Une précision s’impose : « modèle local » ne signifie pas « application hors ligne ». Un logiciel qui exécute un modèle sur l’appareil peut ouvrir des connexions réseau pour s’authentifier, télécharger des mises à jour, synchroniser un historique ou remonter de la télémétrie. L’exécution locale du modèle et le comportement réseau de l’application sont deux choses distinctes.

IA auto-hébergée

Un modèle peut aussi tourner sur un serveur de l’entreprise, une machine dédiée ou un cloud privé administré par l’organisation. La CNIL parle de déploiement « sur site » (*on premise*) et note qu’il limite les risques d’extraction des données par un tiers, au prix d’un coût d’installation et d’exploitation plus élevé.

« Local » et « auto-hébergé » ne sont donc pas synonymes : dans le premier cas les données restent sur l’appareil, dans le second elles circulent vers une machine qu’il faut réellement administrer.

IA dans le cloud

Ici, la requête et les données nécessaires sont transmises à une infrastructure distante exploitée par un fournisseur : l’application prépare la requête, une connexion chiffrée l’envoie vers un service — souvent via une API —, un serveur la traite avec un modèle de langage, puis la réponse revient.

La CNIL distingue l’usage via API des autres modes : la maîtrise du système est alors « quasi exclusivement » entre les mains du fournisseur, ce qui justifie une vigilance particulière sur les données soumises et les conditions contractuelles.

Ce qui arrive réellement à vos données

C’est le point le plus mal compris, parce qu’on confond des opérations différentes. Il en existe au moins six :

1. la transmission : les données quittent l’appareil et circulent sur un réseau ;
2. le traitement : elles sont analysées pour produire une réponse ;
3. le stockage temporaire : elles peuvent séjourner en mémoire ou dans un cache le temps du traitement ;
4. la journalisation : des traces techniques peuvent être enregistrées — l’ANSSI range explicitement les données d’usage, requêtes comme réponses, parmi les éléments à cartographier ;
5. la conservation : une durée de rétention peut s’appliquer, définie par le produit ou le contrat ;
6. la réutilisation : les données peuvent, ou non, servir à améliorer un service ou entraîner un modèle.

Ces étapes ne se déduisent pas l’une de l’autre : une donnée peut être transmise et traitée sans être conservée durablement, ou figurer dans des journaux techniques sans jamais alimenter un entraînement. La CNIL évoque d’ailleurs la possibilité, selon les cas, de désactiver la réutilisation des données d’usage par le fournisseur, voire l’enregistrement de l’historique : il s’agit de réglages et de clauses, pas d’une propriété intrinsèque du cloud.

Le trajet d’une requête : local contre cloud

Deux schémas volontairement simplifiés.

Exemple local

Document → application locale → modèle exécuté localement → réponse

Auxquels s’ajoutent, selon le logiciel, des connexions annexes :

→ authentification du compte → téléchargement de modèles et mises à jour → télémétrie éventuelle → sauvegarde ou synchronisation éventuelle

Exemple cloud

Document → application → connexion réseau → infrastructure du fournisseur → modèle → réponse → journaux éventuels

Un système réel comporte d’autres briques : services frontaux, bases de données, éventuelle base vectorielle pour du RAG, couche de journalisation. Ces schémas situent les étapes ; ils ne décrivent aucun produit précis.

Tableau comparatif

Aucune ligne ne désigne un vainqueur : chacune décrit un compromis à évaluer.

Les avantages possibles d’une IA locale

Une exécution locale peut permettre de traiter certains contenus sans les envoyer à un tiers, de fonctionner sans connexion pour une partie des usages, de maîtriser l’environnement d’exécution et de réduire la dépendance à un service distant. Pour des données personnelles ou de la documentation sensible, la CNIL considère généralement plus opportun de privilégier un déploiement sur site.

Les contreparties sont réelles : matériel, administration système, correctifs, sauvegardes, gestion des accès, protection physique des machines, surveillance. Côté performances, la prudence est de mise : selon la tâche et le matériel, un petit modèle de langage exécuté localement peut suffire — « le local est toujours moins performant » est aussi faux que l’inverse.

Les avantages possibles du cloud

Le cloud donne accès à davantage de puissance sans gérer de matériel, délègue les mises à jour au fournisseur, permet l’accès depuis plusieurs appareils et se déploie souvent plus vite. La CNIL relève qu’une infrastructure mutualisée n’est pas interdite aux petites structures, dès lors que les transferts de données sont encadrés et leur sécurité assurée.

Les contreparties : dépendance à une connexion et à un fournisseur, conditions à comprendre, questions de localisation et de sous-traitance — un transfert hors Union européenne doit être encadré —, contrôles variables selon l’offre, gestion rigoureuse des comptes et des permissions.

Local ne veut pas dire automatiquement privé

Une application peut exécuter son modèle sur l’appareil tout en synchronisant l’historique, en envoyant de la télémétrie, en s’appuyant sur un compte distant, en appelant une API pour des fonctions annexes (recherche, transcription, traduction) ou en créant des sauvegardes en ligne.

La bonne question n’est donc pas seulement « le modèle est-il local ? », mais « quels flux réseau cette application réalise-t-elle réellement ? ». La réponse est dans sa documentation et ses paramètres, pas dans son argumentaire.

Cloud ne veut pas dire automatiquement entraînement

Symétriquement, utiliser un service distant, conserver des données, les journaliser, s’en servir pour améliorer un produit et entraîner un modèle sont cinq opérations distinctes. Les règles varient selon le fournisseur, le produit, la formule grand public ou professionnelle, les paramètres du compte, le contrat et le cadre juridique applicable.

Deux réflexes suffisent souvent : lire la section « données » des conditions du service que vous utilisez réellement, puis ouvrir les paramètres pour voir ce qui est activé par défaut. Ces politiques évoluent : une capture d’écran trouvée en ligne ne vaut pas vérification.

Quelles données éviter d’envoyer à une IA ?

Les recommandations de la CNIL sont explicites : les utilisateurs ne devraient soumettre que des informations qu’ils sont autorisés à partager, et jamais d’informations confidentielles — données personnelles, données de l’entreprise ou de l’administration, en particulier couvertes par un secret — dans un service grand public.

En pratique, restent à l’écart, sauf cadre explicitement prévu :

• les données personnelles non nécessaires à la tâche ;
• les informations confidentielles et les secrets d’affaires ;
• les identifiants, mots de passe et clés d’API ;
• les données de clients, de patients ou d’usagers ;
• les documents internes sensibles ;
• les données concernant des tiers qui ne vous ont rien demandé.

Le principe utile est celui de la minimisation : ne transmettre que ce qui est nécessaire au résultat attendu. Un résumé de contrat n’exige pas toujours les noms, adresses et numéros de compte qui y figurent. Notre guide sur la protection des données personnelles quand on utilise une IA détaille ces réflexes.

À retenir — le bon réflexe n’est pas seulement de demander « local ou cloud ? », mais de savoir quelles données sont nécessaires, où elles sont traitées, combien de temps elles peuvent être conservées et quelles permissions sont réellement accordées.

Et pour une TPE ou un indépendant ?

Trois situations, trois niveaux d’exigence.

Contenu public ou non sensible

Reformuler une publication, corriger un texte destiné à être publié, générer une structure générique : le contenu est déjà public ou anodin, et une solution cloud peut être adaptée selon ses conditions. La CNIL suggère de préférer un compte créé avec une adresse professionnelle dédiée plutôt qu’une adresse personnelle.

Documents professionnels internes

Comptes rendus, procédures, documents commerciaux, fichiers métier : regardez le contrat et la politique de confidentialité, les paramètres du compte, le contrôle des accès et la durée de conservation. La CNIL recommande d’encadrer ces usages par une charte définissant ce qui est autorisé et ce qui est interdit.

Données particulièrement sensibles

Données de santé, informations couvertes par un secret professionnel, éléments stratégiques : le choix de l’outil doit venir après une analyse des données, du besoin et des risques. Aucune architecture ne peut être recommandée universellement ; selon les cas, un délégué à la protection des données ou un conseil juridique est le bon interlocuteur.

Les questions à poser avant de choisir

Une liste de réflexion — pas un audit de conformité :

• Où le traitement principal est-il effectué ?
• Les données quittent-elles l’appareil, et pour quelles fonctions ?
• Le service fonctionne-t-il hors ligne ?
• Certaines fonctions appellent-elles un service distant ?
• Les requêtes sont-elles journalisées, et par qui ?
• Quelle durée de conservation est annoncée ?
• Les données peuvent-elles servir à améliorer ou entraîner un modèle ?
• Existe-t-il un réglage permettant de désactiver certains usages ?
• Qui peut accéder aux données, côté fournisseur comme en interne ?
• Où les données sont-elles hébergées, et un transfert hors UE est-il prévu ?
• Existe-t-il une offre professionnelle aux conditions différentes ?
• Peut-on supprimer les données et révoquer les accès ?
• Que se passe-t-il si le poste local est compromis ?
• Qui est chargé des mises à jour et des correctifs ?

Sécurité : le local déplace une partie du problème

Contrôler son infrastructure apporte des garanties, mais transfère des responsabilités. Les recommandations de l’ANSSI pour un système d’IA générative insistent sur des points qui n’ont rien d’automatique : cloisonner le système dans des environnements dédiés pour limiter les déplacements latéraux d’un attaquant, filtrer les entrées et les sorties, documenter et filtrer les flux réseau avec les applications métier, maîtriser les accès à privilèges, proscrire l’exécution automatisée d’actions critiques sur le système d’information et intégrer la sécurité à toutes les phases du cycle de vie.

La conclusion est inconfortable mais utile : un serveur local mal administré peut être moins sûr qu’un service distant correctement sécurisé — et l’inverse est vrai aussi. Un fournisseur cloud n’est pas sûr par nature : l’ANSSI recommande, pour des données sensibles hébergées dans un cloud public, de privilégier une offre qualifiée.

Performance : pourquoi les gros modèles sont souvent dans le cloud

Un grand modèle a besoin de mémoire pour charger ses paramètres, de puissance de calcul, d’accélérateurs matériels et de parallélisation pour servir plusieurs utilisateurs — ressources plus faciles à concentrer dans un centre de données que sur un ordinateur portable. L’ANSSI note d’ailleurs que le déploiement de tels systèmes implique généralement des processeurs graphiques dédiés.

Cela n’enferme pas le local dans un rôle de figuration : des modèles plus compacts couvrent des usages réels comme la reformulation, le classement ou le résumé court. Le compromis se joue entre contrôle, ressources, simplicité, performances et coût, tâche par tâche.

Une architecture hybride est aussi possible

Rien n’oblige à choisir un camp : un logiciel peut traiter localement les contenus courants et n’appeler un service distant que pour certaines tâches, selon des règles définissant ce qui est autorisé à quitter l’appareil. Cette approche mérite la même évaluation que les autres — « hybride » ne signifie pas « sécurisé » : tout dépend de la règle de routage, de sa fiabilité et de ce qui est effectivement envoyé lorsqu’elle s’applique.

Où MCP et les agents IA interviennent-ils ?

Ces questions se posent avec plus d’acuité dès que l’IA cesse d’être une simple zone de texte. Le Model Context Protocol normalise la façon dont une application d’IA se connecte à des ressources et des outils, qu’ils tournent sur votre machine ou à distance : la frontière se déplace alors vers ce que chaque serveur expose et ce que l’application autorise.

De même, un agent IA manipule davantage de données qu’un échange conversationnel, puisqu’il lit, écrit et enchaîne des actions à travers plusieurs outils. Les permissions, le cloisonnement, la provenance des outils installés et la validation humaine avant une action sensible deviennent les vrais garde-fous — indépendamment du lieu où tourne le modèle.

Alors, faut-il choisir local ou cloud ?

Préférer éventuellement le local

Lorsque fonctionner hors connexion est important, lorsque garder certains traitements dans une infrastructure contrôlée est une priorité, lorsque l’organisation dispose réellement des compétences pour administrer le système, et lorsque les performances requises sont compatibles avec le matériel disponible.

Préférer éventuellement le cloud

Lorsque la simplicité de déploiement, la puissance de calcul, la disponibilité, la maintenance déléguée et l’accès depuis plusieurs appareils comptent davantage, et que les données concernées sont compatibles avec les conditions du service.

Le meilleur choix peut être hybride

Dans beaucoup d’organisations, la réponse raisonnable combine les deux : un service distant pour les usages courants, un traitement contrôlé pour le reste. La décision dépend des données et de leur sensibilité, des usages, des compétences, du matériel, des exigences de sécurité, des conditions contractuelles et du budget. Il n’y a pas de vainqueur universel.

Conclusion

Le lieu où fonctionne le modèle compte : il détermine si un contenu traverse un réseau, qui exploite la machine qui le traite et qui répond des incidents. Mais il ne suffit pas à établir la confidentialité d’un système. Ce qui compte réellement, c’est le trajet complet de la donnée : collecte, transmission, traitement, stockage, journalisation, réutilisation éventuelle, suppression.

Deux outils « locaux » peuvent se comporter très différemment ; deux services « cloud » aussi. Les documents de la CNIL et de l’ANSSI convergent sur une même méthode : partir du besoin et des données, puis choisir l’architecture — jamais l’inverse.

Avant de confier un document à une IA, demandez-vous donc moins si elle est « locale » ou « dans le cloud » que ce qu’elle fera concrètement de ce document.

Questions fréquentes

Une IA locale fonctionne-t-elle toujours sans Internet ?

Non. Le modèle peut s’exécuter sur l’appareil tandis que l’application a besoin du réseau pour l’authentification, les mises à jour ou des fonctions annexes. Le fonctionnement hors ligne dépend du logiciel, pas de l’étiquette « local ».

Une IA locale peut-elle envoyer des données dans le cloud ?

Oui, selon l’application : synchronisation d’historique, sauvegarde en ligne, télémétrie ou appel d’une API pour une fonction précise sont possibles. La documentation et les paramètres font foi.

Une IA cloud utilise-t-elle automatiquement mes données pour s’entraîner ?

Non, ce n’est pas automatique. Cela dépend du fournisseur, du produit, du type de compte, du contrat et des paramètres — la CNIL évoque explicitement la possibilité de s’opposer à la réutilisation des données d’usage. La seule réponse fiable est celle de la documentation du service, à la date où vous l’utilisez.

Une IA locale est-elle forcément plus sécurisée ?

Non. Elle offre plus de contrôle, mais la sécurité dépend de l’appareil, du système, des accès, des mises à jour et de l’administration réelle — conditions que l’ANSSI détaille et qui ne se mettent pas en place d’elles-mêmes.

Peut-on utiliser une IA avec des documents confidentiels ?

Cela ne se règle pas par oui ou non : il faut évaluer la sensibilité des données, l’architecture retenue, les conditions du service et les règles internes. La CNIL recommande d’éviter la saisie d’informations confidentielles dans un service grand public et d’encadrer ces usages par une politique interne.

Quelle solution choisir pour une petite entreprise ?

Partez du besoin et des données, pas de la technologie : identifiez les tâches visées et le type d’informations en jeu, puis regardez quelles solutions y répondent à des conditions acceptables. Combiner un service distant pour les contenus non sensibles et un traitement plus contrôlé pour le reste est souvent la voie la plus réaliste.

Sources officielles

• CNIL — Les questions-réponses de la CNIL sur l’utilisation d’un système d’IA générative
• CNIL — Comment déployer une IA générative ? La CNIL apporte de premières précisions
• CNIL — Intelligence artificielle (IA)
• ANSSI — Recommandations de sécurité pour un système d’IA générative (guide PDF)