Un bon processus vaut mieux qu'un bon développeur
Les fondamentaux pour concevoir des processus métier clairs, reproductibles et maintenables. De la documentation à l'exécution.
Un processus, c'est une promesse : si tu suis ces étapes, tu obtiens ce résultat. Mais dans la plupart des boîtes, les processus sont soit inexistants, soit oubliés dans un Google Doc que personne ne lit. Sam Carpenter, dans Work the System, le résume bien : ton entreprise est un ensemble de systèmes, et la qualité de ces systèmes détermine la qualité de tes résultats. Il l'explique aussi dans son talk TEDx. Le vrai enjeu n'est pas de documenter : c'est de concevoir quelque chose qui vit et reste pertinent.
Qu'est-ce qu'un bon processus ?
Un bon processus a trois propriétés :
- Clair - n'importe qui peut le lire et comprendre quoi faire, dans quel ordre, et pourquoi.
- Reproductible - le résultat est le même que ce soit toi, un collègue, ou un prestataire qui l'exécute.
- Maintenable - il évolue avec ton activité au lieu de devenir un document fossile.
Si ton processus ne coche pas ces trois cases, ce n'est pas un processus. C'est une note personnelle.
Avant de formaliser, pose-toi la question de fond : est-ce que ce processus devrait exister ? Comme l'écrit Michaël Hammer dans la HBR, il ne faut pas automatiser un processus, il faut le repenser. Un mauvais processus bien documenté reste un mauvais processus. Commence par vérifier que chaque étape crée de la valeur pour le client final.
L'anatomie d'un processus
Un processus bien construit a une fiche d'identité qui permet de le retrouver et de savoir s'il est fiable, sans le lire en entier.
Les métadonnées obligatoires
| Métadonnée | Contrainte | Pourquoi |
|---|---|---|
| Nom court | 5-10 mots max | Pour identifier le processus en un coup d'oeil. |
| Description | ~155 caractères | Un résumé qui tient dans un tableau de bord. |
| Catégorie | commercial, opérationnel, administratif, support, interné | Pour regrouper et filtrer. |
| Date de péremption | Calculée depuis la fréquence de revue | Le signal d'alerte. |
| RACI | Au moins un R et un A par étape | Sans RACI, personne ne sait qui fait quoi. |
La règle des 500 lignes
Le corps d'un processus ne doit pas dépasser 500 lignes. Au-delà, personne ne lit. Si ton processus dépasse cette limite, il fait probablement deux choses au lieu d'une.
Que faire si c'est trop long ?
- Découper - Identifier les sous-processus autonomes et les extraire.
- Simplifier - Retirer les détails d'implémentation. Un processus décrit le QUOI, pas le COMMENT.
- Référencer - Pointer vers des documents externes (checklist, template, guide technique).
Le RACI : savoir qui fait quoi
La première erreur quand on conçoit un processus, c'est de décrire les étapes sans dire qui est concerné. Le RACI résout ce problème :
- R - Responsible : celui qui fait le travail.
- A - Accountable : celui qui valide et porte la responsabilité finale. Un seul par étape.
- C - Consulted : ceux qu'on consulte avant ou pendant.
- I - Informed : ceux qu'on prévient une fois que c'est fait.
| Étape | R (Exécute) | A (Valide) | C (Consulté) | I (Informé) |
|---|---|---|---|---|
| Envoi du contrat | Commercial | Dirigeant | Juridique | Comptabilité |
| Setup technique | Développeur | CTO | Client | Commercial |
| Formation | Formateur | Chef de projet | Client | Support |
Les règles du RACI
- Un seul A par étape. Si tout le monde est accountable, personne ne l'est.
- Au moins un R par étape. Pas de tâche orpheline.
- Pas trop de C. Consulter 8 personnes à chaque étape, c'est paralyser le processus.
- I ne bloque pas. Informer n'est pas demander un avis.
Le RACI a ses limites. McKinsey le souligne : quand les décisions impliquent plusieurs parties prenantes aux intérêts divergents, une matrice ne suffit pas. Complète-le avec un critère d'escalade : qui tranche en cas de conflit, et dans quel délai ?
Les dates de revue
Un processus jamais relu devient dangereux : il décrit une réalité qui n'existe plus. La solution : chaque processus a une date de prochaine revue.
| Type de processus | Fréquence de revue |
|---|---|
| Commercial (venté, onboarding) | Tous les 30 jours |
| Opérationnel (livraison, support) | Tous les 60 jours |
| Administratif (facturation, RH) | Tous les 90 jours |
Quand la date arrive, le responsable relit, met à jour, et repousse la prochaine revue. Sans ce cycle, les processus pourrissent en silence.
Le cycle PDSA
Un bon processus s'améliore par itérations. Le cycle PDSA (Plan-Do-Study-Act) donne le cadre :
- Plan - Identifie un problème ou une amélioration possible.
- Do - Teste le changement à petite échelle (un client, une exécution).
- Study - Mesure les résultats. L'effet attendu est-il là ?
- Act - Si oui, intègre le changement. Si non, reviens en arrière.
L'erreur classique : modifier trois étapes d'un coup et ne plus savoir quel changement a produit quel effet. Un changement à la fois, une mesure à chaque fois.
Les erreurs classiques
Trop de détail. Un processus n'est pas un mode d'emploi. Reste au niveau de l'action métier. Pas de responsable. "L'équipe s'en occupe" signifie que personne ne s'en occupe. Pas de revue. Écrit en janvier, jamais relu : c'est un piège. Automatiser un processus cassé. Si ça ne marche pas en manuel, l'automatisation ne féra que produire des erreurs plus vite. Corrigé d'abord. Et si tu doutes encore de l'intérêt de formaliser, lis pourquoi documenter ses processus est le prérequis de tout le reste.
Une fois ton processus en place, la question suivante sera : peut-on y intégrer de l'IA ? Et le choix des outils compte : comment bien choisir ses outils.
En résumé
- Identifier clairement - nom court, description en 155 caractères, catégorie, date de péremption.
- Décrire les étapes avec un critère de sortie clair, et rester sous 500 lignes.
- Attribuer les rôles avec un RACI - pas de flou sur qui fait quoi.
- Planifier la maintenance avec des dates de revue - un processus périmé est pire que pas de processus.
Chez PluginFactory, j'ai documenté chaque processus client : de l'audit initial à la livraison du plugin. Le jour où j'ai voulu déléguer une partie de la formation, tout était écrit. Résultat : zéro perte de qualité, et un temps d'onboarding divisé par deux.
Le meilleur processus n'est pas le plus détaillé. C'est celui que les gens suivent vraiment.
PluginFactory
Guide
