Avant-propos

L'observation du fonctionnement et des effets de l'informatique dans les secteurs de l'activité humaine qu'elle affecte (c'est-à-dire à peu près tous) révèle des succès et des échecs qui ne sont pas répartis au hasard. L'Internet, le logiciel de pilotage des Airbus, celui des téléphones portables sont des succès considérables. Les Systèmes d'Information de gestion des entreprises sont en revanche souvent des échecs ou du moins des déceptions, cela malgré une complexité technique moindre et un domaine mieux connu, en apparence du moins. Ce livre se propose d'avancer quelques hypothèses sur l'origine de ces disparités.

Dès que l'informatique fut employée à la gestion des entreprises se posa la question du coût des ordinateurs (dont il ne sera pas question ici) et de leur programmation, sujet traité dans ce livre. La création d'un logiciel se révéla difficile, longue, chère, pour un résultat incertain.

Les premières tentatives de maîtrise des coûts furent tayloriennes et échouèrent. Le modèle d'organisation en vigueur depuis une vingtaine d'années est le « mode projet » ; s'il a incontestablement permis aux sociétés de services d'améliorer la gestion de leur personnel et de limiter les risques de contentieux avec leurs clients, il n'a pas accru de façon significative le taux de satisfaction de ces derniers : ce taux plafonne en dessous de 40%, valeur que n'accepteraient aucune industrie ni aucun service. La « démarche qualité », censée consolider l'ensemble, aboutit souvent à la bureaucratie et finalement grève les budgets sans bénéfice réel.

Sera développée ici l'hypothèse que cet insuccès fréquent procède d'une mauvaise compréhension de la nature même du travail de réalisation d'un logiciel. L'échec survient lorsque la dimension intellectuelle de ce travail n'est pas reconnue et que la difficulté relative de ses différentes composantes est mal évaluée. La thèse centrale de ce livre énonce que la programmation n'est pas une fabrication, mais un acte de conception, et des plus complexes : c'est cet acte qu'il s'agit de comprendre et d'accomplir.

Cela pose la question du rapport paradoxal entre travail et pensée : pour accomplir un travail qui comporte une part de conception, il faut penser, mais un travailleur expérimenté peut (et même doit) accomplir certaines phases de son travail sans avoir à y penser, ce qui lui permet d'être rapide. Le logicien anglais Alfred North Whitehead a même pu écrire, dans une perspective plus générale, « civilisation advances by extending the number of important operations which we can perform without thinking about them » (« la civilisation progesse dans la mesure où le nombre de choses importantes que nous pouvons accomplir sans avoir à y penser augmente »).

La question est donc, ici comme pour d'autres travaux de conception, de savoir penser aux bonnes questions aux bons moments. Les approches bureaucratiques ignorantes de la nature du travail cherchent à éliminer toute pensée, activité coûteuse dont la rentabilité n'est pas immédiatement perceptible. D'où l'échec, que le « perfectionnement » des procédures ne fera qu'amplifier. Plusieurs approches passées et présentes seront examinées : nous verrons qu'ici comme ailleurs l'enfer est parfois pavé des meilleures intentions. L'application trop systématique d'idées parfaitement logiques peut engendrer des catastrophes.

L'examen de ces questions nous amènera à évoquer brièvement les conditions préalables qui s'imposent à toute pensée, et donc à tout travail : à l'heure où la réflexion sur les usages sociaux de l'informatique hésite entre le Charybde de la techno-science obscurantiste et le Scylla d'une nouvelle barbarie qui ne veut rien savoir des techniques qu'elle utilise, seule une véritable approche multi-culturelle peut nous aider à voir clair et à agir juste.

Les dernières années du siècle passé ont vu les cercles dirigeants des entreprises, des administrations et des collectivités publiques, en tout cas en France, détourner leur intérêt des projets informatiques pour le concentrer sur la construction du système d'information de l'entreprise. Cette nouvelle orientation correspondrait, dit-on, à un progrès dans l'assimilation des nouvelles technologies : les problèmes techniques de l'informatisation, triviaux, seraient enfin résolus, et les managers¹, au sein d'une organisation « recentrée sur son métier de base », pourraient prendre du recul et de la hauteur pour se consacrer au recueil et à la canalisation des flux d'information destinés à converger vers le tableau de bord de l'entreprise, grâce auquel le groupe dirigeant pourrait prendre en toute connaissance de cause des décisions stratégiques pertinentes.

Depuis plus de trente-cinq ans l'auteur de ces lignes participe ou assiste à de nombreux projets de création de systèmes d'information aux objectifs divers et de styles variés, avec des fortunes également diverses et variées. Il appartient à plusieurs associations professionnelles et autres types de cénacles, et participe à d'innombrables colloques et conférences, tous consacrés, sous les angles les plus inattendus ou les plus convenus, à la recherche de la meilleure façon de construire tel ou tel type de système d'information. Il a, bien sûr, lu des milliers de pages et participé à des centaines d'heures de conversation consacrées à ces sujets.

Cette participation assidue ne lui a pas apporté la conviction que les problèmes techniques de l'informatisation fussent résolus, même s'ils ont changé d'aspect. L'ambition panoptique du système d'information intégré lui semble pour le moins questionnable, et le présent ouvrage posera cette question. Quant à la phraséologie du recentrage sur le métier de base, que l'on pourrait traduire par « persévérer dans la routine et mettre tous ses oeufs dans le même panier », nous essaierons de savoir qui la produit et à qui elle profite.

Par ailleurs, le monde a vu la construction de réalisations informatiques grandioses telles que l'Internet et tous les systèmes informatiques embarqués qui animent désormais les appareils de notre vie quotidienne, de la console de jeux à l'automobile. Il faudra aussi déterminer les différences, éventuellement explicatives, entre ces projets couronnés de succès et ceux des alinéas précédents, voués à un échec apparemment inéluctable.

Trois classes de systèmes informatiques

Avant d'entamer ce livre il convient de donner une précision : les systèmes informatiques sont envisagés classiquement comme répartis en deux classes, ceux qui sont destinés à faire fonctionner les systèmes d'information des organisations, que nous regrouperons dans la classe 1, et ceux qui assurent la commande et le contrôle des systèmes techniques (trains, avions, téléphones, etc.) rangés dans la classe 2. Il faut à notre avis créer une classe 3 qui regroupe les systèmes destinés à faire fonctionner l'informatique elle-même : systèmes d'exploitation, systèmes de développement, compilateurs, systèmes de gestion de configuration et logiciels de réseau. Ces trois classes de systèmes sont dotées chacune de leur culture technique propre, et les personnes qui travaillent dans chacun de ces domaines sont issues de formations différentes, ont des habitudes de travail différentes et répondent à des analyses sociologiques différentes. Le présent ouvrage est essentiellement consacré aux systèmes de la classe 1, et il n'y sera question de ceux des autres classes qu'incidemment, pour mettre en lumière ce qui les distingue de la classe 1, et pourquoi. Nous pouvons annoncer dès cet avant-propos que les systèmes de classe 1 sont ceux qui rencontrent le plus souvent l'insuccès, bien qu'ils soient les moins complexes sur le plan technique. Il semble bien que les difficultés rencontrées par leurs maîtres d'ouvrage et par leurs maîtres d'oeuvre soient d'ordre sociologique plus qu'informatique, et c'est ce qu'il nous faudra examiner.

Il existe des logiciels qui n'entrent dans aucune de nos trois classes, comme par exemple les logiciels généraux (traitement de texte, progiciels de bases de données...) ou les logiciels scientifiques développés par des chercheurs pour leurs besoins propres : ce sont des logiciels autonomes, qui ne constituent pas des systèmes, même s'ils peuvent en être une partie ou un composant. Un système se caractérise par l'intégration de plusieurs composants complexes[75].

Le poids des obstacles

Le projet de se doter d'un système d'information, même si l'on en admet la légitimité, est fréquemment l'occasion de malentendus et d'erreurs de méthode qui engendrent retards et dépenses imprévues, quand ce ne sont pas échecs et frustrations. En fait, les études classiques menées sur ce sujet de façon récurrente par de grands cabinets internationaux tels que le Standish Group[99][100] ou le Gartner Group[85] égrènent la litanie de taux d'échec ahurissants (seuls 34 % des projets atteindraient les objectifs fixés), et ce sans que l'écoulement du temps, scandé par l'apparition de nouvelles méthodologies et de nouveaux principes organisationnels jaillis de l'imagination fertile des cabinets de conseil et des universitaires, semble apporter un progrès qui soit à la mesure des promesses. Ces études sont internationales, mais les projets français ne s'y distinguent pas par l'excellence, loin de là. L'édition 2003 du rapport Standish porte sur treize mille cinq cents projets ; 15% sont purement et simplement des échecs, les dépassements budgétaires sont en moyenne de 43%. La liste des causes d'échec est une véritable rengaine : devis incomplets, mauvaise participation des utilisateurs, cahiers des charges délirants établis par la maîtrise d'ouvrage, modifications intempestives des spécifications...

Aucun auteur ou propagateur d'une méthodologie ancienne ou nouvelle ne manque de faire état de ces chiffres catastrophiques pour inciter son lecteur ou son auditeur à s'engager dans la voie supposée salvatrice dont il dépeint les cheminements lumineux.

L'idée qui conduit ici la plume de l'auteur est que ces échecs dans l'édification d'un système d'information destiné à gérer l'entreprise sont prévisibles et destinés à se reproduire. C'est le succès qui serait un accident. D'ailleurs beaucoup de succès proclamés sont en fait moins éclatants si l'on va y voir de près. Qui souhaite proclamer qu'il a échoué ? Tout pousse à l'embellissement des résultats.

Pourquoi cette persistance dans l'insuccès, depuis si longtemps ? Parce qu'un système d'information, aussi « stratégique » soit-il, n'est jamais qu'une combinaison de systèmes informatiques, et que la construction sûre de systèmes informatiques robustes est toujours une entreprise incertaine. Parmi les nombreuses plaisanteries professionnelles des informaticiens, l'une énonce que si les architectes et les urbanistes construisaient les villes comme les informaticiens construisent les logiciels, un pivert pourrait détruire la civilisation. On ne saurait mieux dire. Il n'empêche, aujourd'hui la civilisation incorpore beaucoup de systèmes informatiques, et pour être juste il faut dire que beaucoup fonctionnent finalement assez correctement, ceux que nous évoquions quelques lignes plus haut par exemple : l'Internet, les jeux électroniques, le système de pilotage du métro Météor... Pourquoi réussit-on mieux à faire fonctionner des jeux électroniques que des logiciels de gestion comptable ? Pourtant la programmation de jeux est bien plus complexe et mobilise des connaissances scientifiques bien plus rares que celle des applications de gestion. Nous aurons bien sûr à examiner cette question.

Pourquoi en sommes-nous là, près de soixante ans après l'invention de l'ordinateur ? Parce que la nature du travail de construction de logiciels informatiques n'est pas correctement comprise, et du coup l'organisation de ce travail est, très souvent, conçue selon des plans erronés. La mauvaise compréhension de la nature du travail conduit à le confier à des personnes qui ne sont pas forcément les plus appropriées, qui ne reçoivent pas forcément la formation souhaitable, dont les objectifs ne sont pas fixés selon des critères pertinents, etc.

Pour essayer de comprendre cette situation d'échec dans des projets pourtant abordés avec des motivations fortes et des moyens parfois pharaoniques, nous essaierons de mieux comprendre la nature du travail en général, et du travail de réalisation de systèmes informatiques en particulier. En proposant certains éléments d'explication de ces échecs, nous mettrons au jour ce qu'il faut bien appeler des facteurs de sous-développement au sein de nos sociétés qui se perçoivent pourtant plutôt comme développées.

La liste de tous ceux à qui ce livre doit quelque chose serait trop longue pour que je prenne le risque, en la dressant, d'en oublier trop. Je citerai seulement Dominique Sabrier, pour ses relectures toujours précises et d'une exigence judicieuse, et mes collègues de l'INSERM, dont le travail a été pour moi un objet constant de réflexion. Merci à Marc Jammet, des Éditions Vuibert, pour son ouverture d'esprit et sa confiance renouvelée. Le Club des Maîtres d'Ouvrage[27], sous le magistère éclairé de Michel Volle et la présidence de Jean-Marie Faure, a été pour moi une source d'inspiration d'une vivacité incomparable. Les passages de ce livre qui doivent à Michel Volle un conseil, un éclaircissement ou une contribution sont trop nombreux pour que je puisse les indiquer tous. Françoise Hamsa, Éric Julliard, Hakim Saad, Michel Gaudet, Manuel Serrano, Benoît Picaud, Isabelle Perseil, Juliette Poupard et Marcel Moiroud ont relu, utilement commenté, conseillé et encouragé. Mon ami et collègue William Saurin a procuré les objections acerbes qu'il convenait de relever, et apparaît secrètement comme un personnage de ce livre. Mon ancien collègue Jean-Jacques Kasparian a exercé une influence à longue distance, et apparaît lui aussi comme personnage. La responsabilité des erreurs qui subsistent néanmoins dans ce texte ne peut être imputée qu'à l'auteur. Ce livre a été écrit, composé et mis en page au moyen de logiciels libres, notamment Linux, GNU/Emacs, TeX et L^AT_EX : il convient d'en remercier ici les auteurs et contributeurs, dont le travail désintéressé élargit le champ de la liberté d'expression.

Une grande partie de ma vie professionnelle s'est déroulée au sein du service public ou dans sa proximité. Beaucoup d'exemples de ce livre sont donc pris dans la pratique des administrations et des établissements de recherche. Mes critiques à l'égard de leur fonctionnement administratif ne sont pas faites dans un esprit polémique, leur but unique est d'éclairer des écueils pour permettre, peut-être, de les éviter. Les concepteurs et constructeurs de systèmes d'information pourront aussi trouver que je n'ai guère d'indulgence pour leur travail : bien au contraire, c'est du spectacle de leur entreprise pleine d'espoir face à des obstacles considérables qu'est né ce livre, qui est un essai pour indiquer quelques chausse-trappes et mauvaises pistes à éviter.

L'italique est utilisé pour la définition d'un terme caractéristique du sujet traité, ou pour un mot étranger, ou pour un nom de marque.

Les termes en style machine à écrire sont des mots de langages informatiques (il n'y en a que très peu, à titre d'exemples).
Des matériaux complémentaires au texte de ce livre, notes, commentaires ou références, sont disponibles sur le site WWW de l'auteur, sous la rubrique qui porte le même titre que ce livre :
http://www.laurent-bloch.org/

1: Que le lecteur se rassure, l'auteur de ce livre fuit les anglicismes, mais veut rétablir dans la langue française de vieux mots qui ont connu meilleure fortune outre-Manche ou outre-Atlantique, comme manager (qui n'est autre que « ménager », et qu'il convient de prononcer « ma-na-jé ») ou challenge.