| Administratif |
| Identifiant de l'enregistrement | string | Un identifiant unique pour cet enregistrement (par exemple, un ULID, UUID ou identifiant attribué par le programme). La portée est limitée à l'espace de nommage de l'enregistrement ; il n'est pas nécessairement unique à l'échelle mondiale. |
| Identifiants | concept:Identifier | Identifiants portés par cette entité, tels que numéros d'identité nationale, identifiants de programme ou identifiants attestés par un document d'identité. |
| Identifiant externe | string | Identifiants attribués par des systèmes externes (CRM, gestion de cas, etc.). Plusieurs valeurs sont autorisées car un enregistrement peut porter des identifiants provenant de plusieurs systèmes. |
| Type d'enregistrement de consentement | string (consent-record-type) | Indique si cet enregistrement est un enregistrement de stockage interne ou un reçu de consentement émis de manière externe. Les enregistrements internes constituent l'état de travail du responsable du traitement ; les reçus sont des artefacts remis à la personne concernée. |
| Version du schéma | uri | Identifie la version du schéma d'enregistrement de consentement PublicSchema (ou autre) auquel cette instance est conforme. Permet les outils de migration vers les versions ultérieures. Il s'agit généralement d'un URI déréférençable, par exemple 'https://publicschema.org/ConsentRecord/v1'. |
| Conforme à | uri | URI des normes ou spécifications auxquelles cet enregistrement est conforme (ISO/IEC TS 27560, Kantara Consent Receipt, W3C DPV, etc.). Purement déclaratif ; aucune validation n'est effectuée par rapport aux normes citées au niveau du schéma. |
| Créé le | datetime | Horodatage généré par le système indiquant quand cet enregistrement a été conservé. Il s'agit de l'horodatage de numérisation, et non de la date de consentement. Distinct de 'signed_date' (le jour où la personne concernée a indiqué son consentement) et de 'effective_date' (quand l'enregistrement entre en vigueur). Pour les flux de travail papier, les trois horodatages peuvent tous différer. |
| Référence de session de collecte | string | Clé de corrélation opaque pour les enregistrements produits lors de la même session d'enregistrement. Un concept 'CollectionSession' est prévu dans ADR-013 et formalisera cela ; dans la version 1, les adoptants utilisent un identifiant de session libre (par exemple, un identifiant de visite sur le terrain). |
| Parties |
| Personne concernée | concept:Party comprend Person, Group, Household, Family, Farm | La personne physique (ou parfois le groupe) dont les données personnelles sont traitées dans le cadre de cet enregistrement. Party est le supertype abstrait couvrant Person et Group. Farm est exclu : les exploitations agricoles ne sont pas des personnes physiques ni des bénéficiaires légaux au titre d'aucune loi sur la protection des données. Lorsque 'data_subject' est un Group, 'delegation_type' ne doit pas être 'self'. |
| Responsables du traitement | concept:Organization | Organisations qui déterminent les finalités et les moyens du traitement. La cardinalité multiple couvre la responsabilité conjointe (deux organisations ou plus conjointement responsables au titre de l'article 26 du RGPD ou des dispositions nationales équivalentes) ; le cas normatif est un seul responsable du traitement. Voir 'recipient_role' pour distinguer les sous-traitants des responsables parmi les destinataires. |
| Destinataires | concept:Organization | Organisations qui reçoivent les données ou leurs dérivés. Comprend les sous-traitants, les responsables conjoints du traitement et les responsables indépendants du traitement. Voir la propriété parallèle 'recipient_role' pour le rôle de chaque destinataire. |
| Rôle du destinataire | string (recipient-role) | Le rôle joué par chaque destinataire : sous-traitant, responsable conjoint du traitement, responsable indépendant du traitement ou sous-traitant de rang inférieur. Limitation connue : la version 1 utilise un alignement positionnel avec 'recipients' (la Nième valeur de recipient_role correspond au Nième destinataire). Un futur ADR réifiera les rôles par lien. Les adoptants qui ne peuvent pas garantir l'alignement positionnel devraient utiliser un seul destinataire et un seul rôle par enregistrement, ou représenter la relation de manière externe. |
| Catégories de destinataires autorisées | string (organization-type) | Catégories d'organisations autorisées à recevoir les données, telles que décrites à la personne concernée dans l'avis. Complète 'recipients', qui désigne des organisations spécifiques. À utiliser lorsque les organisations destinataires spécifiques ne sont pas préidentifiées au moment du consentement. |
| Indiqué par | concept:Agent comprend Person, Organization, SoftwareAgent | L'agent (généralement une Person, parfois un SoftwareAgent) qui a indiqué l'acte de consentement. Pour le consentement propre, la même Person que 'data_subject'. Pour le consentement délégué, un tuteur légal, un parent ou un représentant. Voir 'delegation_type' pour décrire la base de la délégation. |
| Type de délégation | string (delegation-type) | La base selon laquelle 'indicated_by' agit au nom de 'data_subject'. La valeur 'self' indique l'absence de délégation : la personne concernée a indiqué son propre consentement. Toutes les autres valeurs indiquent qu'un tiers a agi au nom de la personne concernée. |
| Témoigné par | concept:Person | Personnes qui ont été témoins de l'indication du consentement par la personne concernée. Essentiel sur le terrain pour le consentement verbal ('collection_medium = verbal') et pour la biométrie en tant que signature ('consent_expression = opt-in-biometric') et les signatures témoignées ('consent_expression = opt-in-witnessed') ; les adoptants devraient renseigner ce champ même si l'interface de saisie de données ne l'exige pas. |
| Traitement |
| Finalités du traitement | uri | Les valeurs sont des URI W3C DPV, sous-classes normatives de `dpv:Purpose` (par exemple `dpv:ServiceProvision`, `dpv:ResearchAndDevelopment`). Chaque URI identifie une finalité pour laquelle des données personnelles sont traitées dans le cadre de cet enregistrement. Voir `docs/dpv-vocabulary-reference.md` pour une liste de démarrage. |
| Catégories de données personnelles | uri | Les valeurs sont des URI W3C DPV, sous-classes normatives de `dpv:PersonalData` (du noyau DPV ; l'extension DPV-PD définit des taxons plus fins). À ne pas confondre avec la méthode de collecte biométrique, qui est `consent_expression = opt-in-biometric` sur cet enregistrement. Les catégories de données biométriques sont des valeurs de cette propriété (par exemple, un URI pour empreinte digitale, image faciale). |
| Opérations de traitement | uri | Les valeurs sont des URI W3C DPV, sous-classes normatives de `dpv:Processing` (par exemple `dpv:Collect`, `dpv:Store`, `dpv:Share`). Décrit les opérations faisant l'objet du consentement. Référence : RGPD Art 4(2) pour la définition du terme 'traitement'. |
| Base juridique | string (legal-basis) | La base juridique au sens de l'Art 6(1) du RGPD (ou équivalent national) autorisant le traitement. Cardinalité multiple car un enregistrement peut s'appuyer sur plus d'une base ; l'usage normatif sur un ConsentRecord est d'une base. Sur un PrivacyNotice, plusieurs bases peuvent coexister si l'avis couvre plusieurs opérations de traitement. Champ critique : à renseigner même si votre interface ne l'exige pas. |
| Base catégorie spéciale | string (special-category-basis) | Lorsque `personal_data_categories` comprend une catégorie particulière (RGPD Art 9 / `dpv:SpecialCategoryPersonalData`), cette propriété identifie la base au titre de l'Art 9(2) qui autorise le traitement. Obligatoire lorsque des données Art 9 sont concernées ; omis sinon. Champ critique : à renseigner même si votre interface ne l'exige pas. |
| Référence de la base juridique | string | Référence juridique propre à une juridiction (par exemple, une loi nationale, un article ou une citation jurisprudentielle) étayant `legal_basis`. Chaîne libre ; utiliser les normes de la juridiction concernée. Exemple : 'Ley 1581 de 2012, Art 6(a)' en Colombie. |
| Accord de responsabilité conjointe | string | Référence à l'accord de responsabilité conjointe entre les parties listées dans `controllers` (RGPD Art 26). Généralement un URI vers un accord publié ; un identifiant local est acceptable si un URI n'est pas applicable. À renseigner lorsque la cardinalité de `controllers` est supérieure à un. |
| Information |
| Avis de confidentialité | concept:PrivacyNotice | L'enregistrement PrivacyNotice qui a été présenté à la personne concernée au moment du consentement. Ancre l'enregistrement à une version précise de l'avis. |
| Version de l'avis | string | Instantané dénormalisé de la valeur `version` du PrivacyNotice au moment du consentement. Épinglé par conception : si le PrivacyNotice est ultérieurement corrigé ou reversionné, cette valeur NE DOIT PAS être mise à jour. Permet de démontrer quel texte de l'avis la personne concernée a effectivement vu (RGPD Art 7(1), démontabilité). |
| Langue de présentation de l'avis | string (language) | Le code de langue ISO 639-3 dans lequel l'avis a été présenté à la personne concernée au moment du consentement. Champ critique : à renseigner même si l'interface ne l'exige pas. Lorsque l'avis est disponible en plusieurs langues (voir PrivacyNotice `available_languages`), ce champ enregistre celle que la personne concernée a effectivement vue. Pour le consentement verbal avec témoin, il enregistre la langue de la délivrance verbale. |
| Validité et juridiction |
| Date d'entrée en vigueur | date | La date à laquelle cet enregistrement ou cet avis devient opérationnel. Sur un ConsentRecord, elle peut être postérieure à signed_date (le jour où la personne concernée a indiqué son consentement) et à created_at (l'horodatage de numérisation); pour les flux sur support papier, signed_date est le jour de la signature du formulaire papier et effective_date est généralement le même jour, mais peut être retardée par la logique du programme. Sur un PrivacyNotice, il s'agit de la date à partir de laquelle cette version de l'avis s'applique; les enregistrements recueillis avant cette date renvoient à la version antérieure via supersedes_ref. |
| Date de signature | date | Le jour où la personne concernée a indiqué son consentement. Pour les flux sur support papier, le jour de la signature du formulaire papier; pour le consentement verbal avec témoin, le jour de l'indication verbale; pour le numérique, le jour du clic de validation. NE PAS confondre avec created_at (l'horodatage de numérisation, qui peut intervenir plusieurs jours ou semaines plus tard dans les programmes prioritairement sur papier) ni avec effective_date (la date d'entrée en vigueur de l'enregistrement). Critique pour la collecte: à renseigner même si l'interface ne capture que created_at. |
| Date d'expiration | date | La date à laquelle cet enregistrement ou document expire ou devient invalide. |
| Juridiction | string (country) | Code pays ISO 3166-1 alpha-2 de la juridiction dont la législation sur la protection des données régit cet enregistrement. Cardinalité simple: les enregistrements multi-juridictionnels sont rares; un ADR ultérieur lèvera la contrainte si les adoptants en ont besoin. En cas de responsabilité conjointe, il s'agit de la juridiction du siège principal du responsable chef de file. |
| Preuve de collecte |
| Support de collecte | string (collection-medium) | Le support par lequel le consentement a été recueilli: papier, électronique, verbal ou mixte. Le papier est le support dominant dans les programmes humanitaires et de protection sociale en milieu rural; les systèmes électroniques qui ignorent les flux papier excluent la pratique réelle. Critique pour la collecte: à renseigner même si le système suppose par défaut un support électronique. |
| Expression du consentement | string (consent-expression) | La forme sous laquelle le consentement a été exprimé: opt-in explicite, opt-in signé, opt-in avec témoin, opt-in biométrique, opt-out ou implicite. Référence croisée importante: opt-in-biometric désigne la méthode de capture (par exemple, empreinte digitale comme signature), et non la catégorie de données. Le traitement de données biométriques est exprimé via personal_data_categories (un URI de dpv-pd ou équivalent). |
| Référence aux pièces justificatives | string | Références aux artefacts de preuve appuyant cet enregistrement. Les valeurs sont généralement des URI (par exemple, une URL signée vers un objet stocké) mais un identifiant local est acceptable si un URI n'est pas applicable. Les types d'artefacts comprennent: scans PDF de formulaires papier signés, photos de registres de consentement, enregistrements audio de consentements verbaux avec témoin, et documents numériques signés. Au moins un evidence_ref est fortement recommandé pour collection_medium dans {papier, verbal, mixte}. Critique pour la collecte: à renseigner même si l'URI de l'artefact n'est disponible qu'après le téléversement. |
| Vérifié par | concept:Person | Personne ayant vérifié l'enregistrement de consentement (par exemple, un travailleur social examinant un formulaire papier numérisé, ou un auditeur confirmant un échantillon d'enregistrements). À distinguer de witnessed_by (qui a observé l'acte de consentement) et de indicated_by (qui a exprimé le consentement). Facultatif mais précieux pour les flux de travail auditables. |
| Date de vérification | date | Date de l'acte de vérification effectué par verified_by. Généralement postérieure à signed_date. |
| Statut et retrait |
| Statut | string (consent-status) | L'état actuel du cycle de vie de l'enregistrement: demandé, accordé, renouvelé, refusé, retiré, révoqué, expiré, invalidé ou inconnu. Les transitions suivent la machine d'état documentée dans docs/consent-lifecycle.md. given déclenche l'immutabilité des champs de conditions (data_subject, controllers, recipients, purposes, etc.); voir l'annotation immutable_after_status sur chaque propriété concernée. |
| Canal de retrait | string (withdrawal-channel) | Le canal par lequel la personne concernée a retiré son consentement: web, mobile, api, papier, verbal, en-personne-bureau, agent-communautaire ou autre. À renseigner lorsque le statut passe à withdrawn. Critique pour la collecte: les adoptants doivent enregistrer le canal même lorsque le retrait arrive par une voie non numérique. |
| URI de retrait | uri | URI exposée à la personne concernée pour le retrait autonome de son consentement. Exigée par l'article 7(3) du RGPD ('il doit être aussi facile de retirer son consentement que de le donner'). À renseigner sur le ConsentRecord lorsque le responsable du traitement propose un point d'accès en libre-service. |
| Motif de retrait | string | Motif de retrait en texte libre, si la personne concernée le communique. La personne concernée n'est pas tenue de donner un motif; ce champ existe pour les cas où elle le fait, à des fins d'amélioration du service par le responsable du traitement. |
| Motif de refus | string | Motif de refus en texte libre lorsque la personne concernée a décliné le consentement (statut = refused). À distinguer de withdrawal_reason, qui s'applique après qu'un consentement a été initialement accordé puis retiré ultérieurement. |
| Conservation |
| Durée de conservation (jours) | integer | Durée de conservation prévue pour les données personnelles couvertes par cet enregistrement, exprimée en jours. Pilote la logique de rétention dans les systèmes en aval. Zéro signifie: ne pas conserver après le traitement. Null (non renseigné) signifie: la durée est décrite en prose dans le champ retention_description de la PrivacyNotice plutôt que codée. |