Thales constate que les entreprises redoutent davantage les risques liés à l’IA que les cybermenaces familières

Thales a constaté un renversement frappant : 69 % des organisations interrogées ont désigné l’écosystème en évolution rapide de l’IA comme leur principale préoccupation en matière de sécurité de l’IA générative. Les menaces connues telles que les malwares, le phishing et les ransomwares restent actives, mais les entreprises font désormais face à un système qu’elles déploient elles-mêmes.

Cette constatation ne signifie pas que l’IA provoque déjà davantage de violations que les ransomwares ou les malwares. Elle montre que les entreprises redoutent davantage l’incertitude entourant l’adoption de l’IA que n’importe quel type d’attaque établi pris isolément. Les équipes de sécurité maîtrisent les contrôles contre le phishing. Elles ont moins confiance dans des systèmes capables d’accéder aux données, de générer du code et de déclencher des actions métier.

Cette distinction est importante, car le risque lié à l’IA franchit plusieurs frontières établies. Il combine cybersécurité, confidentialité, exposition juridique, fiabilité des modèles et contrôle opérationnel. Le conflit central n’oppose plus l’adoption de l’IA à la résistance. Il oppose la vitesse de déploiement métier à la capacité d’une organisation à gouverner ce qu’elle a déjà installé.

L’enquête révèle une évolution des craintes des entreprises

Les entreprises ne remplacent pas leurs anciennes craintes cyber par l’IA. Elles reconnaissent que l’IA peut amplifier plusieurs risques à la fois.

Le rapport sur les menaces pesant sur les données a interrogé plus de 3 100 professionnels de la technologie et de la sécurité dans 20 pays et 15 secteurs. S&P Global Market Intelligence 451 Research a mené l’étude pour Thales.

Parmi les répondants, 69 % ont sélectionné l’écosystème de l’IA en évolution rapide comme leur principale préoccupation de sécurité liée à l’IA générative. L’intégrité des modèles suivait avec 64 %, tandis que la fiabilité arrivait ensuite avec 57 %.

L’expression « écosystème en évolution rapide » couvre bien plus que les lancements de modèles. Elle inclut les fournisseurs de modèles, les plugins, les services de données, les frameworks de développement, les agents et l’infrastructure qui les relie. Chaque composant peut évoluer indépendamment, créant une chaîne de dépendances que les équipes de sécurité ne contrôlent pas entièrement.

Cela diffère d’un incident de malware familier. Une équipe de sécurité peut identifier un fichier malveillant, isoler un terminal et enquêter sur son parcours. Un système d’IA peut se comporter de manière incorrecte sans transporter de malware ni afficher d’indicateur de compromission traditionnel.

Un modèle peut exposer des informations confidentielles parce qu’un utilisateur les a saisies dans un service non approuvé. Un agent peut récupérer des données au-delà du périmètre prévu par le demandeur. Du code généré par l’IA peut introduire une dépendance vulnérable sans déclencher d’alerte immédiate.

Ces résultats peuvent ressembler à des défaillances ordinaires de cybersécurité. Toutefois, leurs causes se situent souvent en dehors du centre traditionnel des opérations de sécurité. Les équipes achats, juridiques, d’ingénierie, de science des données, de conformité et métier influencent toutes le système.

L’enquête a également révélé que 73 % des répondants investissaient dans des outils de sécurité spécifiques à l’IA. Certains ont reçu de nouveaux budgets, tandis que d’autres ont réorienté des dépenses de sécurité existantes. Ce chiffre confirme que la préoccupation s’est déjà traduite dans les décisions d’achat et de planification.

Pourtant, des logiciels supplémentaires ne résolvent pas automatiquement les responsabilités mal définies. Un produit de surveillance ne peut pas décider auxquelles des données métier un agent devrait avoir accès. Il ne peut pas non plus définir un comportement de modèle acceptable pour chaque client, employé ou flux de travail réglementé.

Les catégories d’attaques traditionnelles sont restées importantes dans la même étude. Les malwares occupaient la première place parmi les types d’attaques observés, le phishing était passé en deuxième position et les ransomwares se classaient troisièmes.

Ce contexte nuance le sens du titre. L’IA constitue la principale préoccupation émergente autour de l’adoption de l’IA générative, et non la preuve que les menaces établies ont disparu. Les entreprises doivent protéger deux environnements qui se chevauchent plutôt que choisir entre eux.

Cette évolution reste importante. Les responsables de la sécurité traitent désormais l’IA comme un domaine de risque pour l’entreprise, et non simplement comme une autre application nécessitant une protection des terminaux. Ses défaillances peuvent provenir de flux de travail approuvés et se propager via des accès de confiance.

Pourquoi les risques de sécurité liés à l’IA échappent aux contrôles familiers

L’IA transforme l’unité de risque : d’une application prévisible, elle devient un système qui interprète des instructions et choisit des actions.

Les applications d’entreprise conventionnelles proposent généralement des fonctions définies. Les utilisateurs saisissent des données structurées, sélectionnent des actions autorisées et reçoivent des résultats délimités. Les équipes de sécurité peuvent relier ces fonctions aux identités, aux autorisations, aux bases de données et aux journaux d’audit.

L’IA générative accepte des instructions ouvertes. Son résultat dépend du prompt, des informations récupérées, du comportement du modèle, de la configuration du système et des outils connectés. De petits changements n’importe où dans cette chaîne peuvent produire des résultats différents.

Un agent d’IA ajoute une couche supplémentaire. Un agent est un logiciel qui utilise un modèle pour planifier des tâches et appeler des outils avec une intervention humaine limitée. Ces outils peuvent inclure les e-mails, les dépôts de code, les bases de données clients, les calendriers et les systèmes financiers.

Cette architecture crée des risques auxquels les défenses périmétriques n’ont pas été conçues pour répondre. Un employé légitime peut formuler une instruction risquée via une interface approuvée. Le modèle peut ensuite utiliser des connexions autorisées de manière non intentionnelle.

L’injection de prompt illustre le problème. Une instruction malveillante peut apparaître dans un document, une page web ou un message traité par un système d’IA. L’instruction cherche à détourner le modèle de sa tâche prévue.

Aucun mot de passe volé n’est nécessaire lorsque l’agent dispose déjà d’un accès. L’attaquant cible plutôt la couche d’interprétation du modèle. Cela transforme du contenu métier ordinaire en un canal de contrôle potentiel.

La récupération de données crée un défi similaire. La génération augmentée par récupération permet à un modèle d’utiliser des informations organisationnelles sélectionnées pour produire une réponse. Le modèle n’a pas besoin de contenir ces informations dans ses données d’entraînement d’origine.

Toutefois, la qualité de la récupération dépend des autorisations et des métadonnées. Un index de recherche qui ignore les règles d’accès au niveau des documents peut exposer des contenus que l’utilisateur ne pouvait pas ouvrir directement. La réponse peut masquer cette défaillance d’accès derrière un langage naturel.

Cela importe pour les entreprises qui développent des assistants internes à partir de contrats, de comptes rendus de réunion, de tickets d’assistance ou de documents d’ingénierie. Un assistant utile a besoin d’un large contexte. Chaque source ajoutée accroît également les conséquences d’autorisations insuffisantes.

Les employés créent une autre exposition via l’IA fantôme, c’est-à-dire des services d’IA utilisés sans approbation ni supervision de l’organisation. Le personnel peut copier du code source, des dossiers clients ou des plans d’affaires dans des outils publics pour gagner du temps.

Ce comportement est difficile à contrôler par la seule politique. Les employés perçoivent souvent une boîte de discussion IA comme un espace de travail temporaire plutôt que comme un processeur de données externe. L’interface semble moins risquée que l’envoi d’un fichier vers un site web inconnu.

Les conclusions sur la supervision de l’IA citaient une enquête selon laquelle 78 % des employés déclaraient utiliser des outils d’IA au travail. Au sein de ce groupe, 58 % reconnaissaient avoir fourni des informations sensibles de l’entreprise à de grands modèles de langage.

Les chiffres autodéclarés ne mesurent pas les pertes de données confirmées. Ils montrent néanmoins pourquoi le risque lié à l’IA commence avec les utilisateurs autorisés, et pas uniquement avec des attaquants externes. L’adoption peut dépasser l’examen formel, car les outils sont faciles d’accès.

Le défi s’étend au développement logiciel. Les assistants d’IA peuvent proposer du code plus vite que les équipes ne peuvent l’examiner. Une fonction générée peut fonctionner lors des tests tout en contenant des paramètres par défaut non sécurisés, une validation faible ou une dépendance obsolète.

Les scanners de sécurité peuvent détecter des schémas connus, mais ils ne peuvent pas garantir que la logique générée correspond à l’exigence métier. La revue humaine reste nécessaire, en particulier lorsque le code traite l’authentification, les paiements ou des informations réglementées.

La sortie du modèle crée également un risque d’intégrité. Un système peut produire du contenu erroné avec une grande assurance, un comportement couramment appelé hallucination. Le résultat devient dangereux lorsqu’une autre application le traite comme une entrée vérifiée.

Un résumé erroné est gênant. Une décision d’accès ou une instruction financière erronée a des conséquences opérationnelles. Le même comportement de modèle entraîne un risque différent selon les outils et l’autorité qui l’entourent.

C’est pourquoi la sécurité de l’IA ne peut pas être réduite à la précision du modèle. La question pertinente est de savoir ce qui se passe lorsque le modèle se trompe, est manipulé ou reçoit un accès excessif.

Le véritable conflit oppose la vitesse de déploiement au contrôle

Les dirigeants veulent dès maintenant des gains mesurables grâce à l’IA, tandis que les équipes de sécurité héritent de systèmes dont les autorisations et les chemins de défaillance restent flous.

La pression commence au-dessus de l’organisation de sécurité. Les conseils d’administration et les équipes de direction attendent des CIO qu’ils trouvent des usages productifs de l’IA, réduisent les frictions opérationnelles et évitent de prendre du retard sur les concurrents.

Les équipes métier peuvent lancer un pilote d’IA en quelques jours. Construire un inventaire complet, un modèle d’autorisations, un processus d’évaluation et un plan de réponse aux incidents prend davantage de temps. Cet écart de calendrier crée le conflit principal de l’article.

Une enquête de Logicalis menée en 2026 a révélé que plus d’un quart des CIO considéraient l’IA comme un risque important. Les répondants l’ont classée aux côtés des malwares, des ransomwares et du phishing, selon les conclusions sur la sécurité des CIO.

La même étude a révélé que deux tiers des répondants jugeaient insuffisante la formation des employés à la gestion des risques liés à l’IA. Elle indiquait également que 94 % des CIO faisaient face à une pénurie de compétences en cybersécurité.

Ces conclusions révèlent un problème de capacité, et pas seulement un problème technologique. Les organisations ajoutent une catégorie de systèmes peu familière alors que les équipes de sécurité existantes manquent déjà de travailleurs suffisamment spécialisés.

La responsabilité peut également devenir fragmentée. Le CIO peut être responsable de la stratégie technologique, tandis que le CISO est responsable de la sécurité. Les équipes juridiques supervisent la propriété intellectuelle et l’exposition réglementaire. Les responsables des données gèrent la gouvernance, et les unités métier sélectionnent les cas d’usage.

Une défaillance de l’IA peut toucher chacun de ces groupes sans s’inscrire clairement dans un seul service. Lorsque la responsabilité demeure ambiguë, les approbations deviennent incohérentes et la réponse aux incidents ralentit.

Les programmes de cybersécurité établis offrent un contraste utile. Les organisations ont consacré des années à définir des processus pour la gestion des vulnérabilités, la protection des terminaux, les identités, les sauvegardes et la reprise.

Ces contrôles restent essentiels. Les systèmes d’IA fonctionnent toujours sur des services cloud, des applications et des comptes utilisateurs ordinaires. Une identité compromise peut exposer un flux de travail d’IA tout comme elle expose d’autres logiciels.

Toutefois, l’IA ajoute des décisions que les contrôles traditionnels ne peuvent pas prendre seuls. Un pare-feu ne peut pas déterminer si une recommandation générée contient un biais inacceptable. Un logiciel de terminal ne peut pas évaluer si un modèle a cité la bonne politique interne.

Cela ne justifie pas la création d’une bureaucratie de gouvernance de l’IA isolée. Séparer complètement l’IA de la cybersécurité dupliquerait les contrôles et créerait de nouvelles lacunes.

L’approche la plus solide commence par les mécanismes existants d’identité, de classification des données, de revue logicielle et de gestion des incidents. Les équipes peuvent ensuite ajouter l’évaluation des modèles et des contrôles propres aux agents là où les processus ordinaires ne suffisent pas.

L’identité mérite une attention particulière, car les agents agissent au moyen d’identifiants. Chaque agent devrait posséder sa propre identité, des autorisations limitées et un propriétaire documenté. Les comptes partagés compliquent la responsabilité.

Les autorisations doivent correspondre au plus petit ensemble d’actions requis pour la tâche attribuée. Un assistant qui résume des dossiers d’assistance n’a pas besoin d’être autorisé à supprimer des enregistrements. Un agent de programmation n’a pas besoin d’un accès de production sans restriction.

Les organisations ont également besoin d’un inventaire à jour. Les équipes ne peuvent pas gouverner les modèles, les plugins et les connexions de données dont elles ignorent l’existence. Les seuls dossiers d’approvisionnement ne permettront pas d’identifier les outils de navigation ni les intégrations créées par les employés.

Un inventaire doit consigner le fournisseur de modèles, le responsable métier, les sources de données, les outils connectés, les utilisateurs visés et l’autorité décisionnelle. Il doit également indiquer si les résultats font l’objet d’une revue humaine.

Pour les activités intensives en connaissances, les entreprises peuvent réduire leur exposition en conservant les sources au sein de systèmes approuvés. Une base de connaissances IA contrôlée peut préserver les limites d’accès tout en aidant les équipes à retrouver le contexte pertinent.

Ce choix n’élimine pas le risque lié à l’IA. Il offre un cheminement des données plus clair que la copie de contenus sensibles entre des services grand public non liés. Une propriété clairement définie et l’application des autorisations restent déterminantes.

L’objectif n’est pas de bloquer toute expérimentation. Des restrictions trop larges peuvent pousser les employés vers des outils non autorisés. La gouvernance fonctionne mieux lorsque les options approuvées restent utiles et accessibles.

Ce que le titre ne prouve pas

Les préoccupations recueillies par l’enquête mesurent l’exposition perçue, et non la fréquence réelle ou l’impact financier des incidents liés à l’IA.

Le titre invite à une conclusion simple : l’IA serait devenue plus dangereuse que les rançongiciels, les logiciels malveillants ou le phishing. Les éléments disponibles ne soutiennent pas cette affirmation.

Thales a interrogé les répondants sur leurs préoccupations liées à l’IA générative et a, séparément, rapporté les catégories d’attaques observées. Ces mesures répondent à des questions différentes et ne permettent pas d’établir un classement direct des risques.

Une enquête sur les préoccupations reflète l’incertitude, l’attention et les conséquences attendues. Les données d’incident mesurent les événements que les organisations ont détectés et classifiés. Aucune de ces deux approches ne représente automatiquement les pertes totales.

Les répondants peuvent classer l’IA très haut parce que ses limites restent floues. Une menace familière peut sembler plus gérable même lorsqu’elle cause des dommages mesurables plus importants.

La nouveauté peut également influencer les réponses. Les responsables de la sécurité reçoivent fréquemment des questions sur l’IA de la part des conseils d’administration, des clients, des régulateurs et des employés. Cette visibilité peut accroître le risque perçu sans démontrer un volume d’incidents plus élevé.

Les recherches financées par un fournisseur exigent une prudence supplémentaire. Thales vend des produits de cybersécurité et de protection des données, ce qui donne à l’entreprise un intérêt commercial dans les dépenses de sécurité liées à l’IA. S&P Global Market Intelligence 451 Research a mené l’enquête, mais les lecteurs doivent néanmoins examiner son cadrage.

Cela n’invalide pas les résultats. Cela signifie que les pourcentages doivent étayer une conclusion limitée : les entreprises signalent une forte préoccupation et orientent des ressources vers une sécurité spécifique à l’IA.

Les données proviennent également de plusieurs pays et secteurs. Une banque utilisant des agents pour des transactions clients fait face à des conséquences différentes de celles d’un fabricant qui teste un assistant de rédaction interne.

Les pourcentages agrégés peuvent masquer ces différences. Le risque dépend de la sensibilité des données, du niveau d’automatisation, de la population d’utilisateurs, des obligations réglementaires et de l’autorité du modèle à agir.

Les entreprises devraient donc éviter de reproduire une liste de contrôle universelle pour la sécurité de l’IA. Un outil de rédaction à faible impact n’exige pas les mêmes contrôles qu’un agent qui modifie des comptes clients.

Une autre incertitude concerne la classification des incidents. Un attaquant peut utiliser l’IA pour rédiger un message de phishing, mais l’organisation peut enregistrer l’événement comme du phishing. L’IA a assisté l’attaque sans devenir la catégorie déclarée.

L’inverse peut également se produire. Une erreur classique d’autorisations au sein d’une application d’IA peut recevoir une étiquette IA parce que la nouvelle interface a rendu la défaillance visible.

Les chercheurs ont besoin de définitions cohérentes avant que les comparaisons deviennent fiables. Ils doivent distinguer les attaques utilisant l’IA, les attaques contre les systèmes d’IA et les défaillances causées par un usage approuvé de l’IA.

L’analyse de sécurité des agents du NIST a constaté un large consensus sur le fait que les pratiques fondamentales de cybersécurité restent pertinentes. Les répondants ont également indiqué que ces pratiques doivent être adaptées à la sécurité des agents.

Ce cadrage est plus utile que de déclarer la cybersécurité traditionnelle obsolète. L’IA hérite de risques d’infrastructure familiers tout en ajoutant de nouvelles voies d’instruction, d’accès et d’action autonome.

Il existe également un risque à réallouer les budgets trop rapidement. Les entreprises ont toujours besoin de correctifs, d’authentification multifacteur, de sauvegardes, de sécurité des e-mails et de plans de reprise testés. Les contrôles liés à l’IA ne peuvent pas compenser des fondations négligées.

Les attaquants exploitent fréquemment des faiblesses connues parce que ces méthodes restent efficaces. Ajouter une couche de surveillance de l’IA au-dessus de contrôles d’identité faibles peut donner une impression de progrès sans réduire l’exposition de base.

Les dirigeants devraient se demander comment chaque investissement modifie un résultat mesurable. Parmi les mesures utiles figurent les accès non autorisés aux données, les actions d’agents à haut risque, les violations de politiques et le temps nécessaire pour contenir un incident lié à l’IA.

Les équipes de sécurité devraient tester les affirmations des fournisseurs dans des conditions réalistes. Un produit qui détecte une injection de prompt évidente peut échouer face à des instructions cachées dans des documents professionnels ou encodées sur plusieurs étapes.

Les exercices de red teaming peuvent révéler ces faiblesses. Une équipe rouge IA teste la manière dont un système réagit à la manipulation, aux requêtes dangereuses, aux autorisations excessives et aux données inattendues.

Les tests doivent couvrir l’application complète plutôt que le seul modèle. Un modèle sûr peut devenir dangereux lorsqu’il est connecté à des outils étendus. Un modèle moins performant peut présenter peu de risques dans un flux de travail strictement limité.

La revue humaine n’est pas non plus une réponse universelle. Les réviseurs peuvent se contenter d’entériner les décisions lorsque les systèmes en génèrent trop ou lorsque les délais favorisent la vitesse.

Le bon contrôle dépend des conséquences. Les contenus à faible risque peuvent faire l’objet d’un échantillonnage. Les actions à fort impact devraient nécessiter une approbation explicite, une validation indépendante ou une limite technique empêchant l’exécution autonome.

La gouvernance de l’IA entre dans les conseils d’administration

Le risque lié à l’IA est devenu une question de gouvernance, car les contrôles techniques ne peuvent pas résoudre une responsabilité floue ou des incitations commerciales contradictoires.

Les publications publiques montrent à quelle vitesse le sujet s’est étendu. The Conference Board a constaté que la part des entreprises du S&P 500 mentionnant les risques liés à l’IA est passée de 12 % en 2023 à 83 % en 2025.

Ses recherches sur la gouvernance ont également révélé que 58 % identifiaient la cybersécurité et les violations de données comme leur risque le plus important lié à l’IA. Moins de 10 % des dirigeants interrogés ont déclaré que leur entreprise était pleinement préparée à la réglementation de l’IA.

Les divulgations de risques ne confirment pas que des incidents se sont produits. Les entreprises utilisent les documents officiels pour décrire des menaces matérielles possibles, et la prudence juridique peut encourager un langage large.

Toutefois, ce changement indique que l’IA a dépassé le cadre des équipes d’innovation. Les conseils d’administration doivent désormais examiner la supervision, l’escalade et la responsabilité du management.

Le rôle du conseil n’est pas d’approuver des modèles individuels. Les administrateurs doivent vérifier que la direction comprend où l’IA affecte les produits, les opérations, les employés et les clients.

Ils doivent également savoir quels déploiements peuvent prendre des décisions ayant des conséquences. Un assistant qui rédige des textes internes diffère d’un agent qui met à jour des prix, déplace de l’argent ou modifie des autorisations d’accès.

Les rapports de la direction devraient relier les signaux techniques à l’impact métier. Les scores de test des modèles ont peu de valeur sans explication des décisions que le système soutient.

Un rapport utile pourrait indiquer combien de systèmes d’IA peuvent accéder à des données confidentielles. Il pourrait identifier les agents disposant d’autorisations d’écriture, les constats à haut risque non résolus et les exceptions en attente d’examen.

Les conseils devraient également examiner le risque de concentration. Plusieurs applications internes peuvent dépendre d’un même fournisseur de modèles, service d’identité ou plateforme de récupération. Une seule défaillance peut alors affecter plusieurs fonctions métier.

Les dépendances vis-à-vis de tiers compliquent l’assurance. Une entreprise peut sécuriser sa propre application tout en s’appuyant sur un fournisseur qui modifie le comportement du modèle, les conditions de conservation ou les fonctionnalités d’intégration.

Les contrats peuvent établir des obligations de notification, d’audit et de traitement des données. Ils ne peuvent pas empêcher chaque changement technique. Les équipes ont toujours besoin de surveillance et de plans de continuité.

La réglementation ajoute une autre source de pression. Les différentes juridictions classent les systèmes d’IA selon leur finalité, leur secteur et leur préjudice potentiel. Une entreprise multinationale peut faire face à des exigences qui se chevauchent en matière de confidentialité, de cybersécurité, de protection des consommateurs et d’IA.

La conformité ne devrait pas devenir la seule définition de la sécurité. Un système peut satisfaire aux exigences documentaires tout en conservant des autorisations excessives ou en produisant des décisions peu fiables.

Inversement, une équipe technique peut réduire le risque de sécurité immédiat sans répondre aux obligations juridiques concernant la transparence, la discrimination ou la propriété intellectuelle.

Cette intersection explique pourquoi la peur de l’IA a dépassé toute menace familière prise isolément dans certaines enquêtes. Le risque ne réside pas dans une seule méthode d’attaque. Il s’agit d’un problème de gouvernance couvrant l’ensemble du cycle de vie de la technologie.

Les organisations ont besoin de jalons clairs avant le déploiement, mais elles ont également besoin d’un examen continu. Les modèles, les données, les utilisateurs et les intégrations évoluent après une approbation initiale.

La surveillance devrait détecter les appels d’outils inhabituels, les récupérations non autorisées, les mouvements anormaux de données et les changements de qualité des résultats. Les journaux doivent indiquer quelle identité a initié chaque action et quelles sources l’ont influencée.

Les plans de réponse aux incidents devraient inclure des scénarios spécifiques à l’IA. Les équipes ont besoin de procédures pour désactiver un agent, révoquer des identifiants, conserver les prompts et identifier les données affectées.

Elles doivent également déterminer à quel moment un résultat peu fiable devient un incident à signaler. Cette décision peut impliquer des responsables de la sécurité, de la confidentialité, du juridique et des opérations.

La formation devrait refléter les rôles des employés. Les avertissements généraux concernant les données confidentielles sont faciles à ignorer. Les développeurs, les équipes commerciales, les analystes et les dirigeants rencontrent des modes de défaillance différents.

Un développeur a besoin de conseils sur le code généré et les dépendances. Un commercial a besoin de règles concernant les données clients. Un dirigeant doit savoir reconnaître l’usurpation par deepfake et les documents décisionnels manipulés.

Une gouvernance efficace facilite donc les comportements sûrs. Les outils approuvés devraient offrir suffisamment de valeur pour que les employés n’aient pas besoin d’alternatives non officielles pour les tâches courantes.

Trois signaux montreront si les défenses des entreprises rattrapent leur retard

La prochaine phase sera mesurée à travers les autorisations des agents, des données d’incidents vérifiées et la preuve que la gouvernance modifie les décisions de déploiement.

Le premier signal est un accès plus restreint des agents. Les entreprises devraient commencer à indiquer combien d’agents d’IA disposent d’identités uniques, d’autorisations limitées et d’une approbation humaine pour les actions ayant des conséquences.

Cette mesure va au-delà du comptage des applications approuvées. Elle évalue si les entreprises comprennent l’autorité qu’elles accordent aux logiciels.

Les progrès seront visibles lorsque les organisations remplaceront les identifiants partagés et les connecteurs sans restriction. Les échecs apparaîtront à travers des agents qui héritent de privilèges étendus d’employés ou d’administrateurs.

Le deuxième signal est une meilleure classification des incidents. Les rapports de sécurité doivent distinguer les attaques assistées par l’IA, les attaques contre les systèmes d’IA et les défaillances causées par l’utilisation interne de l’IA.

Des catégories fiables permettraient aux entreprises de comparer la fréquence, la gravité et l’efficacité des contrôles. Elles permettraient également de vérifier si la crainte actuelle correspond aux préjudices observés.

Une hausse des incidents signalés ne signifierait pas automatiquement que les défenses ont échoué. Une meilleure détection produit souvent des chiffres plus élevés avant de produire des pertes plus faibles.

Le troisième signal est de savoir si la gouvernance modifie les déploiements réels. Les politiques ne comptent que lorsqu’elles limitent les données, réduisent l’autorité, retardent des mises en production dangereuses ou exigent des tests supplémentaires.

Les preuves les plus solides viendront de changements de périmètre documentés. Une entreprise peut retirer à un agent la capacité d’envoyer des messages, limiter les sources de récupération ou maintenir une approbation humaine pour les actions financières.

Un signal plus faible serait la création d’un nouveau comité de supervision dépourvu d’autorité opérationnelle. Une gouvernance incapable d’influer sur une décision de lancement aura du mal à résister à la pression commerciale.

Les entreprises devraient également surveiller la manière dont les assureurs cyber et les régulateurs traitent les incidents liés à l’IA. Des exigences plus précises obligeraient les organisations à documenter leurs contrôles et à distinguer les affirmations des capacités réellement éprouvées.

La leçon essentielle n’est pas que l’IA a vaincu la cybersécurité. C’est que les entreprises connectent des systèmes probabilistes à des données précieuses et à des outils métier de confiance plus vite que les contrôles ne mûrissent.

Ce déséquilibre explique les craintes. Les malwares, le phishing et les ransomwares sont dangereux, mais leurs modes opératoires sont familiers. L’IA introduit de l’incertitude au cœur de flux de travail que les entreprises cherchent activement à étendre.

Les responsables de la sécurité doivent désormais préserver les règles d’hygiène cyber de base tout en ajoutant l’évaluation des modèles, l’identité des agents, les contrôles des données et une responsabilisation interfonctionnelle. Négliger l’un ou l’autre crée une faille évitable.

Pour les acheteurs de technologies, les développeurs et les travailleurs du savoir, la question pratique est simple : un outil d’IA ne reçoit-il que les informations et l’autorité nécessaires à sa tâche ?

Posez cette question avant la mise en production de la prochaine intégration. Consignez la réponse, testez la limite et décidez qui peut arrêter le système lorsqu’il se comporte de manière inattendue. Ces preuves compteront davantage qu’une nouvelle promesse générale selon laquelle une organisation utilise l’IA de manière responsable.