Une architecture de consentement conçue pour nos projets, pour la sécurité et la souveraineté des données
Pour nos applications web, nous avons développé nous-mêmes la gestion des consentements au lieu de la confier à une plateforme externe. Fonction, design et comportement restent entre nos mains ; les consentements et leurs journaux restent sur notre propre infrastructure – sans script tiers dans le chemin de chargement et sans frais récurrents.
- Type
- Étude de cas technique
- Module
- @woop-technology/
consent - Projets de référence
- Woop Art
- Ce site web
- Statut
- En service | en développement continu
- Intégration
- React | Next.js App Router
- Distribution
- Registre de paquets privé
- Architecture de consentement
- Souveraineté des données
- Google Consent Mode v2
- Registre des cookies
- consentements versionnés
- filtrage des scripts
- sources de données interchangeables
- multilinguisme
- interfaces propres au projet
- journalisation côté serveur
Pourquoi nous avons développé notre propre gestion du consentement
Les applications web intègrent souvent des services externes comme l’analytique, les cartes, les vidéos ou la prise de rendez-vous. Il en résulte des flux de données supplémentaires – et deux questions : à quelles conditions ces services peuvent être chargés, et ce qu’il advient des données une fois qu’elles ont quitté notre propre serveur.
La réponse évidente serait une plateforme de consentement externe. Pour nous, elle aurait apporté trois choses dont nous ne voulions pas : une facture mensuelle de plus, un système de consentement qui n’entre dans l’application que dans les limites prévues par le prestataire – et les données de consentement de nos visiteurs sur des serveurs étrangers.
C’est pourquoi nous avons développé notre propre gestion du consentement : comme partie intégrante de notre architecture applicative, réutilisable et adaptable – et conçue pour que les données restent exclusivement sur notre propre infrastructure.
- 01Gérer les consentements et les valeurs de stockage de manière centralisée, sans prestataire externe
- 02Activer les services en fonction du consentement
- 03Traiter les consentements et les journaux exclusivement sur notre propre infrastructure
- 04Prendre en charge différentes langues, sources de données et interfaces
- 05Être réutilisable, sans frais supplémentaires par mois ou par projet
Il en est résulté un moteur de consentement autonome, utilisé aujourd'hui comme module technique commun dans nos projets.
Trois choses que nous ne déléguons pas
Une plateforme de consentement externe ajoute un prestataire : ses propres scripts, sa propre configuration, ses propres serveurs et une redevance récurrente. Notre propre moteur tourne au contraire avec l’application, au sein de la même infrastructure et avec les mêmes outils.
Concrètement, cela tient en trois points.
- Coûts
- Aucune licence par domaine, par page vue ou par mois. Les coûts naissent une fois lors du développement, puis dans la maintenance.C’est viable parce que le même composant tourne dans plusieurs projets.
- Contrôle
- Fonction, base de données, design et comportement sont définis par nous – jusque dans le code applicatif, qui peut interroger directement l’état du consentement.Rien ne s’arrête là où s’arrête l’offre d’un prestataire.
- Données
- Configuration, consentements et journaux se trouvent sur nos propres serveurs. Aucun tiers ne stocke, ne traite ni ne voit les décisions des visiteurs.
La fonction de consentement ne nécessite pas de CMP externe
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.
- aucun script CMP supplémentaire
- aucun appel réseau externe pour la fonction de consentement elle-même
- aucune interface de consentement tierce
- aucune dépendance de plateforme supplémentaire pour la seule gestion des consentements
Les services soumis à consentement en restent distincts et ne se chargent qu'une fois le consentement requis obtenu.
Moins de code tiers, moins de surface d’attaque
Un script de consentement externe s’exécute avec les mêmes droits que la page elle-même et est chargé depuis un serveur tiers. Chaque version livrée par le prestataire devient ainsi partie du site sans pouvoir être vérifiée en détail.
Avec des prestataires établis, cela ne pose généralement pas de problème. Nous préférons néanmoins connaître le code qui s’exécute sur nos pages : notre propre moteur est versionné, vérifié et déployé comme le reste du code de l’application.
- n’accepte que les requêtes provenant de l’origine du site
- vérifie que chaque requête contient des champs complets et autorisés
- tronque l’adresse IP avant l’enregistrement
- se trouve sur un chemin fixe pour lequel le pare-feu en amont peut tenir ses propres règles
Les consentements et les journaux se trouvent sur nos propres serveurs
Aucun autre prestataire n’intervient dans la gestion des consentements. La décision d’un visiteur prend effet dans l’application et est journalisée sur le serveur même où tourne l’application – là où sont aussi traitées les autres données du projet. Cela vaut pour chaque projet qui utilise le moteur : les décisions sont journalisées localement dans le conteneur de l’application concerné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.
Trois couches distinctes pour la logique, les données et l'affichage
Le système de consentement sépare la logique fonctionnelle centrale des données propres au projet et de l'interface visible.
La même base technique peut ainsi servir dans différentes applications, sans devoir réimplémenter l'état du consentement, le versionnage ou le filtrage des scripts pour chaque projet.
Le module est livré avec une interface standard que le projet met en forme ou remplace entièrement. C’est ainsi que le même moteur tourne sur une plateforme d’art et sur un site d’entreprise, bien que les deux interfaces diffèrent par leur design.
- Moteur de consentement
- Le moteur central assure les fonctions qui restent identiques d'un projet à l'autre :
- état du consentement
- vérification de version
- registre des cookies
- filtrage des scripts
- solutions à deux clics
- retrait
- nettoyage des valeurs de stockage déclarées
- Google Consent Mode v2
- Source de données
- Le moteur reçoit les informations propres au projet via une interface définie. Il s'agit notamment de :
- version du consentement
- catégories et services
- cookies et autres valeurs de stockage
- textes par langue
- configurations de scripts
- Interface
- Le bandeau et la fenêtre de réglages sont conçus pour le projet concerné. L'interface reçoit du moteur central les données nécessaires et un ensemble d'actions défini.L'apparence visuelle peut ainsi être adaptée à chaque projet sans devoir modifier la logique de consentement sous-jacente.
Tout sur notre propre infrastructure.
Les chiffres sous les projets de référence correspondent à leur configuration respective. Catégories, services et cookies sont librement configurables.
Un module commun plutôt que des solutions isolées par projet
Le moteur de consentement est fourni sous forme de package propre via le registre de packages privé de Woop Technology. Les versions et les modifications sont gérées de manière centralisée ; chaque projet intègre la version dont il a besoin et adopte les mises à jour à son propre rythme – différents projets peuvent donc utiliser différentes versions en même temps.
Chaque nouveau projet ajoute quatre éléments :
- 01Données
- Catégories, services, valeurs de stockage et textes.
- 02Persistance
- L'endroit où sont stockés les journaux des décisions de consentement.
- 03Intégrations
- L'analytique et d'autres services soumis à consentement.
- 04Design
- Interface par défaut ou composants de bandeau et de réglages sur mesure.
L'état du consentement, le versionnage, le registre, le filtrage des scripts et le retrait proviennent du module commun. Les améliorations du moteur peuvent être reprises dans plusieurs projets via des mises à jour versionnées.
Ce qu’apporte le moteur, ce que décide le projet
- 01Moteurconsentement par catégorie, versionnage, révocation, nettoyage des cookies, gating des scripts, Google Consent Mode v2
- 02Projetsource de données (JSON, API ou CMS headless), langues, interface (UI standard ou composants propres), intégrations (hooks, solutions à deux clics)
- 03Persistancecookie de consentement dans le navigateur, journalisation côté serveur, adresses IP tronquées
- 04Stack & exploitationReact, TypeScript, Next.js App Router, injection de dépendances, registre de packages privé, entrées vérifiées
Les services soumis à consentement ne se chargent qu'après l'accord
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.
- Consent Mode démarre à l'état refusé
- Google Consent Mode v2 est initialisé au premier affichage avec les états de stockage refusés correspondants. Si une décision valide existe ou dès qu'un consentement est donné, cet état peut ensuite être mis à jour de façon ciblée.
- Sans consentement, aucun script soumis à consentement
- Le moteur ne met à disposition que les intégrations dont la catégorie de consentement a effectivement été acceptée. Dans le projet de référence, cela signifie par exemple : sans consentement analytique, aucun script Google Analytics n'est intégré.La décision n'est donc pas répartie entre les composants, mais pilotée de manière centrale par l'état du consentement.
Le registre réunit l'usage technique et la documentation
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.
- identifiant
- nom du cookie ou modèle de nom
- service associé
- catégorie
- durée de conservation
- type de stockage
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.
Les décisions de consentement sont liées à une version de configuration
Chaque configuration de consentement possède une version.
- identifiant de consentement
- version de la configuration
- moment de la décision
- catégories acceptées
Lors d’une visite ultérieure, le moteur compare la version enregistrée avec celle actuellement en service. Si les deux diffèrent, le moteur rejette la sélection enregistrée et demande une nouvelle décision.
Un service nouvellement ajouté peut ainsi être traité par une nouvelle version de consentement, sans développer une logique de migration pour chaque site.
Une décision modifiée produit aussi un effet technique
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.
- supprime les valeurs de stockage déclarées de la catégorie désélectionnée
- met à jour Google Consent Mode
- empêche le rechargement des services associés
- et remet si nécessaire l'application dans un état propre par une reconstruction
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.
Ce qu'un consentement enregistre dans le navigateur
Deux clics avant qu'un service externe ne se charge
Tous les consentements n'ont pas leur place dans le bandeau. Pour les services intégrés comme la prise de rendez-vous, le moteur le recueille là où le visiteur veut réellement utiliser le service.
- 01
Premier clic : l'avis
Le bouton indique quel prestataire serait chargé et quelles données seraient transmises. Son libellé devient « Charger Google Agenda ».
- 02
Deuxième clic : le chargement
Ce n'est qu'à ce moment que le script et la feuille de style du prestataire sont intégrés et que la réservation s'ouvre. Jusque-là, aucune requête n'est envoyée à Google.
- 03
Sans passer par le bandeau
Le visiteur n'a pas besoin d'autoriser une catégorie dans les paramètres de consentement. La décision se prend au niveau du service, pour ce seul service.
Les composants nécessaires se trouvent dans le même package que le moteur : prêts à l'emploi pour Google Agenda et Calendly, et disponibles pour d'autres services via un composant de base commun.
L'identifiant de consentement est à portée de clic
Chaque décision est journalisée sur le serveur, mais elle ne se retrouve sans ambiguïté que par son identifiant de consentement. Un composant dédié met cet identifiant à portée de main des visiteurs.
L'identifiant se trouve dans le cookie de consentement, où personne ne le voit sans outils de développement. C'est pourtant le seul moyen univoque d'accéder à l'entrée sur le serveur, car l'adresse IP n'est enregistrée que sous forme tronquée.
Le composant affiche l'identifiant et le copie en un clic. Pour une question, une réclamation ou une demande d'accès, les visiteurs le joignent directement, et l'entrée est retrouvée sans questions complémentaires – avec l'heure, la version et le choix.
Le composant figure dans la déclaration de protection des données du site concerné et mène aussi directement de là aux paramètres de consentement.
Votre ID de consentement actuel
Cet ID unique est stocké localement dans votre navigateur et de manière pseudonymisée sur notre serveur afin de prouver votre choix en matière de protection des données. Pour toute question ou réclamation concernant votre consentement, veuillez nous transmettre cet ID – il nous permet de retrouver sans ambiguïté la preuve correspondante.
Aucun choix effectué pour l'instantLe composant est fourni prêt à l'emploi avec le package de consentement. Comme le bandeau et la fenêtre de paramètres, il se conçoit librement : le fonctionnement reste dans le package, le projet décide de l'apparence – ici celle de ce site.
La logique de consentement n'est pas liée à une source de données particulière
Le moteur de consentement ne lit pas ses données lui-même, mais via une interface définie. C'est l'implémentation de cette interface qui détermine leur provenance – le moteur reste le même.
- Par défaut : fichiers dans le projet
- L'implémentation fournie lit des fichiers JSON versionnés, livrés avec le code source. La configuration ne nécessite aucun appel réseau.
- CMS éditorial
- Si l'interface est implémentée pour un CMS headless, la rédaction y gère textes, services et cookies – sans modifier le moteur.
- Système propre via API
- Un CMS maison ou un service central se connecte de la même manière via son API – par exemple pour gérer ensemble les données de consentement de plusieurs applications.
Définition technique et traductions restent séparées
Les noms de cookies, les identifiants, les catégories et les durées de conservation sont définis une seule fois. Les textes du bandeau et de la fenêtre de paramètres existent en revanche dans chaque langue ; le visiteur les voit dans la langue qu'il a choisie :
- libellés et descriptions des catégories
- informations sur les services et finalités des cookies
- informations sur les transferts de données
- textes du bandeau et boutons
- libellés pour lecteurs d'écran
Une logique commune, des interfaces différentes
Le moteur propose une interface par défaut, qui peut être remplacée en tout ou en partie par des composants propres au projet.
Un projet peut- reprendre le bandeau et la fenêtre de réglages tels quels
- concevoir uniquement le bandeau
- remplacer uniquement la fenêtre de réglages
- réaliser les deux interfaces sur mesure
L'état du consentement, le versionnage et le retrait restent gérés de manière centralisée.
Journalisation des décisions côté serveur
Chaque consentement et chaque modification ultérieure génèrent un enregistrement sur le serveur, en plus de l'état dans le navigateur. Cette journalisation fait partie intégrante du processus ; elle n'est pas optionnelle.
La destination de l'enregistrement dépend, là aussi, de l'implémentation de l'interface : par défaut, l'application le dépose sous forme de fichier sur son propre serveur. Elle peut tout aussi bien le transmettre via une API à un autre service qui le gère, par exemple dans une base de données.
- identifiant de consentement
- version de la configuration
- sélection effectuée
- horodatage
- user agent
- adresse IP tronquée
Les adresses IPv4 sont tronquées après le deuxième bloc, les adresses IPv6 après le troisième segment. Les entrées reçues sont vérifiées ; les requêtes incomplètes ou non admises sont refusées.
La journalisation soutient la traçabilité des décisions, mais ne constitue pas un archivage à valeur probante.
Une erreur de journalisation ne bloque pas l'application
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.
Du clic à l'entrée de journal
01 Paramètres chargés02 Choix reçu03 État du consentement mis à jour04 Décision journaliséeProcessus terminé- 01
Le choix dans la bannière
Le visiteur décide, catégorie par catégorie, quels services il autorise. Les valeurs de stockage nécessaires restent actives.
- 02
L'application dans le code
Le moteur enregistre le choix, met à jour Google Consent Mode et active les services autorisés.
- 03
La journalisation côté serveur
La décision est journalisée avec version et horodatage.
Pourquoi une solution propre allait de soi pour nous
L'objectif était d'éviter d'emblée les dépendances et les coûts récurrents. Si nous avons pu y parvenir rapidement et de manière fiable, c'est grâce à ce que nous avions déjà en main.
- Expertise en protection des données et en consentement
- La manière dont s'articulent consentements, Google Consent Mode et obligations d'information envers les visiteurs fait partie de notre travail quotidien sur les applications web.
- Nos propres applications, pas un outil de création de sites
- Nos projets sont des applications web autonomes. Le consentement a donc pu être construit comme partie de l'application plutôt que greffé de l'extérieur.
- Notre propre infrastructure
- Nous exploitons nous-mêmes l'hébergement, le déploiement et le pare-feu. Conserver les journaux sur nos serveurs n'a donc demandé aucun nouveau service, seulement un point de terminaison de plus dans l'application existante.
- Modules communs
- Nos projets partagent déjà d'autres modules via notre registre de paquets privé. Le moteur de consentement en fait partie et est disponible pour chaque nouveau projet.
Le moteur de consentement n'a donc pas été un grand chantier, mais le prolongement de ce qui existait déjà.
Le consentement peut être intégré directement dans l'application
L'état central du consentement est également accessible au code applicatif.
- L'analytique est-elle autorisée ?
- Une vidéo intégrée peut-elle être chargée ?
- Faut-il obtenir un consentement avant une carte externe ?
- La décision enregistrée est-elle encore valable pour la version de consentement actuelle ?
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.
Le contrôle total implique la responsabilité totale
Sans prestataire, personne ne met à jour les listes de cookies, ne reprend les évolutions de Google Consent Mode ni n'adapte les textes à un nouveau cadre juridique. Ce travail nous revient – dans le cadre de la maintenance que nous assurons de toute façon pour nos applications – ou au client, lorsque textes et informations sont gérés via un CMS connecté.
Une base propre pour le consentement, sans prestataire entre les deux
Le moteur de consentement est aujourd’hui utilisé dans différentes applications web – sans prestataire externe, sans licence récurrente, avec les consentements et leurs journaux sur notre propre infrastructure. Les fonctions centrales sont maintenues une seule fois, tandis que données, intégrations, langues et interface restent propres à chaque projet.
- Indépendance
- Aucun prestataire, aucune licence, aucun script tiers dans le chemin de chargement.
- Souveraineté des données
- Configuration, consentements et journaux se trouvent sur notre propre infrastructure.
- Consentement avant les services concernés
- Les intégrations correspondantes ne se chargent qu'après le consentement requis.
- Décisions versionnées
- Les consentements enregistrés sont liés à l'état correspondant de la configuration.
- Logique de consentement centrale
- État, versionnage, registre, filtrage des scripts et retrait sont gérés ensemble.
- Réutilisable et flexible
- Sources de données, langues et interfaces par projet ; améliorations du moteur via des mises à jour versionnées.
Souhaitez-vous décider vous-même où vont les données de vos visiteurs ?
Lors d’un premier entretien, nous clarifions quels services de votre site transmettent des données à des tiers, où des alternatives économes en données ont du sens et comment les consentements et les journaux peuvent rester là où tourne votre application.