on conditionne au fait qu'on teste l'unicité d'un champ

mettre la case rafraichir le cache avant affichage résumé de la réponse, juste pour des raisons esthétiques

- Réglages généraux
- Données personnelles
- Divers

Etape 1 : ordonner les champs

label + explication pour la variable d'anonymisation + pas besoin d'une chaine de langue pour l'intro du select (surtout avec un nom absolument pas explicite)

identification ne sert pas que pour la modification des réponses, mais aussi pour interdire les réponses multiple, on reformule la chaîne de langue.

1. n'était utilisé que deux fois
2. était redondante avec le système d'afficher_si utilisé partout ailleurs (car fournit par saisie)
3. en plus n'était pas à bon escient (cf prochain commit)

tout ceci nous permet de supprimer formidable_options, et donc d'economiser à chaque hit. Cela mérite bien un +1 sur y

éviter de mettre une définition  dans un options, lorsque la valeur n'est utilisé que dans une fonction. Autant définir dans ce cas dans la fonction

- code plus clair en évitant de créer des variables juste pour inverser le résultat d'un test, et pour recopier la valeur d'une variable sans la modifier après (!)
- plus de variables globales pour modifier un réglage (qui de toute facon
aurait du passer plutot par un pipeline dédiée)
- limiter les cas d'appel a eval()

Compatibilité assuré pour les quelques personnes qui auraient modifiés
ces variables globales (mais qui?)

pas besoin de définir les constante dans un fichier d'options, ne le définir que lorsqu'on s'en sert

La fonction "d'anomysation" dans traiter/enregistrement  concerne uniquement les auteurs connectés, on modifie les labels en conséquence.
On affiche les options pour cette fonction que si elle est cochée.

qui est passé au squelette de construction d'accusé de reception.
Par ex pour ajouter automatiquement certains messages en fonction des
résultats.

C'est plus propre que de faire cela par le pipeline recuperer_fond, car
cela ne dépend pas du formatage fait par le squelette.

Ceci créait une erreur si jamais un champ obligatoire était en
afficher_si et que la condition d'affichage n'était pas rempli.
Et pour cause, on disait de ne pas tenir compte des afficher_si, et de
vérifier tous les champs.

En fait il n'y a jamais eu d'enregistrement dans formidable de la config
des traitements qui ne sont pas activés. Et pour cause : dès lors qu'il
y a une config pour un traitement, celui-ci est considéré comme actif.

Du coup je sais pas ce qui m'a paris de faire r112371.

Les yaml de traiter disent parfois de passer l'env aux saisies (pour les saisies nom). Or, il y a comme env['id'] l'id du formulaire. Ce qui fait que ces sous-saisies avaient un id html égal à l'id du formulaire. Ce qu'on ne souhaite pas.
Cependant, on ne peut pas modifier directement le contexte du formulaire
de config des traitements, car plusieurs plugins utilise des tests sur
$contexte['id'] et pas sur $contexte['id_formulaire'].
Par conséquence, on se contente d'annuler ce contexte['id'] dans le html
avant de charger les saisies.

les yaml de traiter disent parfois de passer l'env aux saisies (pour les saisies nom). Or, il y avait comme env['id'] l'id du formulaire. Ce qui faisait que ces sous-saisies avaient un id html égal à l'id du formulaire. Ce qu'on ne souhaitait pas. Pour éviter cela, on précise de quel id on parle lorsqu'on charge le formulaire de config des traitements