J'ai mis du temps à comprendre ce que c'est vraiment, un tableau de caractérisation. Pendant longtemps, je pensais que c'était juste un document de plus à remplir avant de commencer un projet. Une case à cocher pour le comité de direction. Et puis j'ai changé d'avis.

Ce qui m'a convaincu, c'est une situation très concrète. On avait lancé un projet de refonte de notre process de facturation. Trois mois de travail, deux prestataires impliqués, et à la livraison... on s'est rendu compte qu'on n'avait pas du tout la même vision du périmètre. Moi je pensais que ça incluait les relances automatiques. Le prestataire, non. Personne n'avait tort. Personne n'avait mis ça par écrit au départ.

Depuis, j'utilise un tableau de caractérisation sur chaque projet. Même les petits. Ça prend deux heures à construire. Ça évite des semaines de confusion.

Ce qu'est vraiment un tableau de caractérisation

C'est un document structuré qui résume l'ensemble des dimensions d'un projet au même endroit. Pas juste les objectifs. Pas juste le budget. Vraiment tout ce qui compte pour que tout le monde parte du même point.

Concrètement, ça regroupe :

le contexte et les raisons du projet
les objectifs mesurables attendus
les parties prenantes et leurs rôles
le périmètre précis, avec ce qui est inclus et ce qui ne l'est pas
les contraintes connues (budget, délai, ressources)
les risques identifiés dès le départ
les critères de succès

Ce n'est pas un cahier des charges. Ce n'est pas non plus un plan de projet. C'est l'outil qui vient avant. Celui qui pose le cadre avant qu'on commence à courir.

Je l'utilise aussi bien pour un projet interne (mise en place d'un outil RH) que pour un projet impliquant des partenaires externes. Dans les deux cas, ça force à se poser les bonnes questions au bon moment.

Pourquoi la méthode why how what change tout ?

Quand je construis le tableau, je commence toujours par la colonne "contexte et objectifs". Et là, j'applique un cadre simple que j'ai découvert assez tardivement : le why how what.

L'idée vient de Simon Sinek à la base, mais elle s'applique très bien à la caractérisation de projet. Le principe :

Why : pourquoi on lance ce projet ? Quel problème on résout vraiment ?
How : comment on va s'y prendre ? Quelle approche, quels moyens ?
What : qu'est-ce qu'on va livrer concrètement ?

La plupart des équipes font l'inverse. Elles commencent par le "what". On sait ce qu'on veut construire, alors on fonce. Le "why" arrive après, quand quelqu'un pose la question lors d'une réunion.

Résultat : on livre quelque chose. Mais pas forcément ce dont on avait besoin.

Dans mon tableau de caractérisation, j'ai désormais une section "Raison du projet" qui force à répondre au "why" en deux ou trois phrases maximum. Si on ne sait pas le formuler clairement, c'est souvent le signe que le projet n'est pas encore assez mûr pour démarrer. C'est inconfortable à entendre, mais c'est utile.

La structure concrète : ce que je mets dans mon tableau

Voici la trame que j'ai stabilisée après plusieurs essais et corrections. Elle n'est pas parfaite. Mais elle couvre l'essentiel pour une TPE ou une PME qui gère des projets en mode terrain.

Dimension	Ce qu'on y met	Exemple concret
Titre du projet	Un nom court et parlant	"Migration ERP vers solution SaaS"
Raison du projet (Why)	Problème ou opportunité identifié	"Réduire le temps de saisie comptable de 30%"
Approche retenue (How)	Méthode ou stratégie choisie	"Déploiement progressif, site pilote en priorité"
Livrables attendus (What)	Ce qu'on livre à la fin	"ERP opérationnel sur 3 sites, formation faite"
Périmètre inclus	Ce qui est dans le projet	"Comptabilité, facturation, stocks"
Périmètre exclu	Ce qui ne l'est pas	"Paie, RH, reporting BI"
Parties prenantes	Qui fait quoi, qui décide	"Chef de projet : Amélie. Sponsor : moi."
Budget estimé	Enveloppe globale	"35 000€ max, prestataire inclus"
Délai cible	Date ou durée	"Mise en prod avant fin T3"
Risques connus	Ce qui pourrait bloquer	"Résistance des équipes, dépendance prestataire"
Critères de succès	Comment on sait que c'est réussi	"Temps de saisie réduit, 0 erreur sur 3 mois"

La colonne "périmètre exclu" est celle que j'aurais aimé avoir sur le projet de facturation dont je parlais au début. C'est souvent la plus difficile à remplir, parce que ça suppose d'avoir des conversations qu'on préférerait éviter. Mais c'est précisément pour ça qu'elle est utile.

Le rôle du tableau dans la comitologie d'un projet

Quand on parle de gouvernance de projet, on entend souvent des mots un peu abstraits. La comitologie d'un projet désigne en réalité quelque chose de très concret : qui se réunit, à quelle fréquence, pour décider de quoi, et avec quelles informations.

Le tableau de caractérisation nourrit directement cette comitologie. Il dit clairement qui est sponsor, qui est chef de projet, qui valide les jalons. Sans ça, les réunions de suivi deviennent floues. On discute, on tourne en rond, et personne ne sait vraiment qui a le mot final.

Dans ma boîte, j'ai mis en place trois niveaux de suivi pour les projets significatifs :

un comité opérationnel toutes les deux semaines (chef de projet + équipe)
un point mensuel avec moi (avancement, risques, budget)
un comité de validation aux jalons clés (livrables, go/no-go)

Le tableau de caractérisation définit quels jalons déclenchent quel niveau de comité. C'est simple, mais avant de l'écrire, on improvisait. Et l'improvisation coûte cher.

Bon, par contre, je ne vais pas vous vendre du rêve. Même avec un bon tableau, si les parties prenantes ne le lisent pas, ça sert à rien. J'ai eu des projets où j'avais tout documenté, et à la première réunion, certains arrivaient sans l'avoir ouvert. Ça reste un document vivant, pas une garantie.

Comment construire votre tableau étape par étape ?

Démarrez seul, puis confrontez

Ma recommandation : rédigez une première version du tableau seul ou avec votre chef de projet. Pas en réunion collective. En réunion, les gens tendent à valider ce qui est dit plutôt qu'à challenger. Une fois que vous avez une première trame, là vous pouvez la soumettre à un petit groupe.

Je garde cette règle depuis deux ans. Ça change la qualité des échanges.

Soyez brutal sur le périmètre

La tentation est forte de mettre des choses dans le tableau "au cas où". On se dit qu'on verra bien. Résistez à ça. Un périmètre vague crée des attentes vagues. Ce qui n'est pas écrit sera interprété différemment par chaque personne dans la salle.

Si vous ne savez pas si une fonctionnalité est dedans ou dehors, mettez-la dans la colonne "hors périmètre" avec la mention "à réévaluer en phase 2". C'est honnête et ça évite les malentendus.

Fixez des critères de succès mesurables

"Le projet est réussi si les équipes sont satisfaites."

Non. Ça ne suffit pas. Satisfaites comment ? Mesurable comment ?

Je travaille avec mes équipes pour transformer chaque objectif flou en indicateur précis. "Réduire le temps de traitement des commandes de 20%" vaut mieux que "améliorer l'efficacité". Et ça oblige tout le monde à se mettre d'accord sur ce qu'on mesure avant, pas après.

Actualisez le tableau à chaque jalon

Le tableau n'est pas figé. Un projet évolue. Les contraintes changent, le budget se recadre, une partie prenante quitte l'entreprise. Je revois le tableau à chaque jalon majeur. Ça prend vingt minutes. Et ça évite de piloter sur des hypothèses périmées.

J'ai appris ça à mes dépens sur un projet logistique. On avait caractérisé le projet en janvier, et en juin, la moitié des hypothèses de départ n'étaient plus valides. On continuait quand même à piloter sur la base du tableau initial. Grosse erreur.

Les erreurs qui reviennent le plus souvent

Je les ai toutes faites, je crois.

Confondre le tableau avec un cahier des charges. Le tableau de caractérisation dit "quoi et pourquoi". Le cahier des charges dit "comment en détail". Ce ne sont pas les mêmes documents, ils n'ont pas le même niveau de précision, et ils n'ont pas les mêmes lecteurs.

Croire que remplir le tableau suffit. C'est un support de dialogue, pas un formulaire administratif. Si vous le remplissez seul dans votre coin et que vous l'envoyez par mail sans en parler, vous passez à côté de l'essentiel. La valeur vient des conversations qu'il génère.

Négliger la colonne "risques". J'ai souvent vu des équipes écrire "aucun risque identifié". C'est presque toujours faux. Ça veut souvent dire qu'on n'a pas encore cherché. Je force maintenant mes équipes à lister au moins trois risques sur chaque projet, même petit. Ça change la posture mentale.

Laisser le tableau dormir dans un dossier partagé sans que personne le retrouve. Ça m'a coûté du temps. Maintenant, le tableau est en première page de chaque espace projet, et il est rappelé en début de chaque réunion de suivi.

Ce que ça change au quotidien dans une petite structure

Quand on est une TPE ou une PME de taille intermédiaire, on n'a pas d'équipe PMO dédiée. Pas de département "méthodes et outils". On fait avec ce qu'on a. Et c'est justement pour ça que des outils simples et bien construits ont une vraie valeur.

Le tableau de caractérisation, c'est deux à trois heures de travail au départ. En échange, vous gagnez :

un point de référence pour tout le monde pendant toute la durée du projet
une base de décision claire lors des comités
moins de réunions pour "reclarifier les objectifs"
une vraie traçabilité si quelqu'un conteste le périmètre six mois plus tard

Sur mon projet ERP de l'an dernier, j'estime qu'on a évité au moins quatre réunions de recalibrage grâce au tableau. À raison de cinq personnes pendant deux heures chacune... vous faites le calcul. En termes de coût salarial, c'est significatif.

Là j'ai un vrai reproche à formuler sur les outils disponibles pour faire ce tableau : la plupart des modèles en ligne sont soit trop simples (juste un tableau vide avec des titres), soit trop complexes (des dizaines de colonnes conçues pour des directions de projet dans des grands groupes). Il faut souvent adapter. J'ai fini par créer ma propre version sur Google Sheets, et c'est celle que j'utilise depuis.

Adapter le tableau selon la taille du projet

Tous les projets ne méritent pas le même niveau de détail. C'est une erreur de croire qu'il faut tout formaliser avec la même rigueur.

Pour un projet court, moins de deux mois, avec une seule personne impliquée, une version allégée suffit. Je remplis quatre blocs : raison du projet, livrables attendus, contraintes, critères de succès. Quinze minutes maxi.

Pour un projet multipartite, avec un budget conséquent et plusieurs mois de durée, là on sort la version complète. Toutes les dimensions, les risques détaillés, la comitologie formalisée, les rôles RACI si besoin.

L'idée, c'est de calibrer l'effort de caractérisation au niveau d'enjeu du projet. Pas de sous-formaliser les gros projets, pas de sur-documenter les petits.

Je me suis fixé une règle simple : dès qu'un projet dépasse 10 000€ ou deux mois de travail, le tableau complet est non négociable. En dessous, la version courte suffit.

Cette règle a le mérite d'être claire. Tout le monde dans l'équipe la connaît. Et ça évite les discussions au cas par cas.

Un outil qui vaut largement le temps qu'on y passe

Je ne suis pas un expert en gestion de projet. J'ai appris sur le tas, parfois à la dure. Le tableau de caractérisation est probablement l'outil le plus concret que j'ai intégré dans mon fonctionnement ces deux dernières années.

Pas parce que c'est révolutionnaire. Parce que ça force à poser les questions qu'on aurait tendance à différer. Pourquoi ce projet maintenant ? Qui décide vraiment ? Qu'est-ce qu'on est prêt à couper si le budget flanches ?

Ces questions sont inconfortables. Le tableau vous oblige à y répondre avant que les problèmes arrivent. Et croyez-moi, ils arrivent toujours.

Si vous n'avez jamais utilisé ce type de document, commencez par un projet en cours. Même rétrospectivement. Essayez de le remplir avec votre équipe, et regardez où les désaccords émergent. C'est souvent très révélateur de ce qui n'a pas été clarifié au départ.