Les entreprises sont aveugles à deux tiers de leur surface d’attaque IA, avertit Snyk

Snyk avance un chiffre frappant sur les risques liés à l’IA en entreprise : près de deux tiers de la surface d’attaque concernée peuvent échapper à la vue directe des équipes de sécurité. Cet avertissement, relayé par Google News, porte sur les agents, plugins, jeux de données et pipelines de données connectés aux activités quotidiennes. Ces composants se multiplient à mesure que les entreprises font passer leurs expérimentations d’IA en production.

Ce chiffre provient de Snyk, et non d’un audit indépendant de l’ensemble du marché des entreprises. Son analyse s’appuie sur des informations anonymisées issues de plus de 500 environnements d’entreprise associés à Snyk Evo. Cette distinction est importante. Les données offrent une vision des environnements participants, tandis que l’affirmation plus générale doit encore être validée sur d’autres plateformes et dans d’autres secteurs.

Même avec cette réserve, Snyk décrit un problème qui dépasse la télémétrie d’un seul fournisseur. Une étude de la Cloud Security Alliance a révélé que 68 % des organisations interrogées ne pouvaient pas clairement distinguer les actions d’agents IA de l’activité humaine. OWASP a par ailleurs identifié l’injection de prompts, les autorisations excessives et l’autonomie non contrôlée comme des risques majeurs pour les applications.

Le conflit central n’oppose donc pas l’adoption de l’IA à la résistance au changement. Il se situe entre un déploiement rapide et décentralisé, d’une part, et des systèmes de sécurité conçus autour d’applications connues, d’identités humaines et d’inventaires stables, d’autre part. Les entreprises autorisent davantage de logiciels à raisonner et agir, tout en perdant confiance dans leur visibilité sur les systèmes connectés à leurs données.

Cette lacune met les équipes de sécurité sous pression, mais elle concerne aussi les développeurs, les ingénieurs plateforme, les responsables des achats et les propriétaires métiers. Chaque groupe peut introduire une dépendance à l’IA. Peu d’organisations disposent d’un système unique capable de cartographier la chaîne qui en résulte, du modèle au plugin, en passant par l’identité, le jeu de données, l’API et l’action en production.

Pourquoi l’avertissement de Snyk a atteint Google News

L’affirmation la plus importante de Snyk n’est pas que l’IA crée de nouvelles vulnérabilités. C’est que les entreprises ne peuvent pas voir de manière fiable les systèmes qui les créent.

Snyk a présenté son AI Security Fabric en février 2026 comme une couche couvrant le développement logiciel et les systèmes agentiques. L’entreprise a indiqué que son approche combinerait visibilité, prévention et gouvernance tout au long du cycle de développement logiciel.

Cette annonce de produit incluait des résultats issus de l’étude 2026 State of Agentic AI Adoption de Snyk. Selon l’entreprise, son analyse couvrait des informations anonymisées provenant de plus de 500 environnements Evo d’entreprise. Snyk a indiqué que chaque modèle d’IA déployé était associé à près de trois fois plus de composants cachés, notamment des jeux de données et des outils tiers.

L’affirmation phare va plus loin. Snyk estime qu’environ deux tiers des risques IA en entreprise se situent sous la couche de modèles la plus visible. Cette partie dissimulée comprend les outils d’agents, les plugins, les dépôts connectés, les services externes et les pipelines de données que les employés relient pendant le développement ou leurs activités quotidiennes.

Ces composants ne sont pas automatiquement malveillants. Un plugin peut simplement récupérer un document, appeler une API interne ou envoyer un message approuvé. Le problème de sécurité découle de la relation entre le composant, ses autorisations, ses sources d’entrée et sa capacité à déclencher des actions en aval.

Un inventaire des modèles ne suffit pas à capturer ces relations. Deux équipes peuvent utiliser le même modèle par l’intermédiaire d’agents aux profils de risque totalement différents. L’un peut résumer des documents publics. L’autre peut lire du code source, interroger des dossiers clients et écrire des modifications dans des systèmes de production.

C’est pourquoi cette histoire mérite davantage qu’un avertissement familier sur les employés qui utilisent des chatbots non approuvés. L’IA fantôme inclut désormais des fonctions intégrées à des logiciels approuvés, des modèles déployés localement, des frameworks d’agents, des extensions de navigateur, des services d’automatisation et des identités machine. Certaines arrivent par les processus formels d’achat. D’autres apparaissent lorsqu’un employé connecte un outil supplémentaire pour terminer une tâche.

Google News offre à cette affirmation un canal de diffusion étendu, mais l’agrégation ne valide pas le chiffre sous-jacent. Les lecteurs devraient considérer l’estimation des deux tiers comme une conclusion de fournisseur fondée sur des données d’environnements liés aux clients de Snyk. La conclusion la plus solide repose sur des éléments corroborants : les entreprises peinent à inventorier le comportement des agents, leurs autorisations et les dépendances entre composants.

Cette distinction évite que l’analyse ne se transforme en marketing produit. L’estimation précise de Snyk à l’échelle du marché reste à vérifier. Le problème de visibilité lui-même est déjà étayé par plusieurs sources indépendantes et orientées normes.

La surface d’attaque IA n’est plus une liste d’applications

En pratique, la surface d’attaque se comporte désormais comme un graphe évolutif, dans lequel les modèles, identités, outils et magasins de données créent des risques par leurs connexions.

La sécurité applicative traditionnelle part d’un objet relativement stable. Une équipe possède une application, maintient son dépôt, suit ses dépendances et la déploie via une infrastructure connue. Les outils de sécurité peuvent analyser le code, les paquets, les images de conteneurs, la configuration cloud et les points de terminaison exposés.

Les systèmes natifs de l’IA ajoutent davantage d’éléments mobiles. L’analyse de Snyk sur les applications natives de l’IA décrit une chaîne d’approvisionnement pouvant inclure des modèles préentraînés, des embeddings, des agents tiers, des jeux de données et des services externes. Chaque composant peut évoluer indépendamment du code source de l’application.

Un embedding est une représentation numérique utilisée pour comparer le sens de contenus. Une base de données vectorielle peut stocker des millions de ces représentations afin de permettre la recherche. Si les autorisations ou les étiquettes de source sont erronées, un agent peut récupérer des informations auxquelles son utilisateur n’aurait jamais dû avoir accès.

La génération augmentée par récupération, souvent abrégée en RAG, fournit à un modèle des documents ou enregistrements sélectionnés avant qu’il ne produise une réponse. Le RAG peut améliorer la précision, mais il crée aussi une nouvelle frontière de confiance. La couche de récupération doit déterminer quelles sources l’agent peut rechercher et quel contenu il doit renvoyer.

Les outils créent une frontière plus conséquente. Un agent connecté aux e-mails, au contrôle de code source, à l’infrastructure cloud ou à une base de données clients peut aller au-delà de la production de texte. Selon les autorisations que les développeurs lui ont accordées, il peut lire, écrire, exécuter, approuver ou transmettre des informations.

Cela crée un décalage avec les inventaires de sécurité organisés autour des applications achetées. Une entreprise peut avoir approuvé le fournisseur de modèles et le framework d’agents. Elle peut néanmoins ne pas disposer d’un registre complet de chaque point de terminaison d’outil, compte de service, jeu de données, modèle de prompt ou plugin ajouté après le déploiement.

La chaîne peut aussi évoluer sans version traditionnelle. Un fournisseur de modèles peut modifier le comportement. Un outil tiers peut ajouter une fonction. Un jeu de données peut recevoir de nouveaux documents. Un utilisateur peut étendre un périmètre OAuth, qui détermine ce qu’une application peut consulter par le biais d’une autorisation déléguée.

Ces changements importent parce que le risque dépend des combinaisons. Un agent de synthèse disposant d’un accès en lecture seule présente un rayon d’impact limité. Donnez au même agent l’autorisation d’envoyer des e-mails, de modifier des fichiers et d’appeler un point de terminaison web sans restriction, et une entrée manipulée peut produire un résultat très différent.

La surface d’attaque comprend donc davantage que les vulnérabilités dans le code. Elle inclut les autorisations excessives, le contexte empoisonné, les identifiants exposés, la gestion non sécurisée des sorties, des règles d’approbation faibles et des journaux d’actions incomplets. Plusieurs de ces problèmes restent invisibles pour les analyseurs qui n’inspectent que les fichiers source ou les paquets logiciels connus.

Pour les équipes d’ingénierie, la documentation devient une partie du système de contrôle. Un registre consultable des décisions d’architecture, des outils approuvés, des périmètres d’autorisation et des conclusions d’incident aide les équipes à identifier des relations que les tableaux de bord individuels ne voient pas. Une base de connaissances d’ingénierie structurée peut soutenir ce travail, sans toutefois remplacer la surveillance de sécurité.

La leçon générale est simple. Un système d’IA ne peut pas être gouverné comme un unique point de terminaison de modèle. Il doit être traité comme une application connectée dont les données, outils, identités et actions restent visibles tout au long de son fonctionnement.

L’IA agentique met les contrôles d’identité sous pression

L’angle mort qui croît le plus rapidement se situe là où des logiciels autonomes héritent d’autorisations conçues pour des utilisateurs humains.

La Cloud Security Alliance a publié une étude sur l’identité des agents en mars 2026. Son enquête a révélé que 73 % des organisations s’attendaient à ce que les agents IA deviennent essentiels au cours de l’année suivante. Pourtant, 68 % ne pouvaient pas clairement distinguer les actions effectuées par des agents de celles réalisées par des personnes.

La similitude entre ce chiffre de 68 % et l’avertissement de Snyk portant sur environ deux tiers est frappante, mais ces chiffres ne mesurent pas la même chose. Snyk traite des composants cachés et des risques dans les environnements IA. L’enquête de la Cloud Security Alliance examine l’attribution d’identité et la gestion des accès.

Ensemble, ils révèlent la même faiblesse structurelle. Les organisations donnent aux identités logicielles accès aux systèmes métier plus rapidement qu’elles n’actualisent leurs pratiques d’authentification, d’autorisation et de surveillance.

Une identité machine est un identifiant utilisé par un logiciel plutôt que par une personne. Elle peut prendre la forme d’une clé API, d’un compte de service, d’un certificat, d’une identité de charge de travail ou d’un jeton OAuth. Les agents dépendent de ces identifiants pour accéder aux données et effectuer des actions.

Les systèmes d’identité humaine supposent généralement qu’une personne se connecte, reçoit un rôle défini et génère une activité associée à ce compte. Les agents compliquent ce modèle. Un agent peut agir pour plusieurs utilisateurs, appeler plusieurs outils et créer en quelques secondes une chaîne d’opérations générées par des machines.

L’attribution devient particulièrement difficile lorsqu’un agent utilise un compte de service partagé. Les journaux peuvent indiquer que le compte a modifié un enregistrement ou téléchargé un fichier. Ils peuvent ne pas identifier la demande de l’employé, la décision du modèle, le document récupéré ou l’appel de plugin à l’origine de l’action.

Il ne s’agit pas simplement d’un désagrément d’audit. Une attribution faible complique le confinement des incidents. Une équipe de sécurité ne peut pas révoquer avec certitude le bon identifiant si elle ne sait pas quel agent, utilisateur ou workflow a initié l’activité suspecte.

Les accès surdimensionnés aggravent les dégâts. Un outil conçu uniquement pour résumer des messages peut recevoir l’autorisation de les envoyer ou de les supprimer. Un assistant de code peut obtenir un accès en écriture à plusieurs dépôts alors qu’il n’a besoin que d’examiner un seul projet.

OWASP décrit cette situation comme une autonomie excessive. Ses recommandations identifient les fonctionnalités, autorisations et niveaux d’autonomie excessifs comme des causes profondes. OWASP recommande de limiter les outils disponibles, de restreindre les autorisations, d’exécuter les actions dans le contexte de l’utilisateur et d’exiger une approbation pour les opérations à fort impact.

Ces contrôles rappellent les pratiques mûres de zéro confiance. Chaque demande devrait être évaluée à l’aide d’une identité spécifique, d’une autorisation définie et du contexte actuel. Le modèle ne devrait pas décider seul si une opération est autorisée.

L’agent doit également disposer d’une identité distincte de celle de son opérateur humain. Les journaux doivent préserver le lien entre la demande de l’utilisateur, l’instance de l’agent, l’outil sélectionné, le justificatif d’accès utilisé et l’action qui en résulte. Sans cette chaîne, les entreprises peuvent collecter d’énormes volumes de télémétrie tout en restant aveugles.

C’est là que l’adoption de l’IA met l’architecture de sécurité sous pression. Les équipes métier veulent des assistants qui éliminent les validations répétitives et exécutent des tâches en plusieurs étapes. Les équipes de sécurité ont besoin de points de contrôle, d’autorisations limitées et de décisions reconstituables. Supprimer chaque point de contrôle augmente la vitesse, mais élargit aussi le rayon d’impact potentiel d’une action erronée ou manipulée.

Le conflit ne sera pas résolu en choisissant l’autonomie totale ou en interdisant les agents. Les entreprises ont besoin de niveaux d’autonomie différents selon les conséquences. La rédaction d’un résumé peut rester automatique. L’envoi de fonds, la suppression d’enregistrements, la modification d’une infrastructure de production ou la divulgation de données protégées doivent exiger des contrôles plus stricts.

Le véritable compromis oppose la vitesse au contrôle vérifiable

Les entreprises tirent de la valeur lorsque les agents franchissent les frontières entre systèmes, mais chaque connexion supplémentaire rend leur comportement plus difficile à vérifier.

L’IA agentique séduit les entreprises parce qu’elle peut relier des étapes distinctes dans un même flux de travail. Un agent de support peut lire un ticket, récupérer l’historique d’un compte, classifier l’urgence, proposer une réponse et mettre à jour le dossier client. Cette séquence peut réduire la coordination manuelle.

Cette même séquence contient plusieurs frontières de sécurité. Le ticket peut inclure du texte non fiable. L’historique du compte peut contenir des données protégées. Le modèle peut générer une instruction d’outil dangereuse. Le système client peut accepter une mise à jour aux conséquences durables.

L’injection de prompt rend ce compromis concret. Elle survient lorsqu’un contenu conçu à cette fin modifie la manière dont un modèle suit les instructions. Ce contenu peut provenir directement d’un utilisateur ou indirectement d’une page web, d’un document, d’un e-mail, d’un dépôt ou d’un enregistrement récupéré.

Une application classique sépare les commandes des données grâce à une syntaxe stricte et à des contrôles d’accès. Les modèles de langage traitent les deux sous forme de jetons dans leur contexte. Cette conception rend difficile la garantie qu’un modèle considérera toujours un texte externe comme une donnée non fiable plutôt que comme une instruction.

Les recommandations actuelles d’OWASP indiquent qu’aucune méthode infaillible de prévention de l’injection de prompt n’est connue. Elles préconisent de contraindre les comportements, de valider les formats de sortie attendus, de filtrer les entrées et les sorties, et de limiter les autorisations disponibles pour le modèle.

Ces mesures réduisent l’impact, mais elles ne créent pas de certitude. Un agent qui peut uniquement lire une collection restreinte de documents présente moins de danger qu’un agent capable d’exécuter des commandes shell. Une étape d’approbation humaine peut détecter des actions suspectes, mais seulement si l’examinateur dispose d’un contexte suffisant pour prendre une décision éclairée.

La vitesse exerce une pression sur chaque garde-fou. Les équipes peuvent accorder un accès étendu pour éviter des travaux d’intégration répétés. Elles peuvent utiliser des identifiants partagés parce que l’autorisation par utilisateur prend plus de temps à mettre en œuvre. Elles peuvent supprimer les demandes d’approbation après que les utilisateurs se sont plaints des frictions.

Le cœur de la compétition devient ainsi un compromis entre rapidité de déploiement et contrôle vérifiable. Snyk affirme que la sécurité doit devenir continue, car les systèmes d’IA évoluent trop vite pour de simples examens occasionnels. L’intérêt commercial de l’entreprise est clair, puisqu’elle vend des produits positionnés autour de cette exigence.

Les acheteurs doivent donc dissocier le diagnostic de la plateforme proposée. Une couche de sécurité unifiée pourrait améliorer la visibilité, mais aucun fournisseur n’a prouvé qu’un seul produit pouvait observer chaque modèle, déploiement local, outil de navigateur, jeu de données, identité et intégration externe dans une grande entreprise.

Les affirmations de couverture dépendent des intégrations et de la télémétrie. Un modèle cloud approuvé peut être facile à détecter. Un modèle hébergé localement sur le poste de travail d’un développeur peut ne pas l’être. Une fonctionnalité d’IA intégrée à un logiciel familier peut générer une activité qui ressemble à un trafic applicatif ordinaire.

Les connexions chiffrées et les règles de confidentialité introduisent d’autres limites. La surveillance des prompts ou des documents récupérés peut exposer des données sensibles concernant les employés et les clients. Les équipes de sécurité ont besoin d’un contexte suffisant pour détecter les abus sans créer un second dépôt d’informations confidentielles.

Les règles régionales relatives aux données ajoutent une autre contrainte. Une entreprise multinationale peut ne pas être en mesure de centraliser tous les journaux d’interaction avec l’IA. Elle peut avoir besoin d’un traitement local, de métadonnées sélectives, de contrôles de conservation et de politiques de surveillance différentes selon les juridictions.

Ces complications n’invalident pas l’avertissement de Snyk. Elles renforcent son idée centrale tout en remettant en cause toute solution simpliste. La visibilité est nécessaire, mais elle génère elle-même des coûts de conception, de confidentialité et d’exploitation.

Ce que l’affirmation des deux tiers ne prouve pas

Les données de Snyk signalent une grave lacune de gouvernance, mais elles n’établissent pas que les deux tiers de chaque environnement d’entreprise sont compromis ou exploitables.

La limitation la plus importante concerne l’échantillonnage. Snyk décrit des enseignements anonymisés tirés de plus de 500 environnements d’entreprise Evo. Les organisations utilisant cet environnement peuvent différer du marché plus large par leur taille, leurs pratiques logicielles, leur maturité en IA ou leurs priorités de sécurité.

L’entreprise n’a pas établi publiquement que son échantillon représente chaque secteur ou région géographique. Elle a également une raison commerciale de définir le problème selon des termes qui favorisent une couverture de sécurité plus étendue. Aucun de ces éléments ne rend les données fausses, mais tous deux exigent une attribution prudente.

Le « risque » est également plus large que la « vulnérabilité ». Un composant caché peut être non géré ou insuffisamment inventorié sans contenir de faille exploitable. Il devient dangereux lorsqu’il est associé à des autorisations faibles, à des données sensibles, à des entrées dangereuses ou à la capacité d’effectuer des actions conséquentes.

De même, « deux tiers » ne signifie pas que les équipes de sécurité voient exactement un tiers de chaque environnement. L’estimation résume des tendances observées dans certains environnements. Les organisations individuelles peuvent bénéficier d’une couverture bien meilleure ou bien pire.

L’expression « surface d’attaque » peut également brouiller différents problèmes. Elle peut inclure des actifs exposés à Internet, des API internes, des dépendances logicielles, des outils d’agents, des flux de données, des identités et le comportement des modèles. Les différents fournisseurs comptabilisent ces éléments de manière différente.

Une mesure indépendante exigera des définitions partagées. Les chercheurs doivent distinguer les actifs connus des actifs inconnus, les composants accessibles des composants inactifs, et l’exposition théorique des chemins d’attaque démontrés. Sans ces distinctions, les grands pourcentages attirent l’attention mais offrent des orientations opérationnelles limitées.

NIST fournit une base plus neutre avec son cadre de risque lié à l’IA. Ce cadre organise le travail autour de la gouvernance, de la cartographie, de la mesure et de la gestion des risques liés à l’IA. Il souligne également que la gestion des risques doit se poursuivre tout au long du cycle de vie du système.

La cartographie est particulièrement pertinente au regard de l’affirmation de Snyk. Une organisation doit identifier le modèle, la tâche prévue, les utilisateurs, les données, les dépendances, le contexte de déploiement et les parties concernées avant de pouvoir mesurer le risque. Un scanner ne peut pas reconstituer chaque politique ou décision de responsabilité manquante.

La mesure exige également des tests. Une entreprise peut documenter les autorisations prévues d’un agent sans jamais vérifier ses autorisations effectives en production. Elle peut répertorier les outils approuvés tout en négligeant des fonctions ajoutées par une intégration mise à jour.

La position sceptique n’est donc pas que l’angle mort est imaginaire. Elle consiste à dire que la télémétrie d’un seul fournisseur ne peut pas encore en définir la taille exacte à l’échelle du marché. Le titre doit motiver l’inventaire et les tests, et non s’y substituer.

Les responsables de la sécurité devraient demander aux fournisseurs comment ils calculent la couverture. Ils devraient exiger le dénominateur, les méthodes de détection, les environnements exclus, la fréquence de mise à jour et le processus de résolution des actifs dupliqués ou obsolètes. Un pourcentage précis sans ce contexte peut créer une fausse confiance.

Ils devraient également mesurer les résultats. Découvrir davantage de composants n’est utile que si l’organisation peut prioriser les relations dangereuses, désigner des responsables, réduire les autorisations et corriger les chemins vérifiés. Un inventaire plus vaste qui produit une file d’alertes ingérable peut devenir une autre forme d’aveuglement.

Trois signaux montreront si l’angle mort se résorbe

La prochaine phase sera mesurée par l’attribution d’identité, les inventaires de composants et des réductions vérifiées des autorisations dangereuses des agents.

Le premier signal est de savoir si les entreprises peuvent distinguer l’activité des agents de l’activité humaine dans leurs journaux. Le constat de 68 % de la Cloud Security Alliance fournit une base de référence claire, même s’il provient d’une enquête plutôt que d’une télémétrie directe.

Une amélioration signifierait que chaque action conséquente comporte une identité d’agent, une délégation utilisateur, un nom d’outil, un contexte d’autorisation et un résultat traçable. Si de futures enquêtes montrent que moins d’organisations rencontrent des difficultés d’attribution, les arguments en faveur d’une gouvernance gérable des agents deviendront plus solides.

Si le chiffre reste proche des deux tiers, la conclusion inverse s’impose. Les entreprises auront déployé davantage de flux de travail autonomes sans résoudre le problème fondamental de la responsabilité. Ce résultat renforcerait l’avertissement de Snyk selon lequel le déficit de visibilité grandit avec l’adoption.

Le deuxième signal est l’émergence de nomenclatures cohérentes des composants d’IA. Une nomenclature des composants d’IA répertorie les modèles, jeux de données, prompts, frameworks, outils, services et dépendances utilisés par un système. Elle étend le concept de nomenclature logicielle aux composants propres à l’IA.

La version utile doit rester synchronisée avec le déploiement. Un document statique créé lors de l’approvisionnement ne prendra pas en compte les outils et jeux de données connectés ultérieurement. La découverte automatisée, l’attribution de responsables, l’historique des versions et les preuves d’autorisations effectives comptent davantage que la simple production d’une liste.

L’adoption généralisée de formats d’inventaire interopérables renforcerait l’argument selon lequel les entreprises peuvent retrouver de la visibilité. La dépendance continue à des tableaux de bord propres aux fournisseurs laisserait des angles morts entre les produits de sécurité, les plateformes cloud et les environnements locaux.

Le troisième signal est de savoir si les organisations réduisent l’autonomie excessive en production. Les équipes de sécurité devraient suivre le nombre d’agents capables d’écrire des données, d’exécuter du code, d’envoyer des communications, de modifier l’infrastructure ou d’accéder à des dépôts sensibles sans approbation distincte.

Une baisse de ce nombre montrerait que les entreprises traduisent la gouvernance de l’IA en contrôles techniques. Une hausse indiquerait que les objectifs de productivité l’emportent encore sur le confinement. Les rapports d’incidents impliquant des agents surautorisés rendraient cette métrique particulièrement urgente.

Ces signaux comptent davantage que le volume de politiques d’IA publiées par les entreprises. Les politiques décrivent l’intention. Les identités, inventaires, autorisations et journaux révèlent la réalité opérationnelle.

Le titre Google News de Snyk réussit parce qu’il condense cette réalité en un avertissement mémorable. Le chiffre exact des deux tiers reste une estimation dérivée d’un fournisseur, mais le décalage sous-jacent est difficile à écarter. Les composants d’IA se multiplient plus vite que de nombreuses organisations ne peuvent les découvrir, les classifier et les gouverner.

Pour les développeurs, la question immédiate est de savoir si chaque connexion d’agent dispose d’un responsable nommé et d’une autorisation nécessaire. Pour les équipes de sécurité, il s’agit de savoir si les journaux peuvent reconstituer une action depuis la demande de l’utilisateur jusqu’au résultat en aval, en passant par la décision du modèle. Les acheteurs d’entreprise devraient exiger des preuves pour les deux.

Le prochain trimestre offre un test pratique. Choisissez un agent de production, cartographiez chaque modèle, outil, identité, jeu de données et appel externe, puis comparez cette carte aux enregistrements de sécurité existants. Si les deux vues diffèrent fortement, l’angle mort se trouve déjà au sein de l’organisation. Si elles correspondent, vérifiez que les autorisations et les contrôles d’approbation se comportent comme documenté. Google News a fourni l’avertissement ; la télémétrie d’entreprise doit désormais fournir la réponse.