Dette de validation projet : pourquoi un livrable produit n’est pas encore un livrable validé

Livré ne signifie pas validé.

Dans un projet Finance ou SI, un livrable peut être terminé sans être réellement validé.

Le document a été rédigé, relu par son auteur, mis en forme, déposé dans l’espace collaboratif et transmis aux personnes concernées. Il apparaît alors comme « terminé » dans le suivi opérationnel.

Pourtant, tant que les acteurs habilités n’ont pas confirmé son contenu, ce livrable ne constitue pas encore une référence commune.

Lorsque cette situation concerne un document isolé, elle semble gérable. Lorsque plusieurs comptes rendus, cartographies, spécifications, matrices ou stratégies de recette restent simultanément en attente, le projet accumule une véritable dette de validation.

Cette dette est rarement visible dans les indicateurs classiques. Elle n’est pas toujours comptabilisée comme un retard et ne provoque pas nécessairement d’alerte immédiate. Elle fragilise néanmoins les décisions, les registres de pilotage et les travaux réalisés en aval.

Qu’est-ce que la dette de validation ?

La dette de validation désigne l’accumulation de livrables produits et diffusés, mais dont le contenu n’a pas encore été formellement accepté, corrigé ou arbitré.

Le terme « dette » est pertinent, car le projet continue souvent d’avancer malgré cette situation. Le travail non réalisé au moment prévu devra être repris plus tard, avec un coût supplémentaire :

  • retrouver le contexte de la discussion ;
  • relancer les participants ;
  • réconcilier des commentaires contradictoires ;
  • corriger les documents dépendants ;
  • réviser le tableau de bord ;
  • rouvrir des décisions supposées acquises ;
  • refaire une partie de la recette ou de la conception.

Comme toute dette, elle donne temporairement l’impression de gagner du temps. Le projet évite d’attendre une validation et poursuit ses travaux. Mais il paie ensuite des intérêts sous la forme de reprises, de contradictions et d’arbitrages tardifs.

Produit, diffusé, relu et validé : quatre statuts différents

Une grande partie du problème vient d’un vocabulaire insuffisamment précis.

Produit

Le livrable existe dans une version exploitable. Son auteur estime avoir traité le périmètre attendu.

Ce statut ne signifie pas que le contenu a été accepté par les métiers, la Finance, la DSI ou le sponsor.

Diffusé

Le document a été transmis aux destinataires ou déposé dans l’espace prévu.

La diffusion prouve que le livrable a été mis à disposition. Elle ne prouve ni sa lecture ni son approbation.

Relu

Une ou plusieurs personnes ont examiné le document et peuvent avoir formulé des commentaires.

La relecture peut révéler des désaccords, des compléments nécessaires ou des points à arbitrer. Elle constitue une étape vers la validation, mais pas toujours son aboutissement.

Validé

Le ou les acteurs disposant de l’autorité attendue ont accepté le contenu, éventuellement après intégration des observations.

La version validée devient alors la référence du projet pour le périmètre concerné. Elle peut alimenter les registres, les décisions, la conception détaillée ou la phase suivante.

L’absence de distinction entre ces quatre statuts crée une ambiguïté dangereuse. Un tableau de suivi peut afficher 100 % de livrables produits alors qu’une part importante de la connaissance projet reste contestable.

Pourquoi la dette de validation reste-t-elle invisible ?

Le planning suit la production, pas toujours l’acceptation

De nombreux plannings contiennent une tâche « rédiger le dossier de conception » ou « transmettre le compte rendu », mais aucune activité spécifique consacrée à la relecture, à la correction et à l’approbation.

La production est donc clôturée alors que le cycle du livrable ne l’est pas.

Les responsabilités sont floues

Un document est envoyé à plusieurs destinataires sans préciser qui doit réellement décider.

Chacun peut considérer qu’un autre acteur répondra. Les commentaires arrivent au fil de l’eau, mais personne ne prononce l’acceptation finale.

Le silence est interprété différemment

Pour l’auteur, l’absence de retour peut signifier que le document est accepté. Pour le destinataire, elle peut simplement signifier qu’il n’a pas encore eu le temps de le lire.

Sans règle connue à l’avance, l’approbation tacite devient une source de contestation future.

Le projet privilégie l’urgence suivante

Les équipes enchaînent les ateliers, démonstrations et échéances. Valider le document précédent semble moins urgent que préparer la prochaine réunion.

La validation est alors repoussée jusqu’au moment où une décision, une recette ou un incident oblige à revenir sur l’historique.

Les conséquences sur le pilotage

Un tableau de bord construit sur une vérité provisoire

Le tableau de bord consolide souvent des informations provenant des comptes rendus, plans d’action et registres de risques.

Si ces sources ne sont pas validées, la synthèse peut être cohérente en apparence tout en reposant sur des éléments non partagés.

Un indicateur vert ne compense pas l’absence d’accord sur le périmètre, la responsabilité ou la date.

Des décisions qui semblent acquises

Une conclusion formulée pendant une réunion peut être reprise comme décision alors qu’un participant clé souhaitait encore vérifier un point.

Plus elle est réutilisée dans d’autres documents, plus il devient coûteux de la corriger.

Des actions contestées tardivement

Une action peut apparaître avec un responsable et une échéance dans un compte rendu diffusé. Si le responsable n’a jamais confirmé l’engagement, la relance révélera le désaccord au moment où l’action est déjà en retard.

Des risques mal qualifiés

La criticité d’un risque, son propriétaire ou son plan de réponse peuvent différer selon les acteurs.

Une consolidation prématurée donne une fausse impression d’alignement et peut orienter le COPIL vers de mauvais arbitrages.

Des travaux aval à reprendre

Une spécification non validée peut être utilisée pour préparer une maquette, un développement ou un scénario de recette.

Lorsque le besoin est finalement corrigé, plusieurs livrables dépendants doivent être repris. La dette de validation devient alors une dette de conception et d’exécution.

La validation est une activité projet à part entière

La validation ne doit pas être traitée comme une formalité située après le « vrai travail ».

Elle exige :

  • du temps dans le planning ;
  • des rôles définis ;
  • des critères connus ;
  • un délai de réponse ;
  • un mécanisme d’arbitrage ;
  • une traçabilité de la décision ;
  • une gestion des versions.

La méthode PM² de la Commission européenne distingue notamment le plan d’acceptation des livrables et la checklist d’acceptation. Elle prévoit également des portes de phase fondées sur une revue et une approbation avant le passage à l’étape suivante. Sources officielles PM².

Cette logique rappelle une règle essentielle : la production d’un livrable et son acceptation sont deux événements de gouvernance différents.

Sept règles pour éviter l’accumulation

1. Identifier le valideur avant de produire

Le responsable de validation doit être connu dès le cadrage du livrable.

Il peut s’agir d’un responsable métier, d’un process owner, de la DAF, de la DSI, du sponsor ou d’une instance collective. L’important est de savoir qui possède l’autorité finale.

2. Définir les critères d’acceptation

Le valideur doit savoir ce qu’il contrôle :

  • couverture du périmètre ;
  • exactitude des règles ;
  • cohérence avec les décisions antérieures ;
  • prise en compte des cas d’exception ;
  • niveau de détail attendu ;
  • conformité au modèle ou aux exigences ;
  • présence des preuves et références nécessaires.

Sans critères, la validation risque de se transformer en appréciation générale ou en nouvelle phase de conception.

3. Prévoir une échéance de validation

La date de production et la date d’acceptation doivent apparaître séparément dans le planning.

Le délai doit être réaliste au regard de la taille du document et de la disponibilité des acteurs. Une validation urgente annoncée au moment de la diffusion est rarement efficace.

4. Utiliser un canal unique pour les commentaires

Les observations dispersées entre courriels, messages instantanés, annotations locales et remarques orales rendent la consolidation difficile.

Le projet doit indiquer où commenter et quelle version relire.

5. Organiser les désaccords

Un désaccord n’est pas un échec de validation. Il révèle un point qui doit être arbitré.

Le document doit distinguer :

  • les corrections factuelles ;
  • les compléments ;
  • les choix encore ouverts ;
  • les décisions nécessitant une autorité supérieure.

6. Définir la règle applicable au silence

Si une approbation tacite est utilisée, elle doit être annoncée à l’avance, avec un délai, une relance et un périmètre adaptés.

Elle ne doit pas servir à imposer silencieusement une décision structurante à un acteur qui n’a pas eu la possibilité réelle de se prononcer.

7. Verrouiller la version de référence

Après validation, la version qui fait foi doit être identifiable : numéro, date, statut et emplacement.

Les versions de travail doivent rester accessibles si l’historique est utile, mais ne doivent pas pouvoir être confondues avec la version approuvée.

Comment représenter la validation dans le tableau de bord ?

Le tableau de bord ne devrait pas afficher uniquement un taux de production.

Il peut distinguer :

  • livrables planifiés ;
  • livrables en préparation ;
  • livrables diffusés pour relecture ;
  • livrables avec commentaires à intégrer ;
  • livrables en arbitrage ;
  • livrables validés ;
  • validations en retard.

Pour les documents structurants, il est utile d’ajouter :

  • le valideur attendu ;
  • la date de diffusion ;
  • la date limite de retour ;
  • l’âge de la demande de validation ;
  • le prochain niveau d’escalade ;
  • les livrables ou jalons dépendants.

Cette présentation rend la dette visible avant qu’elle ne bloque la trajectoire.

Faut-il arrêter le projet tant que tout n’est pas validé ?

Non. Tous les travaux n’ont pas besoin d’être suspendus dès qu’un document attend un retour.

L’enjeu consiste à apprécier la dépendance.

Le projet peut poursuivre des activités réversibles ou indépendantes. En revanche, il doit éviter d’engager une conception coûteuse, un paramétrage, un développement ou une communication définitive sur une hypothèse non acceptée.

Trois situations peuvent être distinguées :

  1. Travail sans dépendance : il peut continuer normalement.
  2. Travail fondé sur une hypothèse réversible : il peut avancer si l’hypothèse est clairement signalée et si le coût de reprise est accepté.
  3. Engagement structurant ou difficilement réversible : il doit attendre la validation ou faire l’objet d’un arbitrage explicite.

Cette approche évite à la fois l’immobilisme et la fuite en avant.

Validation des livrables projet : pourquoi livré ne signifie pas validé

La dette de validation n’est pas un simple problème documentaire.

Elle affecte la qualité des décisions, la fiabilité du reporting, la responsabilité des acteurs et la maîtrise des travaux aval.

Un projet mature ne mesure donc pas seulement sa capacité à produire. Il mesure aussi sa capacité à obtenir des validations claires, traçables et suffisamment rapides.

Avant de consolider un tableau de bord ou de franchir un jalon, une question doit être posée :

La source est-elle seulement disponible, ou est-elle devenue une référence partagée ?

BAZIRE CONSULTING accompagne les directions Finance, les métiers et les DSI dans la structuration de la gouvernance, des livrables, des circuits de validation et du pilotage de leurs projets de transformation Finance & SI.

Sources officielles

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Retour en haut