Précédent Remonter Suivant
Page d'accueil de ce livre

Chapitre 2  Définition et contrôle du travail à faire

Dès lors que le travail est une marchandise qui s'achète et qui se vend se posent à son sujet les questions économiques classiques de la valeur, du prix et de la quantité, ainsi que de leur contrôle. Pour le travail informatique qui nous intéresse ici, ces questions n'ont jamais trouvé de réponse pleinement satisfaisante. Classiquement, la quantité de travail se mesure par le temps de travail : c'est cette quantification qui se révèle de plus en plus inappropriée au fur et à mesure que le travail devient plus complexe et plus difficile à contrôler. L'expertise, par exemple, est un stock de travail accumulé qui produit son effet sans qu'il soit besoin pour cela d'un flux de travail : l'expert « voit » la solution du problème en un éclair, il ne lui reste plus qu'à la décrire et à la communiquer. La durée de travail est donc une mauvaise échelle de mesure pour évaluer la qualité d'une expertise --- ou alors, il faudrait prendre non pas la durée d'une expertise, mais la durée d'accumulation du savoir de l'expert ; et il faudrait encore lui ajouter quelques paramètres qualitatifs. Or curieusement la plupart des tentatives de réponse aux questions énoncées aux premières lignes de ce chapitre, en tout cas dans le domaine de la gestion, se sont tournées vers des adaptations du modèle taylorien, pourtant déjà bien démodé, et entièrement fondé sur deux principes dont nous verrons dans la suite de cet ouvrage qu'ils sont particulièrement inadaptés à la construction de systèmes informatiques ou de logiciels : Pour éclairer le sujet nous allons brosser un tableau rapide des procédures de contrôle du travail en général, avant d'aborder plus précisément leur application à l'informatique.

1  Le modèle de la grande industrie et le taylorisme

C'est au XVIIIe siècle que la vision du travail comme marchandise est vraiment devenue dominante, pour s'imposer au XIXe siècle dans l'organisation type de la grande usine industrielle. Il n'est pas inutile de consacrer quelques lignes à ce modèle d'organisation, parce que même s'il est aujourd'hui en crise et en déclin, il existe encore beaucoup, et a même connu une vogue récente dans l'univers informatisé avec les centres d'appel téléphonique, qui ne sont rien d'autre que des bureaux taylorisés. Philippe Zarifian[127](p. 59), à qui ce chapitre doit beaucoup, caractérise cette organisation par la règle des trois unités du théâtre classique français : Zarifian rappelle combien il a été difficile, en France, d'imposer ce mode de travail à une population ouvrière issue en masse de la paysannerie indépendante et de l'artisanat. On signalera au passage le rôle qu'a joué le service militaire pour réduire l'individualisme des populations rurales et les plier à la discipline collective. Ce n'est que dans le second tiers du XXe siècle que ce modèle se généralisera dans notre pays, bien après l'Angleterre et l'Allemagne.

Entre-temps était apparu le taylorisme, rationalisation ultime du système de la grande industrie. Zarifian le décrit comme « la soumission des actes de travail au calcul du temps, telle qu'elle détermine le choix imposé du contenu de ces actes (de ces gestes, dans le cas du travail ouvrier). » (p. 36). Curieusement, le but conscient poursuivi par Taylor en élaborant sa méthode était l'amélioration de la condition ouvrière. En fait, elle fut surtout un moyen de donner une apparence rationnelle au calcul de la valeur des biens produits par le travail.

Avec le taylorisme « la mesure normée du temps (le temps opératoire que l'ouvrier doit respecter, voire abaisser) s'incorpore dans les actes du travail.

Et le mot ``incorporer'' a un sens parfaitement précis : le temps pénètre dans les gestes et mouvements ouvriers, au point qu'à l'ouvrier échappe la définition du mouvement de son propre corps. Le mouvement de son corps lui est imposé comme une réalité à laquelle il doit se soumettre. Il y a, dans cette incorporation d'un temps abstrait au sein de l'usage de son corps, l'exercice d'une violence incommensurable, qui explique, en profondeur, pourquoi l'organisation taylorienne du travail était (est) destructrice des individualités, pourquoi elle a engendré de véritables révoltes... » (p. 37).

Pratiquement, le découpage du travail en tâches élémentaires dotées d'un temps d'exécution soigneusement calculé est insupportable pour celui qui doit l'effectuer, et cette méthode ne fonctionne que dans deux cas : si le travailleur s'impose à lui-même cette contrainte, parce qu'il y a un intérêt, quel qu'il soit, ou lorsqu'elle peut être appliquée par la force, ce qui peut être le cas du travail manuel simple, comme les coups de rame des galériens cadencés par les roulements d'un tambour, la progression des esclaves dans la plantation où le fouet vient faire accélérer le retardataire, le travail dans la grande industrie contemporaine où la progression inexorable de la chaîne impose son rythme aux ouvriers spécialisés. Dans le cas d'un travail qui requiert l'initiative du travailleur, les moyens de mettre en échec la cadence prévue par l'encadrement sont innombrables, et comme la tentative de lui imposer cette organisation du travail a altéré la confiance du travailleur, il n'hésitera pas à y recourir à la moindre occasion. A fortiori, lorsqu'il s'agit d'un travail de conception, essayer d'imposer des normes de productivité de type taylorien ne peut que mener à la débandade ou, pire, au simulacre et à l'imitation de travail. Nous avons vu qu'Alexandre Zinoviev avait brillamment analysé le système bureaucratique soviétique dans cette perspective.

La discipline d'usine, parachevée par le taylorisme, participe de ce que Gilles Deleuze et Michel Foucault ont appelé une « société disciplinaire », dont la pratique s'élabore à partir du XVIIe siècle pour culminer au XXe ; ils sont ici évoqués par Philippe Zarifian : « dans ces sociétés, l'individu ne cesse de passer d'un milieu clos à un autre, chacun ayant ses lois : d'abord la famille, puis l'école, puis la caserne, puis l'usine, de temps à autre l'hôpital, éventuellement la prison... On sait que Foucault [...] a insisté sur le fait que le capitalisme industriel a largement emprunté à des modèles, dispositifs et savoirs qui s'étaient déjà constitués antérieurement, et dont l'asile et la prison fournissent le référent paradigmatique. » (pp. 13-14).

Après l'usine, le centre d'appel

Aujourd'hui le taylorisme au sens strict est en déclin parce qu'il n'est plus guère adapté aux besoins de la production industrielle contemporaine non plus qu'aux nouvelles normes de comportement individuel et collectif. La société disciplinaire cède le rang à la société de contrôle. Au chronométrage précis de chaque geste de l'ouvrier qui accomplit une tâche formalisée dans une table de temps, succèdent la fixation de délais et le contrôle informatique des activités des opérateurs des centres d'appel, dont il est facile de mesurer le temps moyen consacré à chaque appel de client et le nombre d'appels pris. De tels centres d'appel peuvent être installés dans des pays francophones à coût de main-d'oeuvre modéré, ainsi il en existe un à Tunis qui a pour clients simultanés des acteurs majeurs du secteur français des télécommunications, de l'Internet et du câble. Les opératrices doivent pour être sélectionnées posséder une parfaite maîtrise de la langue française et la parler sans accent, ce qui suppose un niveau d'instruction élevé. Il leur est demandé de se présenter aux clients sous des pseudonymes tels que Sandrine, Annabelle ou Virginie. Leurs salaires sont bien entendu une faible fraction du SMIC français. Ces centres d'appel sont utilisés pour répondre aux demandes de renseignements ou d'assistance technique (« hotline ») des clients, mais aussi pour harceler au téléphone les clients potentiels.

Un dispositif aussi artificiel ne peut pas donner de bons résultats : les univers des deux interlocuteurs au bout du fil sont tellement éloignés l'un de l'autre que les réponses aux questions ne peuvent être que stéréotypées, et dès que la question se complique un peu le dialogue est impossible --- pour être juste, il convient de dire que la qualité de réponse des centres d'appel installés en France n'est pas meilleure. Les services d'assistance téléphonique (« hotline ») des grandes entreprises de télécommunication et d'informatique mis en oeuvre par de tels procédés recueillent un taux de satisfaction des utilisateurs très bas, ce qui semble ne troubler personne : une fois que le client est abonné il est considéré comme captif, notamment parce que les tarifs sont conçus de telle façon que le changement de fournisseur a un coût élevé.

Ce qui a séduit les managers dans l'idée de centre d'appel, c'est bien sûr l'aspect taylorien. Pourquoi ce système ne peut pas marcher, ce sera l'objet de la section suivante.

Incidemment, nous pouvons vérifier ici[16] sur un exemple concret ce que nous écrivions au chapitre précédent : les entreprises qui échappent au diktat des bureaucrates financiers, comme par exemple le groupe Bouygues, agissent différemment : sur 6 800 salariés, Bouygues Télécom compte 2 300 conseillers de clientèle, qui travaillent en fait dans des centres d'appel, mais dont le sort est bien différent de ce qui est décrit ci-dessus. Fait déjà remarquable, ils sont des salariés de l'entreprise, et non d'une quelconque société d'intérim, et même pour certains d'entre eux ils travaillent dans les mêmes locaux que la direction générale. En outre, leur employeur s'évertue à recueillir et à exploiter le savoir qu'ils accumulent à l'écoute des clients, au lieu de simplement l'ignorer comme cela a lieu le plus souvent. On pourra consulter à ce sujet le site de Michel Volle[114]. On pourra aussi voir avec profit le film d'Arnaud et Jean-Marie Larrieu, « Un homme, un vrai », avec Hélène Fillières et Mathieu Amalric, qui se passe dans l'univers grisant des managers de centres d'appel. Pour mémoire, les centres d'appel emploient en France 210 000 personnes au 1er janvier 2005, pour 1 million en Grande-Bretagne.

2  Tout travail émet de la pensée

Le travail a vocation à produire du sens, pour son auteur comme pour son destinataire. La production d'un bien ou d'un service a du sens si elle a valeur d'usage pour une clientèle ou un public. Le travailleur qui les produit en a conscience et cette conscience guide ses actes. Il appartient aux organisateurs du travail de veiller à ce que cette production de sens ait lieu, sauf à vouloir régner sur un univers tel que décrit dans les films « Metropolis » de Fritz Lang ou « Les temps modernes » de Charlie Chaplin, ou encore dans les pièces de Georges Courteline (on rêve à ce que Courteline aurait pu imaginer s'il avait connu les systèmes d'information et les projets !). Suivons ici encore Philippe Zarifian qui nous invite à rendre visite à Gilles Deleuze et à Michel Foucault : « travailler, c'est s'affronter à des situations qui comportent du surprenant, de l'inédit, de l'imprévu, et c'est, pour employer un concept de Gilles Deleuze, contre-effectuer ces événements, leur conférer un sens humain et agir en conséquence...

À tout moment, un individu au travail peut perdre le sens de ce qu'il fait et tomber dans un état d'aliénation. La pression du débit, l'impossibilité de comprendre les attendus et finalités de ce qu'il fait, l'opacité de l'organisation dans laquelle il est placé... peuvent engendrer une forte difficulté à produire du sens. L'aliénation... surgit par perte de sens, enfermement dans une pure routine reproductrice... et dans un champ de pressions que l'on ne peut que subir. » (p. 9-11).

La réalisation d'un travail, comme l'explique encore Philippe Zarifian[127] (p. 83), passe par deux moments au moins : un moment de pensée, où l'on imagine le résultat à venir d'un travail futur et les avantages qui pourraient en résulter, un moment de réalisation de la chose projetée. La division du travail (et plus particulièrement l'organisation taylorienne du travail) vise à ce que celui ou ceux qui pensent ne soient pas les mêmes que celui ou ceux qui réalisent, mais il n'est pas si facile de supprimer toute pensée dans la phase de réalisation. Et cela dépend beaucoup de la nature du travail.



Dans le bâtiment, ces deux moments du travail sont instanciés en deux personnes (généralement collectives) : le maître d'ouvrage, qui dit ce qu'il faut faire (et paie), et le maître d'oeuvre, qui organisera la réalisation, avec, entre les deux, l'architecte qui dit comment ce sera réalisé. Notons au passage le caractère discursif essentiel du travail de définition : il faut des échanges verbaux entre ces différentes personnes pour que le projet aboutisse.

Évidemment le résultat final sera différent de ce qui était prévu par le maître d'ouvrage et par le maître d'oeuvre, parce que le travail de réalisation soulèvera des problèmes imprévus et imprévisibles, qui obligeront tous les participants à apprendre et à imaginer des choses nouvelles pour les résoudre.

Retenons que la bonne fin de la réalisation d'un projet architectural de quelque ampleur suppose une véritable collaboration entre le maître d'ouvrage, l'architecte et le maître d'oeuvre, c'est-à-dire que les problèmes de réalisation rencontrés par la maîtrise d'oeuvre doivent pouvoir être résolus par une évolution du projet prise en compte par la maîtrise d'ouvrage et l'architecte, en d'autres termes la réalisation doit pouvoir agir en retour sur la conception. Pour les projets informatiques nous verrons qu'il en va de même, et que si cette possibilité d'effet rétroactif est bloquée, par exemple par un dispositif aberrant comme le Code des Marchés Publics que nous évoquerons à la section suivante, eh bien le projet échoue, peu ou prou.

3  Théorie et pratique de la commande publique

En France, les prestations de service commandées par les services publics à des entreprises font l'objet de contrôles de leur bonne réalisation selon des procédures et des règles qui sont des cas particuliers d'un ensemble plus vaste, la réglementation des marchés publics de l'État, dont nous allons donner ci-dessous une brève description.

Réglementation des marchés publics

Le dispositif juridique, réglementaire et comptable qui encadre les actes contractuels de la puissance publique en France est très particulier et il convient d'en dire quelques mots. Hormis d'anciennes colonies françaises auxquelles nous l'avons transmis, aucun pays au monde n'est doté d'un système aussi étrange. Dans la plupart des pays, on considère en effet que les lois et les règlements qui s'appliquent au commun des mortels peuvent s'appliquer aux services publics, à quelques ajustements techniques près : idée totalement inappropriée aux yeux de la puissance publique française ! Le Service public français est doté d'un système juridique parfaitement extravagant du droit commun1.

Si l'on veut comprendre quelque chose à ce dispositif (et toute entreprise désireuse de vendre des biens ou des services à des administrations publiques ou locales devra en comprendre au moins les grandes lignes, sauf à subir de graves mésaventures qui pourront aller, le cas n'est pas si rare, jusqu'au dépôt de bilan), il faut bien dès l'abord saisir sa complexité, parce que si chacun de ses éléments pris isolément peut sembler plein de bon sens, ce n'est que leur combinaison, conjuguée à quelques traditions non réglementaires dans leur mise en oeuvre, qui en fait un système bureaucratique absurde et inextricable tel que ceux si bien évoqués par Georges Courteline.

Premier principe : séparation de l'ordonnateur et du comptable

Le premier élément du dispositif est le principe de séparation de l'ordonnateur et du comptable. Il a été instauré en 1319 par l'ordonnance portant création de la Cour des Aides, promulguée au Vivier-en-Brie par Philippe V le Long (1317 -- 1322). Le roi, soucieux d'éviter les détournements de fonds, décidait que celui de ses fonctionnaires qui prenait l'initiative d'une dépense (l'ordonnateur) ne pourrait pas être celui qui payait effectivement (le comptable). Ce principe se traduit aujourd'hui par le fait que si le directeur de tel organisme public de recherche (l'ordonnateur) décide d'effectuer telle dépense, pour laquelle le Parlement a voté un budget, celui qui paiera sera l'Agent Comptable de l'établissement, qui n'est pas son subordonné hiérarchique (il rend compte au directeur du Budget du ministère des Finances) et qui peut refuser de payer (il ne s'en prive pas).

Second principe : contrôle a priori

Le second élément du dispositif est le principe du contrôle a priori. Lorsque le directeur de l'organisme public de recherche pris ici comme exemple (l'ordonnateur) décide d'engager une dépense, il n'envoie pas au fournisseur un bon de commande qui engagerait l'établissement : il le soumet au Contrôleur financier, qui dépend hiérarchiquement du directeur du Budget du ministère des Finances, et dont seul le contre-seing donnera une valeur d'engagement légal au bon de commande. Le contrôle a priori est sans doute l'élément le moins justifiable du dispositif : les directeurs des établissements publics de recherche tels que le CNRS ou l'INSERM sont nommés par le Président de la République, en Conseil des Ministres, ce qui leur confère une légitimité émanée assez directement du peuple souverain ; que leur signature, pour engager l'établissement qu'ils dirigent, doive être contresignée par un obscur fonctionnaire désigné selon un processus bureaucratique opaque, est un déni infligé à la démocratie censée gouverner notre pays. Ce principe a une conséquence délétère très lourde : tous les fonctionnaires, à l'exception des contrôleurs financiers, des agents comptables et de leurs consorts, sont considérés comme des mineurs irresponsables. Lorsque l'on considère les gens comme des irresponsables, ils ont tendance à se comporter de façon irresponsable : ce phénomène n'est pas absent de la fonction publique française.

Rappelons que des millions d'entreprises en France et dans le monde ont recours, pour vérifier que leur argent n'est pas détourné, à des procédures de contrôle a posteriori, et rien ne prouve que le système public français soit une protection plus efficace contre les malversations : si tel était le cas, la France obtiendrait sans doute un meilleur classement sur l'échelle de l'indice de perception de la corruption établi par l'institut Transparency International[107].

Les deux premiers principes de la commande publique sont mis en oeuvre conformément aux dispositions du décret du 29 décembre 1962 portant règlement général sur la comptabilité publique, assorties d'innombrables autres textes qui règlent différents détails. Peu de textes sont abrogés, de nouvelles règles viennent seulement s'ajouter à celles qui existent déjà.

Troisième principe : le Code des Marchés Publics

Le troisième pilier de la commande publique est le Code des Marchés Publics (CMP), qui régit tous les contrats, conclus par des organismes publics ou des collectivités territoriales, dont le montant excède un certain seuil (au jour d'écriture de ces lignes : 150 000 Euros HT pour l'État et 230 000 Euros HT pour les collectivités territoriales ; on consultera avec profit à ce sujet le site du Ministère de l'Économie et des Finances[78], où l'on trouvera notamment le texte du Code lui-même). Ce code semble à première vue plein de bonnes idées, destinées notamment à protéger l'acheteur contre les clauses abusives que les fournisseurs ne se privent guère de glisser dans les contrats-type qu'ils imposent plus ou moins à leurs clients privés. En fait, ce qui fait que ce texte devient assez vite un obstacle plutôt qu'une aide, ce n'est pas tellement sa longueur (69 pages) mais sa complexité, accrue par les correspondances croisées qui le combinent avec d'autres textes (au nombre de 33 dans la version du 7 janvier 2004, disponible en ligne) que le lecteur est censé connaître, et bien sûr avec les deux premiers Principes, surtout le second (contrôle a priori). Le cadre imposé aux parties est formel, rigide, inspiré par la défiance de l'instance de contrôle envers les parties contractantes, et des parties contractantes l'une à l'égard de l'autre (article 64 : « Il ne peut y avoir de négociation avec les candidats. ») Bref, lorsque l'on entame une procédure régie par le Code des Marchés Publics, il faut s'attendre à neuf mois de formalités pour un cas simple et un montant modéré. Le poids d'une telle procédure est tout simplement insupportable.

Cette lourdeur du Code des Marchés Publics a des effets pervers. Ainsi, dans le cas d'un marché de prestations intellectuelles, par exemple la réalisation d'un système informatique comptable et financier, le Code prévoit des clauses perfectionnées qui permettent la résiliation aux torts du titulaire du marché s'il ne remplit pas sa tâche de façon satisfaisante. Mais le client serait bien en peine de les appliquer, parce qu'il lui faudrait alors lancer une nouvelle consultation pour choisir un autre fournisseur, procédure qui aboutirait au bout de neuf mois si tout se passe bien --- n'oublions pas qu'à tout moment le contrôleur financier peut bloquer toute l'opération sine die : comment assurer la continuité du service pendant ce délai ? Le Code des Marchés Publics, censé protéger le client, le livre en fait pieds et poings liés à son fournisseur défaillant.

Il y a aussi dans le Code quelques attrape-nigauds : il comporte ainsi un alléchant article 37 consacré aux « marchés de conception-réalisation ». Ce type de marché semble parfaitement adapté au processus de collaboration dans la durée qui doit régler les relations entre maîtrise d'ouvrage et maîtrise d'oeuvre dans la conduite d'un projet informatique : il concerne « les marchés qui portent à la fois sur la définition du projet et sur l'exécution des travaux... Sont concernés des ouvrages dont la finalité majeure est une production dont le processus conditionne la conception et la réalisation, ainsi que des ouvrages dont les caractéristiques, telles que des dimensions exceptionnelles ou des difficultés techniques particulières, exigent de faire appel aux moyens et à la technicité propres des entreprises. » Mais il ne faut pas rêver, les contrôleurs veillent et disposent d'une batterie d'arguments pour rejeter toute tentative de recours à ce dispositif, sauf cas très particuliers, ce qui est un exemple de détournement de la volonté du législateur.

L'article 36 est consacré à une procédure dite de « dialogue compétitif », censée faciliter la définition d'un cahier des charges, qui risque fort d'être également décevante, compte tenu des habitudes séculaires des administrations financières.

En trois décennies de pratique des marchés publics, l'auteur de ces lignes a vu paraître une demi-douzaine de nouvelles versions du Code ; chacune était censée alléger les procédures et permettre enfin de travailler normalement, c'est-à-dire sur la base d'une confiance réciproque entre client et fournisseur, établie par des moyens normaux (expérience, réputation, échanges d'expérience avec d'autres organismes), et d'un contrôle a posteriori des actes accomplis. En réalité chacune de ces nouvelles versions du Code était aussi indigeste que les précédentes, avec l'inconvénient supplémentaire d'invalider le capital de compétence acquis pour l'utiliser et d'obliger à un effort significatif d'adaptation aux nouvelles règles. Les deux dernières versions, sous l'influence de la loi n° 93-122 du 29 janvier 1993 relative à la prévention de la corruption et à la transparence de la vie économique et des procédures publiques, dite loi Sapin[72], dont pourtant certains articles ont été déclarés anticonstitutionnels par le Conseil Constitutionnel, imputent aux Personnes Responsables des Marchés une responsabilité exorbitante, puisque si elle n'accroît que modérément leur capacité d'initiative, elle fait peser sur leurs têtes une menace judiciaire très lourde. En effet tout soupçon de partialité dans la rédaction d'un appel d'offres peut les conduire devant une juridiction pénale. En fait, tout maître d'ouvrage compétent a une idée de la façon dont un projet doit être réalisé, ce qui le place sous le coup de la loi, risque que n'encourt pas l'incompétent total qui écrit n'importe quoi sans rien savoir, attitude qui, on s'en doute, a les faveurs des instances de contrôle (grâce au ciel, l'incompétence totale n'est pas une denrée introuvable dans l'univers administratif).

Un autre effet pervers de la rigidité du Code des Marchés Publics, conjuguée avec les interventions imprévisibles et bloquantes des agents comptables et des contrôleurs financiers, c'est que l'acheteur public est sûr de se retrouver un jour ou l'autre dans une situation où il sera dans son tort à l'égard du fournisseur, ne serait-ce que parce qu'une fourniture livrée sera payée avec retard : ce genre de situation met l'acheteur public en position de faiblesse dans tout contentieux avec son fournisseur, ce qui, a priori, n'est pas l'objectif visé.

La rigidité de ce cadre réglementaire constitue sa principale faiblesse : comme il rend à peu près impossible toute collaboration réelle entre administration et fournisseur, il engendre lui-même les procédés qui permettent de le contourner, et une fois que ceux-ci sont maîtrisés, ils peuvent être appliqués à des fins que la loi et la morale réprouvent. S'il était un obstacle sérieux aux fraudes et aux malversations, les journaux seraient moins pleins de leur récit. Lors d'un entretien publié par la Revue des Secrétaires Généraux des universités[24], Jérôme Grand d'Esnon, Directeur des Affaires Juridiques au Ministère de l'Économie et des Finances, ne peut que constater la coïncidence géographique entre le territoire des marchés publics régis par une réglementation très rigide, et le territoire de l'occurrence maximum de la corruption en matière de marchés publics :

« La tradition gréco-latine avait imposé une solution de type procédural (appel d'offres + cloisonnement, c'est-à-dire interdiction de dialogue et d'échange). La tradition nordique, anglo-saxonne, est plus ouverte sur les pratiques de la négociation. Or, si la solution latine est bonne en situation d'achat simple, elle est stupide et dangereuse en situation d'achat complexe (celle où l'acheteur ne sait pas rédiger lui-même son cahier des charges ; celle où il a besoin de lisibilité ; celle où il a besoin de pouvoir dialoguer avec ce que lui offre le marché, ce que proscrit la procédure). Or, on peut relever que si l'on superpose la carte des conceptions culturelles en matière de marché public (zone Sud France, Italie, Grèce -- pour l'appel d'offres et le cloisonnement ; zone Nord pour la négociation) et celle de la corruption en matière de marchés publics, on constate un recouvrement quasi-parfait. »

La LOLF est-elle un espoir ?

La réglementation qui s'applique aux marchés publics est elle-même enchâssée dans un cadre plus ample : la loi organique relative aux lois de finances (LOLF), qui prétend représenter la constitution financière de la République. L'avant-dernier avatar de cette réglementation était l'Ordonnance de 1959, qui avait résisté victorieusement à 36 tentatives de réforme par le Parlement. De façon un peu inattendue, le Parlement a voté le 1er août 2001 la Loi organique relative aux lois de finances (LOLF) n° 2001-692 publiée au Journal Officiel du 2 août 2001. Ce texte a réuni de façon surprenante les votes des partis politiques de toutes tendances, le soutien du Président de la République et l'accord du Conseil Constitutionnel. La teneur de ce texte est très novatrice.

Les deux axes de la LOLF sont le passage d'une administration des moyens à une administration de résultats, et le renforcement du pouvoir de contrôle du Parlement, assuré par une transparence accrue des finances publiques destinée à mettre fin à la situation présente, où le parlement vote sans vraiment en juger une Loi de Finances inintelligible au possible. Il est question de clarté des objectifs, et de mesure des résultats. Les gestionnaires deviendraient responsables, leur comptabilité serait soumise aux mêmes règles que celle des entreprises, le contrôle a priori céderait la place au contrôle a posteriori.

Tout ceci semble bel et bon, mais il est permis d'émettre quelques doutes quant aux effets réels de ce programme. Ces doutes sont nourris d'abord par l'expérience des réformes antérieures, certes moins ambitieuses, mais qui affichaient des objectifs analogues sans jamais les atteindre. De plus, la complexité même de la loi, qui ne manquera pas, tel un porte-avions amiral, d'être escortée de toute une flotille de lois annexes, de décrets d'application et de réglements divers et variés, laisse planer un certain scepticisme sur ses bienfaits. Enfin il faut bien voir que les principes de la LOLF sont peu compatibles avec le statut de la fonction publique : soit les fonctionnaires sont responsables, soit il faut les contrôler étroitement, or leur statut actuel ne permet pas qu'ils soient responsables. La seule chose sûre, c'est qu'elle va susciter une grande agitation administrative et des revenus élevés pour les sociétés de services informatiques qui vont réaliser les logiciels comptables et financiers nouveaux requis par ses dispositions.

La pratique des marchés publics

Lorsque l'administration française fait réaliser un système informatique par un prestataire, elle est en position de maître d'ouvrage. Elle rédige (ou fait rédiger) un cahier des charges qui décrit les spécifications du système à réaliser. Ce cahier des charges constitue la partie technique des documents du marché fournis aux entreprises candidates lors de la consultation d'appel d'offres. À l'issue de cette consultation le marché sera attribué au prestataire qui aura fourni la meilleure réponse. La réglementation des marchés publics qui s'impose à ce processus est très rigide, elle limite notamment très rigoureusement toutes les conversations entre maître d'ouvrage et maître d'oeuvre préalables aux travaux, et rend très difficile tout ajustement des clauses du marché aux événements imprévus provoqués par le déroulement de la réalisation. De tels événements sont d'ailleurs considérés comme des failles du dispositif contractuel : le maître d'ouvrage aurait dû les prévoir.

Cette vision de l'Administration laisse planer un doute sur sa capacité à concevoir même ce qu'est le travail, et de là à savoir le respecter, puisqu'elle n'admet pas que puissent surgir des problèmes inédits susceptibles de solutions nouvelles imprévisibles. Cette conception assez mortifère (ce qui est parfaitement prévisible c'est ce qui est mort) s'appelle la bureaucratie, et ne semble pas étrangère au taux de succès assez faible des projets de l'Administration dans le domaine informatique.

Plus précisément, faire fonctionner un dispositif du monde réel, tel que téléphérique, hélicoptère ou ordinateur, impose des contraintes opérationnelles fortes qui sont incompatibles avec le Code des Marchés Publics et le Règlement de la Comptabilité Publique. Pour contourner ces réglementations d'un autre âge, pratiquement incompatibles avec un travail réel, il est tentant (et très couramment pratiqué, notamment dans le monde de la recherche) de recourir à la création de sociétés civiles ou d'associations régies par la loi de 1901. Il est à craindre que parfois cela ne fasse qu'accroître la gabegie et l'impéritie.

En cette année 2004, un ancien secrétaire d'État est mis en examen devant la Cour de Justice de la République pour détournement d'argent public au moyen d'une association, créée à cet effet, qui recevait des subventions et rémunérait grâce à elles des personnels de statut privé. À ce compte, des dizaines de directeurs d'unités de recherche rattachées à des organismes publics devraient être traduits en justice, ainsi que les agences et associations qui les soutiennent. Un chercheur soucieux de faire de la recherche avec efficacité ne peut en effet s'en remettre pour le fonctionnement de son équipe aux délais imprévisibles et aux méandres de procédure courtelinesques d'un organisme public : il créera donc une association, au compte de laquelle il fera verser ses subventions de recherche. Il est indéniable qu'une fois qu'un tel dispositif a été mis en place pour échapper à une réglementation inapplicable, il peut être utilisé pour le meilleur comme pour le pire, pour la recherche comme pour le détournement. Quant aux agences de financement, elles versent des bourses qui permettent de rémunérer, en dehors de tout système de protection sociale, des personnels qui n'ont pas trouvé place dans les corps statutaires --- bref, c'est du travail au noir, encore plus que dans le cas des personnels temporaires employés par l'administration sous le nom de vacataires, un non-statut qui conduirait rapidement devant les tribunaux le dirigeant d'entreprise qui aurait l'idée de s'en inspirer pour ses propres salariés.

Dans le domaine du bâtiment et des travaux publics, les liens traditionnels et cordiaux qui associent en France les entrepreneurs et les notables et politiciens locaux permettent d'aplanir bien des difficultés administratives. Il faut dire que les élus locaux, qui ont besoin d'obtenir des résultats tangibles pour être réélus dans un délai de cinq ou six ans, n'entendent pas se laisser mettre des bâtons dans les roues par les membres de la fonction publique territoriale, et qu'ils disposent de moyens de pression plus efficaces que ceux des chercheurs.

Pour nous résumer, le dispositif français des marchés publics est une calamité. Dans un contexte où plus de la moitié du PIB passe par le budget de l'État d'une façon ou d'une autre un système aussi anachronique et inefficace constitue un boulet que la nation traîne à son pied ; il est dans ces conditions miraculeux que la France figure encore au nombre des cinq ou six pays les plus riches de la planète, et cela donne une idée des efforts considérables consentis par les entreprises privées et leurs salariés pour surmonter un tel handicap.
données 2003, source INSEE et Min. Éco. Fin. milliards d'Euros
PIB français 1 560
marchés publics 130
rémunération des fonctionnaires de l'État 216
Total des dépenses des administrations publiques 851


Quels sont les services publics « rentables » ?

Pour parler comme les informaticiens, nous pouvons identifier un « effet de bord », c'est-à-dire une conséquence non intentionnelle de la réglementation des marchés publics : les administrations ne disposent d'aucun moyen pour envisager la notion d'investissement. Le connaisseur des comptes publics aura sans doute sursauté à cette assertion : il faut donc que je précise le propos. Effectivement, les plans comptables utilisés par les services publics comportent bien des comptes d'investissement. Ce qui en est absent, c'est le moyen de rapprocher une rentrée d'argent d'une dépense, pour associer par exemple un investissement à la ressource qui l'a autorisé, ou aux ressources ultérieures qu'il a permis de réunir. Je n'ignore pas que cet état de fait a des raisons : il ne sied pas que la façon dont l'État collecte tel impôt soit associée de façon obligée à tel type de dépense. Simplement, la comptabilité publique est conçue plus pour le contrôle de la conformité des opérations aux règlements que pour l'efficacité de la gestion, et cette façon de tenir des comptes a des inconvénients, notamment elle ne favorise pas la bonne appréhension des investissements. Or toute une partie de l'enjeu qui est en cause pour savoir si l'informatisation va réussir ou échouer, c'est de savoir si on va la considérer comme une charge (et alors on échouera), ou comme un comme un investissement, ce qui lui donnera quelques chances de succès.

Pendant les deux années que j'ai passées au sein de l'administration centrale du Ministère de l'Économie et des Finances, j'ai observé un effet curieux mais à mon avis pervers et gravissime de cette vision : la Direction Générale des Impôts, la Direction de la Comptabilité Publique et la Direction Générale des Douanes et des Droits Indirects étaient considérés comme les services « rentables » de l'administration, par opposition aux services « dépensiers » comme la Santé, l'Éducation nationale, etc. C'est un peu comme si, chez Renault, on considérait que le service comptable était celui qui faisait vivre la société. En fait, si les contribuables français acceptent bon gré mal gré de payer leurs impôts sans trop égorger de percepteurs, c'est bien parce qu'une pratique démocratique de longue durée leur a enseigné que cet argent qu'ils ont du mal à payer leur reviendra un jour sous la forme d'écoles pour leurs enfants, de routes et d'hôpitaux, de police et de défense nationale. Les administrations financières ne sont dans tout ceci qu'un rouage utilitaire subalterne, dont le coût devrait être allégé au maximum, alors qu'elles sont les mieux traitées, en dotation budgétaire comme en primes pour le personnel. C'est assez aberrant, pour rester sobre.



4  Projet et cahier des charges

Jean-Pierre Boutinet[15] 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éalisation2. 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[88] 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 (voir page ??). 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'oeuvre, 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 »[20], 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 oeuvre 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'oeuvre, 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[19] ; 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[20], 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 ».

Figure 2.1 : 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'oeuvre 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'oeuvre, 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'oeuvre 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[79].

     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 ci-dessous à la page ?? 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é :
    risque =
    menace × vulnérabilité × sensibilité
    contre-mesure
    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épense3. 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 oeuvre 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, à la fin des années 1960, à 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[61] 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 pas de toucher aux ordinateurs, et une affectation opérationnelle où je pourrais toucher aux ordinateurs4 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 à la page ??, 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 : Une fois que la décision de lancer le projet a été prise :
  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 ci-dessous page ?? 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 [33], 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 à la page ??). 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
Que dire de la justice administrative ! Il est permis de s'interroger, et sur le sens de la locution, et sur le bien-fondé de l'instance qu'elle désigne. L'administration ne pourrait-elle répondre aux mêmes tribunaux que les simples citoyens ?
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
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[101] m'a appris que l'administration fédérale américaine souffrait du même mal.
4
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 de la machine plusieurs semaines à l'avance.
© copyright Éditions Vuibert & Laurent Bloch 2004, 2005
Page d'accueil de ce livre
Précédent Remonter Suivant