IA générative en PME : protéger les données et les accès

L’IA générative en PME oblige à examiner ce qui quitte réellement l’entreprise. Un fichier client transmis pour préparer une offre peut contenir des coordonnées, des conditions commerciales ou des informations contractuelles. Même sans intrusion informatique, son envoi à un service non validé peut placer ces données hors du cadre prévu par l’organisation.

Pour un dirigeant, l’enjeu consiste donc à définir les usages autorisés et les informations qui peuvent les alimenter. La CNIL recommande d’encadrer le déploiement de l’IA générative à partir de besoins précis, de former les utilisateurs et d’examiner les possibilités de réutilisation des données par le prestataire. Notre décryptage sur l’IA en entreprise et les règles du RGPD revient sur ces obligations.

IA générative en PME : contrôler les données et les capacités d’action

Le risque évolue lorsqu’un assistant peut consulter des dossiers ou envoyer des messages. Dans son bulletin sur les risques des outils d’automatisation par IA agentique, le CERT-FR décrit notamment les risques d’exfiltration et de commandes non autorisées liés à des injections de prompts. Les accès accordés à l’outil deviennent alors un élément déterminant de la sécurité.

Barracuda a annoncé AI Data Security le 22 septembre 2026, avec une disponibilité prévue en octobre. L’éditeur présente cette offre comme un moyen de contrôler les usages et les transmissions vers les services d’IA. Les capacités exposées ci-dessous sont celles décrites par son représentant ; elles ne constituent pas les résultats d’un test indépendant.

Déjà interrogé par Business Times sur les vulnérabilités des applications web et les priorités de correction, Yaz Bekkar, Architecte Conseil Principal – XDR, EMEA chez Barracuda Networks, répond ici à quatre questions. Il détaille les conditions de couverture du contrôle, les limites de la traçabilité et les décisions qui restent à la charge de la PME.

1. L’IA générative crée-t-elle un nouveau point d’entrée pour les cyberattaques ?

Yaz Bekkar. Oui, mais ce risque ne prend pas toujours la forme d’une cyberattaque classique. Il peut aussi résulter d’usages légitimes de l’IA qui échappent au contrôle de l’entreprise.

Par exemple, un commercial peut importer un fichier client dans un outil d’IA pour finaliser rapidement une proposition. Un collaborateur des RH peut aussi utiliser un assistant pour résumer des dossiers salariés. Ces usages partent souvent d’une bonne intention. Pourtant, ils peuvent exposer des informations sensibles à un service que l’entreprise n’a ni évalué, ni validé. Elle ne l’a pas non plus intégré à son cadre de sécurité.

Il n’est donc pas nécessaire qu’un attaquant compromette directement un système pour qu’une donnée sensible quitte l’entreprise. Avec le shadow AI, la DSI peut même ne pas avoir connaissance de l’utilisation de certains outils ou comptes.

Il existe également des attaques délibérées. Un compte IA compromis peut, par exemple, donner accès à des historiques de conversation. Selon ses autorisations, il peut aussi ouvrir l’accès à d’autres informations ou ressources. L’injection de prompts constitue une autre voie d’attaque. Un cybercriminel peut dissimuler des instructions malveillantes dans un contenu que l’assistant doit analyser. Un document fourni par un tiers pourrait ainsi inciter l’assistant à rechercher des informations internes. Il pourrait ensuite lui demander de les transmettre à une source externe. L’objectif est alors de faire interpréter le contenu comme une instruction, plutôt que comme une simple donnée à analyser.

Les autorisations des agents augmentent les enjeux

Le jailbreak, quant à lui, vise à contourner les garde-fous et les mécanismes de sécurité du modèle.

Les agents d’IA augmentent encore les enjeux, car l’entreprise peut leur confier des capacités d’action. Ils peuvent envoyer des messages, accéder à des fichiers ou modifier des enregistrements dans ses systèmes. Une réponse erronée ou trompeuse constitue un risque. Une action non autorisée dans un système d’entreprise représente un niveau de risque supplémentaire.

Les cyberattaques traditionnelles n’ont donc pas disparu. Ce qui évolue, c’est la possibilité d’influencer un assistant à travers les contenus qu’il traite. L’attaquant peut ensuite exploiter les accès et les autorisations de cet assistant.

C’est précisément sur ce point que les entreprises doivent concentrer leur attention : à quelles informations l’IA peut-elle accéder ? Quelles autorisations possède-t-elle ? Et surtout, quelles actions peut-elle réellement effectuer ?

2. Comment Barracuda AI Data Security surveille réellement les informations envoyées aux outils d’IA ?

Yaz Bekkar. Notre objectif est d’empêcher les informations sensibles de quitter l’entreprise, sans pour autant freiner l’activité des collaborateurs.

Le meilleur moment pour intervenir est avant que l’information n’atteigne le service d’IA. Découvrir après coup qu’un collaborateur a transmis un fichier confidentiel signifie que la donnée a déjà quitté le périmètre de l’entreprise.

Barracuda AI Data Security inspecte les prompts et les fichiers téléchargés lorsqu’ils transitent par le chemin d’application de l’accès SecureEdge pris en charge. L’apprentissage automatique et la détection par motifs permettent d’identifier différents types de données sensibles, notamment les informations personnelles, les identifiants, les données de paiement, les dossiers médicaux ou encore le code source. Cette classification s’appuie sur Barracuda Data Inspector. Elle permet d’appliquer des politiques selon l’utilisateur, le groupe, le service d’IA et le type d’informations.

La première étape consiste toutefois à connaître les outils d’IA que les collaborateurs utilisent réellement. La télémétrie réseau et DNS existante peut permettre d’identifier ces usages sans avoir à installer un agent sur chaque terminal. Mais détecter qu’un collaborateur a accédé à un service d’IA ne signifie pas pour autant que l’entreprise sait ce qu’il y a envoyé. C’est une distinction essentielle.

Vérifier les flux couverts avant le déploiement

La couverture dépend ensuite des usages et des flux concernés : navigateurs, applications installées, API ou encore assistants intégrés aux logiciels métiers. Elle repose notamment sur le passage du trafic par le point d’application, ainsi que sur la prise en charge du service, du protocole et du format des données. Lors du déploiement, les équipes doivent donc vérifier ces éléments à partir des flux et des usages réels de chaque entreprise.

Lorsqu’une règle de blocage s’applique, le dispositif interrompt la transmission. Le collaborateur reçoit une explication et des indications sur la manière de procéder. Le système enregistre aussi l’événement. Lorsque le contexte le permet, les politiques peuvent également générer une alerte ou appliquer une mesure de caviardage plutôt que bloquer systématiquement la demande.

Cette dimension pédagogique est importante. Le collaborateur doit comprendre pourquoi le dispositif a bloqué sa transmission et quel comportement adopter. Il peut ainsi mieux éviter la même erreur à l’avenir.

Mesurer les erreurs et les limites de détection

Le véritable enjeu est donc de protéger les informations sensibles sans perturber en permanence les usages légitimes de l’IA. Les politiques doivent être suffisamment précises. Les équipes doivent aussi les tester dans des conditions proches de la réalité. Les collaborateurs n’utilisent pas uniquement des données parfaitement structurées. Il faut également prendre en compte les formulations indirectes, les différents langages utilisés, les images et les documents complexes.

Enfin, la performance d’une telle solution ne se résume pas à un simple taux de précision. Il faut mesurer ce que le système détecte et ce qu’il ne détecte pas. Il faut aussi évaluer la fréquence des interruptions d’usages légitimes et le délai d’inspection des données. Un pourcentage de précision, pris isolément, ne permet pas de mesurer réellement l’efficacité d’un dispositif de sécurité.

Lorsqu’un flux ou un contenu échappe à l’inspection, l’entreprise doit l’identifier et définir une règle de traitement spécifique. Par défaut, elle ne doit pas le considérer comme sûr.

3. La traçabilité des interactions avec l’IA elle-même peut-elle devenir un risque pour l’entreprise ?

Yaz Bekkar. Absolument. Les entreprises ont raison de se poser cette question. Un dispositif destiné à prévenir l’exposition des données ne doit pas créer une nouvelle collecte d’informations sensibles sans protection suffisante.

La piste d’audit permet notamment d’enregistrer l’utilisateur concerné, la politique appliquée, la catégorie de données détectée, l’action effectuée et l’horodatage. Ces informations permettent de comprendre ce qui s’est passé lors d’un incident. Elles permettent aussi de démontrer que le dispositif a bien appliqué un contrôle de sécurité.

Mais il est important de distinguer la traçabilité d’un événement de la conservation du contenu intégral d’une conversation. Enregistrer le blocage d’une soumission n’impose pas nécessairement de conserver l’intégralité du prompt ou du document concerné.

Avant de collecter davantage d’informations, l’entreprise doit pouvoir répondre à une question simple : pourquoi avons-nous besoin de ces données ? Les seuls éléments de l’événement peuvent parfois suffire à comprendre et à investiguer un incident. Dans ce cas, conserver le contenu complet exige une justification spécifique.

Les entreprises doivent connaître le lieu de stockage, la durée de conservation et les personnes qui peuvent accéder aux données. Elles doivent aussi savoir si le service conserve le contenu intégral ou peut l’anonymiser. Les conditions du service et les politiques de sécurité doivent clairement définir ces éléments. La simple existence d’une piste d’audit ne répond pas à ces questions.

Protéger les journaux et informer les collaborateurs

L’entreprise doit aussi contrôler strictement l’accès aux données de traçabilité. Elle doit le réserver aux personnes qui en ont réellement besoin. Cela concerne également les équipes MSP lorsqu’elles disposent d’un accès délégué. Le chiffrement, l’authentification forte et l’audit des accès administratifs font partie des mesures essentielles. Cette protection doit également s’appliquer aux rapports exportés : transmettre des éléments à un auditeur ou à un assureur ne les rend pas moins sensibles.

Il faut enfin être transparent avec les collaborateurs sur ce qui est surveillé et pourquoi. L’entreprise doit définir les objectifs du traitement, sa base légale et les durées de conservation conformément au RGPD. Elle doit aussi évaluer les impacts sur la vie privée lorsque cela est nécessaire. La sécurité ne doit pas devenir, à l’insu des collaborateurs, un outil de surveillance de leur activité quotidienne.

Enfin, il faut être prudent avec le terme « anonymisé ». Supprimer simplement un nom ne suffit pas nécessairement à rendre une personne impossible à identifier. De la même manière, l’anonymisation ne supprime pas la sensibilité d’une information qui révèle, par exemple, un secret commercial.

C’est pourquoi le principe le plus simple reste souvent le plus efficace : ne collecter que les informations réellement nécessaires, dès le départ, et protéger strictement celles qui doivent être conservées.

4. Cette gouvernance sera-t-elle vraiment accessible aux petites et moyennes entreprises, et qu’est-ce qu’elle ne remplacera jamais ?

Yaz Bekkar. Chez Barracuda, nous devons concevoir nos solutions en tenant compte de la personne qui va réellement les administrer. Dans une PME, il peut s’agir d’un responsable IT généraliste ou d’un prestataire externe qui gère déjà une grande partie de l’infrastructure. Ces équipes doivent pouvoir déployer les contrôles, gérer les exceptions et accompagner les collaborateurs, sans transformer la sécurité de l’IA en une nouvelle activité à temps plein.

Notre modèle commercial commence avec un niveau de découverte gratuit dans l’offre Foundation. Les éditions Premium et Premium Plus reposent ensuite sur une tarification par utilisateur et par mois. Un devis adapte l’offre à la taille et aux besoins de chaque organisation. La disponibilité est prévue pour octobre 2026, avec également une intégration à Barracuda SecureEdge Premium Access sans coût supplémentaire.

La gestion s’effectue depuis BarracudaONE, avec des mécanismes de détection préconfigurés et une configuration guidée via Bailey. Les clients existants de SecureEdge Access peuvent également s’appuyer sur leur déploiement actuel. Lorsque les prérequis existent déjà, les équipes peuvent activer rapidement l’application des politiques.

Le déploiement exige des tests dans l’entreprise

Cela ne signifie pas pour autant qu’un déploiement se résume à activer une fonctionnalité. Une nouvelle installation nécessite notamment de mettre en place le routage et l’inspection du trafic. Il faut aussi associer les utilisateurs et les groupes, définir les services d’IA approuvés et tester les politiques. Activer un contrôle est une chose ; s’assurer qu’il fonctionne correctement dans l’environnement réel de l’entreprise en est une autre.

Pour les entreprises qui ne disposent pas d’un CISO ou d’une équipe de sécurité dédiée, un MSP peut prendre en charge une grande partie de ce travail opérationnel. BarracudaONE permet notamment une gestion centralisée et multi-tenant. Mais les politiques, les autorisations, les journaux et les rapports propres à chaque client doivent rester clairement séparés. La possibilité de gérer plusieurs entreprises depuis une même console ne doit jamais conduire à brouiller les frontières entre leurs données ou leurs responsabilités.

Un MSP peut donc contribuer à gérer les contrôles. Cependant, il ne peut pas prendre à la place de l’entreprise les décisions qui relèvent de sa gouvernance de l’IA. L’organisation doit notamment déterminer quels outils elle autorise et quelles informations les collaborateurs peuvent partager. L’entreprise doit décider explicitement si un agent d’IA peut accéder aux dossiers clients. Elle ne devrait jamais lui accorder cet accès par défaut.

Permettre aux salariés de signaler une erreur

Cette gouvernance doit également s’appuyer sur des mesures fondamentales : une formation pratique des collaborateurs, une classification adaptée des données, le principe du moindre privilège et une authentification forte. L’entreprise doit sécuriser les terminaux et tester régulièrement les sauvegardes. Elle doit aussi disposer d’un plan de réponse aux incidents.

Enfin, il y a un facteur humain que la technologie ne peut pas remplacer. Les collaborateurs doivent se sentir suffisamment en confiance pour signaler rapidement une erreur. Une solution de sécurité peut empêcher une transmission à risque. Mais elle ne peut pas, à elle seule, créer un climat qui encourage un collaborateur à signaler l’envoi du mauvais fichier.

La gouvernance de l’IA repose donc sur trois éléments complémentaires : la technologie, les processus et les personnes. Aucun outil ne peut remplacer les décisions et les responsabilités de l’entreprise.