À la fin d'un projet, un verdict est presque toujours rendu : réussi, partiellement réussi, échoué. Ce qui frappe, c'est la fréquence à laquelle les critères de ce verdict ne prennent forme qu'au moment même où le verdict est rendu. On regarde en arrière ce qui a été livré, et c'est à partir de là qu'on détermine ce que "réussite" était censé signifier. Ce n'est pas une évaluation — c'est une justification a posteriori, et le résultat est déjà figé avant même que la question soit posée.
Un élément constitutif parmi quatre cadres indépendants
Quatre cadres d'évaluation autonomes — l'OCDE-CAD (un cadre largement appliqué et transposable, développé à l'origine pour la coopération au développement), la revue Gate 5 britannique, la pratique PRINCE2 et le modèle CIPP de Stufflebeam — sont arrivés indépendamment aux mêmes éléments constitutifs. L'un d'eux : des critères fixés à l'avance, et non complétés après coup. Aux côtés de la vérification des bénéfices par rapport à la promesse initiale et de la validation indépendante, c'est l'un des éléments récurrents vers lesquels ces cadres convergent chacun de leur côté.
La logique est simple. Dès lors que les critères ne sont formulés qu'après la livraison, aucune comparaison réelle n'est plus possible entre la promesse et le résultat — il ne reste qu'une description du résultat lui-même, colorée par ce qui a justement été livré.
Pourquoi cela tourne mal dans la pratique
Au démarrage d'un projet, la réussite est souvent décrite de façon vague : "un système qui fonctionne", "des utilisateurs satisfaits", "dans les délais et le budget" — sans que soit consigné ce que cela signifie concrètement, ni quand cela sera vérifié. Le temps que le projet se termine, le contexte a changé, le périmètre a été ajusté, de nouvelles parties prenantes sont apparues — et la définition de la "réussite" s'y adapte. Non par mauvaise foi, mais parce qu'il n'y a jamais eu de point de référence fixe pour s'y confronter.
Le résultat est une évaluation qui confirme surtout ce que l'on savait déjà, plutôt que de tester quoi que ce soit. La réalisation des bénéfices en est l'exemple le plus clair : si l'on n'a jamais consigné à l'avance quels bénéfices devaient se matérialiser et à quel moment, il est impossible après coup d'établir s'ils se sont réellement produits.
Ce que cela exige concrètement
Des critères fixés à l'avance ne signifient pas un épais document rédigé au lancement et jamais reconsulté. Cela suppose trois choses réalisables en pratique :
- Consigner ce qui mesure la réussite, pas seulement ce que le projet livre. Une liste de livrables n'est pas un critère de réussite ; une norme à laquelle ces livrables sont confrontés, si.
- Consigner à quel moment cela sera vérifié. Certains bénéfices ne deviennent visibles que des mois après la livraison — ce moment doit déjà figurer au calendrier dès le départ, et non être inventé une fois la question devenue d'actualité.
- Ne pas modifier les critères en silence. Le périmètre et les circonstances évoluent souvent, légitimement, en cours de projet. Si les critères doivent en conséquence être ajustés, cet ajustement doit lui-même être consigné et justifié — et non disparaître discrètement dans le rapport final.
Aucune garantie, mais une condition
Que quatre cadres indépendants désignent chacun de leur côté cet élément comme constitutif ne signifie pas qu'un projet doté de critères fixés à l'avance se déroule automatiquement mieux, ni qu'une évaluation intégrant cet élément débouche démontrablement sur de meilleurs projets suivants. Ce que cela signifie, en revanche : sans critères fixés à l'avance, une évaluation après coup n'est rien de plus qu'un résumé assorti d'un chiffre. La question de savoir si un projet a réussi ne peut alors jamais recevoir de réponse honnête — parce que personne n'a consigné à l'avance ce que cette réponse était censée démontrer.
EvaluatieScore confronte un projet à ses propres critères de réussite, consignés ou non, pour 15 € : dutchmind.com/producten/evaluatiescore.
Sources
- OECD DAC Network on Development Evaluation (EvalNet) (2019), Evaluation Criteria (herzien, DCD/DAC(2019)58 FINAL) — one.oecd.org.
- HM Government / Cabinet Office–IPA (nu NISTA) (2021), Gate 5: Operations Review and Benefits Realisation (Assurance Portfolio Standard, V1.0) — assets.publishing.service.gov.uk.
- PRINCE2-praktijk — End Project Report en Lessons Report Template (prince2.wiki, secundaire bron, geen officiële AXELOS-manual).
- Stufflebeam, D.L. (2015), CIPP Model checklist (2e ed.) — rszarf.ips.uw.edu.pl.