IA locale en entreprise : pourquoi basculer maintenant et comment rentabiliser un usage total

Un abonnement par utilisateur est simple à acheter, mais il décrit mal la réalité d’un usage professionnel. Deux collaborateurs peuvent avoir des besoins très différents : l’un demande quelques synthèses par semaine, l’autre génère du code, interroge une base documentaire et lance plusieurs agents chaque jour. Dans le premier cas, un service cloud standard peut être optimal. Dans le second, l’entreprise paie surtout une capacité externe qu’elle ne maîtrise ni techniquement ni budgétairement.

Une infrastructure locale transforme cette logique. Le matériel devient une capacité mutualisée : plusieurs équipes partagent les modèles, les bases de connaissances, les outils de recherche et les automatisations. Le coût ne disparaît pas, il devient un coût d’infrastructure et d’exploitation que l’on peut dimensionner, surveiller et faire évoluer.

C’est comparable à un atelier. Louer une machine par opérateur convient au démarrage. Mais quand elle tourne toute la journée pour plusieurs équipes, un équipement commun est souvent plus logique. Il faut alors compter la maintenance, la sécurité, l’énergie et les périodes de pointe.

Il ne suffit pas de cumuler ces deux critères. Des données sensibles peuvent rester dans le cloud si elles sont peu utilisées. À l’inverse, un gros volume ne justifie pas le local sans politique d’accès claire et sans exploitation fiable.

Reliez chaque usage à une équipe, une fréquence et une classe de sensibilité. Cette première cartographie aide ensuite à choisir le modèle, le stockage, le routage et le mode de financement.

Le passage à l’IA locale est donc moins une migration technique qu’un apprentissage organisationnel. Les équipes doivent savoir quels usages sont autorisés, comment vérifier une réponse, quand demander une validation humaine et comment signaler une erreur. La plateforme doit rendre ces règles simples à appliquer au quotidien.

En pratique, on commence avec un périmètre réversible : quelques utilisateurs référents, un corpus documentaire maîtrisé et des tâches dont la qualité peut être évaluée. Ce dispositif produit les données nécessaires pour décider si l’on augmente la capacité locale ou si l’on conserve davantage de traitements dans le cloud.

Une comparaison sérieuse doit intégrer le coût total de possession (TCO). Cela comprend le matériel ou sa mensualité de financement, l’électricité, le refroidissement, le réseau, le stockage, les sauvegardes, la supervision, les mises à jour, la maintenance, la sécurité et le temps d’administration. Une infrastructure locale mal opérée peut coûter plus cher qu’un abonnement cloud. À l’inverse, une plateforme dimensionnée à partir des usages peut devenir compétitive.

Commencez par séparer les coûts fixes des coûts variables. Le serveur, l’installation et une partie de la supervision sont prévisibles. Les appels à un modèle externe, le stockage supplémentaire et l’énergie varient avec la charge. Cette distinction permet de calculer un seuil de rentabilité sans promettre une économie identique pour toutes les entreprises.

Un serveur local doit être suffisamment utilisé sans être saturé en permanence. Mesurez les requêtes, la durée des traitements, la taille des contextes, les périodes de pointe et le nombre de collaborateurs actifs. Le scénario de 85 à 90 % des requêtes traitées localement peut servir de repère, mais il ne vaut pas pour toutes les équipes. Le résultat dépend des modèles, du niveau de qualité attendu et de la charge réelle.

Pour estimer le seuil, additionnez le coût local mensuel complet et le coût cloud résiduel. Comparez ensuite ce montant aux abonnements ou appels cloud évités, puis aux gains de temps réellement transformés en production, en qualité ou en délai client.

La souveraineté n’est pas qu’une affaire de droit. Elle a un impact financier dès que certaines données ne doivent pas sortir : code source, contrats, données personnelles, dossiers clients ou informations industrielles. Une exécution locale limite les transferts et peut rendre possibles des usages jusque-là refusés par la sécurité ou par un client.

Elle ne protège pas automatiquement l’entreprise. Un serveur mal configuré, sans contrôle d’accès, chiffrement, journalisation, sauvegarde ni plan de reprise, ajoute une nouvelle faiblesse. La souveraineté repose donc sur des règles d’exploitation concrètes, pas sur le seul emplacement du serveur.

S’appuyer sur un seul fournisseur expose l’entreprise à toutes ses décisions : hausses de prix, nouveaux quotas, changements de conditions, indisponibilités ou retrait de modèles. Le local ne supprime pas la dépendance. Il la déplace vers le matériel, les compétences et les composants logiciels. Gardez des interfaces et des formats interchangeables, évaluez plusieurs modèles et prévoyez une route cloud de secours pour les tâches qui le nécessitent.

Une architecture hybride fiable repose sur quatre éléments : une interface commune, un routeur de modèles, un catalogue de données autorisées et des outils d’observabilité. L’utilisateur n’a pas à choisir son fournisseur à chaque requête. La politique de l’entreprise oriente le traitement.

L’interface peut s’appuyer sur Open WebUI, LibreChat ou un outil métier intégré, avec authentification centralisée et gestion des rôles. Derrière, une passerelle envoie la requête vers un modèle local ou cloud selon la sensibilité des données, la taille du contexte, le niveau de performance attendu et le budget.

L’inférence locale repose sur des modèles évalués, des limites de concurrence et des files d’attente. Le RAG (Retrieval-Augmented Generation) recherche les passages utiles dans les documents autorisés avant de produire une réponse. Il doit respecter les droits d’accès et conserver la trace des sources utilisées.

Enfin, la plateforme suit le coût, la latence, les erreurs, la qualité, la consommation GPU et les appels cloud. Une bascule vers le cloud peut servir de secours pour les traitements admissibles, mais elle ne doit jamais envoyer automatiquement des données sensibles non autorisées.

Une PME peut commencer avec une machine locale dédiée à un cas d’usage clair. Une grande PME peut ensuite partager une workstation ou un serveur interne entre plusieurs équipes. L’objectif est de comparer la mémoire disponible, la bande passante, la consommation électrique et le nombre d’utilisateurs réellement servis.

Le choix ne se limite pas à une marque. Apple privilégie la mémoire unifiée et la sobriété. Intel apporte des plateformes de workstation et de serveur compatibles avec les GPU professionnels. NVIDIA propose des systèmes DGX conçus pour l’inférence et le développement de modèles plus volumineux.

Les cartes ci-dessous donnent un échantillon des architectures possibles. Elles ne constituent pas un classement. Le modèle retenu dépend du volume de requêtes, du contexte, de la confidentialité et du niveau de maintenance acceptable.

Les coûts du matériel, du financement, de l’énergie et des services varient selon le GPU, le fournisseur, la durée du contrat, la région et le niveau de service. Les montants proposés ici servent donc de repères pour lancer une discussion, pas de tarif public.

Pour obtenir le seuil mensuel, additionnez le coût fixe local, le coût d’exploitation et le budget cloud de secours. Comparez ce total aux dépenses cloud évitées et aux gains de temps réellement constatés.

Testez trois hypothèses : prudente, centrale et intensive. Faites varier le nombre d’utilisateurs actifs, la part de requêtes traitées localement, la maintenance, l’électricité, la consommation cloud et le coût d’une interruption. Le but n’est pas de retenir le scénario le plus flatteur, mais de voir à partir de quel niveau d’usage la décision tient.

La bonne décision n’est pas la machine qui affiche le plus grand nombre de paramètres. C’est celle qui garde le modèle utile en mémoire, répond dans le délai attendu et reste exploitable par l’équipe. Commencez par une configuration réversible, puis augmentez la capacité lorsque les mesures montrent une saturation ou un besoin métier confirmé.

Vendre uniquement un serveur GPU laisse le client seul face au choix des modèles, à la sécurité, aux mises à jour, à la formation et à la mesure de la valeur. Une offre d’usage total doit fournir une capacité opérationnelle : accéder à l’IA, l’utiliser dans les processus, protéger les données, suivre les coûts et faire évoluer la plateforme.

Le contrat peut combiner une mise en service, un abonnement de fonctionnement et une enveloppe d’évolution. Le financement du matériel, qu’il s’agisse d’un achat ou d’une location, doit rester distinct du service. Ses effets comptables et fiscaux sont à confirmer avec le financeur et le conseil du client.

Le socle privé n’a de valeur que s’il devient un service utilisable. L’accès doit être aussi simple que celui d’un outil cloud, tandis que les règles de sécurité et de conservation restent pilotées par l’organisation. C’est cette couche d’usage qui transforme une infrastructure en capacité de production.

La séparation entre socle, usage et pilotage permet aussi de faire évoluer l’offre sans reconstruire tout le système. Un client peut commencer avec un assistant documentaire, puis ajouter du code, des automatisations ou un routage hybride lorsque les preuves d’usage sont suffisantes.

Ces trois verbes définissent le périmètre d’une offre opérée. Installer un modèle peut être rapide. Maintenir sa qualité, contrôler les flux et vérifier les résultats demande en revanche un suivi mensuel. Ces tâches doivent apparaître dans le contrat, avec des responsabilités et des indicateurs précis.

Le client comprend alors ce qu’il paie. Il finance une infrastructure disponible, un risque suivi et des usages qui progressent. ProovUp peut ainsi proposer un service récurrent sans enfermer l’offre dans un matériel précis.

La première quinzaine sert à mesurer. Sélectionnez deux ou trois équipes, inventoriez les usages, qualifiez les données et établissez une facture de référence.

Les deux semaines suivantes, testez un environnement pilote sur plusieurs modèles et un jeu de tâches représentatif. Entre le 31e et le 60e jour, connectez les documents, les rôles, les journaux et un premier workflow. La dernière quinzaine sert à décider : comparez les résultats au scénario de référence, calculez le coût complet, recueillez les retours et choisissez d’étendre, d’ajuster ou d’arrêter.

Les indicateurs de réussite doivent être définis avant le pilote : taux d’usage actif, temps moyen gagné sur une tâche précise, qualité évaluée par un échantillon, coût par traitement, taux de requêtes locales, incidents et satisfaction des utilisateurs. Une hausse du nombre de requêtes n’est pas, à elle seule, un succès.

Avant de déployer : commencez par un audit du patrimoine data et logiciel pour identifier les sources, les droits, les dépendances et les actifs réellement mobilisables. Découvrir la phase d’audit du patrimoine.

Pour une équipe opérationnelle, le choix du modèle vient après le problème à résoudre. Il peut s’agir de retrouver une procédure, préparer une réponse, analyser un dossier, qualifier un incident, rédiger un compte rendu ou transmettre un savoir détenu par une seule personne.

Le premier livrable peut être un poste de travail IA gouverné : une interface simple, un périmètre documentaire limité, des sources citées, des droits alignés sur le système de référence et un moyen de signaler une réponse incorrecte. Le traitement local est utile quand l’équipe manipule des contrats, des données clients, des dossiers RH ou des informations de production qui ne doivent pas circuler sur des outils grand public.

Le coût se raisonne alors par équipe et par processus. Mesurez le temps de recherche ou de préparation avant et après, le taux de réutilisation des réponses, les erreurs détectées et le temps d’intégration des nouveaux arrivants. Ne promettez pas une économie par utilisateur si la valeur se concentre sur quelques tâches.

Dans une PME ou une entreprise de taille intermédiaire (ETI), la difficulté est rarement l’absence d’idées. Elle vient de la dispersion : plusieurs outils, des données en silos, des règles différentes selon les filiales et peu de temps disponible pour exploiter une plateforme. Le projet doit donc commencer par une cartographie des flux et des responsabilités, pas par un catalogue de modèles.

Une cible réaliste est un socle IA privé partagé entre fonctions support, équipes commerciales, opérations, qualité et développement. La plateforme peut proposer plusieurs assistants, mais elle doit conserver un même contrôle des identités, des données, des journaux et des coûts. Pour une ETI, on ajoute les exigences de segmentation réseau, de haute disponibilité, de reprise après incident, de gestion multi-sites et de validation par les métiers.

Le financement doit être comparé sur plusieurs horizons : achat, location financière, infrastructure managée ou cloud privé. La location réduit éventuellement la sortie de trésorerie initiale, mais elle crée un engagement fixe. La décision doit intégrer le taux d’utilisation attendu, la durée de vie des GPU, le coût d’une capacité de secours et le coût de sortie. L’argument économique le plus solide est une capacité prévisible et mesurée, pas la promesse d’un coût marginal nul.

Pour ces entreprises, le pilote peut être relié à un dispositif de diagnostic existant, comme un Diag Data IA lorsqu’il est éligible. Le diagnostic sert à prioriser les cas d’usage et à estimer les coûts, il ne remplace pas la conception détaillée, l’intégration ni l’exploitation de la plateforme.

Pour un éditeur, l’IA locale répond à une question différente : comment ajouter une fonction intelligente sans transformer chaque client actif en coût variable imprévisible ? Un assistant intégré à un produit peut générer des appels d’inférence, du stockage de contexte, des embeddings, des logs et des opérations de sécurité. Si ces coûts augmentent avec l’usage alors que le prix reste forfaitaire, la marge brute se dégrade précisément chez les clients qui utilisent le plus la fonctionnalité.

Trois architectures sont à comparer : inférence centralisée dans le cloud de l’éditeur, déploiement dédié chez le client ou dans un cloud privé, et mode hybride avec un modèle local pour les tâches fréquentes et une API pour les tâches de pointe. Le choix dépend du volume, de la latence, de la sensibilité des données, de la capacité du client à opérer une infrastructure et du niveau de personnalisation attendu.

Le produit doit séparer l’orchestration métier de l’exécution du modèle. Une couche d’abstraction permet de changer de modèle, de mesurer le coût par fonctionnalité, de limiter les agents, de mettre en cache certaines réponses et de contrôler les données transmises. Le contrat commercial doit ensuite rendre visible la consommation : forfait avec quota, facturation à l’usage, capacité dédiée ou option de déploiement privé. Le prix ne doit pas masquer un coût d’inférence non maîtrisé.

Le déploiement chez le client peut aussi devenir un avantage commercial pour les secteurs régulés et les grands comptes. Il impose en contrepartie une vraie discipline produit : packaging reproductible, mises à jour signées, compatibilité matérielle, support, télémétrie respectueuse de la confidentialité, tests de performance et procédure de retrait des modèles. Un éditeur ne vend pas seulement un poids de modèle, il vend une expérience fiable dans un environnement qu’il ne contrôle pas entièrement.

Ces recommandations confortent une approche par les cas d’usage et les risques, plutôt qu’un choix idéologique entre cloud et local :

• La CNIL indique que le mode de déploiement dépend des données et du cas d’usage pour des données personnelles ou une documentation sensible, le sur site peut limiter certains risques d’extraction, tout en rappelant son coût et ses contraintes d’exploitation.
• L’ANSSI recommande de sécuriser séparément les phases d’entraînement, d’intégration, de déploiement et de production, et de considérer confidentialité, intégrité, disponibilité et interactions avec le système d’information.
• France Num et Bpifrance soulignent les freins liés au coût, aux mauvais usages, au manque de stratégie data et à la nécessité d’un paramétrage métier, les montants de projet cités dans leurs travaux concernent des contextes précis et ne doivent pas être transposés directement à une infrastructure locale.
• L’AI Act prévoit des mesures spécifiques pour les PME et start-up, notamment des actions de sensibilisation, de formation et un accès prioritaire à certains bacs à sable réglementaires, le niveau d’obligation dépend du rôle et du risque du système.

Les références constructeurs sur le TCO peuvent éclairer les postes de coût, mais elles restent des études situées et potentiellement intéressées. Toute décision doit être recalculée à partir des données de l’entreprise, d’un benchmark représentatif et de plusieurs scénarios de charge.

• Pas d’économie automatique : le local peut être plus coûteux pour de faibles volumes ou des usages très occasionnels.
• Pas de confidentialité automatique : la sécurité dépend de l’architecture, des accès, des sauvegardes, des logs et des pratiques d’exploitation.
• Pas de remplacement intégral du cloud : certains contextes massifs, modèles spécialisés ou pics de charge justifient une capacité externe.
• Pas de productivité sans adoption : un modèle performant ne crée pas de valeur si les équipes ne l’intègrent pas dans leurs processus.
• Pas de traitement comptable universel : les effets d’un achat, d’une location financière ou d’un abonnement dépendent du contrat et de la situation du client, ils doivent être confirmés par ses conseils.

Le local n’est pas un pari contre le cloud. Il permet de reprendre la main sur une infrastructure que l’on comprend, que l’on sécurise et que l’on peut faire évoluer. Il devient intéressant lorsque les usages reviennent souvent, que les données sont sensibles, que les coûts variables sont difficiles à prévoir ou que la disponibilité compte vraiment.

Avancez par étapes : mesurez les usages, lancez un pilote, comparez le coût complet et fixez les règles de routage. Le leasing peut réduire la sortie de trésorerie initiale, mais il ne rend pas une architecture rentable à lui seul. La rentabilité dépend de l’utilisation, de l’exploitation et des résultats obtenus.

Pour ProovUp, cela ouvre une offre plus large qu’une installation technique. Une offre d’usage total de l’IA réunit une infrastructure locale sécurisée, une route hybride vers le cloud, des cas d’usage intégrés, un suivi économique et un accompagnement continu.