Usage et sécurité de l'IA

L'IA fantôme (shadow AI) est l'usage d'outils d'IA au travail sans que les responsables de l'informatique, de la sécurité ou de la protection des données le sachent ou l'aient approuvé. Elle englobe le personnel qui utilise des comptes de chatbot personnels pour des tâches professionnelles, des extensions de navigateur dotées d'IA, des fonctions d'IA activées dans des logiciels existants, des développeurs qui exécutent des modèles locaux ou des assistants de code, et des agents d'IA connectés aux systèmes de l'entreprise. Elle part en général d'une bonne intention : travailler plus vite. Les risques sont concrets. Des données de l'entreprise ou des clients partent chez des fournisseurs avec lesquels vous n'avez aucun contrat, à des conditions qui peuvent les autoriser à les conserver ou à entraîner des modèles dessus. Des données personnelles peuvent être traitées sans base légale. Des résultats entrent dans des documents et du code sans relecture. Et personne ne peut répondre à un client ou à un auditeur qui demande quels services d'IA ont touché ses données. La réponse n'est pas l'interdiction mais la visibilité, une alternative approuvée et une politique claire. Dès l'offre Pro, NetSenX montre quels hôtes se connectent à quels services d'IA et combien de données y partent, pas ce qui a été tapé.

Oui, à partir de l'offre Pro. NetSenX signale le trafic vers des services d'IA externes et vers des modèles de langage exécutés localement, afin que l'usage d'IA non approuvé devienne visible avant de devenir un problème de protection des données.

Regardez les connexions sortantes vers des services d'IA : la destination et le nom de serveur dans la négociation TLS identifient le service sans rien déchiffrer. NetSenX signale ce trafic, ainsi que celui vers des modèles de langage exécutés en local, à partir de l'offre Pro.

En général plus que ce que quiconque a listé, et c'est justement cet écart qu'il faut connaître. Une liste réaliste comporte quatre couches : les services payés sur des comptes d'entreprise ; les fonctions d'IA activées dans des logiciels déjà utilisés, comme les suites bureautiques, le CRM, le support ou les outils de création ; les services que le personnel utilise avec des comptes personnels dans le navigateur ou en application de bureau ; et les modèles exécutés localement sur des portables, des serveurs de compilation ou des stations dotées de GPU. Partez de ce que vous savez, grâce aux contrats, relevés de carte et consoles d'administration, puis ajoutez ce que montre le réseau. Regroupez les résultats par fonction, car la finance, les ventes et le développement utilisent souvent des outils différents pour des données différentes, et donnez à chaque service un statut : approuvé, toléré pour des données non sensibles ou à remplacer. Cette liste fonde votre politique d'IA, la formation à la maîtrise de l'IA exigée par l'AI Act et vos réponses aux clients. Dès l'offre Pro, NetSenX montre quels hôtes joignent quels services d'IA externes et quels environnements de modèles locaux, quand et avec quel volume ; il ne montre pas ce qui a été tapé.

On peut la mesurer au niveau du réseau, par service et par hôte, et ce chiffre est plus utile qu'il n'y paraît. Le volume ne dit pas ce qu'étaient les données, mais il distingue un usage léger, comme des questions et réponses courtes, d'un usage intensif, comme l'envoi de documents entiers, de tableurs, de dépôts de code ou d'enregistrements audio. Un saut soudain sur un hôte, ou un flux régulier depuis un serveur qui ne devrait jamais parler à des services d'IA, justifie une question. Suivez-le chaque mois, par fonction, à côté de votre liste de services approuvés : la hausse d'usage d'un outil approuvé est une bonne nouvelle ; celle d'un outil non approuvé révèle une lacune de la politique. La console d'administration de votre fournisseur d'IA peut ajouter le détail par utilisateur pour les comptes professionnels. Dès l'offre Pro, NetSenX montre quels hôtes joignent quels services d'IA, y compris des environnements de modèles locaux, et combien de données partent vers chacun dans le temps. Il ne lit jamais le contenu et ne peut donc pas dire si les données étaient confidentielles ; ce jugement revient à ceux qui en sont responsables.

En partie. Les journaux DNS montrent quels hôtes résolvent les domaines de services d'IA connus, ce qui est un bon début et ne coûte rien si votre résolveur journalise déjà les requêtes : exportez une semaine de requêtes et rapprochez-les d'une liste de domaines d'IA. Ils manquent le DNS chiffré qui contourne votre résolveur, les services joints par d'autres domaines ou des réseaux de diffusion de contenu, les fonctions d'IA intégrées à des outils que vous utilisez déjà, et la quantité de données réellement échangée. Ils montrent aussi l'hôte, pas la personne, et une requête isolée peut venir d'un navigateur qui précharge une page. Voyez le DNS comme une première vue peu coûteuse et confirmez avec des données de connexion avant d'agir. NetSenX combine, dès l'offre Pro, les destinations avec le volume et l'horaire des connexions : vous voyez quels hôtes utilisent quels services d'IA, y compris des environnements de modèles locaux, et avec quelle intensité ; il ne voit pas le contenu des prompts. Pour le contenu, associez-le aux journaux d'administration de votre fournisseur d'IA.

Oui pour les connexions, non pour le contenu. Une application de chatbot de bureau, un assistant d'IA dans un éditeur de code et un outil en ligne de commande qui appelle une API d'IA doivent tous joindre le fournisseur par le réseau : destination, horaire et volume sont donc visibles comme pour un navigateur. C'est important, car ces outils échappent souvent aux contrôles fondés sur le navigateur : une politique d'extensions ou un proxy web ne les voit pas, et les assistants d'IA des développeurs peuvent envoyer de larges pans d'un code source comme contexte. Limites : quand l'outil parle à un point d'accès cloud générique ou à un proxy d'entreprise, le fournisseur d'IA peut être masqué derrière ; l'Encrypted Client Hello peut cacher le nom du serveur ; et les portables utilisés hors du bureau ne sont visibles que si l'agent y tourne. NetSenX montre dès l'offre Pro quels hôtes se connectent à quels services d'IA externes et à quels environnements de modèles de langage exécutés localement, et combien de données partent vers chacun, quelle que soit l'application à l'origine de la connexion ; il ne voit pas quel fichier ou quel prompt a été envoyé.

Non. Le contenu de la session est chiffré, et NetSenX ne le déchiffre jamais. Il montre qu'un hôte a utilisé un service d'IA, quand, et quel volume il a envoyé ; pour le contenu, il faut les journaux de la version entreprise du service ou un outil de DLP.

Parce que le contenu circule dans des connexions chiffrées vers des services que l'entreprise ne contrôle pas. Quand quelqu'un colle un texte dans un chatbot depuis son navigateur, le pare-feu voit une connexion HTTPS vers le fournisseur et, au mieux, le nom du service ; le prompt lui-même est chiffré de bout en bout entre le navigateur et le fournisseur. Les comptes personnels conservent l'historique chez le fournisseur, hors de portée de l'entreprise. Les fonctions d'IA des applications approuvées ressemblent au trafic ordinaire de ces applications, et les téléphones en données mobiles ne passent jamais par le réseau de l'entreprise. Obtenir une visibilité sur le contenu exige un contrôle à l'une des extrémités : un compte professionnel dont la console d'administration et les journaux d'audit montrent l'usage, une prévention des fuites de données dans le navigateur ou sur le poste, ou un proxy d'interception, chacun avec ses propres questions de vie privée. Ce que le réseau peut offrir, c'est la meilleure alternative : quels hôtes utilisent quels services d'IA, quand et combien. C'est exactement ce que montre NetSenX dès l'offre Pro.

Non. Elle fait partie de l'offre Pro et des offres supérieures. L'offre Free couvre la détection comportementale, par exemple du beaconing, des scans et des mouvements latéraux, sans limite de durée.

Cela dépend de l'endroit où se trouve l'outil, et la réponse mérite d'être demandée par écrit à chaque fournisseur, car la même étiquette recouvre des choses très différentes. Un outil sur le poste voit quelles applications d'IA et extensions de navigateur sont installées, et parfois quels sites sont visités ; un outil fondé sur le DNS voit les requêtes vers des domaines d'IA via le résolveur qu'il contrôle ; une extension de navigateur voit les pages et, avec les bonnes permissions, ce qui y est saisi ; un capteur réseau voit les connexions vers des services d'IA avec leur volume et leur horaire ; et les consoles d'administration des fournisseurs d'IA montrent l'usage des comptes professionnels. Aucun ne voit tout à lui seul. Demandez précisément : de quelle source vient la visibilité, si elle porte sur le contenu ou seulement sur les destinations, si elle couvre les applications de bureau et les modèles locaux, comment elle gère le DNS chiffré, ce qu'elle fait sur les appareils non gérés et quelles données personnelles sur les salariés elle collecte. NetSenX relève de la catégorie réseau : dès l'offre Pro, il montre quels hôtes joignent quels services d'IA externes et environnements de modèles locaux, et combien de données circulent, jamais ce qui a été tapé.

Cela dépend moins du service que du compte et des données. La connexion est chiffrée et les grands fournisseurs mènent des programmes de sécurité solides : les principaux risques sont ailleurs. Un compte personnel relève des conditions grand public : selon le fournisseur et les réglages, les conversations peuvent être conservées et servir à améliorer les modèles, et l'entreprise n'a ni vue d'administration, ni accord de traitement des données, ni moyen d'effacer ce qui a été partagé. Un compte professionnel ou entreprise change en général la donne, avec des limites contractuelles sur l'entraînement, des réglages de conservation, l'authentification unique, des contrôles d'administration et des journaux d'audit. Les autres risques sont humains : données confidentielles ou personnelles collées sans réfléchir, réponses fausses mais assurées, code ou texte générés utilisés sans relecture. Règles pratiques : outil approuvé sur un compte d'entreprise, courte liste de données qui n'y entrent jamais, authentification multifacteur (MFA) sur le compte et relecture des résultats avant qu'ils n'atteignent les clients. NetSenX montre dès l'offre Pro quels services d'IA sont réellement utilisés et combien de données y partent.

Traitez un service d'IA comme tout autre fournisseur qui traite vos données, et configurez-le délibérément. Choisissez un ou deux services approuvés et utilisez des comptes professionnels avec authentification unique et authentification multifacteur, pour que les partants perdent l'accès et que les administrateurs voient l'usage. Vérifiez le contrat : vos données servent-elles à l'entraînement, combien de temps sont-elles conservées, où sont-elles traitées, et un accord de traitement des données au sens du RGPD est-il en place ? Rédigez une politique d'une page avec des exemples de ce qui peut y entrer ou non, et à qui s'adresser. Activez les contrôles d'administration du fournisseur, comme les limites de conservation et les restrictions sur les plugins ou connecteurs. Décidez comment les résultats sont relus avant d'atteindre les clients ou le code de production. Formez le personnel à la politique et à l'obligation de maîtrise de l'IA prévue par l'AI Act. Puis vérifiez la réalité : dès l'offre Pro, NetSenX montre quels services d'IA les hôtes utilisent réellement, y compris ceux non approuvés et les modèles locaux, et combien de données partent vers chacun, sans lire le contenu.

Commencez par une politique que les gens peuvent suivre : quels outils d'IA sont approuvés, pour quelles données et via quel compte d'entreprise. Rendez ensuite l'outil approuvé facile à utiliser, car on contourne les règles qui bloquent le travail, et un compte professionnel chez un fournisseur d'IA offre en général des engagements contractuels sur l'usage des données, des réglages d'administration et des journaux qu'un compte personnel n'a pas. Expliquez la règle par des exemples concrets : listes de clients, contrats, code source, données salariales et tout ce qui relève d'un accord de confidentialité restent hors des outils non approuvés. Les contrôles techniques suivent : prévention des fuites de données sur les postes ou dans le navigateur, proxy web et réglages d'administration du fournisseur d'IA lui-même. Vérifiez le résultat chaque mois, pas une seule fois. NetSenX apporte de la visibilité, pas du blocage : dès l'offre Pro, il montre quels hôtes parlent à quels services d'IA et combien de données y partent, pour que vous voyiez si la politique fonctionne. Il ne voit pas ce qui a été tapé ou envoyé.

Le blocage seul fonctionne rarement : les gens passent sur leur téléphone, leur réseau domestique ou d'autres outils d'IA, et vous perdez la vue sur l'usage, soit l'inverse de ce que vous cherchez. Les listes de blocage prennent aussi du retard, car de nouveaux services d'IA apparaissent chaque mois et beaucoup sont intégrés à des applications que vous autorisez déjà. Une voie plus claire a trois volets : une politique sur les outils d'IA approuvés et les données qui peuvent y entrer ; un outil approuvé avec un compte professionnel là où la demande est réelle, pour offrir une bonne alternative ; et une visibilité sur l'usage effectif, revue régulièrement. Le blocage garde sa place pour certains services à haut risque, pour les appareils non gérés du réseau invité ou pendant un incident. NetSenX montre dès l'offre Pro à quels services d'IA les hôtes du réseau se connectent, y compris les modèles exécutés localement, et combien de données partent vers chacun ; il voit la destination et le volume, pas ce qui a été tapé, et ne bloque rien lui-même.

Commencez par savoir ce qui est utilisé et pourquoi, avant d'écrire des règles. Dans la plupart des entreprises, la première vague d'usage de l'IA vient de personnes qui résolvent de vrais problèmes : rédiger des courriels, résumer des documents, écrire du code ou traduire. Une interdiction rend cet usage invisible ; un outil approuvé avec des consignes claires le garde visible. Expliquez ensuite les risques avec les mots du métier : un contrat client collé dans un chatbot personnel peut violer la clause de confidentialité ; un résumé d'IA peut omettre la seule phrase qui compte ; du code généré peut contenir des vulnérabilités ou des problèmes de licence. Donnez une courte liste de données qui n'entrent jamais dans des outils non approuvés, montrez comment utiliser l'outil approuvé et désignez une personne à qui poser ses questions. Des formations courtes et répétées valent mieux qu'une longue séance, et depuis février 2025 l'AI Act impose aux organisations qui utilisent l'IA de prendre des mesures pour favoriser la maîtrise de l'IA de leur personnel. Mesurez les progrès avec des faits : dès l'offre Pro, NetSenX montre quels services d'IA sont réellement utilisés et combien de données y partent.

Comparez ce que la politique autorise avec ce que l'entreprise utilise réellement, à partir de trois sources. D'abord, les consoles d'administration des services d'IA approuvés : qui a un compte, quelle est son activité, quelles fonctions et quels connecteurs sont activés. Ensuite, les données d'identité et de dépenses : connexions avec des adresses e-mail de l'entreprise à des services que personne n'a approuvés, et abonnements d'IA payés par carte d'entreprise. Enfin, le réseau : quels appareils se connectent à quels services d'IA, y compris des environnements de modèles locaux, et combien de données partent vers chacun. Un bon rapport mensuel montre les services approuvés et leur usage, ceux non approuvés encore utilisés et les transferts inhabituellement importants, pour que la discussion porte sur des faits, pas des rumeurs. Restez au niveau des outils et des appareils plutôt que des personnes, sauf préoccupation précise, et associez les RH ou les représentants du personnel lorsque votre pays l'exige. Dès l'offre Pro, NetSenX fournit la vue réseau : hôtes, services d'IA et volumes dans le temps. Il ne lit pas ce qui a été tapé et ne bloque rien.

Seulement sur un compte professionnel approuvé, et seulement après avoir vérifié ce que contient le tableur. Les exports financiers contiennent souvent plus que ce dont l'analyse a besoin : noms des clients et conditions de paiement, salaires, marges, coordonnées bancaires et résultats non publiés. Sur un compte personnel, ces données se retrouvent chez un fournisseur avec lequel vous n'avez aucun contrat, à des conditions qui peuvent permettre leur conservation ou l'entraînement de modèles. Sur un compte professionnel avec accord de traitement des données, réglages de conservation et sans entraînement sur vos données, le risque est comparable à celui des autres services cloud que vous utilisez déjà. Règles pratiques pour la finance : supprimez les colonnes dont la question n'a pas besoin, agrégez ou pseudonymisez les données personnelles, n'envoyez jamais les résultats non publiés d'une société cotée ni des fichiers couverts par un accord de confidentialité, et vérifiez les chiffres de l'IA par rapport à la source avant qu'ils n'entrent dans un rapport, car les modèles peuvent mal calculer ou mal recopier. NetSenX montre dès l'offre Pro quels hôtes de la finance joignent quels services d'IA et combien de données y partent ; il ne voit pas le fichier.

Pas par le seul réseau, et mieux vaut le dire franchement avant de choisir un outil. Le contenu envoyé à un service d'IA est chiffré : seul un contrôle à l'une des extrémités peut le voir, qu'il s'agisse des journaux d'administration et d'audit d'un compte d'IA professionnel, d'une prévention des fuites de données dans le navigateur ou sur le poste qui reconnaît des motifs de données clients, ou d'un proxy d'interception. Chacun suppose une politique claire, une information du personnel et, dans de nombreux pays, l'association des représentants du personnel. Ce que le réseau montre de façon fiable, c'est le contexte : quels appareils utilisent quels services d'IA, à quelle fréquence et avec quel volume. Un portable commercial qui envoie chaque jour plusieurs mégaoctets à un chatbot non approuvé appelle une discussion sur les outils et les données, pas la preuve d'une violation. Souvent, la meilleure réponse est une alternative autorisée qui fait le même travail sur un compte professionnel. Dès l'offre Pro, NetSenX montre hôtes, services d'IA et volumes ; il ne voit jamais le texte collé.

Cela peut l'être, selon les données, le compte et les conditions. Au sens du RGPD, règlement (UE) 2016/679, envoyer des données personnelles à un fournisseur d'IA est un traitement qui exige une base légale, la transparence envers les personnes concernées et, lorsque le fournisseur agit pour votre compte, un accord de sous-traitance. Les transferts hors de l'UE exigent leurs propres garanties. Sur un compte professionnel doté d'un tel accord et de réglages excluant l'entraînement sur vos données, un usage pour une finalité définie peut être licite. Coller des courriels de clients dans un compte personnel régi par des conditions grand public est plus difficile à justifier et peut constituer une divulgation non autorisée, que le RGPD traite comme une violation de données à caractère personnel ; si elle est susceptible d'engendrer un risque pour les personnes, le responsable du traitement doit la notifier à l'autorité de contrôle dans les 72 heures, selon l'article 33. Associez votre délégué à la protection des données, consignez ce qui a été partagé et avec quel service, et traitez la cause avec un outil approuvé. NetSenX montre dès l'offre Pro quels hôtes ont envoyé des données à quels services d'IA, pas la nature des données.

Rarement en première intention, et jamais sur la seule base de données réseau. La plupart des usages non approuvés de l'IA viennent de personnes qui veulent faire leur travail plus vite, souvent parce qu'aucun outil approuvé n'existe ou que la politique n'a jamais été expliquée. Un licenciement pour un premier manquement de bonne foi peut être disproportionné au regard du droit du travail de nombreux pays de l'UE, et il apprend au reste du personnel à cacher son usage plutôt qu'à poser des questions. Une séquence plus saine : s'assurer que la politique était claire, communiquée et raisonnable ; proposer une alternative approuvée ; traiter un premier manquement par un entretien et un avertissement consigné ; réserver les mesures disciplinaires aux manquements délibérés ou répétés, ou aux préjudices graves comme la divulgation de données confidentielles d'un client. Décidez avec les RH et un conseil juridique, et associez les représentants du personnel lorsque votre pays l'exige. Un capteur réseau ne peut pas établir qui a fait quoi : NetSenX montre quel appareil s'est connecté à quel service d'IA et quel volume a circulé, un point de départ pour des questions, pas une preuve de l'intention d'une personne.

Surtout que des données de l'entreprise partent à des conditions que personne n'a acceptées, et que personne ne puisse en rendre compte ensuite. L'IA personnelle recouvre les abonnements privés à des chatbots, les applications d'IA sur téléphones personnels, les extensions de navigateur, les enregistreurs de réunion dotés d'IA et les modèles exécutés sur du matériel privé. Le risque pour les données : documents, informations clients ou enregistrements partent chez des fournisseurs aux conditions grand public, parfois hors de l'UE, sans accord de traitement, et restent dans des comptes personnels après le départ du salarié. Le risque de qualité : des livrables construits sur des résultats que personne n'a vérifiés. Le risque de conformité : vous ne pouvez pas dire à un client, un auditeur ou une personne concernée où sont allées ses données. Les enregistreurs de réunion méritent une attention particulière, car ils captent la voix et les propos d'autres personnes, souvent sans le consentement de tous. La réponse pratique : proposer un bon outil approuvé, dire clairement quels outils personnels peuvent servir à quoi et exiger que tout enregistrement de réunion soit annoncé. Dès l'offre Pro, NetSenX montre quels services d'IA joignent les appareils de l'entreprise ; les téléphones personnels en données mobiles restent hors de toute vue réseau.

Souvent davantage que les chatbots eux-mêmes, à cause des permissions qu'elles demandent. Pour résumer des pages, réécrire des courriels ou remplir des formulaires, une extension d'IA doit en général pouvoir lire et modifier tout ce qui s'affiche sur chaque site visité, y compris la messagerie web, le CRM, la banque en ligne et les applications internes. Elle envoie ensuite le contenu des pages à ses propres serveurs ou à un fournisseur d'IA. Certaines extensions sont bien gérées ; d'autres sont de petits projets qui changent de main, sont revendus ou reçoivent une mise à jour avec du pistage ou du code malveillant, que le navigateur installe silencieusement. Mesures pratiques : n'autorisez que les extensions d'une liste gérée via les politiques du navigateur, examinez les permissions et l'éditeur de chacune, préférez les fonctions d'IA de vos outils approuvés aux extensions et supprimez celles que personne ne peut justifier. Un capteur réseau voit les connexions d'une extension vers ses serveurs comme tout autre trafic, mais ne peut pas dire quelle extension les a ouvertes ; l'inventaire relève de la gestion des navigateurs ou des postes. Dès l'offre Pro, NetSenX montre quels hôtes joignent quels services d'IA et combien de données y partent.

Si votre organisation utilise des systèmes d'IA dans son activité, l'article 4 du règlement lui impose de prendre des mesures pour favoriser la maîtrise de l'IA de son personnel, et cette obligation s'applique depuis le 2 février 2025 ; depuis juillet 2026, le texte modifié précise qu'aucun niveau précis ne doit être garanti pour chaque personne. Savoir quels services d'IA sont réellement utilisés est une première étape concrète ; votre conseil juridique vous dira ce qui s'applique d'autre à vous.

En partie, oui. Le règlement (UE) 2024/1689 impose des obligations aux déployeurs, c'est-à-dire aux organisations qui utilisent des systèmes d'IA dans leur activité, et pas seulement aux fournisseurs qui les conçoivent. Depuis le 2 février 2025, l'article 4 impose aux fournisseurs et aux déployeurs de prendre des mesures concernant la maîtrise de l'IA du personnel qui utilise des systèmes d'IA ; dans sa version modifiée en juillet 2026 par le règlement (UE) 2026/1744, il s'agit de favoriser cette maîtrise, sans garantir un niveau précis pour chaque personne. Les interdictions de l'article 5 s'appliquent elles aussi depuis le 2 février 2025. D'autres obligations dépendent de la catégorie de risque du système et s'appliquent à des dates ultérieures : le déployeur d'un système à haut risque, par exemple pour le recrutement ou l'octroi de crédit, a des obligations de contrôle humain, de surveillance et de journalisation, et certains usages entraînent des obligations de transparence envers les personnes concernées. Utiliser un chatbot généraliste pour rédiger des textes se situe du côté léger. Un bon début consiste à recenser les systèmes d'IA réellement utilisés et leurs usages, puis à adapter la formation à cette liste. Vérifiez le détail avec un conseil juridique, car les lignes directrices continuent d'être publiées.

Il signifie que l'entreprise doit prendre des mesures qui favorisent la maîtrise de l'IA du personnel qui utilise des systèmes d'IA, et ce sont en général les RH qui l'organisent. L'article 4 du règlement (UE) 2024/1689 s'applique depuis le 2 février 2025 aux fournisseurs comme aux déployeurs, il concerne donc les entreprises ordinaires qui utilisent des outils d'IA ; dans sa version modifiée en juillet 2026 par le règlement (UE) 2026/1744, il précise que l'entreprise n'a pas à garantir un niveau précis de maîtrise de l'IA pour chaque personne. De bonnes mesures tiennent toujours compte des connaissances techniques, de l'expérience, de l'éducation et de la formation des personnes, ainsi que du contexte d'utilisation des systèmes d'IA. L'article 4 n'impose ni certificat, ni nombre d'heures fixe, ni cours unique. Étapes pratiques : recensez les systèmes d'IA réellement utilisés et leurs utilisateurs ; définissez ce que chaque groupe doit savoir, des risques de base et de la politique de l'entreprise pour tous à une formation approfondie pour ceux qui configurent l'IA ou s'appuient sur elle pour décider ; tenez un registre simple de qui a été formé à quoi et quand ; et recommencez quand les outils changent. NetSenX peut aider pour la première étape : dès l'offre Pro, il montre quels services d'IA les appareils de l'entreprise utilisent réellement.

Ceux que votre personnel utilise réellement, ce qui est rarement la liste de la politique. Commencez par un inventaire : services approuvés sur comptes d'entreprise, fonctions d'IA intégrées aux logiciels que vous payez déjà, services utilisés avec des comptes personnels et modèles locaux sur les machines des développeurs ou des ingénieurs. Adaptez ensuite la formation à l'usage. Tout le monde a besoin des bases : quels sont les outils approuvés, quelles données n'entrent dans aucun outil d'IA, pourquoi les réponses peuvent être fausses et comment signaler un problème. Ceux qui utilisent l'IA sur des données clients ou personnelles, en finance, RH ou commercial, ont besoin des règles de protection des données et de confidentialité qui les concernent. Les développeurs ont besoin d'un usage sûr des assistants de code et des agents, y compris de ce à quoi ces outils ont accès. Les managers qui s'appuient sur des résultats d'IA pour décider doivent en comprendre les limites. Former sur des outils que personne n'utilise fait perdre du temps ; oublier ceux du quotidien laisse le vrai risque intact. Dès l'offre Pro, NetSenX montre quels services d'IA externes et environnements de modèles locaux les appareils de l'entreprise joignent, pour que la liste de formation corresponde à la réalité.

En règle générale, non. L'article 5 de l'AI Act, règlement (UE) 2024/1689, interdit la mise sur le marché, la mise en service et l'utilisation de systèmes d'IA pour inférer les émotions d'une personne physique sur le lieu de travail et dans les établissements d'enseignement, sauf lorsque le système est destiné à des raisons médicales ou de sécurité. L'interdiction s'applique depuis le 2 février 2025. Elle vise les outils qui lisent émotions ou intentions à partir du visage, de la voix, de la frappe ou d'autres signaux biométriques, par exemple dans des logiciels de centre d'appels, des modules de visioconférence ou des outils de suivi de productivité, et les amendes pour pratiques interdites sont les plus élevées du texte. Le droit du travail et la protection des données ajoutent leurs propres limites à la surveillance du personnel. Avant d'acheter un outil qui prétend mesurer l'engagement, le stress ou le ressenti des salariés, demandez par écrit au fournisseur quelles données il utilise et comment il se situe au regard de l'article 5, et associez votre conseil juridique et votre délégué à la protection des données. NetSenX ne fait rien de tel : il surveille des appareils et des connexions réseau, jamais des personnes, et n'évalue aucun individu.

Par une réponse précise et vérifiable plutôt que par une assurance. Les clients et leurs acheteurs demandent de plus en plus quels services d'IA touchent leurs données, à quelles conditions et avec quels contrôles. Une bonne réponse cite les services d'IA approuvés et la façon dont ils sont contractés, par exemple des comptes professionnels sans entraînement sur vos entrées, avec un accord de traitement des données et des lieux de traitement indiqués ; précise quelles données du client peuvent y entrer ou non ; décrit les contrôles, comme la politique d'IA, la formation du personnel, les restrictions d'accès et la relecture des résultats ; et explique comment vous vérifiez que la pratique correspond à la politique. Si la réponse honnête est aujourd'hui que vous ne savez pas, dites ce que vous faites pour le savoir et dans quel délai, plutôt que de promettre ce que vous ne pouvez pas montrer. Gardez la réponse cohérente avec vos contrats et votre registre des traitements. Dès l'offre Pro, NetSenX montre quels services d'IA les appareils de votre entreprise joignent réellement et combien de données partent vers chacun : votre réponse au client s'appuie ainsi sur votre propre trafic plutôt que sur des suppositions ; il ne montre pas quelles données de quel client étaient en jeu.

Souvent oui, au moins sous forme d'engagement sur lequel le client peut compter, mais gardez le contrat plus court que la politique. Les clients ajoutent de plus en plus de clauses sur l'IA : pas d'utilisation de leurs données pour entraîner des modèles, pas de traitement par des services d'IA hors des sous-traitants ou régions convenus, information lorsque des livrables sont réalisés avec l'aide de l'IA, et notification si leurs données ont été exposées via un outil d'IA. Plutôt que d'annexer toute votre politique interne, qui change souvent, engagez-vous dans le contrat ou l'accord de traitement sur quelques principes stables, listez comme sous-traitants les services d'IA qui traitent des données du client le cas échéant, et renvoyez à la politique que vous tenez à jour. Assurez-vous de pouvoir tenir chaque promesse en pratique : une clause affirmant qu'aucune donnée client n'entre jamais dans un outil d'IA ne vaut rien si le personnel utilise des comptes de chatbot personnels sans que vous le voyiez. Convenez de ce qui compte comme travail assisté par l'IA, car la plupart des logiciels de bureau ont désormais des fonctions d'IA. Faites relire la rédaction par un conseil juridique. Dès l'offre Pro, NetSenX montre quels services d'IA vos appareils joignent réellement, une vérification utile avant de signer une telle clause.

Cherchez les services qu'exposent les environnements de modèles locaux et le trafic qui les entoure. Les outils qui exécutent des modèles de langage en local ouvrent en général une API HTTP sur un port par défaut connu, proposent une interface web et téléchargent de gros fichiers de modèles depuis des plateformes publiques lors de leur installation. Trois vérifications aident donc : un balayage autorisé des plages internes à la recherche des ports par défaut des environnements courants et d'interfaces web inattendues ; un examen des machines qui ont téléchargé des fichiers de plusieurs gigaoctets depuis des dépôts de modèles ; et la liste des hôtes dotés de GPU puissants, que l'informatique connaît souvent déjà. Demandez ensuite aux responsables à quoi sert chaque serveur, qui peut l'atteindre et quelles données y entrent. Beaucoup sont des expériences inoffensives ; certains restent ouverts à tout le réseau sans authentification. NetSenX montre dès l'offre Pro le trafic vers les environnements de modèles de langage exécutés localement : quel hôte en exécute ou en appelle un et combien de données circulent, aux côtés des services d'IA externes. Il ne voit ni les prompts ni les réponses du modèle.

Il peut l'être, surtout à cause d'erreurs de configuration ordinaires plutôt que de quoi que ce soit d'exotique. Garder les données sur son propre matériel évite de les envoyer à un fournisseur extérieur, ce qui est un vrai avantage. Les risques sont ceux de tout nouveau serveur non prévu : l'API ou l'interface web écoute souvent sur toutes les interfaces sans authentification, si bien que n'importe qui sur le réseau peut utiliser le modèle, lire l'historique des conversations ou déposer des fichiers ; le serveur fait tourner des logiciels non corrigés qui évoluent vite ; des fichiers de modèles téléchargés sur des plateformes publiques peuvent contenir du code malveillant s'ils utilisent des formats non sûrs ; et les documents fournis pour la recherche peuvent être lisibles par tous ceux qui atteignent le serveur. Traitez-le comme tout service interne : un responsable désigné, une authentification, une écoute limitée à localhost ou à un segment restreint, des mises à jour, des formats de modèles sûrs issus de sources fiables, et une décision sur les données autorisées. Dès l'offre Pro, NetSenX montre quels hôtes exécutent ou appellent des environnements de modèles de langage locaux et combien de données circulent, et ses détections de base signalent dans chaque offre les balayages ou mouvements latéraux depuis cet hôte.

C'est le risque qu'un modèle, un jeu de données ou une bibliothèque d'IA que vous téléchargez ou achetez soit compromis, mal décrit ou tout simplement pas ce que vous croyez. Les plateformes publiques hébergent des centaines de milliers de modèles déposés par n'importe qui. Certains formats de fichiers de modèles peuvent exécuter du code au chargement : un modèle malveillant peut donc compromettre la machine qui l'ouvre ; des formats plus sûrs existent et doivent être préférés. Un modèle peut être affiné pour se comporter normalement sauf face à un déclencheur caché, ou entraîné sur des données empoisonnées. Des noms peuvent être copiés pour imiter le modèle d'un éditeur connu. Et les bibliothèques et plugins autour des modèles, comme les environnements d'exécution, les connecteurs et les frameworks d'agents, évoluent vite et portent des vulnérabilités logicielles ordinaires. Mesures pratiques : ne prenez des modèles que d'éditeurs vérifiables, contrôlez signatures ou empreintes quand elles sont publiées, utilisez des formats sûrs, exécutez d'abord les nouveaux modèles dans un environnement isolé, tenez un inventaire des modèles et versions utilisés et corrigez le logiciel qui les entoure comme n'importe quel autre. Un capteur réseau voit les gros téléchargements de modèles et les hôtes qui exécutent des environnements de modèles ; il ne peut pas inspecter les poids d'un modèle.

Il peut l'être, de la même manière que du code copié sur internet, mais plus vite et en plus grande quantité. Les assistants de code produisent du code plausible qui fonctionne en général, mais qui peut contenir des motifs de vulnérabilité connus comme des failles d'injection, une cryptographie faible ou des contrôles d'entrée manquants ; appeler des paquets qui n'existent pas, que des attaquants enregistrent ensuite sous ce nom avec un contenu malveillant ; reproduire du code sous une licence que votre produit ne peut pas accepter ; et embarquer des secrets issus d'exemples. Les outils envoient aussi le code source au fournisseur comme contexte : le choix du service et du compte compte donc pour la confidentialité. Traitez la production de l'IA comme la pull request d'un collègue débutant : même revue de code, tests de sécurité automatisés, analyse des dépendances et des licences, détection des secrets dans la chaîne de déploiement, le développeur restant responsable. Décidez quels dépôts peuvent être partagés avec quel assistant. Dès l'offre Pro, NetSenX montre quels postes de développeurs et serveurs de compilation envoient des données à quels services d'IA, et combien ; il ne peut pas juger la qualité du code.

L'injection de prompt est une attaque dans laquelle un texte lu par un système d'IA est rédigé pour lui faire ignorer ses instructions et faire autre chose. L'injection directe vient de l'utilisateur qui la saisit. L'injection indirecte est la plus sérieuse pour les entreprises : l'instruction se cache dans un contenu que l'IA traite pour quelqu'un, comme une page web, un courriel, un document partagé ou un ticket de support, et le modèle la suit comme si elle venait de son opérateur. Si l'IA ne peut que répondre dans une fenêtre de discussion, les dégâts se limitent à une réponse fausse ou gênante. Si elle peut lire une boîte aux lettres, appeler des outils, interroger une base de données ou naviguer, une instruction injectée peut lui faire divulguer des données ou exécuter des actions. Il n'existe pas de parade complète aujourd'hui, car les modèles ne séparent pas de façon fiable instructions et données. Ce qui aide : donner aux outils d'IA le moins de permissions possible, exiger une validation humaine pour les actions qui ont des conséquences, tenir les systèmes sensibles hors de portée des agents qui lisent des contenus non fiables, et journaliser ce que l'IA a fait. L'OWASP classe l'injection de prompt en tête des risques des applications fondées sur des grands modèles de langage (LLM).

C'est une liste des principaux risques de sécurité des applications construites sur de grands modèles de langage (LLM), publiée par l'Open Worldwide Application Security Project (OWASP), la communauté à l'origine du célèbre Top 10 des applications web. L'édition 2025 cite l'injection de prompt, la divulgation d'informations sensibles, les risques de la chaîne d'approvisionnement, l'empoisonnement des données et des modèles, la mauvaise gestion des sorties, l'autonomie excessive, la fuite du prompt système, les faiblesses des bases vectorielles et des embeddings, la désinformation et la consommation illimitée de ressources. Pour une entreprise qui ne fait qu'utiliser des outils d'IA, trois points comptent le plus : la divulgation d'informations sensibles, c'est-à-dire le problème de l'IA fantôme ; l'autonomie excessive, soit des agents d'IA dotés de plus de permissions que nécessaire ; et l'injection de prompt, qui transforme tout document ou page web lu par un agent en attaque possible. Pour une entreprise qui intègre l'IA à son propre produit, la liste entière constitue une check-list pertinente pour les revues de conception et les tests, et un vocabulaire commun pour les questionnaires de sécurité des clients. C'est un guide, ni une norme ni une certification.

Concevez le système pour que le modèle ne voie que ce dont la tâche a besoin, et partez du principe que tout ce qu'il voit peut ressortir. Concrètement : choisissez un déploiement aux conditions contractuelles adaptées à vos données, comme une API entreprise sans entraînement sur les entrées, avec une durée de conservation définie et un traitement dans l'UE si nécessaire, ou un modèle que vous hébergez vous-même ; minimisez et pseudonymisez ce qui entre dans les prompts ; dans les systèmes de recherche documentaire, appliquez les droits d'accès de l'utilisateur aux documents que le modèle peut récupérer, pour qu'il ne résume pas des fichiers que l'utilisateur n'a pas le droit d'ouvrir ; tenez secrets, clés et identifiants système hors des prompts et du contexte ; filtrez les sorties à la recherche de données personnelles et de secrets avant qu'elles n'atteignent les utilisateurs ou les journaux ; limitez les outils que le modèle peut appeler et exigez une validation pour les actions ; et journalisez prompts et réponses de façon protégée pour les investigations, avec une conservation adaptée. Testez la résistance à l'injection de prompt et aux tentatives d'extraction de données avant le lancement et après chaque changement. Dès l'offre Pro, NetSenX montre quels serveurs envoient des données à quels services d'IA externes et en quelle quantité, ce qui aide à confirmer que le trafic de production ne va que là où la conception le prévoit.

Le Model Context Protocol (MCP) est un protocole ouvert, présenté par Anthropic en novembre 2024 et largement adopté depuis, qui permet aux assistants et agents d'IA de se connecter de façon standard à des outils et à des sources de données. Un serveur MCP expose des capacités, comme lire des fichiers, interroger une base de données, chercher dans un système de tickets ou envoyer des messages, et un client d'IA les appelle quand une tâche en a besoin. L'IA devient ainsi bien plus utile, mais chaque serveur MCP devient aussi une passerelle : tout ce qu'il peut atteindre, l'IA peut l'atteindre, avec les permissions du compte qui est derrière. Les questions de sécurité en découlent directement. Qui a installé le serveur, et depuis où ? Quels identifiants détient-il, et quelle est leur portée ? Tourne-t-il en local sur un portable ou comme service distant ? Exige-t-il une validation avant d'agir ? Est-il journalisé ? Traitez les serveurs MCP comme des logiciels à accès privilégié : approuvez-les, restreignez leurs jetons, tenez-les à jour et préférez ceux d'éditeurs vérifiés. Un capteur réseau voit les serveurs MCP distants comme des connexions vers leurs hôtes ; les serveurs locaux sur un portable restent hors de sa vue.

Un serveur MCP fantôme est un serveur Model Context Protocol que quelqu'un a branché sur un assistant d'IA à l'insu de l'informatique, en général pour gagner du temps : un connecteur vers la messagerie de l'entreprise, un partage de fichiers, un dépôt de code, une base de données ou un outil de tickets, installé depuis un catalogue public ou écrit en un après-midi. Le risque est qu'il crée discrètement un nouveau chemin d'accès. Il détient souvent un jeton d'accès personnel ou une clé d'API aux droits étendus, stockés dans un fichier de configuration sur un portable ; il peut venir d'un auteur inconnu et se mettre à jour seul ; il permet à l'IA d'agir sur les systèmes de l'entreprise avec les permissions de cette personne ; et tout ce que l'IA lit, y compris une instruction malveillante cachée dans un document ou une page web, peut orienter ce qu'elle fait via ce connecteur. Personne ne le contrôle ni ne le journalise, et il survit au départ du salarié si le jeton n'est pas révoqué. Mesures pratiques : publiez une liste de serveurs MCP approuvés, restreignez et renouvelez les jetons, surveillez dans les journaux du fournisseur d'identité les nouvelles autorisations OAuth accordées à des clients d'IA et intégrez les connecteurs au processus de départ. Un capteur réseau voit les connexions d'un portable vers des services distants, pas la configuration MCP qui s'y trouve.

Cherchez là où les agents puisent leur pouvoir : identités, connecteurs et plateformes d'automatisation, puis confirmez avec le trafic réseau. Un agent d'IA est un logiciel qui utilise un modèle de langage pour décider d'étapes et les exécuter, comme lire des tickets, interroger des systèmes, écrire du code ou envoyer des courriels, en général via des clés d'API, des comptes de service ou des autorisations OAuth. Les meilleures premières sources sont donc votre fournisseur d'identité et les consoles d'administration de vos services SaaS : nouvelles applications OAuth aux droits étendus, comptes de service ou jetons personnels créés récemment, fonctions d'IA avec connecteurs activés. Vérifiez ensuite les plateformes d'automatisation et de low-code, les chaînes d'intégration continue et les postes des développeurs à la recherche de frameworks d'agents et de serveurs MCP, et interrogez directement les équipes, car beaucoup d'agents sont des pilotes que personne n'a déclarés. Le réseau ajoute la vue comportementale : quels serveurs ou postes appellent régulièrement des API d'IA, la nuit ou par rafales, et lesquels joignent aussi des systèmes internes. Dès l'offre Pro, NetSenX montre quels hôtes parlent à quels services d'IA externes et environnements de modèles locaux, et combien de données circulent. Il n'identifie pas un agent par son nom, et les signaux comportementaux propres aux agents ne sont pas encore des alertes.

Oui, et en général avec des contrôles plus stricts qu'un humain disposant des mêmes droits. Un agent agit à la vitesse d'une machine, ne se fatigue pas, ne devient pas méfiant, peut être orienté par le texte qu'il lit et tourne souvent avec un jeton qui n'expire jamais. Donnez donc à chaque agent sa propre identité plutôt que le compte d'une personne, n'accordez que les permissions nécessaires à la tâche, privilégiez la lecture seule, séparez les environnements pour qu'un agent de test ne touche pas la production, exigez une validation humaine pour les paiements, suppressions, messages externes et changements de droits, fixez expiration et renouvellement de ses identifiants, et journalisez chacune de ses actions dans un endroit qu'il ne peut pas modifier. Passez les agents en revue avec les comptes de service et intégrez-les au processus de départ. Le coût de l'impasse est concret : le Cost of a Data Breach Report 2025 d'IBM indique que 13 % des organisations ont signalé des violations de modèles ou d'applications d'IA, et que 97 % d'entre elles déclaraient ne pas disposer de contrôles d'accès appropriés à l'IA. Côté réseau, NetSenX détecte dans chaque offre le comportement d'une identité détournée, comme les mouvements latéraux et les envois inhabituels, depuis l'hôte sur lequel tourne l'agent.

Oui, et sans que personne ne le veuille. Un agent ayant accès à un CRM, une boîte aux lettres ou un lecteur partagé peut être sollicité, ou piégé par une instruction cachée dans un document, un courriel ou une page web qu'il lit, pour résumer, transférer ou envoyer des données bien au-delà de ce dont sa tâche a besoin. Les voies courantes : un agent qui répond à des messages externes et inclut des données internes dans sa réponse, un agent capable d'envoyer des courriels ou de publier sur des services externes, un agent de code qui pousse vers un dépôt public du code contenant des secrets, et un agent dont les journaux ou la mémoire conservent des données clients là où personne ne les attend. Le remède, c'est le périmètre : uniquement les données nécessaires, aucun canal sortant sauf besoin, une validation humaine avant que quoi que ce soit ne quitte l'entreprise, et une séparation entre les agents qui lisent des contenus non fiables et ceux qui détiennent un accès sensible. Testez ces chemins avant la mise en service. Dans chaque offre, NetSenX détecte un volume de données sortantes inhabituel depuis un hôte, quel que soit le processus en cause, et dès l'offre Pro il montre avec quels services d'IA l'hôte communique ; il ne voit pas ce que l'agent a envoyé.

En partie aujourd'hui, et NetSenX dit clairement quelle partie. Ce qui fonctionne : dès l'offre Pro, le trafic d'un hôte vers des services d'IA externes et vers des environnements de modèles de langage exécutés localement, avec horaires et volumes ; et dans chaque offre, les comportements qu'un agent détourné partagerait avec tout hôte compromis, comme joindre de nombreux systèmes internes jamais utilisés, balayer le réseau, contacter régulièrement un serveur inconnu ou envoyer un volume de données inhabituel. Ce qui n'est pas actif : les signaux visant spécifiquement les agents, comme des actions à cadence de machine juste après un appel à un modèle de langage, ou une première connexion vers une nouvelle destination qui suit une réponse du modèle. NetSenX les mesure en mode fantôme, sans lever d'alerte, tant qu'ils ne sont pas assez fiables pour être utiles ; il ne faut ni les présenter ni s'y fier comme à des détections. Les contrôles les plus forts sont ailleurs : permissions étroites, validation humaine des actions lourdes de conséquences et journaux d'actions de l'agent lui-même. Un capteur réseau ne voit jamais non plus quelle instruction a fait agir l'agent.

Surtout pour mener des attaques connues plus vite, moins cher et dans une meilleure langue, pas pour en inventer de nouvelles. Les courriels d'hameçonnage ne se trahissent plus par une grammaire maladroite et peuvent être adaptés à votre entreprise en quelques minutes à partir d'informations publiques. Le clonage de voix et les vidéos truquées rendent plus convaincants les faux appels d'un dirigeant ou d'un fournisseur. Les attaquants utilisent l'IA pour écrire et varier des scripts, repérer des cibles et trier rapidement des données volées. Cela change la défense de deux façons. Les contrôles qui reposaient sur le repérage d'une mauvaise rédaction ou d'un ton étrange perdent de leur valeur : les processus ne doivent donc pas dépendre de la détection d'un faux. Confirmez les changements de coordonnées de paiement par un canal connu, utilisez une authentification multifacteur résistante à l'hameçonnage et limitez ce qu'un seul compte volé peut atteindre. Et les étapes qui suivent le premier point d'appui se ressemblent sur le réseau, quel que soit l'auteur des outils, humain ou non : un appareil qui contacte un serveur inconnu, des balayages, des mouvements latéraux et des données qui sortent. NetSenX détecte ces comportements dans chaque offre, y compris Free, sans avoir besoin de reconnaître le logiciel malveillant ou le message à l'origine de l'attaque.

Oui, et la défense est un processus, pas une technologie. Avec quelques minutes d'audio ou de vidéo publics, un attaquant peut imiter la voix et le visage d'un dirigeant ou d'un fournisseur assez bien pour faire illusion au téléphone ou en visioconférence, surtout dans l'urgence. Début 2024, la police de Hong Kong a décrit un cas où un employé d'une multinationale a viré des sommes importantes après une visioconférence dont les autres participants, dont un cadre dirigeant, étaient des hypertrucages. Protection : une règle selon laquelle aucun paiement, changement de coordonnées bancaires ou virement urgent n'est validé sur la seule base d'un appel ou d'un message ; une confirmation par un autre canal déjà connu, comme un rappel au numéro enregistré, jamais à celui donné dans la demande ; deux personnes pour valider les paiements au-delà d'un seuil ; un mot de code pour les vraies urgences si vous le souhaitez ; et un personnel qui sait qu'il sera soutenu s'il ralentit un paiement. Aucun capteur réseau ne distingue une vraie voix d'une fausse. NetSenX n'est pas la réponse ici : il n'analyse ni appels ni vidéos et ne voit pas les ordres de paiement.