Consentements légaux — pourquoi ils existent et comment les traiter
Concerne le formulaire Demande de prêt scolaire (SchoolLoanView.vue), stockés dans loan_requests.additional_data, affichés en lecture seule dans le backoffice (Fiche détail prêt).
Vérifié le 2026-08-12 — toujours exact.
Les champs
| Champ | Signifie |
|---|---|
consent_data_processing | Le client accepte que ses données personnelles (identité, coordonnées, situation professionnelle et financière) soient collectées et traitées par l'UTB, et consultées par les agents/analyste/responsable de zone en charge de l'instruction. |
consent_electronic_signature | Le client reconnaît que la validation électronique du formulaire vaut signature manuscrite. |
consent_date | Horodatage ISO du moment de la soumission — la preuve du "quand". |
Pourquoi les stocker (et pas juste bloquer la soumission côté client)
Une case à cocher qui bloque uniquement l'envoi côté navigateur, sans être transmise et enregistrée, ne prouve rien après coup. Si un client conteste un jour ("je n'ai jamais accepté que mes données soient traitées", ou la validité de sa signature électronique), la seule preuve opposable par la banque est un enregistrement horodaté de ce qu'il a précisément accepté, associé à sa demande. C'est le cas classique où le code doit produire une preuve, pas juste une friction UX.
Dans un contexte bancaire togolais, ça rejoint les exigences de la loi sur la protection des données à caractère personnel : pouvoir démontrer un consentement explicite et daté, pas simplement l'affirmer.
Règle absolue : jamais éditables après soumission
Le backoffice (Fiche détail prêt) affiche ces champs en lecture seule, en dehors du système de brouillon éditable (draft) qui couvre tous les autres champs du dossier. Ne jamais les rendre modifiables — un gestionnaire qui pourrait éditer après coup ce qu'un client a "consenti" viderait complètement leur valeur de preuve.
Historique : le champ consent_communications a été retiré
Une case "communications marketing" (consentCommunications/consent_communications) a existé un temps dans formData et dans le payload envoyé au backend, mais aucune case à cocher réelle ne l'accompagnait dans le template. Le champ était donc systématiquement envoyé à false, ce qui laissait croire que le client avait explicitement refusé — alors qu'il n'avait jamais été sollicité sur ce point. Le champ a été supprimé du formulaire et du payload. Ne pas le réintroduire sans, cette fois, une vraie case à cocher visible et testée de bout en bout (checkbox → formData → payload → stockage).
Formulaires n'ayant pas (encore) ces consentements
Seul SchoolLoanView.vue envoie ces champs actuellement. DemandePretView.vue (formulaire de prêt générique) ne les collecte pas — c'est pour ça que la carte "Consentements du client" du backoffice ne s'affiche que si additional_data.consent_date existe, pour ne pas donner une fausse impression de refus sur les dossiers issus de cet autre formulaire.