Sommaire
Choisir son architecture

IA on-premise, SaaS ou hybride : choisir usage par usage

La question « on-premise ou SaaS » se pose presque toujours pour toute l'entreprise, alors qu'elle se tranche usage par usage. Un résumé de communiqué de presse et l'analyse d'un dossier médical n'appellent pas la même architecture. Ce guide donne une méthode pour classer ses usages et faire tenir un modèle hybride dans la durée.

Publié le 22 septembre 2026

Le mauvais réflexe : une décision pour toute l'entreprise

Beaucoup de projets commencent par un débat de principe. D'un côté, la direction juridique veut que rien ne sorte. De l'autre, les métiers veulent le meilleur modèle du marché, tout de suite. Chacun a raison pour une partie des usages, et tort pour le reste.

Choisir un seul modèle de déploiement pour toute l'organisation conduit à l'un de ces deux échecs. Tout en SaaS, et les usages sensibles restent interdits, ou se font en douce sur des comptes personnels. Tout en interne, et les usages banals paient le prix d'une infrastructure dimensionnée pour le pire cas, avec des modèles parfois moins performants.

La bonne unité de décision n'est pas l'entreprise, c'est l'usage : une tâche précise, faite par une population précise, sur des données précises. Les définitions d'on-premise, de souverain et de privé, ainsi que l'architecture d'une plateforme interne, sont détaillées dans le guide L'IA générative on-premise en entreprise. Ici, on part de ces notions pour décider.

Classer ses usages selon les données qu'ils touchent

Le critère qui décide n'est ni la fonction de l'utilisateur ni l'outil : c'est la donnée la plus sensible que l'usage peut faire circuler. Trois niveaux suffisent dans la plupart des organisations.

Données publiques ou banales

Contenus déjà publiés, textes génériques, code sans secret. Une fuite n'aurait pas de conséquence notable.

Données internes

Comptes rendus, procédures, échanges clients courants. Elles contiennent souvent des données personnelles, qu'on peut masquer avant envoi.

Données qui ne sortent jamais

Dossiers de santé, pièces de procédure, secrets industriels, données couvertes par un secret professionnel ou une obligation sectorielle.

Trois niveaux de sensibilité, trois réponses d'architecture différentes.

Appliqué à des cas concrets, le classement donne une carte des usages plutôt qu'une doctrine :

UsageDonnée la plus sensibleModèle adapté
Reformuler une offre d'emploi ou un articleAucuneSaaS
Résumer un compte rendu de réunion interneNoms, décisions internesHybride, avec masquage des données personnelles
Répondre à une réclamation clientIdentité, contrat, historiqueHybride, ou modèle local selon le secteur
Interroger la base documentaire RHDossiers individuelsModèle local
Analyser un dossier patient ou une pièce de procédureDonnée de santé, secret professionnelModèle local, sans flux sortant

Le tableau se remplit en atelier avec les métiers, la DSI et le DPO. Il sert ensuite de référence : un nouvel usage se classe d'abord, et l'architecture en découle.

Point de vigilance

La donnée la plus sensible n'est pas toujours dans la question de l'utilisateur. Dans un assistant documentaire, ce sont les extraits de documents ajoutés automatiquement au prompt qui sortent vers le modèle. Un usage anodin en apparence peut transporter un contrat entier.

Les signaux qui tranchent

Quand le SaaS pur suffit

Le SaaS est le bon choix quand l'usage ne manipule que des données du premier niveau, quand il faut aller vite, ou quand l'organisation n'a pas d'équipe pour exploiter une infrastructure. C'est souvent le cas d'un premier pilote sur des contenus publics.

Encore faut-il lire le contrat : durée de conservation des requêtes, usage éventuel de vos données pour entraîner des modèles, lieu de traitement, liste des sous-traitants, droit applicable au fournisseur. Ce dernier point a des conséquences propres, traitées dans le guide sur le Cloud Act et l'IA. Pour certaines données sensibles, un service cloud qualifié SecNumCloud par l'ANSSI constitue une option intermédiaire à examiner.

Quand l'on-premise s'impose

L'hébergement interne, avec un modèle qui tourne chez vous, s'impose dès qu'un usage touche le troisième niveau. Il se justifie aussi quand le réseau doit pouvoir être coupé de l'extérieur, ou quand l'usage est intensif et stable, parce qu'une capacité dimensionnée devient alors plus prévisible qu'une facture à l'usage.

Il a un prix : des modèles limités à ceux dont les poids sont publiés, une infrastructure GPU à dimensionner et une équipe pour l'exploiter. Le choix des modèles eux-mêmes fait l'objet du guide LLM open source ou propriétaire.

L'hybride : ce qui le fait tenir

L'hybride n'est pas un compromis tiède entre les deux. C'est une architecture précise : la plateforme, l'historique des conversations, les documents indexés et les identités restent chez vous, et seuls certains appels au modèle partent vers un fournisseur externe, selon des règles écrites.

  1. La plateforme reste interneHistorique, bases documentaires, mémoire et comptes ne quittent pas votre périmètre, quel que soit le modèle appelé.
  2. Chaque usage a sa règle de routageL'agent ou l'espace de travail est rattaché à un modèle autorisé pour son niveau de sensibilité. Le choix ne repose pas sur l'utilisateur.
  3. Les données personnelles sont masquées avant l'envoiNoms, adresses, numéros sont remplacés par des jetons avant l'appel sortant, puis restaurés dans la réponse.
  4. Ce qui sort est journaliséQuel modèle, pour quel usage, avec quel volume : de quoi répondre à un auditeur et piloter la dépense.
Un hybride tient par ses règles, pas par la vigilance de chaque utilisateur.

La technique de masquage mérite qu'on s'y arrête : anonymiser et pseudonymiser ne produisent pas les mêmes garanties, ni les mêmes obligations. Le guide Anonymiser les données avant un LLM détaille les deux approches et leurs limites.

Côté budget, l'hybride mélange une part fixe et une part variable. La part variable se plafonne, sinon elle finit par dicter l'architecture à votre place. La méthode de chiffrage est dans le guide sur le coût d'une IA générative en entreprise.

Les erreurs à éviter

Décider par l'infrastructure plutôt que par la donnée

« Nous avons des GPU, faisons tout en interne » ou « nous sommes déjà chez tel fournisseur cloud, restons-y » : deux raisonnements qui partent de l'existant au lieu des usages. L'infrastructure disponible est une contrainte, pas un critère de classement.

Laisser l'utilisateur choisir le modèle

Un menu déroulant qui propose tous les modèles à tout le monde, avec une consigne de prudence, ne résiste pas à la première urgence. La règle de routage doit être posée par l'administrateur, au niveau de l'usage.

Oublier les flux secondaires

Le prompt n'est pas le seul flux sortant. Les extraits documentaires, les pièces jointes, les résultats d'outils et parfois la télémétrie de la plateforme partent aussi. Faites l'inventaire complet avant de classer un usage en hybride.

Figer le choix

Un usage classé SaaS aujourd'hui peut basculer en interne demain, parce qu'un modèle ouvert devient suffisant ou que le contrat change. Si vos cas d'usage sont écrits pour un modèle donné, cette bascule devient un projet. Une plateforme où le modèle est une ressource interchangeable la rend réversible.

Questions fréquentes

L'hybride est-il plus complexe à exploiter que le tout interne ?

Il ajoute des fournisseurs externes à suivre, des contrats à gérer et une couche de masquage à maintenir. En contrepartie, il évite de dimensionner l'infrastructure interne pour des usages qui n'en ont pas besoin. La complexité se maîtrise si le routage est centralisé, et non laissé à chaque équipe.

Masquer les données personnelles suffit-il pour envoyer n'importe quel document ?

Non. Le masquage traite les données personnelles identifiables, pas le secret des affaires, les informations stratégiques ni les données couvertes par un secret professionnel. Un document confidentiel sans aucun nom reste confidentiel : il relève d'un modèle local.

Peut-on commencer en SaaS et passer ensuite en on-premise ?

Oui, à condition de l'avoir prévu : des usages décrits indépendamment du modèle, un historique et des documents qui ne sont pas stockés chez le fournisseur, et une sortie possible sans perte. Sans ces précautions, la migration revient à reconstruire.

Où se situe SmartAGT

SmartAGT se déploie on-premise, dans votre périmètre. Le fournisseur de modèle reste votre choix : 100 % local, air-gap possible et sans aucun flux sortant, ou un fournisseur cloud que vous contractez directement.

En mode hybride, les données personnelles sont détectées et pseudonymisées de façon réversible, dans un coffre, avant tout appel sortant, et aucun prompt brut n'est stocké. L'administrateur peut restreindre le catalogue aux fournisseurs européens. Voir la page Sécurité et le modèle tarifaire.

SOUVERAIN PAR ARCHITECTURE

Une question que ces guides
ne tranchent pas ?