LLM local en entreprise : les questions avant d'acheter des GPU

Le réflexe est compréhensible : on veut que les données restent chez soi, donc on achète des cartes graphiques. Le matériel arrive, et on découvre que le problème n'était pas la puissance de calcul. Il était dans ce qu'on voulait faire avec le modèle, dans qui allait le faire tourner, et dans ce qu'on n'avait pas écrit.

Voici les questions à régler avant le bon de commande. Aucune ne demande un benchmark : les chiffres qui comptent sont les vôtres, et vous ne les avez pas encore mesurés.

Quelles données, exactement ?

C'est la raison qui justifie le plus souvent l'hébergement local, alors précisez-la. Quelles données le modèle verra-t-il ? Des documents internes via une base de connaissances ? Des échanges clients ? Des données personnelles, de santé, des secrets de fabrication ?

Si la réponse est « des contenus peu sensibles », un service externe encadré par un contrat sérieux peut suffire, et le coût d'un parc de GPU ne se justifie pas par la confidentialité. Si la réponse est « des données que nous ne pouvons en aucun cas faire sortir », alors l'hébergement local ou un cloud qualifié se défend. Dans les deux cas, écrivez la classification des données avant de choisir l'architecture. L'ANSSI, dans ses recommandations de sécurité pour les systèmes d'IA générative, demande de cartographier tous les jeux de données utilisés, y compris les requêtes des utilisateurs et les réponses du modèle. Ces dernières sont des données comme les autres.

Autre point que les projets découvrent tard : les droits d'accès. Un assistant branché sur un partage de fichiers peut répondre à un stagiaire avec le contenu d'un document réservé à la direction, si les permissions ne suivent pas. Le modèle ne connaît pas votre organigramme.

Quelle latence, pour quel usage ?

Un assistant de rédaction interactif, un traitement de documents par lots la nuit et un moteur de recherche interne n'ont pas les mêmes exigences. Le premier veut des réponses rapides, le deuxième du débit, le troisième de la précision de recherche autant que du modèle.

Demandez-vous ce qui se passe si la réponse met quelques secondes de plus. Si l'utilisateur renonce, la latence est un critère d'achat. Si personne ne regarde, le matériel peut être plus modeste et le traitement plus lent. Cette réponse oriente la taille du modèle, donc la mémoire nécessaire, donc le budget.

Quelle charge réelle ?

Combien de personnes l'utiliseront en même temps, pas combien de comptes seront créés ? Un outil déployé à toute l'entreprise est utilisé, au quotidien, par une fraction des gens qui y ont accès. Les pics (début de matinée, fin de mois) comptent plus que la moyenne.

Le conseil que je donnerais : commencez par un pilote sur une location de capacité, ou sur un service externe sur des données non sensibles, pour mesurer l'usage réel pendant quelques semaines. Vous achèterez ensuite le matériel sur des mesures, pas sur des projections de prestataire. Cela retarde le projet. Cela évite surtout de payer du matériel sous-utilisé ou, pire, sous-dimensionné pour le premier succès interne.

Quelle énergie, quel refroidissement, quel local ?

Un serveur de calcul n'est pas un poste de travail. Il consomme, il chauffe, il fait du bruit, et il demande une alimentation et une climatisation que la salle serveur d'une PME n'a pas toujours. Demandez au fournisseur la consommation en charge et à vide, la puissance électrique à prévoir, les contraintes de refroidissement. Faites valider par la personne qui connaît votre installation électrique, pas par le commercial.

Ajoutez la question de la durée de vie. Le matériel de calcul évolue vite. Planifiez un amortissement réaliste, et ce que vous faites du matériel quand il est dépassé : revente, reconversion, recyclage. Le coût total se lit sur la durée, électricité comprise.

Qui exploite, et que se passe-t-il pendant les vacances ?

C'est la question qui tue le plus de projets. Un modèle hébergé localement est un système à maintenir : mises à jour des composants, gestion des versions de modèles, surveillance, sauvegarde de la base documentaire, support aux utilisateurs. Qui s'en charge ? Avec quelle compétence ? Que se passe-t-il quand cette personne part ?

Si la réponse est « le DSI, en plus du reste », vous avez un point de défaillance humain. Soit vous recrutez ou formez, soit vous confiez l'exploitation à un prestataire, et vous retombez sur des questions de dépendance et de coût de sortie. Rien n'est gratuit : vous déplacez la dépendance, vous ne la supprimez pas.

L'ANSSI recommande aussi de prévoir un mode dégradé, une procédure qui fonctionne sans le système d'IA (recommandation R15). Si l'outil tombe et que le service commercial ne peut plus répondre à ses clients, vous aviez mal défini son rôle.

Quelle sécurité ?

Héberger chez soi ne rend pas le système sûr. Il crée de nouvelles surfaces. Les recommandations de l'ANSSI (version 1.0 du 29 avril 2024, non normatives) donnent une grille concrète que vous pouvez reprendre telle quelle :

Héberger dans des environnements de confiance adaptés au besoin de sécurité, avec des environnements distincts pour l'entraînement, le déploiement et la production (R11, R12).
Ne pas partager avec d'autres applications métier les GPU qui traitent des données sensibles (R16).
Isoler le système dans des zones logiques dédiées pour limiter les déplacements latéraux en cas de compromission, et documenter tous les flux (R26, R28).
Limiter ou interdire les actions automatiques déclenchées par des entrées non fiables, comme du contenu web externe ou des courriels (R27), et ne pas laisser le système exécuter seul des actions critiques sur le système d'information (R9).
Évaluer la confiance accordée aux bibliothèques et modules externes, et préférer les formats de modèles qui séparent les paramètres du code exécutable. Le guide demande d'écarter des formats comme pickle (R3, R6).
Journaliser l'ensemble des traitements : requêtes, appels aux données, réponses (R29), en respectant les règles de protection des données, durées de conservation comprises.

Cette liste est un cahier des charges. Si votre équipe ou votre prestataire ne peut pas dire comment chaque ligne sera tenue, le projet n'est pas prêt.

La décision

Avant d'acheter, rédigez une page : données concernées, usage et latence acceptable, nombre d'utilisateurs simultanés mesuré, budget énergétique validé, responsable de l'exploitation nommé, mode dégradé décrit, exigences de sécurité reprises. Si une ligne reste vide, c'est elle qu'il faut traiter d'abord. Le GPU, lui, peut attendre.