Sophie M. dirige un cabinet d'expertise comptable et de gestion de paie de dix-huit salariés, en périphérie lyonnaise. Le portrait qui suit est un cas composite, fictif mais représentatif des dossiers que je croise depuis deux ans : il agrège des situations réelles sans désigner personne. Au printemps 2025, Sophie veut déployer un assistant IA pour soulager ses collaborateurs sur la saisie et la recherche documentaire. Une exigence, non négociable : aucune donnée client ne doit quitter ses murs. D'où une conviction de départ — il faut un hébergement on-premise d'un LLM pour ces données sensibles, point final.

Cette intuition est saine. Elle est aussi, le plus souvent, mal chiffrée. Selon l'étude McKinsey State of AI 2024, une part majoritaire des initiatives d'IA générative ne dépasse jamais le stade du pilote, et la question de l'hébergement des données figure parmi les premiers points de friction. Ce retex retrace les six semaines pendant lesquelles Sophie a confronté son intuition au TCO réel, au cadre du RGPD et au règlement (UE) 2024/1689 sur l'IA. Verdict : la bonne réponse n'était ni le datacenter maison qu'elle imaginait, ni le cloud grand public qu'elle redoutait. Cet article est écrit pour les dirigeants de TPE et PME qui se posent exactement la même question.

Le déclencheur : le Cloud Act plus que le RGPD

Quand on creuse son dossier, la crainte première de Sophie n'est pas le RGPD au sens strict — elle le maîtrise plutôt bien — mais le Cloud Act américain. Cette loi de 2018 permet aux autorités des États-Unis de réclamer des données détenues par un prestataire de droit américain, y compris lorsque ces données sont stockées sur des serveurs situés en Europe. Pour un cabinet soumis au secret professionnel comptable, l'idée que des bulletins de paie ou des liasses fiscales puissent, en théorie, être visés par une réquisition extraterritoriale est rédhibitoire.

Le RGPD vient ensuite. Le règlement impose une base légale, une minimisation des données et une maîtrise des sous-traitants. Faire transiter des données sensibles par un LLM grand public, dont les conditions d'utilisation autorisent parfois la réexploitation des contenus pour l'entraînement, expose le cabinet à un risque de conformité réel. S'ajoute le règlement (UE) 2024/1689 sur l'IA — l'AI Act — entré en application de façon progressive depuis 2025, qui impose des obligations de transparence et de gouvernance selon le niveau de risque du système.

« Je voulais pouvoir dire à mes clients que rien ne sort de chez nous », résume Sophie. C'est de là que naît la conviction qu'un hébergement on-premise d'un LLM est la seule réponse acceptable pour des données sensibles. L'intuition se défend : héberger le modèle sur ses propres serveurs supprime, sur le papier, l'exposition au Cloud Act et simplifie la cartographie RGPD. Le baromètre annuel du Cesin confirme d'ailleurs que la souveraineté des données et la dépendance aux fournisseurs cloud non européens figurent parmi les préoccupations récurrentes des responsables sécurité français. Reste que « sur le papier » et « dans le budget » sont deux mondes distincts — et c'est le second qui a fait vaciller le projet.

Le chiffrage qui refroidit : le vrai TCO d'un LLM on-premise

Le terme « on-premise » recouvre une chaîne de coûts que l'enthousiasme initial sous-estime presque toujours. Premier poste : le matériel. Faire tourner un LLM ouvert de taille sérieuse en local exige un ou plusieurs serveurs équipés de GPU récents. Selon les configurations et le niveau de redondance visé, l'investissement matériel se compte couramment en dizaines de milliers d'euros, hors maintenance — un ordre de grandeur que tout intégrateur confirmera.

Deuxième poste, plus insidieux : les compétences. Un LLM auto-hébergé ne se gère pas seul. Il faut du MLOps — déploiement, supervision, mises à jour du modèle, gestion des versions, monitoring des performances. Or ces profils sont rares et coûteux, et un cabinet de dix-huit personnes ne les a pas en interne. La sous-traitance de cette exploitation représente un abonnement récurrent qui s'ajoute à l'investissement initial.

Troisième poste, le plus souvent oublié : l'obsolescence. Un modèle installé en 2025 sera dépassé en dix-huit mois. Le on-premise fige une version ; le rythme des modèles de fondation, lui, ne ralentit pas. Maintenir la pertinence suppose de réinvestir régulièrement, en matériel comme en intégration.

Mis bout à bout, le TCO d'un hébergement on-premise d'un LLM pour des données sensibles, à l'échelle d'une PME, devient difficilement justifiable face au volume d'usage réel. Sophie projetait quelques centaines de requêtes par semaine. Rapporté à ce volume, le coût unitaire d'une infrastructure dédiée explose. À l'inverse, une approche à l'usage — facturée à l'action, sans engagement — ramène le coût à la consommation effective. C'est précisément la logique d'un modèle en pay-per-use, où l'on paie chaque action plutôt qu'un cluster GPU qui dort la nuit. La question n'est donc pas « cloud ou on-premise ? » dans l'absolu, mais « quel niveau de maîtrise pour quel volume, à quel prix ? ».

La bonne question : quelles données sont réellement sensibles ?

Le tournant du dossier tient à une question simple, posée par le DSI mutualisé qui accompagnait Sophie : « De toutes vos données, lesquelles sont réellement sensibles, et lesquelles transitent vraiment par l'IA ? » La réponse a désamorcé le débat.

La majorité des tâches visées — rédiger un courrier de relance, résumer une note d'instruction fiscale, classer des e-mails entrants, répondre à une question de procédure interne — ne nécessite jamais d'injecter l'intégralité d'un dossier client dans le modèle. Les données les plus sensibles, à savoir les éléments nominatifs de paie et les coordonnées bancaires, restent dans le logiciel métier et n'ont aucune raison d'alimenter un prompt.

De cette segmentation découle une architecture plus sobre. Les documents de référence non nominatifs peuvent être vectorisés pour un usage en RAG (Retrieval Augmented Generation), tandis que les données vraiment sensibles sont pseudonymisées avant tout traitement, ou tout simplement exclues du périmètre. On ne protège bien que ce que l'on a d'abord trié.

Cette discipline change la donne. Une fois les données critiques mises de côté, l'exigence d'un hébergement intégralement on-premise perd de sa force : il ne reste à traiter que des contenus à faible sensibilité, pour lesquels un cloud européen sous contrat de sous-traitance conforme au RGPD suffit largement. Pour les tâches comptables récurrentes, un agent spécialisé comme Max, l'agent comptable de Praxia, traite la TVA, les relances ou les notes de frais sans avoir besoin d'accéder au cœur sensible du système d'information. La sensibilité n'est pas un attribut du projet entier : c'est un attribut de chaque donnée, prise une par une.

Ce qui peut mal tourner avec un on-premise sous-estimé

Le on-premise n'est pas qu'une affaire de budget. Mal exécuté, il peut dégrader la sécurité qu'il était censé renforcer. Plusieurs pièges reviennent.

Sur ce dernier point, l'accompagnement compte. Cadrer les mentions d'information, les bases légales et les clauses contractuelles n'est pas une option. Un appui comme Justine, la juriste IA de Praxia, aide à dégrossir la mise en conformité RGPD et les CGV — étant entendu qu'un litige sérieux relève d'un avocat, pas d'un agent. Le réflexe « on-premise = je suis tranquille » est précisément celui qui mène aux mauvaises surprises d'audit.

La décision : maîtrise des données sans datacenter maison

Au terme de ses six semaines d'analyse, Sophie n'a retenu ni le datacenter maison ni le cloud grand public. Elle a opté pour une approche hybride, structurée autour de trois principes.

D'abord, la souveraineté par le choix du fournisseur plutôt que par le matériel. Des acteurs européens — Mistral pour les modèles, OVHcloud, Scaleway ou Outscale pour l'infrastructure — offrent des garanties de localisation et de non-soumission au Cloud Act, sans imposer d'acheter ses propres serveurs. Pour la grande majorité des PME, c'est le meilleur compromis entre maîtrise et coût.

Ensuite, la contractualisation. Un accord de traitement des données (DPA) clair, l'interdiction de réutiliser les contenus pour l'entraînement, et un engagement de localisation européenne couvrent l'essentiel du risque RGPD pour des données à sensibilité modérée.

Enfin, le vrai on-premise réservé au seul périmètre qui le justifie. Pour les organisations qui doivent absolument tout garder en interne — secteur réglementé, données ultra-sensibles, exigence contractuelle d'un client grand compte — une installation dédiée chez le client garde tout son sens. C'est l'objet de l'Édition Entreprise de Praxia, une installation sur site facturée 1 490 € en one-shot avec douze mois de mises à jour, qui réserve le coût d'un déploiement local aux cas qui le méritent vraiment, plutôt que d'en faire la règle par défaut.

Pour le quotidien — support, marketing, prospection, comptabilité — Sophie utilise désormais des agents en ligne sur données non sensibles, via des formules d'abonnement lisibles dont elle pilote le périmètre. Le projet a abouti parce qu'il a cessé de poser la mauvaise question. La souveraineté ne se résume pas à l'emplacement d'un serveur : elle se construit par le tri des données, le choix des fournisseurs et la rigueur contractuelle. Vous trouverez l'éventail des agents et des usages sur Praxia AI.

En conclusion

Le cas de Sophie, fictif mais fidèle aux dossiers du terrain, illustre une règle simple : la question de l'hébergement on-premise d'un LLM pour des données sensibles est moins technique que méthodologique. Avant de chiffrer un cluster GPU, il faut trier ses données, mesurer son volume réel d'usage et lire les contrats. Trois recommandations, par ordre de priorité :

  1. Cartographier la sensibilité donnée par donnée avant toute décision d'infrastructure. La plupart des tâches ne touchent pas au cœur sensible du SI.
  2. Calculer le TCO complet — matériel, MLOps, obsolescence — et le rapporter au volume réel de requêtes avant d'écarter le cloud souverain européen.
  3. Réserver le on-premise intégral aux seuls périmètres qui l'exigent vraiment, et traiter le reste avec des garde-fous, un DPA solide et une validation humaine.

La souveraineté bien comprise n'est pas un mur, c'est une discipline.