Pourquoi les accès martech deviennent un enjeu de sécurité

Un outil marketing peut fournir à une entreprise des informations sur les acheteurs tout en accédant aux propres données de l’entreprise. Lorsque l’outil se connecte à des systèmes contenant des dossiers clients, des données de pipeline, des tickets de service, des e-mails ou des communications internes, ces autorisations font partie de la décision d’achat. Les dirigeants doivent évaluer la valeur commerciale des informations auxquelles un fournisseur peut accéder en parallèle de la valeur du service qu’ils achètent.

Clark Barron, fondateur de Blackout, affirme que certains fournisseurs de technologies marketing utilisent les informations CRM et internes de leurs clients dans des produits de données commerciaux. Blackout fournit des renseignements sur les menaces GTM grâce à une analyse forensique des logiciels marketing ; l’entreprise en tire donc un bénéfice commercial lorsque les acheteurs considèrent les comportements cachés des logiciels comme un risque nécessitant une enquête. L’affirmation de Barron est suffisamment grave pour mériter un examen, mais elle exige des preuves permettant de retracer les données depuis le système d’un client, via le fournisseur, jusqu’à un produit mis à la disposition d’un autre client.

Le coût en données d’une intégration marketing

Les achats marketing commencent par un résultat métier attendu. Chaque achat soulève une question pratique sur les informations ou les actions que le logiciel fournit. Une intégration soulève une autre question : à quelles informations de l’entreprise le fournisseur doit-il accéder ? Une connexion CRM peut exposer des champs clients et pipeline dans le cadre de ses autorisations, tandis que des connexions à des systèmes de support ou de communication peuvent exposer des informations dans les périmètres accordés à l’application. Les achats doivent identifier l’objectif de chaque autorisation importante et les règles qui encadrent son usage ultérieur.

Le problème dépasse les données personnelles. Le statut du pipeline, les demandes des clients, les problèmes de support et les discussions internes peuvent avoir une valeur commerciale lorsqu’un système connecté est autorisé à les lire. Les dirigeants doivent donc classifier les informations métier sensibles lors de l’examen d’une intégration. Ce sont les autorisations réellement accordées à chaque application qui déterminent l’exposition.

L’accès martech est une décision de sécurité et de renseignement concurrentiel

Chris Penn, cofondateur et chief data scientist de Trust Insights, décrit un angle mort dans la manière dont les marketeurs envisagent les logiciels connectés. « [Les marketeurs] ne se disent jamais : “Tiens, cette chose interagit avec mes données. Je me demande ce qu’elle fait de mes données.” », a déclaré Penn. Son observation établit une distinction utile entre le choix d’un fournisseur et la gouvernance de l’accès aux données accordé à son logiciel.

Barron s’interroge sur la raison pour laquelle un fournisseur de données d’intention aurait besoin d’un accès étendu aux propres données d’un client pour fournir son service. Cette question ne démontre pas un usage abusif. Elle donne aux achats un test concret : chaque autorisation significative devrait avoir un objectif opérationnel que l’acheteur peut identifier.

Le déficit de vérification rend le risque difficile à chiffrer

La documentation et les contrats des fournisseurs décrivent les comportements promis ou autorisés. Un acheteur a néanmoins besoin de preuves sur ce qu’une intégration installée envoie ou reçoit réellement. Barron affirme que Blackout utilise une analyse forensique pour comparer les descriptions des fournisseurs avec le comportement du logiciel après installation. Il affirme avoir analysé « plus de 700 fournisseurs ».

Il formule également une affirmation générale sur le marché : « Il existe quelques plateformes d’analytics, pas d’attribution, mais des plateformes d’analytics qui sont aussi propres que possible ; mais dès que vous entrez dans le domaine des véritables logiciels marketing, comme les fournisseurs ABM, les fournisseurs de données d’intention, tout cela, la désanonymisation, absolument pas. Non. Personne n’est clean. » Cette caractérisation de l’ensemble du marché ne doit pas être traitée comme une conclusion sans preuves étayant la population testée, la méthodologie et le sens du mot « clean ». Cette affirmation ne peut justifier une enquête plus approfondie qu’après examen de sa base factuelle.

Barron donne un exemple plus précis impliquant un fournisseur non nommé de désanonymisation. Il dit avoir trouvé du code source qui contactait deux serveurs différents selon que le logiciel détectait ou non des signes d’inspection. Il affirme que le tracking était désactivé pendant l’analyse automatisée ou l’audit de conformité, et qu’il fonctionnait lorsque le code détectait ce qui semblait être un visiteur ordinaire. Barron a qualifié cela de « véritable dispositif de contournement dans le code source ». Un tel comportement, s’il était établi de manière indépendante, rendrait certains résultats d’inspection moins représentatifs du fonctionnement ordinaire.

Barron formule une accusation plus large sur l’aval de la chaîne. « [Ils] prennent toutes vos données CRM, toutes vos communications internes, chaque octet de données qu’ils peuvent obtenir sur votre entreprise, les blanchissent via leurs propres machines d’agrégation, puis les revendent simplement à vos concurrents », a-t-il déclaré à propos des fournisseurs de données d’intention. Établir cette accusation exigerait des preuves retraçant les informations clients à travers l’agrégation jusqu’à un produit commercial accessible à un concurrent.

Barron affirme également : « Leurs tableaux de bord d’attribution commencent à leur mentir. Leurs coûts d’acquisition client commencent à exploser, et ils ne savent pas pourquoi. » Il soutient en outre que des entreprises peuvent finir par subventionner les coûts d’acquisition client de leurs concurrents. Les dirigeants ont besoin de preuves reliant des pratiques de données spécifiques à des erreurs d’attribution ou à des coûts d’acquisition client avant de considérer ces effets allégués comme établis.

La question d’achat plus restreinte ne dépend pas de ces accusations plus larges. Lorsqu’une intégration peut accéder à des informations commercialement sensibles, l’acheteur doit comprendre ses autorisations, les usages autorisés et son comportement observable. Ce sont ces faits qui déterminent l’exposition créée par l’intégration. Les affirmations de Barron soulèvent des questions à examiner ; elles n’apportent pas les réponses.

Les connexions IA étendent la question de l’accès

Model Context Protocol (MCP) est un protocole permettant de connecter des applications d’IA à des outils externes et à des sources de données. « Quand vous installez un MCP, vous vous connectez à l’ordinateur de quelqu’un d’autre », a déclaré Penn. Penn soutient que des instructions MCP inconnues peuvent créer un risque d’exfiltration de données, c’est-à-dire que des données quittent un environnement sans l’autorisation prévue. Son avertissement identifie un scénario à examiner du point de vue de la sécurité, plutôt qu’une preuve que cette exfiltration est répandue.

Les intégrations d’IA font de l’examen des accès un élément à la fois de la gouvernance technologique et des achats. Un acheteur qui évalue une connexion IA a besoin de preuves sur ce à quoi la connexion peut accéder et sur ce qu’elle échange réellement. Ce sont ces preuves qui déterminent si la valeur métier de l’intégration justifie l’accès aux informations qui lui est accordé.

Points clés

Auditez le coût en données des intégrations : Les équipes achats doivent associer chaque autorisation martech à un objectif métier clair et classifier les données CRM, pipeline, support et communications qu’elle expose.
Traitez l’accès martech comme une décision de sécurité : Les équipes sécurité et achats doivent examiner si l’accès demandé par une intégration est nécessaire au service fourni et comment le fournisseur est autorisé à utiliser ces informations.
Vérifiez indépendamment le comportement du logiciel : Les contrats et la documentation décrivent le comportement attendu, tandis qu’une inspection technique peut tester ce qu’une intégration envoie et reçoit réellement. Les affirmations générales sur l’usage abusif des données exigent des preuves retraçant les informations depuis les systèmes clients jusqu’aux produits en aval.
Appliquez le même niveau d’examen aux connexions IA : Les équipes technologiques qui évaluent MCP et d’autres intégrations d’IA doivent déterminer à quels systèmes chaque connexion peut accéder et quelles données elle échange avant d’accorder un accès en production.