10 mars 2012: Piloter les projets de développement : rétroaction plutôt que programmation rigide ex ante

La conception des projets de développement devient de plus en plus rigide. Il faut avoir défini à l’avance les activités, les avoir programmées et budgétées précisément, avoir défini les indicateurs de suivi. Comme si pour atteindre les objectifs prévus, une fois fait le « bon » diagnostic, il suffisait de dérouler mécaniquement la programmation.

Il y a certes des raisons à ces évolutions : on a tous vu des projets très flous, où l’équipe ne sait pas où elle va, où une série d’activités sont menées sans guère de cohérence, et avec des coûts mal maîtrisés sinon des gaspillages ou des détournements. Clarifier la logique interne d’un projet n’est pas inutile, loin de là ! (Neu, 2005).

Mais il faut quand même s’interroger sur cette conception mécanique, qui est doublement contradictoire :
–    elle porte sur des projets aux objectifs de plus en plus sociaux et institutionnels, menés en partenariats, donc de moins en moins « mécaniques » ;
–    elle est complètement à contre-courant des évolutions du management des projets d’innovation industrielle, qui  a vécu dans les années 90 une « révision déchirante du modèle classique » (Garel, 2003: 200), fondé sur la programmation et la séparation des tâches.

Deux points me paraissent essentiels :
–    par définition, un projet cherche à faire advenir des choses nouvelles, il se confronte à l’inconnu, à « l’incertitude qui accompagne inévitablement une démarche consistant à structurer une réalité à venir » (Garel, 2003: 5) ;
–    un projet de développement est « une intervention dans des systèmes dynamiques » (Elwert et Bierschenk, 1988), inscrite dans des jeux d’acteurs. Son résultat est davantage le produit, en partie aléatoire, de ces interactions multiples que la traduction du projet initial .

Bref, comme le disait Hirschman (1967: 35) à propos des projets de développement régional ou industriels des années 60 : dès lors qu’ils sont ancrés dans des environnements, les projets
« are poorly described by the word « project » which implies far more certainty and knowledge that is available (…) The term « implementation » understates the complexity of the task of carrying out projects that are affected by a high degree of initial ignorance and uncertainty. Here « project implementation » may often mean in fact a long voyage of discovery in most varied domains, from technology to politics ».

« L’art du projet est de faire du sur- mesure à partir de l’objectif à atteindre, des caractéristiques propres au secteur où se déroule le projet » (Garel, op. cit, 117). Puisque le futur est incertain,
« l’art du projet implique de susciter les échanges entre tous ceux qu’on a réussi à enrôler, afin de multiplier l’exploration des combinaisons, rechercher les compromis originaux, les points d’accord possibles » (Midler, 2004 (1998) : 68). Pour « se réaliser » (au sens de « devenir réel »),  tout projet doit se redéfinir en fonction de la confrontation à la réalité et en fonction des acteurs qu’il cherche à mobiliser. Le projet avorté de métro automatique Aramis étudié par Latour (1992) en est un exemple remarquable. Dès lors, la programmation ex ante, la séparation des tâches, le suivi ex post, ne fonctionnent pas, ou mal.

Les leçons du management de projet sont sans appel. La plupart des projets industriels ou informatiques connaissent des dérives importantes en termes e coût et de durée. « Partant de l’analyse de divers programmes ayant eu une réussite exceptionnelle quant à leur vitesse de réalisation, la maîtrise des coûts et des objectifs techniques, [un rapport commandité par le Ministère américain de la Défense] constate que ces projets n’ont pas été menés selon les canons des méthodologies projet traditionnelles, mettant l’accent sur l’explicitation poussée des procédures, la complexification des systèmes de reporting, le jalonnement strictement séquentiel des étapes » (idem : 199). « Contrairement à la tendance dominante qui est de rechercher plus d’efficacité par l’emploi d’outils de plus en plus sophistiqués, il a été établi que les variables les plus actives sont liées pour l’essentiel à des facteurs d’organisation et de communication » (Couillard et Navarre, 1993, cités par Garel, p. 108). On peut dire exactement la même chose des projets de développement (Biggs et Smith, 2003) !

Un premier problème du modèle hiérarchique et normalisé des années 70 est que  « on ne peut séparer le processus de formulation du problème du processus de sa résolution ; (…) le travail séquentiel [séparant la conception, la mise au point expérimentale puis la diffusion] conduit à des remises en cause lourdes (…) ; l’engagement du projet de façon irréversible intervient beaucoup trop tôt » (Jolivet, 1998 : 20-21) et ne permet pas un ajustement réciproque, ni la négociation d’une vision partagée entre les acteurs partie prenante, préalable indispensable à une action collective. Elle oblige à définir les objectifs beaucoup trop tôt et enferme dans des sentiers de dépendance, d’autant plus difficiles à corriger que les ajustements dans la mise en œuvre sont eux-mêmes rendus complexes par les procédures contractuelles. Elle accroît l’irresponsabilité, puisque chacun peut aisément reporter sur l’autre la responsabilité des difficultés et revendiquer à son crédit les réussites (Biggs et Smith, op. cit. : 1747).

Un second est « l’inertie de leurs dispositifs de pilotage. Plus tardive est la détection d’un problème, plus long est le délai d’élaboration d’une solution, et moins grands seront les degrés de liberté disponibles pour le résoudre efficacement et à moindre coût » (Garel, p. 100). « Une des raisons qui explique l’inefficacité de ces méthodologies de gestion est que le système de gestion (ou plutôt de contrôle) est bâti sur les connaissances initiales du projet et qu’il en ignore l’inconnu, lequel inconnu va se révéler au fur et à mesure de son développement » (Jolivet, op. cit. : 25). Dès lors, « ces méthodologies constituent un système de contrôle qui constate les dérapages mais ne les évite pas » (idem).

Ce qui est vrai pour les projets d’innovation industrielle (Latour, 1992; Midler, 2004 (1998)) l’est aussi pour les projets urbains des grandes villes européennes (Pinson, 2009). Dans les deux cas, les mots clés sont aujourd’hui construction de réseaux d’acteurs, co-construction du projet au sein de ce réseau et pilotage collectif, itérativité, souplesse. Cela devrait aussi être le cas des projets de développement ! Comme pour toute action publique, la gestion des projets de développement devrait « plus que toute autre doit se méfier d’une pensée qui ne serait que celle des programmes, des objectifs, des cibles et de la stratégie. Dans les contextes d’incertitude marquée, il est souvent préférable de se fier plus à la rétroaction qu’à la programmation » (Duran, 2010 (1999): 188).

Décidément, la conception bureaucratique du management des projets relève bien « d’une épistémologie positiviste largement dépassée » (Giovalucchi et Olivier de Sardan, 2009: 383). N’est-il pas temps qu’elle fasse aussi sa « révision déchirante du modèle classique  », au profit d’une conception processuelle (Korten, 2006), qui est à l’heure actuelle l’exception ? Pourtant, ses fondements sont là, en termes pratiques dans les savoir faire d’un certain nombre de praticiens, en termes théoriques dans la socio-anthropologie du développement, la sociologie de l’action publique, la sociologie du management de projet.

Cliquez sur ce ficher pdf! Piloter les projets

Références

Biggs S. et Smith S., 2003, « A Paradox of Learning in Project Cycle Management and the Role of Organizational Culture », World Development, vol 31 n° 10, pp. 1743-1757.

Couillard J. et Navarre C., 1993, « Quels sont les facteurs de succès des projets ? résultats d’une enquête menée à partir d’un échantillon de projets militaires canadiens », Gestion 2000, vol 2, pp. 167-189.

Duran P., 2010 (1999), Penser l’action publique, Paris, LGDJ.

Elwert G. et Bierschenk T., 1988, « Development Aid as An Intervention in Dynamics Systems », Sociologia Ruralis, vol 28 n° 2/3, pp. 99.

Garel G., 2003, Le management de projet, Coll. Repères, Paris, La Découverte.

Giovalucchi F. et Olivier de Sardan J.-P., 2009, « Planification, gestion et politique dans l’aide au développement : le cadre logique, outil et miroir des développeurs », Revue Tiers-Monde, vol 198, pp. 383-406.

Hirschmann A. O., 1967, Development projects observed, Washington D.C., The Brookings Intitution.

Korten D., 2006, L’intervention sociale comme processus d’apprentissage, Coopérer aujourd’hui n° 48, Paris, GRET, 41 p.

Latour B., 1992, Aramis ou l’amour des techniques, Paris, La Découverte.

Midler C., 2004 (1998), L’auto qui n’existait pas. Management de projets et transformation de l’entreprise, Paris, Dunod.

Neu D., 2005, Représenter la logique d’un projet pour mieux en débattre : un outil pour faciliter la conception, la présentation et la conduite d’un projet. Les tableaux logiques simplifiés, Tome 1, Coopérer aujourd’hui n° 43, Paris, GRET, 45 p.

Pinson G., 2009, Gouverner la ville par projet. Urbanisme et gouvernance des villes européennes., Coll. Collection Gouvernances, Paris, Presses de Sciences Po.

Advertisements

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s