Votre fournisseur veut connecter l'usine à son IA : 5 réflexes avant d'ouvrir le moindre flux

Quand les demandes de remontée de données industrielles pour alimenter des modèles IA se multiplient, le RSSI doit reprendre la main.

Le scénario qui se répète

Depuis quelques mois, c’est devenu systématique. À chaque comité de pilotage avec un fournisseur d’équipements industriels, le même sujet revient sur la table : « On aimerait récupérer les données de vos machines pour alimenter nos modèles d’IA. » L’argument est toujours le même : maintenance prédictive, optimisation des performances, réduction des arrêts non planifiés. Sur le papier, c’est séduisant. En pratique, c’est le début d’un casse-tête cybersécurité.

D’expérience, le scénario est presque toujours identique. Le fournisseur propose d’installer un boîtier ou un agent logiciel sur le réseau de production. Ce boîtier remonte des données vers une plateforme cloud, souvent hébergée on ne sait pas trop où, pour alimenter un algorithme de machine learning. Le tout est présenté comme anodin et transparent. Sauf que quand on gratte un peu, on découvre que pour faire fonctionner le système, il faut ouvrir des flux réseau depuis l’extérieur vers l’intérieur du réseau industriel. Et ça, d’un point de vue cybersécurité, c’est une aberration.

Le vrai problème : des flux descendants déguisés en remontée de données

La promesse initiale, c’est de la remontée de données. Du flux sortant. Les machines envoient leurs données de fonctionnement vers le cloud du fournisseur. Jusque-là, on peut encadrer. Mais dans la réalité, les architectures proposées par les fournisseurs nécessitent presque systématiquement des flux descendants : mises à jour des modèles IA, envoi de commandes de reconfiguration, accès distant pour la maintenance de la solution. On se retrouve avec un flux bidirectionnel, parfois même un accès VPN permanent du fournisseur vers le réseau OT.

C’est exactement le type de situation que la CISA et ses partenaires internationaux ont identifié dans leur guide publié en 2025 sur l’intégration sécurisée de l’IA dans les environnements OT. Le document, cosigné par l’ANSSI, le BSI allemand et le NCSC britannique, insiste sur un point fondamental : les opérateurs d’infrastructures critiques doivent exiger transparence et contrôle de la part de leurs fournisseurs sur la façon dont l’IA est intégrée dans leurs produits.

Le contexte ne fait que renforcer cette urgence. En 2025, les environnements industriels européens ont connu une hausse de 43 % des événements de sécurité. Les attaques récentes ont mis en lumière les risques liés à l’interconnexion croissante entre IT et OT, et surtout la dépendance aux prestataires externes dont les accès ne sont pas toujours suffisamment sécurisés. La directive NIS2 place désormais explicitement les fournisseurs dans le périmètre de responsabilité des entités essentielles.

5 réflexes du RSSI face à une demande de connexion IA fournisseur

Le sujet n’est pas d’interdire l’IA en usine. L’intelligence artificielle apporte une vraie valeur ajoutée dans la maintenance prédictive, l’optimisation énergétique ou le contrôle qualité. Le sujet, c’est d’encadrer la façon dont on connecte ces solutions, et de ne pas accepter n’importe quelle architecture sous prétexte que le fournisseur assure que c’est sécurisé. Voici les cinq réflexes que nous avons mis en place.

1. Rassurer et valider la faisabilité en amont

Premier réflexe, et c’est essentiel pour ne pas être perçu comme le service qui bloque tout : rassurer les équipes métier et le fournisseur sur le fait que c’est faisable. Oui, on peut remonter des données industrielles vers une plateforme IA. Oui, la cybersécurité n’est pas là pour empêcher l’innovation. Mais on pose un cadre. On explique qu’il y a des conditions techniques et contractuelles à respecter, que c’est normal, et que ça fait partie de l’intégration. D’expérience, cette posture d’accompagnement change complètement la dynamique. Le RSSI qui commence par « c’est possible, voici comment on s’y prend » obtient une bien meilleure collaboration que celui qui commence par « il faut qu’on vérifie si on a le droit ».

2. Vérifier que le flux est bien sortant, et uniquement sortant

C’est le point technique non négociable. Le flux de données doit être sortant : de l’usine vers le cloud du fournisseur. Pas l’inverse. Concrètement, on demande au fournisseur son architecture réseau détaillée et on vérifie qu’aucun flux descendant n’est nécessaire pour le fonctionnement nominal de la solution. Si le fournisseur a besoin d’un accès entrant pour mettre à jour ses modèles IA ou pour de la maintenance, on exige que ce soit via un mécanisme de pull initié depuis l’intérieur du réseau, jamais un push depuis l’extérieur. Le boîtier ou l’agent va chercher ses mises à jour sur un serveur intermédiaire en DMZ, pas l’inverse. Si le fournisseur ne peut pas fonctionner sans flux descendant direct, c’est un signal d’alerte majeur sur la maturité de son architecture.

3. Vérifier les contraintes légales et réglementaires

Avant toute remontée de données, il faut clarifier le cadre juridique. Quelles données exactement sont remontées ? Des données de fonctionnement machine, ou aussi des données qui pourraient être qualifiées de données personnelles (identifiants opérateurs, horaires de production) ? Où sont stockées ces données ? Dans quel pays ? Sous quelle juridiction ? Le RGPD s’applique-t-il ? Le DPO doit être impliqué dès cette étape. Pour les secteurs réglementés, vérifier la conformité avec NIS2, les exigences sectorielles et les éventuelles restrictions à l’export de données industrielles sensibles. Certaines données de production peuvent avoir une valeur stratégique et leur transfert vers un cloud étranger peut poser des questions de souveraineté industrielle.

4. Évaluer l’acceptabilité en termes de confidentialité

Au-delà du cadre légal, il y a la question de confidentialité métier. Les données de production remontées au fournisseur peuvent révéler des informations stratégiques : cadences de production, taux de rendement, formulations, paramètres de recettes. Si votre fournisseur d’équipements travaille aussi avec votre concurrent, est-ce que les données que vous lui transmettez ne vont pas, même agrégées et anonymisées, alimenter un modèle dont votre concurrent bénéficiera ? Ce n’est pas de la paranoïa, c’est de l’intelligence économique basique. On vérifie avec la direction industrielle et la direction générale que le périmètre de données remontées est acceptable du point de vue de la confidentialité business.

5. Profiter de l’occasion pour mettre à jour le contrat fournisseur

Dernière étape, et probablement la plus structurante sur le long terme. Chaque demande de connexion IA est une opportunité pour remettre à plat les clauses contractuelles relatives aux échanges de données. On formalise dans le contrat : le périmètre exact des données collectées, la finalité du traitement, la durée de conservation, les conditions de suppression, les engagements de localisation, les obligations de notification en cas d’incident, et l’interdiction explicite de réutiliser les données à d’autres fins que celles prévues. La CISA recommande spécifiquement de négocier des accords contractuels détaillant les fonctionnalités IA, de demander un SBOM pour les modèles IA, et d’imposer des politiques explicites d’utilisation des données. C’est l’occasion de professionnaliser la relation et de poser des bases saines pour les années à venir.

Ce qu’il faut retenir

L’IA en usine va devenir la norme, pas l’exception. Les fournisseurs d’équipements industriels intègrent tous des briques d’intelligence artificielle dans leurs offres. Le RSSI qui refuse systématiquement sera contourné. Celui qui accompagne en posant un cadre clair sera écouté et respecté.

Le point de vigilance essentiel reste la direction des flux. Accepter un flux sortant encadré, c’est du pragmatisme. Accepter un flux descendant vers le réseau OT pour faire plaisir à un fournisseur, c’est ouvrir une brèche. Et dans un contexte où les attaques sur les environnements industriels explosent, cette brèche peut coûter très cher.

Vous voyez un post LinkedIn sur le sujet , n’hésitez pas et partagez cet article en commentaire !