Une case cochée dans un formulaire ne suffit pas à mettre en place un processus de consentement fiable. L’application doit savoir quelle autorisation a été accordée, pour quelle action, à quel moment et dans quelle portée ; elle doit aussi pouvoir cesser d’agir lorsque le consentement est retiré. Cette conception est particulièrement pertinente pour les fonctionnalités facultatives, comme les communications ou les traitements qui ne sont pas nécessaires à la fourniture du service principal.
La conception d’un consentement révocable dans les applications PHP exige de séparer des décisions qui finissent souvent regroupées dans un seul indicateur. Elle ne détermine pas à elle seule si une pratique est conforme à la réglementation applicable : elle traduit les décisions produit et les instructions examinées par des spécialistes en un comportement technique vérifiable.
Délimiter l’action et distinguer les notions
Commencez par décrire l’action concrète qui nécessite une autorisation. « Tout accepter » est difficile à interpréter et à révoquer ; « recevoir des communications promotionnelles par e-mail » délimite mieux la finalité et le canal. Si la finalité ou la portée change de manière substantielle, ne partez pas du principe que le consentement antérieur reste automatiquement valable.
Distinguez le consentement des notions connexes :
- Conditions d’utilisation : elles expriment des conditions contractuelles ou d’accès ; les accepter ne revient pas en soi à autoriser un traitement facultatif.
- Préférences : elles décrivent des choix de présentation ou de configuration. Elles peuvent nécessiter un consentement, mais ne le représentent pas toujours.
- Autorisations d’accès : elles déterminent ce qu’une identité authentifiée peut faire dans le système. La révocation d’une autorisation facultative ne devrait pas désactiver automatiquement le compte.
- Consentement : il consigne une décision portant sur une finalité et une portée définies, conformément aux critères fonctionnels et juridiques adoptés.
Documentez chaque finalité dans un catalogue stable, avec une description compréhensible pour l’interface et une référence interne pour le code. Évitez de réutiliser une clé générique telle que accepted pour des finalités différentes.
Modéliser l’état et ses changements
Un modèle utile identifie le sujet, la finalité, la portée, l’état, l’origine de la décision et les horodatages. Le sujet peut être un compte ou une identité associée ; le choix dépend de la manière dont le consentement est lié aux personnes, aux comptes et aux canaux. Ne stockez que les données nécessaires pour appliquer la décision et l’expliquer.
Au lieu de tout représenter par un booléen dépourvu de contexte, conservez un enregistrement actuel consultable et, si les exigences d’audit le justifient, des événements de changement immuables ou en ajout uniquement (append-only). Un événement peut comprendre :
- L’identifiant du sujet et la clé de la finalité.
- L’action consignée, par exemple l’octroi ou le retrait.
- La portée applicable, comme le canal ou la catégorie.
- La date et l’heure du serveur dans un format cohérent.
- L’origine, comme un formulaire authentifié ou un flux administratif, sans collecter de données excessives.
- Un identifiant de corrélation ou une version de la définition, lorsqu’ils facilitent l’analyse des changements.
Le journal des événements assure la traçabilité, mais ne prouve pas automatiquement que la demande était claire, que l’interface était correctement présentée ou que la décision est juridiquement valable. Évitez de stocker des copies inutiles de formulaires, des adresses IP ou d’autres données sensibles en guise de substitut à une conception correcte.
En PHP, regroupez les opérations dans un service de domaine, par exemple ConsentService, au lieu de laisser chaque contrôleur écrire directement l’état. La mise à jour de l’état courant et l’insertion de l’événement doivent être effectuées dans une transaction de base de données lorsqu’elles partagent le même stockage.
Vérifier l’autorisation au point d’exécution
L’interface peut masquer une option en l’absence d’autorisation, mais cela ne constitue pas un contrôle suffisant. La vérification doit avoir lieu au point de déclenchement de l’action : avant la mise en file d’un envoi, l’exécution d’un traitement facultatif ou l’appel à une intégration externe. Un message en attente créé avant un retrait doit également faire l’objet d’une vérification avant son envoi.
Une opération de domaine peut interroger une interface telle que ConsentRepository::isGranted($subjectId, $purpose, $scope). Le nom est donné à titre d’exemple : le résultat doit tenir compte de l’état courant, de la finalité exacte, de la portée et de toute règle d’expiration ou de version définie par le produit. Ne transformez pas un consentement pour un canal en autorisation pour un autre.
Si l’exécution est asynchrone, transmettez des identifiants et consultez de nouveau l’état lors du traitement du travail, au lieu de vous fier à une copie obsolète envoyée depuis le formulaire. En cas d’indisponibilité du dépôt, déterminez explicitement le comportement à adopter : pour une action facultative sensible, il est généralement plus sûr de ne pas l’exécuter tant que l’autorisation ne peut pas être vérifiée. Consignez l’incident opérationnel sans exposer de données inutiles.
Retirer le consentement et propager le changement
Le retrait est une transition explicite de l’état, et non une suppression silencieuse de l’historique ni une révocation de la session. L’utilisateur peut rester authentifié et conserver l’accès au service tandis que l’action facultative autorisée est interrompue. De même, le retrait d’un consentement n’implique pas automatiquement la suppression de toutes les données : leur conservation, leur effacement ou leur traitement ultérieur peuvent dépendre d’exigences distinctes, à définir avec des conseils appropriés.
Lors de l’enregistrement du retrait, mettez à jour l’état consulté par l’application et émettez un événement permettant de coordonner les tâches ultérieures. Identifiez les points de propagation : tâches en file d’attente, planificateurs, systèmes de communication et intégrations. Pour éviter les incohérences, utilisez des modèles tels qu’une table transactionnelle de sortie (outbox) et des consommateurs idempotents ; définissez ce qui se passe si une intégration est indisponible.
Il n’est pas toujours possible d’annuler un effet déjà produit, comme un message remis à son destinataire. Distinguez donc la prévention des actions futures, l’annulation des tâches encore en attente et la correction des effets déjà produits. Présentez le résultat avec précision et prévoyez un mécanisme de nouvelle tentative ou de révision opérationnelle en cas d’échec de propagation.
Tester les limites, les répétitions et les défaillances partielles
Les tests doivent couvrir le cycle complet, et pas seulement l’enregistrement d’une option par le formulaire. Incluez l’octroi, le refus, le retrait, les changements de finalité et les demandes répétées. Vérifiez que répéter un retrait ne réactive pas le consentement et que les événements en double ne provoquent ni envois dupliqués ni états contradictoires.
- Vérifiez qu’une action ne démarre pas en l’absence d’une autorisation en vigueur pour cette finalité et cette portée.
- Retirez le consentement après la création d’un travail et confirmez que le consommateur le vérifie de nouveau avant d’agir.
- Simulez une défaillance entre la mise à jour de l’état et la notification à une intégration ; vérifiez que le rapprochement permet d’achever la propagation.
- Testez les états anciens, les données manquantes et les erreurs du dépôt, en appliquant le comportement sûr défini.
- Vérifiez que le retrait d’une finalité ne modifie pas les autres finalités, les autorisations d’accès ni la session.
Enregistrez les métriques opérationnelles et les erreurs de traitement sans transformer les journaux techniques en dépôt parallèle d’informations personnelles. Examinez régulièrement les tâches en attente et les divergences entre l’état central et les intégrations.
Définir les responsabilités avant le déploiement
L’équipe produit doit définir les finalités, la portée, le texte et l’expérience de retrait ; l’équipe technique doit faire respecter ces décisions dans chaque chemin d’exécution. Les équipes de sécurité et les spécialistes juridiques peuvent examiner le modèle de menaces, la minimisation des données, les durées de conservation et l’interprétation applicable. La mise en œuvre ne remplace pas cet examen.
Avant le déploiement, documentez les actions qui dépendent de chaque finalité, les personnes autorisées à modifier leurs définitions et la manière de corriger les erreurs. Le consentement cesse ainsi d’être une case isolée et devient une condition vérifiable, traçable et propagée dans l’application PHP.
