Classement forcé: pourquoi les projets en souffrent le plus

Le stack ranking détruit la collaboration dans les équipes projet temporaires. Comprendre ses mécanismes et découvrir les alternatives adaptées au mode projet.

Quand Yahoo a instauré son système de Quarterly Performance Review en 2012, l’objectif affiché était d’élever le niveau de performance. Chaque trimestre, les managers devaient classer leurs collaborateurs sur une échelle de 1 à 5, avec des quotas prédéfinis: 10% devaient figurer dans la catégorie la plus haute, 5% dans la plus basse. Ce système de classement forcé (stack ranking, ou forced ranking) n’avait rien d’original. General Electric l’avait popularisé dans les années 1980 sous l’impulsion de Jack Welch, qui licenciait systématiquement les 10% les moins bien classés chaque année. Pourtant, en quelques trimestres, le QPR de Yahoo a produit des effets dévastateurs: poursuites judiciaires, départs massifs de talents, climat de méfiance généralisé.

Un système conçu pour des organisations stables

Le classement forcé repose sur une hypothèse implicite: la performance individuelle peut être isolée, mesurée et comparée de manière fiable au sein d’un groupe stable. Dans un département fonctionnel où les collaborateurs exercent des fonctions comparables sur la durée, cette hypothèse est déjà discutable. Dans une équipe projet, elle est absurde.

Une équipe projet est par nature temporaire, pluridisciplinaire et interdépendante. Le développeur, le juriste et le spécialiste métier qui collaborent pendant six mois sur un même livrable n’exercent pas des fonctions comparables. Leur contribution individuelle est indissociable du résultat collectif. Comparer leurs performances sur une même échelle revient à classer des instruments d’orchestre du plus performant au moins performant: l’exercice n’a pas de sens.

Le talon d’Achille de la matrice

Le problème se complique dans les organisations matricielles, configuration la plus courante pour les projets d’envergure. Le chef de projet observe quotidiennement la performance de ses équipiers, mais c’est le responsable fonctionnel qui rédige l’évaluation annuelle. Cette dissociation entre l’observation et l’évaluation produit deux effets pervers.

Le premier est un biais d’information. Le responsable fonctionnel évalue sur la base d’interactions limitées, souvent réduites aux réunions de service et aux remontées indirectes. La performance réelle en projet, celle qui se manifeste dans la résolution de problèmes transversaux, l’entraide technique ou la gestion des imprévus, lui échappe en grande partie. Le PMI qualifie cette situation de “talon d’Achille du management matriciel”.

Le second est un conflit de loyauté. Puisque le responsable fonctionnel contrôle l’évaluation, la rémunération et la progression de carrière, les membres de l’équipe projet orientent naturellement leurs efforts vers ce qui sera valorisé par leur hiérarchie. Les tâches projet qui ne correspondent pas aux critères d’évaluation fonctionnelle passent au second plan, même si elles sont critiques pour la réussite du projet.

Quand le classement tue la collaboration

Les données empiriques confirment ce que l’intuition suggère. Chez Microsoft, avant l’abandon du stack ranking en 2013, d’anciens cadres ont rapporté que les meilleurs développeurs évitaient délibérément de travailler avec d’autres talents, par crainte d’être désavantagés dans le classement. La collaboration, censée être le moteur de l’innovation, était devenue un risque de carrière.

Ce phénomène est particulièrement destructeur en gestion de projet, où le succès dépend précisément de la capacité des individus à coopérer au-delà de leurs spécialités. W. Edwards Deming, dont les principes de management ont influencé des décennies de pratiques industrielles, préconisait l’abolition pure et simple des évaluations de mérite, qu’il considérait comme un obstacle à la coopération et à l’amélioration continue.

Le déclin d’un modèle

En 2013, 44% des entreprises du Fortune 1000 utilisaient une forme de classement forcé, selon les données du cabinet CEB. En 2015, ce chiffre était tombé à 27%. Accenture, Deloitte, GE elle-même ont abandonné le modèle. Adobe l’a remplacé par un système de check-ins continus et a constaté une baisse de 30% du turnover volontaire en un an.

Pour les équipes projet, cette évolution est une bonne nouvelle, mais elle ne suffit pas. Remplacer l’évaluation annuelle par du feedback fréquent ne résout pas le problème structurel de la matrice si le chef de projet reste exclu du processus d’évaluation. La transformation réelle consiste à reconnaître que la performance en mode projet ne se mesure pas sur une échelle individuelle, mais à travers la capacité d’une équipe à produire un résultat collectif dans un contexte d’incertitude.

Intégrer le feedback dans les rituels projet

Les projets disposent déjà des rituels nécessaires pour pratiquer un feedback continu sans reproduire les travers du classement. Les rétrospectives, les revues de phase et les points d’avancement sont des moments naturels d’observation et de retour. Ce qui manque souvent, c’est un mécanisme formel pour que ces observations alimentent le processus d’évaluation.

Un feedback utile répond à trois conditions: la proximité temporelle (un retour donné dans la semaine, pas six mois plus tard), la spécificité (décrire la contribution précise plutôt qu’une impression générale) et la réciprocité (un feedback qui circule dans tous les sens, pas seulement du haut vers le bas). Les rituels projet réunissent naturellement ces conditions, à condition que le chef de projet les exploite consciemment.

Certaines organisations ont commencé à formaliser cette remontée en intégrant le chef de projet comme contributeur officiel de l’évaluation, avec un poids défini. Ces approches restent minoritaires, mais elles reconnaissent une réalité que le système traditionnel ignore: c’est en projet que la performance se révèle le plus concrètement, et c’est le chef de projet qui est le mieux placé pour l’observer.