Analyser
Rien ne compte tant que personne n'a signé.
Lorsque les validations sont activées, une réponse envoyée attend une décision d'approbation ou de rejet, assortie d'un commentaire facultatif, avant de compter comme complète. Vous pouvez désigner une liste de validateurs par enquête ; à défaut, tout éditeur de l'organisation peut décider. La personne qui a décidé et le moment où elle l'a fait sont enregistrés par la base de données, à partir de la session authentifiée, et non fournis par le navigateur — c'est toute la différence entre une piste d'audit et une simple affirmation.
Les validations se font en une seule étape. Une décision par réponse, sans chaîne, sans délégation, sans suppléance en cas d'absence, sans escalade et sans relance automatique. Si votre processus exige une chaîne à trois étapes, mieux vaut l'apprendre sur cette page qu'à la troisième semaine d'un déploiement.
Comment l'état évolue réellement
Une réponse arrive en attente. C'est une soumission complète — chaque réponse, chaque fichier déposé, chaque signature conservés comme ils le seraient autrement — mais signalée comme non encore tranchée. Un validateur l'ouvre et l'approuve ou la rejette, avec un commentaire facultatif dans les deux cas. Voilà toute la machine à états, et sa brièveté est délibérée : il n'y a pas de « renvoyée pour correction » ni de boucle de renvoi qui rouvrirait l'enregistrement au répondant. Une réponse rejetée reste en place et reste lisible au sein de l'organisation.
La décision ne modifie pas les données. La vue de résultats continue de compter la réponse dans ses graphiques par question. La validation est une décision consignée en regard d'une soumission, non un filtre qui la masque.
Ce qui est écrit, et par qui
Quatre éléments sont conservés pour chaque décision. Deux d'entre eux sont la raison d'être de cette fonctionnalité.
Décision
Approuvée ou rejetée. Il n'existe pas de troisième état une fois la décision prise.
Auteur de la décision
Repris de la session authentifiée par la base de données, et non d'un champ envoyé par le navigateur.
Horodatage
Écrit côté serveur au moment où la décision est enregistrée, et non lu sur l'horloge du relecteur.
Commentaire
Facultatif, à l'approbation comme au rejet, conservé avec la décision et visible uniquement au sein de l'organisation.
Bien des outils vous diront qui a approuvé quelque chose. La question à poser à un fournisseur est de savoir d'où vient ce nom. Si le client transmet l'identité du validateur avec la décision, quiconque peut appeler le point de terminaison peut inscrire n'importe quel nom et n'importe quelle heure dans le journal d'audit.
Ici, l'identité et l'horodatage sont repris de la session authentifiée par la base de données elle-même. Un navigateur ne peut pas les proposer, il ne peut donc pas s'y tromper. C'est le même socle que le reste de la plateforme : sécurité au niveau des lignes partout, cloisonnement entre organisations fixé côté serveur, et des règles comme la date de clôture et le plafond de réponses appliquées par des déclencheurs de base de données plutôt que par l'interface.
Le répondant ne voit jamais la décision
L'état de validation est invisible pour la personne qui a rempli le formulaire. Elle envoie, elle obtient l'écran de remerciement, et cela s'arrête là. Aucun suivi d'état, aucun courriel automatique lui annonçant un refus.
Il s'agit d'un choix et non d'un oubli. Un rejet est le plus souvent procédural — pièce justificative inadaptée, demande hors dispositif, doublon — et un « rejeté » automatique et sec est une mauvaise façon de l'annoncer à un habitant. Les collectivités disposent déjà de procédures pour notifier des décisions, avec la formulation, la voie de recours et le numéro de référence qui les accompagnent. Une file de validation interne ne doit pas devenir subrepticement une notification de décision non encadrée.
Ce que cela recouvre dans les collectivités
Le cas courant est un formulaire qui n'est pas vraiment une enquête : un petit dispositif de subventions, une demande de réservation de terrain, une déclaration de changement de situation, une modification de licence. Quelque chose arrive, un agent l'examine, et c'est accepté ou non. Cette décision unique constitue tout le circuit, et c'est précisément le cas pour lequel les validations ont été conçues. La page collectivités en dit davantage sur l'adéquation au secteur.
Deux éléments s'y associent. Le dépôt de fichiers, parce que ces formulaires transportent des justificatifs — un devis, une facture, une photographie — conservés dans un espace privé et lisibles uniquement par l'organisation, via des URL signées de courte durée. Et les signatures électroniques, qui conservent la marque, la méthode, le texte exact de l'engagement et une empreinte SHA-256 de ce texte, de sorte qu'en modifier la formulation par la suite modifie l'empreinte. Une décision consignée par-dessus une déclaration empreintée vous donne la trace de qui a accepté quoi et de qui l'a approuvé. Il s'agit de signatures électroniques simples, non de signatures qualifiées : savoir si cette preuve suffit pour un dispositif donné relève de celui qui en a la responsabilité.
Ce que les validations ne font pas
Quatre choses sortent du cadre de l'étape unique, et méritent d'être nommées.
- Aucune chaîne. Vous ne pouvez pas acheminer une réponse vers un chef d'équipe puis vers le service financier. Une décision clôt le dossier.
- Aucune délégation ni suppléance. Un validateur ne peut pas confier sa file à un collègue pendant son absence.
- Aucune escalade ni relance. Rien ne relance un validateur au bout de trois jours. Une réponse en attente attend.
- Aucun acheminement conditionnel. Les questions vues par un répondant peuvent dépendre de ses réponses antérieures grâce à la logique conditionnelle ; l'identité de celui qui examine le résultat, non.
La raison tient à la surface d'exposition. Chaînes, délégation, suppléance et escalade amènent avec elles des échéances, des états d'absence, des règles de réattribution et un moteur de notifications — et chacun de ces éléments est un endroit où une décision peut se perdre. Un relecteur unique, avec approuver, rejeter et un commentaire, couvre le cas courant et s'explique en une phrase. S'il vous faut une véritable chaîne, utilisez un outil de gestion de dossiers pour le circuit et celui-ci pour la réception, ou dites-nous à quoi ressemble votre chaîne.
Faire passer la décision dans vos autres systèmes
Le moment compte. Un webhook se
déclenche à l'arrivée de la réponse — signé en HMAC-SHA256 dans un
en-tête X-NumoForms-Signature, à l'aide d'un secret propre à
chaque webhook —, c'est-à-dire avant que quiconque ait examiné quoi que
ce soit. Un système qui reçoit cette charge utile reçoit une demande, et
non une demande approuvée : il doit la traiter comme telle. Les
notifications par courriel se comportent de la même façon. Ni l'une ni
l'autre ne transporte la décision, pas plus que
l'export CSV, qui comporte une colonne
par question et aucune colonne de validation. La décision réside dans la
vue de résultats : aujourd'hui, elle voyage vers un autre système par
l'intermédiaire de la personne qui l'a prise.
Ce que l'on demande souvent sur les validations
Qu'est-ce qu'une étape de validation sur une réponse d'enquête ?
Une étape de validation maintient une réponse envoyée en attente jusqu'à ce que quelqu'un l'approuve ou la rejette, avec un commentaire facultatif. Jusque-là, elle ne compte pas comme complète. La décision, son auteur et l'horodatage sont écrits par la base de données à partir de la session authentifiée, et non fournis par le client.
Qui est autorisé à approuver une réponse ?
Vous pouvez définir une liste nominative de validateurs par enquête. À défaut, tout éditeur de l'organisation peut décider. Il n'existe pas de type de siège « validateur » distinct : les validateurs sont des personnes qui disposent déjà d'un accès à l'espace de travail.
Le répondant apprend-il que sa réponse a été rejetée ?
Non. L'état de validation n'est jamais montré au répondant, qui voit l'écran de remerciement habituel au moment de l'envoi. Un rejet est une décision interne portant sur l'enregistrement, non un jugement communiqué à la personne : c'est vous qui la contactez, de la manière qui convient au dossier.
Les chaînes de validation à plusieurs étapes sont-elles prises en charge ?
Non. Les validations se font en une seule étape : une décision d'approbation ou de rejet par réponse. Il n'y a ni étapes successives, ni signature en parallèle, ni délégation, ni escalade, ni relance automatique. Un processus qui exige une chaîne à trois étapes n'est pas couvert aujourd'hui.
Que se passe-t-il si l'unique validateur est absent ?
Rien ne se produit automatiquement : il n'existe ni délégation ni suppléance en cas d'absence. Désignez plusieurs validateurs sur l'enquête, ou laissez la liste vide pour que tout éditeur de l'organisation puisse décider.
Placez une décision derrière le formulaire.
Activez les validations et chaque réponse envoyée attend une seule décision — approuver ou rejeter, avec un commentaire facultatif — avant de compter comme terminée. L'auteur de la décision et l'horodatage sont inscrits par la base de données à partir de la session authentifiée : la piste d'audit ne vient donc pas de ce que le navigateur a bien voulu déclarer.
- Validation en une seule étape : approuver ou rejeter, avec un commentaire
- Des validateurs désignés par enquête, ou n'importe quel éditeur de l'organisation
- Les répondants ne voient jamais la décision
