How We Built a System That Scans 100,000 Websites for Cookie Consent Violations

La vérification automatisée de la conformité du consentement semble simple jusqu'à ce que vous essayiez de la construire. L'approche naïve -- récupérer une page, vérifier les cookies, chercher une bannière -- manque l'essentiel de ce qui compte. Les violations de consentement sont comportementales, pas structurelles. Elles se manifestent dans le timing de l'exécution des scripts, la séquence des requêtes réseau, la réponse des éléments d'interface aux interactions utilisateur et la persistance de l'état à travers les chargements de page. Vous ne pouvez évaluer rien de tout cela sans exécuter un vrai navigateur, interagir avec la page comme le ferait un humain et enregistrer ce qui se passe réellement au niveau réseau.

Cet article décrit comment nous avons construit le moteur de scan derrière GDPR Monitor, les défis d'ingénierie qui ont consommé la majeure partie de notre temps, les décisions architecturales que nous avons prises et pourquoi, et les limitations dont nous sommes honnêtes. Si vous travaillez sur la conformité web, l'automatisation de navigateur ou la mesure web à grande échelle, il devrait y avoir quelque chose d'utile ici.

Vue d'ensemble du pipeline

Chaque scan passe par six étapes. Comprendre le pipeline est un contexte nécessaire pour les défis spécifiques qui suivent.

Étape 1 : Lancement du navigateur et isolation. Une instance Chromium propre démarre avec zéro état -- pas de cookies, pas de localStorage, pas de cache, pas de service workers. C'est la garantie de salle blanche qui rend la mesure pré-consentement significative. Nous configurons un viewport standard, des en-têtes User-Agent et Accept-Language réalistes correspondant au pays cible, et des drapeaux de navigateur standard. Chaque scan obtient son propre processus de navigateur ; il n'y a pas de fuite d'état entre les scans. Étape 2 : Navigation et instantané pré-consentement. Le scanner navigue vers l'URL cible, attend que la page atteigne un état stable (réseau inactif, DOM stabilisé) et capture tout ce qui s'est passé : cookies définis, requêtes réseau effectuées (avec URL complète, timing et métadonnées de réponse), domaines tiers contactés et une capture d'écran pleine page. Cet instantané répond à la question fondamentale : qu'a fait ce site web avant que l'utilisateur ait la moindre opportunité de consentir ? Étape 3 : Détection CMP et identification de bannière. Le scanner tente d'identifier la plateforme de gestion du consentement et de localiser la bannière de consentement, le bouton d'acceptation et le bouton de refus. Cela utilise un système de détection multicouche décrit en détail ci-dessous. Étape 4 : Interaction de consentement. Le scanner interagit avec la bannière -- clique sur accepter pour le flux standard, clique sur refuser pour le test du flux de refus. Il attend que la page se stabilise après l'interaction, en tenant compte des animations, de la réévaluation des scripts et du déclenchement retardé des balises. Étape 5 : Instantané post-consentement et analyse différentielle. Un second instantané complet capture l'état après l'interaction de consentement. La comparaison des instantanés pré-consentement et post-consentement révèle ce qui a changé : nouveaux cookies, nouvelles requêtes de suivi, état de consentement dans les API CMP. Étape 6 : Analyse, classification et génération de rapport. Les données brutes alimentent les modules d'analyse : classification des cookies contre notre base de données, correspondance des traceurs avec des modèles connus, évaluation de la durée de vie des cookies, audit d'accessibilité de la bannière, validation du Google Consent Mode, détection de signaux d'empreinte et scoring de risque. La sortie est un rapport structuré avec des constats, des artefacts de preuve et un score de risque composite.

Chaque étape produit des preuves horodatées stockées de manière durable. Tout constat peut être retracé jusqu'à des requêtes réseau spécifiques, des entrées de cookies ou des captures d'écran.

Défi 1 : Détection CMP -- 45 plateformes, variations infinies

La gestion du consentement n'est pas standardisée. Il n'y a pas d'attribut HTML universel, pas d'API JavaScript obligatoire, pas de structure DOM cohérente qui dit « ceci est une bannière de consentement ». Il y a 45 CMP distincts dans notre bibliothèque de détection, chacun avec sa propre structure DOM, ses signatures de scripts, ses variables globales JavaScript et ses patterns d'interaction. Au-delà de ceux-ci, 34,7 % des bannières que nous avons détectées dans notre étude de 97 304 sites étaient génériques ou non identifiées -- implémentations personnalisées, fournisseurs régionaux ou solutions minimales ne correspondant à aucune signature CMP connue.

Notre détection utilise une approche multicouche basée sur la confiance :

Couche 1 : Détection de signature de script

Le scanner vérifie la présence de scripts CMP connus par pattern d'URL et variables globales JavaScript. Cookiebot, par exemple, se charge depuis `consent.cookiebot.com` et expose `window.Cookiebot`. OneTrust se charge depuis `cdn.cookielaw.org` et expose `window.OneTrust`. Chaque CMP a des patterns de chargement caractéristiques qui peuvent être détectés avant d'examiner le DOM.

Cette couche est rapide et à haute confiance quand elle correspond. Mais elle a une limitation critique : elle vous dit quel CMP est présent sur la page, pas nécessairement quel CMP est responsable de la bannière de consentement. Un site pourrait charger PiwikPRO pour l'analyse (qui inclut un composant CMP) tout en utilisant tarteaucitron pour la gestion réelle du consentement. Détecter les deux scripts est facile ; savoir lequel contrôle la bannière est plus difficile.

Couche 2 : Correspondance de sélecteurs vérifiés

Pour chaque CMP connu, nous maintenons un ensemble curé de sélecteurs CSS qui identifient de manière fiable le conteneur de la bannière, le bouton d'acceptation et le bouton de refus. Ce sont des sélecteurs que nous avons validés à travers plusieurs versions et configurations de chaque CMP. Quand un CMP est détecté en couche 1 et que ses sélecteurs vérifiés correspondent à des éléments dans le DOM, nous avons une haute confiance tant dans l'identification du CMP que dans les cibles d'interaction de la bannière.

Couche 3 : Correspondance de sélecteurs compatibles

Un ensemble plus large de sélecteurs qui fonctionnent à travers de nombreuses versions d'un CMP mais sont moins précis. Ceux-ci gèrent les cas où un CMP a été personnalisé, thématisé ou exécute une version non couverte par nos sélecteurs vérifiés. Ils échangent la précision contre la couverture.

Couche 4 : Heuristiques génériques

Pour les 34,7 % de bannières non associées à un CMP connu, nous recourons à la détection heuristique. Le scanner cherche :

• Des éléments à position fixe ou sticky en bas ou en haut du viewport
• Des éléments contenant des mots-clés liés au consentement dans plusieurs langues (« cookies », « consentement », « confidentialité », « akzeptieren », « accepter », « aceptar », etc.)
• Des boutons avec des libellés d'action de consentement courants (« Tout accepter », « Tout refuser », « Gérer les préférences » et équivalents)
• Des patterns structurels typiques des dialogues de consentement : arrière-plans d'overlay, conteneurs modaux, boutons de fermeture

Cette couche attrape de nombreuses implémentations personnalisées mais est intrinsèquement moins fiable. Une bannière promotionnelle à position fixe ou une inscription à une newsletter peut ressembler structurellement à un dialogue de consentement.

Couche 5 : Sondage d'API CMP

Certains CMP exposent des API JavaScript -- notamment l'API IAB Transparency and Consent Framework (TCF) via `__tcfapi`. Nous sondons ces API pour à la fois vérifier la détection CMP et lire l'état de consentement programmatique, que nous comparons plus tard avec le comportement observé du navigateur.

Le modèle de confiance

Plutôt que de traiter la détection comme binaire (trouvé/non trouvé), nous attribuons des scores de confiance basés sur les couches qui ont correspondu et avec quelle force. Un site où nous détectons un script CMP, faisons correspondre des sélecteurs vérifiés et trouvons une API TCF obtient une haute confiance. Un site où seules les heuristiques génériques ont déclenché obtient une confiance moindre. Ce score de confiance alimente notre classification des risques -- une confiance de détection moindre signifie que les constats sont plus susceptibles d'être classés comme non concluants plutôt que définitifs.

Le modèle de confiance est la raison pour laquelle la mauvaise identification de CMP, bien qu'elle se produise, ne biaise pas systématiquement nos résultats. Quand la détection est ambiguë, nous le disons, plutôt que de forcer une classification.

Défi 2 : Le flux de refus -- Pourquoi « cliquer et vérifier » est étonnamment difficile

Tester un bouton de refus semble simple : le trouver, cliquer dessus, vérifier si les cookies ont disparu. En pratique, chaque étape est semée de problèmes de timing, de comportement asynchrone et de particularités spécifiques aux plateformes.

Trouver le bouton de refus. Tous les boutons de refus ne sont pas étiquetés « Refuser ». Ils peuvent dire « Tout décliner », « Refuser », « Uniquement les cookies nécessaires », « Gérer les paramètres » (menant à une deuxième couche où le refus est possible), ou des équivalents dans des dizaines de langues. Certains CMP placent l'option de refus dans un emplacement visuel différent, à une taille différente ou dans une couleur différente de l'option d'acceptation. Certains la cachent derrière un lien « Plus d'options » ou « Personnaliser ». Notre scanner maintient un ensemble multilingue de patterns d'action de refus et détecte aussi les options de refus en deuxième couche lorsque la première couche n'offre qu'accepter et personnaliser. Attendre le bon moment. Après avoir cliqué sur refuser, la page peut subir des changements significatifs : la bannière se ferme (souvent avec une animation), le CMP déclenche des callbacks d'état de consentement, les gestionnaires de balises réévaluent leurs règles et des scripts peuvent être chargés ou déchargés. Vérifier les cookies trop tôt capture l'état de transition. Vérifier trop tard manque le suivi transitoire qui se déclenche et se termine rapidement. Nous utilisons une attente multi-signal : inactivité réseau, stabilité DOM et un plancher de délai minimum, calibrés empiriquement à travers des centaines de configurations CMP. Le test de rechargement et la réapparition du consentement. L'étape de rechargement est ce qui a révélé la réapparition du consentement comme phénomène. Nous ne cherchions pas à la trouver -- notre test de flux de refus original ne vérifiait que l'état post-refus immédiat. Mais pendant le développement, nous avons remarqué des sites qui semblaient propres après le refus mais avaient des cookies de suivi quand nous vérifiions après un rechargement de page. Le débogage initial a supposé un problème de timing du scanner. Des investigations supplémentaires ont confirmé que c'était réel : des scripts tiers redéfinissant des cookies à chaque chargement de page indépendamment de l'état de consentement.

Nous avons ajouté la détection explicite de réapparition au pipeline : après le flux de refus, le scanner recharge la page, attend la stabilité et compare l'inventaire de cookies avec l'instantané post-refus. Tout cookie supprimé par le refus et réapparaissant après le rechargement est signalé comme réapparition. Cela a capturé 1 642 sites avec 4 932 cookies réapparaissants -- un constat qui aurait été invisible sans l'étape de rechargement.

Le sondage `waitForScriptIdentifiedCMP`. Certains CMP se chargent de manière asynchrone et ne rendent pas leur bannière avant plusieurs secondes après le chargement initial de la page. Si le scanner passe à l'étape de refus avant que le CMP ne se soit initialisé, il manque soit la bannière entièrement, soit interagit avec une interface partiellement chargée. Nous avons implémenté un mécanisme de sondage qui attend que l'API JavaScript du CMP devienne disponible (par ex., `__tcfapi` pour les CMP basés sur TCF, le global `Cookiebot` pour Cookiebot) avant de continuer. Cela ajoute de la latence par scan mais réduit significativement les faux négatifs dus au chargement asynchrone du CMP.

Défi 3 : Saturation du pipeline à grande échelle

Scanner 97 304 sites web n'est pas un travail pour une seule machine. Chaque scan lance un processus Chromium, navigue vers un site web, intercepte et classifie des centaines de requêtes réseau, prend plusieurs captures d'écran et exécute des modules d'analyse. Un seul scan prend 30 à 90 secondes selon la complexité du site. À 15 scans simultanés par worker, la gestion des ressources devient la préoccupation d'ingénierie principale.

L'architecture à sémaphores

Nous utilisons un modèle de concurrence basé sur des sémaphores pour limiter le nombre de processus Chromium simultanés par worker. Chaque worker a un sémaphore fixe (15 slots dans notre configuration de production). Un scan acquiert un slot avant de lancer son navigateur et le libère à la fin. Cela empêche l'épuisement de la mémoire -- 15 instances Chromium avec interception complète des requêtes consomment déjà une quantité significative de RAM -- et fournit une contre-pression contre la file d'attente Redis.

L'exemption de requête de document

Tôt dans le développement, nous avons rencontré un problème de débit : notre logique d'interception des requêtes (qui inspecte chaque requête pour la sécurité SSRF -- bloquant les requêtes vers les plages d'IP privées, les réseaux internes et d'autres cibles potentiellement dangereuses) ajoutait de la latence à chaque chargement de ressource, y compris la requête du document principal. Puisque l'URL du document a déjà été validée avant le début du scan, nous avons ajouté un contournement en chemin rapide : les requêtes de type document vers l'URL cible pré-validée sautent le pipeline d'interception complet. Cette optimisation apparemment mineure a eu un impact significatif sur le débit global car la requête de document bloque tout le reste.

Préchauffage DNS

La première requête vers un nouveau domaine entraîne une résolution DNS qui, sur notre infrastructure, pouvait ajouter 50 à 200 ms par domaine. Avec le site moyen contactant 10,4 domaines tiers (et certains en contactant jusqu'à 171), le temps de résolution DNS s'accumulait significativement. Nous avons implémenté un préchauffage DNS utilisant un cache de résolveur DNS local Unbound : avant chaque scan, nous résolvons le domaine cible et préchauffons le cache. L'instance Unbound sert des réponses mises en cache pour les résolutions suivantes au sein du scan, réduisant le surcoût DNS par domaine à moins d'une milliseconde.

Sécurité SSRF à grande échelle

Chaque requête interceptée par le scanner est vérifiée contre un ensemble de règles de sécurité avant d'être autorisée à continuer. Les requêtes vers des plages d'IP privées (RFC 1918, RFC 4193, link-local, loopback) sont bloquées. Cela empêche un site cible malveillant d'utiliser le scanner comme vecteur SSRF pour sonder les réseaux internes.

Le défi à grande échelle était de distinguer les blocages SSRF authentiques de la saturation des sémaphores. Quand les 15 slots de sémaphore sont utilisés et qu'un scan ne peut pas acquérir un slot, le timeout résultant ressemble superficiellement à une requête bloquée pour des raisons de sécurité. Nous avons ajouté une catégorisation explicite des erreurs pour distinguer « bloqué parce que la cible a résolu vers une IP privée » de « bloqué parce que le scanner est à pleine capacité ». C'était essentiel pour la surveillance opérationnelle et pour une classification précise des échecs de scan.

Défi 4 : Détection d'évasion de bot

Pendant l'étude, nous avons identifié 137 sites web qui semblent cacher délibérément leur bannière de consentement aux scanners automatisés. La bannière est servie aux visiteurs humains mais supprimée quand le site détecte des caractéristiques de navigation automatisée.

Le mécanisme le plus courant que nous avons identifié implique l'option de configuration `isAcceptAllForBots` du plugin WordPress RCB (Real Cookie Banner). Quand elle est activée, ce paramètre détecte les navigateurs automatisés (via `navigator.webdriver`, des heuristiques de user-agent ou des signaux comportementaux) et soit accepte automatiquement le consentement en leur nom, soit cache la bannière entièrement. L'intention, telle que documentée par le plugin, est d'empêcher les visiteurs automatisés de recevoir un dialogue de consentement avec lequel ils ne peuvent pas interagir de manière significative. L'effet est que les scanners de conformité -- et les auditeurs réglementaires utilisant des outils automatisés -- voient un site qui semble ne pas avoir de mécanisme de consentement, alors que les visiteurs humains voient une bannière de consentement complète.

C'est un problème de transparence. Si le mécanisme de consentement d'un site web n'est visible que pour les visiteurs humains, il ne peut pas être audité à grande échelle. Nous signalons ces sites séparément dans nos résultats car le constat est qualitativement différent de « aucune bannière détectée ». Le site a une bannière ; il choisit de ne pas nous la montrer.

Nous détectons l'évasion de bot par une combinaison de signaux : la présence de configurations connues de détection de bot dans les paramètres CMP (accessibles via l'inspection JavaScript), les écarts entre ce que le DOM montre et ce que l'API du CMP rapporte, et dans certains cas par la comparaison des résultats de scan automatisé avec une vérification manuelle.

Le chiffre de 137 est certainement un sous-dénombrement. Nous ne pouvons détecter l'évasion de bot que lorsque nous pouvons identifier le mécanisme. Les sites utilisant une détection de bot plus sophistiquée ou personnalisée peuvent échapper avec succès à la fois à notre scanner et à notre détection d'évasion.

Défi 5 : Mauvaise identification de CMP

Un site peut charger plusieurs scripts qui ressemblent à des plateformes de gestion du consentement. PiwikPRO inclut un composant CMP mais est principalement une suite d'analyse. Certains sites WordPress chargent Complianz aux côtés d'un plugin d'analyse séparé qui a des fonctionnalités similaires à un CMP. Les sites d'entreprise peuvent avoir des restes d'un ancien CMP toujours en chargement aux côtés du CMP actuel.

La détection naïve -- « si nous voyons le script, c'est le CMP » -- produit des identifications erronées qui se propagent en cascade vers une interaction de bannière incorrecte. Si le scanner identifie PiwikPRO comme le CMP et essaie d'utiliser les sélecteurs de bannière de PiwikPRO, il peut manquer la vraie bannière tarteaucitron qui contrôle le consentement sur le site.

Notre approche basée sur la confiance résout cela en classant les candidats CMP. Quand plusieurs CMP potentiels sont détectés :

1. Nous vérifions lequel a une bannière visible dans le DOM (script présent mais pas de bannière signifie probablement inactif ou utilisation non-CMP).

2. Nous vérifions lequel expose une API CMP active (par ex., un `__tcfapi` fonctionnel ou équivalent).

3. Nous préférons le CMP dont les sélecteurs vérifiés correspondent à des éléments DOM visibles à celui qui n'est détecté que par l'URL du script.

Cette heuristique n'est pas parfaite, mais elle a résolu les cas de mauvaise identification les plus courants que nous avons rencontrés pendant le développement et les tests.

Limitations

Aucun scanner automatisé ne réplique parfaitement chaque expérience de navigation humaine. Ce sont les limitations connues :

Bannières dépendantes du GeoIP. Certains CMP, notamment CookieYes, servent des expériences de consentement différentes basées sur la géolocalisation IP du visiteur. Nos scans proviennent d'emplacements réseau spécifiques en Europe. Un site qui montre une bannière de consentement aux visiteurs de France mais pas aux visiteurs de l'extérieur de l'UE montrera des résultats différents selon l'origine du scan. Nous ne scannons pas actuellement chaque site depuis chaque pays de l'UE. Shadow DOM fermé. Certains CMP rendent leur bannière à l'intérieur d'un shadow DOM fermé, inaccessible aux requêtes DOM standard via `document.querySelector`. Le CMP de Transcend utilise cette approche. Notre scanner peut détecter l'élément hôte du shadow mais ne peut pas inspecter son contenu pour trouver les boutons d'acceptation/refus. Ces sites finissent typiquement comme non concluants dans nos résultats. Noms de classes dynamiques et obfuscation. Certains CMP, notamment Admiral, utilisent des noms de classes générés dynamiquement qui changent à chaque chargement de page. La détection basée sur les sélecteurs échoue pour ceux-ci car les sélecteurs ne sont pas stables d'une visite à l'autre. Nous recourons aux heuristiques génériques, mais la confiance est moindre. Applications monopage. Les SPA qui gèrent l'état de consentement entièrement en JavaScript côté client et chargent le mécanisme de consentement après des changements de route initiaux (plutôt qu'au chargement initial de la page) sont plus difficiles à évaluer. Notre scanner navigue vers l'URL et attend que la page se stabilise, mais ne simule pas la navigation intra-application. Une bannière de consentement qui n'apparaît qu'après que l'utilisateur navigue dans la SPA peut être manquée. Couverture linguistique. Notre détection de bouton de refus utilise la correspondance de texte à travers un ensemble de langues supportées, mais nous ne couvrons pas chaque langue de l'UE de manière égale. Une bannière en maltais ou en estonien peut avoir des libellés de bouton de refus que notre correspondance de texte ne reconnaît pas, menant à un échec du test de flux de refus (bien que la bannière elle-même puisse toujours être détectée par des heuristiques structurelles). Cas limites de timing. Un script qui se déclenche 30 secondes après le chargement de la page sera manqué par un scan qui attend 15 secondes l'inactivité réseau. Nous utilisons des délais d'attente généreux, mais la longue traîne du comportement asynchrone est intrinsèquement difficile à capturer complètement.

Ces limitations contribuent à notre taux de 14,9 % non concluant.

L'infrastructure

L'infrastructure de scan en production consiste en :

• Moteur de scan : Une application Go utilisant chromedp comme client CDP pour l'automatisation Chromium. Go a été choisi pour son modèle de concurrence (les goroutines et les channels correspondent naturellement à l'orchestration de scans parallèles), ses caractéristiques de performance et sa simplicité de déploiement (binaire statique unique).
• Runtime navigateur : Chromium headless lancé par scan via CDP. Chaque scan obtient un processus de navigateur frais sans état partagé.
• File d'attente : File de travail adossée à Redis distribuant les URL aux workers de scan. Redis gère la distribution des tâches, le suivi de la progression et la limitation de débit.
• Base de données : PostgreSQL pour les résultats de scan durables, les constats, les métadonnées de preuves et toutes les données structurées. Les scans, constats, cookies, requêtes et sorties d'analyse sont tous stockés de manière relationnelle.
• Cache DNS : Résolveur local Unbound fournissant des résolutions DNS mises en cache et une résolution sûre contre le SSRF.
• Stockage des preuves : Les captures d'écran, fichiers HAR et rapports PDF sont stockés comme artefacts durables liés aux enregistrements de scan.

Pour l'étude de 97 304 sites, nous avons traité 114 748 URL candidates (97 304 complétées avec succès) sur environ 2,5 jours en utilisant 3 instances de serveur exécutant des workers de scan en parallèle. Chaque serveur exécutait plusieurs processus worker avec 15 slots de scan simultanés chacun. Le débit de pointe était d'environ 25 à 30 scans complétés par minute par serveur.

Le goulot d'étranglement principal n'était pas le CPU ou la mémoire mais le réseau : chaque scan génère des centaines de requêtes sortantes (vers le site cible et ses ressources tierces), et la bande passante agrégée et le nombre de connexions à travers tous les scans simultanés saturaient la capacité réseau disponible avant que d'autres ressources ne soient épuisées.

Défis ouverts et travaux futurs

Plusieurs problèmes restent non résolus ou partiellement résolus :

Localisation des bannières de consentement. Notre correspondance de texte couvre les principales langues de l'UE mais est incomplète pour les communautés linguistiques plus petites. Étendre la couverture nécessite non seulement d'ajouter des traductions mais aussi de valider que les sélecteurs et les patterns d'interaction fonctionnent correctement avec les versions localisées des CMP. Surveillance longitudinale. Notre architecture actuelle est optimisée pour le scan ponctuel. Détecter les changements dans le comportement de consentement au fil du temps -- un site s'est-il amélioré après une action d'application ? Une mise à jour CMP a-t-elle corrigé une classe d'échecs de flux de refus ? -- nécessite des scans répétés avec analyse différentielle, ce qui est architecturalement différent de l'évaluation ponctuelle. Benchmarking de conformité CMP. Nous avons les données pour évaluer les taux de conformité par CMP (Cookiebot est-il associé à une meilleure conformité que OneTrust ?), mais démêler la qualité du CMP de la qualité de configuration de l'opérateur du site est méthodologiquement complexe. Un CMP plus souvent déployé par de grandes entreprises avec des équipes de confidentialité dédiées paraîtra mieux en agrégé même si l'outil lui-même n'est pas plus conforme. Vérification de l'état de consentement en temps réel. Le scanner actuel fonctionne en mode batch. Intégrer la vérification du consentement dans les pipelines CI/CD ou la surveillance en temps réel nécessite un mode de scan plus rapide et plus léger qui sacrifie une certaine profondeur de preuve pour la vitesse. Nous explorons cela.

L'API

Le même moteur de scan décrit dans cet article est disponible via l'API publique de GDPR Monitor. Vous pouvez soumettre des demandes de scan de manière programmatique, interroger les résultats et récupérer des constats structurés et des artefacts de preuve. L'API retourne les mêmes données que notre interface affiche : instantanés pré-consentement, inventaires de cookies, résultats de détection CMP, résultats de flux de refus, scores de risque et chaînes de preuves complètes.

Si vous construisez des outils de conformité, intégrez des vérifications de confidentialité dans des pipelines CI/CD, menez vos propres recherches ou intégrez la surveillance dans un programme de confidentialité, l'API fournit l'accès à l'analyse comportementale du consentement sans avoir besoin de construire et maintenir votre propre infrastructure d'automatisation Chromium.

---

Essayez par vous-même. La documentation de l'API est disponible sur gdprmonitor.eu/developers/api. Soumettez une URL unique ou intégrez la surveillance automatisée de la confidentialité dans votre workflow.