Le livrable minimal avant d’automatiser un workflow tient sur une page. Cette page doit décrire le déclencheur, le résultat attendu, les états du dossier, les règles, les exceptions, les données, les responsabilités, les preuves et les mesures du processus. Elle n’a pas besoin d’être exhaustive. Elle doit être testable.
Le test est simple : donnez cette page à une personne qui connaît le métier, mais qui n’a pas participé à sa rédaction. Présentez-lui quelques dossiers réels, dont au moins un cas incomplet ou inhabituel. Si elle peut reproduire le traitement manuel, expliquer ses décisions et identifier les situations qui nécessitent une intervention, la documentation est probablement suffisante pour préparer un pilote. Si elle doit demander « et dans ce cas-là, on fait quoi ? » à chaque bifurcation, il reste du travail.
Cette approche évite deux excès : automatiser une pratique mal comprise ou rédiger un cahier des charges abstrait que personne ne peut confronter au terrain. Elle prolonge le travail de sélection présenté dans notre guide sur les tâches administratives à automatiser en priorité : une tâche intéressante sur le papier ne devient un bon pilote que lorsque son fonctionnement réel est assez clair pour être construit, observé et corrigé.
Une page de décision, pas la description idéale de l’entreprise
Documenter un workflow ne consiste pas à raconter toute l’organisation. Il faut délimiter une unité de travail observable : une demande de devis, une facture fournisseur, une création de compte client ou une relance d’impayé.
La page de décision répond à trois questions :
- Que doit faire le processus ? Son point de départ, son résultat et ses étapes.
- Comment décide-t-il ? Ses règles, ses exceptions et les données utilisées.
- Comment sait-on qu’il fonctionne ? Ses preuves, ses volumes et ses métriques.
Cette documentation doit décrire le service rendu dans son ensemble avant de détailler l’outil. Le GOV.UK Service Manual recommande précisément de comprendre le problème complet de l’utilisateur et de cartographier son parcours plutôt que de partir trop tôt d’une solution technique.[3][4][6] Pour une PME, cela signifie par exemple suivre une facture depuis sa réception jusqu’à son enregistrement ou son rejet, et non commencer par dessiner une connexion entre une boîte email et un logiciel comptable.
Le canevas complet à copier
Le canevas suivant peut être rempli dans un document partagé. Les réponses courtes, les tableaux et les listes sont préférables aux longs paragraphes.
Page de décision — [nom du workflow]
- Objectif métier : quel problème le workflow résout-il, pour qui et sans mentionner de solution technique ?
- Périmètre : quels dossiers sont inclus ? Lesquels sont explicitement exclus du pilote ?
- Déclencheur : quel événement observable démarre un dossier ? Quelle preuve permet de le dater ?
- Fin : quel résultat observable ferme le dossier ? Quels résultats alternatifs sont possibles : traité, rejeté, annulé ou transmis à un humain ?
- États : quels statuts successifs un dossier peut-il prendre ? Quels passages entre états sont autorisés ?
- Règles : quelles conditions déterminent l’action suivante ? Préciser les seuils, délais, priorités et critères de validation.
- Exceptions : quels cas ne suivent pas le chemin normal ? Pour chacun : détection, responsable, action et délai.
- Données : quelles informations sont nécessaires ? Où se trouve leur source ? Lesquelles sont obligatoires, sensibles ou modifiables ?
- Rôles : qui exécute, qui décide, qui valide, qui reçoit les alertes et qui reste responsable du pilote ?
- Preuves : quel email, statut, journal, document ou horodatage prouve le passage de chaque étape ?
- Volumes : combien de dossiers sont reçus par période ? Existe-t-il des pics ? Quelle part suit le chemin normal ?
- Mesures : quelle situation de référence observe-t-on aujourd’hui ? Quelles métriques décideront de poursuivre, corriger ou arrêter le pilote ?
- Limites du pilote : quelles actions restent manuelles ? Quels cas déclenchent un arrêt ou un retour vers un opérateur ?
- Questions ouvertes : quelles hypothèses doivent encore être vérifiées sur le terrain ?
Une question ouverte n’empêche pas nécessairement le pilote. Elle doit toutefois être visible, attribuée et associée à une manière de la vérifier. Une ambiguïté cachée est plus dangereuse qu’une limite assumée.
Exemple rempli : traiter une facture fournisseur reçue par email
Prenons une PME dans laquelle les factures arrivent sur une adresse partagée. Une assistante télécharge les pièces jointes, vérifie leur contenu, cherche le fournisseur et la commande, puis saisit les informations dans le logiciel comptable. Le pilote envisagé extrait les données, prépare l’enregistrement et soumet les cas admissibles à validation.
| Rubrique | Décision documentée |
|---|---|
| Objectif | Réduire la saisie répétitive tout en conservant la validation comptable avant enregistrement. |
| Périmètre | Factures PDF reçues sur factures@entreprise.fr, émises par un fournisseur déjà référencé et libellées en euros. Avoirs, factures papier, devis, doublons suspects et fournisseurs nouveaux exclus du premier pilote. |
| Déclencheur | Réception d’un email contenant au moins une pièce jointe PDF. L’identifiant et l’horodatage de l’email constituent la preuve d’entrée. |
| Fin | La facture est soit préparée puis validée dans le logiciel comptable, soit placée en « contrôle requis », soit rejetée comme document hors périmètre. Chaque fin possède un statut horodaté. |
| États | Reçue → à qualifier → à rapprocher → prête à valider → validée. Sorties latérales : contrôle requis, doublon suspect, rejetée. |
| Règles | Le fournisseur doit être identifié par son numéro de TVA ou son référentiel interne. Le numéro de facture, la date, les montants hors taxe, TVA et TTC doivent être présents. Les totaux doivent être cohérents. Une commande correspondante doit être trouvée lorsque la catégorie d’achat l’exige. |
| Exceptions | PDF illisible : contrôle manuel. Fournisseur inconnu : création hors automatisation. Plusieurs factures dans un PDF : contrôle manuel pendant le pilote. Doublon potentiel : blocage sans écriture. Écart avec la commande : transmission au responsable de l’achat. |
| Données | Email et pièce jointe comme sources d’entrée ; référentiel fournisseurs et commandes comme sources de contrôle ; logiciel comptable comme destination. Les coordonnées bancaires ne sont jamais modifiées automatiquement. |
| Rôles | L’assistante comptable contrôle les alertes et valide les propositions. Le responsable comptable décide des règles et porte le pilote. L’acheteur traite les écarts de commande. Le prestataire technique corrige l’automatisation, mais ne modifie pas seul les règles métier. |
| Preuves | Email original conservé, fichier identifié, valeurs extraites enregistrées, contrôles exécutés, décision humaine horodatée et journal des changements. |
| Volumes | À renseigner à partir de quatre semaines observées : nombre total, pics hebdomadaires, nombre de pièces par email, part des fournisseurs référencés et part des exceptions. |
| Mesures | Temps actif par facture, délai entre réception et validation, part des dossiers préparés sans correction, taux d’exceptions par type et nombre d’écritures incorrectes détectées avant ou après validation. |
| Limites | Aucune validation autonome, aucun paiement, aucune modification de coordonnées bancaires et aucun traitement silencieux d’un échec. |
Les volumes et les seuils ne sont pas inventés pendant l’atelier. Ils sont mesurés sur l’activité de l’entreprise. Si personne ne connaît le taux de factures hors périmètre, il faut échantillonner les dossiers récents avant de fixer l’ambition du pilote.
Les éléments à ne pas laisser implicites
Le déclencheur et la fin
« Quand une facture arrive » reste ambigu : arrive-t-elle par email, courrier, dépôt dans un portail ou transfert d’un salarié ? Un déclencheur exploitable correspond à un événement détectable et datable. De même, « facture traitée » ne suffit pas. Est-elle extraite, saisie, validée ou payée ?
La fin doit être associée à une preuve. Sans elle, l’automatisation peut exécuter une action sans permettre de vérifier que le résultat métier a été obtenu.
Les états et leurs transitions
Un état décrit la situation du dossier, pas l’action de l’outil. « En attente de validation » est un état ; « envoyer un email » est une action. Pour chaque état, précisez les entrées possibles, le responsable, le délai attendu et les sorties autorisées.
Cette distinction révèle les dossiers bloqués. Elle empêche aussi qu’une relance, un redémarrage ou une erreur technique crée une seconde facture, un second message ou une transition incohérente.
Les règles et les exceptions
Une règle doit pouvoir être appliquée de manière stable à un cas concret. Remplacez « montant important » par un seuil décidé par le responsable métier. Remplacez « fournisseur habituel » par une présence dans un référentiel nommé.
Une exception n’est pas seulement un message d’erreur. Elle doit avoir une destination opérationnelle : qui reçoit le dossier, avec quelles informations, pour prendre quelle décision ? Les exceptions oubliées font partie des erreurs qui rendent une automatisation fragile. Le chemin de reprise mérite autant d’attention que le chemin idéal.
Les données et leurs sources
Pour chaque donnée, notez son nom métier, sa source de référence, son format, son caractère obligatoire et les personnes autorisées à la modifier. Deux colonnes portant le même nom dans deux outils ne constituent pas nécessairement la même donnée.
Il faut également distinguer une donnée absente, une donnée invalide et une donnée contradictoire. Ces situations peuvent produire trois décisions différentes : demander un complément, corriger une forme ou soumettre un conflit à un responsable.
Les rôles et les preuves
Le pilote doit conserver un responsable métier. Celui-ci décide du périmètre, valide les règles, accepte les risques résiduels et tranche à la fin de l’essai. L’équipe technique construit et observe le système ; elle ne remplace pas la responsabilité opérationnelle.
Les preuves rendent le workflow vérifiable : identifiant du dossier, valeur avant et après traitement, règle appliquée, décision humaine, date, erreur et reprise. Elles servent au contrôle quotidien comme à l’analyse du pilote.
Les volumes et les métriques
Le volume total ne suffit pas. Il faut observer sa variabilité, les pics, la proportion de dossiers simples et la fréquence de chaque exception. Un workflow de faible volume peut rester pertinent si son risque ou son délai est élevé ; un gros volume peut être un mauvais pilote si la majorité des dossiers dépend d’un jugement non stabilisé.
Les métriques doivent comparer le pilote à une référence mesurée avec la même définition. Le GOV.UK Service Standard demande notamment de comprendre les besoins, de traiter le problème dans son ensemble et de définir ce que signifie la réussite du service.[5] Pour un pilote PME, un tableau de bord sobre suffit généralement : délai de traitement, temps actif, taux de dossiers sans correction, taux d’exceptions et erreurs par niveau de gravité.
Tableau d’états ou BPMN : choisir le niveau utile
Un tableau d’états suffit lorsque le processus possède un début clair, peu de bifurcations, des rôles faciles à distinguer et des exceptions qui reviennent vers une file de contrôle unique. Il tient dans une page et se valide facilement avec des dossiers réels.
| État | Condition d’entrée | Responsable | Sorties autorisées | Preuve |
|---|---|---|---|---|
| À qualifier | Document reçu | Automatisation | À rapprocher, contrôle requis, rejeté | Résultat de qualification |
| À rapprocher | Facture reconnue | Automatisation | Prête à valider, contrôle requis | Référence fournisseur et commande |
| Prête à valider | Contrôles réussis | Comptabilité | Validée, contrôle requis | Décision horodatée |
Ajoutez un diagramme BPMN lorsque le tableau masque la réalité : plusieurs équipes agissent en parallèle, des messages circulent entre organisations, des délais déclenchent des chemins distincts, le dossier revient plusieurs fois en arrière ou de nombreuses décisions se combinent.
BPMN est une notation graphique standardisée par l’Object Management Group. Elle fournit une syntaxe définie pour représenter notamment les événements, les activités, les décisions et les flux d’un processus.[1][2] Cette notation peut créer un langage commun entre les personnes du métier et les équipes techniques, à condition de n’utiliser que les éléments nécessaires.
Pour un premier schéma, limitez-vous souvent à un événement de début, un événement de fin, des tâches, quelques décisions, des flux et un couloir par rôle. N’ajoutez pas BPMN pour donner une apparence formelle à un processus encore incertain. Le diagramme doit résoudre une ambiguïté que la page et le tableau ne résolvent plus ; il n’est pas un préalable universel.
Organiser un atelier de documentation
Réunissez au minimum la personne qui exécute régulièrement le travail et le responsable métier capable de décider. Ajoutez un représentant technique pour poser des questions sur les données, les interfaces et les preuves, sans laisser la discussion dériver immédiatement vers le choix d’un outil.
Un atelier de deux temps fonctionne bien :
- Cartographier le cas normal. Partez d’un dossier récemment terminé. Identifiez son déclencheur, chaque état et la preuve de fin.
- Attaquer la carte avec des exceptions. Rejouez un dossier incomplet, un doublon, un retard, une donnée contradictoire et une panne de l’outil de destination.
À chaque étape, demandez : « Comment le savez-vous ? », « Où regardez-vous ? », « Qui peut décider ? » et « Que faites-vous si cette information manque ? ». Ces questions font apparaître les pratiques implicites, comme la vérification d’un ancien email ou l’appel à une personne expérimentée.
Terminez l’atelier avec une version datée de la page, un propriétaire pour chaque question ouverte et une liste de dossiers à rejouer. Ne cherchez pas à résoudre toutes les variantes historiques de l’entreprise.
Valider la page sur le terrain
Une revue en salle ne suffit pas. Sélectionnez un petit échantillon représentatif de dossiers récents : cas normal, donnée absente, doublon, seuil dépassé, correction et cas hors périmètre. Masquez si nécessaire la décision finale, puis demandez à un opérateur de les traiter uniquement à partir de la page.
Consignez chaque hésitation :
- règle absente ou interprétée différemment ;
- donnée introuvable ou source contestée ;
- état sans sortie claire ;
- exception sans responsable ;
- preuve insuffisante pour confirmer le résultat.
Corrigez ensuite la page et rejouez les cas concernés. Cette validation ne prouve pas que toutes les situations futures sont couvertes. Elle montre que la description résiste à un ensemble crédible de situations réelles et que les cas inconnus disposent d’un chemin sûr vers un humain.
Les critères pour lancer le pilote
Le pilote peut commencer lorsque les conditions suivantes sont réunies :
- le responsable métier approuve le périmètre, les règles et les exclusions ;
- le déclencheur et les résultats de fin sont détectables ;
- les états et les transitions autorisées sont compris ;
- les données nécessaires ont une source identifiée ;
- les exceptions connues ont une file, un responsable et une action ;
- un échantillon de cas réels a été rejoué avec la page ;
- les actions irréversibles ou sensibles restent protégées par une validation adaptée ;
- la situation de référence et les métriques du pilote sont définies ;
- les journaux permettent de reconstruire ce qui s’est passé ;
- une procédure d’arrêt et de reprise manuelle existe.
Le bon périmètre n’est pas celui qui automatise tout. C’est celui qui permet d’apprendre sans rendre une erreur silencieuse ou difficile à corriger. Les dossiers hors périmètre doivent être orientés proprement, pas forcés dans le chemin normal.
Checklist finale de la page de décision
- □ Le déclencheur correspond à un événement unique, observable et datable.
- □ Chaque fin produit un résultat et une preuve explicites.
- □ Les états décrivent la situation du dossier.
- □ Les transitions autorisées sont connues.
- □ Les règles utilisent des critères vérifiables.
- □ Les exceptions prioritaires ont été rejouées.
- □ Chaque exception possède un responsable et une sortie.
- □ Les données obligatoires et leurs sources sont identifiées.
- □ Les droits de modification des données sensibles sont définis.
- □ Un responsable métier porte le pilote.
- □ Les décisions et les changements laissent des preuves.
- □ Les volumes et les pics reposent sur une observation réelle.
- □ Une référence avant pilote est disponible.
- □ Les métriques de qualité, de délai et d’exception sont définies.
- □ Les exclusions, l’arrêt et la reprise manuelle sont prévus.
- □ Une autre personne peut traiter les cas tests avec cette seule page.
Une documentation suffisante est une documentation que l’on peut éprouver
Avant un pilote, l’objectif n’est ni la documentation parfaite ni le diagramme le plus impressionnant. Il s’agit de rendre les décisions visibles : ce qui démarre le travail, ce qui constitue un résultat, comment le dossier change d’état, quelles règles s’appliquent, où vont les exceptions et comment vérifier le traitement.
Commencez par une page et un tableau d’états. Testez-les avec des dossiers réels. Ajoutez BPMN si les interactions, les parallélismes ou les retours rendent le flux difficile à comprendre. Cette progression conserve le principe essentiel du design de service : comprendre d’abord le problème et le parcours complet, puis choisir le niveau de représentation et la technique nécessaires.[3][6]
Une page imparfaite mais rejouable est plus utile qu’un cahier des charges abstrait. Elle donne au responsable métier, aux opérations et à l’équipe technique une base commune pour construire un pilote limité, mesurable et corrigeable.