Page d'accueil de ce livre
Nous avons essayé de montrer que, avant de réfléchir au pourquoi et au
comment d'un projet informatique, il faut avoir à l'esprit un certain
nombre de caractères propres au logiciel : il est abstrait, invisible
et infiniment malléable ; lors de son élaboration, pour prendre le
contre-pied d'une métaphore usuelle mais fallacieuse qui compare la
réalisation de logiciels à celle de bâtiments, il sera possible de
modifier le plan et les fondations au moment d'attaquer le deuxième
étage ! En outre, le logiciel est complexe : cette complexité est dans
sa nature ; un logiciel simple, au sens où par exemple il serait
constitué par la répétition d'un petit nombre d'éléments identiques,
n'aurait aucun intérêt.
L'idée que la programmation n'est pas une fabrication, mais un acte de
conception, et des plus complexes, découle de la nature abstraite du
logiciel ; cette idée est au centre de ce livre, comme le lecteur aura
pu le constater. On peut le dire autrement, comme Paul
Graham[48] par exemple : « En programmation, comme dans
beaucoup d'autres domaines, la difficulté n'est pas tant de résoudre
les problèmes que de choisir les problèmes à résoudre ». Il s'agit là
de la programmation entendue dans un sens assez large, qui englobe
aussi bien le paramétrage d'un progiciel que l'assemblage de plusieurs
logiciels pour réaliser une application ; on aurait tort de prendre à
la légère de tels travaux, ils posent des problèmes intellectuels du
même ordre que l'écriture d'un logiciel à partir d'une feuille de
papier blanc.
De cette réhabilitation du travail de programmation, souvent dévalué
ou sous-estimé, découle une conséquence qui ne paraîtra décourageante
qu'aux porteurs d'espoirs déraisonnables : la programmation n'est pas
industrialisable, elle est vouée à rester un artisanat. Les méthodes
de cet artisanat pourront progresser, grâce par exemple à de meilleurs
langages, à de meilleurs environnements de développements, à des
systèmes de preuve plus puissants qui déplaceront l'effort du
programmeur plus loin du concret technique et plus près du problème
abstrait, mais la nature fondamentale de son activité demeurera
artisanale. Cela n'est pas dû à de mauvaises méthodes de travail et
d'organisation, dont l'amélioration ouvrirait la voie à
l'industrialisation : ce caractère artisanal est intrinsèque à la
programmation, et je soutiens l'idée que cet état de fait tient à des
raisons fondamentales, inhérentes à la nature de la pensée humaine
et à celle de l'activité de programmation des ordinateurs.
L'adoption de ce point de vue conduit logiquement à abandonner un
certain nombre de pratiques, dont je me suis employé à analyser les
faiblesses : organisation d'une division taylorienne du travail
informatique, externalisation massive (comme s'il s'agissait du
nettoyage et du gardiennage des locaux), constitution de grandes
équipes organisées en ateliers dans l'espoir de réaliser des économies
d'échelle comparables à celles que la grande industrie des XIXe
et XXe siècles a obtenues dans des contextes et des domaines
très différents. Il faut aussi renoncer aux grandes visions
bureaucratiques de gestion de l'activité de développement : méthode
canonique de gestion de projets, démarche qualité conforme à ISO 9000.
Examiner ces questions nous a mené à un regard critique sur deux
tendances de fond des sociétés développées depuis un siècle et demi au
moins : l'accroissement tentaculaire de la
bureaucratie et les abus de la division du
travail. Ces deux mouvements ont depuis longtemps déjà entraîné la
sclérose des services publics de l'État, du moins en France ; les
grands groupes industriels et financiers ne sont pas non plus à l'abri
de ce phénomène. Cette bureaucratie des grandes structures fait peser
un poids énorme sur l'ensemble de la société, qui se répercute
particulièrement sur les petites et moyennes entreprises. Les
structures de la recherche scientifique et de l'enseignement ne sont
pas épargnées par ces maladies modernes, dont un des symptômes est
l'imitation de travail décrite de
façon approfondie par Alexandre
Zinoviev[128] et que nous
avons évoquée à la page ??.
Pourquoi ces questions relèvent-elles de la problématique du système
d'information ? Par deux aspects :
-
le système d'information des entreprises est au coeur des
appareils productifs contemporains, et par là il fournit une
contribution majeure aux formes de la bureaucratie et de la division
du travail ;
- les maîtres d'ouvrage des systèmes d'information ont tenté, de
diverses façons, d'appliquer ces mêmes formes de la
bureaucratie et de la division du travail à la construction de
systèmes d'information.
C'est surtout le second de ces deux aspects, l'effort pour appliquer
des principes tayloriens et bureaucratiques au développement
informatique, qui a fait l'objet du présent ouvrage ; nous avons
essayé d'illustrer la vanité de ces tentatives, et leur échec.
Si le développement informatique ne se prête pas à l'industrialisation
et doit rester artisanal, il convient d'en tirer les conséquences sur
le plan de l'organisation. Les grands projets menés avec des effectifs
importants organisés selon une hiérarchie complexe accumulent les
occasions d'échec, ce que l'expérience confirme. Les projets de taille
moyenne menés par de petites équipes très intégrées ont de bien
meilleures chances de succès. Il est donc judicieux de se rapprocher
le plus possible de ce modèle d'organisation. Pour ce qui est des
rapports avec le client final ou son représentant, il n'y a que deux
hypothèses viables : soit il s'implique totalement dans l'équipe, y
compris jusqu'à un certain point dans les aspects techniques
(scénarios, tests, validation), soit il reste à distance. Le client
qui chaque lundi matin téléphone pour communiquer à l'équipe de
développement les modifications de spécifications dont il a eu l'idée
pendant le week-end conduit son projet à un échec certain, ce qui
n'empêche pas ce comportement d'être très courant. Or justement les
spécifications changent, parce que les circonstances de la vie changent ;
deux conséquences en découlent :
-
L'implication forte du maître d'ouvrage ou de son mandataire est indispensable si l'on veut
développer un système adapté à un besoin du client (par opposition
à un logiciel à usage général). Les logiciels dont il est question
ici sont pour l'essentiel ceux que nous avons rangés dans la
classe 1 définie par notre introduction (page ??),
c'est-à-dire ceux qui sont destinés à assurer le fonctionnement
des systèmes d'information des entreprises.
- Il faut privilégier les méthodes de développement incrémentales,
dont nous avons cité un exemple avec eXtreme
Programming,
mais il en existe d'autres.
Les grands projets de gestion offrent le paysage désolé de taux
d'échec élevés. Il faut considérer qu'un système comme Socrate à la
SNCF, qui finit par marcher après qu'ont été multipliés par deux le
budget prévisionnel et le délai de réalisation, non sans avoir
entraîné plusieurs années de désordre dans l'entreprise, est un échec.
De nombreux échecs de ce type ne sont pas ébruités si la dissimulation
est possible. Le cas de Socrate a été l'objet de débats publics et
d'analyses détaillées par des experts indépendants, ce qui permet de
savoir que les facteurs techniques n'ont compté que pour une part, et
pas la plus importante, dans les errements du projet. L'absence de
stratégie claire, l'intervention désordonnée de plusieurs groupes de
pouvoir au sein de l'entreprise, l'insuffisance de la formation
dispensée aux personnels concernés ont compté sans doute plus que les
défauts de l'adaptation du logiciel au besoin.
Les projets de notre classe 1 (systèmes d'information de gestion)
rencontrent plus souvent l'échec que ceux de la classe 2 (systèmes
techniques) ou de la classe 3 (infrastructures informatiques). Nous
avons évoqué plusieurs facteurs de nature à expliquer cet état de fait :
les systèmes de la classe 1 sont techniquement plutôt moins complexes
que ceux des classes 2 et 3, mais ils sont beaucoup plus complexes
socialement.
Pour les projets des classe 2 et 3, tous les participants appartiennent
au même univers intellectuel, ce sont pour l'essentiel des ingénieurs
qui parlent le même langage, et qui se reconnaissent une obligation
morale de comprendre les problèmes techniques, même ceux qui ne sont
pas exactement de leur spécialité.
Si l'on considère un projet typique de classe 2, comme un nouveau
modèle d'avion ou une ligne de métro sans conducteur, le coût du
logiciel représente une faible partie du budget total, cependant que
son dysfonctionnement peut provoquer le naufrage complet du projet ;
de ce fait, le maître d'ouvrage ne reculera pas devant des méthodes de
développement coûteuses et le recours à des équipes de haut niveau.
Nous serions tentés de dire que les entreprises industrielles qui
n'ont pas compris cela ont disparu ou sont condamnées à brève
échéance, parce qu'un avionneur, par exemple, ne peut se dissimuler
que le logiciel de pilotage de son prochain avion doit être au
coeur de ses préoccupations. En outre, une fois qu'un projet
industriel est lancé, il est hors de question d'en changer les
spécifications tous les deux mois : en effet tout le monde comprend
bien qu'on ne peut pas passer son temps à démolir et à reconstruire
les usines.
Nous avons brièvement décrit à la page ?? un système
de classe 3 de première grandeur : l'Internet. Le projet était immense,
mais les interactions entre participants de cultures différentes étaient
limitées : les ingénieurs et les chercheurs qui bâtissaient le système
entre 1977 et 1992 en étaient les principaux utilisateurs, c'était en
quelque sorte un projet autarcique. Parler de projet est d'ailleurs
quelque peu abusif, puisque personne n'avait imaginé son aboutissement
ni son ampleur, et encore moins ses usages ! Le processus complexe
d'auto-régulation du développement qui s'est déroulé reste encore
largement à élucider, ne serait-ce que sur le plan sociologique, mais
le milieu social qui a construit l'Internet s'est construit lui-même
en même temps et par le même processus. On pourrait risquer
l'hypothèse de considérer l'Internet comme une institution
imaginaire au sens où Cornelius
Castoriadis emploie cette locution, qui
désigne le fait que toute société humaine se construit elle-même, et
que le moyen et le matériau de cette construction consistent en
significations imaginaires (construites par l'imagination) auxquelles
adhèrent les membres du corps social naissant. Bien sûr, le milieu
social qui édifiait l'Internet au cours des années 1980 n'a rien à
voir avec celui des consommateurs actuels du réseau.
La plupart des projets de la classe 3 correspondent peu ou prou au
schéma que nous venons de décrire pour l'Internet : lors de la
conception d'un système d'exploitation ou d'un compilateur, des
informaticiens parlent à des informaticiens ; les utilisateurs
finals n'interviennent pas, on ne voit d'ailleurs pas très bien
comment ils le pourraient.
Il en va tout autrement pour les projets de la classe 1, qui édifient
des systèmes d'information destinés à la gestion des entreprises. Les
maîtres d'ouvrage sont le plus souvent dépourvus de culture technique,
et le contexte est mobile --- que ce soit pour de bonnes raisons ou
par l'effet de la mode ne change pas grand chose aux conséquences de
cet état de fait. Beaucoup de gens ont voix au chapitre, notamment,
a priori et par définition, tous les secteurs de l'entreprise,
avec des préoccupations diverses que chacun exprimera dans le contexte
de son univers culturel propre : autant dire que l'établissement d'un
langage commun ne sera pas facile, et la définition d'objectifs
partagés pratiquement impossible. Un ouvrage récent[103]
donne de ces difficultés une description satirique mais finalement
assez réaliste.
Puisque la difficulté du projet de système d'information réside pour
une part majeure dans la difficulté, éprouvée par des acteurs aux
horizons culturels différents, à trouver un langage et des objectifs
communs, la sagesse semble conseiller d'éviter dans la mesure du
possible les interférences de ces acteurs entre eux, et avec le maître
d'oeuvre. Évidemment cette sagesse entre en conflit avec
l'objectif même du système d'information, qui est d'accroître la
cohérence de l'entreprise --- mais le maximum de cohérence est-il
toujours et partout le bon objectif ? Dans un établissement de
recherche, par exemple, chaque laboratoire poursuit des activités
autonomes, et la coordination peut sans doute se limiter à
l'identification des synergies utiles sur le plan scientifique, qui
seront d'ailleurs souvent avec des laboratoires extérieurs à
l'établissement, et à la création de services communs efficaces. La
collecte et la consolidation des informations nécessaires à la bonne
administration de la recherche n'imposent sans doute pas une
centralisation générale. Beaucoup d'entreprises se trouveraient sans
doute très bien d'une gestion assez décentralisée, et la mode des
progiciels de gestion globale de l'entreprise, qui sévit depuis
quelques années, n'est sans doute que l'effet d'une propagande
efficace des fournisseurs auprès de dirigeants financiers qui y ont
vu, non sans raison, un moyen d'étendre leur pouvoir : il semble bien
aujourd'hui que le bilan du déploiement de ce genre d'outil se révèle
assez peu favorable. Il serait sans doute sage de revenir à des
solutions de gestion à centralisation modérée, qui n'imposent aux
acteurs de l'entreprise que la cohérence nécessaire, déterminée avec
doigté.
Il faut souligner ici que la complexité d'un système informatique de
gestion n'est que la conséquence de la complexité de l'univers à gérer :
il faut certes éviter que les logiciels n'accroissent arbitrairement
celle-ci, mais il est vain d'espérer qu'ils puissent à eux seuls la
réduire --- la simplification éventuelle des procédures de gestion ne
pourra résulter que d'une action sur l'organisation, rendue possible
peut-être par l'informatisation, et à laquelle les logiciels
contribueront. Toute informatisation doit être précédée d'une remise
en cause de l'organisation et de la gestion au plus haut niveau, faute
de quoi on aboutit au mieux à une préservation de l'existant qu'il
aurait justement fallu modifier, au pire à un accroissement
significatif et parfois fatal du désordre.
Il résulte de cette dernière proposition, comme nous l'avons déjà
souligné, qu'il convient d'identifier clairement les rôles respectifs
de la maîtrise d'ouvrage et de la maîtrise
d'oeuvre et d'assurer l'équilibre entre
ces deux pôles. La disparition ou l'affaiblissement excessif de l'un ou
de l'autre conduirait le projet à l'échec.
Une autre conclusion de nos observations relatives au rôle et à la
place du système d'information, c'est que tout responsable d'entreprise
devrait posséder un minimum de compétence en système d'information, et
partant en informatique. Dans beaucoup de pays cela va de soi, mais
pas dans le nôtre, semble-t-il. Il existe bien en France une « fracture
numérique », mais elle n'est pas forcément où on le croit, ses
victimes (qui en sont aussi les coupables) sont à chercher au sommet
de la hiérarchie sociale, au sein des élites économique, culturelle et
sociale, où l'on pense que toucher un clavier d'ordinateur, acte
technique et partant subalterne, serait déroger à son rang.
© copyright Éditions Vuibert & Laurent Bloch 2004, 2005
Page d'accueil de ce livre