L'IA générative on-premise en entreprise : ce qu'il faut savoir avant de décider.

On-premise, souverain, privé : trois notions distinctes

La confusion entre ces termes est la première cause de mauvaise décision. Un fournisseur peut être parfaitement sincère en disant « souverain » tout en désignant autre chose que ce que vous avez compris. Trois questions différentes se cachent derrière ces mots : où tournent les traitements, qui a un pouvoir juridique sur les données, et qui peut techniquement y accéder.

On-premise : une question de lieu d'exécution

On-premise signifie que le logiciel s'exécute sur une infrastructure que vous contrôlez : vos serveurs, votre datacenter, ou un cloud privé dont vous maîtrisez le périmètre. C'est une propriété d'architecture, pas une promesse contractuelle. Elle se vérifie : vous pouvez regarder les flux réseau sortants.

Souverain : une question de droit applicable

La souveraineté n'est pas la localisation. Une donnée hébergée en France, mais opérée par une entité soumise à une loi extraterritoriale, reste exposée à cette loi. La bonne question n'est pas « où sont mes données » mais « quel droit s'applique à l'entité qui les opère, et qui peut être contraint de les remettre ». C'est ce qui distingue un hébergement européen d'une réelle immunité juridique.

Privé : une question d'accès effectif

Une plateforme privée est une plateforme à laquelle personne d'autre que vous n'accède, y compris l'éditeur. Beaucoup de solutions dites privées conservent un canal de télémétrie, de support ou d'amélioration du modèle. Ce n'est pas illégitime, mais cela doit être explicite, et vous devez pouvoir le couper.

Pourquoi des entreprises choisissent l'on-premise

Le réflexe est d'y voir une position défensive, motivée par la peur. Dans les faits, les organisations qui font ce choix avancent quatre raisons, et une seule relève de la conformité.

• La nature des données. Dossiers patients, pièces de procédure, données de défense, tarification d'assurance, code source : dans certains métiers, l'envoi vers un tiers ne se négocie pas, quel que soit le contrat signé.
• L'exposition juridique. Le RGPD, le secret professionnel et les obligations sectorielles créent une responsabilité qui reste la vôtre, même quand le traitement est délégué. L'architecture est le seul moyen de réduire l'exposition plutôt que de la transférer sur le papier.
• La maîtrise des coûts. Une facturation à l'usage sur un volume qui croît est difficile à prévoir. Une infrastructure interne transforme une dépense variable en dépense capacitaire, que l'on dimensionne et que l'on plafonne.
• L'indépendance vis-à-vis d'un fournisseur. Les modèles changent vite, leurs prix et leurs conditions aussi. Une plateforme qui vous permet de changer de modèle sans redéployer vos cas d'usage vous évite d'adosser votre stratégie à un catalogue que vous ne contrôlez pas.

Ces quatre motifs n'ont pas le même poids selon les organisations. Une DSI qui n'a que le troisième a probablement intérêt à un modèle hybride plutôt qu'à un déploiement complet.

L'architecture réelle d'une plateforme interne

Un déploiement d'IA générative en entreprise ne se réduit pas à héberger un modèle. Le modèle est la brique la plus visible, rarement la plus coûteuse à exploiter. Une plateforme complète comporte cinq couches.

• Le service d'inférence. Le moteur qui exécute les modèles, typiquement vLLM ou Ollama pour des modèles locaux. C'est lui qui consomme le GPU, et c'est son dimensionnement qui détermine le nombre d'utilisateurs simultanés supportables.
• La couche documentaire, ou RAG. L'ingestion, le découpage et l'indexation de vos documents, puis la recherche qui alimente le modèle. C'est ce qui fait la différence entre un assistant générique et un assistant qui connaît votre organisation. C'est aussi la couche qui demande le plus de travail d'exploitation dans la durée.
• L'identité et les droits. Le raccordement à votre annuaire (LDAP, OIDC, SAML) et un contrôle d'accès qui s'applique aussi aux documents indexés. Une base documentaire qui ignore vos droits transforme un moteur de recherche interne en fuite d'information généralisée.
• La gouvernance. Qui a droit à quel modèle, avec quel plafond de dépense, sur quels connecteurs, avec quelle validation humaine sur les actions sensibles. Sans cette couche, une plateforme reste un prototype toléré, pas un service d'entreprise.
• L'observabilité et l'audit. La trace de ce qui a été demandé, par qui, avec quel modèle, sur quelles sources, et pour quel coût. C'est ce qui rend le service défendable devant un auditeur, et pilotable par la DSI.

Les projets qui échouent sous-estiment presque toujours les trois dernières couches. Elles n'ont rien de spectaculaire en démonstration, et ce sont elles qui décident du passage à l'échelle.

Ce que ça coûte vraiment

Comparer un abonnement par utilisateur au prix d'un serveur GPU n'a pas de sens : les deux ne recouvrent pas les mêmes postes. Un coût complet de plateforme interne se décompose en quatre lignes.

• L'infrastructure de calcul. Le poste le plus visible. Il dépend du modèle retenu et surtout du nombre d'utilisateurs simultanés, pas du nombre d'utilisateurs déclarés. Un usage réel est très concentré sur quelques heures de la journée.
• La licence logicielle. La plateforme elle-même. Vérifiez surtout si l'éditeur prend une marge sur l'inférence : dans ce cas, votre facture croît avec votre usage, ce qui reproduit exactement le modèle que vous cherchiez à quitter.
• L'exploitation. Les mises à jour, la supervision, l'ajout de sources documentaires, le support aux métiers. C'est un coût récurrent d'équipe, souvent absent des comparatifs, et rarement nul.
• L'inférence externe éventuelle. Si vous branchez aussi des modèles SaaS pour certains usages, cette consommation reste à votre charge. Contractualiser en direct avec le fournisseur vous garantit d'en connaître le prix réel.

L'arbitrage économique se joue sur le volume et la durée. En dessous d'un certain usage, le SaaS reste moins cher. Au-delà, et surtout sur plusieurs années, la dépense capacitaire devient plus prévisible et souvent plus basse. Le point de bascule dépend trop de votre situation pour qu'un chiffre générique ait la moindre valeur.

Les pièges les plus fréquents

Ces quatre erreurs reviennent projet après projet, et aucune n'est de nature technique.

Croire que local vaut conforme

Héberger un modèle chez vous ne vous met pas en conformité. Le RGPD porte sur la finalité, la minimisation, la durée de conservation et les droits des personnes. Une plateforme interne mal gouvernée qui indexe sans contrôle des données personnelles est un problème de conformité, pas une solution.

Dimensionner sur le nombre d'utilisateurs déclarés

Le dimensionnement se fait sur la simultanéité et sur la longueur des contextes traités, pas sur l'effectif. Un projet dimensionné sur le nombre de comptes est soit surdimensionné et cher, soit inutilisable aux heures de pointe.

Négliger la qualité documentaire

Un RAG branché sur une base documentaire obsolète produit des réponses fausses avec l'assurance d'une réponse sourcée. C'est plus dangereux qu'une absence de réponse, parce que l'erreur est crédible. Le travail sur les sources précède le déploiement, il ne le suit pas.

Se lier à un modèle unique

Construire des cas d'usage sur les particularités d'un modèle donné crée une dépendance forte au moment où le paysage bouge le plus vite. Une plateforme agnostique, où le modèle est une ressource interchangeable, protège l'investissement fait sur les cas d'usage.

On-premise, SaaS ou hybride : comment arbitrer

Le choix n'est pas binaire, et la bonne réponse est souvent un mélange : traitements sensibles en interne, usages banals sur un modèle externe. Cette grille compare les trois options sur les critères qui décident réellement.

En pratique, la question utile n'est pas « quelle option choisir » mais « quels traitements ne doivent jamais sortir ». Une fois cette liste établie, l'architecture en découle presque mécaniquement.