Principe

Un formulaire n'est jamais codé en dur : il est décrit par un schéma JSON. Le renderer parcourt fields, mappe chaque type vers le composant bpm correspondant, évalue les conditions visibleIf à chaque saisie et n'exige un champ requis que s'il est visible. Ajouter un champ ou une règle métier revient à modifier le schéma — pas le code.

Types de champs

text — saisie libre (bpm.input).
number — valeur numérique, ex. montant estimé (bpm.input type="number").
date — sélecteur de date au format FR (bpm.dateInput).
select — liste déroulante avec options (bpm.selectbox).
radio — choix exclusif court, ex. profil lecture/écriture/admin (bpm.radioGroup).
checkbox — choix binaire, ex. demi-journée (bpm.checkbox).
textarea — texte long : commentaire, justification, motif (bpm.textarea).

Conditions `visibleIf`

Une condition observe un autre champ du même formulaire et se réévalue à chaque saisie. Deux opérateurs sont supportés :

equals — égalité stricte. Ex. la justification n'apparaît que si type_conge = "sans_solde" ; motif et durée que si profil = "admin".
greaterThan — comparaison numérique. Ex. la validation directeur apparaît si montant > 1000.

Les mêmes conditions pilotent les messages : des bandeaux bpm.message (info, warning) affichés en contexte, par exemple l'avertissement de seuil d'achat.

Validation

Requis conditionnel — required: true ne s'applique que si le champ est visible : un champ masqué n'est jamais bloquant.
Format numérique — un champ number doit contenir un nombre positif.
Contrôle croisé — dateRange vérifie que la date de fin suit la date de début.
Restitution — chaque erreur s'affiche sous le champ concerné ; la soumission n'aboutit qu'à zéro erreur, puis produit un récapitulatif et une entrée dans « Demandes soumises ».

Exemple complet — schéma « Achat de matériel »

{
  "id": "achat-materiel",
  "title": "Achat de matériel",
  "fields": [
    {
      "id": "categorie",
      "label": "Catégorie",
      "type": "select",
      "required": true,
      "options": [
        { "value": "informatique", "label": "Informatique" },
        { "value": "mobilier", "label": "Mobilier" },
        { "value": "logiciel", "label": "Logiciel" }
      ]
    },
    {
      "id": "montant",
      "label": "Montant estimé (€ HT)",
      "type": "number",
      "required": true
    },
    {
      "id": "description",
      "label": "Description du besoin",
      "type": "textarea",
      "required": true
    },
    {
      "id": "validation_directeur",
      "label": "Validation directeur (montant > 1 000 €)",
      "type": "select",
      "required": true,
      "options": [
        { "value": "c.moreau", "label": "C. Moreau — Directeur des opérations" },
        { "value": "a.petit", "label": "A. Petit — Directrice financière" }
      ],
      "visibleIf": { "field": "montant", "operator": "greaterThan", "value": 1000 }
    }
  ],
  "messages": [
    {
      "id": "msg-seuil",
      "type": "warning",
      "text": "Montant supérieur à 1 000 € HT : validation directeur obligatoire.",
      "visibleIf": { "field": "montant", "operator": "greaterThan", "value": 1000 }
    }
  ]
}

Intégration en production

Le simulateur embarque trois schémas seedés en état local. En production, servir les schémas depuis une API (table form_schemas versionnée), conserver le même renderer côté client, et persister chaque soumission validée (l'équivalent du tableau « Demandes soumises ») avec son statut de circuit d'approbation.

Ouvrir le simulateur

Documentation — Formulaire dynamique