IA locale ou cloud : comment choisir l’hébergement de votre assistant ?

Intelligence artificielle

Un serveur dans vos locaux ne garantit pas, à lui seul, la confidentialité. Une offre cloud ne décrit pas tous les flux. Voici une grille pour comparer les architectures et préparer une décision documentée.

Choisir entre une IA locale et une IA dans le cloud demande de comparer l’ensemble du service : données transmises, lieu d’exécution du modèle, accès de maintenance, exploitation, coût et possibilité de changer de solution. Le bon point de départ n’est donc pas « Quel serveur acheter ? », mais « Quel usage autorisons-nous, avec quelles informations et sous la responsabilité de qui ? ».

Ce guide concerne un assistant professionnel, notamment documentaire ou administratif. Il aide une direction, une équipe métier et ses interlocuteurs informatiques à préparer leur décision. Il ne valide pas une architecture particulière et ne constitue ni un audit de sécurité ni un avis juridique. Une utilisation clinique demanderait une analyse spécifique supplémentaire.

IA locale, cloud privé et API : remettre les mots à leur place

Une IA sur site exécute les composants considérés sur une infrastructure de l’organisation. Une infrastructure distante peut héberger une application et un modèle dédiés. Une API est une interface qui permet à un logiciel de solliciter un service : elle ne désigne pas un lieu d’hébergement.

La FAQ de la CNIL, section 5, distingue les déploiements sur site, sur infrastructure cloud et par API. Elle invite à choisir selon le cas d’usage et les données. Pour des informations sensibles, elle souligne l’intérêt d’une maîtrise renforcée ; pour un hébergement externe, elle rappelle l’importance du contrat et des responsabilités.

Ces catégories peuvent se combiner. Une interface installée sur un serveur interne peut appeler un modèle distant. Un modèle hébergé chez un prestataire peut être exploité sous le contrôle de votre équipe. Demandez donc un schéma des flux, plutôt qu’une réponse limitée au mot « local » ou « privé ».

Dessiner le parcours d’un document avant de comparer les offres

Voici une proposition de travail originale : prenez un document fictif représentatif et décrivez son trajet, depuis l’ajout jusqu’à sa suppression. L’exercice sert à préparer les questions à poser aux équipes techniques. Il ne faut pas utiliser un dossier réel confidentiel pour tester un service dont le cadre n’est pas encore établi.

  1. Entrée : qui s’authentifie, qui dépose le fichier et où celui-ci arrive-t-il ?
  2. Préparation : un service extrait-il le texte ou transforme-t-il le contenu avant la recherche ?
  3. Recherche et génération : quels composants sélectionnent les passages et produisent la réponse ?
  4. Conservation : où restent le fichier, les échanges, les traces et les sauvegardes ?
  5. Sortie : comment retire-t-on le document et comment vérifie-t-on ce retrait ?

Un point laissé « à confirmer » doit rester visible dans la comparaison. L’absence d’information n’équivaut pas à une absence de transfert. Le registre des usages et outils IA aide à rattacher ce schéma à un propriétaire métier et à une finalité.

Une grille de choix pour comparer des architectures complètes

Le tableau ci-dessous est une grille de discussion proposée pour cet article, pas un classement de fournisseurs. Pour chaque ligne, demandez un document, une démonstration ou un engagement contractuel adapté. Une déclaration commerciale seule peut laisser la question ouverte.

Choisir un hébergement d’assistant IA : les vérifications à documenter avant l’arbitrage
CritèreQuestion à instruireÉlément à obtenir
Données et fluxQuels contenus quittent chaque composant, et vers quelles destinations ?Schéma de flux incluant les services associés et les tiers.
AccèsQui peut consulter les documents, les échanges et les traces, y compris pour le support ?Rôles, habilitations et conditions d’intervention explicites.
ExploitationQui assure les mises à jour, les sauvegardes et la réponse aux incidents ?Répartition des responsabilités et engagements de service.
Utilité métierLa solution répond-elle aux tâches attendues dans les conditions réelles d’usage ?Jeu de tests représentatif, limites et décision de validation.
Coût completQuelles ressources faut-il mobiliser au démarrage puis pendant l’exploitation ?Hypothèses de charge, postes de coût et conditions de dépassement.
RéversibilitéQue récupère-t-on et que faut-il reconstruire si le service change ?Formats d’export, procédure de sortie et essai de restitution.

Quand étudier sérieusement un déploiement sur site ?

Un déploiement sur site mérite une étude lorsqu’un projet demande une maîtrise forte de son environnement et que l’organisation peut en assumer les contraintes. Dans la comparaison, faites apparaître les personnes disponibles pour l’exploitation, les capacités de calcul nécessaires et les modalités de support. Posséder un équipement ne règle pas ces questions.

Il faut aussi distinguer « fonctionne sur le réseau interne » et « fonctionne sans dépendance extérieure ». La bonne question à faire tester est celle du fonctionnement attendu lorsqu’un service distant devient indisponible. Définissez le périmètre de ce test avec l’équipe informatique, sans conclure qu’un simple débranchement valide la sécurité de l’ensemble.

Enfin, le choix de l’infrastructure ne résout pas celui des connaissances utiles à l’assistant. Pour cette autre décision, consultez les différences entre RAG et fine-tuning. Une architecture documentaire et un mode d’hébergement répondent à des questions distinctes.

Quand une infrastructure cloud peut-elle convenir ?

Une infrastructure distante peut être examinée pour disposer d’un service exploité par un tiers, mutualiser certains moyens ou adapter une capacité au besoin. Ces possibilités sont à vérifier dans l’offre retenue : elles ne constituent pas des avantages garantis de tout service cloud.

Demandez qui opère chaque composant, dans quels lieux, avec quelles interventions possibles et quelles règles de conservation. Comparez aussi les scénarios de défaillance : indisponibilité du fournisseur, changement de modèle ou arrêt d’une fonctionnalité importante. Un engagement de disponibilité doit être lu avec son périmètre et ses exclusions.

La confidentialité ne se déduit ni de la nationalité commerciale d’un prestataire ni de la présence d’un serveur en France. Ces informations peuvent compter dans l’analyse, mais elles ne remplacent pas l’examen des flux, des accès, des sous-traitants et du cadre applicable.

Données de santé : ne pas réduire l’analyse au sigle HDS

Pour les structures de santé, l’Agence du Numérique en Santé précise le champ de l’obligation HDS. Elle repose notamment sur la nature des données, les activités à l’occasion desquelles elles ont été recueillies et l’hébergement réalisé pour le compte des personnes ou organismes concernés. Ces conditions sont à examiner ensemble, au cas par cas.

N’affirmez donc ni que tout projet IA d’un hôpital exige automatiquement la même architecture, ni qu’une mention HDS chez un prestataire valide l’ensemble du projet. Faites examiner la chaîne et le périmètre réellement concernés par les interlocuteurs compétents. Les données d’un assistant RH, par exemple, demandent leur propre analyse ; elles ne doivent pas être assimilées sans examen à un dossier patient.

Le guide de l’ANSSI sur la sécurité des systèmes d’IA générative apporte un autre regard, celui de la sécurisation de l’architecture. Sa présentation précise qu’il ne traite pas la qualité métier, l’éthique ni la protection des données personnelles. Additionner les bons interlocuteurs est donc plus utile que chercher un label censé répondre à toutes les questions.

Un exemple fictif pour préparer une décision, sans choisir à votre place

Scénario pédagogique entièrement fictif. Un établissement veut aider ses équipes support à retrouver des informations dans des consignes internes. Le premier périmètre exclut les dossiers patients et les informations individuelles des salariés. La direction hésite entre un serveur interne et un service distant dédié.

Avant de comparer les prix, le groupe projet sélectionne un corpus fictif, décrit les droits de consultation et prépare quelques recherches représentatives. Il demande ensuite deux propositions fondées sur le même besoin, avec une description des flux et de l’exploitation. Si une proposition inclut un service de traitement documentaire extérieur non annoncé, ce point retourne dans l’analyse au lieu d’être considéré comme un détail.

Le groupe pourrait retenir une expérimentation limitée, demander des garanties supplémentaires ou différer le projet. Cet exemple ne rapporte aucun déploiement client ni résultat obtenu. Il montre comment rendre les options comparables avant un arbitrage.

Coût complet et sortie : prévoir l’après-démonstration

Pour établir votre propre comparaison, répartissez les postes en trois ensembles : mise en place, fonctionnement courant et sortie. Dans le premier figurent notamment la préparation documentaire et l’intégration. Dans le deuxième, faites préciser les ressources d’exploitation et de support. Dans le troisième, demandez ce qu’il faut restituer, exporter ou reconstruire.

Un coût par requête ne suffit pas à décrire cette organisation. Un achat de matériel non plus. Demandez des hypothèses explicites : utilisateurs attendus, concurrence des demandes, disponibilité requise et volume documentaire. Sans ces éléments, une estimation basse peut simplement correspondre à un autre service que celui dont vous avez besoin.

Écrivez enfin ce qui autorisera la mise en service : données permises, résultats des tests, responsables, incidents à signaler et retour possible au fonctionnement standard. La grille de tests d’un assistant IA complète la décision d’hébergement ; elle ne la remplace pas.

Pour cadrer vos besoins, les services IA de DEMETER SANTÉ articulent notamment acculturation, analyse des usages et gouvernance. Vous pouvez présenter votre contexte pour préparer une démarche adaptée avec vos équipes et vos interlocuteurs techniques. Aucune architecture n’est déclarée conforme sur la seule base de cet article.

Questions fréquentes

Une IA locale fonctionne-t-elle forcément sans Internet ?

Non. Une interface ou un modèle peut être installé sur site tout en utilisant d’autres services distants. Il faut examiner les composants et tester le fonctionnement attendu sans ces dépendances, dans un périmètre défini avec l’équipe informatique.

Quelle différence entre cloud privé et API d’IA ?

Le cloud privé décrit une organisation d’infrastructure à préciser dans l’offre. Une API est un mode d’accès à un service. Les deux notions ne s’excluent pas et ne renseignent pas, à elles seules, sur les lieux de traitement ou les accès aux données.

Un hébergement en France suffit-il pour protéger les données ?

La localisation est un élément de l’analyse, pas une garantie globale. Les flux, les intervenants, les accès de support, les conditions contractuelles et les règles applicables doivent aussi être examinés.

Faut-il acheter un serveur avant de tester un assistant ?

Commencez par définir l’usage, les données autorisées et les critères de test. Une expérimentation avec des données fictives peut aider à préciser le besoin, sans préjuger de l’architecture qui sera autorisée pour la production.

Le RAG impose-t-il un hébergement local ?

Non. Le RAG décrit une manière de rechercher des informations pour contextualiser une réponse. Son hébergement reste une décision distincte, à étudier selon le corpus, les droits d’accès, les flux et les contraintes de l’organisation.

Sources et méthode

Article rédigé le 19 octobre 2026 sous la signature éditoriale de Dimitri Jorand. Sources primaires consultées à cette date. Préparation rédactionnelle assistée par IA et contrôle documentaire des références. Les exemples sont fictifs ; les grilles et propositions pratiques sont originales. Ce support d’information ne remplace pas une analyse de votre situation par les interlocuteurs compétents ni les procédures de votre structure.

Sources