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, règles géographiques mondiales. Le cœur d'Agreely 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. Pour la moitié navigateur, la bannière de témoins est une capacité de la même plateforme, offerte à tout compte Agreely et facturée à part : elle recueille le choix, bloque les traceurs non essentiels et transforme chaque décision en preuve ancrée. Ce qu'Agreely ne cherche pas à couvrir, c'est le reste du périmètre d'une grande CMP : chaînes IAB TCF, ciblage géographique mondial, cartographie des données, automatisation des demandes de droits.
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, le réseau principal, chain id 8453) |
| Étendue | Automatisation des demandes de droits, cartographie des données, risque fournisseur, analyse des témoins, bannières, modèles d'EFVP | La bannière de témoins, une capacité de la même plateforme offerte à tout compte Agreely et facturée à part; le reste demeure hors de portée, à 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 règles géographiques mondiales, les chaînes IAB TCF, les flux de demandes de droits et la cartographie des données sont un travail réel et nécessaire, et Agreely n'en fait pas. La bannière de témoins, elle, est couverte : c'est une capacité de la même plateforme, offerte à tout compte Agreely et facturée à part, et chaque choix y devient une preuve ancrée. Le cœur d'Agreely demeure 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 conforme à la Loi 25, avec blocage des traceurs et preuve de chaque choix. La bannière de témoins d'Agreely couvre cela : une capacité de la même plateforme, offerte à tout compte Agreely et facturée à part.
- Il vous faut des chaînes IAB TCF, des règles géographiques mondiales, 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.
- Vous exploitez déjà une CMP. Gardez-la : laissez-la 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 d'abord comme couche de preuve : même sa bannière de témoins produit des preuves ancrées, plutôt qu'un simple enregistrement détenu par le fournisseur.
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 est asynchrone et soumis par le portefeuille relayeur d'Agreely : il ne conditionne jamais une décision, et ce qu'il garantit est qu'une écriture ne peut plus être réécrite en douce après coup. 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.