Workflows d'approbation ERP : concevoir une matrice de délégation qui ne bloque pas l'activité

Un workflow d’approbation ERP est généralement configuré pendant le projet, à partir de l’organigramme du moment. Six mois plus tard, un directeur part en congé, un service est réorganisé, une commande urgente doit partir avant midi. Le circuit se bloque, et l’entreprise invente ses propres règles : mots de passe partagés, approbations par e-mail, commandes passées hors système. Le contrôle interne n’a pas disparu par malveillance, il a été contourné par nécessité.

Ce guide s’adresse aux DAF, DSI et responsables achats ou finance. Il propose une méthode pour concevoir des circuits d’approbation qui survivent à la vie réelle (absences, réorganisations, urgences) tout en restant défendables devant un auditeur.

Pourquoi les workflows d’approbation génèrent plus de contournements que de contrôle

Un circuit d’approbation poursuit deux objectifs qui s’opposent en apparence : garantir qu’aucune dépense ou écriture sensible ne passe sans validation légitime, et ne pas ralentir l’activité. Quand le second objectif est sacrifié, les utilisateurs rétablissent la fluidité par d’autres moyens.

Les 5 erreurs classiques de conception (et leur contre-mesure)

Les mécanismes de contournement les plus courants sont toujours les mêmes. Chacun a une cause de conception et une réponse précise.

1. Le partage d’identifiants

• Piège : le collaborateur d’un directeur absent se connecte avec le compte de celui-ci pour « débloquer » les validations.
• Conséquence : la traçabilité devient fausse, ce qui est pire que l’absence de traçabilité, et l’auditeur ne peut plus attribuer une décision.
• Contre-mesure : une suppléance nominative et datée, saisissable en libre-service, plus un suppléant permanent par rôle.

2. Le fractionnement de commandes

• Piège : trois commandes de 4 000 € plutôt qu’une de 12 000 € pour rester sous le seuil de validation.
• Conséquence : l’engagement réel échappe au niveau d’approbation prévu, et le pouvoir de signature est contourné.
• Contre-mesure : un contrôle de cumul par fournisseur et par période, avec alerte au propriétaire du circuit.

3. La régularisation a posteriori sauvage

• Piège : le bien est commandé ou le service rendu, puis la demande est saisie après coup, sans mention de l’exception.
• Conséquence : le budget n’a pas été vérifié avant l’engagement, et l’exception devient la norme.
• Contre-mesure : une voie d’urgence officielle, avec motif obligatoire et revue ultérieure (voir plus bas).

4. L’approbation hors ERP

• Piège : un e-mail ou un message instantané tient lieu de validation, l’ERP ne reçoit que la commande finale.
• Conséquence : la preuve d’approbation est dispersée, invérifiable et non exploitable en audit.
• Contre-mesure : approbation depuis la messagerie ou le mobile mais enregistrée dans l’ERP, et mesure du taux de contournement.

5. Le sur-approbateur

• Piège : un seul dirigeant reçoit toutes les demandes « au cas où ».
• Conséquence : goulot d’étranglement, validations non lues, et blocage total à chaque absence.
• Contre-mesure : des seuils par palier, des rôles intermédiaires et des délégations plafonnées.

Ces comportements ont des causes de conception, pas des causes disciplinaires. Un circuit qui ne prévoit ni l’absence, ni l’urgence, ni la réorganisation pousse mécaniquement à la fraude de commodité. La bonne réponse n’est pas de durcir le circuit mais de le concevoir avec ses exceptions.

Partir de la délégation de pouvoirs, pas de l’organigramme

L’organigramme décrit qui rapporte à qui. La délégation de pouvoirs décrit qui peut engager l’entreprise, pour quel montant, sur quelle nature de dépense et dans quelle entité. Ce sont deux documents différents, et seul le second doit piloter le paramétrage de l’ERP.

La matrice seuils x nature x entité

La matrice de délégation est un tableau à trois dimensions :

Dimension	Exemples
Seuil	Montant de l’engagement, souvent par tranches (en dessous de X, entre X et Y, au-delà de Y)
Nature	Achats de biens, prestations intellectuelles, investissements, frais de déplacement, paiements bancaires
Entité	Société, établissement, centre de coûts, pays

Chaque cellule de la matrice désigne un rôle (et non une personne) : responsable de centre de coûts, directeur de site, DAF, directeur général. Le rôle est ensuite rattaché à des personnes nommées, avec leurs suppléants.

Les principes de construction

1. Raisonner en rôles. Un circuit qui cite « Marie Dupont » casse au premier départ. Un circuit qui cite « responsable budgétaire du centre de coûts » survit à l’arrivée de son successeur.
2. Aligner la matrice sur les documents juridiques. Les montants de la matrice doivent correspondre aux délégations de pouvoirs formalisées (statuts, décisions du dirigeant, procédures internes). L’ERP ne crée pas de pouvoir, il reflète celui qui existe.
3. Limiter le nombre de niveaux. Au-delà de trois niveaux d’approbation, le délai s’allonge et la qualité des validations baisse. Mieux vaut peu de niveaux, bien paramétrés, que cinq niveaux rituels.
4. Désigner un propriétaire métier du circuit. Le DSI paramètre, mais le propriétaire du circuit (le responsable achats pour le procure-to-pay, le DAF pour les écritures et paiements) décide des règles et valide les changements.
5. Versionner la matrice. Chaque modification (seuil, rôle, entité) est datée, justifiée et approuvée. Un auditeur doit pouvoir reconstituer la règle en vigueur à la date d’une transaction.

Le versionnement est souvent négligé. Il suffit pourtant d’un document sous gestion documentaire, avec numéro de version, date d’effet et approbateur. L’ERP applique la version courante, le dossier garde les précédentes.

Les 5 familles de circuits

Tous les circuits ne se conçoivent pas de la même façon. Voici les cinq familles à traiter, avec pour chacune les approbateurs habituels et les contrôles à prévoir. Les seuils sont volontairement laissés en variables : ils dépendent de la taille de l’entreprise et de sa tolérance au risque, et doivent venir de votre propre matrice.

Famille	Approbateurs types	Logique de seuil	Contrôles associés
Demande d’achat	Responsable du centre de coûts, puis responsable achats ou directeur de site selon montant	Montant estimé, nature de la dépense	Budget disponible, imputation analytique, catalogue ou contrat cadre existant
Commande fournisseur	Acheteur, puis responsable achats, DAF ou DG selon montant	Montant total de la commande, fournisseur référencé ou non	Fournisseur validé, conditions négociées, absence de fractionnement
Facture fournisseur	Réceptionnaire (service fait), puis valideur budgétaire, puis comptabilité	Écart avec la commande, montant, absence de commande	Rapprochement commande, réception et facture (three-way match), tolérances d’écart
Note de frais	Manager direct, puis comptabilité ; direction pour les frais de la direction	Montant, nature, justificatifs	Respect de la politique de frais, justificatifs, doublons
Écritures et paiements	Comptable (saisie), responsable comptable ou DAF (validation), deux signataires pour les paiements	Nature de l’écriture (manuelle, extourne, clôture), montant du paiement	Séparation saisie/validation, double validation des virements, modification des coordonnées bancaires fournisseurs

Quelques remarques de conception :

• La demande d’achat et la commande n’ont pas le même rôle. La demande valide le besoin et le budget, la commande valide l’engagement vis-à-vis du fournisseur. Les confondre en une seule validation affaiblit les deux.
• La facture fournisseur est le circuit le plus bruyant. Il est utile de distinguer la validation du « service fait » (par le métier qui a reçu la prestation) de la validation comptable. Le premier atteste, le second contrôle.
• Les modifications de données fournisseurs (RIB, raison sociale) méritent un circuit propre. C’est un vecteur classique de fraude au changement de coordonnées bancaires, et il se traite par une double validation indépendante, pas par un simple champ modifiable.
• Les écritures manuelles doivent être approuvées par une personne distincte de celle qui les saisit, avec une exigence renforcée en période de clôture.

Pour le détail du cycle d’achat lui-même, voir notre guide sur la gestion des achats et le procure-to-pay dans l’ERP.

Absences, suppléances et escalades automatiques

C’est le point où la plupart des circuits échouent. Il faut le traiter comme une règle de conception, pas comme un cas particulier.

Les règles de délégation temporaire

• Une suppléance nominative et datée. Le délégant désigne un suppléant, pour une période définie, depuis l’ERP. Aucun partage de compte, jamais.
• Un suppléant de même niveau ou supérieur. Un approbateur ne délègue pas à quelqu’un dont le propre plafond est inférieur au sien, sauf à plafonner explicitement la délégation.
• Un plafond de délégation. Une suppléance peut être limitée en montant : le suppléant approuve jusqu’à un seuil, au-delà duquel la demande remonte.
• Une suppléance par défaut. Chaque rôle d’approbateur a un suppléant permanent désigné à l’avance, qui s’active si aucune suppléance n’a été saisie. On ne dépend pas de la prévoyance de la personne absente.
• Pas d’auto-approbation par délégation. Si un utilisateur devient suppléant de la personne qui valide ses propres demandes, le système doit bloquer l’approbation de ses propres documents.

Délais et relances

Un circuit sans délai est un circuit qui s’enlise. Prévoir pour chaque étape :

1. Une relance automatique après un délai court, adressée à l’approbateur.
2. Une escalade après un délai plus long, vers le suppléant puis vers le niveau hiérarchique supérieur.
3. Une alerte de blocage à destination du propriétaire du circuit, pour traiter les demandes durablement en attente.

Les délais exacts dépendent de votre activité : un circuit de réapprovisionnement industriel n’a pas le même rythme qu’un circuit d’investissement. L’essentiel est qu’ils soient explicites, paramétrés et suivis. Une escalade doit être tracée comme telle : elle ne vaut pas approbation silencieuse. Approuver automatiquement une demande après un délai sans réponse est une mauvaise idée dans la plupart des contextes, car cela transforme l’inaction en validation.

Gérer les exceptions : urgences, approbation a posteriori, dérogations tracées

Même un circuit bien conçu rencontrera des cas hors norme : panne de production un samedi, fournisseur critique à payer avant une échéance, dirigeant injoignable. Si l’ERP ne prévoit pas de voie d’exception, les utilisateurs en créeront une.

Trois mécanismes à prévoir :

• La procédure d’urgence. Un statut « urgent » est ouvert à des rôles désignés, avec un motif obligatoire. La commande peut partir, mais elle est signalée et soumise à revue.
• L’approbation a posteriori. Pour certaines natures de dépense strictement listées (dépannage, sécurité des personnes), la validation peut intervenir après l’engagement, dans un délai court et défini. Passé ce délai, un rappel remonte au propriétaire du circuit.
• La dérogation tracée. Quand une règle doit être levée (fournisseur non référencé, dépassement de seuil), la dérogation est demandée, motivée, approuvée par un niveau supérieur et conservée avec la transaction.

Le principe commun : l’exception est autorisée, mais jamais invisible. Chaque exception génère une trace consultable, et un reporting périodique en donne le volume au propriétaire du circuit. Une exception qui devient fréquente est un signal : soit le circuit nominal est mal calibré, soit une pratique de contournement s’installe.

Articulation avec la ségrégation des tâches

La matrice de délégation et la ségrégation des tâches (SoD) sont deux faces du même contrôle. La première dit qui peut approuver quoi, la seconde interdit les cumuls dangereux.

La règle de base : un même utilisateur ne doit pas créer et approuver le même document, qu’il s’agisse d’une demande d’achat, d’une commande, d’une facture ou d’un paiement. Ce principe doit résister à toutes les configurations :

• À la délégation, comme évoqué plus haut : le suppléant ne valide pas ses propres saisies.
• Aux changements de rôle, quand un collaborateur cumule temporairement deux fonctions après une réorganisation.
• Aux profils à privilèges élevés, comme les administrateurs, qui ne devraient pas pouvoir approuver dans les circuits métier qu’ils paramètrent.

Un point souvent oublié : celui qui peut modifier un circuit d’approbation peut potentiellement se l’accorder à lui-même. L’accès à la configuration des workflows doit être restreint, journalisé et séparé des droits d’approbation.

Ces sujets sont détaillés dans nos articles sur les 12 contrôles SoD à implémenter avant l’audit annuel et sur la gouvernance des habilitations ERP.

Mesurer : délai moyen d’approbation, taux d’escalade, taux de contournement

Un circuit non mesuré se dégrade sans que personne ne le voie. Trois indicateurs suffisent pour démarrer :

Indicateur	Ce qu’il révèle	Comment le lire
Délai moyen d’approbation (par famille et par étape)	Les goulots d’étranglement	Un délai qui s’allonge sur une étape pointe un approbateur surchargé ou une règle trop large
Taux d’escalade	La fiabilité des approbateurs et des suppléances	Un taux élevé sur un rôle suggère une absence de suppléant ou un seuil mal placé
Taux de contournement	La part des transactions passées hors circuit nominal	Sont comptés : commandes sans demande d’achat, factures sans commande, dérogations, approbations a posteriori

Le taux de contournement est le plus révélateur, et le plus difficile à produire. Il se construit en croisant les données de l’ERP : commandes créées sans demande préalable, factures sans bon de commande, écarts entre la date de l’engagement et celle de l’approbation. Aucun seuil universel n’existe ; ce qui compte est la tendance et la comparaison entre entités ou services.

Ces indicateurs doivent être présentés au propriétaire du circuit à une fréquence régulière. Sans cette boucle de retour, le paramétrage est figé alors que l’organisation évolue.

Exemples de paramétrage dans SAP, Dynamics 365 / Business Central et Odoo

Les principes ci-dessous sont volontairement génériques : les écrans et options varient selon les versions et les éditions, et doivent être vérifiés dans la documentation officielle de votre version avant tout paramétrage.

SAP.

• Forces : les stratégies de validation (release strategies) des achats déterminent, selon des critères de gestion comme le montant ou le groupe d’achats, quels codes de validation sont requis sur une demande d’achat ou une commande. Cela correspond naturellement à une matrice seuils x nature x entité. Les mécanismes de workflow et de suppléance permettent aussi de rediriger les tâches vers un remplaçant, et la traçabilité des documents est solide.
• Limites : le paramétrage est technique et repose sur des critères (classes, caractéristiques) qu’il faut maintenir. Une matrice mal préparée en amont se traduit par des stratégies nombreuses et difficiles à relire. Chaque changement d’organisation demande une intervention spécialisée.
• Pertinence cible : groupes et ETI avec de nombreuses entités et un besoin de contrôle fin, qui disposent d’équipes ou de partenaires capables de maintenir les stratégies. Moins adapté à une PME sans compétence interne dédiée.
• Point de vigilance : préparez la matrice de délégation avant d’ouvrir le paramétrage, et limitez le nombre de stratégies de validation à ce que le propriétaire du circuit peut relire. Testez les cas d’absence et de suppléance avec des utilisateurs réels, vérifiez que la suppléance ne permet pas d’approuver ses propres documents, et assurez-vous que les journaux de validation sont extractibles pour l’audit.

Microsoft Dynamics 365 et Business Central.

• Forces : des modèles de workflow d’approbation prêts à l’emploi, avec des approbateurs, des limites d’approbation par utilisateur et la possibilité de désigner des remplaçants. Dans Business Central, la configuration des utilisateurs approbateurs (approbateur direct, limite de montant, remplaçant) structure la chaîne de validation de manière lisible pour un responsable financier.
• Limites : des plafonds par personne sont faciles à créer mais difficiles à maintenir si l’on ne raisonne pas en rôles : chaque départ ou promotion oblige à revoir les fiches. Les cas complexes (multi-entités, natures de dépense variées) demandent des workflows personnalisés.
• Pertinence cible : PME et ETI déjà dans l’écosystème Microsoft, qui veulent des circuits compréhensibles par les métiers et peu de développement spécifique.
• Point de vigilance : avant le go-live, testez le comportement d’un approbateur absent sans remplaçant désigné, d’un demandeur qui est aussi approbateur, et d’un montant situé exactement sur un palier. Vérifiez également qui peut modifier les limites d’approbation : ce droit de configuration doit être séparé des droits d’approbation, et ses modifications journalisées pour être présentées à l’auditeur. Ce point est trop souvent traité tardivement, alors qu’il conditionne la crédibilité de tout le circuit.

Odoo.

• Forces : une approbation des commandes d’achat déclenchée à partir d’un montant minimum, simple à activer, et un écosystème de modules et d’outils de personnalisation qui permettent d’ajouter des circuits multi-niveaux selon l’édition utilisée.
• Limites : la couverture dépend fortement des modules installés et de l’édition. Il faut vérifier que la fonction d’approbation couvre chaque famille de circuits (demande, commande, facture, note de frais, paiement) et que sa piste d’audit suffit à un auditeur. Les suppléances et escalades peuvent nécessiter des développements complémentaires.
• Pertinence cible : PME et structures en croissance qui acceptent de cadrer précisément leur périmètre fonctionnel et de documenter leurs paramétrages, avec un intégrateur qui maîtrise les modules retenus.
• Point de vigilance : documentez, pour chaque famille de circuits, quel module porte l’approbation, qui en est le propriétaire métier et comment les droits d’accès sont attribués. Sur un ERP modulaire, l’ajout d’un module ou une mise à jour de version peut modifier le comportement d’un circuit : rejouez vos tests d’absence et de seuils après chaque évolution significative, et conservez la trace des versions de la matrice appliquée. Cette discipline évite qu’un circuit validé au lancement ne dérive silencieusement au fil des mises à jour.

Dans les trois cas, trois vérifications s’imposent avant le go-live :

1. Le test avec cas d’absence : simuler le départ d’un approbateur, un suppléant sans droit suffisant, un approbateur qui est aussi le demandeur.
2. Le test des seuils : vérifier le comportement juste en dessous et juste au-dessus de chaque palier.
3. La journalisation : s’assurer que chaque approbation, délégation, escalade et dérogation est enregistrée avec l’utilisateur, la date et le document, et que l’auditeur peut l’extraire.

Checklist de revue annuelle

Une revue annuelle de la matrice et des circuits suffit généralement ; elle doit en plus être déclenchée à chaque réorganisation significative.

• La matrice de délégation en vigueur correspond aux délégations juridiques formalisées.
• Chaque circuit a un propriétaire métier nommé.
• Chaque approbateur a un suppléant permanent actif et compétent.
• Les comptes des collaborateurs partis ou ayant changé de poste ont été retirés des circuits.
• Aucune règle ne permet à un utilisateur d’approuver ses propres documents.
• Les accès à la configuration des workflows sont restreints et journalisés.
• Les exceptions de l’année (urgences, a posteriori, dérogations) ont été revues et leurs causes traitées.
• Les trois indicateurs (délai, escalade, contournement) ont été analysés par famille de circuit.
• Un test d’absence a été rejoué sur au moins un circuit par famille.
• La version de la matrice a été mise à jour, datée et approuvée.

Pour aller plus loin

Un workflow d’approbation n’est solide que s’il repose sur des accès bien gouvernés. Commencez par notre guide de gouvernance des habilitations ERP, puis appliquez les contrôles SoD avant audit. Pour cadrer votre matrice de délégation ou auditer vos circuits actuels, contactez-nous.