Pourquoi des LLM locaux en entreprise

Pourquoi ce chapitre

Un directeur des systèmes d'information qui évoque aujourd'hui « l'IAintelligence artificielleIAEnsemble des techniques permettant à un programme d'accomplir une tâche qui demanderait de l'intelligence humaine. Le terme couvre aussi bien les systèmes à règles écrites que ceux qui apprennent de données.Voir dans le glossaire générative » pense presque toujours à un service SaaS : une API appelée depuis son application, facturée au tokentokenIAFragment de texte manipulé par un modèle de langage, généralement plus court qu'un mot — trois à quatre caractères en français. La tarification et la limite de contexte se comptent en tokens.Voir dans le glossaire, hébergée par un tiers. C'est le chemin le plus rapide pour démarrer, et c'est souvent le bon choix. Mais un nombre croissant d'organisations — banques, cabinets d'avocats, hôpitaux, industriels sous contrat de défense — constatent que ce chemin se heurte à des murs : confidentialité des donnéesdonnéesIAEnsemble d'informations structurées ou non utilisées pour entraîner, évaluer ou alimenter un modèle. La qualité, la quantité et la représentativité des données sont les facteurs décisifs pour les performances en apprentissage automatique.Voir dans le glossaire, contraintes réglementaires, coûts qui deviennent imprévisibles à l'échelle, ou tout simplement impossibilité de connexion réseau vers l'extérieur.

Ce chapitre pose les bases de la décision : quand un LLMLLMIAGrand modèle de langage (Large Language Model) entraîné sur d'énormes corpus pour prédire et générer du texte.Voir dans le glossaire local a-t-il un sens, quand n'en a-t-il pas, et comment cartographier les cas d'usage de votre organisation pour trancher sans idéologie.

Nous ne détaillons pas encore les outilstool callingIACapacité d'un agent ou d'un LLM à invoquer des outils externes (API, calcul, recherche) pendant le raisonnement.Voir dans le glossaire (Ollama, vLLM, llama.cpp) ni le dimensionnement matériel — ces sujets arrivent dans les chapitres suivants. Ici, il s'agit exclusivement de la décision stratégique : faut-il héberger, et pour quoi faire.

SaaS, on-prem, hybride : trois familles de déploiement

Avant de parler de motivations, il faut clarifier le vocabulaire, car les termes sont utilisés de façon interchangeable alors qu'ils désignent des architectures très différentes.

Le modèle SaaS consiste à appeler un modèle hébergé par un fournisseur (OpenAI, Anthropic, Google, Mistral, etc.) via une API. Vous ne gérez aucune infrastructure de calcul. Vos données transitent par les serveurs du fournisseur, selon les conditions contractuelles négociées.

Le modèle on-premise (ou local) consiste à faire tourner le modèle sur une infrastructure que vous contrôlez entièrement : serveurs internes, cloud privé, voire poste de travail pour les petits modèles. Aucune donnée ne sort de votre périmètre réseau, sauf si vous le décidez explicitement.

Le modèle hybride combine les deux : par exemple, un modèle local pour les traitements sensibles ou volumineux, et un modèle SaaS pour les tâches ponctuelles où la puissance d'un très grand modèle propriétaire est nécessaire et où la donnée n'est pas sensible.

Aucun de ces modèles n'est intrinsèquement supérieur. Le bon choix dépend de la donnée traitée, du volume, du budget et des contraintes réglementaires propres à chaque cas d'usage — et une même entreprise se retrouve souvent avec les trois modèles actifs simultanément, chacun sur un périmètre différent.

La question n'est presque jamais « SaaS ou local ? » au niveau de l'entreprise, mais « SaaS ou local pour ce cas d'usage précis ? ». Le découpageChunkingIADécoupage d'un document en segments de taille fixe ou sémantique avant indexation vectorielle, pour optimiser la récupération RAG.Voir dans le glossaire se fait cas d'usage par cas d'usage, pas globalement.

Les cinq motivations qui poussent vers le local

1. Confidentialité et propriété intellectuelle

C'est la motivation la plus citée, et souvent la mieux fondée. Certaines données ne doivent structurellement jamais transiter par un tiers : dossiers médicaux, informations classifiées, code source stratégique, contrats en cours de négociation, données de R&D. Même avec des engagements contractuels solides de non-réutilisation des données par le fournisseur SaaS, l'exposition existe dès l'instant où la donnée quitte votre périmètre réseau — ne serait-ce que pour des raisons d'audit, de conformité ou de gestion des risques fournisseurs.

2. Souveraineté et conformité réglementaire

Au-delà de la confidentialité contractuelle, certains cadres réglementaires imposent une localisation des traitements : hébergement de données de santé (HDS en France), marchés publics sensibles, secteurs sous contrôle export, filiales de groupes étrangers soumises au droit extraterritorial d'un pays tiers (type Cloud Act américain). Dans ces contextes, la question n'est plus de préférence mais d'obligation légale.

3. Latence et disponibilité

Un modèle local hébergé sur le même réseau, voire dans le même datacenter que l'application qui l'appelle, élimine le round-trip internet. Pour des usages temps réel (assistance vocale, classification en flux, systèmes embarqués), cette latence compte. De même, un LLMgrand modèle de langageIAModèle entraîné à prédire le token suivant d'une séquence de texte. Toutes ses capacités apparentes — résumer, traduire, coder — découlent de cette unique tâche.Voir dans le glossaire local ne dépend pas de la disponibilité d'un service tiers ni de ses éventuels rate limits en période de forte charge.

4. Prévisibilité des coûts

La facturation SaaS au token est linéaire par construction : elle scale avec l'usage, ce qui est un avantage au démarrage (pas d'investissement initial) et un inconvénient à l'échelle (le coût devient difficile à prévoir et peut croître plus vite que la valeur générée). Un modèle local implique un coût d'infrastructure largement fixe — matériel, électricité, exploitation — qui devient plus avantageux au-delà d'un certain volume d'usage.

5. Air-gap et environnements déconnectés

Certains environnements n'ont tout simplement pas d'accès internet : réseaux industriels isolés, sites classifiés, navires, installations en zone à faible connectivité. Le SaaS y est physiquement impossible ; le LLM local est la seule option pour bénéficier de capacités génératives.

Un cabinet d'avocats d'affaires traite des mémoires confidentiels pour des opérations de fusion-acquisition non publiques. Utiliser un LLM SaaS pour résumer ces documents exposerait, même en théorie, une information à fort enjeu boursier à un tiers. Le cabinet déploie un modèle local de taille moyenne (30-70 milliards de paramètres) sur un serveur dédié, réservé à cet usage, tout en continuant d'utiliser un service SaaS pour la rédaction de courriers types non sensibles.

Les cas où le SaaS reste le bon choix

Il serait malhonnête de présenter le local comme systématiquement préférable. Le SaaS conserve des avantages structurels :

• Qualité de pointe : les modèles propriétaires les plus performants (raisonnement complexe, code, agentsagentIASystème qui enchaîne des appels d'outils de façon autonome pour atteindre un objectif : il planifie, agit, observe, recommence. Sa fiabilité décroît exponentiellement avec le nombre d'étapes.Voir dans le glossaire multi-étapes) restent souvent en avance sur les meilleurs modèles ouverts déployables localement, en particulier pour les tâches les plus exigeantes.
• Coût de démarrage nul : pas d'investissement matériel, pas d'équipe MLOps à constituer.
• Maintenance déléguée : le fournisseur gère les mises à jour de modèle, la scalabilité, la sécurité de l'infrastructure.
• Volumes faibles ou usages non sensibles : pour un usage ponctuel ou une donnée publique, l'argument confidentialité disparaît et le SaaS gagne sur tous les autres critères.

Déployer un LLM local « parce que c'est plus sûr » sans avoir chiffré le volume réel d'usage est une erreur de gestion de projet classique. En dessous d'un certain seuil de requêtes, le coût total de possession d'une infrastructure locale (matériel, électricité, temps d'ingénieur pour le maintien en condition opérationnelle) dépasse largement ce qu'aurait coûté l'abonnement SaaS équivalent. Le local n'est rentable économiquement qu'à partir d'un volume soutenu — la confidentialité, elle, peut justifier le local même à faible volume.

Cartographie des cas d'usage internes

Pour structurer la décision, il est utile de classer les cas d'usage d'une organisation selon quatre familles récurrentes.

Assistant interne conversationnel — un chatbot de support RH, IT ou documentation interne. Volume généralement modéré, sensibilité variable selon les données consultées. Souvent un bon candidat hybride : modèle local pour les documents RH sensibles, SaaS pour les questions génériques.

Assistant de code — complétion et génération de code sur la base du code source de l'entreprise. Le code source est presque toujours une donnée sensible ; c'est l'un des cas d'usage où la pression vers le local est la plus forte, en particulier dans l'édition logicielle et l'industrie.

RAGRAGIATechnique consistant à rechercher les documents pertinents et à les fournir au modèle dans son contexte. Elle permet des réponses à jour et citables, ce que l'affinage ne permet pas.Voir dans le glossaire documentaire (retrieval-augmented generation) — interrogation en langage naturel d'une base documentaire interne (contrats, procédures, rapports). La sensibilité dépend entièrement du contenu de la base ; un RAG sur des procédures qualité publiques n'a pas les mêmes exigences qu'un RAG sur des dossiers clients.

Classification et extraction — tri automatique de courriers entrants, extraction de champs sur des factures, détection de fraude. Volumes souvent très élevés et répétitifs, ce qui pousse naturellement vers le local pour des raisons de coût, indépendamment de la sensibilité.

Un schéma de décision go/no-go

Le schéma ci-dessous synthétise les critères présentés plus haut sous forme d'arbre de décision applicable cas d'usage par cas d'usage.

Ce schéma reste une simplification pédagogique. Dans la pratique, il faut aussi considérer la criticité opérationnelle (un service qui ne peut tolérer aucune interruption externe), la maturité de l'équipe technique interne, et la disponibilité d'un modèle ouvert dont la qualité est suffisante pour la tâche visée.

Avant tout arbitrage, faites l'inventaire des cas d'usage IA existants ou envisagés dans l'organisation, et notez pour chacun : le volume mensuel estimé de requêtes, la nature de la donnée traitée (publique, interne, confidentielle, réglementée), et la contrainte de latence. Ce simple tableau, rempli en une heure avec les équipes métier, tranche la majorité des cas avant même de discuter de technologie.

Le coût caché : les compétences

Un dernier point mérite d'être souligné, car il est souvent sous-estimé dans les premiers arbitrages : déployer un LLM local n'est pas un projet ponctuel, c'est une compétence à faire vivre dans la durée. Il faut suivre les nouvelles versions de modèles ouverts, gérer les mises à jour de sécurité de l'infrastructure d'inférenceinférenceIAUtilisation d'un modèle déjà entraîné sur une donnée nouvelle. Peu coûteuse à l'unité mais répétée à chaque requête, elle constitue le coût récurrent d'exploitation.Voir dans le glossaire, surveiller les performances, et souvent réentraîner ou ajuster les prompts système à mesure que les usages évoluent. Une organisation qui n'a pas de compétence MLOps ou infrastructure interne doit intégrer ce coût de montée en compétence — ou de recrutement — dans son calcul de rentabilité, et pas seulement le prix du matériel.

Cette compétence, une fois acquise, devient elle-même un actif : elle permet de déployer rapidement de nouveaux cas d'usage locaux sans repartir de zéro, ce qui change progressivement l'équation économique en faveur du local à mesure que le portefeuille de cas d'usage s'étoffe.

Pièges fréquents lors du premier arbitrage

L'expérience des projets d'IA générative en entreprise fait ressortir des erreurs récurrentes, indépendamment du secteur d'activité.

Confondre sensibilité de la donnée d'entrée et sensibilité de la sortie. Un modèle peut recevoir une question anodine mais produire, dans sa réponse, une synthèse qui recoupe des informations sensibles issues du contextefenêtre de contexteIAQuantité de texte qu'un modèle peut prendre en compte simultanément : question, documents fournis et historique. Au-delà, les éléments les plus anciens sortent du champ.Voir dans le glossaire fourni (documents joints en RAG, historique de conversation). L'analyse de sensibilité doit porter sur l'ensemble du flux, pas uniquement sur le promptpromptIAConsigne ou contexte fourni à un modèle de langage pour orienter sa réponse. La qualité du prompt conditionne souvent la qualité du résultat.Voir dans le glossaire initial.

Sous-estimer le travail d'adaptation du modèle ouvert. Un modèle propriétaire SaaS arrive généralement pré-optimisé pour une large gamme de tâches. Un modèle ouvert déployé en local nécessite souvent un travail de prompt engineeringprompt engineeringIADiscipline consistant à concevoir des instructions précises pour guider un LLM vers la réponse souhaitée. Elle inclut les techniques de chain-of-thought, few-shot, rôle et format de sortie.Voir dans le glossaire, de fine-tuningFine-tuningIAAjustement des poids d'un modèle pré-entraîné sur un jeu de données spécifique pour adapter son comportement à un domaine ou une tâche cible.Voir dans le glossaire léger ou de mise en place d'un pipeline RAG pour atteindre une qualité comparable sur un cas d'usage précis. Ce travail a un coût et un délai qu'il faut anticiper dans le planning du projet.

Négliger la question du support et des mises à jour de sécurité. Un modèle ouvert n'a pas de service client attaché. Les correctifs de sécurité sur la chaîne d'inférence (serveur, bibliothèques, dépendances) restent à la charge de l'équipe interne, ce qui suppose une veille active sur les vulnérabilités.

Lancer un pilote sans métrique de succès définie. Beaucoup de projets pilotes de LLM local s'arrêtent faute d'avoir défini, en amont, ce qui constituerait un succès mesurable : taux de résolution correct, gain de temps constaté, réduction du volume transmis à un prestataire externe. Sans ces métriques, le comité de pilotage ne dispose d'aucun élément objectif pour décider de la généralisation.

Un modèle local qui « fonctionne techniquement » n'est pas la même chose qu'un modèle dont la qualité de réponse a été validée par les utilisateurs métier sur des cas réels. Prévoyez systématiquement une phase de test avec un panel d'utilisateurs représentatifs avant toute généralisation, quel que soit le mode de déploiement choisi.

Checklist de démarrage avant le premier déploiement

Avant de lancer un projet de LLM local, il est utile de vérifier que les points suivants ont été traités, même sommairement :

• La donnée traitée par le cas d'usage a été classifiée (publique, interne, confidentielle, réglementée).
• Le volume mensuel de requêtes attendu a été estimé, même approximativement.
• Une contrainte de latence ou de disponibilité a été identifiée, ou explicitement écartée.
• Une personne ou une équipe a été désignée comme responsable du maintien en condition opérationnelle.
• Un budget matériel et humain a été chiffré sur au moins 18 à 24 mois, pas seulement sur la phase pilote.
• Des métriques de succès mesurables ont été définies avant le lancement du pilote.
• Un plan de repli vers le SaaS (ou l'inverse) a été envisagé si le mode de déploiement choisi s'avère inadapté après le pilote.

Cette liste n'a rien d'exhaustif, mais elle évite l'écueil le plus commun observé sur le terrain : se lancer dans un déploiement local motivé par un principe général de sécurité, sans avoir chiffré ni la charge réelle, ni le coût de maintien dans la durée, ni la manière dont le succès sera mesuré.

Ce qu'il faut retenir avant le chapitre suivant

Le déploiement d'un LLM local en entreprise se décide cas d'usage par cas d'usage, en croisant sensibilité de la donnée, volume, contrainte réseau et budget disponible pour l'infrastructure et les compétences. Le SaaS et le local ne s'excluent pas : la plupart des organisations matures finissent avec une architecture hybride, où chaque cas d'usage est routé vers le mode de déploiement le plus adapté à ses contraintes propres. Le chapitre suivant entre dans le concret technique en présentant Ollama, la porte d'entrée la plus simple pour faire tourner un premier modèle local.