Souveraineté des données et IA conversationnelle en environnement industriel

Où vont réellement les données avec une API grand public ?

La manière la plus rapide de déployer un personnage IA consiste à appeler l'API d'un fournisseur de modèle de langage grand public. Techniquement, chaque message envoyé par un opérateur ou un visiteur transite par les serveurs de ce fournisseur, où il est traité pour générer une réponse. Selon le fournisseur et le contrat commercial souscrit, ces échanges peuvent être conservés un temps, utilisés pour améliorer les modèles, ou stockés dans des centres de données situés hors de l'Union européenne.

Pour un usage grand public sans enjeu de confidentialité, cette architecture ne pose pas de problème particulier. Pour un environnement industriel, elle en pose un dès que les échanges contiennent des informations sur des procédés de fabrication, des références de pièces, des plannings de production, des noms de projets ou des données techniques qui n'ont pas vocation à sortir du périmètre de l'entreprise. Le sujet n'est pas la malveillance du fournisseur, mais la perte de maîtrise sur le chemin que suivent les données une fois envoyées.

Cette question se pose avec une acuité particulière pour les sites relevant de la défense ou de l'aéronautique, où certaines informations relèvent de régimes de protection spécifiques et où le simple fait de les faire transiter par une infrastructure tierce, même sans fuite avérée, peut constituer un manquement aux règles internes de l'entreprise ou à ses obligations contractuelles envers un donneur d'ordre.

En quoi l'hébergement en France ou sur site change-t-il la donne ?

Une première alternative consiste à héberger l'infrastructure du personnage IA dans un centre de données situé en France, exploité par un prestataire soumis au droit français. Les données ne quittent alors pas le territoire national, ce qui simplifie l'analyse juridique et rassure les équipes de sécurité, sans pour autant équivaloir automatiquement à une certification particulière : l'hébergement géographique est une condition nécessaire dans beaucoup de cahiers des charges, rarement suffisante à elle seule.

Une deuxième option, plus stricte, consiste à héberger l'infrastructure sur site, dans les locaux de l'entreprise, sur du matériel qu'elle possède ou contrôle directement. Cette configuration convient aux environnements où aucune donnée ne doit sortir du réseau interne, y compris vers un prestataire français de confiance. Elle demande en contrepartie des ressources de calcul dédiées et une équipe capable de maintenir l'infrastructure dans la durée, ce qui représente un coût et un engagement organisationnel réels.

Le choix entre ces options dépend moins d'une préférence générale que de la classification des données réellement manipulées par le personnage : un assistant de documentation technique interne n'a pas les mêmes exigences qu'un agent qui interagit avec des informations relevant du secret des affaires ou d'un marché de défense.

Les modèles ouverts exécutables localement sont-ils une solution viable ?

Depuis plusieurs années, des modèles de langage dits ouverts sont publiés avec des poids téléchargeables, ce qui permet de les exécuter sur une infrastructure entièrement maîtrisée par l'entreprise, sans appel réseau vers un service externe. Cette approche supprime par construction le risque de transit des données vers un tiers, puisque le modèle tourne sur du matériel interne et que rien ne sort du réseau si la configuration l'impose.

Cette solution a un coût technique. Les modèles ouverts les plus performants demandent une puissance de calcul significative, en particulier des cartes graphiques dédiées, et leur qualité de génération reste en général en retrait par rapport aux modèles propriétaires les plus avancés, même si l'écart se réduit régulièrement. Le choix d'un modèle ouvert implique donc souvent un compromis assumé entre souveraineté et performance brute, à évaluer selon les usages réels du personnage plutôt que sur des benchmarks génériques.

Un point mérite d'être clarifié sans ambiguïté : l'exécution locale d'un modèle ouvert garantit l'absence de transit externe des données, mais elle ne garantit rien d'autre par elle-même. La sécurité globale du dispositif dépend toujours de la configuration du réseau, des accès autorisés et des pratiques internes, exactement comme pour n'importe quel autre système d'information de l'entreprise.

Comment cloisonner un personnage IA dans un réseau industriel ?

Le cloisonnement consiste à limiter strictement les échanges réseau du personnage IA à ce qui est strictement nécessaire à son fonctionnement, et à l'isoler des systèmes critiques de production. Concrètement, cela signifie placer l'infrastructure du personnage sur un segment réseau dédié, séparé des automates industriels et des systèmes de conception, avec des règles de pare-feu qui interdisent tout flux non explicitement autorisé.

Ce cloisonnement s'applique aussi à l'intérieur même du dispositif conversationnel : un personnage IA déployé sur un site sensible ne devrait avoir accès qu'au périmètre de données strictement requis pour son usage, sans connexion large à l'ensemble du système d'information. Un agent d'accueil n'a par exemple aucune raison de pouvoir interroger une base de données de conception, même si l'intégration technique la rendrait accessible sans effort supplémentaire.

Cette discipline de cloisonnement demande une collaboration étroite entre l'équipe qui conçoit le personnage et les équipes de sécurité des systèmes d'information du site, dès la phase de conception plutôt qu'en correction après coup. Un cloisonnement pensé après le déploiement coûte systématiquement plus cher et laisse une fenêtre d'exposition pendant la transition.

Pourquoi la traçabilité et la journalisation sont-elles indispensables ?

Un environnement industriel ou de défense exige généralement de pouvoir répondre a posteriori à une question simple : qui a échangé quoi, avec quel système, à quel moment. Pour un personnage IA, cela suppose une journalisation complète des échanges, incluant l'identité de l'utilisateur, l'horodatage, le contenu de la conversation et, le cas échéant, les documents ou données consultés pour formuler la réponse.

Cette journalisation sert plusieurs objectifs distincts. Elle permet un audit de sécurité en cas d'incident suspecté. Elle permet aussi de détecter des usages anormaux, comme une tentative répétée d'obtenir une information hors du périmètre autorisé. Elle constitue enfin une pièce utile en cas de contrôle interne ou de vérification par un donneur d'ordre, qui peut exiger de savoir comment les échanges impliquant ses propres données ont été traités.

La journalisation elle-même doit être stockée avec le même niveau de rigueur que les données qu'elle décrit : des journaux d'accès conservés sur une infrastructure tierce non maîtrisée annuleraient une partie de l'effort de cloisonnement réalisé par ailleurs.

Que dit le cadre réglementaire, sans promesse excessive ?

Plusieurs cadres réglementaires s'appliquent potentiellement à un déploiement d'IA conversationnelle en environnement industriel, et il convient de les mentionner avec prudence, car leur applicabilité précise dépend de chaque situation et ne peut être tranchée que par une analyse juridique dédiée à l'entreprise concernée. Le Règlement général sur la protection des données encadre le traitement de toute donnée à caractère personnel échangée avec le personnage, y compris pour un usage interne.

Le secret des affaires, tel que défini par le droit français, peut s'appliquer aux informations techniques ou commerciales échangées, ce qui renforce l'intérêt d'un contrôle strict sur leur circulation, sans que le simple fait d'héberger en France constitue à lui seul une protection juridique automatique. Pour les sites relevant de la défense, des régimes de diffusion restreinte peuvent s'appliquer à certaines catégories d'informations, avec des exigences propres qui dépassent le cadre d'un simple choix d'hébergement.

Il n'existe pas de certification unique qui garantirait, en soi, la conformité d'un dispositif d'IA conversationnelle à l'ensemble de ces exigences. La démarche responsable consiste à qualifier précisément les données manipulées, à faire valider l'architecture retenue par les équipes juridiques et de sécurité internes de l'entreprise, et à documenter les choix effectués, plutôt qu'à s'appuyer sur une promesse commerciale de conformité qui ne pourrait être vérifiée qu'au cas par cas.

Comment choisir une architecture adaptée à son niveau de sensibilité ?

Le choix entre API grand public, hébergement français, hébergement sur site et modèle ouvert local ne relève pas d'une hiérarchie absolue où l'option la plus stricte serait toujours préférable. Un site de production sans enjeu de confidentialité particulier peut légitimement s'appuyer sur une API grand public pour un usage d'accueil générique, tandis qu'un site travaillant sur des programmes sensibles n'aura pas d'autre option raisonnable que l'hébergement sur site avec un modèle exécuté localement.

La démarche pratique consiste à cartographier, avant tout choix technique, les catégories de données que le personnage sera amené à manipuler, à les classer selon leur sensibilité réelle, et à faire correspondre chaque niveau à une architecture proportionnée. Cette cartographie doit être menée avec les équipes métier, juridiques et de sécurité du site, et non décidée uniquement par l'équipe qui développe le personnage.