La question arrive tôt dans les projets : faut-il faire tourner le modèle de langage sur sa propre infrastructure, ou passer par un fournisseur ?
Elle est presque toujours posée sous l'angle de la confidentialité. C'est un angle légitime, mais partiel, et surtout mal cadré : beaucoup d'organisations choisissent l'auto-hébergement pour résoudre un problème qu'elles n'ont pas, et découvrent après coup les contraintes qu'elles ont acceptées.
Voici les quatre critères qui décident réellement.
D'abord, savoir ce qui sort
Avant tout arbitrage, il faut être précis sur la circulation des données. C'est le point où le plus de conversations partent de travers.
Dans une architecture de recherche documentaire correctement conçue, la transformation des documents en index de recherche s'exécute localement. Indexer un corpus ne provoque donc aucun transfert vers un tiers, y compris quand le modèle de langage est externe.
Ce qui peut sortir, c'est la question posée par l'utilisateur et les passages retrouvés dans le corpus, transmis au modèle au moment de la génération.
La distinction est décisive. Un cabinet qui craint que l'intégralité de ses dossiers soit absorbée par un fournisseur a une crainte infondée sur ce point précis. En revanche, si les extraits transmis contiennent des noms de clients ou des éléments couverts par le secret professionnel, la crainte redevient fondée, et elle porte sur la génération, pas sur l'indexation.
Poser la question ainsi permet des réponses nuancées : on peut affecter un modèle auto-hébergé aux corpus sensibles et un modèle externe aux usages anodins, sans changer toute l'infrastructure.
Critère 1 : la confidentialité, appliquée aux bons usages
Une fois la circulation clarifiée, la question se pose usage par usage.
Rédiger une note de synthèse à partir d'un corpus juridique nominatif, analyser des dossiers médicaux, traiter des données bancaires : ces usages exigent que rien ne sorte, et la réponse est un modèle auto-hébergé.
Rédiger un texte marketing, reformuler un paragraphe, traduire une documentation publique : ces usages ne posent aucun problème avec un modèle externe.
Entre les deux, une zone grise que seule l'organisation peut trancher, et qui demande de classer ses usages. C'est un exercice utile en soi, indépendamment de la technologie : beaucoup d'organisations n'ont jamais formalisé quelles données sont sensibles et lesquelles ne le sont pas.
Une configuration sans aucun transfert externe est possible, en affectant des modèles auto-hébergés à tous les usages. La contrepartie doit être annoncée franchement : matériel dédié à prévoir, et modèles locaux généralement moins performants.
Critère 2 : la performance, et l'écart réel
C'est le critère le plus souvent minimisé par les partisans de l'auto-hébergement, et le plus douloureux à découvrir après coup.
Un modèle auto-hébergé de taille raisonnable, tournant sur du matériel accessible, est généralement moins performant qu'un grand modèle commercial. L'écart est faible sur des tâches simples : extraire une information d'un passage, reformuler, classer. Il devient sensible sur le raisonnement complexe, la synthèse de sources contradictoires, ou les instructions en plusieurs étapes.
Deux conséquences pratiques.
D'abord, l'écart se mesure, il ne se discute pas. Un jeu de questions représentatives, passées sur les deux options, tranche la question en une journée. C'est infiniment plus utile que n'importe quel comparatif générique.
Ensuite, l'écart dépend de l'usage. Sur une tâche de recherche documentaire où le modèle sert surtout à formuler une réponse à partir de passages fournis, un modèle local convient souvent. Sur une tâche d'analyse où le modèle doit raisonner, l'écart se voit.
Notre recommandation : mesurer sur les cas réels du client avant de trancher, jamais après.
Critère 3 : le coût, dont la structure diffère
Les deux options ne coûtent pas seulement des montants différents, elles ont des structures de coût opposées.
Un modèle externe se facture à l'usage. Le coût initial est nul, et il croît avec le nombre d'utilisateurs et de questions. Cette structure convient à un démarrage, et devient un sujet de discussion quand l'usage se généralise.
Un modèle auto-hébergé demande un investissement matériel initial, notamment en cartes graphiques, puis son coût marginal par question est nul. Cette structure est défavorable au démarrage et favorable à l'échelle.
Il existe un troisième poste, souvent oublié : l'évaluation. Si vous construisez une chaîne d'intégration continue qui rejoue un jeu de questions à chaque livraison, chaque exécution est facturée avec un modèle externe. Multipliez par le nombre de questions, d'exécutions et de livraisons quotidiennes, et l'addition devient un vrai sujet.
C'est un argument concret en faveur de l'auto-hébergement pour les environnements de test, même quand la production utilise un modèle externe. Peu d'équipes y pensent avant d'avoir reçu la première facture.
Critère 4 : la stabilité, le critère négligé
Un modèle externe évolue sans préavis. Le fournisseur met à jour, ajuste, déprécie une version, et le comportement change du jour au lendemain.
Ce point mérite plus d'attention qu'il n'en reçoit. Un système validé en recette, dont les réponses ont été relues par des praticiens, peut se mettre à répondre autrement sans qu'une ligne de code ait bougé. Le diagnostic est déroutant : l'équipe cherche une régression dans son propre code, alors que la cause est ailleurs.
Deux parades. La première consiste à conserver l'historique des versions de modèle utilisées à chaque exécution des tests d'évaluation : la corrélation devient immédiatement visible. La seconde consiste à surveiller en continu quelques questions de référence, avec des seuils explicites, ce qui transforme une surprise en signal daté.
Un modèle auto-hébergé, lui, ne bouge que quand on décide de le faire bouger. Pour une organisation qui doit démontrer la reproductibilité de ses traitements, cette stabilité peut valoir davantage qu'un écart de performance.
Ce que l'auto-hébergement transfère comme charge
Choisir l'auto-hébergement, c'est accepter des responsabilités qui existaient chez le fournisseur.
Le matériel doit être dimensionné et renouvelé. Les modèles doivent être mis à jour, ce qui suppose de valider que la nouvelle version ne dégrade pas les résultats. La supervision doit distinguer une lenteur du modèle d'une lenteur de la base ou du réseau, ce qui suppose une mesure par couche plutôt qu'un indicateur global.
Ces charges sont modestes prises isolément. Ensemble, elles supposent une capacité d'exploitation. Une organisation qui n'a personne pour tenir un serveur dans la durée obtiendra un système qui se dégrade lentement, et qui finira moins sûr qu'un service géré correctement configuré.
C'est le scénario le plus dommageable : la souveraineté sur le papier, l'abandon dans les faits.
La réponse est souvent mixte
L'arbitrage n'est pas binaire, et le poser ainsi conduit à de mauvaises décisions.
Une configuration fréquente et raisonnable : modèles auto-hébergés pour les corpus sensibles et pour les environnements de test, modèle externe pour les usages où la performance prime et où les données sont anodines.
Cette approche demande une seule chose à l'organisation : savoir classer ses usages. Ce classement est le vrai travail, et il a de la valeur même si l'on choisit finalement une option unique.
Comment décider en pratique
Quatre questions, dans cet ordre.
Quels usages traitent des données dont la sortie serait un problème ? Pas « quelles données avons-nous », mais « qu'est-ce qui sortirait effectivement, au moment de la génération ».
Quel écart de performance sépare les deux options sur nos cas réels ? Mesure sur un jeu de questions représentatives, pas comparatif générique.
À quel volume d'usage le coût bascule-t-il ? Le calcul se fait en une heure et évite une mauvaise surprise à six mois.
Avons-nous la capacité d'exploiter ? Question la plus inconfortable et la plus déterminante.
Une organisation qui répond à ces quatre questions a sa réponse, et elle est souvent plus nuancée que la position de départ.
Ce qu'il faut retenir
Le choix entre modèle auto-hébergé et modèle externe se joue sur quatre critères : quels usages exigent qu'aucune donnée ne sorte, quel écart de performance est acceptable, à quel volume le coût bascule, et si l'organisation peut exploiter dans la durée.
La souveraineté est un critère parmi ces quatre, et elle se cadre précisément : ce qui sort, ce sont les questions et les passages retrouvés, au moment de la génération, pas les documents à l'indexation.
Et la meilleure réponse est rarement exclusive. Classer ses usages permet d'affecter le bon modèle au bon endroit, plutôt que d'imposer à tout le système la contrainte du cas le plus sensible.
