Un formulaire de vingt questions avec des sauts conditionnels est un programme, et les éditeurs de formulaires ne le montrent jamais comme un programme. On découvre le chemin cassé quand un répondant tombe dedans.
Le graphe
L’outil lit un formulaire par l’API et en dessine l’arbre complet : chaque question, chaque écran de fin, chaque saut conditionnel avec sa condition affichée sur la flèche et le chemin par défaut en pointillés. On peut zoomer et changer l’orientation, parce qu’un formulaire long est illisible dans un seul sens.
Le diagnostic est la vraie fonctionnalité : il compte les questions, les obligatoires, les sauts et les variables, puis signale les questions et écrans de fin devenus inaccessibles et les sauts qui pointent dans le vide. Ce sont les deux pannes classiques d’un formulaire qu’on a modifié six fois, et elles ne se voient pas dans l’éditeur : on ne voit que ce qu’on a ajouté, jamais ce qu’on a débranché.
L’édition
Deux niveaux. L’édition simple, en ligne, pour les intitulés, celle qu’on fait vingt fois par jour. Et l’édition de la définition brute, pour la logique et les validations, là où l’interface d’origine devient une suite de menus déroulants. Puis on enregistre, et ça écrit sur le formulaire publié : c’est un outil d’atelier, pas une maquette. Le serveur retire au passage les champs en lecture seule que l’API refuse en écriture, ce qui est exactement le genre de détail qui fait échouer un premier essai.
Ce que j’en retiens
Le jeton reste côté serveur : le navigateur ne voit jamais la clé, tout passe par un proxy local. C’est une règle bête que je répète dans tous ces outils, parce que la version paresseuse. La clé dans le front, « c’est juste en local », finit toujours par être déployée quelque part.
Plus largement, c’est le plus petit des copilotes et l’un des plus rentables : trois cents lignes pour rendre visible une structure que l’outil officiel cache, et le temps gagné se compte en heures dès le premier formulaire audité.