Nos ateliers de cadrage : le déroulé, heure par heure
Alban
Product manager & product owner
En bref
Comment se déroule un atelier de cadrage de projet applicatif ?
Sur deux à quatre semaines, en quatre ateliers de deux à trois heures : cartographier le processus actuel tel qu'il se passe réellement, identifier les irritants et les chiffrer, arbitrer le périmètre de la première version, puis valider les critères de succès et les risques. Les participants doivent inclure ceux qui font le travail, pas seulement ceux qui le dirigent — c'est la condition qui détermine la qualité du résultat.
Le cadrage est la phase la plus rentable d’un projet et celle qu’on cherche toujours à raccourcir. Comme elle ne produit pas de logiciel, elle ressemble à du temps perdu.
Voici précisément ce que nous y faisons, pour qu’on puisse en juger sur pièces.
Qui doit être là
C’est la décision la plus déterminante, prise avant le premier atelier.
Ceux qui font le travail. Pas seulement leurs responsables. Le gestionnaire qui saisit quarante dossiers par jour sait des choses que personne d’autre ne sait — notamment tous les contournements qui font tenir le processus actuel.
Un décideur. Quelqu’un qui peut trancher un arbitrage de périmètre dans la salle. Sans lui, chaque question ouverte devient un délai d’une semaine, et le cadrage s’étire sans fin.
Quelqu’un du support ou de l’informatique interne. Il connaît les systèmes existants, les contraintes techniques et les projets voisins qui pourraient entrer en collision.
Six à huit personnes maximum. Au-delà, la parole se répartit mal et les plus discrets — souvent les mieux informés — se taisent.
Atelier 1 — Le processus réel
Deux à trois heures. On dessine ensemble le parcours actuel, étape par étape, sur un mur ou un tableau partagé.
La consigne que je répète : on décrit ce qui se passe, pas ce qui devrait se passer. La procédure officielle nous intéresse moins que la réalité, y compris le tableur parallèle que tout le monde utilise et le message envoyé à un collègue pour débloquer un dossier.
C’est presque toujours l’atelier le plus révélateur. Il est fréquent que deux services découvrent à ce moment-là comment travaille l’autre, et qu’une double saisie évitable apparaisse au grand jour.
Atelier 2 — Les irritants, et leur coût
On reprend le parcours et on marque chaque point de friction : ce qui prend du temps, ce qui génère des erreurs, ce qui oblige à ressaisir, ce qui provoque des appels clients.
Puis on chiffre, même grossièrement. Combien de fois par semaine ? Combien de minutes ? Combien de personnes concernées ?
Ce chiffrage change la nature de la discussion. Un irritant qui coûte trois heures par semaine à cinq personnes n’est pas dans la même catégorie qu’un désagrément mensuel — et à l’œil nu, les deux se ressemblent.
C’est aussi ce qui permettra, plus tard, de prioriser sans arbitraire.
Photo : rawpixel — licence CC0.
Atelier 3 — L’arbitrage du périmètre
Le plus inconfortable, et le plus utile.
On classe tout ce qui a été identifié en trois colonnes : indispensable à la première mise en production, souhaitable ensuite, hors périmètre.
Deux règles que j’annonce en ouverture.
La colonne « indispensable » a une taille limitée. Je donne une contrainte de capacité — « environ huit semaines de développement » — et on remplit dans cette limite. Sans contrainte, tout devient indispensable.
Rien ne disparaît. La troisième colonne reste écrite et visible. Ce qui n’est pas fait maintenant n’est pas oublié ; il est daté. C’est ce qui rend l’arbitrage acceptable.
Photo : domaine public (CC0).
Atelier 4 — Succès et risques
On écrit ce qui devra être vrai pour dire que ça a marché. En chiffres quand c’est possible : « le temps de traitement d’un dossier passe de 12 à 4 minutes », « plus aucune ressaisie entre les deux outils ».
Puis on liste les risques, sans langue de bois : la reprise de données incertaine, la disponibilité des utilisateurs pour la recette, une dépendance à un système que personne ne maîtrise, une échéance réglementaire.
Pour chacun : qui s’en occupe, et à quelle date on saura. Un risque sans porteur n’est pas traité, il est constaté.
Ce qui sort du cadrage
Un document d’une quinzaine de pages : le processus cible, le périmètre arbitré, les critères de succès, les risques, et un chiffrage par lot.
Ce document appartient au client. S’il choisit un autre prestataire pour la réalisation, il repart avec — et il pourra faire chiffrer ailleurs sur une base sérieuse. C’est une condition de notre proposition, et elle nous coûte parfois l’affaire.
Photo : domaine public (CC0).
Ce que je prépare avant le premier atelier
Un atelier réussi se joue en partie avant qu’il commence.
Je regarde l’outil actuel. Une heure passée dans l’application existante, ou même dans le tableur qui en tient lieu, vaut mieux qu’une heure de questions. J’arrive avec des observations plutôt qu’avec un questionnaire vierge.
Je demande trois documents. Un exemple de chaque document produit par le processus — devis, bon de commande, rapport. Ils contiennent les vraies règles de gestion, y compris celles que personne ne pense à mentionner.
Je préviens de ce qui sera inconfortable. J’annonce dès l’invitation que le troisième atelier consistera à renoncer à des choses. Les gens arrivent préparés, et l’arbitrage se passe beaucoup mieux que lorsqu’il tombe par surprise.
Le cadrage ne remplace pas la découverte
Un point d’honnêteté : le cadrage ne supprime pas l’incertitude, il la réduit.
Il reste des choses qu’on ne saura qu’en construisant, et d’autres qu’on ne saura qu’en mettant entre les mains des utilisateurs. C’est pour cela que le cadrage produit une trajectoire par lots, pas un plan figé à six mois.
Je le dis toujours en restitution, parce que la promesse inverse est tentante et malhonnête. Un cadrage qui prétend éliminer toute surprise se trompe, ou ment. Ce qu’il apporte réellement : des surprises moins nombreuses, plus tôt, et moins chères.
Ce que je fais quand un participant monopolise
Cela arrive dans un atelier sur deux, et le laisser s’installer fausse tout le cadrage.
La personne connaît le sujet et parle beaucoup ; les autres se taisent. À l’arrivée, le processus décrit est celui d’une seule personne, présenté comme celui de l’équipe.
Deux techniques suffisent. Faire écrire avant de faire parler : cinq minutes où chacun note sa réponse, puis un tour de table. Personne ne peut être devancé. Et interroger nommément les silencieux, sur un point précis plutôt que par une question ouverte : « Sur cette étape-là, tu fais comment de ton côté ? »
Les écarts qui apparaissent alors sont précieux. Deux personnes censées suivre le même processus le décrivent différemment, et cet écart est presque toujours l’endroit où se trouve le vrai problème.
Les trois moments où ça déraille
Quand il manque les opérationnels. Le cadrage produit alors le processus tel que la direction l’imagine. L’écart se découvre en recette, et il est douloureux.
Quand personne ne peut trancher. Chaque arbitrage part en validation, le cadrage s’étale sur deux mois, et l’élan retombe.
Quand on cadre en pensant à la solution. Si les participants arrivent avec des écrans en tête, ils décrivent une application au lieu de décrire un problème. Je consacre les deux premiers ateliers à l’existant, sans jamais parler de la future application — c’est frustrant, et c’est ce qui garantit qu’on résoudra le bon problème.