Déployer un LLM on-premise conforme nLPD : par où commencer
Garder vos données et votre IA dans vos murs est devenu réaliste. Voici comment nous abordons ces projets, les décisions qui comptent vraiment, et les pièges que nous voyons le plus souvent.
Pourquoi la question se pose maintenant
Il y a deux ans, faire tourner un modèle de langage utile dans ses propres murs supposait un investissement matériel difficile à justifier. Ce n'est plus le cas. Les modèles à poids ouverts ont gagné en qualité pendant que leur taille utile diminuait, et un serveur équipé d'un seul GPU professionnel couvre aujourd'hui la majorité des usages d'entreprise.
Trois motivations reviennent chez nos clients : la conformité, les secrets d'affaires, et la maîtrise. Elles ne pèsent pas du même poids selon les secteurs, et il vaut la peine de les séparer plutôt que de les confondre dans un argument unique.
Ce que la nLPD exige réellement
Écartons d'abord un raccourci fréquent : la nLPD n'interdit pas d'envoyer des données personnelles à l'étranger, elle encadre cette communication. Le transfert est admis vers un État dont le Conseil fédéral considère que la législation assure une protection adéquate, ces États figurant sur une liste officielle. À défaut, il faut des garanties : clauses contractuelles types, règles d'entreprise contraignantes, ou l'une des exceptions prévues par la loi.
Pour les États-Unis, la Suisse reconnaît depuis 2024 le Swiss-U.S. Data Privacy Framework : une entreprise américaine certifiée sous ce cadre est réputée offrir une protection adéquate. Le fournisseur d'IA que vous envisagez est peut-être certifié. Encore faut-il le vérifier, le documenter, et suivre dans le temps le sort d'un cadre dont l'histoire récente montre qu'il n'est pas éternel.
C'est précisément là que l'auto-hébergement gagne. Il ne rend pas le problème plus facile à résoudre : il le fait disparaître. Pas de communication à l'étranger, donc pas d'analyse de transfert à tenir à jour, et pas de dépendance à la validité d'un cadre d'adéquation que vous ne contrôlez pas.
Restent les obligations qui ne disparaissent pas : inscrire le traitement dans votre registre des activités, informer les personnes concernées, fixer les durées de conservation, et conduire une analyse d'impact si le traitement présente un risque élevé. Un modèle hébergé chez vous n'exonère de rien de tout cela.
Ce qui précède décrit notre pratique d'ingénieurs et ne remplace pas un avis juridique.
Choisir le modèle : le plus petit qui réussit
La bonne question n'est pas « quel est le meilleur modèle » mais « quel est le plus petit modèle qui réussit ma tâche ». La différence de coût entre les deux réponses est considérable, et la différence de qualité perçue par l'utilisateur est souvent nulle.
Un modèle de 8 à 30 milliards de paramètres, éventuellement quantisé en 8 ou 4 bits, couvre l'extraction, la classification, la synthèse et les questions-réponses sur corpus documentaire. Les familles à poids ouverts courantes sont toutes des points de départ défendables.
On tranche en mesurant sur sa propre tâche, jamais en lisant un classement public. Un modèle qui domine un banc d'essai généraliste peut échouer sur votre vocabulaire métier, et l'inverse arrive tout autant.
Dimensionner le matériel
Trois grandeurs commandent le dimensionnement : la taille du modèle en mémoire, la longueur de contexte, et le nombre de requêtes simultanées.
La mémoire vidéo nécessaire tient approximativement au nombre de paramètres multiplié par la précision retenue. Un modèle de quatorze milliards de paramètres servi en 8 bits demande de l'ordre de quatorze gigaoctets, environ sept en 4 bits, auxquels s'ajoute le cache d'attention qui croît avec la longueur de contexte et le nombre d'utilisateurs simultanés.
En pratique, un serveur doté d'un GPU professionnel de quarante-huit gigaoctets absorbe confortablement un modèle de cette classe pour quelques dizaines d'utilisateurs internes. Commencez petit, mesurez, puis grandissez. L'inverse coûte cher et n'apporte rien : un GPU surdimensionné ne rend pas les réponses meilleures.
RAG avant fine-tuning
Le réflexe « il faut entraîner le modèle sur nos données » est presque toujours prématuré. La génération augmentée par récupération, le RAG, apporte la connaissance métier au moment de la requête plutôt que de l'enfouir dans les poids du modèle.
Trois raisons de commencer par là. La connaissance métier change, et un index se met à jour en quelques minutes là où un réentraînement prend des jours. Le fine-tuning n'apprend pas des faits de manière fiable, il ajuste un style et un format. Et surtout, seul le RAG permet de citer la source, ce qui est la condition d'usage dans tout contexte réglementé.
Réservez donc le fine-tuning aux cas où la sortie doit respecter un format strict ou un ton très particulier, et jamais pour injecter du savoir.
Évaluer avant de déployer
C'est le point que les projets d'IA ratent le plus souvent, et de loin. Sans jeu de test métier, il est impossible de savoir si le système régresse quand on change de modèle, de prompt, de découpage ou de base documentaire. Or on change tout cela en permanence.
Un jeu d'évaluation utile est court et réel : trente à cent questions posées par les futurs utilisateurs, la réponse attendue, et le passage du corpus qui la justifie. On y ajoute des questions dont la réponse ne figure pas dans le corpus, pour vérifier que le système sait se taire.
Les critères d'acceptation se chiffrent avant de commencer : taux de réponses correctes, taux de réponses sans source, taux d'abstention sur les questions hors corpus. C'est ce document qui permet d'affirmer que le système est prêt autrement qu'à l'intuition.
Isolation, accès, journalisation
Un modèle interne est un composant d'infrastructure comme un autre et se traite comme tel : réseau isolé ou hébergement dans vos murs, sauvegardes, supervision, gestion des versions.
Le contrôle d'accès mérite une attention particulière. Il doit s'aligner sur les droits que les utilisateurs ont déjà sur les documents. Un assistant documentaire qui ignore les permissions devient une fuite de données interne, et c'est l'erreur la plus fréquente que nous rencontrons sur les projets déjà commencés.
La journalisation des requêtes, enfin, avec une durée de conservation décidée et non subie. Les requêtes contiennent souvent plus d'informations personnelles que le corpus lui-même.
Environnements validés et EU AI Act
Pour les environnements validés, en pharma notamment, la qualification s'inscrit dans le cadre GAMP 5 et de l'Annexe 11 : catégorisation du logiciel, spécifications, tests reproductibles, gestion des changements. Le caractère non déterministe d'un modèle de langage n'empêche pas la validation, il déplace l'objet de la preuve du composant vers le système complet et son jeu d'évaluation.
Si vos utilisateurs ou vos clients sont dans l'Union européenne, il faut classer le système au regard de l'EU AI Act. La majorité des assistants documentaires internes relèvent du risque limité, avec des obligations de transparence. Un système qui interviendrait dans le recrutement, l'accès au crédit ou l'éducation bascule en risque élevé, avec une documentation nettement plus lourde. Cette classification se fait au début du projet, pas à la fin.
Les pièges les plus fréquents
Cinq erreurs reviennent assez régulièrement pour mériter d'être listées.
- Sous-estimer l'évaluation : sans jeu de test métier, impossible de savoir si le système régresse à chaque changement.
- Surdimensionner le GPU : commencer petit, mesurer, puis grandir ; l'inverse coûte cher et n'apporte rien.
- Ignorer les permissions : un assistant qui répond à partir de documents que l'utilisateur n'a pas le droit de lire est une fuite, pas une fonctionnalité.
- Négliger la qualité du corpus : un RAG sur des documents mal reconnus, dupliqués ou périmés produit des réponses fausses et sourcées, ce qui est pire qu'une absence de réponse.
- Oublier le cycle de vie : un modèle se met à jour, se réévalue et se remplace ; prévoyez-le dès l'architecture.
Par où commencer
Un cas d'usage, un corpus délimité, un jeu d'évaluation, six à douze semaines. C'est le format qui permet de trancher sans engager l'entreprise. Si le résultat convainc, l'extension à d'autres corpus relève ensuite du travail de données bien plus que de l'architecture.
Et le poste qui prend le plus de temps n'est jamais celui qu'on imagine : c'est la constitution et le nettoyage du corpus, pas l'intégration technique.