Une architecture de consentement qui fonctionne d’un projet à l’autre

Les applications web intègrent souvent des services externes : analytique, cartes, vidéos ou prise de rendez-vous. Cela crée des flux de données supplémentaires et pose la question des conditions dans lesquelles ces services peuvent être chargés.

De nombreuses solutions de consentement sont intégrées après coup dans un site, comme un système à part. Cela crée des dépendances supplémentaires : la configuration et l'interface se trouvent en dehors de l'application, des scripts externes s'insèrent dans le chemin de chargement technique et le contrôle des intégrations se répartit entre plusieurs systèmes.

Pour nos projets, nous voulions donc intégrer le consentement directement dans l'architecture applicative.

Il en est résulté un moteur de consentement autonome, utilisé aujourd'hui comme module technique commun.

Le système de consentement sépare délibérément la logique fonctionnelle centrale des données propres au projet et de l'interface visible.

La même base technique peut ainsi servir dans des applications construites différemment, sans devoir réimplémenter l'état du consentement, le versionnage ou le filtrage des scripts pour chaque projet.

Une exigence centrale consistait à ne pas se contenter de désactiver les services soumis à consentement avant l'accord. Ils ne doivent pas être chargés du tout.

Plusieurs mécanismes s'articulent pour cela.

Afin que les valeurs de stockage déclarées et l'implémentation réelle ne soient pas maintenues indépendamment l'une de l'autre, le moteur utilise un registre central. Des propriétés techniques sont définies pour chaque valeur de stockage gérée par l'infrastructure de consentement.

Les informations dépendantes de la langue, comme la finalité et la description, sont maintenues séparément.

Si du code applicatif tente d'écrire une valeur non enregistrée via l'infrastructure de consentement, l'opération est refusée. Le registre n'est donc pas seulement une documentation, mais fait partie du contrôle technique.

Chaque configuration de consentement possède une version.

Lors d'une visite ultérieure, le moteur compare la version enregistrée avec l'état actuellement utilisé. Si la configuration a changé en conséquence, la sélection existante peut être écartée et une nouvelle décision demandée.

Un service nouvellement ajouté peut ainsi être traité par une nouvelle version de consentement, sans développer une logique de migration pour chaque site.

Un consentement peut être ajusté à tout moment via les réglages. Lorsqu'une catégorie précédemment acceptée est désélectionnée, ce n'est pas seulement l'état de consentement enregistré qui change.

La reconstruction est importante, car des scripts tiers déjà exécutés ne peuvent pas être annulés de manière fiable par la seule suppression de leur élément de script.

Après le retrait, l'état doit donc correspondre à celui d'un visiteur qui n'a jamais autorisé la catégorie concernée.

Entre le moteur de consentement et la configuration se trouve une interface définie. Le moteur a besoin de certaines informations, mais n'est pas lié à l'endroit où elles sont stockées.

Différents modèles sont ainsi possibles.

Les noms de cookies, les identifiants, l'attribution aux catégories et les durées de conservation sont neutres du point de vue linguistique. Tout ce que lisent les visiteurs peut en revanche être maintenu par langue.

Une valeur de stockage est ainsi définie techniquement une seule fois, puis décrite dans chaque langue nécessaire.

Dans le projet de référence Woop Art, l'allemand et l'anglais sont entièrement maintenus. Le site de Woop Technology utilise le même moteur avec des langues supplémentaires.

Le moteur fournit une interface par défaut réutilisable, sans en imposer l'usage.

La logique de consentement reste inchangée.

L'affichage peut donc être adapté au système de design du projet sans réimplémenter des fonctions centrales comme le versionnage, le registre ou le retrait.

Outre l'état de consentement dans le navigateur, chaque décision explicitement enregistrée peut être journalisée côté serveur.

Les adresses IPv4 sont tronquées après le deuxième bloc, les adresses IPv6 après le troisième segment.

Le point de terminaison prévu à cet effet n'accepte que les requêtes provenant de la même origine et se trouve sur un chemin fixe, afin de pouvoir être restreint de façon ciblée au niveau de l'infrastructure.

La décision du visiteur prend d'abord effet dans l'état de consentement de l'application. Si l'enregistrement côté serveur échoue, le site reste utilisable.

L'erreur est journalisée côté serveur plutôt que d'exposer des détails techniques dans le navigateur. Le bon fonctionnement du système de consentement ne dépend donc pas de la disponibilité permanente de cette journalisation.

La configuration de consentement et le moteur central font partie de l'application. Aucun fournisseur de CMP externe n'est donc nécessaire pour le système de consentement lui-même.

Les services soumis à consentement en restent distincts et ne se chargent qu'une fois le consentement requis obtenu.

Le moteur de consentement existe sous forme de paquet distinct et est distribué via le registre de paquets privé de Woop Technology. Les versions et les modifications peuvent ainsi être gérées de manière traçable, comme toute autre dépendance technique.

Un nouveau projet ajoute pour l'essentiel quatre éléments qui lui sont propres.

Une architecture de consentement propre n'est pas nécessaire pour tous les projets. Pour un site simple avec peu de services externes, une plateforme de consentement établie peut être la solution la plus rapide et la plus économique.

Dans ces cas, un moteur commun réduit les implémentations propres à chaque projet et permet de faire évoluer les fonctions centrales en un seul endroit.

L'état central du consentement est également accessible au code applicatif.

Cela permet également de mettre en place des solutions à deux clics. À la place d'un service tiers non encore autorisé, un composant local peut d'abord s'afficher, informer sur le service externe et ne le charger qu'après une décision correspondante.

Le consentement ne se limite donc pas au bandeau et à la fenêtre de réglages, mais peut être intégré directement dans le déroulement d'une application.

Une plateforme de consentement externe apporte un fournisseur supplémentaire, ses propres scripts, sa propre configuration et généralement une dépendance technique de plus. Notre moteur, lui, est exploité avec les applications existantes et au sein de l'infrastructure prévue.

Cela ne signifie pas que les plateformes de consentement externes soient inadaptées par principe. Le choix dépend de l'ampleur et des exigences du projet.

Aucun autre fournisseur de CMP n'est nécessaire pour la gestion des consentements elle-même. Les données de consentement correspondantes peuvent donc être traitées là où l'application est exploitée.

Les autres services externes utilisés par un projet donné et les données transmises à cette occasion sont définis et documentés séparément, projet par projet.

Le moteur de consentement est aujourd'hui utilisé comme composant réutilisable de différentes applications web. Les fonctions centrales sont maintenues une seule fois, tandis que les données, les intégrations, les langues et l'interface restent propres à chaque projet.