Faire tourner l’IA sur ses propres serveurs : le guide pour une PME

Depuis dix-huit mois, je fais tourner des modèles de langage en local sur des rigs GPU, à côté des API cloud que j’utilise au quotidien. Cette double pratique m’a appris une chose : la question « où tournent nos IA » n’est pas un débat d’ingénieur, c’est une décision de direction. Je vous propose ici un guide honnête, sans hype, pour arbitrer ce qui doit rester chez vous et ce qui peut partir chez un fournisseur.

Pourquoi la question se pose vraiment

Quand un de vos collaborateurs colle un contrat, un dossier RH ou un compte-rendu médical dans une interface de chat en ligne, ces données quittent votre entreprise. Elles transitent vers des serveurs que vous ne contrôlez pas, souvent hors d’Europe, et vous n’avez qu’une garantie contractuelle sur ce qu’il en advient. Pour beaucoup d’usages anodins, c’est acceptable. Pour d’autres, c’est un risque que peu de dirigeants mesurent.

Le premier enjeu est réglementaire. Le RGPD vous rend responsable du traitement des données personnelles que vous confiez à un sous-traitant. Si ce sous-traitant est une entreprise américaine, s’ajoute le Cloud Act : une loi qui permet aux autorités américaines de réclamer des données à une société soumise à leur juridiction, y compris quand ces données sont stockées sur un serveur situé en Europe. Autrement dit, la localisation physique du datacenter ne suffit pas à vous protéger : ce qui compte, c’est la nationalité juridique du fournisseur.

Le second enjeu est stratégique. Certaines données ne sont pas seulement « personnelles », elles sont le cœur de votre valeur. Je pense aux secrets industriels, aux formules, aux plans, aux fichiers clients, aux grilles tarifaires, aux dossiers juridiques en cours. Envoyer ces éléments à un tiers pour qu’une IA les résume ou les analyse, c’est accepter qu’ils sortent de votre périmètre de confidentialité. Dans la santé, les RH ou le conseil, ce n’est tout simplement pas envisageable pour une partie des traitements.

Je ne dis pas que le cloud est dangereux par nature. Je dis qu’il faut distinguer les données selon leur sensibilité, et choisir l’infrastructure en conséquence. C’est exactement ce que fait déjà votre DSI avec les fichiers : tout n’est pas stocké au même endroit ni avec les mêmes droits.

Les trois options, et leurs compromis

Il existe trois grandes façons de mettre de l’IA générative entre les mains de vos équipes. Chacune place le curseur différemment entre coût, performance et confidentialité.

Option 1 : l’API cloud

Vous appelez un modèle puissant hébergé par un fournisseur (Anthropic avec Claude, OpenAI avec GPT, Mistral, Google). C’est l’option la plus simple et la plus performante. Les modèles sont excellents, vous n’avez aucun matériel à gérer, et vous payez à l’usage.

Le compromis : vos données sortent. La plupart des fournisseurs sérieux s’engagent aujourd’hui à ne pas entraîner leurs modèles sur les données transmises par API, et proposent des options de non-rétention. Mais l’engagement reste contractuel, et la question du Cloud Act demeure pour les acteurs américains. Côté coût, l’usage intensif finit par peser : facturé au token, un déploiement à l’échelle de toute une entreprise peut représenter plusieurs centaines à plusieurs milliers d’euros par mois.

Option 2 : le modèle hébergé en Europe

Vous utilisez un modèle servi par un fournisseur européen, ou un modèle open-weight déployé chez un hébergeur européen souverain. Vous gagnez sur le plan juridique : le fournisseur relève du droit européen, ce qui neutralise l’essentiel du risque Cloud Act. Les performances sont bonnes, souvent proches de l’option 1.

Le compromis : vos données quittent toujours vos murs, même si elles restent dans un cadre juridique protecteur. Et vous dépendez d’un prestataire, avec un coût récurrent. C’est un excellent compromis pour beaucoup de PME qui veulent de la performance sans monter une infrastructure, tout en respectant le RGPD sereinement.

Option 3 : le modèle open-weight auto-hébergé

Vous téléchargez un modèle à poids ouverts (Llama 3.1, Mistral, Qwen…) et vous le faites tourner sur votre propre matériel, dans vos locaux ou sur un serveur que vous maîtrisez. C’est ce que je pratique avec Ollama et des modèles 7B–8B en quantization Q4. Ici, les données ne sortent jamais. La confidentialité est maximale, par construction : il n’y a pas de fournisseur à qui faire confiance, il n’y a que vous.

Le compromis : la performance brute d’un modèle 8B local reste en dessous des grands modèles cloud, et vous devez investir dans du matériel et assumer la maintenance. C’est l’option souveraine, mais elle exige un peu d’ingénierie et un peu de réalisme sur ce que ces modèles savent faire.

Ce qu’un modèle local 7B–8B sait vraiment faire

C’est le point sur lequel je vois le plus de malentendus, dans les deux sens. Certains croient qu’un modèle local est un jouet ; d’autres imaginent qu’il remplace Claude ou GPT sur tout. La vérité est plus intéressante.

Un modèle 7B–8B tournant sur votre serveur est très compétent sur une famille de tâches précises :

• La classification : trier des e-mails entrants, catégoriser des tickets de support, router des demandes vers le bon service, détecter le sentiment d’un avis client. Sur ces tâches cadrées, la qualité est au rendez-vous.
• L’extraction d’informations : sortir les montants, dates, noms et clauses d’un document, transformer un e-mail en champs structurés pour votre logiciel de gestion — une brique classique d’automatisation des processus. C’est un usage où le local excelle et où l’enjeu de confidentialité est souvent fort.
• La reformulation et la rédaction assistée : réécrire un texte, l’adapter à un ton, produire un brouillon de réponse, résumer un compte-rendu. Pour des documents internes sensibles, faire cela en local a beaucoup de sens.
• Le RAG (génération augmentée par récupération) : brancher le modèle sur votre base documentaire pour qu’il réponde à partir de vos propres documents. C’est le principe des assistants documentaires que je mets en place, et là que le local devient vraiment puissant en entreprise, car le modèle n’a pas besoin de « tout savoir » : il a besoin de bien lire les documents que vous lui donnez et de répondre en s’appuyant dessus.

Ses limites face au cloud sont réelles et il faut les nommer. Un modèle 8B raisonne moins bien sur des problèmes complexes en plusieurs étapes, produit un code moins fiable, gère moins finement des instructions très longues ou très subtiles, et se débrouille moins bien dans certaines langues rares. Sur une tâche exigeant une vraie profondeur de raisonnement ou une créativité de haut niveau, un grand modèle cloud reste supérieur. Mais l’immense majorité des usages quotidiens d’une PME relèvent de la classification, de l’extraction, de la reformulation et du RAG — précisément le terrain où le local tient parfaitement la route.

Le matériel et les ordres de grandeur de coût

Parlons concret, car c’est souvent le point de blocage. Faire tourner un modèle 7B–8B quantifié ne demande pas un supercalculateur. Le composant qui compte est la carte GPU, et plus précisément sa mémoire vidéo (VRAM). Une carte grand public dotée de 12 à 24 Go de VRAM suffit à faire tourner confortablement un modèle 8B quantifié, avec des temps de réponse tout à fait utilisables pour un petit groupe d’utilisateurs.

En ordre de grandeur, un serveur d’inférence pour une PME représente un investissement de 3 000 à 8 000 euros : la fourchette basse pour une machine mono-GPU dimensionnée pour quelques utilisateurs simultanés, la fourchette haute pour une configuration plus robuste, multi-GPU, capable de servir davantage de monde ou des modèles plus gros. À cela s’ajoute l’installation et la configuration, que vous internalisez ou confiez à un prestataire.

La vraie bascule économique se situe après. Une fois le matériel amorti, le coût d’usage est quasi nul : vous ne payez que l’électricité et la maintenance. Vous pouvez traiter des millions de tokens par jour sans voir une facture grimper. C’est l’inverse du modèle cloud, où chaque appel coûte. Pour une entreprise qui a un volume d’usage régulier et prévisible, le calcul devient vite favorable au local : l’investissement initial se rentabilise en général en un à deux ans par rapport à un abonnement cloud intensif, tout en offrant une confidentialité que le cloud ne peut pas égaler.

Je précise que ces montants sont des ordres de grandeur, à affiner selon vos besoins réels de débit et de disponibilité. L’objectif ici n’est pas de vous donner un devis, mais de vous montrer que le ticket d’entrée est celui d’un serveur d’entreprise classique, pas d’un projet à six chiffres.

Comment décider : l’approche hybride

Ma recommandation n’est presque jamais « tout local » ni « tout cloud ». C’est une approche hybride, où vous classez vos usages selon la sensibilité des données, et vous routez chaque usage vers la bonne infrastructure. J’ai détaillé cet arbitrage dans un guide dédié : cloud ou local, quel LLM choisir pour votre entreprise.

La règle que j’applique est simple. Dès qu’un traitement touche des données personnelles sensibles, des documents confidentiels, des secrets industriels ou des informations couvertes par une obligation de discrétion, il reste en local. L’analyse de dossiers RH, la lecture de contrats en cours, l’exploitation de données de santé, la recherche dans une base documentaire interne : tout cela ne sort pas.

À l’inverse, pour tout ce qui n’est pas sensible — rédiger un article de blog, brainstormer une campagne marketing, générer du code sur un projet non confidentiel, traduire un document public — j’utilise le cloud, parce que la performance est meilleure et qu’il n’y a aucun risque à confier ces contenus. C’est exactement ma pratique : le local pour les données sensibles, le cloud pour le reste.

Concrètement, cela se traduit par une petite cartographie de vos cas d’usage, colonne par colonne : quelle donnée, quelle sensibilité, quelle infrastructure. Cet exercice, fait une fois avec votre responsable IT, clarifie les décisions pour des mois et évite les fuites accidentelles.

Les pièges à connaître

Monter une IA locale n’est pas magique, et je préfère vous prévenir des embûches plutôt que de vous vendre du rêve.

Les droits d’accès. C’est le piège le plus fréquent et le plus grave. Quand vous branchez un modèle sur votre base documentaire pour faire du RAG, il peut potentiellement restituer à un utilisateur des informations auxquelles cet utilisateur n’aurait pas dû accéder. Une IA qui répond à partir de vos documents doit respecter exactement les mêmes permissions que vos utilisateurs. Ce cloisonnement se conçoit dès le départ, pas après coup.

Les hallucinations. Un modèle, local ou cloud, peut produire une réponse fausse avec un aplomb total. C’est particulièrement délicat sur les tâches où l’on attend une exactitude factuelle. Le RAG réduit fortement le risque en ancrant les réponses dans vos documents, mais ne l’élimine pas. Toute sortie qui engage une décision importante doit rester sous supervision humaine. L’IA propose, un humain valide.

La maintenance. Un serveur d’inférence est un serveur : il faut le mettre à jour, surveiller sa disponibilité, gérer les modèles, assurer les sauvegardes et la sécurité. Ce n’est pas lourd, mais ce n’est pas nul. Une PME doit soit disposer de la compétence en interne, soit s’appuyer sur un prestataire pour l’installation et le maintien en condition. Sous-estimer ce poste, c’est se retrouver avec une machine que plus personne ne maîtrise six mois plus tard.

En résumé

Faire tourner l’IA sur vos propres serveurs n’est plus réservé aux grandes structures. Le matériel est accessible, les modèles open-weight sont bons, et la souveraineté qu’ils offrent sur vos données sensibles n’a pas d’équivalent dans le cloud. La bonne stratégie n’est pas idéologique : elle est pragmatique. Vous gardez en local ce qui est sensible, vous confiez au cloud ce qui ne l’est pas, et vous décidez en connaissance de cause plutôt que par défaut. C’est la meilleure façon de profiter de l’IA sans confier vos secrets à un géant que vous ne contrôlez pas.

Vous vous demandez ce qui, dans votre entreprise, gagnerait à rester en local ? Parlons-en lors d’un diagnostic gratuit : je vous dis franchement ce qui est faisable et à quel coût.