Qu'est-ce que l'IA on-premise et est-elle rentable pour une PME ?

Que signifie exactement "IA on-premise" ?

L'IA on-premise (aussi appelée auto-hébergée ou locale) désigne l'exécution de modèles d'IA – surtout de grands modèles de langage (LLM) – sur une infrastructure que l'organisation contrôle elle-même. Les requêtes, documents et réponses ne quittent pas votre environnement et ne sont pas transmis à un fournisseur externe.

En pratique, « local » est un spectre : d'une simple station GPU en pilote, à un serveur dans votre propre centre de données, jusqu'à une instance dédiée et mono-locataire chez un fournisseur suisse (cloud souverain). L'important n'est pas seulement l'emplacement, mais qui contrôle les données et les clés.

• On-premise : matériel dans votre propre salle serveur ou centre de données – contrôle physique total.
• Cloud privé/souverain : instance dédiée chez un fournisseur suisse, sans colocation.
• API cloud (pour comparaison) : rapide et évolutive, mais les données quittent l'entreprise.
• Air-gap : fonctionnement totalement isolé d'internet pour une confidentialité maximale.

Architecture de référence : les composants d'une pile on-premise

Un système d'IA on-premise est un modèle en couches. Le matériel est à la base, le logiciel qui exécute le modèle au-dessus, puis les applications, et l'exploitation et la sécurité traversent l'ensemble. Séparer les couches permet de changer de modèle sans reconstruire l'application.

• Couche matérielle : serveur GPU avec VRAM suffisante, réseau et stockage rapides.
• Runtime d'inférence : le logiciel qui charge le modèle et génère les réponses (p. ex. vLLM, Ollama, llama.cpp, Hugging Face TGI).
• Couche modèle : modèles open-weights comme Llama, Mistral, Qwen, Gemma ou le suisse Apertus.
• Ancrage documentaire (RAG) : base vectorielle, embeddings et recherche pour que le modèle exploite vos propres documents.
• Couche applicative : interface de chat, passerelle API et intégrations aux systèmes existants.
• Exploitation et sécurité : authentification, contrôle d'accès, journalisation, supervision et mises à jour.

Besoins matériels et logiciels

Le principal goulet d'étranglement est la mémoire graphique (VRAM). Elle détermine la taille de modèle possible. La quantification – stocker le modèle avec moins de bits par paramètre – réduit fortement les besoins en VRAM, généralement avec une faible perte de qualité. Règle approximative : VRAM ≈ nombre de paramètres × octets par paramètre (quantification 4 bits ≈ 0,5 octet).

• Modèle de 7–8 milliards de paramètres (quantifié) : environ 6–12 Go de VRAM – tourne sur un GPU grand public performant (16–24 Go).
• Modèle de ~70 milliards de paramètres (quantifié) : environ 40–48 Go de VRAM – nécessite un GPU de centre de données ou plusieurs cartes.
• Le fonctionnement CPU seul est possible mais bien plus lent ; un GPU est recommandé pour la charge de production.
• Autres facteurs de dimensionnement : nombre d'utilisateurs simultanés, longueur de contexte et débit requis (jetons par seconde).
• La pile logicielle est en grande partie open source et auto-hébergeable ; vérifiez les prix matériels actuels auprès du fournisseur.

Avantages de sécurité et conformité – le regard suisse

L'atout majeur de l'on-premise est la souveraineté des données : données personnelles, secrets d'affaires et dossiers clients restent dans l'entreprise. Cela facilite la preuve de conformité à la loi révisée sur la protection des données (nLPD) et évite les transferts transfrontaliers sensibles. Pour les professions soumises au secret (avocats, médecins, fiduciaires ; art. 321 CP), le traitement local peut être décisif.

Le règlement européen sur l'IA (EU AI Act) compte aussi : il s'applique de façon extraterritoriale et peut concerner les entreprises suisses vendant dans l'UE. L'on-premise facilite la traçabilité et le contrôle, mais ne remplace pas la gouvernance. Important : local ne signifie pas automatiquement sûr – durcissement, contrôle d'accès, chiffrement et correctifs restent votre responsabilité.

• Aucune transmission à des tiers ni transfert de données transfrontalier incontrôlé.
• Les requêtes et documents ne nourrissent pas l'entraînement de modèles tiers.
• Fonctionnement air-gap possible pour les environnements très sensibles.
• Surveillance en Suisse : le PFPDT ; responsabilité claire plutôt que des CGU d'un fournisseur étranger.
• Mais : la sécurité n'est pas automatique – un concept de sécurité opérationnelle propre est nécessaire.

Attentes réalistes : coûts, qualité, effort

L'on-premise ne se pilote pas tout seul. La qualité des bons modèles open-weights suffit souvent pleinement à de nombreuses tâches de PME : résumé, rédaction, recherche interne, classification. Sur le raisonnement complexe, les longues chaînes et la nuance multilingue, les plus grands modèles cloud gardent toutefois souvent une avance. Cet écart se réduit, mais ne disparaîtra pas du jour au lendemain.

• Modèle de coûts : fort investissement initial en matériel (CapEx) au lieu de frais cloud récurrents (OpEx) ; rentabilité seulement au-delà d'un volume d'usage constant.
• Effort opérationnel : mises à jour, changements de modèle, mise à l'échelle et disponibilité à assurer en interne ou via un partenaire.
• Délai de mise en production : plutôt des semaines à des mois que des jours – intégration des données et tests compris.
• Ne pas tout construire soi-même : les approches appliance ou managed-on-prem réduisent nettement la charge d'exploitation.
• Consommation électrique, refroidissement et matériel de secours entrent dans le coût total de possession (TCO).

On-premise, cloud ou hybride ? Guide de décision pour PME

La question est rarement binaire. De nombreuses PME s'en sortent mieux avec un modèle hybride : garder en local les données sensibles et les tâches standard récurrentes, et envoyer les pics de charge et les tâches très exigeantes vers un cloud (idéalement suisse). Commencez par un cas d'usage bien délimité et un seul serveur GPU, plutôt que de planifier d'emblée un centre de données.

• L'on-premise se justifie avec : données très sensibles, secteurs réglementés, volume élevé et constant, exigence d'air-gap.
• Le cloud se justifie avec : démarrage rapide, charge très variable, besoin de modèles de pointe, ressources IT limitées.
• Hybride : le meilleur des deux – souveraineté locale des données plus modèles cloud de pointe au besoin.
• Pilote d'abord : choisir un cas d'usage mesurable, prouver la valeur, puis passer à l'échelle.