« Nos données ne sortent pas. » C'est la phrase qui déclenche la plupart des conversations sur le déploiement local, et c'est rarement une question technique. C'est une contrainte réglementaire, une politique interne, ou un engagement pris devant un client.
Le déploiement dans l'infrastructure du client répond à cette contrainte. Il en crée d'autres, moins visibles, qui apparaissent après la mise en service.
Nous éditons NeuraScope et nous la déployons dans les deux modes : sur notre infrastructure mutualisée, et chez nos clients. Voici ce que le second change réellement.
Ce qui sort et ce qui ne sort pas, en mode mutualisé
Avant de parler de déploiement local, il faut être précis sur ce qui se passe sans lui. Beaucoup d'organisations choisissent l'hébergement dédié pour résoudre un problème qui n'existait pas, et passent à côté de celui qui existe.
Dans NeuraScope, la transformation d'un document en index de recherche s'exécute localement, sur l'infrastructure qui héberge la plateforme. Indexer un corpus ne provoque donc aucun transfert vers un tiers, quel que soit le mode d'hébergement.
Ce qui peut sortir, c'est la question posée par un utilisateur et les passages retrouvés dans le corpus, transmis au modèle de langage, et uniquement si ce modèle est externe.
La distinction est décisive. Un cabinet qui craint que ses dossiers soient absorbés par un fournisseur de modèle a un problème réel, mais qui se résout en affectant des modèles auto-hébergés aux usages sensibles, pas nécessairement en changeant toute l'infrastructure.
Il reste une limite que nous énonçons avant qu'un client ne la découvre : sur une infrastructure mutualisée, l'isolation entre organisations est applicative, pas cryptographique. Chaque projet dispose de sa propre base vectorielle, physiquement distincte, ce qui vaut mieux qu'un filtre logique qu'un défaut de code pourrait contourner. Mais pour une organisation qui exige une séparation cryptographique, la réponse est le déploiement dans sa propre infrastructure.
Ce que le déploiement local apporte réellement
Quatre choses, et il vaut mieux savoir laquelle on cherche.
L'isolation réseau complète. La plateforme peut fonctionner sans aucune connexion sortante. Ce n'est pas une promesse de configuration, c'est une propriété vérifiable par une règle de pare-feu. Pour un secteur soumis au secret professionnel, c'est souvent le seul argument qui compte, parce qu'il est démontrable devant un auditeur.
L'absence de dépendance à un service en ligne. Un fournisseur de modèle qui change ses conditions, augmente ses tarifs, ferme un accès ou modifie son modèle sans préavis n'affecte pas une installation locale. Cette stabilité a une valeur qui apparaît rarement dans les comparatifs initiaux, et toujours après le premier incident.
La maîtrise du cycle de vie des données. Sauvegardes, rétention, effacement, journalisation : tout se décide et se démontre en interne. Sur un service en ligne, la même démonstration dépend des engagements du prestataire.
Le contrôle du calendrier. Une mise à jour se déploie quand l'organisation le décide, après ses propres tests. C'est une contrainte pour l'éditeur et un confort pour l'exploitant.
Ce que cela transfère à l'organisation
Ces quatre bénéfices se paient par un transfert de responsabilités que je préfère énoncer complètement.
Le matériel. Faire tourner des modèles auto-hébergés demande des ressources dédiées, et notamment de la carte graphique si l'on veut des temps de réponse acceptables. Ce n'est pas un serveur d'application ordinaire. Le dimensionnement doit être arbitré avant l'engagement, pas découvert après.
L'exploitation. Sauvegardes vérifiées, supervision, mises à jour de sécurité du système, gestion des certificats, rotation des journaux. Ces tâches existaient déjà pour d'autres applications, mais elles s'ajoutent à une charge existante, et personne ne les fait spontanément.
La performance des modèles. C'est le point le plus souvent sous-estimé. Un modèle auto-hébergé de taille raisonnable est généralement moins performant qu'un grand modèle commercial. Sur des tâches de synthèse ou de raisonnement complexe, l'écart se ressent. Nous le disons avant le déploiement, parce que le découvrir après crée une déception qui contamine tout le projet.
Le diagnostic. Quand un service en ligne est lent, on ouvre un ticket. Quand une installation locale est lente, il faut savoir si la cause est le modèle, la base de données, le réseau ou le stockage. Cela suppose un minimum d'outillage.
L'outillage minimal, et pourquoi la virtualisation aide
Sur ce dernier point, l'expérience nous a conduits à considérer trois éléments comme non négociables.
La séparation des rôles. Base de données, application, modèles et stockage doivent pouvoir être arrêtés, redimensionnés ou restaurés indépendamment. Un environnement virtualisé rend cette séparation naturelle : chaque rôle vit dans sa propre machine, avec ses ressources, ses sauvegardes et son cycle de vie.
C'est ce qui rend une plateforme comme Proxmox pertinente dans ce contexte. L'intérêt n'est pas la virtualisation en soi, c'est qu'un incident sur un composant n'oblige pas à toucher aux autres, et qu'une restauration se fait à la machine près plutôt qu'au serveur entier.
Les instantanés avant intervention. Toute mise à jour est précédée d'un instantané. Cela transforme un retour arrière de plusieurs heures en une opération de quelques minutes. C'est la mesure la plus rentable de toutes, et la plus facile à oublier quand tout va bien.
La surveillance par couche. Un tableau de bord qui agrège tout en un seul indicateur ne sert à rien en diagnostic. Sur NeuraScope, nous mesurons séparément l'infrastructure, les points d'entrée HTTP, les services applicatifs, la couche IA et le parcours utilisateur complet. Les latences observées vont de 1 ms pour l'infrastructure à 1 597 ms pour un parcours complet.
Ce facteur de plus de mille explique pourquoi la séparation est indispensable. Quand un utilisateur signale un ralentissement, la couche fautive se lit immédiatement, au lieu de se chercher.
La sauvegarde, et le test qu'on ne fait jamais
Une plateforme documentaire pose une question de sauvegarde particulière, parce que les données ne sont pas toutes de même nature.
Il y a la base relationnelle, qui contient les utilisateurs, les projets, la configuration. Il y a les fichiers sources téléversés. Et il y a les bases vectorielles, c'est-à-dire l'index de recherche construit à partir de ces fichiers.
Ces trois ensembles doivent être cohérents entre eux. Restaurer une base relationnelle d'hier avec un index d'aujourd'hui produit un système qui référence des documents absents, ou qui ignore des documents présents.
D'où deux règles simples.
La première : sauvegarder les trois ensembles au même moment, ou accepter de reconstruire l'index après restauration. La reconstruction est possible puisque l'index dérive des fichiers, mais elle prend du temps sur un corpus volumineux, et ce temps doit être connu avant l'incident.
La seconde, plus importante : tester la restauration. Une sauvegarde jamais restaurée est une hypothèse, pas une garantie. C'est le test que toutes les organisations remettent à plus tard, et celui dont l'absence se paie le jour où il faut restaurer.
Comment choisir
L'arbitrage se résume à quelques questions, et la réponse n'est pas toujours le déploiement local.
Une contrainte réglementaire impose-t-elle l'isolation ? Si oui, la question est réglée, et le reste de la discussion porte sur les moyens.
Le corpus contient-il des données dont la sortie serait un problème en soi ? Attention à la précision : ce qui sort, ce sont les questions et les passages retrouvés, pas les documents. La réponse peut différer selon les corpus, ce qui autorise une approche mixte.
L'organisation a-t-elle une capacité d'exploitation ? Sans équipe capable de tenir un serveur dans la durée, un déploiement local se dégrade lentement et finit moins sûr qu'un service géré. C'est le scénario le plus dommageable : la souveraineté sur le papier, l'abandon dans les faits.
Quel niveau de performance est attendu ? Si les usages exigent le meilleur niveau de raisonnement disponible, le tout-local imposera un compromis qu'il vaut mieux mesurer avant de s'engager.
Une configuration mixte est souvent la plus juste : modèles auto-hébergés pour les corpus sensibles, modèle externe pour les usages où la performance prime et où les données sont anodines. Cela suppose seulement de savoir classer ses usages, ce qui est un exercice utile en soi.
Ce qu'il faut retenir
Le déploiement dans une infrastructure privée n'est pas une version supérieure du service en ligne. C'est un transfert : on gagne l'isolation, l'indépendance et la maîtrise du calendrier, on prend en charge le matériel, l'exploitation et un compromis de performance.
Ce transfert est le bon choix quand une contrainte réglementaire l'impose, ou quand l'indépendance vis-à-vis d'un fournisseur a une valeur stratégique. Il est un mauvais choix quand il est motivé par une crainte imprécise sur la circulation des données, alors qu'un réglage de modèle aurait suffi.
La question à poser en premier n'est pas « où sont hébergées les données ? » mais « qu'est-ce qui sort, dans quel cas, et vers qui ? ». La réponse à cette question détermine tout le reste.
