Suivi de projet web : que doit montrer un tableau de bord client ?
Suivi de projet web : que doit montrer un tableau de bord client ?
Un tableau de bord client doit permettre à un dirigeant de comprendre l’état réel de son projet web en moins d’une minute.
Il doit répondre à six questions :
- où en est le projet ;
- ce qui est réellement terminé ;
- quelle est la prochaine étape ;
- quelle décision est attendue du client ;
- quel obstacle menace le planning ;
- où trouver les livrables et les décisions validées.
Il ne doit pas reproduire toute l’activité interne de l’agence. Il doit sélectionner les informations qui permettent au client de comprendre, décider et agir.
Cette distinction évite deux échecs fréquents : le projet opaque, qui oblige à relancer, et le tableau de bord surchargé, qui montre beaucoup de tâches sans donner un statut compréhensible.
Un tableau de bord client n’est pas un compte rendu d’activité
Une longue liste de tâches accomplies ne répond pas forcément à la question principale : le projet avance-t-il conformément à ce qui a été décidé ?
Le guide GOV.UK sur le suivi des projets agiles pose un principe utile : le reporting doit donner une vision claire de l’avancement sans créer de travail supplémentaire pour l’équipe. Il recommande de s’appuyer sur la planification continue, une information visuelle accessible et des échanges réguliers.
Le Project Management Institute insiste de son côté sur des rapports courts, structurés et adaptés à leur lecteur. Le détail peut rester accessible, mais il ne doit pas masquer l’information importante.
Pour un dirigeant, le bon niveau n’est donc ni la carte technique déplacée ce matin, ni la présentation mensuelle de dix pages. C’est un état du projet relié aux jalons convenus, aux validations et aux risques.
Les six blocs utiles dans un suivi de projet web
1. Un état actuel expliqué
Le premier écran doit indiquer la phase en cours avec des mots simples : cadrage, structure, design, intégration, contenus, recette ou mise en ligne, selon le projet.
Un statut n’a de valeur que s’il est expliqué. « En cours » peut vouloir dire que l’équipe travaille normalement, qu’elle attend un contenu du client ou qu’un problème technique bloque la suite. Ces situations ne produisent pas la même décision.
Une phrase suffit souvent :
L’intégration des pages principales est en cours. La validation des textes de la page Services conditionne le prochain lot.
Cette formulation donne l’état, le périmètre actif et la dépendance. Elle est plus utile qu’une jauge de progression isolée.
2. Les éléments terminés avec leur preuve
Une tâche cochée par l’équipe ne signifie pas toujours qu’un livrable est prêt pour le client.
Chaque jalon terminé devrait être associé à une preuve consultable : arborescence validée, maquette approuvée, page intégrée, contenu reçu, test exécuté ou décision enregistrée.
Le tableau de bord doit aussi préciser la condition de sortie. Une page peut être techniquement intégrée mais encore attendre ses contenus, sa recette mobile ou sa validation finale. Le mot « terminé » doit avoir une définition partagée.
Cette discipline limite les malentendus sans exposer toutes les opérations internes.
3. Le prochain jalon
L’avancement devient concret lorsque le client voit ce qui vient ensuite.
Le prochain jalon doit comporter :
- son résultat attendu ;
- son responsable ;
- sa date cible ;
- ses prérequis ;
- son critère de validation.
« Finaliser le design » reste trop vague. « Valider les maquettes des cinq pages principales avant le démarrage de l’intégration » décrit une sortie observable.
Le planning peut évoluer. Le tableau de bord doit alors conserver la nouvelle date et la raison du changement, plutôt que remplacer silencieusement l’ancienne information.
4. Les décisions attendues du client
Une partie du délai d’un projet web dépend de réponses extérieures à l’équipe de production : choix d’une variante, fourniture d’un accès, validation d’un texte, accord juridique ou arbitrage entre deux fonctions.
Ces demandes ne devraient pas rester dispersées dans les emails et les messageries.
Chaque décision attendue doit présenter :
- la question à trancher ;
- les options compréhensibles ;
- la recommandation éventuelle ;
- la conséquence de chaque choix ;
- la date à laquelle la réponse devient bloquante.
Le PMI souligne l’importance de rendre les dépendances visibles. Dans un projet client, cette visibilité protège les deux parties. Elle évite d’attribuer automatiquement tout retard au prestataire, mais aussi de noyer une demande importante dans une suite de notifications.
5. Les obstacles, risques et changements de périmètre
Un tableau de bord utile ne doit pas devenir une vitrine où tout reste vert.
Un obstacle doit être affiché lorsqu’il modifie une date, un coût, une qualité attendue ou le périmètre. Il faut indiquer ce qui s’est produit, son effet probable, l’action engagée et la personne qui doit décider.
Il faut également séparer trois notions :
- un risque peut se produire ;
- un blocage empêche déjà d’avancer ;
- une demande de changement modifie ce qui avait été convenu.
Les mélanger rend les responsabilités illisibles. Les distinguer permet de décider sans dramatiser.
6. Les livrables et l’historique des validations
Le client doit pouvoir retrouver la dernière version utile sans chercher dans plusieurs outils.
Le tableau de bord peut regrouper les liens vers les maquettes, contenus, accès, comptes rendus de recette et documents de livraison. Il n’a pas besoin de stocker tous les fichiers lui-même, mais il doit pointer vers la bonne version.
Un historique léger complète cet espace : décision, date, personne ayant validé et objet concerné. Cette trace devient particulièrement importante lorsque plusieurs interlocuteurs participent au projet ou lorsqu’une décision est révisée.
Éviter la fausse précision du pourcentage global
Afficher « 72 % terminé » donne une impression de maîtrise. Ce nombre peut pourtant être trompeur si les tâches n’ont pas le même poids ou si une validation critique bloque la suite.
Pour un projet web, des jalons lisibles sont souvent plus utiles qu’un pourcentage unique : structure validée, maquettes approuvées, intégration en cours, contenus manquants, recette planifiée.
Si une progression chiffrée est utilisée, sa méthode de calcul doit être explicite et stable. Sinon, mieux vaut montrer les étapes franchies et les conditions restantes.
Mettre à jour sans créer une deuxième gestion de projet
Le tableau de bord échoue s’il oblige l’équipe à ressaisir manuellement toutes les informations dans un outil réservé au client.
La bonne architecture consiste à partir des données déjà produites pendant le travail : jalons, statuts, validations, risques et livrables. La vue client filtre et reformule ces données. Elle ne crée pas un second projet parallèle.
Quelques règles suffisent :
- mettre à jour l’état lorsqu’un jalon change, pas pour simuler de l’activité ;
- notifier le client seulement lorsqu’une action ou une décision est nécessaire ;
- conserver le détail technique derrière un lien ;
- utiliser les réunions pour arbitrer, pas pour reconstituer l’historique ;
- attribuer chaque information à une source et à une date.
Ce que ce cadre change pour une TPE ou une PME
Un dirigeant n’a pas besoin d’observer chaque heure de production. Il a besoin de savoir si le projet suit sa trajectoire, ce qui réclame son attention et quelle conséquence aura sa décision.
C’est le cadre qui guide actuellement la construction du Dashboard ONORA. La preuve disponible montre aujourd’hui son accueil et son écran de connexion. Elle ne démontre pas encore un suivi complet de bout en bout, ni l’application automatique de modifications sur un site. Ces fonctions devront être montrées sur un projet réel avant de pouvoir être présentées comme opérationnelles.
Le principe, lui, peut déjà être appliqué sans outil complexe : un espace partagé, six blocs d’information, des jalons définis et un historique des décisions.
Un bon tableau de bord ne cherche pas à prouver que l’équipe est occupée. Il rend le projet compréhensible au moment où le client doit décider.
