Un cadrage projet digital raté ne se voit pas le premier jour. Le projet démarre, tout le monde hoche la tête, et il faut parfois attendre la première démonstration pour découvrir que le marketing et la technique n'avaient pas le même projet en tête. Si vous lancez un site, une intégration ou une application et que chacun le décrit à sa façon, c'est là que je mettrais la première semaine.
Mes missions commencent par quelques jours de diagnostic, avant de construire quoi que ce soit. Je vous donne ici une façon de découper ce temps sur cinq jours, le modèle de note de cadrage qui en sort, et les cas où une semaine ne suffit pas. Le découpage est un cadre de travail, pas un rituel : sur votre projet, le mardi débordera peut-être sur le mercredi.
01Ce qu'un cadrage doit produire : une décision
On imagine souvent qu'un cadrage produit un document. Je préfère qu'il produise une décision : on continue, on réduit, ou on s'arrête. La chaîne de Nielsen Norman Group conseille de formuler l'objectif d'une phase de découverte comme un point de décision, c'est-à-dire ce sur quoi l'équipe veut pouvoir s'accorder à la fin. Je trouve cette formulation très utile, parce qu'elle donne une date de fin au travail.
L'arrêt fait partie des réponses possibles. Le manuel de service du gouvernement britannique le dit sans détour : s'arrêter à la fin de cette phase n'est pas un échec quand la recherche montre que c'est le mieux à faire. J'ai écrit la même règle dans mes machines de contenu : un article qui ne peut pas passer honnêtement est abandonné avec une note, plutôt que forcé. La pression de finir pousse à inventer. Sur un projet, elle pousse à démarrer quand même.
Pour décider, il faut cinq choses sur la table à la fin de la semaine :
- le problème, en une phrase ;
- le périmètre, avec ce qui est exclu ;
- les contraintes, séparées entre celles qu'on subit et celles qu'on peut changer ;
- les inconnues qui restent, et qui les lèvera ;
- le nom de celui qui décide quoi.
Nielsen Norman Group ajoute que cette phase n'a pas pour but de produire des livrables pour eux-mêmes. Si un schéma n'aide pas à décider, je ne le fais pas.
02Une semaine, alors que GOV.UK parle de quatre à huit
GOV.UK indique qu'une discovery dure typiquement de 4 à 8 semaines, en précisant qu'il n'y a pas de durée fixe, qu'il faut parfois plus de temps sur un problème que personne n'a étudié et un peu moins sur un problème déjà bien connu. Ce cadre vise des services publics, avec une recherche utilisateur qui part souvent de loin.
La semaine dont je parle correspond à l'autre bout de cette échelle : une entreprise qui connaît ses clients, un projet de taille raisonnable, des décideurs disponibles. Elle ne remplace pas une recherche. Elle sert à mettre noir sur blanc ce que l'entreprise sait déjà, à repérer ce qu'elle ne sait pas, et à trancher.
La date courte a aussi un effet que j'ai appris bien avant le digital, en production audiovisuelle : quand la date ne bouge pas, on arrête de discuter de tout et on choisit. C'est ce que je cherche ici.
03Le déroulé, jour par jour
Lundi : passer de la solution demandée au problème
Le kick-off du projet web se fait ce jour-là, et il commence rarement par un problème. On vous demande une carte, une application, un nouveau site. GOV.UK donne un bon exemple : « il nous faut une carte interactive de nos centres de contact » n'est pas un problème. Le problème, c'est de savoir comment aider les gens à trouver le centre le plus proche quand ils ont besoin d'un rendez-vous en personne.
Pour cet atelier, je reprendrais les cinq étapes que propose la vidéo de Nielsen Norman Group sur les ateliers de lancement : les rôles de chacun, l'énoncé du problème, l'objectif formulé comme une décision, les inconnues classées par risque, et un plan avec un responsable et une durée bornée pour chaque action. Une demi-journée me paraît suffire pour une première version.
Mardi : écouter ceux qui vivront avec le résultat
Des entretiens courts, une personne à la fois : le commanditaire, ceux qui feront le travail au quotidien, ceux qui parlent aux clients, ceux qui tiennent la technique. Posez à chacun les mêmes questions : l'intérêt est dans les écarts entre les réponses.
Nielsen Norman Group recommande une équipe restreinte, de 3 à 7 personnes, avec un responsable assez influent pour obtenir l'accès aux gens et aux données. Sur une semaine, je vérifierais ce point dès le lundi : si personne ne peut ouvrir les portes, le mardi est perdu.
Mercredi : lister les contraintes et les trier
Lois, contrats, ancienne technique, processus existants : ce sont les catégories de GOV.UK, qui distingue les contraintes dures, qu'on ne changera pas, des contraintes souples, qu'on doit travailler à changer. Le tri compte plus que la liste. Une contrainte souple prise pour une contrainte dure, et le projet contourne pour toujours un processus qu'une réunion aurait pu corriger.
France Num rappelle que vous n'êtes pas tenu de connaître la technologie du futur site, mais qu'il faut préciser avec quels outils il devra fonctionner, comme un CRM ou un ERP. J'ajoute les données de référence. Sur un projet, un mélange de centimètres et de millimètres entre deux outils a suffi à déformer tout un rendu. Je demande donc qui détient la bonne valeur, et dans quelle unité.
Jeudi : couper le périmètre, et le montrer
C'est le jour le plus inconfortable. France Num dit que vouloir tout faire d'emblée est la principale source de dépassement budgétaire et conseille de séparer ce qui est indispensable au lancement de ce qui peut attendre une seconde phase. Je propose trois colonnes : au lancement, plus tard, jamais. La colonne « jamais » est la plus difficile à remplir, et c'est elle qui oblige à choisir.
Quand un désaccord résiste, je le rends visible. Montrer plusieurs directions de maquette au même niveau de finition débloque une décision mieux qu'un long débat, parce que chacun réagit à la même chose. Un jeudi suffit pour des schémas simples, pas pour une maquette achevée.
Vendredi : écrire, puis faire décider
La note s'écrit le matin et part à ceux qui décident avant la séance de l'après-midi. Celle-ci a un seul sujet : continuer, réduire ou arrêter. Rien de neuf n'arrive dans la salle, comme pour un comité de pilotage qui doit trancher : tout le monde a lu avant, et on sort avec une décision écrite.
04La note de cadrage tient sur deux pages
Une note de cadrage projet n'est pas un cahier des charges. France Num estime que cinq à dix pages bien structurées suffisent à un cahier des charges pour un site vitrine ou un e-commerce simple, et ce document vient après. Je vise deux pages pour la note, parce que je veux qu'elle soit relue. Voici le modèle :
- Projet, date, numéro de version
- Problème à résoudre : une phrase, sans nommer de solution
- Décision attendue : continuer, réduire ou arrêter
- Objectifs par ordre de priorité, avec la mesure de chacun
- Dans le périmètre au lancement
- Plus tard
- Hors périmètre
- Contraintes dures / contraintes souples
- Inconnues restantes : qui les lève, avant quelle date
- Ce que le projet ne promet pas
- Qui décide quoi : commanditaire, métier, technique
- Suite : premier jalon, enveloppe budgétaire
Deux lignes viennent directement de ma pratique. « Ce que le projet ne promet pas » reprend un champ que j'ai mis dans le brief de l'une de mes machines de contenu, qui oblige à lister ce que le texte s'interdit d'affirmer : écrire les limites avant de commencer évite les promesses glissées en route. Et le numéro de version vient d'une intégration entre un ERP et un site marchand, où la spécification a bougé presque à chaque réunion. Je l'ai fait évoluer version après version, pour que tout le monde parle du même document.
Je m'inspire aussi de mon brief de rédaction, qui refuse d'avancer tant qu'un champ reste vide. Une ligne vide dans cette note désigne une inconnue, à attribuer à quelqu'un.
Reste la question de la plume. Dans un article publié par le PMI, Richard et Elizabeth Larson écrivent que les chefs de projet rédigent le plus souvent la charte, alors que le commanditaire devrait en garder la propriété. Je peux écrire le document, mais le commanditaire doit pouvoir l'expliquer sans l'avoir sous les yeux.
05Ce qui arrive au périmètre après le cadrage
Le périmètre va bouger, et ce n'est pas grave. Les mêmes auteurs font une distinction que je trouve juste : un élargissement approuvé n'est pas une dérive. Le problème, c'est l'ajout que personne n'a décidé, parce qu'il semblait petit. Ils nomment aussi l'excès inverse, le « scope kill » : un processus si rigide qu'on refuse des changements utiles.
Je propose donc une règle légère, une ligne par demande : ce qui est demandé, l'objectif de la note auquel cela répond, l'effet sur le temps et le coût, qui a tranché. France Num conseille aussi de prévoir une réserve de 15 à 20 % pour les besoins non anticipés : ce sont ces lignes qui disent quand on y touche.
06Quand une semaine ne suffit pas
Je ne ferais pas ce format dans plusieurs cas.
- Personne dans l'entreprise n'a parlé aux utilisateurs concernés. Sur Moonworkers, le produit s'est conçu à partir des utilisateurs, avec personas et maquettes filaires : une semaine de cadrage ne remplace pas ce travail.
- Le projet traverse plusieurs organisations, chacune avec ses décideurs. Trouver un créneau commun prendra déjà une semaine.
- Il s'agit d'une refonte SAP ou ERP. Je n'en fais pas, et ce n'est pas la bonne échelle.
- Le commanditaire n'a pas de temps cette semaine-là. Sans lui, vous produirez un document et aucune décision. Je décalerais la semaine.
La méthode a aussi un coût. Elle demande à plusieurs personnes d'interrompre leur travail, et elle peut conclure qu'il ne faut pas lancer le projet, ce qui n'est pas toujours bien reçu par celui qui le portait. Elle laisse des inconnues : c'est écrit dans la note, mais elles restent là. Je n'ai pas non plus de mesure qui prouve qu'une semaine vaut mieux que deux ; c'est un choix de méthode, à ajuster à votre cas.
07Par où commencer lundi
Vous n'avez pas besoin d'attendre le lancement officiel. Demandez à trois personnes du projet d'écrire, chacune de son côté, le problème en une phrase et ce qui est hors périmètre. Comparez. Si les réponses se ressemblent, votre cadrage est peut-être déjà fait, et il suffit de l'écrire. Si elles divergent, vous savez ce qu'il faut régler avant de chiffrer quoi que ce soit.
Bloquez ensuite un créneau avec le commanditaire pour le vendredi suivant, avant de remplir le reste du modèle. C'est ce rendez-vous qui fera tenir le reste.
Si vous préférez que quelqu'un d'extérieur mène cette semaine avec vous, c'est le début de ce que je propose en direction de projet, et on peut en parler.