Agreely et les plateformes de gestion du consentement

Si vous exploitez déjà une plateforme de gestion du consentement (CMP) telle que OneTrust, Didomi ou Osano, une question légitime se pose : Agreely fait-il double emploi, et vous faut-il les deux? Cette page y répond franchement. En résumé, une CMP et Agreely résolvent deux moitiés différentes de la même loi, et pour bien des équipes la bonne réponse est les deux. Agreely est conçu pour se placer aux côtés d'une CMP, et même derrière elle, non pour la remplacer.

La façon la plus nette de voir la distinction, c'est la portée. Une CMP gouverne le consentement aux témoins et aux traceurs sur le Web : bannières, blocage des balises et des scripts, chaînes IAB TCF. Agreely ne fait délibérément pas le travail de la bannière de témoins. Il gouverne le consentement pour les renseignements personnels que vos propres systèmes traitent, côté serveur, au point où votre code serveur touche réellement aux données. Même loi, portée différente à dessein : consentement Web et aux témoins d'un côté, consentement à l'utilisation des données de l'autre.

Deux tâches différentes

Une CMP est faite pour recueillir un signal de consentement et contrôler le navigateur. Elle affiche la bannière et le centre de préférences, analyse les témoins, cible géographiquement l'avis, et empêche les scripts, les témoins et les balises de se déclencher tant qu'une catégorie n'est pas acceptée. C'est un vrai travail au sens de la Loi 25, et c'est la porte d'entrée dont la plupart des sites Web ont besoin.

Agreely est fait pour prouver le consentement et l'appliquer là où votre serveur utilise les données. Il émet un reçu signé qu'un auditeur peut vérifier sans faire confiance à Agreely, et il répond à une seule question synchrone, en refus par défaut, directement dans votre code serveur, avant que vous n'utilisiez un renseignement personnel à une fin donnée :

Ce client a-t-il accordé cette catégorie pour cette finalité, à l'instant même?

Une CMP empêche une balise de se déclencher dans le navigateur. Agreely empêche votre traitement de facturation d'utiliser un numéro de téléphone qu'il n'a jamais été autorisé à utiliser. Ce sont des points différents dans la pile, et les deux comptent.

Côte à côte

Nous décrivons ici une « CMP type » de façon générique. Les produits diffèrent, les fonctionnalités évoluent, et le résumé ci-dessous reflète la catégorie telle qu'elle est généralement construite, non une affirmation au sujet de la version actuelle d'un fournisseur précis. Validez les détails auprès de la documentation propre à chaque fournisseur.

Une CMP type Agreely
Ce qu'elle gouverne Les témoins et les traceurs sur votre site Web (bannières, blocage des balises et des scripts, chaînes IAB TCF) Les renseignements personnels que vos propres systèmes traitent, au point d'utilisation côté serveur
Ce qu'elle optimise Recueillir le consentement et contrôler les témoins et les balises dans le navigateur Prouver le consentement et l'appliquer au point d'utilisation côté serveur
Où elle s'exécute Bannière côté client plus blocage des balises et des témoins Une vérification synchrone /v1 que votre code serveur appelle en ligne
Comment le consentement est journalisé Stocké dans la base ou le registre géré du fournisseur, signé avec une clé que le fournisseur détient Un reçu signé (justificatif vérifiable W3C, EdDSA plus clé d'accès WebAuthn) lié à des clés publiées dans un document DID
Vérifiable par un tiers sans le fournisseur? La vérification passe par le fournisseur ou son API Un auditeur peut vérifier sans faire confiance à Agreely *
Point d'application Bloque les témoins et les balises dans le navigateur Vérification en refus par défaut par cellule (customer, category, purpose) dans votre code serveur
Résistance à l'altération Base ou registre géré du fournisseur Engagements keccak256 et Merkle ancrés sur une chaîne publique (Base; réseau de test aujourd'hui)
Étendue Automatisation des demandes de droits, cartographie des données, risque fournisseur, analyse des témoins, bannières, modèles d'EFVP Rien de tout cela, à dessein

* Entièrement vrai hors ligne aujourd'hui pour les reçus attestés par l'entreprise. Un reçu signé par le citoyen n'atteint qu'une vérification hors ligne partielle tant que le chemin de vérification côté serveur n'est pas livré. Voir les réserves plus bas.

Remarquez l'asymétrie honnête de la dernière ligne : une CMP est bien plus large qu'Agreely. Les bannières de témoins, les règles géographiques, les flux de demandes de droits, la cartographie des données et l'analyse des témoins sont tous un travail réel et nécessaire, et Agreely n'en fait aucun. Agreely est délibérément étroit : une seule couche de reddition de comptes, faite pour tenir sans faire confiance au fournisseur.

Quand utiliser laquelle (souvent les deux)

  • Il vous faut une bannière de témoins, des règles géographiques, le contrôle des balises, des flux de demandes de droits ou de la cartographie de données. C'est une CMP. Agreely ne fait pas cela et ne cherche pas à le faire.
  • Il vous faut prouver, après coup, qu'une utilisation précise des données était autorisée, d'une manière qu'un régulateur ou un auditeur peut vérifier sans vous croire sur parole, et il vous faut que votre propre code refuse les données quand ce n'était pas le cas. C'est Agreely.
  • Il vous faut les deux, ce qui est courant. Laissez la CMP posséder la bannière et le navigateur, et laissez Agreely être la couche de reddition de comptes derrière elle pour les utilisations de données côté serveur qui portent le risque au sens de la Loi 25. Agreely peut se placer directement derrière une CMP.

La seule distinction honnête

La plupart des outils de consentement peuvent vous montrer un enregistrement qu'ils détiennent. La question que le principe de reddition de comptes de la Loi 25 pose vraiment, c'est de savoir si une personne qui ne fait pas confiance au fournisseur peut tout de même vérifier ce qui a été convenu. Aujourd'hui, les grandes CMP signent leurs enregistrements de consentement avec une clé qu'elles détiennent elles-mêmes, qu'il s'agisse d'un jeton à secret partagé, d'une clé de signature détenue par le fournisseur, ou d'un registre géré derrière l'API du fournisseur, de sorte que la vérification passe par le fournisseur. Agreely signe avec des clés asymétriques publiées dans un document DID, de sorte que la preuve tient d'elle-même. Voilà la ligne, et c'est pourquoi Agreely existe comme couche distincte plutôt que comme une bannière de plus.

Réserves honnêtes

Nous nous tenons à la même honnêteté au sujet de nos propres limites que celle que nous attendons de toute comparaison. La page des frontières honnêtes dresse la liste complète des affirmations qu'Agreely refuse de faire.

Là où Agreely est honnête au sujet de ses propres limites

Deux réserves gardent cette page véridique. L'ancrage sur la chaîne fonctionne aujourd'hui sur Base Sepolia, un réseau de test; l'ancrage sur le réseau principal n'est pas encore en service. Et « vérifiable sans faire confiance à Agreely » est entièrement vrai hors ligne aujourd'hui pour les reçus attestés par l'entreprise, tandis qu'un reçu signé par le citoyen n'atteint qu'une vérification hors ligne partielle tant que le chemin de vérification côté serveur n'est pas livré. Les deux sont énoncées clairement, non cachées.

Ensuite