Formulaire d’édition

[mquandalle]

Afin de maintenir à jour l'ensemble des aides de l'ensemble des collectivités, on a besoin d'associer largement des contributeurs externes : agents municipaux (exemple #22), associations d'usagers (exemple #68). Naturellement on ne peut pas demander à ces contributeurs motivés d'installer nodejs et vscode, de cloner le dépôt git, de lire la documentation publicodes, de modifier le code et d'ouvrir une pull request sur Github; ce process est bien trop complexe.

L'idée serait donc d'avoir un éditeur visuel permettant de mettre à jour les méta-données de l'aide tout comme de corriger les calculs.

Pour la partie méta-données, on a vu avec @guillett que l'utilisation d'un CMS configurable comme Netlify CMS peut-être un bon moyen d'avoir rapidement une interface fonctionnelle. Cela permet trivialement de gérer des informations statiques telle que le titre, la description, les dates, etc., mais aussi des paramètres conditionnels comme un champ « collectivité » qui puisse gérer tous les cas avec de l'auto-complétion (régions, départements, intercommunalités, communes). D'autres CMS « headless » existent et pourraient être utilisés, par exemple Strapi.

L'équipe betagouv/aides-jeunes développe avec Netlify CMS une telle interface d'édition. Cette interface permet notamment de visualiser l'aide telle qu'elle sera affichée dans l'application. Pour aller plus loin, on pourrait même intégrer l'éditeur directement dans l'application, un peu comme un développeur utilise le « hot reload » en modifiant les fichiers sources. Certains CMS headless permettent ce type de cas d'usage (exemple.

Pour la partie calculs, il me semble difficile d'intégrer toutes les aides existantes dans un schéma tel que celui proposés par les différents CMS. Publicodes fonctionne avec la notion de « mécanisme » qui sont des briques élémentaires simples (produit, somme, plafond, barème, etc.) que l'on peut composer comme on le souhaite. Pour gérer cet aspect dans un éditeur visuel, il faut donc une interface qui puisse supporter une notion de « bloc » que l'on peut composer de manière récursive. Google a par exemple développé Blockly qui répond à ce problème — même si à ma connaissance, ce type d'interface « puzzle » n'a jamais vraiment fonctionné. Une alternative serait de s'inspirer d'avantage de l'auto-complétion des « formules » dans Excel.

Si le but est d'ouvrir la contribution aux aides rapidement, on peut donc effectivement passer par un CMS existant. Les aides publicodes possédant un identifiant unique, il devrait être aisé de leur associer des données provenant d'un outil externe. Reste à définir quelles sont les données que l'on intègre au niveau du CMS. En revanche pour la partie calcul, je pense qu'il faudra en passer par le développement d'un outil spécifique qui permette d'éditer un sous-ensemble restreint de publicodes. S'il n'y a pas d'urgence, peut-être même vaut-il mieux démarrer directement sur cet outil permettant de gérer “nativement” tous les cas particuliers dans le calcul des aides.

(Je me permet de notifier mes camarades @johangirod et @laem que le sujet peut intéresser.)

[guillett]

L'approche côté aides-jeunes, c'est de faire le 80% du 80% / 20% avec l'interface CMS. Pour les 20 % restants, l'interface c'est du code et dans notre cas, du code OpenFisca.

J'ai par ailleurs, expérimenter et regarder de plus près Blockly mais sans y voir de perspectives viables (pour le moment en tous cas).

[mquandalle]

Oui et ça fait sens pour aides-jeunes qui a vocation a intégrer tous types d'aides.

Pour les aides vélo, le fait de se restreindre à un type d'aides assez spécifique autour de l'achat ou la location d'un vélo, peut être l’occasion de créer un éditeur qui puisse gérer 100% des cas — y compris les formules un peu originales de certaines collectivités. On verra bien si c'est réalisable en pratique ou bien s'il est inévitable de devoir gérer certains cas « hors formulaire », mais vu le fichier publicodes actuel, ça me semble réaliste de gérer tout ça dans une UI.

[laem]

Le fait que publicodes soit du JS exécuté côté client ET qu'on ait déjà (en conséquence) la génération de la /documentation pousse à mon avis à tester l'édition des règles directement dans /documentation.

Concrètement en fait, ça revient à intégrer le bac à sable (https://publi.codes/studio) directement dans la doc (sous forme d'option évidemment).

L'utilisateur peut modifier librement son code. Idéalement, on stocke les changements comme un diff de règles dans le localstorage, ce qui permet de voir les changements en "hot update" (juste le flux de données React en fait) dans un autre onglet sur les calculs ciblés. Ou alors une approche telle le studio avec la cible à droite de l'écran, mais qui marche alors seulement sur bureau (pas une grosse contrainte pour ce cas d'usage).

Il y aurait un bouton "ajouter une aide" qui donnerait accès à un tuto puis à un bloc de code type, comme le studio.

Plutôt que de viser la contribution qui compile, ce mode pourrait être très tolérant : "votre code ne compile pas, mais c'est normal, cliquez ici pour envoyer votre contribution qui sera revue par d'autres". Clic -> PR.

Le problème que je vois alors, mais qui est commun à toutes ces solutions qui ne passent pas par github, c'est qu'on n'a pas la discussion entre contributeur / reviewer. Impossible de reproduire ce que github a fait sans une équipe de 5 personnes.

Une version v0 de tout ça serait de ne pas permettre l'édition libre mais simplement permettre de changer les meta des règles et des taux ou valeurs finales des algos.

[mquandalle]

Je ferme ce ticket car je n'ai pas le temps de travailler sur un formulaire de saisie, et je ne crois pas que c'est le meilleur moyen d'avoir de l'impact :

• Au final la saisie des aides va vite une fois qu'on l'a fait quelques fois. Ce qui prend le plus de temps c'est de récupérer les bonnes informations. Un formulaire de contact avec un champ de texte libre répond déjà à ce besoin.
• J'ai eu quelques PR de contributeurs qui ont réussi à s'approprier le publicodes, exemple Mise à jour et ajout d'aides en Drôme-Ardèche #183. Améliorer la documentation et le bac à sable du site https://publi.codes est un axe plus intéressant que de développer un éditeur spécifique à mesaidesvelo. Et comme le disais Mael, ce n'est pas grave s'il y a quelques erreurs de syntaxe ou de calcul, le relecteur peut les corriger.
• Je préfère me concentrer sur le développement du site et de ses fonctionnalités : nouveaux types de vélo, meilleures explications des aides (Refonte nouvelle prime à la conversion #176), aide au choix du vélo, travail sur le référencement, etc.