Avant de digitaliser, regarder le processus réel

Le workflow parfait suit une procédure qui n’existe plus

Cette analyse rétrospective porte sur 2019 et a été écrite en 2026. Le récit est fictif, les données pédagogiques, et aucun résultat n’est attribué à un client ou à CYTIZEN. Le propos concerne le cadrage d’une transformation métier et IT : observer le travail pour décider ce qu’il faut simplifier, encadrer ou automatiser.

Sophie, responsable achats, montre à l’équipe projet une procédure de six validations. Le futur outil doit envoyer chaque demande dans cet ordre. Karim, chef de projet, accompagne ensuite une acheteuse sur dix dossiers. Dans quatre cas, le valideur appelle le demandeur avant de cliquer. Dans deux autres, un directeur donne son accord par courriel puis l’assistante saisit après coup une justification. Un troisième contrôle ne sert qu’à vérifier une donnée déjà renseignée par la finance.

La procédure n’est pas fausse parce que les personnes travailleraient mal. Elle est devenue une représentation incomplète : exigences nouvelles, informations absentes, exceptions urgentes et contrôles hérités se sont ajoutés au fil du temps. Digitaliser cette représentation sans l’examiner automatise certaines files d’attente et laisse les contournements en dehors du système.

Définir le résultat avant de dessiner la cible

Sophie veut réduire le délai d’une demande à une commande, tout en conservant le contrôle des engagements. Ces deux objectifs doivent être décomposés. Quelle catégorie de demande ? À partir de quel événement ? Jusqu’à quelle preuve de commande ? Le cadrage distingue achats récurrents, création de fournisseur, investissement et urgence de maintenance. Une moyenne qui mélange ces familles rendrait les décisions de simplification arbitraires.

Le premier périmètre retient les achats récurrents sous un montant illustratif de 5 000 euros, avec un fournisseur déjà référencé. Les investissements et achats urgents sont étudiés séparément. Ce choix ne signifie pas qu’ils seraient moins importants : leurs contrôles et responsabilités diffèrent. Le responsable de processus confirme les critères d’entrée et explique quels cas resteront hors du futur chemin standard.

L’équipe précise aussi ce qu’elle ne peut pas décider seule. Une séparation de tâches imposée, un contrôle financier ou une exigence qualité ne disparaît pas parce que sa case rallonge le diagramme. Les fonctions compétentes doivent dire quelle preuve est nécessaire et si un autre mécanisme peut la produire. Le programme facilite l’examen ; il n’arbitre pas une obligation sur la seule base du temps gagné.

Suivre les dossiers, pas seulement organiser un atelier

Karim prépare un échantillon avec demandes terminées, abandonnées, urgentes et reprises. Chaque dossier conserve identifiant, date, montant, site, type et résultat. Il observe les événements : création, attente, correction, validation, transmission et réception. Les entretiens expliquent les causes, mais les horodatages apportent une autre information. Une personne peut travailler dix minutes sur un dossier qui attend quatre jours dans sa file.

Le relevé associe travail effectif et attente. Il indique les ressaisies, les informations manquantes et les contrôles réalisés hors outil. Si les données d’événements sont imparfaites, l’équipe combine observation et traces existantes, puis décrit les limites. Elle ne fabrique pas une précision à la seconde à partir de souvenirs. Les personnes observées savent pourquoi elles participent ; l’exercice cherche à améliorer le processus, pas à classer secrètement leur productivité.

Un atelier sert ensuite à confronter les versions. Pourquoi le directeur valide-t-il par courriel ? Parce qu’il ne possède pas les données utiles dans l’outil. Pourquoi l’acheteuse ressaisit-elle la justification ? Parce que le reporting n’exploite pas le message d’origine. Ces réponses permettent d’envisager une modification de données et de preuve, plutôt qu’une nouvelle notification automatique.

Le relevé qui change la discussion

Chaque contrôle doit expliquer sa raison

Sophie et la finance examinent les six validations. Pour chacune, elles précisent le risque couvert, la donnée utilisée et la personne habilitée. Deux étapes contrôlent le même montant avec la même information. Leur redondance peut être utile si elle assure une indépendance réelle ; elle peut être inutile si les deux acteurs se fient automatiquement au même fichier. Le nombre d’étapes ne permet pas de conclure.

Une suppression proposée indique le mécanisme de remplacement et les cas où il ne suffit pas. Dans l’exemple, le fournisseur approuvé est vérifié à la source, tandis qu’un changement de coordonnées déclenche un contrôle particulier. Le dossier conserve la décision des achats, de la finance et de la fonction compétente sur les risques. Il ne suffit pas de dessiner une nouvelle flèche pour modifier une responsabilité.

Les seuils sont eux aussi examinés. Un montant sous 5 000 euros peut paraître faible, mais vingt achats fractionnés ne représentent pas la même exposition. Le processus doit traiter les exceptions plausibles et la répétition. Le programme ne promet pas un contrôle automatique tant que la donnée permettant de le réaliser n’est pas disponible et suffisamment fiable.

Décrire la cible comme un contrat de fonctionnement

Le chemin standard indique qui saisit, les informations requises, les validations nécessaires et le moment où le dossier peut passer à l’ERP. Les règles sont explicites : un fournisseur absent ou une donnée modifiée déclenche une branche particulière. Une erreur ne renvoie pas simplement le demandeur à la première étape ; elle explique le problème, son propriétaire et le mécanisme de correction.

Karim demande au métier de rejouer trois dossiers avec la cible sur papier avant tout développement. Le nominal fonctionne. L’urgence révèle que le valideur n’est pas toujours disponible. L’équipe définit alors un remplacement autorisé et une trace. Le dossier avec centre de coût incorrect montre que le support doit pouvoir faire corriger la source sans autoriser une dépense lui-même. Ces découvertes coûtent peu avant paramétrage et beaucoup après déploiement.

Le périmètre d’automatisation vient ensuite : règle stable, donnée contrôlée, exception orientable et responsabilité de traitement. L’outil doit conserver l’histoire des décisions et les changements pertinents. Si un fournisseur propose une fonction séduisante qui ne couvre pas le parcours urgent, le programme chiffre l’écart au lieu de considérer la démonstration comme une preuve d’adéquation.

Calculer le gain sans faire disparaître le travail

Le délai de bout en bout va de la demande recevable à la commande transmise. Le temps de travail additionne les interventions réellement nécessaires. La distinction évite de vendre trois jours économisés comme trois jours de charge humaine libérée. Les retours en correction et les opérations hors outil sont conservés dans la mesure.

Dans le scénario, une demande récurrente passe de 18 à 12 minutes de travail, sur un volume théorique de 800 demandes mensuelles. Le gain brut est 800 multiplié par six minutes, soit 80 heures. Il faut retrancher contrôles par exception, support supplémentaire et entretien des données. La capacité restante n’est pas une économie financière automatique : le manager précise comment elle pourra être utilisée ou si elle évite une charge future.

Les volumes sont testés avec des hypothèses prudentes. Si un quart des demandes quitte le standard, leur traitement peut absorber le gain attendu. Le business case comporte donc une sensibilité au taux d’exception. Une baisse de délai sans réduction de charge peut rester utile pour l’activité, mais elle doit être présentée comme telle.

Mettre la nouvelle règle à l’épreuve avant de généraliser

Le pilote porte sur un site et une famille d’achat, avec un responsable métier disponible. Le support possède les procédures de reprise, les achats observent les exceptions et la finance contrôle un échantillon convenu. Les utilisateurs indiquent les informations qu’ils cherchent encore dans un courriel ou un fichier local. Ces pratiques ne sont pas ignorées au motif qu’elles seraient extérieures au processus cible.

L’équipe compare les dossiers de même famille avant et après, en précisant la taille des échantillons. Elle suit la médiane de délai, les dossiers très longs, le taux de retour et les exceptions. Dans ce cas, une progression du taux d’exception au-dessus de 20 % provoquerait une revue des critères d’entrée. Le seuil est pédagogique ; l’organisation doit choisir le sien selon ses volumes et risques.

Une extension exige que les corrections soient intégrées dans la règle, les données et le support. Si le pilote fonctionne grâce à la présence permanente de Karim et Sophie, la cible n’est pas encore un service durable. Les opérateurs courants doivent pouvoir exécuter le parcours sans leur assistance.

L’adaptation sectorielle se joue sur les exceptions

Dans la pharma, un achat peut concerner un équipement ou un composant avec exigences qualité spécifiques. La cible doit préserver les validations pertinentes et leur traçabilité. Un circuit rapide réservé aux dépenses courantes ne peut pas devenir la voie implicite pour contourner une qualification.

Dans l’industrie, l’urgence de maintenance impose une procédure qui fonctionne quand le valideur habituel est absent et que la production risque l’arrêt. L’autorisation, la réception et le rapprochement après intervention doivent rester explicites. Dans la banque, la séparation des tâches et les habilitations de paiement peuvent empêcher qu’un même acteur crée le fournisseur et autorise l’engagement sans contrôle adapté.

Dans une organisation de services, les achats de prestations demandent parfois une description de résultat et une validation de service fait plus importante que la réception physique. Le diagramme standard ne suffit pas à ces différences. L’analyse doit décider quelles branches partager et lesquelles conserver, avec leur coût d’exploitation.

Sources et méthode

Les références sont des repères officiels de gouvernance, de mesure et de qualité des données, consultés en 2026. Le Government Data Quality Framework, publié en 2020, est un éclairage actuel et n’est pas présenté comme une source disponible en 2019. Le protocole d’observation, les calculs et les choix du cas sont originaux. Ils ne constituent pas une étude statistique ni une garantie de gain.

• GOV.UK — Governance principles for agile service delivery
• GOV.UK — How to set performance metrics for your service
• GOV.UK — Government Data Quality Framework, publié en 2020, repère complémentaire actuel

Liens vérifiés le 4 octobre 2026. Les scénarios et seuils proposés dans ce dossier sont pédagogiques ; ils ne décrivent pas une mission client ni un résultat obtenu par CYTIZEN.