La conception d'une matrice d'approbation commence par définir les seuils, les approbateurs de secours, les suppléants et les escalades afin que vos écrans reflètent le vrai parcours décisionnel.
Un écran soigné peut masquer un processus désordonné. Si la logique d'approbation n'est pas définie en premier, les utilisateurs peuvent voir des boutons Approuver et Refuser sans savoir qui doit agir, quand agir, ni ce qui se passe ensuite.
Cette confusion se manifeste rapidement dans le travail réel. Quelqu'un soumet une demande, elle arrive dans l'application, et la première question est : « Est-ce que ça doit aller au responsable, à la finance, ou aux deux ? » L'écran semble terminé, mais le chemin décisionnel manque.
Cela arrive parce que les écrans simplifient l'apparence des règles. Un formulaire peut afficher le statut, les commentaires et des boutons d'action, mais il ne peut pas deviner la véritable matrice d'approbation qui se cache derrière le processus. Si l'entreprise a des limites par montant, des règles par service ou des délégations temporaires, l'UI commence à casser dès que ces cas apparaissent.
Il suffit souvent d'une exception pour faire sortir le travail de l'application. Les approbations vont habituellement au chef d'équipe, sauf quand la demande est urgente, dépasse un certain montant, ou que l'approbateur est en congé. Si ce cas n'a jamais été cartographié, les gens reviennent aux e-mails, au chat ou aux tableurs.
Puis un problème plus important apparaît : chaque équipe commence à appliquer sa propre version des règles. Les opérations envoient la demande d'une manière, la finance d'une autre, et le support gère les exceptions différemment des RH. L'application devient un écran partagé pour des décisions incohérentes au lieu d'un processus partagé.
Les signes avant-coureurs sont généralement faciles à repérer :
Les mises à jour de politique exposent rapidement cette faiblesse. Quand la logique vit dans l'écran plutôt que dans des règles de workflow claires, chaque changement de seuil ou de rôle se transforme en refonte de l'UI. Cela ralentit les équipes, crée de nouvelles erreurs et fait perdre confiance aux utilisateurs.
L'écran doit refléter le chemin décisionnel, pas le définir. Quand la matrice est claire en premier, l'UI devient plus simple, plus stable et plus facile à utiliser.
Commencez par la logique de décision, pas par l'écran. Une matrice d'approbation solide commence par un tableau simple qui montre qui peut approuver quoi, dans quelles conditions, et ce qui arrive quand quelqu'un n'est pas disponible. Si cette logique est floue, même une interface soignée confondra les gens.
Pour chaque type de demande, cartographiez les niveaux d'approbation dans l'ordre. Notez le rôle qui possède chaque étape et ce que permet cette étape : approuver, rejeter, examiner ou renvoyer. Les rôles fonctionnent mieux que les noms personnels parce que les personnes bougent, les équipes changent, et le processus doit tenir.
Ensuite, définissez les règles qui changent le parcours. Le montant est le déclencheur évident, mais rarement le seul. Les règles de workflow d'approbation dépendent souvent de la région, du service, du type de fournisseur, de la catégorie de demande ou du niveau de risque. Le même montant peut être routinier dans une équipe et sensible dans une autre.
Les absences nécessitent aussi des règles. Si l'approbateur principal est absent, qui prend la relève immédiatement ? Si le suppléant est temporaire, quelles sont les dates applicables ? Sans cela, les demandes restent bloquées parce que personne ne sait qui en est responsable cette semaine.
Les délais comptent tout autant. Décidez ce qui se passe quand une demande reste sans réponse. Vous pouvez envoyer un rappel après un jour, escalader après deux jours et notifier les opérations après trois. Ces choix affectent les libellés de statut, les notifications et les vues de file d'attente, ils doivent donc être réglés avant la conception des écrans.
Une matrice pratique répond généralement à cinq questions de base :
Si vous cartographiez ces réponses tôt, le reste de la construction devient beaucoup plus simple.
Utilisez un tableau, un tableau blanc ou un tableur. Gardez-le assez simple pour qu'un manager, un chef d'équipe et un responsable de processus puissent le comprendre en un seul passage.
D'abord, listez chaque type de demande qui nécessite une approbation. Ne forcez pas tout dans un flux générique si l'entreprise traite déjà les demandes différemment. Une demande d'achat, un remboursement, une approbation de remise et une demande d'accès nécessitent souvent des approbateurs, des limites et des délais différents.
Ensuite, écrivez le premier approbateur puis chaque point de décision après cela. Pour chaque type de demande, notez qui l'examine en premier et ce qui se passe après approbation ou rejet. Suivez le parcours jusqu'à un résultat final tel qu'approuvé, rejeté, renvoyé pour modifications ou annulé.
Après cela, ajoutez les seuils qui changent le parcours. C'est là que beaucoup d'équipes butent plus tard. Si une demande inférieure à 500 $ va au chef d'équipe mais tout montant supérieur à 500 $ va au responsable de service, écrivez-le maintenant. Si les demandes urgentes sautent une étape ou suivent un parcours plus rapide, capturez cela aussi.
Puis enregistrez les exceptions, les délais et les états finaux. Incluez des cas comme documents manquants, demandes en double, violations de politique et approbations en retard. La règle n'est pas terminée tant que vous ne savez pas comment elle se comporte quand les choses tournent mal.
Enfin, révisez le brouillon avec les personnes qui approuvent les demandes aujourd'hui. Demandez où le travail coince habituellement, où les gens sautent des étapes, et ce qui arrive quand l'approbateur normal n'est pas disponible. Les habitudes réelles révèlent souvent des règles qui n'ont jamais été documentées.
Un petit exemple rend cela clair. Imaginez une demande d'achat : fournitures de bureau inférieures à 200 $ vont au chef d'équipe, les logiciels entre 200 $ et 2 000 $ vont au responsable de service, et tout montant supérieur nécessite aussi la finance. Si le formulaire ne capture pas le montant et la catégorie tôt, l'UI ne peut pas envoyer la demande sur le bon chemin.
Les seuils ne fonctionnent que si les gens peuvent les lire rapidement et faire le même choix à chaque fois. Si une règle dit « petits achats » ou « fournisseurs à haut risque », différentes personnes l'interpréteront différemment. Utilisez des nombres fixes, des dates et des conditions nommées à la place.
Une règle plus claire ressemble à ceci : « Jusqu'à 1 000 $ va au chef d'équipe. De 1 001 $ à 5 000 $ va au responsable de service. Au-delà de 5 000 $ va à la finance et au directeur. » Personne n'a à deviner où la demande appartient.
Le montant est fréquent, mais il ne doit pas être le seul déclencheur si votre processus dépend d'autres facteurs. Un achat logiciel peu coûteux auprès d'un nouveau fournisseur peut nécessiter plus de revue qu'une commande plus importante auprès d'un fournisseur approuvé.
La plupart des équipes n'ont besoin que d'un petit ensemble de règles de routage. Exemples courants : plage de montants, statut du fournisseur, catégorie d'achat, service et urgence. L'important n'est pas le nombre de règles, mais que tout le monde les applique de la même manière.
L'ordre des règles compte aussi. Si les gens ne savent pas quelle condition prime, ils routent la même demande différemment. Choisissez un ordre et gardez-le cohérent. Vous pouvez vérifier d'abord le statut du fournisseur, puis la catégorie, puis le montant. Ou vérifier d'abord le montant et traiter les exceptions ensuite. Les deux fonctionnent si tout le monde suit la même séquence.
Il aide aussi de définir qui peut outrepasser un seuil, et quand. Sans cela, le personnel attend trop longtemps ou contourne le processus par e-mail et chat. « Le directeur financier peut approuver les demandes hors limite pendant la clôture de fin de mois » est utile. « La direction peut faire des exceptions » ne l'est pas.
Un test simple marche bien ici : donnez le même exemple de demande à trois personnes et demandez où il doit aller. Si vous obtenez trois réponses différentes, les seuils sont encore trop vagues.
Une matrice forte ne s'arrête pas à l'approbateur principal. Le travail réel continue quand quelqu'un est en congé, malade ou ne répond tout simplement pas. Si vous ne prévoyez pas cela tôt, l'écran peut sembler propre tandis que le processus stagne en silence.
Commencez par nommer l'approbateur de secours pour chaque étape importante. Cela doit être une personne ou un rôle ayant le contexte adéquat, pas seulement « le manager suivant » par défaut. Si un responsable finance approuve les dépenses au-dessus d'un certain montant, décidez qui prend le relais quand cette personne est indisponible.
Les suppléants temporaires ont besoin de limites. Un suppléant doit obtenir les droits d'approbation uniquement pour une période définie, comme des dates de vacances ou un congé planifié. Cela maintient la responsabilité claire et évite des cas où quelqu'un conserve l'accès d'approbation bien après la période prévue.
Une configuration simple devrait répondre à quatre choses : qui est l'approbateur principal, qui est le backup, combien de temps le suppléant peut agir, et quand la demande monte la chaîne.
Les escalades doivent être basées sur des déclencheurs clairs, pas sur des suppositions. Déclencheurs fréquents : temps, montant, risque ou information manquante. Par exemple, si une demande d'achat supérieure à 10 000 $ reste sans réponse pendant 24 heures, elle peut être escaladée au responsable de service.
Gardez le chemin d'escalade court. Si les gens ont besoin d'un diagramme complexe juste pour comprendre qui reçoit la demande ensuite, la règle est probablement trop compliquée. Un ou deux sauts clairs suffisent généralement.
Enregistrez chaque décision également. Sauvegardez qui a approuvé, qui a remplacé, quand le transfert a eu lieu et pourquoi la demande a été escaladée. Cet historique compte quand quelqu'un demande plus tard pourquoi une demande a été retardée ou approuvée par un remplaçant.
Une règle de plus qui compte : évitez les boucles. Une demande ne doit jamais revenir à quelqu'un qui l'a déjà approuvée, ni à un suppléant agissant pour cette même personne. Vérifiez la matrice pour des parcours circulaires avant de construire la logique applicative.
Imaginez une petite entreprise achetant des articles quotidiens. Un employé soumet une demande d'achat avec l'article, le montant, la raison et la date souhaitée. Le routage est piloté par les règles, pas par qui est connecté.
Si la demande est de 420 $, elle va directement au chef d'équipe. Cela permet aux petits achats d'avancer. Une demande à 3 200 $ contourne le chef d'équipe et va au responsable de service parce que l'impact budgétaire est plus important.
Prenez maintenant une demande à 7 800 $ pour du nouvel équipement. Le responsable de service l'examine toujours, mais ce n'est pas suffisant. Comme le montant dépasse 5 000 $, la finance doit aussi l'examiner. C'est là qu'une matrice claire aide : des montants supérieurs ajoutent du contrôle sans ajouter d'incertitude.
Les absences comptent ici aussi. Si le responsable de service est en congé, la demande ne doit pas stagner. Un suppléant nommé la reçoit automatiquement et peut agir pendant la période définie.
Les délais exigent la même clarté. Si personne n'agit sous deux jours, la demande est escaladée aux opérations. Les opérations peuvent relancer, réaffecter ou s'assurer que cela ne bloque pas le travail.
Dans cet exemple, la matrice répond à quelques questions simples mais importantes : quel est le montant demandé, quel rôle approuve à chaque niveau, quand la finance intervient, qui couvre les absences et ce qui arrive quand un délai est dépassé.
Une fois ces réponses définies, la conception des écrans devient simple. Le formulaire n'a besoin que des bonnes données, et la page de demande n'a qu'à montrer l'approbateur actuel, tout suppléant et si l'horloge d'escalade tourne.
La plupart des retouches commencent avant qu'un seul écran ne soit dessiné. Les équipes devinent le chemin d'approbation, puis essaient d'adapter l'UI à des règles qui n'ont jamais été réellement convenues.
Une erreur fréquente est de copier l'organigramme et de l'appeler workflow. Cela peut sembler propre, mais les demandes réelles se déplacent souvent par montant, risque, localisation ou type de demande. Si la matrice ignore cela, les écrans auront ensuite besoin de champs supplémentaires, d'états supplémentaires et d'exceptions maladroites.
Un autre problème est d'oublier les cas spéciaux. Les demandes urgentes, les achats réglementés ou les demandes inter-équipes nécessitent souvent un parcours différent. Si ces exceptions ne sont pas cartographiées tôt, les gens demandent des solutions manuelles et l'interface se remplit d'options ponctuelles qui embrouillent tout le monde.
Les équipes créent aussi des difficultés quand elles donnent à deux personnes la même tâche sans règle de départage. Si les deux peuvent approuver, qui agit en premier ? S'ils ne sont pas d'accord, quelle décision prévaut ? Sans réponse, les demandes rebondissent et les utilisateurs perdent confiance.
Les règles de suppléance sont un autre point faible. Un suppléant doit couvrir une absence, pas devenir silencieusement un second propriétaire pour toujours. Quand la couverture temporaire et la propriété permanente se mélangent, les rapports deviennent confus et la responsabilité disparaît.
Concevoir les formulaires avant que le routage soit réglé crée encore une autre vague de retouches. Un formulaire peut sembler complet, mais une fois les règles d'approbation finalisées, on découvre souvent des champs manquants comme la bande de montant, le service, l'urgence ou un flag politique. Alors la mise en page, la validation et les notifications doivent changer.
Une vérification rapide aide à attraper cela tôt :
Si une réponse est floue, arrêtez-vous là. Fixez la matrice avant de peaufiner les écrans.
Avant d'esquisser un formulaire ou un badge de statut, testez la logique en langage clair. Une bonne matrice d'approbation doit se décrire sans ouvrir un diagramme. Si un manager, un responsable finance ou un collègue opérations ne peut pas décrire le parcours en environ une minute, le processus est encore trop vague pour le travail UI.
Faites une revue rapide avec des exemples concrets. Demandez à une personne d'expliquer le parcours complet de la demande à la décision finale. Vérifiez que chaque résultat probable a un approbateur suivant nommé, pas seulement le chemin heureux. Réécrivez les seuils vagues en règles exactes comme « 1 000 $ et moins » ou « plus de 10 % de remise ». Confirmez que les règles de secours et d'escalade utilisent des délais clairs comme « après 24 heures » ou « après 2 jours ouvrés ».
Ensuite, testez la traçabilité. Quelqu'un demandera plus tard pourquoi une demande a été retardée, qui a approuvé une exception ou quand un suppléant est intervenu. Votre processus doit déjà répondre à ces questions. Les horodatages, l'historique des décisions et des changements de statut clairs ne sont pas des extras. Ils font partie de l'ensemble des règles.
Un scénario simple expose généralement les points faibles. Imaginez une demande d'achat à 4 800 $ arrivant un vendredi après-midi alors que l'approbateur habituel est absent. Qui la reçoit ensuite ? Combien de temps le système attend-il avant de bouger ? Que se passe-t-il si le backup ne fait rien non plus ? Si ces réponses ne sont pas écrites, l'UI masquera la confusion au lieu de la résoudre.
Quand ces vérifications sont satisfaisantes, la conception des écrans devient beaucoup plus simple. Vous ne devinez plus ce que l'interface doit afficher. Vous donnez une forme claire à des règles claires.
Une fois les règles claires, construisez le processus avant de peaufiner les écrans. Commencez par la logique, les champs de données et les états d'approbation. Si le routage fonctionne, l'interface est beaucoup plus simple à concevoir. Si le routage change encore, des écrans attrayants ne feront que masquer les problèmes.
Une première version pratique inclut généralement le strict nécessaire : type de demande, montant, service, approbateur actuel, statut final et un historique clair de chaque décision. Ensuite, ajoutez les règles qui font avancer une demande, envoient au remplaçant ou déclenchent une escalade quand quelqu'un ne répond pas dans les temps.
Gardez les premiers écrans simples. Un demandeur doit pouvoir soumettre, vérifier le statut et répondre aux questions de suivi. Un approbateur doit pouvoir examiner, approuver, rejeter ou réassigner. C'est suffisant pour tester si le workflow a du sens en usage quotidien.
Un ordre de construction sensé :
Cette source de vérité partagée compte plus que beaucoup d'équipes ne l'imaginent. Si le mobile affiche un statut, le panneau web un autre, et le backend suit des seuils différents, la confiance disparaît vite.
Si vous construisez cela dans AppMaster, une matrice claire facilite grandement la configuration. Vous pouvez modéliser les données, la logique métier et le flux d'approbation d'abord, puis porter le même processus sur le backend, le web et le mobile sans réécrire les règles dans des outils séparés.
Utilisez un cas réel pour le premier test. Lancez une vraie demande d'achat avec un seuil, un approbateur suppléant et une escalade pour retard. Observez où les gens hésitent, quelles données manquent et quels libellés de statut les perturbent.
Améliorez le libellé et la mise en page ensuite. Quand le processus fonctionne avec une demande réelle, les écrans sont plus faciles à concevoir et beaucoup moins susceptibles d'être refaits une semaine plus tard.
07 mars 2026
11 min
07 mars 202610 min
20 févr. 202610 minExpérimentez avec AppMaster avec un plan gratuit.
Lorsque vous serez prêt, vous pourrez choisir l'abonnement approprié.
