Objectifs pédagogiques

• Distinguer une IA exécutée sur un poste, un serveur interne ou une infrastructure distante.
• Reconnaître une architecture hybride et ses échanges de données.
• Différencier installation locale, auto-hébergement et fonctionnement hors ligne.
• Comparer les contraintes de coût, de maintenance et de disponibilité.
• Proposer une architecture en justifiant les conditions nécessaires à son utilisation.

1. Commencer par définir le périmètre

Dans cette formation, nous parlerons d’IA locale lorsque les traitements concernés s’exécutent sur votre ordinateur ou sur un serveur situé dans vos locaux. Nous préciserons toujours si toute la chaîne est locale ou seulement une partie.

Le cloud désigne ici une infrastructure distante utilisée pour le traitement, généralement exploitée par un fournisseur. Une architecture hybride combine des composants locaux et distants selon une répartition définie.

Attention au vocabulaire : un serveur dédié loué dans un centre de données est distant, sans être nécessairement une offre cloud au sens technique strict. Pour votre décision, l’essentiel reste de connaître sa localisation, son opérateur, les accès possibles et les flux.

Exemple : une PME possède un serveur dans son atelier. Dix collaborateurs y accèdent depuis leurs postes. L’IA reste locale à l’entreprise, même si elle ne tourne pas sur chacun des dix ordinateurs.

2. L’IA locale : calculer sur un équipement de l’entreprise

Sur un poste individuel

Le modèle et son moteur d’exécution sont installés sur l’ordinateur utilisé pour travailler. Le poste doit disposer de ressources suffisantes pour la tâche demandée.

Exemple : une consultante reformule ses notes avec un modèle installé sur son ordinateur portable. Pour qualifier cet usage de entièrement local, il faut aussi vérifier que les notes, l’historique et les fonctions utilisées ne sont pas transmis à un service extérieur.

Cependant, l’IA locale impose un investissement matériel immédiat, contrairement au cloud. Les modèles de langage requièrent une mémoire vidéo importante (VRAM). Ainsi, l’ordinateur de cette consultante ou le serveur interne de l’entreprise devront être équipés de cartes graphiques performantes, dont le coût initial doit être budgétisé. Sans ce matériel spécifique, les calculs seront trop lents pour un usage professionnel.

Sur un serveur interne

Le moteur fonctionne sur une machine partagée. Les utilisateurs y accèdent par le réseau de l’entreprise, souvent avec un navigateur. Cette organisation centralise les modèles et l’administration, mais exige de gérer les comptes, les accès et la charge simultanée.

Avantages possibles : maîtrise de l’équipement, choix des versions et fonctionnement sans accès Internet pour les fonctions préparées en conséquence.

Contraintes : achat ou mobilisation du matériel, consommation électrique, sauvegardes, surveillance et maintenance.

Il faut d’ailleurs budgétiser précisément cette consommation : contrairement au Cloud facturé de manière imprévisible à l’usage (au nombre de tokens générés), l’IA locale repose sur des cartes graphiques (GPU) très gourmandes en énergie. Un serveur ou une station de travail dotée d’une alimentation puissante (par exemple de 1000W) sollicitant fortement ses composants représente un coût électrique fixe et non négligeable si la machine tourne 24h/24.

Une panne du serveur peut interrompre le service pour toute l’équipe.

3. L’IA dans le cloud : utiliser des ressources distantes

Une demande est transmise à un service distant qui réalise le calcul et renvoie un résultat. L’accès peut se faire par une interface web ou par une API, c’est-à-dire une interface permettant à un logiciel d’appeler un autre service.

Une API ne désigne pas obligatoirement un service cloud : un serveur local peut également proposer une API. Il faut identifier la destination de l’appel.

Deux situations courantes sont à distinguer :

• Le service prêt à l’emploi : le fournisseur gère l’application et les modèles ; vous paramétrez les usages et les comptes selon les possibilités de l’offre.
• L’infrastructure louée : vous installez votre propre environnement sur une machine distante ; vous restez responsable d’une partie plus importante de son administration.

Avantages possibles : démarrage sans achat d’un GPU, accès à des ressources importantes et adaptation de la capacité selon l’offre.

Contraintes : dépendance à la connectivité, au fournisseur, aux quotas et à la tarification. Les règles de conservation, de réutilisation et d’accès aux données doivent être examinées pour l’offre exacte retenue.

La tarification « à la consommation » du cloud (facturation au nombre de tokens ou de mots générés) peut également représenter un risque financier. Si une entreprise met à disposition un assistant cloud à tous ses employés pour analyser quotidiennement de longs documents PDF (comme des appels d’offres), la facture mensuelle peut exploser de manière imprévisible, rendant parfois l’achat d’un serveur local plus rentable à moyen terme.

Exemple : une agence prépare des variantes d’un texte public avec un service distant autorisé par l’entreprise. Elle doit tout de même contrôler les résultats et éviter d’ajouter des informations internes non prévues.

4. L’architecture hybride : répartir les traitements

Une architecture hybride organise la coopération entre composants locaux et distants. Elle peut réserver certains traitements au serveur interne et envoyer d’autres demandes vers une ressource externe.

Exemple : un assistant recherche des passages dans des documents stockés dans les locaux, puis transmet ces passages à un modèle distant pour rédiger une réponse. Les documents complets restent sur place, mais les extraits transmis quittent l’entreprise.

Autre possibilité : une application dirige les demandes internes vers un modèle local et les travaux sur des contenus publics vers un service distant. Cette répartition doit être définie et contrôlée ; elle ne doit pas reposer uniquement sur la vigilance de l’utilisateur.

Trois règles à fixer :

1. Quelles catégories de données peuvent être transmises à l’extérieur ?
2. Quel composant décide de la destination et comment cette décision est-elle vérifiée ?
3. Que se passe-t-il si le modèle local ou le service distant devient indisponible ?

Ce dernier point correspond au scénario hybride le plus fréquent en entreprise : le « Fallback ». Le système interroge d’abord le serveur local (gratuit et sécurisé). Mais si le modèle local juge la question trop complexe ou s’il est surchargé, l’application redirige automatiquement la requête vers une API Cloud puissante (payante). C’est ce basculement silencieux qu’il faut surveiller de très près si la requête initiale contenait des données confidentielles.

La parade la plus efficace en cybersécurité n’est pas seulement de faire confiance à l’interface logicielle, mais d’appliquer une isolation stricte au niveau de l’infrastructure. En plaçant votre moteur d’IA locale dans un réseau Docker isolé, privé de toute route vers l’extérieur (règles de pare-feu de type egress bloquées), vous rendez techniquement impossible toute fuite de données vers une API Cloud, même en cas de mauvaise configuration de l’application ou de tentative d’exfiltration.

Un basculement automatique vers le cloud peut modifier la destination des données. Pour un traitement réservé au local, mieux vaut prévoir explicitement une mise en attente ou un arrêt qu’un transfert non autorisé.

Utiliser séparément un outil local et un outil cloud constitue une combinaison d’usages. Cela ne signifie pas nécessairement qu’ils forment une architecture intégrée.

5. Comparer les trois approches

Aucune colonne ne garantit à elle seule la meilleure qualité, la plus grande vitesse ou le coût le plus faible. Il faut comparer sur vos tâches, avec le temps de vérification et d’exploitation inclus.

6. Quatre confusions à éviter

« L’application est installée sur mon PC, donc tout reste local. »

Elle peut envoyer des requêtes à un moteur distant, synchroniser l’historique ou utiliser un service externe pour lire un document.

« Je passe par un navigateur, donc c’est du cloud. »

Le navigateur peut ouvrir une interface hébergée sur votre machine ou sur le réseau interne.

« C’est auto-hébergé, donc c’est dans mes locaux. »

L’auto-hébergement décrit une prise en charge de l’exploitation ; l’installation peut être réalisée sur un serveur loué à distance.

« Le serveur est en France, donc toutes les garanties sont acquises. »

La localisation est un élément du choix. Elle ne suffit pas à établir les droits d’accès, les destinations des sauvegardes, la maîtrise des sous-traitants ou la conformité du traitement.

Point de vigilance : le RGPD ne disparaît pas lorsque les données personnelles sont traitées localement. Le choix d’architecture doit être accompagné d’un cadre d’utilisation adapté. Les obligations seront approfondies dans une unité dédiée.

7. Suivre toute la chaîne de traitement

Pour analyser un assistant documentaire, posez les questions dans l’ordre suivant :

1. Réception : où le fichier est-il téléversé ?
2. Extraction : quel outil lit le texte ou reconnaît les caractères d’un document numérisé ?
3. Recherche : où sont produits et conservés les index nécessaires pour retrouver des passages ?
4. Génération : quel modèle reçoit la question et les extraits ?
5. Conservation : où vont l’historique, les journaux et les sauvegardes ?
6. Fonctions annexes : quels services interviennent pour l’authentification, la voix, la recherche web ou les extensions ?

Dans un outil comme Open WebUI, une interface locale n’impose pas que l’extraction, les embeddings — représentations numériques utilisées pour la recherche — et la génération soient tous locaux. Chaque service doit être vérifié.

Les réglages hors ligne ne remplacent pas le filtrage réseau. Une réponse obtenue sans Internet prouve le fonctionnement du scénario testé, pas l’absence de toute communication dans toutes les configurations.

8. Local ne signifie pas indépendant de toute infrastructure

Un assistant sur un poste a besoin de cet ordinateur et de ses fichiers. Un assistant partagé a également besoin du serveur et du réseau interne. Même sans Internet, l’électricité, les comptes et le stockage doivent rester disponibles.

Préparer un fonctionnement hors ligne suppose de disposer à l’avance des modèles, des dépendances et des services requis. Il faut tester un redémarrage et une nouvelle tâche, par exemple l’ajout d’un nouveau document, sans accès extérieur.

Une sauvegarde distante peut protéger un système local contre un sinistre, mais elle constitue un flux de données externe à documenter. Le calcul peut rester local tandis que le stockage de secours ne l’est pas.

9. Choisir à partir du besoin métier

Avant de choisir un produit, rédigez une réponse à ces six questions :

• Quelle tâche doit être réalisée, et comment juger un résultat acceptable ?
• Quelles données sont nécessaires et lesquelles doivent rester dans les locaux ?
• Combien de personnes utiliseront le service simultanément ?
• Faut-il continuer à travailler pendant une coupure Internet ?
• Qui assurera les accès, les mises à jour, les sauvegardes et le support ?
• Quel budget couvre l’installation et l’exploitation dans la durée ?

Si une tâche doit fonctionner hors ligne avec des documents réservés au réseau interne, une chaîne locale complète constitue un point de départ cohérent. Si l’usage est occasionnel, porte sur des données autorisées et exige des ressources importantes, une offre distante peut être étudiée. Si les besoins diffèrent selon les tâches, une répartition hybride peut être pertinente, à condition de maîtriser sa complexité.

Il s’agit de pistes de décision, pas de garanties automatiques : un essai sur des exemples représentatifs doit confirmer la faisabilité.

10. Exercice : identifier l’architecture et le point à contrôler

Durée : 10 à 15 minutes. Les situations suivantes sont fictives. Pour chacune, identifiez l’architecture, les données qui sortent des locaux et un contrôle prioritaire.

1. Atelier A : un ordinateur exécute le modèle, lit les documents et conserve l’historique sur son disque. Aucun service externe n’est utilisé pour ces fonctions.
2. Cabinet B : six collaborateurs utilisent un navigateur pour interroger un serveur situé dans leur bureau. Tous les traitements et stockages de cet assistant y sont réalisés.
3. Agence C : une application installée sur les postes transmet les demandes et les pièces jointes à l’API d’un fournisseur externe.
4. PME D : un moteur recherche des extraits dans un index interne, puis les transmet avec la question à un modèle cloud.
5. Entreprise E : elle administre elle-même son assistant sur un serveur loué dans un centre de données français. Les fichiers y sont envoyés pour traitement.

Application à votre entreprise : choisissez une tâche et proposez une architecture. Notez une contrainte décisive et trois points à vérifier avant de retenir la solution.

11. Vérifiez votre compréhension

1. Un assistant utilisé dans un navigateur est-il nécessairement distant ?
2. Pourquoi un index local ne garantit-il pas que les extraits restent locaux ?
3. Quelle différence faites-vous entre auto-hébergement et hébergement dans les locaux ?
4. Quels équipements restent nécessaires à un assistant local partagé lors d’une coupure Internet ?
5. Pourquoi faut-il encadrer un basculement automatique du local vers le cloud ?

Repère d’autoévaluation : visez au moins quatre réponses correctes sur cinq. Cette vérification personnelle ne remplace pas le quiz de validation prévu dans votre parcours.

12. Votre fiche mémo

• Locale : les traitements concernés s’exécutent sur un poste ou un serveur interne.
• Cloud : le traitement utilise une infrastructure distante ; les conditions dépendent du service retenu.
• Hybride : les opérations sont réparties entre composants locaux et distants.
• Auto-hébergée : la solution est administrée par vous ou pour vous, sans garantie de localisation sur site.
• Hors ligne : les fonctions concernées opèrent sans accès extérieur après préparation et vérification.

Question à retenir : « Pour cette tâche précise, quelles données vont à quel service, où et sous la responsabilité de qui ? »

Unité suivante : définir la souveraineté numérique à l’échelle d’une TPE ou PME.