[Refactoring] Traitement des données spécifiques à Publicodes en dehors du traitement des données de questionnaire

pierrecamilleri commented 10 months ago

Contexte

Aujourd'hui, les réponses au questionnaire sont transformées à la volée dans le front-end en variables utiles par publicode (y compris des contournements des limites de publicodes)

Par exemple codeNAF1 = ["A", "B"] est transformé en :

entreprise . code NAF niveau 1 . est A: "oui",
entreprise . code NAF niveau 1 . est B: "oui",
entreprise . code NAF niveau 1 . est C: "non",
entreprise . code NAF niveau 1 . est D: "non",
entreprise . code NAF niveau 1 . est E: "non",
entreprise . code NAF niveau 1 . est F: "non",
entreprise . code NAF niveau 1 . est G: "non",
entreprise . code NAF niveau 1 . est H: "non",
entreprise . code NAF niveau 1 . est I: "non",
entreprise . code NAF niveau 1 . est J: "non",
entreprise . code NAF niveau 1 . est K: "non",
entreprise . code NAF niveau 1 . est L: "non",
entreprise . code NAF niveau 1 . est M: "non",
entreprise . code NAF niveau 1 . est N: "non",
entreprise . code NAF niveau 1 . est O: "non",
entreprise . code NAF niveau 1 . est P: "non",
entreprise . code NAF niveau 1 . est Q: "non",
entreprise . code NAF niveau 1 . est R: "non",
entreprise . code NAF niveau 1 . est S: "non",
entreprise . code NAF niveau 1 . est T: "non",
entreprise . code NAF niveau 1 . est U: "non"

Le problème

Ce processus pose deux problèmes :

Cela crée un grand couplage entre le front et publicodes. Tout changement de publicodes en une autre solution technique impliquerait de changer, question par question, ce traitement de données spécifique dans le front-end.
Les données de questionnaires ne sont pas uniquement utiliséees par publicodes, mais potentiellement par d'autres services, en l'occurrence on a déjà Brevo.

Par ailleurs, la seule limitation que cela introduirait est que dans la conditionnalité des questions ("si telle conditon, se rendre à telle question"), on ne pourrait pas utiliser des champs calculées. Dans la mesure ou les champs calculés le sont pour publicodes, et qu'aujourd'hui ce cas de figure n'arrive pas, ce n'est pas un problème.

Solution

Migrer les calculs spécifiques à publicodes dans une étape de preprocessing spécifique, comme j'ai commencé à le faire ici.

Lorsque le filtrage sera dans le backend, le preprocessing aura vocation à être dans le backend également.

ttdm commented 5 months ago

J'aimerai confirmer une règle de filtrage qui me semble étrange et qui m'a fait tourner en rond pendant des heures :

Lorsque l'on a pas le SIRET et que l'on choisi son secteur à la main, pour tous les choix, on met d'abord tous les CodeNAF1s existants à 'non' puis on modifie à 'oui' les codes NAF qui correspondent au secteur...
SAUF pour le premier secteur, craftmanship, où l'on met uniquement à 'oui' les codes NAF du secteur.

Est ce un choix volontaire ou est-ce un bug/un oubli ?

pierrecamilleri commented 5 months ago

J'aimerai confirmer une règle de filtrage qui me semble étrange et qui m'a fait tourner en rond pendant des heures :

* Lorsque l'on a pas le SIRET et que l'on choisi son secteur à la main, pour tous les choix, on [met d'abord tous les CodeNAF1s existants à 'non'](https://github.com/betagouv/transition-ecologique-entreprises-widget/blob/27d73e1d048089d915a1ccfaf791b4e1084c5a90/packages/web/src/questionnaire/trackStructureSectors.ts#L41C1-L41C22) puis on modifie à 'oui' les codes NAF qui correspondent au secteur...

* SAUF pour le premier secteur, craftmanship, où l'on met uniquement à 'oui' les codes NAF du secteur.

Est ce un choix volontaire ou est-ce un bug/un oubli ?

C'est un oubli (qui a pour conséquence de montrer plus de dispositifs que prévu dans ce cas de figure).

Désolé pour l'obstacle :/

betagouv / mission-transition-ecologique