Formulaire Webflow conditionnel : concevoir les étapes et les tests

Un formulaire à plusieurs étapes peut rendre une demande plus facile à expliquer. Il peut aussi multiplier les écrans sans aider le visiteur. Le critère de choix est concret : les réponses données doivent-elles changer les questions suivantes ? Si tous les visiteurs remplissent les mêmes quelques champs, un formulaire simple reste une option à comparer.

L’exemple relie trois besoins fictifs — création, refonte et maintenance — à une matrice de questions et à une recette de contrôle. La matrice aide à décider ce qu’il faut demander ; la recette permet de vérifier les retours, les erreurs et les données finales. Les éléments essentiels sont reproduits ci-dessous. Le laboratoire complet n’est pas diffusé publiquement. Ses tests portent sur une référence locale, sans validation d’intégration ou de réception dans Webflow, par email ou dans un CRM.

Ce que Webflow permet de documenter, et ce qui doit être testé

Webflow documente les champs et les destinations de ses formulaires. Il propose aussi du code embarqué et des composants de code ; la documentation de ces derniers cite les formulaires à étapes. Documentation des formulaires.

Les « Conditionals » documentés portent sur les champs CMS, les propriétés de composants et les données de locale. Ce n’est pas une preuve que le formulaire décrit ici peut être assemblé sans code à partir des réponses du visiteur. Documentation des conditions.

Nous avons donc choisi du HTML, du CSS et du JavaScript sans bibliothèque ni service tiers. Le démonstrateur ne requiert aucun crédit de génération. Une adaptation future pourrait étudier le code embarqué, sous réserve d’accès approprié et de recette : Webflow précise que la compatibilité du code additionnel n’est pas garantie. La page locale complète n’est pas un bloc à coller tel quel dans le Designer. Code Embed, composants de code générés.

Commencer par trois parcours et leurs questions utiles

Le formulaire comporte quatre étapes : choisir le besoin, préciser ses détails, saisir des coordonnées fictives, puis relire le récapitulatif. L’écran final annonce seulement une validation locale.

Les coordonnées sont communes : nom, organisation et email fictifs. Le téléphone n’apparaît que si le mode de contact choisi est le téléphone. Ce choix illustre une dépendance ; il ne démontre pas qu’un champ téléphone serait nécessaire sur toutes les demandes commerciales.

Utilisée pendant le cadrage, cette matrice tranche trois décisions : quelles questions poser, à quel moment les rendre obligatoires et quelles réponses effacer après un changement de choix. Elle donne aussi au relecteur un attendu précis : après le passage de CMS « oui » à « non », le responsable des contenus doit disparaître de l’écran et de la charge finale. Une question sans rôle dans la qualification ou la suite du parcours mérite d’être retirée du cahier des charges.

Définir des validations explicites, sans les confondre avec celles de Webflow

Le démonstrateur utilise des règles pédagogiques choisies pour rendre les tests reproductibles. Elles ne sont pas des limites imposées par Webflow.

Les espaces en début et fin sont retirés avant les contrôles de longueur. Les textes conservent leurs accents, guillemets et caractères utiles. Les messages d’erreur indiquent le champ à corriger ; le résumé permet d’y revenir. Il faut vérifier ce comportement dans l’interface, pas seulement vérifier qu’une fonction retourne false.

Les contrôles HTML comme required et les API de validation peuvent aider côté navigateur. Ils ne remplacent jamais une validation côté serveur : le navigateur et ses contrôles peuvent être contournés. MDN : validation des contraintes.

Retour, changement de branche et valeurs cachées : choisir une politique

Dans notre exemple, le bouton Retour conserve les réponses encore actives. Le visiteur peut revenir aux détails sans perdre son nom ou le nombre de pages choisi. En revanche, désactiver une condition efface immédiatement la valeur qui n’a plus de rôle. Si le CMS passe de oui à non, le responsable des contenus est supprimé ; il n’est pas seulement masqué.

Changer entièrement le type de besoin efface ses anciens détails. Les coordonnées communes restent disponibles. Cette règle est annoncée dans le démonstrateur. Une autre politique pourrait être choisie, mais elle devrait être explicitement testée : garder des réponses invisibles en mémoire peut provoquer un récapitulatif trompeur ou une charge contenant des données abandonnées.

Le moteur sépare les champs possibles des champs actifs. Voici la fonction employée pour déterminer les détails d’une branche :

export function detailFields(data) {
  if (data.projectType === 'creation') return ['pagesCount', 'cmsNeeded', ...(data.cmsNeeded === 'yes' ? ['contentOwner'] : [])];
  if (data.projectType === 'refonte') return ['currentUrl', 'preserveSeo', ...(data.preserveSeo === 'yes' ? ['migrationNotes'] : [])];
  if (data.projectType === 'maintenance') return ['issueType', ...(data.issueType === 'technique' ? ['problemDescription'] : data.issueType === 'contenu' ? ['contentVolume'] : [])];
  return [];
}

Pour reproduire ce choix de champs, copiez la fonction dans un module JavaScript et passez-lui { projectType: 'creation', cmsNeeded: 'yes' } : le résultat attendu est ['pagesCount', 'cmsNeeded', 'contentOwner']. Avec cmsNeeded: 'no', la liste attendue ne contient plus contentOwner. Ce contrôle peut être refait à partir de l’extrait seul ; il ne reconstruit pas toute l’interface.

La fonction ne soumet rien : elle donne la liste des clés autorisées pour le besoin courant. La fonction de mise à jour efface les dépendances devenues inactives. L’interface masque et désactive leurs contrôles. La sérialisation utilise ensuite une liste blanche des clés actives, même si une ancienne valeur a été injectée dans l’état pendant un test.

Un contrôle HTML désactivé est exclu des contraintes et d’une soumission de formulaire classique. Notre garantie locale ne repose cependant pas sur ce seul attribut : la charge est construite à partir du modèle. MDN : attribut disabled.

Vérifier la charge finale, pas seulement l’écran de confirmation

Le parcours de création avec CMS aboutit à cette charge attendue et observée dans le test moteur P01 :

{
  "schemaVersion": "1.0",
  "status": "LOCAL_VALIDATED_NOT_SENT",
  "projectType": "creation",
  "details": {
    "pagesCount": "6-15",
    "cmsNeeded": "yes",
    "contentOwner": "marketing"
  },
  "contact": {
    "fullName": "Alex Exemple",
    "email": "alex@atlas.example.test",
    "company": "Atelier Atlas Fictif",
    "contactMode": "email"
  }
}

Le statut signifie exactement « validé localement, non envoyé ». Il ne constitue pas une demande enregistrée. Le téléphone n’est pas présent, puisque ce parcours choisit l’email. Le test inverse vérifie que basculer du téléphone vers l’email efface la valeur et retire la clé de la sortie.

Le récapitulatif revalide toutes les étapes. Il ne suppose pas que les étapes précédentes restent correctes parce qu’elles ont été traversées une fois. Une deuxième activation de la validation locale ne produit pas de seconde charge. Ce verrou est local : une vraie destination aurait encore besoin de ses propres protections contre les doubles traitements.

Ce que les tests ont réellement montré

Le 21 octobre 2026, 40 tests ont été exécutés avec Node 22.18.0 : 40 réussis, aucun échec. Ils contrôlent les trois parcours complets, les branches opposées, la conservation au retour, l’effacement des champs abandonnés, les erreurs, les bornes, les caractères spéciaux, la liste blanche et la double validation locale.

Une recette distincte a été exécutée dans Chrome 155 headless, avec profil isolé : 9 contrôles réussis. Elle a observé les erreurs et le focus, des variantes des trois familles de besoins, la navigation Entrée/Espace, les changements de branche, une largeur 390×844 sans débordement horizontal pour le scénario testé, l’absence d’envoi et le comportement sans JavaScript. Les chaînes contenant du HTML sont restées du texte ; aucune requête externe ni erreur JavaScript non gérée n’a été relevée pendant cette suite.

Ces résultats couvrent la référence locale et cet environnement : ils ne valident ni Webflow, ni l’accessibilité complète, ni les autres navigateurs. Les journaux détaillés restent dans le dossier technique de revue, sans téléchargement public annoncé. La recette ci-dessous peut servir à préparer vos propres attendus ; toute modification d’un composant demande de rejouer les cas concernés.

La recette à demander avant de livrer un formulaire réel

1. Nominal. Remplir chaque parcours représentatif et comparer les clés et valeurs de sa charge finale à l’attendu. Un succès visuel ne suffit pas.

2. Erreurs. Retirer un obligatoire, saisir une valeur incohérente, puis vérifier que l’avancement est bloqué, que le message est relié au bon champ et que la correction est possible au clavier.

3. Retours. Revenir à une étape, contrôler la conservation, changer une condition et vérifier l’effacement annoncé dans le récapitulatif et dans la charge.

4. État final. Tester une activation répétée, l’absence de JavaScript et les erreurs de script. Une référence locale peut bloquer toute soumission ; un formulaire réel doit prévoir le traitement et le secours convenus.

5. Destination. Recetter séparément ce qui reçoit réellement la demande. Pour ce problème, le guide Formulaire Webflow : retrouver pourquoi une demande n’arrive pas distingue les observations à réunir. Le présent guide traite la construction des états, pas ce diagnostic de réception.

Adapter le composant à un projet Webflow

Avant de choisir entre un montage simple, un composant de code ou un service spécialisé, faire préciser le nombre de branches, les responsabilités de maintenance et la destination. La solution doit rester compréhensible pour la personne qui la reprendra. Un outil ne dispense pas d’écrire la matrice et de contrôler les champs abandonnés.

Une adaptation de notre référence exigerait de vérifier les identifiants, le chargement des scripts, les contraintes de l’environnement Webflow et le traitement des demandes. Il faudrait aussi recetter la validation serveur, les erreurs de destination et les règles de collecte applicables.

Pour replacer cette fonction dans la page, le guide de création de landing page Webflow aide à cadrer l’action attendue et la suite du parcours. Si votre projet exige plusieurs chemins de qualification, présentez le besoin à Gemme Studio : le premier travail consiste à décider quelles questions sont utiles et comment vérifier la livraison, sans promettre un gain de conversion.