Le comptoir · Lancer un projet
Cadrage de projet : ce qu'il faut avoir écrit avant de lancer
« Il y a ce projet, c'est toi qui le pilotes, on compte sur toi. » Beaucoup de projets commencent par une réunion comme celle-là, et le chef de projet repart avec, comme si c'était une feuille de route. Ce n'en est pas une.
Un responsable de production est reçu par son manager et le directeur du site. Réunion courte, à l’ordre du jour : le projet de changement du logiciel de gestion de production. On lui dit qu’il a été choisi pour le piloter, qu’il faudra que ce soit en place avant l’été, et qu’on compte sur lui. Il dit oui. On se lève. C’est formel, c’est clair, et il n’y a presque rien dedans.
Ce que je vois ensuite, en formation comme en intervention, c’est que cette réunion devient la feuille de route. On ne la questionne pas, ou peu. On ne se demande pas vraiment si le logiciel est le vrai sujet, qui en a besoin, ce qu’on cherche à régler, ce qu’on y met et ce qu’on n’y met pas. On commence. Et six mois plus tard, on a un projet qui avance dans le détail sans que personne sache dire ce qu’il doit livrer ni qui tranche quand deux services ne sont pas d’accord.
Le cadrage, c’est le travail qu’on fait entre cette réunion et le premier jour du projet. Sa taille dépend du projet : pour un logiciel dans une PME, une ou deux pages et quelques jours ; pour une centrale nucléaire, un dossier épais et des mois. Mais dans tous les cas, c’est une phase courte par rapport à ce qui suit, la préparation puis l’exécution, et c’est elle qui oriente tout le reste. Peu de temps, pour beaucoup d’effet.
À quoi sert le cadrage, et qui le fait
Le cadrage vient au tout début, avant le planning, avant l’équipe, avant le lancement. Il répond à une question simple : est-ce que cette idée est une vraie opportunité pour l’entreprise, et si oui, de quoi parle-t-on exactement ?
En principe, c’est le travail de celui qui demande le projet : le commanditaire, le sponsor, ce que les méthodes appellent la maîtrise d’ouvrage. Dans la pratique, le commanditaire désigne souvent quelqu’un pour le faire, et ce quelqu’un est fréquemment le futur chef de projet. Ce n’est pas un problème, à une condition : qu’il le fasse comme un travail à part entière, avec le commanditaire, et pas comme une formalité à remplir pour avoir le droit de commencer.
Parce que le cadrage est un engagement. Quand le commanditaire relit la page et dit « oui, c’est ça », il s’engage sur ce qu’il demande, sur ce qu’il n’attend pas, sur qui décidera. Le chef de projet, lui, s’engage sur ce qu’il va livrer. Sans ce moment-là, chacun porte sa version du projet dans sa tête, et on découvre les écarts au pire moment.
Les grands référentiels disent la même chose, chacun avec son document. Chez le PMI, c’est la charte de projet : le chef de projet peut la rédiger, c’est le sponsor qui l’émet et l’approuve. Chez PRINCE2, c’est le project brief : le chef de projet l’assemble, et c’est l’exécutif, le représentant de celui qui paie, qui en répond et qui décide ensuite si le projet démarre. Dans les deux cas, le chef de projet hérite du sujet, et celui qui a demandé le projet garde la décision. Ce que je propose ici est une synthèse des deux, ramenée à douze rubriques, avec pour chacune les questions à se poser avant d’écrire. Ces questions, on les apprend en formation ou en préparant une certification ; elles ne sont pas toujours sous la main le jour où un responsable de production se retrouve avec un projet et deux pages blanches. C’est pour ce jour-là que l’article et le gabarit du bas sont faits.
Le besoin, et le besoin derrière le besoin
La première rubrique est celle qu’on bâcle le plus, parce qu’on croit la connaître. On nous a demandé un logiciel, donc le besoin, c’est un logiciel.
Non. Un logiciel, c’est une solution. Le besoin, c’est ce que cette solution est censée régler : des commandes qu’on perd, des stocks qu’on ne connaît pas, un client qui attend trois jours une réponse qu’il devrait avoir en une heure. Il faut distinguer le besoin exprimé, celui qu’on nous a donné avec les mots de la demande, et le besoin réel, celui qu’on trouve en posant trois ou quatre questions de plus. Pourquoi maintenant ? Qu’est-ce qui se passe si on ne fait rien ? Qui souffre du problème aujourd’hui ? Qu’est-ce qui serait différent dans six mois si le projet réussit ?
Ces questions, on ne peut pas y répondre seul à son bureau. Il faut aller voir les parties prenantes : celui qui demande, ceux qui utiliseront le résultat, et ceux qui seront touchés sans l’avoir demandé, parce que ce sont eux qu’on oublie et qui bloquent plus tard. Trois ou quatre conversations suffisent souvent. Elles servent à affiner le besoin, et elles servent à autre chose qui n’est pas écrit dans les méthodes : les gens qu’on a consultés au cadrage se sentent concernés par le projet. Ceux qu’on a informés après, non.
Ce qui est dedans, et surtout ce qui n’y est pas
Le périmètre, tout le monde pense à l’écrire. Ce qu’on oublie presque toujours, c’est d’écrire ce qui en est exclu.
Or c’est la partie la plus utile de la page. « Le projet couvre le déploiement du logiciel sur le site de Lyon. Il ne couvre pas le site de Nantes, ni la reprise de l’historique antérieur à 2024, ni la formation des intérimaires. » Chaque ligne d’exclusion est une conversation qu’on n’aura pas à avoir dans quatre mois, quand quelqu’un dira « mais je croyais que c’était compris ». Et quand on relit le périmètre avec le commanditaire, c’est sur les exclusions qu’il réagit : c’est là qu’on découvre ce qu’il avait en tête sans l’avoir dit.
Juste à côté du périmètre, les livrables principaux, nommés, et les critères de succès : comment on saura, à la fin, que c’est réussi. Pas « le logiciel est déployé », mais « plus aucune commande saisie à la main au 30 juin, et un délai de réponse client sous une heure ». C’est ce qui permettra, plus tard, de dire que le projet est fini.
Plus d’une solution
Le cadrage est aussi le moment où on s’autorise à ne pas prendre la première solution venue. La réunion de départ en contenait une. Il y en a presque toujours d’autres : un autre logiciel, le même logiciel sur un périmètre réduit, une réorganisation sans logiciel, ou ne rien faire.
Écrire au moins deux options, dont « ne rien faire », n’est pas un exercice de style. C’est ce qui oblige à dire pourquoi on retient celle qu’on retient, et c’est ce qui donne au commanditaire une vraie décision à prendre, plutôt qu’une confirmation à signer. Un projet dont le sponsor a choisi la solution parmi d’autres est un projet qu’il défendra. Un projet dont il a juste validé l’idée de départ, il le lâchera à la première difficulté.
Ce que ça coûte, et ce que ça rapporte
On pense au budget. On pense moins à la valeur, et pourtant c’est elle qui devrait décider.
Le budget, c’est ce que le projet coûte : les prestations, les licences, et le temps des personnes, qu’on oublie toujours parce qu’il ne sort pas de la trésorerie. La valeur, c’est ce que le projet rapporte ou évite : des heures de saisie, des erreurs, des pénalités, un risque réglementaire, un client qu’on garde. Au stade du cadrage, on n’a pas besoin d’un chiffrage au centime. On a besoin d’un ordre de grandeur des deux côtés, pour pouvoir dire si le jeu en vaut la chandelle, et pour pouvoir le redire dans six mois quand quelqu’un demandera pourquoi on fait tout ça.
Les jalons, la gouvernance, les risques
Trois rubriques qui vont ensemble, parce qu’elles décrivent comment le projet va se tenir.
Les grandes étapes. Pas un planning, on n’en est pas là. Trois à six étapes, datées grossièrement, et surtout les moments où on s’arrêtera pour vérifier quelque chose avant de continuer : la fin de l’étude, le choix du prestataire, le pilote sur un site. Ce sont des points où le commanditaire reprend la main et décide de poursuivre, de changer, ou d’arrêter.
La gouvernance. C’est la rubrique que les petits projets sautent, et c’est celle qui les tue. Qui décide au quotidien, et jusqu’où ? Qui arbitre quand la production et la qualité ne sont pas d’accord ? Dans quelle réunion, à quel rythme ? Si la réponse est « on verra », le projet s’arrêtera au premier désaccord, parce que personne n’aura le droit de trancher. Écrire la gouvernance au cadrage, c’est aussi donner au chef de projet une marge : ce qu’il peut décider seul, et à partir de quand il doit remonter.
Les risques et les opportunités. Ce qui peut faire échouer le projet, et ce qu’on fait pour l’éviter. Ce qui pourrait le rendre meilleur que prévu, aussi, parce qu’on ne pense jamais à le noter. Cinq lignes suffisent au cadrage ; le travail détaillé viendra après.
Ce que le projet touche autour de lui
Deux dernières rubriques, souvent absentes des gabarits simplifiés, et pourtant décisives dans une entreprise.
Les compétences. De quoi aura-t-on besoin pour faire ce projet, et qui l’a ? Si la réponse est « Martine, mais elle est déjà sur deux autres projets », c’est maintenant qu’il faut le savoir, et c’est maintenant qu’il faut voir son manager pour que le temps soit alloué. Pas au lancement, et surtout pas au premier retard.
Les interfaces et les projets connexes. Un projet ne vient jamais seul. Il touche un autre système, une autre équipe, un autre projet en cours qui attend la même personne ou le même budget. Les écrire au cadrage, c’est savoir qui prévenir, et éviter de découvrir en juin que le projet d’à côté a besoin du même serveur en juin aussi.
Et pour finir, les hypothèses et les contraintes : ce qu’on suppose vrai sans l’avoir vérifié, et ce qu’on ne peut pas changer, une date réglementaire, un budget fermé, une décision déjà prise. Les écrire noir sur blanc évite qu’elles se transforment, plus tard, en surprises.
Quand on ne le fait pas
J’ai accompagné une organisation qui avait lancé un projet de transformation interne, important pour elle, en partant d’une intention et d’un prestataire. L’intention était bonne. Le prestataire était compétent. Personne n’avait écrit ce qu’on cherchait à obtenir, ce qui était exclu, ni qui déciderait de quoi.
Le projet a fait ce que font tous les projets sans cap : il est entré dans le détail très vite, parce que le détail est rassurant quand on ne sait pas où on va. Et dans le détail, il a buté sur des dizaines de décisions que personne n’était légitime pour prendre. Chaque arbitrage remontait, redescendait sans réponse, remontait encore. Le projet s’est enlisé, puis s’est arrêté.
La première chose qu’on a faite en reprenant la main n’a pas été de refaire le planning. Ça a été d’écrire la page qui manquait : le besoin réel, le périmètre et ses exclusions, la gouvernance, les grandes étapes. Deux semaines de conversations. À la fin, l’organisation avait sa charte de projet, et le travail a pu reprendre, parce qu’on savait enfin qui décidait de quoi et ce qu’on cherchait à obtenir.
Le gabarit
Le gabarit reprend les rubriques de la charte de projet du PMI et du project brief de PRINCE2, en une synthèse de deux pages, et ajoute sous chaque rubrique les questions à aller poser, et à qui, avant d’écrire. C’est ce qui manque le plus à un chef de projet occasionnel : pas la liste des rubriques, mais quoi faire pour les remplir.
C’est ce gabarit-là que je mets à disposition ici : douze rubriques, avec pour chacune les questions à s’être posées plutôt que des cases à cocher. Il se remplit avec le commanditaire, pas pour lui. Il se relit avec lui. Et il se lit au lancement, avec l’équipe, qui l’amende.
Télécharger la page de cadrage (Word, 2 pages)
Trois questions qu’on me pose souvent
Qui doit écrire le cadrage, le sponsor ou le chef de projet ? Le sponsor en est responsable, le chef de projet le rédige souvent. Ce qui compte, c’est qu’ils le relisent ensemble et que le sponsor dise « c’est ça ». Si le sponsor refuse d’y passer une heure, le projet a déjà son premier risque, et il faut l’écrire dans la page.
Combien de temps ça prend ? C’est proportionnel au projet. Pour un projet de quelques mois : trois à cinq conversations et quelques heures d’écriture, étalées sur une à deux semaines. C’est long par rapport à la réunion de départ. C’est court par rapport aux six mois qu’on perd sans.
Et si on a déjà commencé ? On cadre quand même. C’est ce qu’on a fait dans l’exemple ci-dessus. Un cadrage tardif est moins confortable qu’un cadrage au départ, parce qu’il révèle des écarts qu’il faudra assumer, mais il vaut toujours mieux qu’un projet qui continue sans cap.
Pour aller plus loin. La page de cadrage est lue et amendée avec l’équipe lors du lancement : c’est le premier des quatre points de Réunion de lancement de projet : ce qui doit en sortir. Et le réflexe « cadrer sur une page » est le premier des quatre que je travaille avec les chefs de projet occasionnels.