Page d'accueil de ce livre
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 managers1, 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 LATEX : 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.
© copyright Éditions Vuibert & Laurent Bloch 2004, 2005
Page d'accueil de ce livre