Les articles de votre blog ici ? Inscrivez votre blog !

Contre les méthodes de conduite de projet

Publié le 06 janvier 2008 par Lbloch

Ce texte est extrait de mon livre Systèmes d'information, obstacles et succès, paru en mars 2005 aux Éditions Vuibert. Avec l'aimable autorisation de l'éditeur.

Page d'accueil de ce livre

#Sommaire-

Projet et cahier des charges

Jean-Pierre Boutinet [1] nous guidera ici pour ce qui concerne l'histoire de la notion de projet. Ce terme apparaît d'abord dans le contexte architectural pour désigner un élément de construction situé en avant de la façade, mais le premier projet au sens moderne est dû à Filippo Brunelleschi, créateur du Duomo de Florence, Santa Maria del Fiore, au début du XVe siècle. Auparavant les constructions de grande ampleur étaient réalisées par un concours pas toujours très ordonné de maçons, de charpentiers, de couvreurs, de sculpteurs, etc., sous la direction d'un architecte. On peut certes déjà identifier de grands maîtres d'ouvrage, comme l'abbé Suger pour la basilique de Saint-Denis, ou de grands architectes comme Villard de Honnecourt, mais Brunelleschi a voulu une démarche plus formalisée, au moyen d'un document écrit et dessiné préalable à toute exécution afin de limiter l'autonomie des corps de métier impliqués dans la réalisation [2]. Ce document sera nommé le cahier des charges du projet. Il semble que ce soit grâce à cette démarche centralisée et rationnelle et à la division du travail qui en découlait qu'ait été rendue possible la prouesse architecturale constituée par la coupole de la cathédrale de Florence.

Nous retrouverons ces notions de projet et de cahier des charges parmi les méthodes envisagées pour mener à bien la réalisation de systèmes informatiques.

Il est clair qu'il semble judicieux, avant de commencer un travail de quelque ampleur, de savoir le mieux possible ce que l'on veut faire. Le consigner par écrit ne peut qu'aider, surtout si le travail doit ensuite être réalisé par plusieurs personnes, éventuellement liées les unes aux autres par des contrats. Vérifier à intervalles réguliers par des procédures elles-mêmes écrites que ce qui est fait correspond bien à ce qui avait été décidé ne devrait que contribuer au succès.

Jean-Pierre Boutinet nous indique par ailleurs ceci : « La gestion par projet se veut être un mode original de gouvernement qui vise à déterminer les meilleures conditions dans l'implantation d'une innovation au sein d'un ensemble organisationnel, qu'il s'agisse d'une innovation technologique, d'une innovation comptable, d'une innovation sociale ... Au lieu de faire transiter l'innovation en cause par la hiérarchie, on la confie directement à une équipe autonome, qui aura la plus large latitude pour intégrer cette innovation aux secteurs concernés de l'entreprise. » Et Juliette Poupard [3] ajoute : « Ainsi l'organisation par projet est-elle censée dépasser les limites de l'organisation pyramidale classique et proposer des dispositifs de travail propres à encourager la coopération transversale entre les acteurs. » Comment ne pas approuver un programme aussi intelligent ?

Alors pourquoi cette démarche en apparence si rationnelle et sage échoue-elle si souvent à éviter l'échec dans le domaine de l'informatique de gestion ?

Avant d'entrer dans le vif de ce sujet, rappelons que nous avons réparti les systèmes informatiques en trois classes, ceux qui sont destinés à faire fonctionner les systèmes d'information des organisations (classe 1), ceux qui assurent la commande et le contrôle des systèmes techniques (classe 2) et ceux de la classe 3 qui constituent des infrastructures informatiques. Le présent ouvrage est essentiellement consacré aux systèmes de la première classe, et il n'y sera question de ceux des autres classes qu'incidemment.

La frontière entre conception et fabrication

La vision classique de la conduite d'un projet informatique de gestion est la suivante : le maître d'ouvrage élabore (ou fait élaborer) un cahier des charges, complété par un document de spécifications détaillées qui décrit par le menu les fonctions qui devront être assurées par le logiciel à réaliser. Avec le bon à tirer des spécifications détaillées se clôt la phase de conception. Le maître d'œuvre, choisi à l'issue d'un appel d'offres pour la qualité de sa réponse au cahier des charges, entreprend la phase de fabrication du logiciel conformément aux spécifications détaillées. Il suffit, à chaque étape du travail, de vérifier la conformité aux spécifications pour que tout se passe bien, et qu'à la fin le logiciel livré soit satisfaisant. Cette vision, bien résumée par le schéma de la figure 2.1, est particulièrement ancrée dans l'administration, et de façon générale elle plaît aux managers qui pensent parfois qu'une incompétence technique distinguée, en les plaçant « au-dessus de la mêlée », leur évite les partis-pris qui seraient le lot des simples ingénieurs. Eh bien la technique se venge : la démarche que nous venons de décrire échoue, et ne peut qu'échouer, parce qu'elle repose sur une erreur.

Quelle est cette erreur ? C'est de croire que les spécifications détaillées constituent la conception, et que la rédaction du texte des programmes dont se composera le logiciel constitue la fabrication. Comme l'ont bien mis en lumière les auteurs du livre L'eXtreme Programming [4],

la rédaction du texte des programmes, en un mot la programmation, appartient intégralement au travail de conception. Ce qui correspond à la fabrication, c'est la traduction des programmes en langage machine et leur assemblage, opérations réalisées par des logiciels. Le chapitre 4 apportera des précisions à ce sujet.

Dès lors que la programmation est reconnue comme une activité complexe qui demande de la créativité, il est clair qu'elle va soulever des problèmes inédits qui vont nécessiter de revenir sur les spécifications pour les modifier, et donc que le scénario proposé ci-dessus ne peut pas aboutir au succès. À plus forte raison, si la programmation change de statut pour passer de la phase de fabrication (sous-entendu, de travail simple facile à quantifier) à la phase de conception, toute méthode qui repose sur le scénario en question est vouée à l'échec. Et si de plus le projet est encadré par un règlement tel que le Code des Marchés Publics, qui interdit toute discussion entre les auteurs du cahier des charges et les responsables de la programmation avant la remise du cahier des charges, qui ensuite est figé contractuellement, les dernières chances de succès s'évanouissent à l'horizon, d'autant plus qu'au fil des deux ou trois années que dure la réalisation d'un projet informatique les desiderata de l'utilisateur final auront de toute façon changé — souvent à un point tel d'ailleurs que le projet formulé initialement n'a plus aucun intérêt pour lui — et que le scénario n'envisage aucune façon d'en tenir compte. Hélas pour le contribuable...

Bâtiment, mécanique, programmation : le démon de l'analogie

Nous y reviendrons au chapitre 4, mais nous savons déjà que la mise en œuvre de l'informatique s'est beaucoup inspirée des procédures de travail les plus élaborées du XXe siècle, qui étaient celles de l'industrie mécanique. Celle-ci disposait d'un outil de conception, le dessin industriel, qui permettait la séparation entre conception et fabrication tout en assurant la transmission précise des spécifications et des consignes de l'une à l'autre. L'informatique a toujours cru manquer d'un tel outil de conception, et a fébrilement cherché à s'en doter, de la méthode Merise à UML (Unified Modeling Language). En fait, elle possède des outils de conception, sous la forme des langages de programmation, mais ils semblent de trop bas niveau aux yeux de certains maîtres d'ouvrage, alors que si la programmation des ordinateurs s'avère plus difficile, beaucoup plus difficile que le dessin industriel, c'est tout simplement parce que la spécification d'un logiciel est beaucoup plus complexe que celle d'un appareil mécanique.

Quelques années après l'analogie entre l'industrie mécanique et l'informatique, la métaphore architecturale est apparue. Il faut reconnaître qu'elle n'est pas dépourvue de séductions. Pour l'architecte qui dessine un bâtiment, le plus important, ce ne sont pas les pièces, mais les moyens de circuler entre elles : escaliers, couloirs, vestibules et patios, munis des portes et fenêtres qui conviennent. De même pour l'urbaniste ce sont les rues, places, rond-points, ponts et tunnels qui organisent un espace où il plantera les immeubles. Cette façon de voir les choses n'est pas sans intérêt pour l'informaticien, qui sera bien avisé de s'en inspirer pour organiser la division de son programme en sous-programmes en tenant compte des données qu'ils auront à s'échanger. Le chapitre 4 traitera ce sujet. L'analogie avec le bâtiment permet aussi d'introduire le couple maître d'ouvrage — maître d'œuvre, en oubliant curieusement l'architecte au passage, et de renforcer le rôle du cahier des charges.

Finalement ces deux analogies ont surtout engendré des erreurs. Un objet mécanique, comme un bâtiment, est un objet physique que l'on peut dessiner (que ce soit avec un crayon ou avec un ordinateur) de façon précise. Le dessin pourra être montré au maître d'ouvrage, pour qui l'on pourra aussi fabriquer des maquettes. J'ai eu un professeur de dessin industriel qui nous parlait avec mépris du dessin en perspective, destiné selon lui aux mécaniciens, incapables à l'en croire de comprendre un vrai dessin selon les trois axes. Incidemment, ma courte expérience du dessin industriel (le vrai, selon trois axes) m'a suggéré que le processus d'abstraction auquel il soumettait son objet n'était pas sans parenté avec la programmation.

À la différence des bâtiments et des automobiles, les logiciels ne sont pas des objets physiques, ils sont même parfaitement invisibles, comme l'a remarqué F. P. Brooks [5] ;

les moyens qui ont été imaginés pour les dessiner n'ont jamais été satisfaisants. Dans les années 1960 ce fut l'ordinogramme, auquel succéda, avec la programmation structurée des années 1970, le diagramme arborescent, pour céder la place vingt ans plus tard au diagramme UML (Unified Modeling Language) inspiré de la programmation par objets des années 1990 : ces procédés seront évoqués plus longuement au chapitre 5, mais il est d'ores et déjà possible de dire qu'ils n'ont jamais pu prétendre au rôle joué par le dessin industriel pour l'industrie mécanique. Et, lorsqu'ils s'en rapprochaient, c'était au prix d'une complexité équivalente à celle de l'écriture du programme, ce qui dissuadait les programmeurs de s'en servir ; alors que l'avantage du dessin, c'est qu'il est beaucoup plus facile à réaliser que l'objet lui-même : moins d'énergie, moins de matière, moins de temps et moins d'argent.

Mais comme justement les logiciels ne sont pas des objets physiques, dont on pourrait montrer une maquette au donneur d'ordres, ils ont les avantages de l'abstraction.

Imaginons que l'on veuille construire un bâtiment sans très bien savoir dès le départ combien d'étages il aura. On va commencer par creuser des fondations pour une cabane de jardin, construire la cabane, puis imaginer de lui ajouter un étage, et ainsi de suite jusqu'à cinq ou six étages : le lecteur sent bien que ce n'est pas la bonne démarche, parce qu'ajouter de la profondeur aux fondations n'est pas facile à première vue, c'est même sans doute impossible, et il en va de même si l'on veut renforcer les murs porteurs. Bref, la législation du permis de construire est là pour interdire une telle démarche, et dans les pays où l'absence d'une telle législation n'est pas compensée par le respect de règles ancestrales issues de l'expérience, et où l'on construit ainsi, les accidents provoqués par les écroulements d'immeubles sont monnaie courante.

Eh bien cette démarche si inappropriée pour un bâtiment convient très bien pour un logiciel. Je me risquerai même à dire que c'est la meilleure, et que tous les logiciels vraiment bons ont été réalisés ainsi.

Pour résumer, par rapport au bâtiment ou à l'automobile, le logiciel possède une complexité de nature différente : il s'agit d'une complexité abstraite, plus difficile à maîtriser par l'imagination qui se trouve ici privée du secours que pourraient lui apporter dessins et maquettes. Décrire dans un document le détail de ce que sera un logiciel est une entreprise beaucoup plus difficile que pour un objet concret ; de plus le délai nécessaire pour la mener à bien est si long qu'entre-temps les desiderata du maître d'ouvrage auront changé.

Cycle de vie du logiciel

Une vision managériale périmée : le cycle en V

Mais si le logiciel offre une complexité plus difficile à appréhender que celle d'un objet matériel, il présente les avantages qui découlent de son caractère abstrait : il est infiniment malléable. Il est donc possible d'en réaliser une version préliminaire rudimentaire, livrée au maître d'ouvrage qui pourra l'essayer, découvrir d'ailleurs à cette occasion que ses besoins n'étaient pas ceux qu'il imaginait, et faire part de ses remarques et suggestions, qui donneront lieu à une nouvelle version plus élaborée, et ainsi de suite.

Procéder ainsi suppose évidemment que le maître d'ouvrage collabore très étroitement avec l'équipe de conception, et que l'activité de conception, comme le suggèrent les adeptes de l'eXtreme Programming [3], mais contrairement aux habitudes, englobe la programmation. Une telle démarche postule aussi un dispositif contractuel fondé sur la confiance mutuelle et un cahier des charges léger, ce qui n'est pas toujours possible, notamment dans un contexte de Marchés Publics, mais sans doute plus facile à obtenir dans le cas d'une réalisation par des équipes de la même société que le maître d'ouvrage.

Il est clair que cette démarche, que nous examinerons plus en détail au chapitre 5, est impossible si l'on adopte le cycle de développement « en V » hérité des métiers du bâtiment et préconisé par les méthodes traditionnelles. La figure 2.1 reproduit le schéma traditionnel de ce cycle, qui se parcourt en commençant en haut à gauche par la spécification des choses à faire, et en terminant en haut à droite par la recette du projet. Entre-temps on aura procédé, par étapes aussi bien séparées que possible, à la conception globale, puis à la conception détaillée, enfin au « codage ».

Cycle de développement « en V » du logiciel selon la vieille école.

Ces différentes étapes seront confiées, au moins pour un projet important, à des personnes différentes, de rang hiérarchique décroissant au fur et à mesure que l'on descend le long de la branche de gauche du V. On remarque que l'activité de programmation, dévaluée par l'emploi du terme péjoratif « codage », qui suggère une transcription mécanique sans intelligence d'un document pourvu de « contenu », est, tout en bas, confiée à des tâcherons. Chaque rectangle de la branche de gauche, à l'exception du « codage », a sa contrepartie sur la branche de droite : le respect par le « codage » des prescriptions issues de la conception détaillée est validé par les tests unitaires, l'intégration vérifie que les « livrables », validés par les tests unitaires, s'assemblent bien selon le plan prévu par la conception globale, enfin les hauts responsables prononcent la recette en faisant vérifier que l'ensemble correspond aux spécifications émises initialement. Typiquement, la maîtrise d'ouvrage rédigera les documents de spécification et de recette (les deux rectangles qui occupent les sommets des branches du V), la maîtrise d'œuvre sera chargée des tâches indiquées dans les rectangles inférieurs.

On observe que ce schéma, inspiré d'ouvrages destinés à des responsables de projets informatiques, ne fait apparaître nulle part de rôle dévolu à l'architecte.

Tout l'ensemble de l'édifice repose sur le socle de l'assurance qualité, qui définit les procédures d'acceptation des livrables aux différents étages de la branche de droite. Les colonnes de la gestion de projet et de la gestion des configurations sont sans doute là pour éviter le basculement de l'édifice. L'assurance qualité et la gestion de projet incombent tant à la maîtrise d'ouvrage qu'à la maîtrise d'œuvre, cependant que la gestion des configurations est du seul ressort de la seconde.

Cette démarche semble empreinte de bon sens, et elle l'est d'ailleurs, à condition qu'elle soit adoptée avec modération. Il est bien sûr préférable de définir l'objet à réaliser avant de commencer à le fabriquer et, si plusieurs équipes d'entreprises différentes doivent participer au projet, il est souhaitable que les missions des uns et des autres soient délimitées avec autant de précision que possible. S'il s'agit d'un objet matériel, bâtiment ou machine, le respect de ces règles est même indispensable, parce qu'il sera difficile de changer d'avis quant au plan d'un bâtiment au moment d'attaquer le deuxième étage.

Mais s'en tenir de façon rigide à ce schéma pour un projet informatique présente trois inconvénients et risque de conduire son adepte à quatre erreurs.

Les trois inconvénients du cycle de développement en V

La liste qui suit ne saurait être exhaustive, mais les trois faiblesses de la démarche traditionnelles énumérées ci-dessous nous paraissent emblématiques.

  1. S'obliger à terminer chaque étape de la branche de gauche du V avant d'entamer la suivante, et s'interdire d'y revenir, c'est se priver de l'avantage principal du logiciel par rapport au bâtiment : on peut modifier le plan et les fondations au moment d'attaquer le deuxième étage ! Il ne faut pas abuser de cette latitude, elle a bien sûr un coût, mais il n'y a aucune raison de s'interdire d'en profiter.
  2. Un projet informatique, même de taille modeste, peut difficilement être mené à bien en moins d'un an. Le temps moyen de réalisation d'un progiciel commercial est de l'ordre de sept ans. Le système d'information, auquel il est destiné, n'est pas de la même nature qu'un bâtiment ou qu'une automobile. Lorsqu'un bâtiment est terminé, il restera tel qu'il est pendant des dizaines ou des centaines d'années. Lorsqu'un modèle de voiture entre en production sur une chaîne construite à cet effet, il ne subira pas de modification importante pendant quelques années. Le système d'information est, et doit être, plus malléable. Un logiciel de comptabilité ou de gestion de paie doit s'adapter aux variations de la réglementation ou à l'apparition de nouvelles technologies d'accès aux données telles que le WWW. Si les équipes de la maîtrise d'œuvre ont travaillé imperturbablement pendant trois ans sur la base des spécifications initiales, il est à peu près sûr que le logiciel livré à l'issue de la recette sera déjà périmé.
  3. Non seulement le logiciel livré sera inadapté, mais la spécification qui l'aura engendré aura coûté trop cher. Puisque le cahier des charges est immuable, il aura été élaboré avec le plus grand soin. Dans le contexte des marchés publics français, par exemple, lorsque le maître d'ouvrage constate avec dépit lors de la recette que ce qui est livré est conforme aux spécifications, et doit donc être payé au prestataire qui livre, et que pourtant c'est inutilisable parce qu'entre-temps le contexte a changé, il rédige un avenant au marché pour adapter le logiciel aux nouvelles circonstances. Il se fait alors tancer par les bureaucrates chargés du contrôle, qui lui disent qu'« il aurait dû prévoir ». Prévoir quoi ? Un changement de majorité parlementaire qui a entraîné des modifications de la fiscalité ou du droit social ? Cette exigence est bien sûr stupide, mais pour la satisfaire le maître d'ouvrage va désormais élaborer des cahiers des charges d'un niveau de détail exagéré, qui spécifieront des logiciels excessivement paramétrables, donc lourds, complexes et trop chers. Tout cela est d'ailleurs vain, puisque la vie se chargera de toute façon de créer des cas de figure imprévus.

Les quatre erreurs dans la conduite de projet

Pas plus que pour les trois inconvénients, cette énumération des quatre erreurs n'épuise le sujet, toutefois elle met l'accent sur les raisons les plus importantes qui militent en faveur d'un renouvellement des méthodes.

  1. Comment le maître d'ouvrage, angoissé à juste titre par l'idée d'avoir à rédiger des spécifications pour un système destiné à être mis en place plusieurs années plus tard, va-t-il essayer de rédiger un cahier des charges à l'épreuve de tous les événements prévisibles ou imprévisibles ? C'est là qu'il tombe le plus souvent dans l'ornière que lui conseillent d'ailleurs tous les bons auteurs : l'« analyse de l'existant ». Cette activité en apparence innocente rassure les chefs de projet angoissés devant les incertitudes de l'avenir et les subtilités de technologies qu'ils ne connaissent souvent pas suffisamment. Or l'existant c'est l'organisation issue du passé que l'on veut justement remplacer. Il serait idiot de l'ignorer totalement, mais lui consacrer trop de temps peut avoir une influence néfaste. Pire : la rédaction des spécifications est souvent confiée à des personnes issues du terrain, ancrées dans les pratiques du passé sur lesquelles elles n'ont pas un regard suffisamment critique. Dans ce cas, et il est courant, le cahier des charges va consister en l'énumération de ces procédures, qu'il faudrait justement réformer. La démarche du projet, loin de déboucher sur une rénovation du système d'information, va durcir et ossifier des pratiques qui n'étaient jusque là que de mauvaises habitudes et dont l'énoncé va désormais être gravé dans le marbre du cahier des charges. Le projet aura débouché sur un renforcement de la bureaucratie et des dispositifs paralysants.
  2. Une autre mauvaise pratique prend généralement son essor à peu près au même moment dans la chronologie du projet : le « recensement (ou l'expression) des besoins ». Le lecteur pourrait croire à un paradoxe : il est évident que l'on ne construit pas un système d'information juste pour le plaisir, et qu'il est préférable d'avoir une idée de l'objectif poursuivi. Mais trop souvent la pratique qui se donne cours sous ce prétexte ne sert en rien à éclairer la cible visée, mais plutôt à recueillir les opinions et desiderata hétéroclites de personnes plus ou moins reliées à l'activité concernée, et à embrouiller la marche à suivre dans un galimatias de motivations privées ou collectives plus ou moins incohérentes. De toute façon, lorsque viendra le jour de la recette, ces motivations auront complètement changé et les personnes consultées (si elles n'ont pas de toute façon changé d'affectation dans l'entreprise) ne seront pas satisfaites. Bien sûr ce tableau peut varier selon le contexte : dans une entreprise de taille moyenne dirigée par son propriétaire, la personne habilitée à énoncer le besoin est bien identifiée et, surtout, il y a de bonnes chances pour qu'elle agisse de façon conséquente par rapport aux décisions qu'elle aura prises, puisque c'est son argent qui sera engagé — et s'il n'en est pas ainsi, la conséquence sera en quelque sorte morale, parce que celui qui aura commis l'erreur en sera la victime. À l'autre bout du spectre, dans une administration publique en proie à la concertation compulsive, savoir ce que l'on veut vraiment faire est à peu près impossible, et il faut reconnaître que certaines commissions de fonctionnaires risquent d'être prêtes à ne pas reculer devant des décisions incohérentes, d'autant plus que leurs membres n'encourent aucun risque personnel pour les inconvénients qui pourraient en découler. Il est d'ailleurs reconnu depuis longtemps par les spécialistes des organisations que la prise de décision collégiale, loin d'engendrer la modération des décisions, suscite la montée aux extrêmes par un emballement rhétorique que ne vient contrebalancer aucune angoisse devant des responsabilités futures qui seront de toute façon assumées par d'autres ; les deux attitudes en jeu dans ce phénomène sont l'illusion d'unanimité ou au contraire la polarisation conflictuelle, on en trouvera une analyse bien documentée sous la plume de Christian Morel [6].

    La démarche d'expression des besoins peut être fautive de façon encore plus patente : considérons un établissement de recherche de taille moyenne, composé d'une direction générale qui regroupe quelques centaines de personnes et des unités de recherche qui regroupent quelques milliers de chercheurs. Les départements de la direction générale, pour accomplir leur mission d'administration de la recherche, désirent, et c'est peut-être légitime, se doter d'un système d'information pour savoir ce que font tous ces chercheurs. Si on les interroge pour qu'ils expriment leurs besoins, nul doute que l'on obtienne une longue liste d'informations, sûrement pertinentes d'ailleurs. Mais qui va devoir fournir ces informations ? Les chercheurs, déjà submergés de tâches administratives dont l'utilité leur semble obscure, et qui risquent de mal accueillir ces nouveaux formulaires à remplir à propos de tout et du reste. L'expression des besoins sera ici franchement nuisible. Nous verrons dans un chapitre ultérieur l'exemple d'une enquête statistique, exercice analogue à celui que nous évoquons ici en cela qu'il y faut, comme ici, commencer par déterminer quelles sont les informations qui pourraient être accessibles sans trop de difficulté, puis convaincre leurs détenteurs de bien vouloir les donner — sans la prise en considération de cette nécessité nulle expression des besoins ne peut donner le moindre résultat.

  3. Les deux erreurs ci-dessus, conjuguées entre elles, peuvent être utilement complétées par une attitude intellectuelle qui semble de prime abord assez saine, mais qui va se révéler comme une nouvelle erreur : le souci d'exhaustivité. Prenons comme exemple un projet de sécurité informatique destiné à évaluer et à améliorer la disponibilité d'un système d'information. Le responsable du projet pourra par exemple s'inspirer de la méthode EBIOS élaborée en France par la Direction centrale de la sécurité des systèmes d'information (DCSSI). Une telle méthode le conduira à dresser une liste des risques, à associer chacun de ces risques à des vulnérabilités, et à envisager les contre-mesures qu'il peut élaborer pour s'en prémunir, selon une formule pleine de bon sens et d'utilité :

    Cette conceptualisation est intéressante, mais elle peut engendrer la tentation de dresser une liste de risques ou une liste de vulnérabilités que l'on placera dans la colonne de gauche d'un tableau, afin d'en remplir la colonne de droite avec les contre-mesures appropriées.

    Pourquoi cette démarche est-elle maladroite ? Parce que les risques et les menaces sont nombreux et souvent inconnus, alors que le répertoire des contre-mesures possibles est beaucoup plus réduit ; souvent, cela peut se résumer à cinq ou six grands thèmes : plan de sauvegarde des données, amélioration du stockage, aménagement d'un site de secours avec duplication des données à distance, administration correcte des serveurs (fermeture des services inutiles, séparation des privilèges, application des correctifs de sécurité, surveillance des journaux), sécurisation du réseau (pare-feu, authentification forte, fermeture des services inutiles), sécurisation physique des locaux. Il est donc plus simple et plus efficace de partir de la table inverse de la précédente : mettre les contre-mesures dans la colonne de gauche, et énumérer dans la colonne de droite les risques éliminés par elles, ce qui évitera de payer un consultant pendant des mois pour élaborer la liste des centaines de risques plus ou moins réels que l'on peut envisager.

    Cette démarche prétendue exhaustive qui consiste à examiner de longues listes d'items pour cocher des cases dans la colonne d'en face, c'est la façon de travailler des ordinateurs, rapides, systématiques et mécaniques ; l'intérêt du travail d'un professionnel compétent par rapport à l'ordinateur, c'est que l'homme réfléchit, a des idées et des connaissances, il est capable d'en tirer parti pour éliminer les cas non pertinents et regrouper les cas similaires de façon à leur appliquer le même traitement, bref il est capable d'avoir une vue synthétique des choses. Réduire le travail humain à des procédures de type informatique est tout à fait contre-productif.

  4. Les trois erreurs ci-dessus peuvent se combiner avec d'autres pour engendrer une méta-erreur encore plus stérilisante : la rédaction d'un Schéma Directeur du Système d'Information. Dans les administrations publiques, commettre cette erreur est une obligation réglementaire. Que le lecteur ne se méprenne pas : mener une réflexion sur les objectifs à moyen terme qu'il semble raisonnable de fixer au Système d'Information ne peut être qu'une bonne pratique, et le faire régulièrement une saine discipline. Mais ce n'est pas de cette oreille que l'entendent les instances de contrôle de l'administration, pour qui l'édification d'un Système d'Information ne saurait être qu'une charge. D'ailleurs le système de comptabilité publique n'offre aucun moyen de prendre en considération la valeur du capital dont la puissance publique se sera dotée en contrepartie de cette dépense [7]. Dans ces conditions, le Schéma Directeur a surtout le rôle de digue destinée à fixer des limites durables aux projets informatiques, et par là à limiter la dépense. Le contribuable qui lit ces lignes pourra penser que limiter les dépenses des administrations n'est peut-être pas une mauvaise chose. Sans doute, mais dans un domaine où l'innovation technique est non seulement foisonnante, mais encore porteuse de réductions de coût soutenues, figer pour plusieurs années le périmètre des développements et, surtout, le catalogue des technologies mises à contribution pour les entreprendre, c'est se donner la certitude de payer trop cher, avec un surcoût de plus en plus important au fur et à mesure que passent les années. Nous avons là un nouvel exemple d'une pratique qui semble de bon sens, alors que sa mise en œuvre sans prise en compte des caractéristiques réelles des objets auxquels elle s'applique, par défaut de compétence technique, aboutit très souvent (et pas seulement dans l'administration) à un résultat opposé à celui qui était espéré.

Évidemment, pour la bureaucratie tout ira très bien, les choses seront bien en ordre, même si elles ont coûté en fait beaucoup trop cher, mais comment le savoir, puisque l'on n'y connaît rien ?

La vraie nature de la conduite de projet

Comment détruire votre informatique

Au début de ma carrière, entre la fin des années 1960 et 1972, à l'INSEE, j'ai eu l'occasion d'assister à une réorganisation de l'informatique par un prestigieux cabinet de conseil qu'à la suite d'Émile Landormy [8] j'affublerai du nom d'Alex Andréiev afin de rétablir envers les peuples slaves un équilibre compromis par les noms tous anglo-saxons des prestigieux cabinets. Avant la réorganisation, le Département Informatique fort de près de cent cinquante personnes était regroupé dans un bâtiment unique du sud de Paris (rue Boulitte). Les opérateurs y côtoyaient de vrais théoriciens de l'informatique, et de cette ambiance assez désordonnée émanaient une véritable effervescence intellectuelle et une émulation tant pour acquérir de nouveaux savoirs que pour réaliser de nouveaux programmes. Ce département était un des endroits de France les plus en pointe pour l'usage et les développements informatiques.

Par ailleurs, les autres départements de l'INSEE trouvaient que l'informatique ne leur donnait pas satisfaction, mais cela, de toute façon, est vrai presque partout et presque toujours. Dans la plupart des institutions (ou divisions d'institution) vouées à la production d'information, le travail réel est effectué par l'informatique, et les départements situés en aval réagissent à leur impuissance par des récriminations contre cette puissance démiurgique. Il est donc pratiquement toujours possible, pour se débarrasser de son informatique, d'arguer des plaintes qu'elle suscite de la part des « utilisateurs », et peu de dirigeants se privent du recours à ce moyen de pouvoir.

Les réorganisateurs d'Alex Andréiev, requis par la Direction Générale de l'INSEE (dont on rappelle qu'elle est une direction du Ministère de l'Économie et des Finances, au même titre que la Direction Générale des Impôts ou que la Direction de la Comptabilité Publique), n'eurent donc guère de difficulté à établir un constat de mauvais fonctionnement et à proposer un plan pour une organisation plus professionnelle. Le principe de cette réorganisation était, ô surprise, taylorien.

Chaque fonction du Département Informatique (développement de logiciels, applications, système d'exploitation et réseau, exploitation) fut découpée en deux tranches : une mince tranche « fonctionnelle » dévolue à la conception, et une tranche « opérationnelle » plus épaisse consacrée à la production. À la tranche fonctionnelle était aussi dévolue une mission de pilotage, terme goûté par certains managers parce qu'il flatte leurs fantasmes de toute-puissance.

Il me semble nécessaire de s'interroger ici sur la permanence du modèle taylorien de l'entreprise au sein des cabinets de conseil : en quoi sert-il leurs propres intérêts commerciaux ? quelle relation entretient-il avec leur propre modèle d'organisation, qui comporte une comptabilité minutieuse du temps de leurs collaborateurs ? Et la logique de leur démarche commerciale ne leur impose-t-elle pas de forcément préconiser à leur client une réorganisation ?

De retour du service militaire, et affecté à l'équipe chargée du système d'exploitation, je dus choisir entre une affectation fonctionnelle, c'est-à-dire avoir le droit de réfléchir mais sans toucher aux ordinateurs, et une affectation opérationnelle où je pourrais toucher aux ordinateurs [9] mais en exécutant aveuglément des procédures décidées pas les fonctionnels. Pour être sûr que les choses soient séparées, elles étaient installées sur des sites différents, fonctionnels à la Direction Générale et opérationnels au centre de calcul. Cette organisation m'apprit un principe : si un travail est intéressant, il suffit de le diviser suffisamment pour obtenir plusieurs activités inintéressantes. Je réussis à échapper temporairement au dilemme en me faisant nommer fonctionnel en stage au centre de calcul au sein d'une équipe opérationnelle, mais ce n'était que reculer l'échéance fatale de la bureaucratisation.

Dans le domaine du développement logiciel, Alex Andréiev nous avait trouvés trop artisanaux : il était préconisé de monter des projets plus professionnels et de recourir à des prestations extérieures pour la réalisation des logiciels. Ce fut fait. Un cahier des charges fut rédigé pour la réalisation d'un logiciel de dépouillement d'enquêtes statistiques, un appel d'offres lancé et une société de services choisie comme prestataire. Tout cela était extrêmement bien fait : cahier des charges rédigé par des gens hyper-compétents en informatique et en statistiques, consultation des départements utilisateurs, constitution d'une équipe de projet avec deux ingénieurs INSEE de haute qualification et une dizaine d'ingénieurs du prestataire, eux aussi très qualifiés. Il convient de souligner que la plupart des projets que j'ai observés étaient loin de bénéficier de conditions initiales aussi favorables.

Tout fonctionna à merveille : au bout de trois ou quatre ans et de quelques millions de francs le logiciel fut livré, et comme le lecteur des lignes ci-dessus peut le prévoir, il déçut. Son mode d'emploi était fort lourd et nécessitait un apprentissage d'une difficulté comparable à celle d'un véritable langage de programmation, sans en procurer la souplesse et la puissance. Des logiciels d'analyse statistique plus agréables à utiliser et plus versatiles étaient apparus sur le marché. Ses seuls utilisateurs furent les exécutants auxquels le choix n'était pas laissé, à de rares exceptions près. Nous reviendrons sur les leçons à tirer du développement de ce logiciel dans un prochain chapitre, mais disons ici que de cette expérience pourtant menée avec le plus grand sérieux et dans toutes les règles de l'art j'ai dû tirer trois conclusions : pour faire de l'informatique intéressante il fallait m'extraire des organisations alexo-andréieviennes, si possible je devais devenir responsable de l'informatique pour pouvoir l'organiser à ma guise, et j'éviterai alors, dans toute la mesure du possible, de faire appel à des prestataires extérieurs.

La chance m'a été donnée de pouvoir réaliser ce programme pendant vingt ans, grâce à des directeurs d'établissements de recherche qui m'ont accordé leur confiance pour diriger leur informatique scientifique, et je crois pouvoir dire qu'ils s'en sont bien trouvés, et moi aussi. J'ai fini par être rattrapé et démasqué par les alexo-andréieviens, mais ceci est une autre histoire.

Vingt et quelques années plus tard, je me suis donc retrouvé dans un univers qui essayait de devenir conforme à la doctrine du prestigieux cabinet Alex Andréiev, et je constate que dans ce monde de l'informatique où soi-disant tout va de révolution en révolution, rien n'a changé si ce n'est le vocabulaire. Les projets de système d'information (locution inconnue dans les années 1970, notez-le) menés par des sociétés de service coûtent toujours aussi cher, les délais sont toujours autant dépassés, et le résultat final déçoit toujours autant les utilisateurs (c'est un euphémisme).

Les détails de la conduite de projet

Aujourd'hui (et depuis quelque temps déjà, mais cela va en s'aggravant) il n'est plus question que de projet. On travaille en mode projet, c'est-à-dire en appliquant les méthodes de conduite de projet, qui sont l'objet d'enseignements universitaires qui jettent pas mal de poudre aux yeux. Ne pas parler ce langage, c'est s'exposer à ne plus être considéré comme un professionnel. En quoi cela consiste-t-il ? En ceci :

  1. Rédiger des documents pour préciser ce que l'on veut faire, à chaque étape, ainsi :
    • note d'argumentation, pour convaincre de l'opportunité de lancer le projet ;
    • note de cadrage, pour délimiter le périmètre fonctionnel affecté par le projet (c'est, au passage, un exemple de parler projet) ;
    • dossier de faisabilité. Une fois que la décision de lancer le projet a été prise :
    • cahier des charges ;
    • plan qualité du projet ;
    • planning du projet ;
    • spécifications générales et détaillées ;
    • plan de recette et plan de formation ;
    • différents dossiers techniques ;
    • documents de recette du projet ;
    • documents de déploiement (j'abrège).
  2. Planifier : il existe des logiciels (et même des logiciels libres) de gestion de projet, qui permettent d'enregistrer les différentes étapes du projet et leurs durées, et d'en déduire un calendrier, avec le calcul des effectifs mobilisés pour chaque tranche de temps, etc. Ces logiciels peuvent bien sûr produire des diagrammes de Gantt ou de Pert.
  3. Travail fusionnel : tous les participants au projet sont regroupés dans un espace de travail ouvert (« open space »), développent à grands cris, communiquent en temps réel et sont en « 100% réactivité » (oui, ils parlent ainsi).

La liste des documents énumérés au point 1 semble tout à fait raisonnable. Pour ce qui est des documents destinés à scander l'avancement du projet, nul ne pourra nier qu'il est bon de rendre explicite ce que l'on veut faire plutôt que de se lancer au jugé dans un projet mal évalué, et pour ce faire les documents cités ici (tirés d'un exemple réel un peu simplifié) semblent raisonnables.

Pour le point 2 je serai plutôt réservé : à la différence des adeptes de la conduite de projets, je pense que la réalisation d'un logiciel, fût-il destiné à prendre place dans un système d'information, est une activité de conception, en tant que telle rétive par nature à la planification ; il faut bien sûr tenter de juguler cette rétivité, mais un excès de planification, ou une planification trop précise ne peuvent que répandre des illusions et des déceptions et finalement stériliser le projet. J'exposerai un peu plus loin une hypothèse sur le rôle réel de ces diagrammes de planification.

Là où les choses peuvent se gâter, c'est lorsque la conduite de projet selon la méthode standard engendre l'apparition d'une profession particulière, le chef de projet, dont bien souvent la compétence va se limiter à la chefferie de projet, et qui va être chargé d'encadrer les ressources, pour exhiber le terme insupportable qui sert à ces gens-là pour parler des êtres humains qui travaillent sous leur responsabilité. Que l'on m'entende bien : le chef de projet est indispensable à la réussite du projet, mais dès lors que la position qui lui est assignée est essentiellement administrative, et le cas n'est pas rare, la production de documents va cesser d'être le support d'une activité plus importante de nature technique, la réalisation d'une application informatique, et va sombrer dans une bureaucratie envahissante, c'est-à-dire devenir une fin en soi. À partir de ce moment, la compétence technique devient une gêne dans le projet, parce qu'elle menace le pouvoir du chef de projet (et de ses chefs à lui), assis sur une montagne de papier — remarquons que dans une telle organisation, avec d'un côté des bureaucrates et de l'autre des développeurs, toutes les erreurs sont forcément attribuées aux développeurs, ne serait-ce que parce qu'ils sont en bout de chaîne, les rédacteurs de cahiers des charges ne peuvent pas avoir tort ; un dispositif qui a pour conséquence une situation aussi aberrante ne peut guère se justifier. Il va donc devenir urgent d'éliminer la compétence interne pour lui substituer une compétence externe fournie par une entreprise extérieure, et de ce fait plus docile puisque mercenaire ; il n'y aura plus « en interne » que des rédacteurs de cahiers des charges et de plannings. Mais ceci a bien sûr aussi des inconvénients, comme tout mercenariat : perte de compétence de l'entreprise sur des activités (le système d'information) dont on ne cesse pourtant de proclamer qu'elles sont stratégiques et vitales, coûts incontrôlables, disparition de toute vision relative à l'évolution des techniques, enkystement dans des solutions périmées que l'on ne sait plus comment remplacer, sclérose généralisée. Ce tableau clinique n'est hélas que trop facile à observer tant il est répandu.

Pour ce qui est du point 3 de la liste ci-dessus (regroupement de tous les participants au projet dans un « open space »), il s'agit surtout d'un outil de productivité destiné à renforcer le contrôle sur le personnel, avec la contrepartie (pas nécessairement involontaire) de créer des conditions où tout réel travail de création est impossible. Ce qui résout ipso facto le dilemme du point 2 examiné ci-dessus : puisque l'on n'a plus affaire à un travail de conception mais à un travail de bureau répétitif ordinaire, il redevient planifiable ! Le remplissage de formulaires vides de sens est une activité dont le rendement est calculable avec une bonne précision. Sans oublier la signification concrète de l'aspect « 100% réactivité » : on est à la merci du téléphone pour obéir sans délai à toute injonction des « fonctionnels », ce qui rend impossible tout travail réel.

Une autre critique à l'encontre des méthodes de conduite de projet est souvent formulée par les développeurs : la hiérarchie du projet est très avide de documents, de reporting comme on dit, l'établissement de ces documents consomme énormément de temps, mais il n'y a le plus souvent aucun retour d'information vers les opérationnels ; tout laisse croire que ces documents n'ont qu'une justification administrative, alors que s'ils étaient vraiment utiles à l'accomplissement des objectifs du projet ils devraient engendrer un flux d'information dans les deux sens. L'aspect unilatéral du reporting donne à penser qu'il s'agit simplement d'un dispositif de surveillance du personnel, un peu comme le chronométrage dans les usines tayloriennes.

Un chef d'entreprise informatique de haute technicité, qui avait auparavant exercé des responsabilités importantes dans le dispositif public de recherche scientifique, me confiait un jour son idée sur la raison d'être véritable de ces dispositifs de conduite de projet : aujourd'hui, la direction du personnel par des méthodes autoritaires, du type « vous allez faire ceci ou cela parce que je suis votre chef et que je vous dis de le faire », fonctionne de plus en plus mal, et plus du tout dans les activités de conception. Alors le calendrier prévisionnel vient prendre la relève de manière douce : « tu vois, sur le planning, jusqu'à telle date les cases qui correspondent à telle tâche, qui t'est attribuée et que tu as acceptée en réunion de projet tel jour, eh bien ces cases sont jaunes, mais après cette date elles sont rouges, eh bien cela veut dire que les livrables de la tâche devront avoir été livrés à ce moment-là ». Cela semble tout bête, mais ne marche pas trop mal.

Là où la méthode de gestion de projet se révèle très utile, c'est entre les mains d'une entreprise de prestation de services, à l'encontre de ses clients. En général les prestataires maîtrisent beaucoup mieux la méthode que les clients, parce que c'est leur métier et qu'ils la pratiquent à longueur d'année, ce qui n'est jamais le cas des clients. Un calendrier prévisionnel habilement concocté peut donc servir à justifier l'entassement sur le projet de nombreux personnels aussi lourdement facturés que faiblement compétents et utiles, tandis que tout retard de livraison pourra être facilement imputé au client qui n'aura pas remis dans les délais contractuels tel obscur document que tout le monde avait oublié. Les dérives potentielles de la sous-traitance en matière de gestion de projet informatique seront développées plus amplement lors d'un prochain chapitre et suivantes, consacrées respectivement à l'externalisation et aux avantages et inconvénients comparés des prestations de services au forfait ou en régie.

Voici les leçons que je tire de ces péripéties. Au risque de me répéter, la division de l'activité informatique en « conception » réalisée par des « fonctionnels » et « production » réalisée par des tâcherons est inappropriée. La combinaison de la gestion de projet, du cycle de développement en V et du recours à un prestataire extérieur engagé au forfait sur la base d'un cahier des charges immuable est une recette pratiquement infaillible pour conduire à l'échec. Ce qui est triste pour le contribuable français, c'est que la réglementation de la commande publique rend cette démarche à peu près obligatoire.

En conclusion, la gestion de projet nous apparaît essentiellement, sans que cela nous surprenne, et une fois débarrassée de tout le verbiage pseudo-scientifique qui l'accompagne, comme un mécanisme du pouvoir de l'entreprise sur ses employés, et éventuellement comme une arme concurrentielle dans les relations contractuelles entre les entreprises sous-traitantes et leurs clients.

Littérature de conduite de projets

Réaliser l'inventaire des manuels de conduite de projet disponibles sur le marché serait une entreprise dont l'ampleur excède de beaucoup les dimensions du présent ouvrage, tant l'intensité de la demande en recettes de management prêtes à appliquer est grande dans ce domaine. Leur lecture exhale en outre une grande monotonie, même si un certain bon sens et un certain humour n'en sont pas absents. Un ouvrage typique de ce champ est Le Chef de projet paresseux... mais gagnant [10], chez Microsoft Press ; parsemé de dessins satiriques souvent drôles, c'est un assez bon livre, propre à retenir jusqu'à la fin l'attention de lecteurs peu enclins à l'effort intellectuel. Les méthodes de travail qu'il préconise sont générales, et l'identité de son éditeur pourrait suggérer qu'elles s'appliquent aux projets informatiques ou de systèmes d'information, mais en fait la plupart des exemples concrets qui les illustrent sont empruntés aux industries de fabrication ou au secteur du bâtiment et des travaux publics. Si l'on tente d'imaginer la transposition de ces exemples au domaine informatique, on voit bien pourquoi cela ne peut pas donner les résultats espérés : tous les critères d'appréciation de la démarche du projet et de sa réalisation reposent sur des faits matériels et des objets concrets et mesurables, et l'on ne peut espérer trouver des critères comparables en informatique qu'au prix d'artefacts réducteurs. Ainsi on peut mesurer l'avancement d'un projet de développement au nombre de lignes de programme écrites, mais cela ne dira rien de leur justesse, ni encore moins de leur adaptation à l'objectif poursuivi, ce qui est bien sûr beaucoup plus important.

Une autre impression qui se dégage de la lecture de ce livre, c'est l'importance des procédures bureaucratiques : si l'on additionne le temps consacré aux réunions et celui dévolu à l'écriture et, peut-être, à la lecture des multiples rapports, notes et compte-rendus dont la rédaction est préconisée, on se demande quand et par qui le travail va être fait. En réalité, si l'on garde à l'esprit le fait que cette méthode s'applique à des industries de fabrication ou de construction, l'énigme se dissipe : ces secteurs sont soumis à une division du travail héritée des siècles passées, il y a des terrassiers qui piochent (fusse avec des tracto-pelles), et des ingénieurs qui font des mesures et rédigent des rapports. Mais, comme nous avons déjà commencé à le voir, et la suite de cet ouvrage approfondira cette conception, la réalisation de logiciels et de systèmes d'information n'obéit pas aux mêmes contraintes, et ce type de division du travail y est voué à l'échec.

Post-scriptum : mesure des projets

Dès lors que par les bienfaits de la gestion de projet une activité de conception délicate et difficile à planifier a été ramenée à une routine bureaucratique, rien n'interdit plus de lui appliquer des méthodes de mesure tayloriennes. Au passage, clarifions bien notre propos : transformer une activité coûteuse en activité de routine peu qualifiée et planifiable, cela s'appelle améliorer la productivité, et c'est généralement considéré plutôt comme un bien. Il pourrait en être de même dans le cas que nous envisageons ici : le seul inconvénient, c'est que ladite activité de routine ne produit ici rien, ou à peu près rien, en tout cas pas du tout ce qui en était attendu, et le gain de productivité espéré, et même mesuré par des métriques fallacieuses, se révèle en définitive négatif.

Jacques Printz, spécialiste du génie logiciel, a produit plusieurs ouvrages[89, 90] consacrés à la mesure de l'activité des programmeurs, qui sont de bons exemples de ce que l'on peut faire de mieux dans cette direction : je crains fort que ce qui peut être mesuré par ces méthodes parfois fort raffinées ne corresponde pas exactement à ce qu'il serait souhaitable de mieux comprendre.

Faut-il céder au désespoir ?

La conclusion provisoire à laquelle nous a menés ce chapitre semble désespérante : les méthodes disponibles pour définir le travail à effectuer dans le cadre d'un projet informatique sont inadaptées, les cadres conceptuel et juridique qui devraient nous aider dans cette entreprise se révèlent être en fait des obstacles. Devons-nous céder au désespoir et retourner à la plume d'oie et au boulier ? Les tenants de la nouvelle barbarie élitiste et technophobe, issus des meilleures écoles de la République, ne cessent de nous le suggérer plus ou moins insidieusement, cependant que les adeptes de la technoscience obscurantiste persistent aveuglément dans ces démarches inadaptées qui n'enrichissent que certaines sociétés de service et cabinets d'audit et d'organisation.

Le chef d'entreprise informatique de haute technicité déjà évoqué plus haut me fait remarquer que les critiques formulées ici, et également dans les chapitres suivants, à l'encontre des méthodes courantes de conduite de projet sont surtout valables dans le contexte du secteur public français. Il est vrai que beaucoup des observations qui sont à l'origine de ces critiques ont été faites au sein d'organismes publics. Je suis entièrement d'accord avec lui pour attribuer le rôle principal dans certains égarements de l'économie française à l'organisation de l'État, et notamment aux marchés publics. Mais justement l'État occupe dans ce pays une place importante et il n'est pas isolé du non-État par une cloison étanche. Il a donc largement contaminé les autres secteurs de la société, et particulièrement les grandes sociétés privées, presque toutes dirigées par des fonctionnaires, et pour lesquelles la concurrence du marché capitaliste est très atténuée, notamment du fait de leurs liens étroits avec l'État — et cette intimité est scandaleuse. Pour ce qui est des sociétés de services informatiques, la part la plus lucrative de leur marché est le secteur public, rendu encore plus rentable par son déficit de compétences. Ces relations impures contribuent à créer une situation malsaine qui tire l'ensemble de l'économie vers le bas en assurant des rentes à des agents économiques parasitaires et en fermant l'accès au marché (qu'il soit du travail ou de l'entreprise) à des acteurs potentiellement plus dynamiques qui pourraient créer plus de richesses.

Y a-t-il une autre voie ? Oui, et même plusieurs. Nous allons en parler, et d'ailleurs elle ne sont pas franchement inédites, mais elle n'ont jamais été bien populaires parce qu'elle sont fatigantes : elle demandent l'acquisition de compétences, puis du travail (par opposition à l'imitation de travail évoquée par Alexandre Zinoviev). Elles feront l'objet de la suite de ce livre, non sans que nous ayons consacré le chapitre suivant à la normalisation et à la démarche qualité, détour inévitable à qui veut comprendre les méandres de l'encadrement du travail dans le monde contemporain.

[1] Jean-Pierre Boutinet, Anthropologie du projet, Presses Universitaires de France, Paris, 1990 — 2003.

[2] Il est possible de se faire une idée exacte de sa conception en visitant à Florence le Musée des Travaux du Duomo, qui expose maquettes, dessins et autres documents.

[3] Juliette Poupard, De la question du mélange des genres communicationnels numériques et de la rationalisation des modes de production des objets numériques en entreprise, 2004. article à paraître.

[4] Jean-Louis Bénard, Laurent Bossavit, Régis Médina, Dominic Williams, L'eXtreme Programming, Eyrolles, Paris, 2002.

[5] Frederick P. Brooks, Jr The Mythical Man-Month (traduction : Le mythe de l'homme-mois ), Addison-Wesley (Vuibert pour la traduction), Reading, Massachusetts (Paris), 1975-1995.

[6] Christian Morel, Les décisions absurdes — Sociologie des erreurs radicales et persistantes, Gallimard, Paris, 2002.

[7] J'ai longtemps cru que cette inaptitude à envisager la notion d'investissement était propre à l'administration française, mais la lecture des livres du prix Nobel d'Économie Joseph Stiglitz(The Roaring Nineties (en français : Quand le capitalisme perd la tête, W.W. Norton (pour la traduction : Arthème Fayard), New-York (Paris), 2003.) m'a appris que l'administration fédérale américaine souffrait du même mal.

[8] Émile Landormy, Moi, Émile Landormy, indépendant du 21ème siècle, Téraèdre, Paris, 1997.

[9] Pour que cela soit intelligible au jeune lecteur, il faut rappeler qu'à cette époque il n'y avait ni micro-ordinateurs posés sur les bureaux, ni réseau, et qu'une installation de système se faisait de nuit, après réservation plusieurs semaines à l'avance de la machine, laquelle pesait quelques tonnes et logeait dans une salle de 200 m2.

[10] Marc Destors, Jean Le Bissonais, Marc Fersten, Le Chef de projet paresseux... mais gagnant, Microsoft Press, Les Ulis, France, 2000.