Gestion des consentements — Réflexion et proposition

Auteur : Victor Lequay Date : 19 mars 2026 Statut : Brouillon pour discussion

1. Contexte

La plateforme OpenCaps collecte des données énergétiques auprès de plusieurs fournisseurs (Enedis, GRDF, CPCU, Fraîcheur de Paris) pour le compte de gestionnaires de bâtiments et de copropriétaires. Cette collecte nécessite des autorisations légales (consentements, mandats, contrats) dont la gestion est aujourd'hui entièrement manuelle.

Situation actuelle

Aspect	État
Suivi des consentements	Aucun système. PDFs stockés sur Google Drive, référencement dans la tête des opérateurs
Vérification avant collecte	Aucune. Le ct-injector collecte tant que le fournisseur le permet
Détection d'expiration	Réactive uniquement — découverte quand les données cessent d'arriver
Alertes proactives	Inexistantes
Lien entre preuves et comptes	Manuel (audit ponctuel via rclone + API)

Risques identifiés

Conformité réglementaire : Enedis peut demander à tout moment la preuve d'un mandat valide. Délai de grâce estimé ~1 mois après le début de la collecte.
Interruptions de service : Les consentements expirent silencieusement, la collecte s'arrête, les données manquent dans les rapports.
Opérationnel : Impossible de savoir rapidement quels consentements sont à jour, lesquels arrivent à expiration, lesquels manquent.

2. Types d'utilisateurs concernés

Type	Rôle vis-à-vis du consentement
Copropriétaire / Résident	Donne son consentement pour son propre compteur (PRM, PCE)
Gestionnaire de patrimoine	Donne le consentement au nom d'un bâtiment ou d'un portefeuille, couvre potentiellement de nombreux compteurs
Opérateur OpenCaps	Gère les comptes de collecte, vérifie les consentements, relance les renouvellements

3. Fournisseurs et leurs modèles de consentement

Chaque fournisseur a un processus de consentement différent :

Enedis (électricité)

Granularité : Par PRM (Point de Référence Mesures)
Forme : Mandat signé (PDF) par le titulaire du contrat
Temporalité : La collecte peut commencer immédiatement (déclaration ACCORD_CLIENT), mais Enedis peut auditer à tout moment et demander la preuve du mandat. Marge d'environ 1 mois.
Expiration : Date inscrite sur le mandat. Renouvellement nécessaire.
Migration R6X : Enedis remplace le flux CMDV3 (ACCORD_CLIENT) par un modèle de publication SERVICE_ACCES. Le modèle de consentement change : abonnements de service au lieu de mandats individuels. Deadline fin 2026.
Remarque : Un client SOAP pour l'enregistrement programmatique de mandats (CommandeAccesDonneesMesuresClient) existe dans le code mais n'est pas utilisé en production.

GRDF (gaz)

Granularité : Par PCE (Point de Comptage et d'Estimation)
Forme : Enrôlement via la procédure DigiConnect
Temporalité : Le consentement doit être obtenu avant que les données soient accessibles. Pas de collecte possible sans enrôlement préalable.
Expiration : À déterminer (conditions du contrat DigiConnect)

CPCU / Engie (chauffage urbain)

Granularité : Par numéro client
Forme : Contrat commercial avec Engie
Temporalité : Contrat en cours = accès aux données
Expiration : Selon les termes du contrat

Fraîcheur de Paris (refroidissement)

Granularité : Par mnémonique (identifiant de sous-station)
Forme : Contrat commercial + clé API
Temporalité : Contrat en cours = accès aux données
Expiration : Selon les termes du contrat

Futurs fournisseurs / capteurs tiers

Granularité : Variable (capteur, passerelle, bâtiment)
Forme : Inconnue (appairage, approbation utilisateur, API)
Remarque : Le système doit être conçu pour accueillir de nouveaux types de consentement sans modification majeure.

4. Cycle de vie d'un consentement

Un consentement n'est pas un booléen. C'est un objet avec un cycle de vie :

  NÉCESSAIRE          Le compteur est identifié, le consentement est requis
      │
      ▼
  EN COURS            La procédure d'obtention est lancée
      │                (signature envoyée, enrôlement demandé)
      ▼
  OBTENU              Preuve reçue, collecte autorisée
      │                (PDF signé, confirmation d'enrôlement, contrat validé)
      │
      ├──► EXPIRATION PROCHE    Dans les N jours avant expiration
      │         │
      │         ▼
      ├──► EXPIRÉ              Date d'expiration dépassée, renouvellement nécessaire
      │
      └──► RÉVOQUÉ             Retiré explicitement (départ locataire, résiliation)

Métadonnées associées

Champ	Description
Identifiant compteur	PRM, PCE, numéro client, mnémonique...
Fournisseur	Enedis, GRDF, CPCU, Fraîcheur, etc.
Bâtiment / Entité	Lien avec le patrimoine (ID Hemisphere/GraphDB)
Donneur de consentement	Nom, rôle (copropriétaire, gestionnaire)
Statut	NÉCESSAIRE, EN_COURS, OBTENU, EXPIRATION_PROCHE, EXPIRÉ, RÉVOQUÉ
Date de signature / obtention	Quand le consentement a été obtenu
Date de début de validité	À partir de quand la collecte est autorisée
Date d'expiration	Quand le consentement expire
Type de preuve	PDF signé, confirmation API, référence contrat
Référence de preuve	Lien vers le document (Drive, S3, etc.)
Notes	Informations libres (numéro de contrat, cas particulier)

5. Ce que le système doit faire

Fonctionnalités essentielles

Enregistrer et suivre les consentements — CRUD par compteur, par fournisseur, avec statut et dates
Stocker ou référencer les preuves — Upload de PDFs ou lien vers un stockage externe (Google Drive, S3)
Alerter sur les expirations — Notifications proactives N jours avant expiration (email, Zulip, chatbot)
Servir de "gate" pour la collecte — Le service d'ingestion (ct-injector ou successeur) interroge le statut avant de lancer une collecte. Pas de consentement valide = pas de collecte (ou collecte avec flag d'alerte)
Tableau de bord — Vue d'ensemble par bâtiment / portefeuille : combien de compteurs couverts, combien en attente, combien expirés
Audit trail — Historique des changements de statut (qui, quand, pourquoi)

Fonctionnalités souhaitables

Workflow d'obtention — Suivi du processus : mandat envoyé → signé → reçu → enregistré
Renouvellement automatique — Notification + régénération du mandat à signer (templates)
Import en masse — Charger un fichier avec N PRMs et créer les consentements en attente
Intégration chatbot — "Quels consentements manquent pour le bâtiment X ?" via MCP

6. Contraintes architecturales

Le contexte de migration

Composant	Aujourd'hui	Demain
MetaInfoDB	Store de métadonnées entités (MongoDB)	Remplacé par une base de données graphe
Hemisphere	Plateforme centrale (utilisateurs, bâtiments, JWT)	Possiblement absorbé dans le graphe
CT-Injector	Monolithe (scheduling + fetch + write + anomalies)	Refactoring prévu, séparation des responsabilités

Conséquence

Le système de consentement ne doit pas être construit comme une extension de ct-injector ou de MetaInfoDB — ces deux composants vont évoluer significativement. Il doit être autonome et communiquer avec le reste via des APIs.

7. Options d'implémentation

Option A : Service autonome dédié

Un nouveau microservice avec sa propre base de données, API REST, et MCP.

Avantage	Inconvénient
Indépendant des migrations en cours	Un service de plus à opérer
Modèle de données conçu pour le domaine	Risque de duplication d'information (entités, bâtiments)
Peut évoluer indépendamment	Nécessite une intégration avec les autres services
Survivra aux refactorings

Stack potentiel : Go ou TypeScript, PostgreSQL, API REST, MCP dédié.

Option B : Module dans la future base graphe

Le consentement comme un nœud/relation dans le graphe (compteur) -[A_CONSENT]-> (consentement) -[DONNÉ_PAR]-> (utilisateur).

Avantage	Inconvénient
Modèle relationnel naturel	Dépend de la migration GraphDB (timeline incertaine)
Pas de service supplémentaire	Mélange domaines métier et juridique
Requêtes traversant entités + consentements	Moins de flexibilité sur le modèle

Option C : Extension du CT-Injector (ou son successeur)

Ajouter des champs de consentement au modèle Account + une table de documents.

Avantage	Inconvénient
Proximité avec la collecte	CT-Injector va être refactoré
Moins de services	Couplage domaine collecte / domaine juridique
Vérification au plus près	Les contrats CPCU/Fraîcheur ne sont pas des "accounts"

Recommandation préliminaire

Option A (service autonome) semble la plus résiliente face aux migrations à venir, avec une intégration progressive :

Phase 1 : Service + API + MCP, import des consentements existants (audit Drive)
Phase 2 : Intégration avec ct-injector (vérification avant collecte)
Phase 3 : Alertes d'expiration (Zulip, email)
Phase 4 : Workflow d'obtention + templates de mandats
Phase 5 : Migration vers le graphe quand celui-ci sera prêt

8. Questions ouvertes pour discussion

Qui est responsable de l'obtention des consentements ? L'opérateur OpenCaps ? Le gestionnaire de patrimoine ? Le copropriétaire lui-même ?
Faut-il bloquer la collecte si le consentement n'est pas enregistré, ou simplement alerter ? (Enedis permet de collecter avant d'avoir le mandat — est-ce une pratique qu'on veut maintenir ?)
Où stocker les documents ? Google Drive (existant), S3/MinIO (à déployer), dans le service lui-même (blob storage) ?
Quelle granularité pour les alertes ? Par compteur ? Par bâtiment ? Par gestionnaire ?
R6X timeline : La migration Enedis vers SERVICE_ACCES change fondamentalement le modèle de consentement. Faut-il anticiper ce modèle dès maintenant ?
RGPD : Les consentements sont-ils des données personnelles ? (Le nom du signataire, potentiellement son adresse). Implications sur la durée de conservation et le droit à l'effacement.
Volumétrie estimée : Combien de compteurs aujourd'hui ? Projection à 1 an, 3 ans ?
Priorité : Quel fournisseur traiter en premier ? (Enedis a le risque d'audit le plus élevé)

9. État des lieux technique — Annexe

Consentements actuellement en production (mars 2026)

Fournisseur	Comptes actifs	Compteurs couverts	Consentements documentés
Enedis	31 (enedis, enedis_day, enedis_top, enedis_day_top)	~20 PRMs uniques	PDFs sur Google Drive (audit Félicité uniquement)
GRDF	0	0	N/A (credentials pas encore déployées)
CPCU	1	1 client (19070)	Contrat commercial (non documenté dans le système)
Fraîcheur de Paris	1	1 mnémonique (040012)	Contrat commercial (non documenté)
Weather	4	N/A (données ouvertes)	Pas de consentement requis
Synthesis	3	N/A (calcul interne)	Pas de consentement requis
Per_month	2	N/A (agrégation interne)	Pas de consentement requis

Comptes problématiques identifiés

PRM / ID	Fournisseur	Problème	Impact
3 PRMs (868..., 740..., 740...)	Enedis	Bloqués depuis janvier 2023	Aucune donnée depuis 3 ans, comptes toujours actifs
50059419716994	Enedis	"Point résilié" (SGT4M1)	Génère ~750K alertes cumulées
50008194526040	Enedis	Bloqué depuis janvier 2026	76 jours sans données
19070	CPCU	Gap données jan-mars 2026	Provider-side, résolu récemment

Anomalies liées au consentement dans GEDB

Il n'existe aucun type d'anomalie dédié au consentement. Quand Enedis retourne le code SGT4M1 ("point résilié"), l'anomalie est classée TECHNICAL_FAULT / UNAVAILABLE — indistinguable d'une panne technique. Un opérateur ne peut pas filtrer les alertes pour identifier spécifiquement les problèmes de consentement.