La conception des parcours d'exception aide les équipes à gérer les demandes rejetées, les documents manquants et les approbations partielles avant que les retouches ne ralentissent le processus.
La plupart des équipes commencent par la version propre d'un workflow. Une demande arrive, quelqu'un la vérifie, et elle est approuvée. Ça paraît efficace, mais cela cache le vrai travail.
Le happy path est généralement le chemin le plus court. Le formulaire est complet, les pièces sont jointes, et le relecteur sait exactement quoi faire. Dans la réalité opérationnelle, ce n'est rarement la partie qui provoque des ralentissements.
Les retards commencent quand quelque chose manque, n'est pas clair, est en retard ou n'est acceptable que partiellement. Un manager peut approuver le budget mais rejeter une ligne. La finance peut demander un document fiscal jamais téléversé. Un responsable support peut renvoyer la demande parce que le champ "raison" est trop vague. Chacun de ces moments crée des étapes supplémentaires, des messages en plus, et de l'attente.
Si ces situations ne sont pas planifiées tôt, les gens prennent des décisions au fil de l'eau. Un relecteur envoie un email. Un autre laisse un commentaire dans l'outil. Un troisième rejette la demande sans explication. Le demandeur reste à deviner : doit-il corriger, tout recommencer, ou demander de l'aide ?
Cette confusion a un coût. Elle freine la personne qui a soumis la demande, le relecteur et tous ceux qui sont sollicités pour expliquer ce qui s'est passé. Un workflow qui paraissait simple sur un tableau blanc se transforme en discussions de suivi, soumissions en double et transferts manuels.
Un flux d'approbation de base est facile à esquisser :
La version réelle est plus compliquée. Et si un document manque ? Et si seule une partie de la demande est approuvée ? Et si le relecteur la rejette mais que l'utilisateur peut la corriger ? Ce ne sont pas des cas rares. Pour beaucoup d'équipes, ce sont les cas normaux.
C'est pourquoi la conception des parcours d'exception mérite de l'attention avant de dessiner les écrans et nommer les statuts. Le parcours d'exception définit ce qui se passe quand la réalité interrompt le plan, et la réalité le fait souvent.
Si vous construisez une application d'approbation interne, y compris dans une plateforme no-code comme AppMaster, les cas rejetés et incomplets méritent autant d'attention que le cas approuvé. Ils déterminent les messages affichés, les actions possibles ensuite et si le workflow aide les utilisateurs à se remettre en selle ou les laisse bloqués.
Un happy path montre l'intention. Les parcours d'exception montrent si le processus peut survivre à l'usage réel.
Un parcours d'exception décrit ce qui arrive quand une demande ne peut pas avancer normalement. Ce n'est pas un cas marginal rare. C'est la partie du processus qui gère le désordre réel : une demande est refusée, un formulaire est incomplet, une partie est approuvée mais une autre non, ou le dossier reste bloqué.
Un parcours d'exception clair utilise un langage simple. Au lieu d'un statut vague comme "Failed", indiquez la raison : "Rejeté car le budget dépasse la limite" ou "En attente du justificatif d'identité". Les gens doivent savoir ce qui ne va pas, qui doit agir et ce qui se passe ensuite.
La plupart des workflows cassent de quelques façons prévisibles :
L'information manquante est l'un des problèmes les plus fréquents. Imaginez un formulaire d'onboarding fournisseur qui nécessite un document fiscal et un numéro de compte bancaire. Si l'un des deux manque, le système ne doit pas simplement s'arrêter. Il doit marquer la demande comme incomplète, afficher exactement ce qui manque et la renvoyer à la bonne personne.
Les approbations partielles sont tout aussi importantes. Pensez à une demande de déplacement pour vol, hôtel et budget repas. Le manager approuve le vol et l'hôtel mais réduit le budget repas. Le processus a alors besoin de règles. L'employé accepte-t-il la modification, met-il à jour la demande ou annule-t-il le voyage ?
Les blocages comptent aussi. Une demande peut rester sans mouvement parce que le relecteur assigné a quitté l'entreprise, l'équipe n'a pas défini de remplaçant, ou le processus arrive à une étape sans propriétaire suivant. Rien n'est techniquement cassé, mais la demande ne peut pas avancer.
Si vous ne concevez pas ces parcours tôt, les gens les gèrent par email, chat ou notes de tableur. Rapidement, personne ne sait quelle version est finale.
Prenez une demande de déplacement pour un manager commercial qui souhaite assister à une conférence de deux jours. Sur le papier, le flux paraît simple : l'employé saisit les dates, le coût estimé et le motif. Le manager approuve, la finance confirme le budget et la réservation peut commencer.
Ce flux est propre, mais incomplet.
Brisons la même demande. L'employé téléverse l'estimation de vol et le billet de conférence mais oublie le devis hôtel. Si le système ne connaît que "soumis" et "approuvé", les gens se retrouvent vite bloqués. La finance voit une demande incomplète, le manager pense qu'elle est prête et l'employé ignore ce qui manque.
Un meilleur flux donne cet état sa propre place, par exemple "En attente de document" ou "Besoin de mise à jour". L'employé doit voir un message clair : "Ajoutez le devis hôtel avant que la demande n'aille en finance." Le manager ne doit pas rejeter tout le voyage pour demander un seul fichier.
Ajoutez un deuxième problème. Le manager accepte le déplacement, mais pas pour le montant total. Il approuve le vol et une nuit d'hôtel, mais rejette le supplément atelier et la deuxième nuit.
C'est souvent là que les équipes découvrent qu'elles n'ont pas vraiment de processus d'approbation partielle.
Si le workflow ne peut pas n'approuver qu'une partie de la demande, les gens utilisent des contournements. Ils rejettent la demande entière et demandent une nouvelle soumission. Ou la finance approuve par erreur le montant total parce que le système n'enregistre qu'une décision oui/non.
Un modèle plus clair suit chaque poste de coût, ou au moins le total approuvé. Une demande pourrait montrer :
Cet exemple montre pourquoi les erreurs dans les workflows d'approbation viennent souvent de règles manquantes, pas de personnes négligentes. Si vous définissez ces règles avant de concevoir les écrans, le reste du flux devient beaucoup plus fiable.
Une bonne façon d'améliorer un workflow est de partir du postulat que la demande ne passera pas proprement. Ce simple changement élève rapidement la qualité du design.
Commencez par les cas désordonnés : formulaire incomplet, politique peu claire, approbateur absent ou seule une partie doit avancer. La plupart des équipes peuvent les regrouper en trois modèles principaux :
Cela rend le travail gérable. Au lieu d'inventer une réponse pour chaque cas, vous définissez un petit ensemble de modèles et les appliquez à chaque type de demande.
Travaillez dans cet ordre.
D'abord, listez chaque point où la demande peut s'arrêter. Pensez aux documents manquants, valeurs invalides, violations de politique, délais expirés, soumissions en double et revues manuelles. Si la demande peut attendre, échouer ou retourner à l'expéditeur, notez-le.
Ensuite, décidez ce qui se passe dans chaque cas. Pour chaque exception, répondez à quatre questions simples :
Par exemple, imaginez une note de frais de 600 €. le justificatif d'hôtel manque et un repas dépasse la politique. Si vous ne concevez que le happy path, la demande reste bloquée ou est rejetée en bloc. Si vous concevez les exceptions en premier, le système peut mettre la note en pause pour le justificatif manquant, notifier l'employé avec un message clair et marquer les éléments autorisés comme approuvés conditionnellement.
C'est là que les règles d'approbation partielle comptent. Il faut décider si le montant approuvé peut avancer maintenant, si le reste reste en attente, et si le demandeur peut éditer uniquement la partie contestée ou doit resoumettre l'ensemble.
Si vous construisez le processus dans AppMaster, c'est le moment de cartographier ces branches dans la logique métier avant d'affiner l'interface. Il est beaucoup plus facile de faire confiance à un workflow quand rejeter, renvoyer pour modification et approuver avec conditions sont traités comme des chemins séparés au lieu d'être cachés derrière un statut vague.
Enfin, testez un scénario réel du début à la fin. Utilisez des nombres réels, un vrai document manquant et une exception de politique. Si une personne qui lit le flux ne sait pas quoi faire ensuite en moins d'une minute, le design est encore trop vague.
Les écrans semblent concrets, donc les équipes commencent souvent par là. Elles esquissent boutons, formulaires et tableaux de bord avant de s'accorder sur les règles. Cela crée généralement des problèmes plus tard, car l'interface finit par cacher des décisions que personne n'a réellement prises.
Un meilleur ordre est simple : définissez les états, les transferts, les délais et les preuves requises pour avancer. Puis construisez les écrans autour.
La conception des parcours d'exception devient plus simple quand l'ensemble de règles est petit et clair. Si une demande peut être approuvée, rejetée, renvoyée pour corrections ou partiellement approuvée, ces états doivent avoir des noms simples qui signifient une chose unique. Évitez les quasi-doublons comme "Renvoyé", "Rouvert à nouveau" et "Besoin de modifications" sauf s'ils se comportent vraiment différemment.
Prenez une demande d'achat. Un manager l'ouvre et remarque que le devis manque. Si l'équipe n'a pas décidé quoi faire ensuite, chacun improvise. Un manager rejette, un autre laisse en attente, un troisième envoie un message et ne change rien dans le système. Rapidement, personne ne fait confiance au statut.
Rédigez la règle d'abord. Quand un devis manque, la demande passe en "Needs documents". Le demandeur est responsable de l'étape suivante. La demande reste là cinq jours ouvrés. Si rien n'arrive, elle passe en "Expiré" et une nouvelle soumission est requise.
Cette règle seule guide mieux le produit qu'une maquette. Vous savez alors ce que l'utilisateur doit voir, quel rappel envoyer et quelle historique conserver.
Un ensemble de règles pratique doit répondre à quatre questions :
Les approbations partielles demandent le même soin. Si le voyage est approuvé mais pas le coût d'hôtel, le demandeur modifie-t-il le même dossier ou crée-t-il un nouveau ? La finance revoit-elle seulement la partie changée ou tout à nouveau ? Si ce n'est pas décidé tôt, l'écran peut paraître propre tandis que le processus reste chaotique.
Quand les équipes décident des règles d'abord, l'interface devient plus simple. Surtout, les utilisateurs savent exactement quoi faire ensuite, même si la réponse est "pas encore approuvé".
Un mauvais message d'exception ralentit tout. Les gens n'ont pas seulement besoin de savoir qu'une chose a échoué. Ils doivent savoir ce qui s'est passé, ce que cela impacte et ce qu'il faut faire ensuite.
C'est là que le design devient concret pour les utilisateurs. Vos règles internes peuvent être claires, mais si l'écran indique seulement "Erreur" ou "En attente de vérification", les gens devinent, renvoient les mauvais fichiers ou contactent le support.
Prenez un exemple d'approbation fournisseur. Un utilisateur soumet un formulaire avec un document fiscal, des coordonnées bancaires et une attestation d'assurance. Les coordonnées bancaires sont correctes, le document fiscal est obsolète et l'attestation d'assurance manque. Si le système n'affiche que "Demande non approuvée", l'utilisateur n'a pas de suite claire.
Un meilleur message dit : "Vos coordonnées bancaires ont été approuvées. Il nous manque un document fiscal à jour et l'attestation d'assurance avant l'approbation finale." Cette phrase sépare ce qui est fait de ce qui reste à faire et fait gagner du temps.
Les bons messages répondent souvent à quatre petites questions :
Cette dernière partie compte. Les gens achèvent plus volontiers la tâche quand l'étape suivante est claire. "Téléversez le fichier manquant et renvoyez pour vérification" est bien mieux que "Action requise".
Les labels vagues créent aussi de l'anxiété. "En attente de vérification" peut signifier attendre une personne, des données manquantes ou un contrôle interne. Si vous connaissez la raison, dites-la clairement. "En attente d'approbation du manager" et "En attente d'un justificatif d'adresse" ne sont pas la même chose et ne devraient pas se ressembler.
Si un processus autorise l'approbation partielle, montrez-le clairement dans le statut lui-même. Un bref détail marche souvent mieux qu'un seul libellé :
L'utilisateur peut ainsi corriger seulement ce qui importe. Il n'a pas besoin de tout recommencer.
C'est aussi là qu'il faut faciliter la resoumission. Placez l'action suivante proche du message, pas sur un autre écran. Si vous construisez le flux dans AppMaster, veillez à faire correspondre le texte visible avec les états réels du processus afin que l'appli dise exactement ce que le workflow fait.
De bons messages réduisent les tickets au support, accélèrent les approbations et donnent l'impression d'un processus équitable. Les gens acceptent mieux un refus quand ils le comprennent.
La plupart des retouches partent d'une mauvaise hypothèse : on conçoit principalement le chemin idéal. Les équipes cartographient soumission, approbation, terminé et s'arrêtent là. Puis la vie réelle arrive : un fichier manque, un manager demande des changements ou seule une partie peut avancer.
Cet écart crée vite du travail supplémentaire. Les gens inventent des corrections manuelles, envoient des messages à côté et renommant les statuts à la volée. Quelques semaines plus tard, personne ne fait confiance au workflow car chaque exception ressemble à un cas particulier.
Une erreur courante est de traiter le chemin idéal comme le produit et tout le reste comme du nettoyage. Imaginez une note de frais qui nécessite un reçu, l'approbation du département et la revue de la finance. Si le reçu manque, la demande est-elle en pause, renvoyée à l'employé ou rejetée ? Si cette règle n'est pas claire dès le départ, l'équipe la colmate souvent après avec des emails et des commentaires.
Des noms de statut confus entraînent une autre série de retouches. Des libellés comme "En revue 2" ou "Action requise" semblent inoffensifs, mais ils obligent les gens à deviner la suite. Des noms clairs réduisent les erreurs car ils indiquent le problème, le propriétaire, l'issue ou l'étape suivante.
La propriété est un autre point de rupture. Une demande ne doit jamais rester dans un statut qui n'appartient à personne. Si un dossier attend, quelqu'un doit être responsable de le faire avancer, demander plus d'informations ou le clôturer. Sinon, les délais silencieux s'accumulent et les utilisateurs pensent que le système a perdu leur demande.
L'approbation partielle est souvent mal gérée aussi. Les équipes la traitent comme un rejet total parce que c'est plus simple. Mais ces issues signifient des choses différentes. Si une demande de déplacement demande vol, hôtel et repas, la finance peut approuver le vol et l'hôtel mais refuser les repas. Ce cas nécessite son propre chemin, son message et souvent une action de suivi.
Quand l'approbation partielle est confondue avec le rejet, les gens resoumettent la demande complète, dupliquent des documents et recommencent des revues déjà faites. C'est de la retouche pure.
Un test simple aide : lisez chaque statut non-happy-path et demandez-vous « Qui en est responsable, que voit l'utilisateur et que se passe-t-il ensuite ? ». Si la réponse est floue, le processus cassera probablement au même endroit plus tard.
Avant de créer des écrans ou d'automatiser, passez une dernière fois sur les cas désordonnés. Une bonne conception des parcours d'exception tient souvent en quelques décisions claires prises tôt, avant que la confusion ne devienne du travail supplémentaire.
Si une demande est rejetée, mise en pause ou seulement partiellement approuvée, quelqu'un doit toujours savoir ce qui se passe ensuite, qui le fait et quelles informations manquent.
Utilisez cette vérification rapide pour chaque exception de votre processus :
Ensuite, faites un test simple. Donnez le processus à quelqu'un qui ne l'a pas conçu. Remettez-lui une demande rejetée et une demande avec un document manquant. S'il ne sait pas quoi faire en moins d'une minute, le processus est encore trop vague.
Un petit exemple illustre : imaginez qu'un manager approuve une demande logicielle mais refuse la partie matériel. Si le statut indique seulement "Partiellement approuvé", l'employé peut penser que tout peut avancer. Un meilleur statut indique exactement ce qui a été approuvé, refusé et si l'employé peut resoumettre la partie manquante.
Si vous voulez transformer ces règles en application interne, cartographiez d'abord les états d'exception et construisez ensuite le happy path. Dans AppMaster, cela signifie définir statuts, règles métier et champs requis avant de polir les écrans. C'est une manière pratique de créer des applications no-code qui gèrent le travail réel, pas seulement la version idéale.
L'étape suivante est simple : listez vos cinq principales exceptions, assignez un propriétaire à chacune et rédigez le message que l'utilisateur doit voir. Si ces trois points sont clairs, la construction devient généralement beaucoup plus simple.
Pourquoi le "happy path" ne suffit-il pas pour un flux d'approbation ?Parce que les vrais retards surviennent généralement lorsque quelque chose manque, est ambigu, est en retard ou n'est qu'en partie approuvé. Si vous ne concevez que le flux propre, les gens finissent par régler les problèmes par chat, email et solutions manuelles.
Quelles sont les voies d'exception à concevoir en premier ?Commencez par les cas qui se produisent le plus souvent : rejet, information manquante et approbation partielle. Ajoutez ensuite les blocages, comme une demande sans propriétaire ou sans étape suivante définie.
Quels statuts une application d'approbation devrait-elle avoir ?Utilisez un petit ensemble d'états clairs, chacun ayant une seule signification. Par défaut pratique : approuvé, rejeté, besoins de documents, besoin de modifications, partiellement approuvé, et expiré si vous avez des délais.
Comment gérer les documents manquants dans le processus ?L'utilisateur doit voir exactement ce qui manque et ce qu'il doit faire ensuite. Par défaut, placez la demande dans un état comme « Needs documents », nommez clairement les éléments manquants et renvoyez-la à la bonne personne au lieu de rejeter l'ensemble de la demande.
Comment gérer les approbations partielles sans créer de retouches ?Traitez l'approbation partielle comme sa propre voie, pas comme un rejet total. Montrez ce qui a été approuvé, ce qui a été refusé, le nouveau total approuvé si pertinent, et si le demandeur peut accepter la modification, modifier la demande ou ne renvoyer que la partie contestée.
Que doit-il se passer lorsqu'une demande reste bloquée sans action ?Attribuez un propriétaire à chaque état d'attente et définissez une règle de durée. Si un relecteur est absent ou qu'une demande reste trop longtemps sans mouvement, le workflow doit escalader, réaffecter ou expirer au lieu de rester bloqué.
Qu'est-ce qui rend un message d'exception vraiment utile ?Restez simple et précis. Dites à l'utilisateur quelle partie a été rejetée ou manque, ce qui a déjà été accepté, ce qu'il doit faire ensuite et ce qui se passe après la soumission. Une phrase comme « Téléversez le fichier manquant et renvoyez pour vérification » est bien meilleure que « Action requise ».
Faut-il concevoir d'abord les écrans ou d'abord les règles du workflow ?Définissez d'abord les règles. Mettez-vous d'accord sur les statuts, les responsables, les délais, les fichiers requis et les actions suivantes avant de dessiner boutons ou tableaux de bord. L'interface doit refléter des décisions déjà prises.
Comment tester si mon parcours d'exception est suffisamment clair ?Testez un scénario réel du début à la fin avec des chiffres concrets et un ou deux problèmes (par exemple un fichier manquant ou une violation de politique). Si une personne extérieure ne sait pas quoi faire en moins d'une minute, le flux est encore trop vague.
Comment construire ce type de workflow dans AppMaster ?Cartographiez d'abord les états d'exception dans la logique métier avant de peaufiner l'interface. Dans AppMaster, cela signifie définir statuts, champs requis, propriété et branches comme rejeter, renvoyer pour modification ou approuver avec conditions avant d'ajouter le UI.
10 mars 2026
10 min
08 mars 20267 min
07 mars 20269 minExpérimentez avec AppMaster avec un plan gratuit.
Lorsque vous serez prêt, vous pourrez choisir l'abonnement approprié.
