Tableau de caractérisation : méthode simple pour analyser un projet efficacement

Vingt ans à faire de la compta, ça apprend une chose : un projet mal cadré en amont coûte bien plus cher qu'un logiciel raté. J'ai vu des équipes tourner en rond pendant des semaines parce que personne n'avait pris le temps de poser les bonnes questions au départ. Le tableau de caractérisation, je l'ai découvert un peu par hasard, lors d'une formation gestion de projet que ma direction m'avait imposée. Je pensais que ça ne me concernait pas vraiment. J'avais tort.

Depuis, je l'utilise pour cadrer à peu près tout ce qui dépasse deux semaines de travail dans mon service : changement d'outil comptable, révision du processus de clôture mensuelle, migration vers la dématérialisation des factures fournisseurs. Chaque fois, ça m'a évité des réunions inutiles et des retours en arrière coûteux.

Ce qu'est vraiment un tableau de caractérisation (et ce qu'il n'est pas)

On l'appelle aussi fiche projet, fiche de cadrage, ou encore fiche d'identité de projet. Peu importe le nom. L'idée, c'est de poser sur une page unique les informations clés qui définissent un projet avant qu'on y touche vraiment. Pas un cahier des charges de 40 pages. Pas un planning Gantt. Juste une grille claire, lisible par tout le monde, technique ou non.

Ce que j'apprécie particulièrement, c'est que le tableau de caractérisation force à répondre à des questions qu'on esquive souvent. Pourquoi fait-on ça ? Qui décide ? Qu'est-ce qu'on considère comme un succès ? Ces questions paraissent évidentes. Pourtant, dans ma carrière, j'ai rarement vu des projets où tout le monde avait la même réponse. C'est là que les problèmes commencent.

Bon, par contre, ne confondez pas ça avec un simple mémo ou un compte-rendu de réunion de lancement. La caractérisation, c'est structuré. Il y a des rubriques précises, et chaque rubrique a un rôle. Si vous remplissez le tableau à moitié ou de façon approximative, vous passez à côté de l'intérêt.

Les rubriques incontournables d'un bon tableau de caractérisation

Il n'existe pas de format universel imposé. Mais dans les structures que j'ai vues fonctionner (et celles qui ont raté), quelques rubriques reviennent toujours. Je vous les présente avec ce que j'y mets concrètement.

L'intitulé et le contexte du projet

Ça semble basique. Et pourtant. L'intitulé doit être précis : "amélioration de la facturation" ne veut rien dire. "Automatisation du rapprochement bancaire pour réduire le temps de clôture de 3 jours à 1,5 jour" : là, on sait de quoi on parle.

Le contexte, c'est la photo de la situation actuelle. Pourquoi ce projet existe maintenant, pas il y a deux ans. Dans mon cas, pour la migration vers la dématérialisation, le contexte c'était l'obligation légale de facturation électronique qui approchait, combinée à un volume de factures papier qui avait doublé en trois ans. Sans ce contexte écrit noir sur blanc, certains managers pensaient qu'on anticipait une contrainte lointaine. En réalité, on avait moins de 18 mois.

Les objectifs et le why how what

C'est la rubrique que je remplis en m'appuyant sur la logique why how what, une approche popularisée par Simon Sinek mais qui s'adapte très bien à la caractérisation de projet. Pourquoi fait-on ce projet ? Comment va-t-on s'y prendre ? Qu'est-ce qu'on va produire concrètement ?

Le "why" est souvent flou dans les projets d'entreprise. On dit "pour gagner du temps" mais on ne quantifie pas. Je recommande d'écrire un objectif mesurable : "réduire de 40% le temps passé sur les relances fournisseurs d'ici juin". Le "how" décrit l'approche : mise en place d'un outil d'automatisation des relances, avec paramétrage sur notre ERP existant. Le "what" liste les livrables attendus : règles de relance configurées, tableau de bord de suivi, formation des deux gestionnaires comptables.

Trois niveaux de lecture, trois questions simples. Mais écrire les réponses oblige à aligner les parties prenantes avant que le projet ne démarre. C'est là que la méthode why how what prend tout son sens dans un tableau de caractérisation : pas pour faire joli, mais pour forcer la clarté.

Le périmètre et ce qui est hors périmètre

Là j'ai un vrai reproche à faire aux équipes qui remplissent ce tableau trop vite : elles oublient systématiquement de préciser ce qui est exclu. Et c'est pourtant aussi important que ce qui est inclus.

Sur le projet de dématérialisation que j'ai piloté, on avait bien indiqué que la solution concernait les factures fournisseurs. Mais on n'avait pas précisé que les notes de frais étaient hors périmètre. Résultat : deux mois après le lancement, un responsable de service est arrivé avec sa liste de notes de frais en demandant quand "son module" serait prêt. J'ai perdu du temps là-dessus, à réexpliquer ce qui n'avait jamais été dans le scope.

Depuis, je remplis toujours les deux colonnes :

• Ce qui est dans le périmètre (factures fournisseurs, bon de commande, rapprochement automatique)
• Ce qui est explicitement hors périmètre (notes de frais, factures clients, refacturation inter-sociétés)

Les acteurs, la gouvernance et la comitologie d'un projet

Cette rubrique est souvent bâclée. On écrit "chef de projet : Untel" et on passe à la suite. Mauvaise idée.

Un tableau de caractérisation sérieux doit identifier qui fait quoi, mais aussi qui valide, qui arbitre, et à quelle fréquence. C'est ce qu'on appelle la comitologie d'un projet : l'ensemble des instances de gouvernance qui jalonnent la vie du projet. Un comité de pilotage mensuel avec le DG et la DAF ? Un comité opérationnel hebdomadaire avec les équipes terrain ? Un comité de validation avant chaque livraison ?

Si la comitologie d'un projet n'est pas définie dès la caractérisation, vous allez passer les premières semaines à vous demander qui a le droit de décider quoi. J'ai vécu ça sur un projet de mise en place d'un nouvel outil de reporting. Personne ne savait si c'était la DSI ou la DAF qui validait les choix techniques. On a perdu presque un mois à trancher cette question, alors qu'elle aurait pu être réglée en deux lignes dans le tableau de départ.

Dans cette rubrique, je note systématiquement :

• Le sponsor du projet (celui qui porte le budget et les décisions finales)
• Le chef de projet opérationnel
• Les contributeurs internes (DSI, RH, métiers concernés)
• Les prestataires externes si applicable
• La fréquence et le format des instances de suivi

Le planning macro et les jalons

Pas un Gantt détaillé. Juste les grandes étapes et les dates clés. Ce que j'appelle les "points de non-retour" : le moment où on choisit l'outil, le moment où on valide la configuration, la date de bascule en production.

Sur un tableau de caractérisation, un planning sur 4 à 6 lignes suffit. Si vous avez besoin de plus, c'est que vous êtes déjà en train de faire du planning détaillé, pas de la caractérisation.

Les risques identifiés

Rubrique que j'adore. Pas parce que j'aime les mauvaises nouvelles, mais parce qu'écrire les risques en amont oblige à les penser vraiment. Et quand un risque se concrétise, l'équipe n'est pas surprise, elle a déjà un plan B sous la main.

Je limite volontairement à trois ou quatre risques maximum dans le tableau de caractérisation. Les gros, les vraisemblables. Pas une liste exhaustive de tout ce qui pourrait théoriquement mal tourner.

Un exemple concret : tableau rempli pour un projet réel

Pour que vous voyez ce que ça donne en pratique, voici une version simplifiée du tableau que j'ai utilisé lors du projet d'automatisation des relances fournisseurs dans mon entreprise (une PME industrielle de 65 personnes, Lyon).

Ce tableau tient sur une page. Il a été présenté en comité de direction en 10 minutes. Tout le monde savait où on allait, qui faisait quoi, et ce qu'on attendait. C'est exactement l'objectif.

Les erreurs que je vois le plus souvent

Après avoir accompagné ou observé une vingtaine de projets en PME, j'ai une petite liste des erreurs récurrentes qui sabotent l'utilité du tableau de caractérisation.

Remplir le tableau seul dans son coin. C'est la première. La caractérisation doit être co-construite, au moins avec le sponsor et un ou deux contributeurs clés. Si vous remplissez tout seul et que vous envoyez le tableau pour "validation", vous obtiendrez au mieux un accord de façade. Les vrais désaccords remonteront pendant le projet, au pire moment.

Mettre des objectifs flous. "Améliorer la productivité" ne vaut rien. "Réduire le délai de clôture mensuelle de 5 à 3 jours ouvrés" : là on peut mesurer, on peut débattre, on peut ajuster.

Négliger la rubrique des risques parce qu'on veut être positif. Je comprends l'état d'esprit, mais c'est contre-productif. Écrire un risque ne le fait pas arriver. En revanche, ne pas l'écrire empêche de s'y préparer.

Et la dernière, que je considère comme la plus coûteuse : ne jamais mettre à jour le tableau. Le document de caractérisation n'est pas une photo figée. Si le périmètre change en cours de route, il faut l'amender officiellement, avec une date et un signataire. Sinon, vous vous retrouvez avec un document de référence obsolète que personne ne consulte plus.

Pour quel type de projet est-ce vraiment utile ?

Je ne l'utilise pas pour tout. Pour une tâche récurrente ou un mini-chantier de deux jours, c'est disproportionné. Mais dès qu'un projet implique plusieurs personnes, un budget, et une durée supérieure à un mois, le tableau de caractérisation vaut le temps qu'on y consacre.

Dans mon contexte comptable, je l'ai utilisé pour :

• La mise en place d'un nouvel outil de reporting consolidé
• La révision complète du processus de clôture trimestrielle
• Le déploiement d'une solution d'OCR pour la lecture automatique des factures
• La migration vers un nouveau logiciel de notes de frais

À chaque fois, le tableau a servi de référence commune. Quand quelqu'un ajoutait une demande en cours de projet, je pouvais sortir le tableau et demander si ça rentrait dans le périmètre défini ou si ça méritait un nouveau projet. Ça évite le scope creep, cette tendance naturelle à élargir le projet au fil de l'eau jusqu'à ce qu'il devienne ingérable.

Par contre, je déconseille de l'utiliser comme prétexte pour retarder l'action. J'ai vu des équipes passer trois semaines à "peaufiner le tableau de caractérisation" avant de démarrer quoi que ce soit. Le tableau, ça se fait en deux à trois sessions de travail, pas plus. Si vous avez besoin de plus, c'est que vous n'avez pas encore les informations nécessaires pour lancer le projet.

Questions fréquentes

Quelle est la différence entre un tableau de caractérisation et un cahier des charges ?

Le cahier des charges est un document détaillé qui décrit précisément ce qu'on attend d'une solution ou d'un prestataire. Il peut faire 20, 50 ou 100 pages. Le tableau de caractérisation, c'est la page de garde intelligente qui précède tout ça. C'est le document qui permet d'aligner les parties prenantes avant d'entrer dans le détail. L'un ne remplace pas l'autre : ils se complètent, et le tableau vient en premier.

Qui doit remplir le tableau de caractérisation ?

Le chef de projet en pilote la rédaction, mais il ne le remplit pas seul. Le sponsor apporte la vision stratégique et valide les objectifs. Les contributeurs clés (DSI, métiers concernés) alimentent la partie périmètre et risques. En PME, une session de travail d'une heure à deux heures avec les bonnes personnes suffit généralement à produire un premier jet solide.

Est-ce qu'il existe un modèle standard ?

Il n'y a pas de format imposé. Chaque organisation peut adapter la structure à ses besoins. Ce qui compte, c'est que les rubriques clés soient présentes : contexte, objectifs mesurables, périmètre, acteurs, gouvernance (la comitologie d'un projet), planning macro, risques et critères de succès. Le reste est optionnel.

Combien de temps faut-il pour remplir un tableau de caractérisation ?

Pour un projet de taille moyenne en PME, comptez deux à quatre heures au total, réparties sur deux sessions. La première pour un premier draft individuel, la deuxième pour le valider en groupe. Si vous prenez beaucoup plus de temps que ça, posez-vous la question de savoir si le projet est suffisamment mûr pour démarrer.

Peut-on utiliser un simple fichier Excel ou Word ?

Oui, tout à fait. Aucun outil spécifique n'est requis. J'utilise personnellement un modèle Word d'une page que j'ai construit au fil des années. Certaines équipes préfèrent Notion, Confluence ou même une slide PowerPoint. L'outil n'a aucune importance. Ce qui compte, c'est que le document soit partagé, accessible, et mis à jour.

Que se passe-t-il si les objectifs changent en cours de projet ?

C'est normal et ça arrive. Dans ce cas, le tableau de caractérisation doit être officiellement amendé, avec une date de révision et la mention des personnes qui ont validé le changement. Un tableau non mis à jour devient rapidement un document fantôme que personne ne consulte plus. Et quand un litige survient sur le périmètre ou les objectifs, vous n'avez plus rien de fiable comme référence.

Le tableau de caractérisation est-il adapté aux petites équipes non techniques ?

C'est justement là qu'il est le plus utile. Le vocabulaire est simple, la structure est visuelle, et ça ne demande aucune compétence en gestion de projet formelle. J'ai formé deux assistantes comptables à l'utiliser en moins d'une heure. Elles s'en servent maintenant pour cadrer leurs propres mini-projets sans avoir besoin de me solliciter à chaque fois. C'est exactement l'effet recherché.