PubSunuCyberSecuritySunuCyberSecurityCybersecurite pour l'AfriqueTests d'intrusion et audits de securite. Scans automatises, pentest et detection continue.Scanner mon sitePubSunuBarometreSunuBarometreCybersecurite AfriqueDonnees reelles, mises a jour en continu, sans extrapolation.Voir les chiffres
PubSunuCyberSecuritySunuCyberSecurityCybersecurite pour l'AfriqueTests d'intrusion et audits de securite. Scans automatises, pentest et detection continue.Scanner mon sitePubSunuBarometreSunuBarometreCybersecurite AfriqueDonnees reelles, mises a jour en continu, sans extrapolation.Voir les chiffres
ZDNet France
6 novembre 2026

Tanguy Duthion, Avanoo et Alex Combessie, Giskard : « Quelles IA ont accès à nos données ? » : la question que tout RSSI redoute en comité de direction

Tanguy Duthion, Avanoo et Alex Combessie, Giskard : « Quelles IA ont accès à nos données ? » : la question que tout RSSI redoute en comité de direction
62 % des salariés des grandes entreprises françaises utilisent déjà l'IA, mais seuls 34 % disposent de règles d'usage formalisées. Tanguy Duthion, CEO d'Avanoo, et Alex Combessie, cofondateur et CEO de Giskard, détaillent la chaîne en quatre maillons nécessaire pour reprendre la main sur le Shadow AI.
Tanguy Duthion, Avanoo et Alex Combessie, Giskard : « Quelles IA ont accès à nos données ? » : la question que tout RSSI redoute en comité de direction 62 % des salariés des grandes entreprises françaises utilisent déjà l’IA, mais seuls 34 % disposent de règles d’usage formalisées. Tanguy Duthion, CEO d’Avanoo, et Alex Combessie, cofondateur et CEO de Giskard, détaillent la chaîne en quatre maillons nécessaire pour reprendre la main sur le Shadow AI. PAR TANGUY DUTHION, CEO D’AVANOO, ET ALEX COMBESSIE, COFONDATEUR ET CEO DE GISKARD, © Tanguy Duthion, Avanoo et Alex Combessie, Giskard Assistants grand public, extensions de navigateur, connecteurs, agents bricolés par les équipes métiers : l'IA s'est installée dans les entreprises bien plus vite que les règles censées l'encadrer. Pour les DSI et les RSSI, le défi est double. Il faut d'abord voir ce qui tourne réellement, puis s'assurer que les IA conservées se comportent comme prévu, aujourd'hui et dans six mois. Il existe une question que tout RSSI redoute d'entendre en comité de direction : « Quelles IA ont accès à nos données ? » Elle est simple. La réponse, presque jamais. En France, 62% des salariés des grandes entreprises déclarent utiliser l'IA en 2026, contre 38% en 2024. Seuls 34% disposent de règles d'usage formalisées. Entre ces deux chiffres se loge tout le problème : l'usage a pris de l'avance, la gouvernance court derrière. Cet écart a un nom : le Shadow AI. On l'imagine souvent sous les traits d'un salarié qui colle un document dans un chatbot grand public. La réalité est bien plus large. C'est l'ensemble des IA qui touchent aux données de l'entreprise sans que personne ne l'ait décidé. Un assistant de prise de notes qui rejoint seul une réunion client. Du code propriétaire collé dans un assistant pour corriger un bug. Un agent no-code branché sur la messagerie, avec les droits de son créateur. Aucun de ces usages n'est malveillant, mais tous font sortir de la donnée. Et la plupart échappent aux outils classiques d'inventaire, parce qu'ils sont gratuits, passent par des comptes personnels ou vivent dans le navigateur. Voilà pourquoi la question du comité de direction reste si souvent sans réponse. Cette zone d'ombre a un coût : le Shadow AI est impliqué dans 43% des incidents de sécurité des organisations victimes d'une violation de données, contre 20% un an plus tôt. Et ces incidents coûtent en moyenne 5,39 millions de dollars, au-dessus de la moyenne mondiale de 4,99 millions. Face à cet angle mort, le premier réflexe n'est pas d'interdire, mais de détecter en continu, là où l'usage a lieu, pour savoir quels outils, quelles données et quels agents sont en jeu. C'est à partir de cette carte que la DSI et le RSSI peuvent décider, outil par outil, ce qu'ils autorisent, encadrent ou refusent. Bloquer quelques services d'IA sans visibilité, c'est verrouiller la porte d'entrée en laissant toutes les fenêtres ouvertes. Le sujet n'est pas de dire non, c'est de savoir à quoi on dit oui. Et pour le savoir, il faut d'abord voir ce qui tourne vraiment dans les navigateurs des collaborateurs (spoiler : rarement ce qui figure dans la politique d'usage). Une IA validée en janvier peut dérailler en mars Voir ne suffit pas pour autant. Parmi les IA identifiées, certaines seront conservées, voire déployées à grande échelle : l'assistant interne qui répond à partir des documents de l'entreprise, le chatbot exposé aux clients, l'agent qui agit dans les outils métiers. Or une IA visible n'est pas une IA sûre. Elle peut être manipulée par injection de prompt, laisser fuiter des données ou inventer une réponse. Parmi les organisations victimes d'une violation étudiées par IBM, plus d'une sur cinq déclare que l'attaque visait ses propres modèles ou applications d'IA. Un modèle de langage ne se comporte pas comme un logiciel classique. La même question peut produire deux réponses différentes, et une mise à jour du fournisseur peut changer son comportement du jour au lendemain. Le prompt système évolue, la base de connaissances s'enrichit, de nouvelles techniques d'attaque circulent. Un système sain en janvier peut donc ne plus l'être en mars sans qu'une ligne de code ait changé côté entreprise. Tester une IA une seule fois avant sa mise en production, c'est photographier une cible mouvante. D'où la nécessité de tester en continu, en partant non pas de la technique, mais des dommages que l'entreprise veut éviter : fuite de données, action non autorisée, réponse inventée, écart aux règles métier. Puis de vérifier si l'IA peut les provoquer, que l'origine soit une attaque, une question hors périmètre d'un utilisateur ou une hallucination. La sécurité de l'IA tient en une chaîne de quatre maillons : voir ce qui est utilisé, décider de ce qui est autorisé, tester ce qui est conservé, et pouvoir le prouver. Aucun ne vaut sans les autres. Un inventaire sans tests reste une liste. Des tests sans inventaire ne couvrent que ce que l'on connaissait déjà. C'est aussi ce qu'exigent, chacun à sa manière, l'AI Act, NIS2 et DORA : savoir quels systèmes sont en usage, et démontrer qu'ils sont maîtrisés. La conformité ne se joue donc plus sur un audit annuel, mais sur la capacité à produire à tout moment une carte à jour et des preuves de tests récentes. Reste une question trop souvent oubliée. Un outil de sécurité de l'IA voit passer ce qu'une entreprise a de plus sensible : la carte de ses usages, le contenu de ses prompts, les failles de ses assistants. Le choisir, c'est choisir qui détient la cartographie de ses vulnérabilités, et sous quel droit. Les DSI et les RSSI ont appris à poser la question de la souveraineté pour l'hébergement de leurs données ou pour leur messagerie. Ils doivent désormais la poser pour les outils qui observent et attaquent leurs IA. Sécuriser son IA ne devrait pas obliger à confier la carte de ses failles à un acteur soumis à un autre droit que le sien. Ce serait faire auditer ses serrures par quelqu'un qui garde un double des clés. Martin Pavanello, Mister IA : Les Pays-Bas réduisent l'État avec l'IA. La France n'a pas le temps d'y penser Galaxy Book6 Series : 10 raisons de choisir la performance Le guide de la migration écoresponsable vers Windows 11 IA locale : la nouvelle ère de l’Intelligence artificielle ?
Publié le 6 novembre 2026
Source originale : ZDNet France