IA en local entreprise : quand garder le calcul sur place

Qu'appelle-t-on IA en local, IA sur site et edge AI ?

L'IA en local, l'IA sur site et l'edge AI désignent trois façons de rapprocher le calcul de l'entreprise ou de ses données, mais elles ne recouvrent pas le même périmètre.

IA locale et IA sur site (on-premise)

Une IA locale, aussi appelée auto-hébergée ou on-premise, est un système d'IA installé et exécuté sur l'infrastructure de l'entreprise (serveur local, mini PC ou ordinateur de bureau), sans passer par des serveurs cloud externes [27]. Concrètement, il s'agit d'un modèle de langage et de ses briques logicielles déployés sur cette infrastructure, avec les données conservées dans le périmètre de l'entreprise [21].

Les sources n'emploient pourtant pas « local » de la même façon :

• Certaines le limitent à la machine seule : le modèle s'exécute entièrement sur un ordinateur de bureau ou portable [18].
• D'autres l'étendent à un serveur, dans les locaux de l'entreprise ou chez un hébergeur [16].

Dans le second cas, « sur site » n'est donc pas toujours synonyme de « dans vos murs ».

Edge AI

L'edge AI, ou IA en périphérie du réseau, désigne la mise en œuvre de l'IA dans un environnement d'edge computing [35]. Les algorithmes et modèles sont déployés directement sur des appareils en périphérie [40]. Le calcul se fait à proximité de l'endroit où les données sont collectées, plutôt que dans un cloud centralisé ou un datacenter hors site [35][20].

Une réserve sur les sources

Les sources du dossier sont en grande majorité des acteurs commerciaux (constructeurs, éditeurs, prestataires), dont les définitions accompagnent une offre. Les sources académiques du dossier traitent d'autres sujets et ne sont pas utilisées ici.

Garder les données en interne : quel gain réel pour la confidentialité et la conformité ?

Faire tourner l'IA sur place répond à une contrainte de périmètre : les données ne quittent pas l'organisation. Cela ne remplace pas la mise en conformité.

Ce que le local évite

Quand des équipes envoient des contrats, des dossiers clients ou du code source à une API d'IA américaine, ces données sortent de l'entreprise. Cela soulève des questions juridiques : RGPD, secret des affaires, Cloud Act [37]. Un modèle exécuté en interne écarte cette étape. Le constructeur Lenovo, acteur commercial du matériel, résume l'intérêt ainsi : conserver la maîtrise de ses données propriétaires tout en obtenant plus vite des résultats [20][23]. Le cas est jugé particulièrement utile, voire indispensable, pour les informations confidentielles et les dépôts de code internes [33]. Une université propose d'ailleurs des modèles locaux pour les données sensibles [13].

Moins de contractualisation

Selon un guide de déploiement, sans envoi de données à un fournisseur externe, il n'y a pas de sous-traitant IA à référencer ni de DPA à signer. Le même guide juge le Cloud Act inapplicable, car aucune entreprise américaine n'héberge les données [24]. Cet argument vaut tant que la chaîne d'hébergement reste maîtrisée.

Ce que le local ne règle pas

Le local répond à la contrainte de ne pas faire sortir la donnée d'un périmètre défini, mais il ne dispense pas des obligations RGPD classiques [14]. Les autres exigences du règlement continuent donc de s'appliquer aux traitements réalisés en interne. Parmi elles, on peut citer la base légale, l'information des personnes et la sécurité. Ce point repose sur une seule source du dossier, qui ne détaille pas ces obligations.

Quand la latence et la bande passante justifient-elles l'edge AI ?

Traiter les données près de leur source réduit la latence et limite la bande passante consommée, deux gains qui comptent surtout quand les données sont produites en continu et que la réponse doit être rapide. L'edge AI (« IA en périphérie ») consiste à réaliser les calculs à proximité de l'endroit où les données sont collectées, plutôt que dans un cloud centralisé ou un datacenter distant [35]. Réaliser ces calculs localement réduit considérablement la latence et permet une prise de décision plus rapide [39].

L'exemple type est la caméra industrielle. Au lieu d'envoyer toutes les images vers le cloud pour analyse, on les traite directement sur un terminal périphérique [28]. Seul le résultat de l'analyse a alors besoin de circuler, ce qui explique l'effet sur la bande passante. Le même raisonnement vaut pour d'autres équipements : certaines entreprises déplacent l'inférence du cloud vers les postes de travail pour réduire la latence et les coûts de bande passante, en plus d'améliorer la confidentialité [22].

L'edge AI se justifie donc surtout dans deux cas :

• la décision doit être rapide, et un aller-retour vers un datacenter distant est un obstacle ;
• le flux de données est volumineux et continu, comme les images d'une ligne de production, et l'envoyer en totalité vers le cloud serait coûteux.

Un chiffre circule sur l'ampleur du mouvement. Selon Renewator, cité par un blog, 55 % de l'inférence IA en entreprise se ferait désormais en local ou en edge, contre 12 % en 2023 [36]. Ce chiffre est rapporté par un tiers, nous n'avons pas pu le vérifier et il ne doit pas servir de base à une décision d'investissement. Les sources qui vantent l'edge AI sont par ailleurs souvent des acteurs commerciaux du matériel [39][35].

C'est le cas d'usage visé par Nexus One, le boîtier d'Oupi conçu pour faire tourner l'IA au plus près des données.

IA locale ou cloud : que change le modèle de coûts ?

L'IA locale et le cloud n'ont pas la même structure de coûts : la première vise un coût quasi fixe, le second facture généralement à l'usage, au jeton.

Deux logiques de facturation

• IA locale : le modèle tourne sur votre propre serveur, dans vos locaux ou chez un hébergeur. Son atout principal est un coût quasi fixe [16].
• IA cloud : les coûts sont généralement calculés par jeton utilisé [25]. Un jeton (token) est l'unité de texte que le modèle lit ou produit. La facture suit donc le volume d'usage.

Ces deux constats viennent de prestataires du secteur [16][25] : ils décrivent une tendance, pas un tarif.

Raisonner en trajectoire, pas sur le prix d'entrée

Le bon calcul se fait « en trajectoire », pas en « prix d'entrée » [21]. Un abonnement ou une facturation au jeton paraît léger au départ, mais il évolue avec l'adoption par les équipes. À l'inverse, une infrastructure locale demande un engagement initial, puis une dépense plus stable. Comparez donc des scénarios d'usage sur la durée plutôt que deux devis de départ.

Le matériel reste à financer

« Quasi fixe » ne veut pas dire nul. Installer une IA sur sa propre machine ne génère aucun coût d'utilisation hors matériel [34] : l'achat, l'hébergement et l'exploitation de l'équipement restent à votre charge.

Le dossier ne fournit aucun seuil de rentabilité chiffré, et cet article n'en avance donc pas. Pour votre cas, il faut estimer votre volume d'usage prévisible, le coût du matériel et de son exploitation, et la durée sur laquelle vous comptez amortir l'investissement.

Sur quel matériel faire tourner l'IA : poste, serveur ou boîtier ?

Le bon matériel dépend de la taille du modèle et du nombre d'utilisateurs : un poste ou un mini PC pour un usage individuel avec un petit modèle, un serveur local pour servir une équipe.

Les options, de la plus légère à la plus lourde

• Poste de travail ou mini PC. Une IA locale peut tourner sur l'infrastructure de l'entreprise, qu'il s'agisse d'un serveur local, d'un mini PC ou d'un ordinateur de bureau, sans serveurs cloud externes [27]. Sur un appareil peu puissant, le calcul et le stockage limitent les possibilités. Les petits modèles de langage (SLM), comme Phi, y sont mieux adaptés. Microsoft, qui publie cette recommandation, ajoute que ses PC Copilot+ embarquent des modèles intégrés [29].
• Serveur local. Un serveur de bureau ou départemental, souvent équipé de GPU dédiés, peut desservir une équipe en gardant les données dans le réseau interne [10]. Avec les techniques d'optimisation, un serveur d'entreprise standard peut déjà servir des modèles performants pour des tâches de classification ou de résumé, sans cluster de calcul intensif [32].
• Hébergement du LLM chez un tiers. Cette méthode figure parmi celles recensées pour héberger une plateforme LLM [19], et certaines sources rangent « chez un hébergeur » dans l'IA locale [16]. Les définitions ne coïncident donc pas toutes : si le serveur n'est plus dans vos murs, vérifiez où se trouvent les données avant de parler d'IA sur site.

Nexus One

Nexus One est le boîtier d'Oupi pour faire tourner l'IA au plus près des données. Il s'ajoute à ces options pour les organisations qui veulent un équipement dédié plutôt qu'un poste ou un serveur généraliste. Le détail figure sur la page Nexus One.

Quelles sont les limites de l'IA locale, et quand le cloud reste-t-il pertinent ?

L'IA locale a trois limites principales : des modèles souvent moins puissants, un matériel à dimensionner et une sécurité à organiser soi-même. Un guide grand public (CNET) indique qu'elle exige un matériel solide, avec au moins 8 Go de RAM, et donne accès à des modèles moins puissants que les services en ligne [38]. Selon Microsoft, un appareil dont la puissance de calcul ou le stockage est limité peut en pâtir, et les modèles linguistiques réduits (SLM), comme Phi, conviennent mieux à un usage local [29].

Le cloud garde l'avantage sur les plus gros modèles. Un contributeur d'un forum (Reddit) explique que la plupart des utilisateurs passent par le cloud parce que ces modèles demandent une grande puissance de calcul [12]. Un article d'expert présente aussi le cloud comme irremplaçable pour certains usages [30]. Enfin, une société de services (WorkMyWay) souligne que l'entreprise peut rester dépendante du fournisseur de son modèle, même si les données restent en interne [25].

La sécurité ne vient pas avec le matériel. Le local ne dispense pas des obligations RGPD classiques [14]. Un prestataire (ID Interactive) décrit ses propres mécanismes : isolation réseau du serveur d'IA, connexions sortantes contrôlées et journalisées, absence de clé d'API vers un service tiers, audit mensuel des journaux d'accès [26]. Cet exemple vient d'un acteur commercial, mais il donne une base de contrôles à vérifier.

Grille de décision. Le calcul sur place se justifie surtout si :

• les données sont sensibles ou réglementées [14][37] ;
• la latence ou la bande passante est critique [22][28] ;
• l'usage est intensif, ce qui avantage un coût quasi fixe [16][25] ;
• les tâches sont compatibles avec des modèles modestes [29][32].

Si un de ces critères manque, ou si la tâche exige un très gros modèle, le cloud reste pertinent [12][30]. Une approche hybride est plausible, mais les sources du dossier la décrivent peu : elles ne permettent pas d'en détailler l'architecture.