Retire le responsable de traitement des demandes API Entreprise

[Isalafont]

Le problème

API Entreprise demande de ne plus exiger le responsable de traitement sur ses habilitations. En administration, il est déjà connu (DAC, maire), change souvent et n’est pas maintenu : le référent utile est le contact métier, déjà demandé.

Le changement

Même geste que le retrait côté API Particulier (#327), sans le renommage vers le contact métier puisqu’il existe déjà :

• AuthorizationRequest::APIEntreprise n’inclut plus GDPRContacts, le DPO est redéclaré en tête des contacts (ordre d’affichage inchangé). Validation, affichage, mail RGPD et fixture des e-mails automatiques suivent seuls, sur les 18 formulaires.
• api_entreprise_through_editor.html.erb, seule vue à lister ses contacts en dur, ne rend plus le bloc.
• Une migration crée une BulkAuthorizationRequestUpdate sur api_entreprise : modale au demandeur à sa prochaine visite du résumé, et entrée dans l’historique. Auteur en production : User.find(43_809), pas d’e-mail en dur.

Aucune donnée n’est modifiée : les clés responsable_traitement_* restent dans data. Un ancien responsable de traitement garde donc l’accès en lecture et voit la demande dans ses mentions.

Effets de bord à connaître

• Webhooks : les champs responsable_traitement_* disparaissent du payload API Entreprise, stock compris. À signaler à API Entreprise.
• CRM Hubspot : le responsable de traitement n’est plus poussé.
• API v1 : sérialise data brut, le stock continue d’exposer ces champs, pas les nouvelles demandes (même situation qu’API Particulier).

Tests corigés / ajoutés :

• Nouvelle spec modèle et nouveau contexte DeliverGDPRContactsMails (DPO seul, même avec une clé legacy en data).
• Nouvelle feature habilitations/api_entreprise/responsable_de_traitement.feature, vue rouge sur le code de develop.
• Specs et features existantes qui remplissaient le responsable de traitement sur API Entreprise basculées sur le DPO.

Recette : retrait du responsable de traitement sur API Entreprise (sandbox)

1. Nouvelle demande via un formulaire éditeur (compte user@yopmail.com)

• Aller sur API Entreprise, choisir « Conformité titulaires de marchés » de l’éditeur « Approval », puis cliquer sur « Débuter ma demande ».
• Attendu : le bloc « Responsable de traitement » n’apparaît plus. Le bloc « Délégué à la protection des données » est toujours là. Les contacts métier et technique sont préremplis par l’éditeur.
• Remplir uniquement le délégué à la protection des données, puis cliquer sur « Enregistrer et continuer vers le résumé ».
• Attendu : on arrive sur le résumé sans erreur, et le résumé ne mentionne pas de responsable de traitement.
• Cocher les conditions générales, puis cliquer sur « Soumettre la demande ».
• Attendu : le message « soumise avec succès » s’affiche.

2. Nouvelle demande via le formulaire standard en plusieurs étapes (même compte)

• Démarrer une demande API Entreprise hors éditeur et avancer jusqu’à l’étape des contacts.
• Attendu : on voit le délégué à la protection des données, le contact métier et le contact technique. Il n’y a pas de responsable de traitement.
• Aller jusqu’à la soumission. Attendu : aucune erreur ne demande un responsable de traitement.

3. Validation par l’instruction (compte datapass@yopmail.com)

• Se connecter avec datapass@yopmail.com

• Valider l'une des des demandes Api Entreprise soumise.

• Attendu : le message «La demande d’habilitation a été validé » s’affiche.

• Attendu : seul le délégué à la protection des données reçoit un mail RGPD. Le responsable de traitement n’en reçoit plus. Côté formulaire, la liste des emails automatiques d’API Entreprise affiche « 3 emails automatiques » au lieu de 4.

• En local : Ouvrir http://localhost:/letter_opener. Il doit y avoir un mail pour le délégué à la protection des données et aucun pour un responsable de traitement.
  Sur Sandbox

• Par le dashboard GoodJob /workers https://sandbox.datapass.api.gouv.fr/workers Il faut être admin, avec datapass@yopmail.com. Après la validation, les jobs ActionMailer::MailDeliveryJob montrent le mailer appelé : on doit trouver GDPRContactMailer#delegue_protection_donnees et aucun GDPRContactMailer#responsable_traitement.

4. Demande existante, créée avant le déploiement (compte du demandeur de cette demande)

• Ouvrir le résumé d’une demande ou d’une habilitation API Entreprise antérieure au déploiement.
• Attendu : une fenêtre annonce la mise à jour globale : « Le responsable de traitement n’est dorénavant plus demandé… ». Elle ne s’affiche qu’une seule fois par personne. Le bloc « Les personnes impliquées » n’affiche plus le responsable de traitement, même s’il avait été renseigné.
• Côté instruction, l’historique de la demande contient l’événement de mise à jour globale.

6. Non-régression sur une autre API

• Démarrer une demande API scolarité de l’élève.
• Attendu : le responsable de traitement est toujours demandé.

Ref DPP-99, côté APIM : API-7366.

[linear]

DPP-99