ETQ Développeur, je veux pouvoir identifier correctement les champs des dossiers reçus par api

[apibrac]

Lorsque j'utilise l'api (graphql) pour récupérer et traiter automatiquement les dossiers de mes démarches, je ne peux pas identifier correctement les différents champs que je reçois. Seuls l'id et le label du champ sont disponibles :

L'id n'est pas utilisable car :

• si mon code traite plusieurs démarches identiques, les ids sont différents (par exemple une démarche par environnement pour pouvoir faire la recette de ce même bout de code ; ou en cas de modification de la démarche, ce qui implique parfois une duplication).

Le label n'est pas utilisable facilement car :

• Il doit être répété dans le code.
• Il peut être très long (sous la forme de question) donc sujet à erreur de typo.
• Il peut être modifié (en cas de modification / duplication de la démarche) ce qui rend très complexe la gestion de plusieurs démarches quasi identiques par le même code.
• In fine il n'est tout simplement pas destiné à un traitement automatisé par un programme, plutôt aux utilisateurs de ma démarche.

---

Proposition de solution : Ajouter un label technique à tout mes champs, pouvoir le régler lorsque je créé mon formulaire, et le retrouver dans l'api pour pouvoir identifier chaque champ selon ce label. Cela me permet d'utiliser le même dans mes différentes démarches quasi identiques, pour que le même code les traite. Inspiration : le "name" des différents champs d'un formulaire html, qui permet au javascript ou à l'api qui reçoit les valeurs d'identifier chaque champ sans se soucier du label pour l'humain (son langage, sa complexité, son intention).

Proposition complémentaire : Pour simplifier son introduction, je propose qu'il reçoive le minimum de contrainte possible :

• champ texte complètement libre
• optionnel (défaut à "")
• aucune validation (telle que l'unicité) Ainsi : charge au développeur qui paramètre le formulaire et qui traite les réponse à api d'en faire un bon usage. Cela simplifie l'introduction puisque rien ne change pour les anciens usagers ni pour les nouveaux qui ne veulent pas l'utiliser. Et cela ne présuppose pas d'usage, donc les futurs développeurs pourront y mettre ce qui est pratique pour eux, un peu comme les métadonnées qui sont habituellement des cases vides utilisées très différemment en fonction des cas.

(j'en avais discuté rapidement avec certains dev demarches-simplifiees lorsqu'ils étaient venu voir l'équipe pass Culture, et nous avait suggéré de le faire nous, je veux bien faire une PR ! à dispo si besoin de plus d'info ou d'en discuter)

[tchak]

Merci pour cette issue. Je comprends bien le problème. Nous allons en parler avec l'équipe.

Ce qui m'embête le plus c'est un problème d'UI. Si on ajoute le champ "nom" dans l'éditeur de champs ça va créer énormément de confusion – beaucoup d'administrateurs qui utilisent DS ne sont pas "techniques" et leur exposer une options de config qui n'est utile que pour l'API c'est non. Je suis en train de penser qu'on pourrait ajouter une mutation qui permettrait d'assigner un nom technique aux champs via l'API. C'est un peu moins pratique pour le développeur, mais au moins on reste dans le domaine de l'API.

[apibrac]

Merci pour ta réponse @tchak !

Effectivement le rendre modifiable via l'api est une solution, ça rendrait le champ très caché. On pourrait alors lui donner un nom très explicite comme quoi c'est un nom uniquement technique. L'inconvénient est qu'une fonctionnalité très cachée est peu utilisée...

Pour aller plus loin, il pourrait même y avoir une api pour créer des formulaires, ce qui nous permettrait (côté développeur) de coder chez nous la structure de ce formulaire et de créer ou modifier les formulaires automatiquement. Ainsi en répétant la même création dans les différents environnements on s'assurerait d'avoir des formulaires consistants.

Je te propose deux autres solutions pour rendre ce champ intelligible, si ça peut alimenter ta réflexion :

• cacher l'input dans le formulaire de création/édition des formulaire et ne la montrer que pour certains utilisateurs, ceux qui auraient demandé à débloquer la fonctionnalité (un peu comme les webhooks, ça pourrait même être le même marqueur puisque ça identifie des interlocuteurs techniques ?). Ainsi rien ne change pour les non techniques.

• plutôt que de cacher le champ, aller à fond et l'exposer plus, en lui trouvant un usage y compris pour les interlocuteurs non techniques. Par exemple : lors de la visualisation d'un dossier par un instructeur, ne pas identifier les champs via la question "Quel est votre nom ?" mais via ce nouveau nom de champ "Nom :". Vous pourriez alors axer clairement la différence entre "label externe, à destination de ceux qui déposent un dossier" et "nom interne, à destination de ceux qui les traitent". Utile aux tech et aux non techs (usage pour les non tech à vérifier, un peu inventé pour le coup)

[tchak]

@apibrac on peut s'organiser un call ? Tu es sur Mattermost de betagouv ou pas du tout ? Tu peux m'envoyer un email le cas échéant ?