DP-1869 — Formulaire d’habilitation « Produits DINUM » (V1)

[Isalafont]

Contexte

Nouveau formulaire d’habilitation « Produits DINUM » (accès groupé aux produits de la Suite numérique), issu du cadrage DP-1868 et de la réunion juridique du 08/07 (DP-1851).

Implémenté en dur dans le code (STI)

Ce que fait la PR

Formulaire à 2 étapes :

1. Cadre juridique — champ « Nature juridique de votre structure » + justification either/or : URL du texte ou document justificatif, au moins l’un des deux (validation au niveau du modèle). Rendu conforme à la maquette (2 encadrés).
2. Contacts — DPD, « Responsable de l’administration », « Référent des outils numériques de l’administration ».

Pas d’étape « Nom du projet ». CGU en case à cocher standard. Pas de sélection de produits (liste dans l’introduction).

Décisions clés

• STI (AuthorizationRequest::ProduitsDinum + config/authorization_request_forms/produits_dinum.yml + authorization_definitions/produits_dinum.yml) plutôt qu’un type dynamique en base : le formulaire vit dans le code → aucune manip en base (ni local, ni staging, ni prod).
• Contacts recyclés + renommés par form_uid (pas de contact_types dédiés) : responsable_traitement → « Responsable de l’administration » (déjà notifié par email à la validation = besoin métier), contact_technique → « Référent des outils numériques de l’administration ».
• Amélioration système : le titre des contacts devient surchargeable par formulaire (shared/_contact.html.erb → f.wording_for, cascade form_uid → default, rétro-compatible). Ouvre la voie à de la config par formulaire sans dupliquer de types.
• Cadre juridique = concern AuthorizationExtensions::CadreJuridiqueDinum (bloc legal_dinum), stockage en data, zéro migration.
• .intitule → try(:intitule) dans les vues d’instruction (ce type n’a pas de bloc basic_infos fournissant l’intitulé).

Comment tester

Pas de reseed — le formulaire est dans le code :

1. Redémarrer le serveur (charge le YAML de formulaire).
2. Se connecter en demandeur : /local-sign-in?email=user@yopmail.com
3. Démarrer : /demandes/produits_dinum/nouveau
4. Parcours :
   • Cadre juridique : saisir la nature ; tester le blocage si ni URL ni document ; valider avec l’un des deux.
   • Contacts : DPD + Responsable de l’administration + Référent des outils numériques.
   • CGU : cocher, soumettre → succès.
5. Côté instruction (/local-sign-in?email=datapass@yopmail.com) : ouvrir la demande, vérifier qu’approuver / refuser / demander des modifications ne plantent pas.

Tests automatisés : bundle exec rspec (2955 examples, 0 échec) · bundle exec cucumber features/habilitations/produits_dinum.feature.

Points en attente (hors périmètre technique)

• Lien CGU en placeholder (https://example.org/cgu-produits-dinum, dans authorization_definitions/produits_dinum.yml) → à remplacer par le document juridique.
• Champ « nature de structure » conservé — utilité à reconfirmer côté métier (l’info est dérivable du SIRET de l’organisation, plus fiable que le déclaratif).
• Bouton « C’est moi » affiché sur les contacts recyclés — comportement hérité, à vérifier si pertinent pour ces rôles.

[linear]

DP-1869

[skelz0r]

(désolé je lâche un pavé je me suis lancé dans une réflexion couplé avec des explications en écrivant, le but est d'apporter mon point de vue architecte/concepteur logiciel vis-à-vis des défis que vous avez)

J'ai plusieurs remarques/questions:

1. Pourquoi introduire un champ nature sur l'administration alors qu'on a déjà l'info sur l'organisation ?
2. Pourquoi introduire 2 nouveaux contacts alors qu'il suffit de prendre métier/technique et de modifier uniquement les wordings ?
3. Pourquoi tester tout le formulaire alors que c'est (à priori) en db ?

Si 1. on simplifie, on peut reprendre le bloc existant du legal et si on recycle les contacts métiers/techniques, à priori.. tout peut-être fait directement en db non ? (je ne sais pas si on peut customiser les wordings mais à priori c'est le seul truc qu'il faut faire)

Là ce qui me dérange d'un point de vue technique c'est qu'à chaque fois qu'on introduit un nouveau formulaire en db on introduit des wordings/blocs customs (qui sont pas vraiment des vrais blocs customs, juste des moyens d'utiliser le système en db) sans avoir toute la chaîne, ce qui rend le code très compliqué (vu que y'a du bloc dans le code qui est dépendant de valeurs en db).

Pour illustrer mon point: le bloc legal_dinum -> si le formulaire était dans le code, on pourrait juste override de manière partielle le legal et rendre ça plus clair. Là on se retrouve à devoir introduire des blocs avec des clés différentes alors qu'in fine c'est ~ish la même chose, mais j'ai l'impression qu'il n'y a aucun moyen de faire ces overrides simplement que de redéfinir intégralement le bloc. Si on veut appliquer un override de legal en gardant le formulaire en db, il faudrait créer en amont le formulaire, récupérer le slug, et faire les overrides des wordings avec le bon slug (qui n'aurait du coup aucune réalité dans le code, ce qui serait compliqué 😅). On peut faire une réflexion identique sur les contacts.

J'entends l'envie d'industrialiser du formulaire DataPass, mais ça a du sens sur des blocs straightforward (genre de l'automatisation avec data.gouv par exemple), comme c'est un poil ~ish custom c'est plus tricky et on se retrouve à faire des galipettes très étranges/qui font des noeuds au cerveau ici.

Là à mon sens, sous condition qu'on drop le champ nature (qui est inférable de l'organisation, et surtout plus fiable que ce que dit l'usager non ?), y'a 2 choix qui me semble plus logiques concernant l'implémentation de ce formulaire:

1. En dur dans le code avec les customisations nécessaires -> c'est le plus logique/simple/straightforward, si demain on veut le migrer en db ça sera fait avec tout le reste
2. On itère sur le système de création de formulaire pour customiser les wordings (et les sortir de la db à la volée) -> de là on fait 100% sur l'UI (which is nice)

L'option entre 2 chaises c'est complexifier le système à mon sens (car le système aura un pied de config dans le code et un autre pied de config en prod, qui faut sync et avoir l'image mental du système).

Après c'est une question de stratégie : si il y a beaucoup d'itérations avec plein de champs customs and stuff, l'option 1. me semble la plus logique, si on sait d'avance que ça sera surtout du wording, le 2. est le mieux (limite ça se fait même en live 👍)

C'est de la réflexion high level que j'ai eu à la lecture de cette PR qui me semble compliqué par rapport à l'option 1. en dur qui est assez straightforward 🤔 (et l'option 2. si on est ~ish sûr qu'il n'y a pas de champ custom c'est le plus banger car on peut laisser quelqu'un de la suite faire la config lui même en autonomie, ce qui est j'ai cru comprendre le but in-fine).

Pour aller plus loin: si on sait qu'il va y avoir des champs customs en mode texte souvent, clairement l'option faire un bloc/vue custom à chaque formulaire c'est pas viable, de là y'a plusieurs approches : continuer à faire du code custom sur les cas complexes (i.e. proactivité), ou introduire un colonne qui défini des attributs customs (mais là on commence à s'orienter vers un form builder ala DN)

[Isalafont]

@skelz0r en fait j'en viens à exactement la même conclusion que toi , je vais faire au plus simple et je vais tout reprendre dans ce sens.
Le champs nature pour le cadre legal specialement pour ce formulaire est pour recupèrer une information dont a besoin le pole juridique afin d'alimenter le Grist des organisations (ce qui va infinie permettre de qualifier les orga en is_administration sur pro_connect et nous servir egalement pour le projet en marge du hackaton et en vision de l'automatisation des validations (notamment pour ce formulaire)

Du coup ce n'est pas tout à fait le même champs que pour le cadre legal "normal". (a terme dans une V2, ce champ devra s'auto complete comme pour proactivité en récupérant les info de l'orga)
En tout cas je serais ravie de te faire un point recap car le sujet à long terme est très interessant.

On doit juste push cette V1 pour cette semaine (ou semaine pro) afin de mettre en prod au max fin juillet et entre temps faire les aller retours de wording avec le juridique.

Ps: je suis pas hyper fan de faire des blocs de code custom mais tant que l'on ne gère pas les wordings en mode form builder comme DN, du moins facilement, on n'a pas trop le choix pour ce bloc.

[skelz0r]

Le champs nature pour le cadre legal specialement pour ce formulaire est pour recupèrer une information dont a besoin le pole juridique afin d'alimenter le Grist des organisations

Je m'en suis douté, mais doit y avoir un truc qui m'échappe car la nature d'une organisation on l'a déjà via les APIs, je suppose que la qualification des administrations pour l'alimentation du JDD doivent se faire après examen du cadre juridique global, et les juristes doivent du coup inférer que tel organisation est une administration pour X/Y/Z raison, et du coup après alimenter à la main 🤔 Surtout que c'est un champ libre (soit la porte ouverte à n'importe quoi).

Perso je shipperai sans et je ferai directement 1. parce qu'en fait les personnes en face (i.e. la suite) ne savent pas forcément qu'on a déjà (potentiellement) l'info, et c'est aussi l'occasion de rendre le produit plus legaltech, et ça introduit surtout beaucoup moins de dette.

Faire la v1 avec 1. c'est 1 prompt claude et 0 test à introduire (car c'est déjà testé automatiquement) vu que tout est détaillé dans les procédures, même ajouter un champ custom avec du code c'est trivial ici.

A dispo pour en discuter.

[Un3x]

Je m'abstiens de valider ou non, j'ai juste fait une review purement technique avec mon ignorance complète

[Un3x]

J'avoue qu'ici j'ai du mal à comprendre dans quelle mesure ce fichier est un fichier de test ou non.

Je comprends d'après le contenu que c'est le cas mais d'après le code j'interprête ca comme un fichier qui va partir en prod.

Potentiellement ajoutable en tant que block, je trouve ca limite.

[skelz0r]

C'est un fichier de config de type d'habilitation (comme tout ce qui est dans config/authorization_definitions), vu la potentielle complexité du sujet (i.e. c'est pas un formulaire straightforward) c'est plus simple de le faire en mode code que via le système existant (qui n'est pas assez complet).

Plus de détails sur mon commmentaire plus haut #1677 (comment)

[Un3x]

on est ok ici que ca va continuer d'afficher les anciens wording aussi et les anciesn attributs ? il y a une maj qui a été faite en ce sens dans le partial et le décorator de _contact mais j'ai l'impression que ce serait aussi pertinent.

[skelz0r]

Oui (mais en fait je ne vois pas le rapport avec cette ligne 🤔)

[Isalafont]

J'ai introduit le except: pour ne pas a avoir à afficher certains champs des contact pour le formulaire des produit DINUM et qu'ils ne soient pas bloquer en validation.

Le but étant de ne pas impacté le comportement des autres formulaires existant.
Je ne mergerai de toute façon rien sans avoir testé que nous n'introduisons aucune régression.

[Un3x]

On est d'accord que ici, on skip une potentielle erreur 500 en renvoyant null ?

Juste pour confirmer que c'était bien l'intention

[skelz0r]

Oui, mais imo c'est pas la meilleure approche (car l'intitulé est un champ standard mais parfois absent comme sur HubEE), ici il faudrait utiliser AuthorizationRequest#name https://github.com/etalab/data_pass/blob/develop/app/models/authorization_request.rb#L188 imo

Suggested change

	data-message-template-selector-authorization-request-data-value="<%= { demande_url: authorization_request_url(@authorization_request), demande_intitule: @authorization_request.try(:intitule), demande_id: @authorization_request.id }.to_json %>">
	data-message-template-selector-authorization-request-data-value="<%= { demande_url: authorization_request_url(@authorization_request), demande_intitule: @authorization_request.name, demande_id: @authorization_request.id }.to_json %>">

[Isalafont]

Et c'est le changement que je vais faire, c'était un résidu du passage de formulaire dynamique à STI fait le soir... 👍🏻

[Isalafont]

Pour information, j'ai appliqué les derniers changements suite à ton retour @skelz0r .

Pour le cadre juridique, j'aimerais passer par le bloc de base sauf que cela demande une petite refacto pour qu'il ressemble bien à la dernière version et ça impacterait la tout de suite, tous les formulaires.
Je me suis rendue compte que l'on avait une dette design entre le cadre juridique de base et la version utilisé en view Component pour Api particulier par ex.

Je pense qu'il serait préférable que l'on traite cela dans une PR moins "urgente" et surtout entièrement dédié à cela. La différence de design n'est pas grand chose mais la on commence à sortir du scope de cette PR.

Il me manque encore des infos à récupérer auprès du Pole juridique concernant les envoie d'email.
Je les contacte lundi pour obtenir tout cela, avoir une validation de texte de leur côté.

Du coup, si je passe la PR en Draft ici, est ce que ça aura une incidence sur le deploiement de cette branche sur Sandbox ? @Un3x (si vous avez la réponse à cette question je suis preneuse)

[skelz0r]

Pour moi le design n'est en effet pas à traiter dans le cadre d'une simple configuration de formulaire car ce n'est pas le scope.