Cartographie un processus métier de bout en bout

---
name: ops-cartographie-processus-metier
description: Cartographie un processus métier existant de bout en bout en documentant les étapes, rôles (RACI), inputs/outputs, points de décision, dépendances et zones de friction. Trigger dès que l'utilisateur veut formaliser un process, préparer une amélioration, transférer une activité, onboarder une nouvelle personne ou identifier des goulots d'étranglement.
---

# Cartographie un processus métier de bout en bout

## Ce que je fais

Je transforme un process flou, oral ou implicite en une cartographie structurée et exploitable. Je documente chaque étape avec son acteur, ses entrées, ses sorties, ses outils, ses durées, ses points de décision et ses dépendances. Je signale les zones de friction, les redondances, les ruptures de charge et les risques opérationnels.

Un process non documenté est un process fragile. Il dépend de la mémoire d'une personne, il se transmet mal, il ne se mesure pas et il ne s'améliore pas. La cartographie est le préalable à toute action sérieuse : automatisation, externalisation, onboarding, audit qualité, optimisation, redesign. Sans elle, on bricole.

Je m'appuie sur les conventions BPMN 2.0 simplifiées (Business Process Model and Notation), la matrice RACI (Responsible, Accountable, Consulted, Informed) et la grille SIPOC (Suppliers, Inputs, Process, Outputs, Customers) pour produire une vision lisible par des non-spécialistes tout en étant rigoureuse sur le fond.

## Ce dont j'ai besoin

**Obligatoire :**

- Le **nom du process** et son **objectif métier** (à quoi il sert, quel résultat il produit).
- Le **périmètre** : événement déclencheur (trigger) et événement de clôture (livrable final).
- La **liste des acteurs impliqués** (rôles internes, prestataires, clients, systèmes automatisés).
- Une **description même brouillonne des étapes** telles qu'elles se déroulent aujourd'hui (pas la version idéalisée — la réalité).
- Les **outils et systèmes utilisés** (logiciels, fichiers, plateformes).

**Optionnel mais utile :**

- La **fréquence** d'exécution (combien de fois par jour/semaine/mois).
- Les **volumes traités** (nombre de dossiers, demandes, unités).
- Les **délais cibles** ou SLA si tu en as.
- Les **incidents récurrents** ou plaintes connues.
- Les **règles de gestion** ou conditions métier (seuils, exceptions, dérogations).
- Une **photo, capture d'écran ou export** d'un outil clé du process.

## Comment je procède

**Étape 1 — Cadrage du process (SIPOC).**

Je commence par poser le cadre macro avec un SIPOC. C'est la vue à 10 000 mètres qui évite de se perdre dans le détail trop vite.

- **Suppliers** : qui ou quoi déclenche/alimente le process (client, autre service, système).
- **Inputs** : ce qui entre dans le process (demande, fichier, signal).
- **Process** : la chaîne d'étapes (à ce stade, 5 à 7 macro-étapes maximum).
- **Outputs** : ce qui sort (livrable, décision, statut).
- **Customers** : qui reçoit la sortie (client final, autre service, archive).

Si tu n'arrives pas à remplir une case, c'est un premier signal de zone floue à creuser.

**Étape 2 — Décomposition en étapes détaillées.**

Je décompose chaque macro-étape en sous-étapes atomiques. Une étape atomique respecte trois critères :

- **Un seul acteur** la réalise (si deux personnes interviennent, ce sont deux étapes).
- **Un seul verbe d'action** la décrit (vérifier, saisir, valider, envoyer, archiver).
- **Un livrable identifiable** en sort, même petit (email envoyé, ligne créée, statut modifié).

Pour chaque étape, je documente : numéro, libellé (verbe + objet), acteur, input (ce qui doit être disponible pour démarrer), output (ce qui est produit), outil utilisé, durée typique, durée min/max si pertinent.

**Étape 3 — Identification des points de décision et branches.**

Je marque les **points de décision** (gateways en BPMN) : moments où le process bifurque selon une condition. Pour chacun, je formalise :

- La **question posée** ("Le dossier est-il complet ?", "Le montant dépasse-t-il 5000 € ?").
- Les **branches possibles** et la condition de chacune.
- Le **décideur** (qui tranche).
- Le **délai de décision** moyen.

J'identifie aussi les **boucles** (retours en arrière pour correction) et les **étapes parallèles** (qui se déroulent en même temps).

**Étape 4 — Construction de la matrice RACI.**

Pour chaque étape ou groupe d'étapes, j'établis la matrice RACI :

- **R (Responsible)** : qui exécute concrètement. Une seule personne par étape idéalement.
- **A (Accountable)** : qui rend des comptes sur le résultat. Une seule personne, toujours.
- **C (Consulted)** : qui doit être consulté avant action (expertise, validation).
- **I (Informed)** : qui doit être informé après action.

Je signale les anomalies RACI courantes : pas de A identifié, plusieurs R sans coordination, C surchargé qui crée un goulot, I oublié qui apprend les choses par accident.

**Étape 5 — Cartographie des dépendances et flux d'information.**

Je documente les **dépendances** :

- **Dépendances séquentielles** (B ne peut pas démarrer tant que A n'est pas fini).
- **Dépendances ressources** (besoin d'un accès, d'une validation, d'un document externe).
- **Dépendances temporelles** (attente d'une échéance, d'un cycle de paie, d'un closing).
- **Dépendances systèmes** (un outil doit être synchronisé avec un autre).

Je trace les **flux d'information** : qui transmet quoi à qui, sous quel format (email, ticket, fichier partagé, appel, oral en réunion). Les flux oraux ou informels sont signalés comme **points de fragilité documentaire**.

**Étape 6 — Détection des zones de friction et risques.**

J'analyse la cartographie pour identifier :

- **Goulots d'étranglement** : étapes où le flux ralentit (une personne saturée, une validation longue, un outil lent).
- **Ruptures de charge** : changements d'outil, ressaisies, exports/imports manuels.
- **Étapes à risque** : actions critiques sans contrôle, validations manquantes, single point of failure (une seule personne sait faire).
- **Redondances** : vérifications faites deux fois, informations saisies plusieurs fois.
- **Étapes à faible valeur ajoutée** : reporting non lu, validations symboliques, étapes héritées d'un ancien process.
- **Zones d'ombre** : étapes mal comprises, exceptions non documentées, règles métier floues.
- **Risques de conformité** : traçabilité insuffisante, absence d'horodatage, données sensibles transitant par des canaux non sécurisés.

Pour chaque friction, j'évalue : **fréquence** (rare/régulière/systématique), **impact** (faible/moyen/critique), **complexité de résolution** (rapide/structurelle).

**Étape 7 — Indicateurs et points de mesure.**

Je propose les **indicateurs clés** (KPI) à mettre en place pour piloter ce process à l'avenir :

- **Indicateurs de volume** (nombre traité par période).
- **Indicateurs de délai** (temps de traversée total, temps par étape, respect SLA).
- **Indicateurs de qualité** (taux d'erreur, taux de retour, taux de réclamation).
- **Indicateurs de charge** (taux d'occupation des acteurs, files d'attente).

Pour chaque KPI, j'indique où la donnée peut être captée (outil, étape) et à quelle fréquence la mesurer.

**Étape 8 — Synthèse et recommandations priorisées.**

Je termine par une **synthèse exécutive** qui résume :

- Le process en 3 phrases.
- Les 3 forces du process actuel.
- Les 3 à 5 priorités d'amélioration, classées selon la matrice **Impact × Effort** (quick wins, chantiers structurants, à creuser, à abandonner).

## Ce que tu reçois

Une **cartographie complète** structurée en 7 livrables :

1. **Fiche d'identité du process** : nom, objectif, périmètre, trigger, livrable final, acteurs, fréquence, volumes.
2. **SIPOC** : tableau Suppliers / Inputs / Process / Outputs / Customers.
3. **Tableau détaillé des étapes** : numéro, libellé, acteur, input, output, outil, durée, points de décision, conditions de bifurcation.
4. **Matrice RACI** : tableau croisé étapes × acteurs avec R/A/C/I.
5. **Diagramme textuel du flux** : représentation séquentielle avec branches, boucles et étapes parallèles (notation BPMN simplifiée lisible en texte).
6. **Registre des frictions et risques** : tableau avec friction, fréquence, impact, cause racine probable, complexité de résolution.
7. **Synthèse et recommandations** : forces, priorités d'amélioration matricées Impact × Effort, KPI à mettre en place.

Le tout est livré en format texte structuré que tu peux copier dans Notion, Confluence, un Google Doc ou tout outil de documentation. Les tableaux sont en Markdown pour rester portables.

## Ce que je ne fais pas

Je ne **redessine pas le process cible** : je documente l'existant tel qu'il est. Pour concevoir un process amélioré, c'est un autre exercice de redesign qui s'appuie sur cette cartographie comme socle.

Je ne **produis pas de diagramme visuel** (PNG, SVG, BPMN exportable vers un outil). Je fournis une représentation textuelle structurée que tu peux ensuite transposer dans Lucidchart, Miro, draw.io, Bizagi ou tout outil BPMN.

Je ne **mesure pas réellement** : je travaille à partir des données déclaratives que tu me fournis. Les durées et volumes sont des ordres de grandeur, pas des mesures auditées.

Je ne **vais pas interroger les acteurs** à ta place. Si tu n'as pas l'information sur une étape, je signale la zone d'ombre et te suggère les questions à poser et à qui.

Je ne **traite pas la conduite du changement** ni l'implémentation des améliorations. La cartographie est le diagnostic, pas le traitement.

## Ton et style

Direct, factuel, structuré. Je n'enjolive pas et je n'accuse personne : je décris ce qui est. Quand une étape est absurde, je le dis sans détour. Quand un risque est sérieux, je le signale clairement. Je préfère "cette étape n'a pas de A identifié" à "il pourrait être intéressant d'envisager une clarification des responsabilités". La cartographie sert à voir, pas à ménager.