Modèles Sauvegarder‑et‑reprendre pour brouillons, validation partielle et liens reprenables afin que les utilisateurs puissent finir plus tard sans perdre leur progression.
Un assistant multi‑étapes divise un long formulaire en étapes plus petites, comme les informations de profil, la facturation, les préférences et la révision. C'est utile quand la tâche est longue, les données sont complexes ou qu'il faut respecter un ordre précis. Bien conçu, il paraît plus léger qu'une page unique et interminable.
Pourtant, les utilisateurs abandonnent encore parce que la vie les interrompt. Ils peuvent ne pas avoir un document, attendre un responsable, perdre la connexion ou passer du téléphone à l'ordinateur. Certains quittent aussi parce qu'ils trouvent l'assistant risqué : une erreur ou un rafraîchissement pourrait tout effacer.
La fonction Sauvegarder‑et‑reprendre change la donne. Les utilisateurs peuvent faire une pause sans crainte, revenir plus tard et continuer à la bonne étape avec leur progression intacte. Les équipes y gagnent aussi : moins de soumissions abandonnées, des échanges de support plus clairs ("ouvrez votre brouillon et continuez") et une meilleure visibilité sur les étapes problématiques.
Pour tenir la promesse de ne pas perdre la progression (même sur plusieurs appareils), la plupart des assistants ont besoin de quelques basiques :
Il est plus simple de concevoir un assistant Sauvegarder‑et‑reprendre si vous le pensez comme deux choses distinctes : un brouillon et un enregistrement soumis.
Un brouillon est temporaire et modifiable. Un enregistrement soumis est officiel et doit suivre des règles plus strictes.
L'« état » est juste le label de ce qu'est l'enregistrement à un moment donné. Les états courants incluent draft, submitted, approved, rejected et archived. Si vous n'avez besoin que de deux, commencez par draft et submitted. Garder cette séparation nette simplifie grandement le reporting, les permissions et le support.
Ce que vous stockez à chaque étape dépend de ce dont vous avez vraiment besoin pour reprendre plus tard. Sauvegardez seulement les saisies de l'utilisateur pour cette étape, plus des métadonnées basiques comme le propriétaire et la date de dernière mise à jour. Évitez de stocker des éléments sensibles « au cas où » (par exemple les données complètes de carte, des documents non demandés ou des notes internes qui pourraient apparaître plus tard et embrouiller l'utilisateur).
Le suivi de progression doit être ennuyeux et explicite. Deux champs couvrent la plupart des cas :
current_step (l'endroit où l'utilisateur arrive quand il reprend)completed_steps (ce qui est déjà fait)Certaines équipes stockent completed_steps comme une liste d'IDs d'étape. D'autres utilisent un simple compteur.
Un modèle mental pratique :
created_at, updated_at, submitted_atQuand faut‑il créer le brouillon ?
Si votre flux est anonyme ou que vous voulez des liens reprenables, créez‑le dès l'ouverture de l'assistant pour disposer d'un ID auquel sauvegarder. Si l'utilisateur est connecté et que vous voulez éviter les brouillons vides, créez‑le à la première vraie action « Suivant » ou « Enregistrer ».
Un bon modèle de brouillon fait deux choses : il sauvegarde les saisies partielles sans casser et il rend la soumission finale prévisible. Si le modèle de données est maladroit, l'assistant semblera peu fiable même avec une excellente interface.
C'est l'approche la plus simple. Vous stockez tout dans une table (ou une entité principale) et ajoutez des champs comme status (draft/submitted) et current_step (1–6). Chaque enregistrement met à jour le même record.
Cela fonctionne le mieux quand le formulaire correspond clairement à une « chose » (une candidature, une commande, un profil).
Ici, vous conservez une table Draft pour les données partielles et une table Final pour les données propres et validées. À la soumission, vous créez l'enregistrement Final à partir du Draft, puis verrouillez ou archivez le brouillon.
Ce modèle brille quand les données finales doivent être strictes (facturation, conformité, reporting), mais que le brouillon peut rester flexible. Il rend aussi la suppression du brouillon plus sûre car elle n'affecte jamais les enregistrements soumis.
Si vous devez savoir qui a changé quoi et quand, conservez l'historique. Deux méthodes courantes :
Utilisez cela quand des approbations, des litiges ou des données régulées sont en jeu.
Les sections répétables (lignes d'articles, pièces jointes) sont souvent où les brouillons cassent. Modélisez‑les comme des tables enfants liées au brouillon (et plus tard à l'enregistrement final). Par exemple, un assistant d'onboarding peut avoir plusieurs « membres d'équipe » et « documents ». Sauvegardez chaque élément indépendamment. Évitez de tout entasser dans un tableau unique à moins que vous n'ayez vraiment pas besoin de requêter, trier ou valider par élément.
La validation partielle fait la différence entre un assistant aidant et un assistant qui fait barrage. Laissez les gens avancer quand ils ont fait l'essentiel, mais n'acceptez pas que des données manifestement erronées s'invitent dans le brouillon.
La plupart des assistants ont besoin des deux :
Pour permettre des champs incomplets sans enregistrer de mauvaises données, séparez « manquant » et « invalide ». Le manquant peut être acceptable dans un brouillon. L'invalide doit bloquer ou être clairement signalé car il crée de la confusion ultérieurement.
Exemple : un numéro de téléphone vide peut convenir dans un brouillon. Un numéro contenant des lettres doit être rejeté ou marqué clairement.
Que valider immédiatement vs plus tard :
Les erreurs doivent être spécifiques et locales. Au lieu de « Corrigez les erreurs pour continuer », montrez le champ, expliquez le problème et indiquez comment le corriger. Si une étape a des avertissements (plutôt que des erreurs), laissez l'utilisateur continuer mais conservez un badge clair « nécessite attention ».
Un modèle pratique est de renvoyer une réponse structurée depuis le serveur contenant :
Un bon assistant prend effet dès le premier écran. N'attendez pas l'étape 3 pour créer un enregistrement. Dès que l'utilisateur saisit quelque chose de significatif, vous voulez un brouillon que vous puissiez mettre à jour.
status = draft, et les champs de l'étape 1 (même incomplets).status = submitted.Pendant la rédaction, validez seulement ce qui est nécessaire pour l'étape courante. Sauvegardez les données partielles avec des indicateurs clairs comme « manquant » ou « à vérifier » au lieu de considérer tout comme une erreur bloquante.
Un lien reprenable est une URL qui contient un jeton unique (ponctuel ou à courte durée de vie). Lorsqu'on l'ouvre, l'app recherche le brouillon correspondant au jeton, vérifie sa validité et renvoie l'utilisateur à la bonne étape. C'est très pratique quand les gens changent d'appareil.
Un flux type : créer le brouillon -> générer un jeton lié au brouillon -> stocker une copie hachée du jeton -> afficher ou envoyer le lien -> échanger le jeton pour reprendre -> faire pivoter ou invalider le jeton.
Décidez quelques règles en amont pour que le support n'ait pas à deviner plus tard :
Exemple pratique : quelqu'un commence une candidature sur son téléphone, clique « M'envoyer un lien de reprise », puis continue sur son ordinateur. Si vous faites pivoter les jetons à chaque reprise, l'ancien lien cesse de fonctionner après usage, ce qui réduit le partage accidentel.
Soyez explicite.
Évitez de créer silencieusement un nouveau brouillon : l'utilisateur peut supposer que ses données originales sont encore là.
La fonction n'aide que si les gens lui font confiance.
Ne mettez jamais de données personnelles ou sensibles dans l'URL. Le lien doit porter uniquement un jeton aléatoire sans signification en lui‑même.
Traitez les jetons de reprise comme des mots de passe. Générez‑les avec suffisamment d'entropie, gardez‑les courts à copier et stockez uniquement une version hachée en base. Le hachage limite l'impact en cas de fuite de logs ou de sauvegardes.
Les jetons réutilisables sont pratiques mais plus risqués. Les jetons à usage unique sont plus sûrs mais peuvent frustrer si l'utilisateur clique deux fois sur un ancien email. Un compromis pratique : un jeton réutilisable à courte durée (heures ou jours) plus un bouton simple « renvoyer un nouveau lien ».
Valeurs par défaut sensées pour la plupart des produits :
Le contrôle d'accès dépend si les utilisateurs doivent être connectés.
Si l'assistant exige une session, le jeton devrait être optionnel : la reprise peut aussi exiger la session du compte, et le brouillon doit appartenir à cet utilisateur (ou à son organisation). Cela évite les problèmes de liens transférés.
Si l'assistant supporte la reprise anonyme, limitez le contenu du brouillon. N'enregistrez pas de détails de paiement complets, d'identifiants gouvernementaux ou toute donnée dangereuse si elle venait à être exposée. Envisagez le chiffrement des champs sensibles au repos et n'affichez qu'un résumé masqué à la reprise.
Ajoutez aussi une protection anti‑abus : limiter les vérifications de jetons, appliquer un rate limit sur les endpoints de reprise et bloquer un jeton après de multiples échecs.
La plupart des échecs viennent de l'UI, pas du backend. Les gens s'en vont quand ils se sentent perdus, incertains de la suite ou inquiets de perdre leur travail.
Commencez par un sens clair de la position. Montrez une progress bar avec des titres d'étape que les utilisateurs comprennent, comme « Informations société » ou « Méthode de paiement », et non des labels internes. Gardez‑la visible et laissez consulter les étapes terminées sans pénalité.
Faites que la sauvegarde paraisse réelle sans être intrusive. Un petit état « Sauvegardé » près du bouton principal et un horodatage « Dernière sauvegarde : il y a 2 minutes » renforcent la confiance. Si la sauvegarde échoue, dites‑le clairement et indiquez la marche à suivre.
Proposez une sortie facile. « Sauvegarder et terminer plus tard » doit être une action normale. Si l'utilisateur ferme l'onglet, souvenez‑vous où il en était et affichez un écran de reprise simple au retour.
Le mobile concentre souvent les abandons : adaptez les étapes à un petit écran. Préférez des étapes courtes avec peu de champs, des cibles tactiles larges et des claviers adaptés aux champs (email, numérique, date).
Checklist UI rapide qui aide généralement :
Le moyen le plus rapide d'augmenter l'abandon est de traiter l'assistant comme un examen final. Si vous bloquez la progression à l'étape 1 parce que l'étape 6 est incomplète, les gens quittent. Un assistant Sauvegarder‑et‑reprendre doit être indulgent : laissez avancer et enregistrez souvent.
Un piège fréquent est la sur‑validation tôt. Faites des vérifs par étape (est‑ce que cette étape est utilisable ?) et réservez les contrôles stricts pour la revue finale.
Si vous avez besoin de garde‑fous sans bloquer, utilisez des avertissements doux (« Vous pourrez terminer plus tard ») et mettez en évidence ce qui sera requis à la fin.
Beaucoup d'équipes créent le brouillon trop tard. Si vous ne créez le brouillon qu'après l'étape 3, les données initiales sont fragiles : un rafraîchissement, un plantage d'onglet ou une expiration de session peut tout effacer. Créez un brouillon dès que vous avez une identité stable (session compte ou email), et sauvegardez sur chaque transition d'étape.
Définissez aussi clairement la propriété. Décidez qui peut reprendre et modifier un brouillon : uniquement l'utilisateur original, tout membre de l'organisation, ou un coéquipier invité. Rendez cette règle visible dans l'UI.
Autres pièges à prévoir :
wizard_version et mappez les anciens brouillons aux nouvelles étapes quand c'est possibleAvant la mise en ligne, vérifiez les basiques qui impactent l'abandon et les tickets support.
Les liens reprenables sont des clés temporaires. Gardez‑les privées, limitées dans le temps et sûres à partager seulement intentionnellement.
Règle pratique : si quelqu'un transfère l'email au mauvais destinataire, cette personne ne devrait pas pouvoir voir des données sensibles du brouillon. Utilisez une courte expiration et exigez une ré‑authentification pour les étapes à haut risque.
Imaginez un assistant B2B en six étapes : informations société, contacts, facturation, documents de conformité, configuration du produit et revue finale. L'objectif est d'obtenir un compte opérationnel sans forcer les utilisateurs à tout faire en une seule fois.
L'étape délicate est la 4 (documents de conformité). Certains clients n'ont pas les fichiers prêts. D'autres doivent attendre l'approbation d'un responsable. L'assistant enregistre un brouillon après chaque étape et garde des états clairs comme Draft, Waiting for documents, Waiting for approval ou Submitted.
Un moment d'abandon fréquent : l'utilisateur termine l'étape 3 (facturation) puis part. À son retour, il ne retrouve pas un formulaire vide : il arrive sur un écran « Reprendre l'onboarding » qui affiche la progression (3 sur 6), ce qui manque (documents) et un bouton pour continuer à l'étape 4. Voilà l'essentiel de Sauvegarder‑et‑reprendre : partir est normal, pas un échec.
Si l'utilisateur a commencé depuis une invitation par email ou doit changer d'appareil, un lien reprenable peut le ramener exactement sur le brouillon et l'étape, après les contrôles requis (connexion, code à usage unique, ou les deux).
Côté équipe, le support et les commerciaux voient la progression des brouillons depuis une vue admin : quelle étape chaque client a atteinte, depuis combien de temps le brouillon est inactif et ce qui empêche la soumission.
Commencez petit. Choisissez un assistant qui a déjà de l'abandon (un checkout, un onboarding, une candidature) et ajoutez d'abord les brouillons. Un simple bouton « Sauvegarder » plus la sauvegarde automatique au changement d'étape réduisent souvent l'abandon plus vite qu'une refonte complète.
Mesurez avant de changer, puis mesurez après la mise en production. Suivez la complétion étape par étape, le temps pour finir et la part d'utilisateurs qui reprennent après être partis. Surveillez aussi les tickets support et les événements « bloqués » (utilisateurs qui rebondissent entre deux étapes ou échouent souvent à valider).
Prévoyez que l'assistant évoluera : on ajoute des étapes, on renomme des questions et les règles se durcissent. Le moyen le plus simple d'éviter de casser les vieux brouillons est de versionner ce que vous enregistrez. Stockez une wizard_version sur chaque brouillon et gardez de petites règles de migration pour que les anciens brouillons puissent encore s'ouvrir.
Si vous ne voulez pas tout coder vous‑même, AppMaster (appmaster.io) est une option. Vous pouvez modéliser une entité Draft en base, construire la logique d'étape comme un Business Process, et livrer le même flux sur le web et le mobile sans coder entièrement la pile.
When do I actually need save-and-resume in a multi-step wizard?La fonction Sauvegarder‑et‑reprendre réduit le risque perçu quand un flux est long ou sujet aux interruptions. Si un appel coupe, un onglet se rafraîchit ou l'utilisateur doit récupérer un document, il peut revenir plus tard sans perdre son travail, ce qui diminue en général l'abandon et les tickets au support.
What’s the simplest way to think about drafts vs submitted records?Commencez avec deux états : draft et submitted. Un brouillon (draft) est flexible et peut être incomplet ; un enregistrement soumis (submitted) est « officiel » et doit être verrouillé avec des règles, des permissions et des rapports plus stricts.
When should my backend create the draft record?Créez-le dès que vous avez un moyen stable de l'identifier. Pour les flows anonymes ou les liens reprenables, créez le brouillon à l'ouverture de l'assistant ; pour des utilisateurs connectés et moins de brouillons vides, créez‑le au premier « Enregistrer » ou « Suivant » significatif.
How often should a wizard save draft data?Par défaut, enregistrez à chaque transition d'étape, et ajoutez l'autosave pour les étapes longues. Le but est qu'un rafraîchissement ou une courte perte de connexion n'efface pas le progrès, sans toutefois surcharger le serveur à chaque frappe.
What data should I store in the draft, and what should I avoid?Stockez juste ce qu'il faut pour restaurer l'interface : les champs des étapes complétées, les informations de propriété et les horodatages. Évitez les données sensibles dont vous n'avez pas besoin pour reprendre, car les brouillons vivent souvent plus longtemps et sont consultés plus librement que les soumissions finales.
How do I validate partial data without blocking users too early?Validez au niveau de l'étape pendant la rédaction et lancez la validation complète à la soumission finale. Laissez l'absence d'une donnée acceptable dans un brouillon quand ce n'est pas requis, mais traitez les entrées manifestement invalides (ex. format d'email cassé) comme des éléments à corriger tout de suite.
Should I keep drafts and final submissions in the same table or separate ones?Une seule table évolutive suffit quand l'assistant correspond à une seule « chose » et que les contraintes finales ne sont pas radicalement plus strictes. Utilisez des tables séparées Draft et Final quand la soumission doit être propre pour la facturation, la conformité ou le reporting : cela garde les données brouillons hors des tables officielles.
How do resumable links work without leaking private information?Un lien reprenable doit contenir uniquement un jeton aléatoire, pas de données personnelles. Stockez côté serveur uniquement un hachage du jeton, fixez une date d'expiration et pensez à faire pivoter le jeton après chaque reprise pour réduire les risques si le lien est partagé par erreur.
What UI details make save-and-resume feel trustworthy?Affichez un indicateur de progression clair et un petit état « Sauvegardé » avec un horodatage récent. Proposez « Terminer plus tard » comme action normale et, si la sauvegarde échoue, indiquez clairement le problème et la marche à suivre pour que l'utilisateur ne suppose pas à tort que son travail est sauvegardé.
How can I build a save-and-resume wizard in AppMaster without writing everything from scratch?Dans AppMaster, modélisez une entité Draft, stockez status, current_step et des horodatages, puis implémentez la logique de sauvegarde/reprise comme un Business Process backend afin que chaque étape persiste de manière prévisible. Avec AppMaster, vous pouvez concevoir visuellement le modèle de données, orchestrer la logique et déployer le même flux sur le web et les applications mobiles sans tout coder à la main.
21 janv. 2026
8 min
20 janv. 20268 min
20 janv. 20268 minExpérimentez avec AppMaster avec un plan gratuit.
Lorsque vous serez prêt, vous pourrez choisir l'abonnement approprié.
