Déployer une IA en local en aéronautique, c'est installer un modèle de langage spécialisé (SLM) sur un serveur interne, dans un périmètre sans connexion vers un fournisseur cloud, avec des accès restreints aux personnes habilitées. Concrètement : un GPU dimensionné au modèle, un réseau cloisonné ou totalement air-gapped, une journalisation systématique des requêtes, et un processus de mise à jour maîtrisé. C'est l'architecture qui permet d'utiliser l'IA sur des données couvertes par l'ITAR ou le secret industriel sans jamais les exposer.
Ce guide couvre les cinq questions concrètes que se pose un DSI ou un RSSI de sous-traitant aéronautique avant de lancer un tel projet : pourquoi le local plutôt que le cloud, quel matériel prévoir, comment sécuriser les accès, ce que change un déploiement air-gapped, et comment faire vivre le modèle dans la durée sans réintroduire du risque.
Pourquoi déployer en local plutôt que dans le cloud en contexte aéronautique
Le 28 mai 2026, Airbus a officialisé un accord pluriannuel avec Mistral AI pour héberger une IA souveraine directement dans l'infrastructure du groupe, plutôt que de passer par un fournisseur cloud généraliste (Le Journal Toulousain). Ce signal descendant se répercute sur toute la chaîne de sous-traitance : les rangs 1, 2 et 3 vont devoir démontrer qu'ils traitent leurs propres données IA avec le même niveau de rigueur. Notre article IA souveraine vs ChatGPT chez les sous-traitants aéronautiques détaille ce que cet accord change concrètement pour un sous-traitant qui utilise encore ChatGPT sur des données sensibles.
Le on-premise n'est pas un choix idéologique contre le cloud. C'est une réponse à une contrainte précise : une partie des données manipulées en aéronautique (plans, notes de calcul, procédés, documentation soumise à l'ITAR ou l'EAR) ne peut légalement ou contractuellement pas transiter par un serveur tiers non maîtrisé.
Le risque ITAR et EAR sur un appel API cloud
L'ITAR (International Traffic in Arms Regulations) et l'EAR (Export Administration Regulations) encadrent l'export de technologies liées à la défense. Un appel API vers un LLM cloud transmet le contenu de la requête, y compris les extraits de documentation technique, vers des serveurs qui peuvent sortir du périmètre autorisé. Même les offres "souveraines" des grands clouds ont des limites précises sur les accès et les transferts que peu d'entreprises auditent réellement avant signature.
Ce que le on-premise change concrètement
Avec un modèle hébergé en interne, aucune requête ne sort du réseau de l'entreprise. Le risque de divulgation réglementée disparaît par construction, pas par contrat. C'est une différence importante face aux auditeurs et aux donneurs d'ordre : on peut montrer l'architecture, pas seulement une clause de confidentialité.
Principe de base
Le on-premise ne remplace pas la gouvernance : il crée les conditions techniques de la conformité (zéro trafic sortant), mais la politique d'habilitation, la formation et la responsabilité humaine restent à construire à côté. Un serveur bien sécurisé avec une gouvernance absente reste un projet incomplet.
Le matériel : quel GPU pour un SLM en local
Le choix du matériel dépend de trois paramètres : la taille du modèle retenu, le nombre d'utilisateurs simultanés, et le niveau de latence acceptable. Un SLM de 3 à 8 milliards de paramètres se fine-tune et s'exécute sur un seul GPU, ce qui change radicalement le budget par rapport à un grand LLM de plusieurs centaines de milliards de paramètres. Ce fine-tuning se fait précisément à partir des données confidentielles évoquées plus haut : notre article entraîner une IA sur des données aéronautiques confidentielles détaille comment préparer ce type de dataset (FAI, 8D, CCTP) avant de dimensionner le GPU.
CPU seul pour un usage mono-utilisateur
Pour un modèle de 3 à 4 milliards de paramètres quantifié en Q4 (Ministral 3B, Phi-4-mini), un serveur CPU récent avec 16 Go de RAM DDR5 suffit pour 1 à 3 utilisateurs. Comptez 10 à 25 tokens par seconde selon le processeur, soit une réponse de 100 à 200 mots générée en 8 à 20 secondes. Correct pour un usage occasionnel, limite pour un service partagé.
GPU grand public pour une équipe
Pour un modèle de 7 à 8 milliards de paramètres (Ministral 8B, Qwen2.5 7B) servant une dizaine d'utilisateurs, une carte Nvidia RTX série 40 (RTX 4060 Ti 16 Go ou RTX 4090 24 Go) change la donne : 60 à 100 tokens par seconde, réponse en moins de 3 secondes. Ces cartes tiennent dans une station de travail standard, sans salle serveur dédiée.
GPU professionnel pour un déploiement d'atelier
Au-delà de 20 à 30 utilisateurs simultanés, ou pour héberger plusieurs modèles en parallèle (un pour la documentation technique, un pour l'analyse qualité), une carte professionnelle type Nvidia L4 ou A10 (24 Go de VRAM, conçue pour tourner en continu dans un rack) devient pertinente. Ce sont des cartes pensées pour l'inférence serveur, avec une meilleure fiabilité thermique qu'une carte grand public poussée en continu.
| Configuration | Taille de modèle | Utilisateurs simultanés | Débit approximatif | Ordre de grandeur matériel |
|---|---|---|---|---|
| CPU seul (16 Go RAM) | 3-4B, quantifié Q4 | 1-3 | 10-25 tokens/s | 400-700 euros |
| RTX 4060 Ti (16 Go VRAM) | 7-8B | 5-10 | 60-100 tokens/s | 450-600 euros (carte seule) |
| RTX 4090 (24 Go VRAM) | 7-8B, contexte long | 10-20 | 90-140 tokens/s | 1600-2000 euros (carte seule) |
| Nvidia L4 / A10 (24 Go VRAM pro) | 7-8B, multi-modèles | 20-30+ | 80-130 tokens/s | Serveur rack, budget entreprise |
Pour le détail des modèles eux-mêmes (Ministral, Phi-4-mini, tailles et licences), notre guide Ministral et Mistral Small, guide des SLM français couvre les benchmarks et les arbitrages de licence.
Sécuriser l'accès : habilitations, journalisation et ITAR
Un serveur bien dimensionné ne sert à rien si l'accès n'est pas maîtrisé. En contexte ITAR ou EAR, la sécurisation des accès n'est pas une option de configuration, c'est une exigence réglementaire.
Restreindre l'accès aux personnes habilitées
Le principe du "need to know" s'applique : seules les personnes dont la mission le justifie, et dont la nationalité ou le statut est compatible avec les règles ITAR du programme concerné, doivent pouvoir interroger le modèle. Techniquement, cela passe par une authentification forte (SSO interne couplé à une MFA) et une gestion des rôles par groupe, avec des bases documentaires cloisonnées selon le niveau d'habilitation.
Journaliser chaque requête pour l'audit trail
Chaque question posée au modèle, chaque document consulté, chaque réponse générée doit être journalisé avec horodatage et identité de l'utilisateur. Cette traçabilité répond à deux besoins simultanés : les exigences de maîtrise documentaire de l'EN 9100, et les contrôles d'accès attendus par le référentiel américain NIST SP 800-171 sur la protection des informations non classifiées contrôlées (CUI). Un audit qui ne trouve aucun log d'accès sur un système IA touchant des données sensibles est un point de non-conformité quasi automatique.
Documenter la chaîne de responsabilité
Au-delà des logs techniques, il faut un registre qui répond à trois questions en permanence : qui a accès au système, sur quelle base cette habilitation a été accordée, et depuis quand. Ce registre est ce qu'un auditeur ITAR ou un auditeur EN 9100 demandera en premier, avant même de regarder l'architecture technique.
Point de vigilance
Un serveur on-premise mal cloisonné en interne reste un risque : si tous les collaborateurs de l'entreprise peuvent interroger un modèle contenant des données ITAR, l'isolement réseau ne compense pas l'absence de contrôle d'accès. Les deux couches sont nécessaires, pas l'une ou l'autre.
Air-gapped : une IA sans connexion internet
Le air-gapped est le niveau de sécurisation le plus strict : le serveur qui héberge le modèle n'a aucune connexion, physique ou logique, vers un réseau externe. Pas de câble, pas de Wi-Fi, pas de VPN sortant. C'est la garantie que même une erreur de configuration applicative ne peut pas exfiltrer de données, puisqu'il n'existe tout simplement pas de chemin réseau vers l'extérieur.
Quand le air-gapped est nécessaire
Sur certains programmes de défense ou sur des données classifiées, le air-gapped n'est pas une option parmi d'autres, c'est une exigence contractuelle du donneur d'ordre. Pour la majorité des sous-traitants aéronautiques civils, un réseau interne cloisonné (VLAN dédié, sans accès internet sortant pour le serveur IA, avec un pare-feu strict) offre déjà un niveau de protection suffisant et plus simple à opérer au quotidien.
Les contraintes opérationnelles du air-gapped
Un serveur sans connexion internet ne peut pas recevoir de mise à jour automatique, ni de correctif de sécurité en temps réel. Chaque mise à jour du modèle, du système d'exploitation ou des dépendances logicielles doit être transférée physiquement (clé USB contrôlée, support validé) après avoir été testée sur un environnement isolé équivalent. C'est plus lent, mais c'est le prix de la garantie d'étanchéité.
Pour l'architecture RAG qui accompagne souvent ce type de déploiement (indexation de documentation technique, recherche vectorielle locale), notre article SLM embarqué pour la documentation technique aéronautique détaille la chaîne complète, de l'indexation à l'affichage de la source.
Maintenir et mettre à jour le modèle dans la durée
Un modèle déployé n'est jamais un projet fini. Sans processus de maintenance, la qualité des réponses se dégrade avec le temps : la documentation évolue, le vocabulaire métier change, de nouveaux cas d'usage apparaissent.
Un cycle MLOps adapté à l'absence de connexion continue
Le principe reste proche du MLOps classique, mais adapté aux contraintes on-premise. Les nouvelles versions du modèle ou du corpus documentaire sont d'abord validées sur un environnement de test isolé, comparées à la version en production sur un jeu de questions de référence représentatif du métier, puis déployées manuellement après validation. Rien n'est poussé automatiquement en production sans ce passage de contrôle.
Définir qui est responsable et à quelle fréquence
La question la plus souvent oubliée : qui, dans l'entreprise, est responsable de cette mise à jour ? À quelle fréquence l'index documentaire est-il rafraîchi quand un AMM ou un service bulletin est révisé ? Sans réponse écrite à ces questions dès le lancement du projet, le modèle finit par tourner sur une version obsolète de la documentation, ce qui est pire que de ne pas avoir d'IA du tout sur un usage réglementé.
Prévoir un mécanisme de retour arrière
Toute mise à jour doit pouvoir être annulée rapidement en cas de régression constatée sur les réponses. Conserver la version précédente du modèle et de l'index, avec une procédure de bascule documentée, évite qu'un incident de qualité se transforme en interruption de service prolongée.
Pour l'arbitrage entre indexer la documentation qui bouge (RAG) et entraîner le vocabulaire métier dans le modèle lui-même (fine-tuning), notre guide architecture hybride SLM/LLM et maîtrise des coûts détaille les arbitrages d'architecture et de budget entre les deux approches.
Ce que le on-premise ne règle pas seul
Le déploiement local résout le problème du transfert de données. Il ne dispense ni de la formation des utilisateurs, ni de la vérification humaine des réponses sur les procédures critiques, ni de la responsabilité qui reste entièrement celle de l'entreprise et de ses collaborateurs. L'IA aide à consulter et à formuler, elle ne décide jamais à la place du technicien ou de l'ingénieur qualité.
Questions fréquentes
Projet IA on-premise en aéronautique
Vous évaluez la faisabilité d'un déploiement local sur votre périmètre ITAR ou EN 9100 ? Cadrons ensemble le matériel, les accès et l'architecture.
Pour aller plus loin
- SLM embarqué pour la documentation technique aéronautique : architecture RAG locale complète, de l'indexation à l'affichage de la source AMM/IPC.
- Ministral et Mistral Small, guide des SLM français : benchmarks, tailles de modèles et licences pour l'entreprise.
- Architecture hybride SLM/LLM et maîtrise des coûts : arbitrer entre RAG et fine-tuning selon le type de document.
- SLM on-device et IA embarquée : architectures edge, serving et benchmarks sur matériel contraint.
- SLM en entreprise : le guide complet : définition, panorama des modèles, comparatif coûts.
- IA pour les sous-traitants aéronautiques à Toulouse : panorama des cas d'usage du secteur.
- IA et MRO en aéronautique à Toulouse : usages de l'IA en maintenance et réparation.
- Intégrer LLM, RAG et Agents IA : accompagnement Tensoria pour le cadrage et le déploiement de systèmes IA sur mesure en entreprise.
- ITAR et le piège du LLM cloud pour les sous-traitants de défense : analyse détaillée des risques réglementaires.
- Conformité ITAR 2026 : ce que doit savoir tout CIO et CSO : panorama des obligations à jour pour 2026.
