Le routage par seuil permet de stocker les règles d'approbation dans des tables selon le montant, le département ou la région, afin que les changements de politique n'exigent pas de modifications de code.
Les règles d'approbation codées en dur semblent correctes au départ. Un développeur ajoute quelques conditions, le workflow s'exécute et l'équipe passe à autre chose.
Le problème apparaît lorsque l'entreprise change. La finance augmente une limite de dépense, une région adopte une politique différente, ou un département a besoin d'un approbateur supplémentaire pour certaines demandes. Ce qui semblait être une petite mise à jour devient alors une modification de la logique de l'application, des tests et une attente pour une nouvelle version.
Ce délai coûte cher. Une mise à jour de politique qui devrait prendre quelques minutes peut prendre des jours quand elle dépend de travaux techniques. Pendant cet intervalle, les employés suivent les anciennes règles, les approbations stagnent et les managers commencent à gérer des exceptions par e-mail ou chat.
Les exceptions cachées aggravent le problème. Avec le temps, les équipes ajoutent des règles ponctuelles comme "si le montant est supérieur à 5 000 et que le département est Sales, envoyer au Directeur A" ou "si la demande provient d'Europe, sauter cette étape." Quand ces règles vivent profondément dans le workflow, seules quelques personnes peuvent les voir.
Alors des questions simples deviennent difficiles à répondre :
Quand personne ne peut voir l'ensemble des règles, les erreurs suivent. Quelqu'un pense respecter la politique, mais l'application utilise encore une ancienne règle. Un nouveau manager reçoit des demandes qu'il ne devrait jamais voir, tandis que le vrai approbateur est exclu.
C'est pourquoi le routage par seuil fonctionne mieux quand les politiques d'approbation changent souvent. Au lieu de traiter les règles comme des parties fixes de l'application, vous les stockez comme des données métier qui peuvent être révisées et mises à jour.
Imaginez une politique de dépenses simple. Les demandes inférieures à 1 000 vont à un responsable d'équipe, les demandes de 1 000 à 10 000 vont au chef de département, et tout montant supérieur va à la finance. Si ces limites changent le mois prochain, l'entreprise ne devrait pas avoir besoin d'un développeur juste pour que les approbations continuent.
Coder en dur transforme des mises à jour de politique ordinaires en projets logiciels. Voilà le vrai coût.
Le routage par seuil signifie que le chemin d'approbation change en fonction de valeurs que vous définissez à l'avance. Un seuil est simplement une limite, comme un montant supérieur à 1 000 $, une demande du département Finance ou un achat effectué en Europe.
Au lieu d'écrire ces règles directement dans l'application, vous les stockez dans des tables. Le workflow lit la table, trouve la règle correspondante et envoie la demande à la bonne personne.
Une configuration de base pourrait ressembler à ceci :
Le processus reste le même, mais les valeurs qui le contrôlent peuvent changer.
C'est l'idée clé. La logique est la partie qui dit : "vérifier les règles et choisir la première correspondance." Les données de politique sont la liste des règles elle-même : plages de montant, départements, régions, approbateurs et priorité.
Quand logique et politique sont mélangées, même un petit changement peut nécessiter un développeur pour éditer le workflow. Lorsqu'elles sont séparées, le workflow reste stable et seules les lignes de règles changent.
Par exemple, si Sales en APAC nécessite désormais l'approbation d'un directeur au-delà de 3 000 $ au lieu de 5 000 $, vous mettez à jour une entrée dans la table. Vous ne reconstruisez pas tout le processus d'approbation.
C'est plus simple à gérer parce que la politique change plus souvent que la structure du processus. Les équipes se réorganisent, les budgets évoluent et les régions changent de responsables. Une table gère cela mieux que des conditions codées en dur.
Dans une plateforme no-code comme AppMaster, cela signifie généralement créer une table de règles et laisser le processus métier la consulter à l'exécution. Le modèle est facile à comprendre pour les équipes non techniques car il correspond à la façon dont la politique est rédigée : si cette condition correspond, envoyer ici.
Une bonne table de règles doit répondre à une question simple : quand une demande correspond à ces conditions, qui doit l'approuver ?
Si le routage dépend de valeurs cachées dans le code, chaque mise à jour de politique se transforme en reconstruction. Une table garde ces changements visibles et plus faciles à gérer.
Une table de règles pratique commence généralement par les champs qui décrivent la demande :
Le montant et la devise sont importants car un même nombre peut signifier des choses différentes selon les budgets ou les pays. Une demande de 5 000 USD peut suivre un chemin, tandis que 5 000 EUR ou 500 000 JPY peut en suivre un autre.
Le département et la région reflètent le fonctionnement réel des entreprises. Finance, RH et Opérations ont souvent des chemins d'approbation différents même pour les mêmes dépenses. La région compte aussi lorsque des règles locales ou des responsables diffèrent.
Le type de demande est un autre filtre utile. Voyage, achats de logiciel, paiements fournisseur et approbations de remise peuvent nécessiter des réviseurs différents. Sans ce champ, des demandes non liées peuvent finir par utiliser la même règle.
Pour l'approbateur, stockez un rôle plutôt qu'un nom de personne. Utilisez des valeurs comme Department Manager, Regional Director ou Finance Controller. Quand quelqu'un change de poste, vous mettez à jour l'affectation du rôle une seule fois au lieu d'éditer chaque règle.
Il est aussi utile d'ajouter des dates de début et de fin. Cela couvre les politiques qui commencent à une date donnée, les règles temporaires pendant la saison budgétaire ou les changements planifiés pour le trimestre suivant. Vous conservez l'historique sans laisser des règles expirées actives.
Un champ de priorité vaut également la peine d'être ajouté. Une règle comme "EU + Finance + plus de 10 000" doit généralement l'emporter sur une règle plus large comme "tous départements + plus de 10 000." Une priorité claire rend le routage prévisible.
Gardez la structure simple : une ligne doit correspondre à une règle d'approbation.
Si des dépenses marketing supérieures à 2 000 $ en Europe nécessitent un responsable régional, cela doit vivre dans un seul enregistrement. Quand chaque ligne a un sens clair, la configuration est plus facile à mettre à jour, tester et auditer.
La table principale doit se concentrer sur deux choses seulement : les conditions qui déclenchent une règle et le résultat qui indique au workflow quoi faire ensuite. Cela la rend lisible pour les utilisateurs métier comme pour la personne qui construit le processus.
Une table claire inclut souvent ces champs :
Pour les colonnes de condition, utilisez des champs exacts plutôt que du texte libre quand c'est possible. Un ID de département est plus sûr que de taper "Finance" à la main à chaque fois. Il en va de même pour les codes régionaux, les types de demande et les centres de coût. De petites tables de référence pour départements, régions et rôles d'approbateur aident à éviter les fautes de frappe et facilitent le filtrage.
Pour les colonnes de résultat, décidez ce que le workflow doit retourner. Dans certaines équipes, la règle doit pointer vers une personne spécifique. Dans d'autres, elle doit router vers un rôle comme Regional Manager ou Finance Director. Choisissez une approche et restez cohérent.
La priorité compte car plus d'une règle peut correspondre à la même demande. Ne comptez pas sur l'ordre des lignes ou la date de création. Ajoutez un champ de priorité numérique et définissez son fonctionnement, par exemple 1 vérifié en premier et 100 vérifié plus tard.
Vous avez aussi besoin d'une règle de secours. C'est le filet de sécurité pour tout ce qui n'est pas couvert par une ligne spécifique. Une règle par défaut peut envoyer les demandes non appariées à un responsable des opérations ou à une file d'examen admin. Sans cela, des demandes peuvent rester bloquées sans itinéraire.
Si vous construisez cela dans AppMaster, ces tables peuvent être éditées visuellement, de sorte que les changements de politique se font dans les données plutôt que par des branches de workflow codées en dur.
Commencez par la décision, pas par la table. Notez les questions exactes auxquelles votre workflow doit répondre. Un achat de plus de 5 000 $ nécessite-t-il un manager ? La finance examine-t-elle tout ce qui provient des ventes ? Les demandes d'une région suivent-elles un chemin différent ?
Une fois ces choix clairs, le routage par seuil devient beaucoup plus simple parce que vous stockez la politique au lieu d'essayer de deviner la logique plus tard.
Une configuration simple suit généralement cinq étapes.
Premièrement, créez une table de règles d'approbation avec les champs qui influencent le routage. Les colonnes courantes incluent amount_min, amount_max, department, region, approver_role, priority et active_status.
Deuxièmement, décidez quels champs peuvent rester vides. Un département ou une région vide peut signifier "cette règle s'applique à tous" quand il n'existe pas de correspondance plus spécifique.
Troisièmement, ajoutez les règles des plus spécifiques aux plus générales. Une règle pour "Sales + Europe + plus de 10 000" doit être vérifiée avant une règle large comme "n'importe quel département + n'importe quelle région + plus de 10 000."
Quatrièmement, testez avec des exemples réels avant le lancement. Utilisez des cas limites comme exactement 5 000 $, des données de département manquantes ou une région sans règle personnalisée.
Cinquièmement, limitez qui peut éditer la table. Les changements de politique doivent être simples, mais ils ne doivent pas être ouverts à tout le monde.
Voici un exemple simple. Une demande de 12 000 $ de HR en Amérique du Nord peut d'abord correspondre à une règle "HR au-delà de 10 000" qui l'envoie au directeur RH. Si aucune règle spécifique à HR n'existe, le système peut tomber sur une règle plus large comme "n'importe quel département au-delà de 10 000" qui l'envoie à la finance.
L'ordre est plus important que beaucoup d'équipes ne le pensent. Si des règles larges sont placées au-dessus de règles spécifiques, la mauvaise personne recevra la demande et les utilisateurs cesseront de faire confiance au système.
Avant la mise en service, assignez un propriétaire pour les changements de règle, rédigez un bref document de politique et testez à nouveau après chaque mise à jour. De petits changements de routage peuvent avoir de grands effets.
Imaginez une entreprise qui utilise un seul formulaire de demande d'achat pour toutes les équipes. Chaque demande inclut un montant, un département et une région. Le système vérifie ces valeurs par rapport à une table de règles et choisit le bon approbateur.
Supposons que l'entreprise ait deux départements, Marketing et IT. Les deux peuvent soumettre une demande de 4 000 $, mais le chemin d'approbation n'a pas à être le même.
| Département | Région | Plage de montant | Approbateur |
|---|---|---|---|
| Marketing | US | 0 $ à 5 000 $ | Responsable Marketing |
| Marketing | US | 5 001 $+ | Finance Director |
| IT | US | 0 $ à 3 000 $ | Responsable IT |
| IT | US | 3 001 $+ | CTO |
| Marketing | EU | 0 $ à 5 000 $ | Responsable Marketing Régional |
Comparez maintenant deux demandes avec le même montant. Une demande Marketing de 4 000 $ aux US va au Responsable Marketing. Une demande IT de 4 000 $ aux US ne passe pas par le Responsable IT et va au CTO, parce que l'IT a un seuil plus bas.
La région peut aussi modifier le résultat. Une demande Marketing de 2 500 $ aux US va au Responsable Marketing, mais la même demande en EU va au Responsable Marketing Régional. Le formulaire reste identique. Seule la règle correspondante change.
Voilà la vraie valeur d'une table de règles. La politique vit dans les données, pas dans la logique du workflow.
Si l'entreprise met à jour sa politique le mois suivant, vous n'avez pas besoin de reconstruire tout le processus. Si l'IT décide que les demandes supérieures à 2 000 $ doivent désormais remonter au CTO, vous modifiez une seule ligne :
Tout le reste continue de fonctionner. Les nouvelles demandes suivent la nouvelle politique immédiatement tandis que la structure de l'application reste intacte.
La partie la plus difficile du routage par seuil n'est généralement pas l'idée centrale. Ce sont les cas limites désordonnés qui apparaissent plus tard, quand la politique change et que personne ne se souvient pourquoi une demande a été envoyée à la mauvaise personne.
Une erreur courante est d'avoir des règles qui se chevauchent sans priorité claire. Vous pouvez avoir une règle qui envoie toutes les demandes Marketing supérieures à 3 000 $ au responsable de département et une autre qui envoie toute demande supérieure à 5 000 $ à la finance. Une demande Marketing de 6 000 $ correspond aux deux, donc le système a besoin d'un vainqueur clair. Mettez cette priorité dans la table de règles, pas dans une logique cachée du workflow.
Une autre erreur est de coder en dur des personnes au lieu des rôles ou des groupes. Les noms changent. Les équipes changent. Une personne part en congé ou change de département. Si une règle dit "envoyer à Maria Lopez," vous l'éditez à chaque changement de personnel. Il est plus sûr de router vers un rôle comme Regional Finance Manager ou Sales Director, puis de mapper ce rôle à la personne actuelle.
Ne pas prévoir de chemin de secours provoque des échecs silencieux. Tôt ou tard, une demande ne correspondra à aucune règle parce que le montant est inhabituel, le département est nouveau ou un champ est vide. Dans ce cas, le workflow doit tout de même faire quelque chose de sûr, comme envoyer l'élément à une file par défaut ou à l'équipe admin.
Les exceptions régionales sont un autre point faible. Une politique qui fonctionne dans un pays peut être inadaptée dans un autre à cause de limites locales de dépenses, règles fiscales ou besoins de reporting. Si vous ne testez qu'une région, vous pouvez manquer des cas où les demandes EU, US ou APAC devraient suivre des chemins différents.
Les règles basées sur le temps sont aussi souvent oubliées. Si vous créez une règle temporaire pour la fin de trimestre, un gel budgétaire ou un projet spécial, assurez-vous qu'elle a des dates de début et de fin. Les règles expirées doivent cesser de s'appliquer automatiquement. Sinon, de vieilles exceptions restent actives et envoient des demandes au mauvais endroit.
Avant d'activer le routage par seuil, révisez-le du point de vue d'un utilisateur réel. Chaque demande doit aller au bon approbateur sans que personne n'ait à deviner pourquoi.
Gardez la revue finale simple.
Vérifiez que chaque demande normale a une correspondance claire. Si deux règles peuvent s'appliquer en même temps, les utilisateurs obtiendront des résultats incohérents.
Assurez-vous qu'il existe un chemin de secours. Les départements manquants, les nouvelles régions ou les montants inhabituels doivent toujours aller quelque part de sûr.
Confirmez que les mises à jour de politique peuvent se faire sans développeur. Si Finance ou Operations doit changer des limites, des dates ou des approbateurs, ils doivent pouvoir éditer des enregistrements dans une table plutôt que de demander une modification de code.
Testez les dates, pas seulement les valeurs. La politique d'hier et celle du mois prochain doivent se comporter comme prévu quand des dates effectives sont en jeu.
Rédigez la logique de routage en une page en langage simple. Si un manager ne peut pas l'expliquer clairement, c'est probablement trop complexe.
Un test final utile consiste à créer cinq demandes d'exemple couvrant cas normaux, cas limites et cas de politique obsolète. Si votre équipe peut prédire le résultat avant de les lancer, la configuration est probablement prête. Sinon, simplifiez-la.
Commencez petit. Choisissez un flux d'approbation qui cause le plus de retard ou de confusion aujourd'hui, comme les demandes d'achat au-delà d'un certain montant ou les notes de frais par département. Construisez cela en premier, testez-le avec des cas réels, puis ajoutez d'autres types de règles.
Cette approche rend le modèle de routage plus fiable. Les gens peuvent voir comment les règles fonctionnent, où apparaissent les exceptions et ce qui doit être modifié avant d'étendre la configuration.
Le premier déploiement doit répondre à quatre questions de base :
Ce dernier point est très important. Si personne ne prend clairement en charge les mises à jour de politique, le workflow dérivera lentement de la façon dont l'entreprise fonctionne réellement. Attribuez une personne ou une petite équipe pour réviser les changements de règles, approuver les éditions et conserver un bref historique indiquant pourquoi une politique a changé.
Il est aussi utile de définir un calendrier de révision. Si les politiques changent souvent, révisez les règles chaque mois. Si le processus est stable, un rythme trimestriel peut suffire. Une courte revue peut détecter des seuils obsolètes, des départements manquants ou des exceptions régionales avant qu'ils ne provoquent des retards.
Restez pragmatique lors de la revue. Posez des questions simples : les approbations vont-elles aux bonnes personnes, des équipes ont-elles changé de structure, les limites actuelles correspondent-elles encore à la politique financière, y a-t-il trop d'interventions manuelles ?
Si vous voulez construire cela visuellement, AppMaster peut être un bon choix pour créer la table de règles, le processus de routage et les écrans d'administration où le personnel non technique met à jour les politiques. Conçu pour des applications no-code complètes, il fonctionne bien quand vous voulez que les équipes métier gèrent directement les changements d'approbation plutôt que d'envoyer chaque mise à jour aux développeurs.
Une fois qu'un flux fonctionne bien, réutilisez le même modèle pour le processus suivant. De petites étapes claires fonctionnent généralement mieux qu'une reconstruction complète.
Qu'est-ce que le routage par seuil ?Cela signifie que l'application choisit un chemin d'approbation à partir de données de règles plutôt que de branches fixes dans le workflow. Par exemple, le montant, le département ou la région peuvent décider qui approuve une demande, et vous pouvez modifier ces valeurs dans une table sans reconstruire tout le processus.
Pourquoi les règles d'approbation codées en dur posent-elles problème ?Les règles codées dans l'application tiennent au départ, mais chaque changement de politique devient un travail de développement, de tests et de publication. Une table de règles est plus rapide car le workflow reste identique tandis que les valeurs de politique changent.
Que dois-je mettre dans une table de règles d'approbation ?Commencez par les champs qui influencent réellement le routage, comme montant minimum, montant maximum, devise, département, région, type de demande, rôle de l'approbateur, priorité et statut actif. Si vous avez des politiques temporaires, ajoutez aussi des dates de début et de fin.
Dois-je stocker les noms des approbateurs ou leurs rôles ?Les rôles sont généralement préférables. Si vous orientez vers un rôle comme Finance Director ou Department Manager, les changements de personnel sont plus simples : vous mettez à jour l'affectation du rôle une fois au lieu d'éditer de nombreuses règles.
Comment gérer les règles d'approbation qui se chevauchent ?Utilisez un champ de priorité clair et définissez quelle valeur gagne. Le système doit vérifier la règle la plus spécifique en premier : une règle étroite comme « UE + Finance + plus de 10 000 » doit battre une règle large « tous départements + plus de 10 000 ».
Que se passe-t-il si aucune règle ne correspond à une demande ?Ajoutez une règle de secours. Si une demande a des données manquantes ou ne correspond à aucune ligne spécifique, elle doit tout de même aller vers une file sûre, une équipe admin ou un approbateur par défaut au lieu de rester bloquée.
Des équipes non techniques peuvent-elles mettre à jour les règles d'approbation elles-mêmes ?Oui, si le système est conçu ainsi. Dans AppMaster, vous pouvez conserver les règles dans des tables et laisser le processus métier les lire à l'exécution, de sorte que le personnel autorisé peut modifier les données de politique via des écrans d'administration sans toucher au code.
Pourquoi ajouter des dates de début et de fin aux règles ?Les dates d'effet permettent de planifier des changements et de retirer automatiquement des exceptions temporaires. Elles sont utiles pour les règles de fin de trimestre, les gels budgétaires ou les modifications qui commencent le mois prochain sans affecter les demandes en cours.
Comment tester le routage par seuil avant le lancement ?Testez des cas réels avant le lancement, en particulier les cas limites. Vérifiez les valeurs exactes de seuil, les champs vides, les nouveaux départements, les exceptions régionales et les politiques expirées afin de garantir qu'une demande a bien une unique route claire.
Quelle est la meilleure façon de commencer à utiliser cette approche ?Commencez par un flux d'approbation qui cause déjà des retards, comme les demandes d'achat ou les notes de frais. Gardez la première version simple, vérifiez que les règles fonctionnent, puis appliquez le même modèle à d'autres processus.
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é.
