Peut-on croire les informaticiens? Ou: de la rationalité des

1998.10
Peut-on croire les informaticiens? Ou: de la rationalité des
anticipations concernant les technologies de l’information
Jean-Louis Peaucelle
Professeur à l’IAE de Paris
Résumé : Comme pour les autres projets, la conception et le développement des applications informatiques donnent lieu à des prévisions, afin de jauger le projet, de manière prévisionnelle, avant de s’y engager. Ces anticipations portent sur les coûts pour les inscrire dans des
budgets. Elles portent aussi sur les usages afin de calculer une rentabilité prévisionnelle. Or les
informaticiens ont une tendance à l’optimisme. Les coûts affichés au départ sont sous évalués
et les gains surestimés. Le projet Taurus à la bourse de Londres et le projet Socrate à la SNCF
sont présentés dans cette optique de management de projet. L’auteur montre comment les décisions fondées sur la rentabilité prévisionnelle sont vulnérables à l’exactitude des chiffres
utilisés. Il conclut sur des conseils adressés aux pilotes des grands projets informatiques.
Mots clés : Bénéfices de l’informatique, gestion de projet, glissement de projet, abandon de
projet, Taurus, Socrate.
Abstract: The design and development of computer applications, as for other project
oriented endeavors, involves the use of forecast in order to provide a preliminary evaluation
prior to undertaking a definitive commitment to the project. The expectations inherent in such
forecast pertain to the costs to be budgeted as well as to the eventual uses of the developed
product, thereby resulting in a projected level of profitability. In this respect, computer professionals tend to be overoptimistic. The costs announced up front get underestimated and the anticipated returns overestimated. The Taurus project at the London Stock Exchange, along with
the "Socrate" project implemented by France’s SNCF Railway Company, have presented herein
from a project management perspective. The author highlights how decisions based on
projected profitability are indeed vulnerable to the accuracy of the figures used. In its conclusion, this paper provides a set of recommendations for those leading major computer-related
projects.
Keywords: Benefits of IT, project management, project, project reevaluation, project
failure, Taurus, Socrate.
1
La crise du logiciel
Même si les technologies de l’information se présentent au public comme des technologies
heureuses où les progrès se succèdent et où les volumes d’affaires s’envolent, tout n’est pas rose
dans l’industrie informatique. Les spécialistes du génie logiciel parlent entre eux d’une "crise
du logiciel". Crise sociale parce que les utilisateurs rejettent des programmes de qualité insuffisante (non-conformité aux besoins, erreurs, rigidité, complication). Crise économique aussi
parce que les coûts annoncés sont rarement tenus, parce que les dates de mise à disposition sont
sans cesse retardées. Crise de capacité de production parce que les programmeurs sont trop peu
nombreux pour les projets envisagés.
Les informaticiens cherchent des solutions dans leurs propres outils: progiciels, langages de
quatrième génération, ateliers de génie logiciel, programmation objet, réutilisation de modules,
prototypage. Ils veulent améliorer à la fois la productivité des développeurs de programmes et
la qualité du résultat. Mais il n’est pas sûr que ces solutions modifient réellement la situation.
IAE de Paris (Université Paris 1 - Panthéon - Sorbonne ) - GREGOR - 1998.10 -
2
Un spécialiste du génie logiciel américain dressait devant ses pairs un tableau très sombre de
la situation (Yourdon, 1993 [20]). D’après lui
- 10 % des projets sont conformes aux prévisions,
- 60% des projets dérapent largement,
- le projet moyen dépasse son budget de 100 %,
- le projet moyen est en retard de 1 an.
D’autres avancent que, dans l’administration américaine, près de 50 % des logiciels livrés ne
sont jamais été utilisés. L’industrie du logiciel semble être marquée par le gâchis.
Ce thème est repris par Brynjolfsson (1993 [3]) comme une des raisons permettant d’expliquer que la productivité du travail n’augmente pas aux USA malgré la croissance des investissements réalisés en informatique ("paradoxe de Solow"). Trop d’erreurs et de gâchis obéreraient
les effets positifs des technologies de l’information.
C’est dans cette perspective très large que se situe cet article. Les coûts et de délais des
projets informatiques correspondent rarement à ceux qui avaient été prévus. Pour rendre ceci
plus concret, on va analyser le cas de deux grandes applications pour lesquelles cette discordance est flagrante. Ce choix correspond à la méthodologie de Karl Weick qui a renouvelé notre
approche des organisations grâce à l’analyse du rapport de la commission d’enquête nommée
après un accident d’avion.
Cette partie descriptive sera complétée par un modèle de la dynamique de la décision rationnelle en cas de gonflement progressif des coûts. L’optimisme initial des informaticiens force les
décisions en leur faveur et obère la rentabilité des projets.
À partir de ces résultats, deux questions se posent aux sciences de gestion pour aider les
entreprises. Quels raisonnements aideraient les dirigeants pour éviter les gâchis informatiques?
Par quelle attitude les chefs de projets informatiques peuvent-ils réduire le risque des projets et
construire une meilleure confiance en ce qu’ils entreprennent?
Tout d’abord rappelons qu’il existe des prévisions concernant l’informatique qui sont parfaitement réalisées. Depuis la fin des années quatre-vingt, on annonce, sous le nom de "loi de
Moore", que la puissance et la capacité des micro-ordinateurs doubleront tous les dix-huit mois.
Cette loi a été vérifiée et l’innovation a eu plutôt tendance à s’accélérer. Parallèlement, le coût
des micro-ordinateurs décroît à puissance constante. L’indice INSEE PVIN270100-90T fait
apparaître une baisse de 30 à 40 % par an depuis le début de son calcul, même si le surcroît de
puissance à prix égal est consommé par les logiciels, de plus en plus gourmands mais offrant de
nouvelles fonctions. Sur ce point les industriels semblent maîtriser l’évolution.
2
Les écarts entre prévisions et réalisations
Dans les entreprises, on tente de maîtriser les développements informatiques par le jeu classique de la prévision et par la constatation des résultats. Mais les écarts sont si importants qu’ils
bouleversent les habitudes du contrôle de gestion. Les entreprises ne sont pas disertes sur les
aventures malheureuses qu’elles ont connues. Direction générale et direction informatique sont
d’accord pour cacher les historiques des projets. On pilote sans mémoire, en effaçant les anticipations antérieures, en re planifiant sans cesse.
Parfois ce souci du secret n’est plus possible. Dans le cas du système Socrate de la SNCF,
c’est la Cour des Comptes qui a mené une étude et la rend publique dans son rapport de
1996 [4]. Les chiffres du projet, déjà un peu connus dans la presse, deviennent affichés officiellement.
En Grande Bretagne, le projet Taurus abandonné par la Bourse de Londres en 1993 a fait
aussi l’objet de diffusion d’information par la presse spécialisée. Un ouvrage [5] y a été
consacré et on y puise largement pour comprendre ce cas d’échec informatique.
IAE de Paris (Université Paris 1 - Panthéon - Sorbonne ) - GREGOR - 1998.10 -
2-1
3
Taurus
La Bourse de Londres a renoncé en mars 1993 au projet informatique Taurus qui devait
assurer complètement le suivi de l’exécution des transactions. Ce système avait coûté directement 60M£ et les opérateurs sur le marché avaient dépensé 400M£ pour y adapter leurs propres
logiciels. Cet échec informatique, étudié par Helga Drummond (1996 [5]), est exemplaire de la
dérive des prévisions des projets informatiques.
Les archives du projet étant inaccessibles à la Bourse de Londres, Helga Drummond a utilisé
trois sources de renseignements: les articles de journaux qui ont couvert le projet depuis le
début, les documentations fournies officiellement sur le projet et des entretiens avec la plupart
des protagonistes du projet. Ceux-ci ont accepté de parler plus ou moins volontiers. Au-delà des
faits qu’ils rapportent, leur opinion change avec l’éloignement des événements. Tout d’abord ils
sont soulagés par la décision d’abandon, quelques années plus tard, ils regrettent de ne pas être
allé jusqu’au terme du projet.
Le projet Taurus était mené par une équipe technique qui en 1993 a comporté 360 informaticiens. Celle-ci était contrôlée classiquement par un comité (SISCOT, Securities Industry Steering Committee On Taurus) composé des parties intéressées, avec à leur tête le directeur de
projet. Trois personnes se sont succédé à ce poste de 1986 à 1993. Au début, ce groupe avait peu
de pouvoir et il est remplacé par un bureau plus actif dans ses actions de contrôle en
septembre 1991.
Le projet Taurus a commencé en 1986. La prévision initiale indique un coût de 6M£ pour des
gains de 1700 emplois qui permettraient de diviser par trois le coût des transactions sur le
marché boursier. Le projet devait démarrer en mai 1989. Entre temps la Bourse de Londres a été
bouleversée par le crash d’octobre 1987 où des actions pour un montant de 13 Milliards de
Livres n’ont pas été payées par le système de règlements (il a fallu dépenser 200M£ pour
redresser la situation). Évidemment, on attendait Taurus pour que ces faits ne puissent se reproduire. On va fonder les plus grands espoirs sur lui et on va le compliquer. Mais alors les prévisions initiales sont complètement dépassées. En 1988, le budget prévisionnel atteint 60M£ pour
un système à la limite de la capacité des plus gros ordinateurs de l’époque. Le démarrage n’aura
pas lieu en 1989.
Ce premier projet est alors renommé Taurus 1. Il coûte trop cher, on étudie d’autres variantes.
Une solution prudente nommée Taurus 3 prévoit de dépenser 15M£ et de livrer le système en 6
mois. Son inconvénient est de s’appuyer sur une identification des intervenants sur le marché,
ce qui n’était pas le cas auparavant.
En mars 1989, le projet Taurus est complètement réorienté vers la dématérialisation des
actions. Il affiche un coût prévisionnel de 15M£ et des gains de 100M£ par an. Mais le mois
suivant, un rapport de Touche and Ross estime que les gains seraient au mieux de 18M£ par an
et peut être de 6M£.
En décembre 1990, le coût prévisionnel atteint 50M£. En novembre 1992 on prévoit 60M£
de dépenses et en janvier 1993 on parle de 80M£. Les coûts ne cessent de déraper. La figure 1
montre cette évolution en fonction de la date de prévision. La baisse du coût de l’automne 1988
correspond à l’abandon du projet Taurus 1. Mais ensuite le coût ne cesse de croître à nouveau,
avec des oscillations dépendant des sources d’estimation (experts extérieurs ou responsables du
projet).
Parallèlement, la date de fin du projet dérape. Dans la figure 2, la date de fin prévue est reliée
à la date de la prévision. Le moment du démarrage s’éloigne au fur et à mesure que le temps
s’écoule. Si on prolonge la tendance, le démarrage aurait lieu en avril 1997, mais quel en aurait
alors été le prix?
Les estimations du projet ne sont pas fiables. De la même manière, les gains annoncés
oscillent entre 6M£ par an et 100M£, selon les moments et selon les sources (experts extérieurs
ou partenaires du projet).
IAE de Paris (Université Paris 1 - Panthéon - Sorbonne ) - GREGOR - 1998.10 -
4
Figure 1 : Coût prévisionnel de Taurus selon la date de prévision, graphique établi d’après
les informations données par Helga Drummond.
dépenses annoncées en M£
80
70
60
50
40
30
20
10
abandon de Taurus 1
0
Fév-86
Jui-87
Nov-88
Mar-90
Aoû-91
Déc-92
Mai-94
date de la prévision budgétaire
Figure 2 : Date prévue de démarrage de Taurus selon la date de prévision d’après les informations données par Helga Drummond.
juin-98
date de fin prévue
extrapolation des
retards annoncés
févr-97
sept-95
mai-94
déc-92
Taurus
août-91
mars-90
nov-88
ligne d‘écoulement
du calendrier
juil-87
févr-86
oct-84
oct-84
févr-86
juil-87
nov-88
mars-90 août-91
déc-92
mai-94 date
sept-95
févr-97
de prévision
juin-98
Cette escalade des coûts, de la complexité, du retard, est exemplaire parmi les histoires informatiques, parce que le projet glisse et aussi parce que les responsables ont su l’arrêter. Elle est
IAE de Paris (Université Paris 1 - Panthéon - Sorbonne ) - GREGOR - 1998.10 -
5
interprétée par Helga Drummond selon plusieurs approches: psycho-sociale (on se fixe selon
son émotivité sur les sommes perdues et on persiste dans l’erreur), rationnelle en fonction des
coûts de l’abandon (on continue pour ne pas tout perdre). Elle met l’accent sur les représentations. Une fois construite une représentation forte du projet (elle parle de "mythe", de point de
vue dominant, non contestable), toutes les décisions allaient dans le sens de la poursuite du
projet, malgré les dérapages successifs. L’abandon intervient lorsque le responsable du projet
(non informaticien) réussit à asseoir son pouvoir et à construire une autre vision (un autre
"mythe") qui sera celle de l’abandon.
La décision d’abandon a-t-elle été la meilleure? Helga Drummond ne tranche pas. Elle se
contente de montrer les forces en jeu pour pousser le projet et puis pour l’abandonner.
2-2
Socrate
Le système Socrate (Système Offrant à la Clientèle la Réservation d’Affaire et de Tourisme
en Europe) est bien connu comme ayant eu des problèmes importants lors de son lancement le
18 janvier 1993. À l'inverse du projet Taurus, il est allé jusqu’à son terme malgré les difficultés.
Et pourtant il présente bien des similitudes. Là encore les archives du projet ne sont pas disponibles, mais en 1996, la Cour des Comptes rend publiques ses observations dans son rapport
annuel.
Les prévisions initiales, approuvées par le conseil d’administration de la SNCF le 22 mars
1989, étaient fort optimistes. Dans le tableau 1, on a reconstitué, d’après les indications du
rapport, les chiffres prévus et les réalisations.
Tableau 1 : Prévisions et réalisations de Socrate
trafic voyageurs Millions
réservations Millions
investissement initial Socrate MF 1988
coût de fonctionnement annuel 1994 MF
date de démarrage
Taux de Rendement Interne
1995
prévu en 1988
150
130
940
650
janvier 1991
28 %
1995 réel
95
65
2100
914
janvier 1993
?
Le phénomène d’escalade est ici encore visible. Les prévisions ne sont pas respectées et
pourtant le projet a continué. La similitude avec Taurus porte sur:
- le caractère stratégique du projet (ici lié à la modulation de la tarification et pour Taurus
à la dématérialisation),
- le caractère limite des performances demandées aux informaticiens (qui oblige à passer
par un seul prestataire technique, ici les américains du système SABRE),
- l’interpénétration avec le domaine politique (Taurus a demandé une nouvelle réglementation votée en février 1992 et Socrate a «anticipé» la modification de l’article 14 (sur la
tarification) du cahier des charges de la SNCF, modification intervenue en juillet 1994),
- l’illusion de l’existence d’un logiciel répondant aux besoins (dans les deux cas on a pensé
réduire les risques en prenant un progiciel (Vista et SABRE respectivement) et finalement
on a réécrit tout le logiciel ou presque),
- l’ampleur du projet qui absorbe toutes les ressources informatiques,
- la complexité institutionnelle du projet (voyageurs et agences de voyage pour la SNCF,
agents de change et banques pour Taurus),
- le peu d’attention accordée aux autres solutions (la modification du logiciel RESA de
réservation SNCF ou la poursuite du logiciel Talisman de la Bourse de Londres),
- le mépris pour les avis divergents sur le projet,
IAE de Paris (Université Paris 1 - Panthéon - Sorbonne ) - GREGOR - 1998.10 -
6
- l’attribution de gains au projet (politique commerciale ou dématérialisation des titres)
alors que ces aspects y sont périphériques.
Cependant il existe des différences. Le «maître d’ouvrage» de Socrate est le directeur des
«grandes lignes» à la SNCF. Il était en poste du début à la fin du projet. Il a l’idée initiale. Il suit
tous les aspects techniques. Il y est impliqué totalement. La Cour parle d’un « cumul de fonctions »
qui le conduit à négliger «les aspects financiers et les questions d’organisation». Le Ministère de l’Equipement qui assure la tutelle est, à cette époque, fort distant, au nom d’une autonomie de gestion
de la SNCF.
Au contraire le directeur du projet Taurus qui va décider de l’abandon n’a été nommé qu’en
1989, trois ans après le début, alors que le retard était bien connu parce qu’on avait déjà atteint
la date de démarrage initialement annoncée. Il n’est pas informaticien et le comité qui l’entoure
a été renforcé institutionnellement en 1991. Son pouvoir fort explique sa capacité à arrêter le
projet en 1993.
Ces dérapages des projets informatiques justifient-ils un scepticisme sur les prévisions
concernant tous les projets informatiques? Tout au moins ils nous alertent sur le piège dans
lequel les prévisions optimistes conduisent les pilotes du projet.
3
Le point de non-retour de rentabilité des projets
Le choix rationnel sur les projets suppose que les chiffres prévisionnels de dépenses et de
gains sont exacts. S’ils ne le sont pas, il y a risque. On va considérer, plus précisément, le risque
de l’optimisme, d’une sous-évaluation des coûts et d’une surévaluation des gains. Considérons
un projet informatique non rentable sur lequel on prendrait une décision en 1988 pour un démarrage opérationnel en 1993. Supposons qu’on puisse connaître dès 1988 les vraies valeurs (indiquées dans le tableau 2). Avec un taux d’actualisation de 8 %, la VAN est négative (-500 MF).
On ne doit pas lancer le projet.
Supposons maintenant que le projet ait été lancé en 1988 (par exemple, parce qu’on n’aurait
pas disposé des vrais chiffres). On peut considérer à chaque moment la décision de poursuivre
le projet qui ne tient compte que des flux de trésorerie à venir (les dépenses passées ne sont pas
récupérables). La VAN sur la période restante a été calculée dans le tableau 2 et on montre son
évolution dans la figure 3.
Figure 3 : Evolution de la VAN pour la période à venir.
VAN pour la période restant à cou
2,5
2
1,5
démarrage
moment de non
retour
1
fin de durée
de vie
0,5
0
1988
-0,5
-1
1989
VAN intiale
1990
1991
1992
1993
1994
1995
1996
1997
IAE de Paris (Université Paris 1 - Panthéon - Sorbonne ) - GREGOR - 1998.10 -
7
Tableau 2 : Rentabilité d’un projet selon les moments du projet
total 1989 1990 1991 1992 1993 1994 1995 1996 1997
investissement
2,1
0,2
0,2
0,3
0,4
1
fonctionnement
4,5
0,9
0,9
0,9
0,9
0,9
gains commerciaux
4
0
1
1
1
1
coût ancien système 2,5
0,5
0,5
0,5
0,5
0,5
cash flow
-0,2 -0,2 -0,3 -0,4 -1,4 0,6
0,6
0,6
0,6
VAN
-0,49
TRI
-1 %
VAN sur période restante -0,49 -0,33 -0,15 0,13 0,54 1,99 1,55 1,07 0,56
0
Cette VAN, restant à courir jusqu’à la fin de la durée de vie du projet, augmente au début
parce qu’elle ne tient plus compte des dépenses passées. Elle devient positive au milieu de
l’année 1990. Puis à partir du démarrage de l’application, en 1993, elle décroît parce qu’elle
porte sur une période plus petite. À la fin de la vie du projet, elle est nulle.
Le plus important est ce moment du milieu de l’année 1990 où la VAN à venir devient positive. À partir de cette date, les décisions «rationnelles», avec les vrais chiffres, ne peuvent plus
arrêter le projet. Les sommes déjà engagées ne pouvant pas être récupérées, il est raisonnable
de poursuivre. En revanche, si on dispose des vrais chiffres dès le début, il ne faut pas se lancer
dans le projet.
Pour promouvoir le projet, il est efficace, au début, de cacher les vrais chiffres, de se montrer
optimiste, de maquiller la réalité. Une fois le projet engagé, il y a un moment de non-retour où
les bénéfices ultérieurs sont suffisants pour justifier la poursuite du projet, bien que celui-ci soit
globalement une erreur. Les prévisions biaisées du début ont conduit à un piège dont on ne peut
sortir parce que les dépenses initiales ne sont pas récupérables.
Ce modèle s’applique à toutes sortes de projets. Ceux qui concernent l’informatique sont
marqués par l’optimisme des promoteurs et le caractère non récupérable des dépenses initiales.
Ainsi s’explique que ces projets puissent aller à leur terme, bien que non-rentables, parce qu’ils
ne peuvent plus être arrêtés, compte tenu de la rentabilité pour la période à venir. Mais pour qu’il
y ait, à un moment donné, une rentabilité positive dans l’avenir, il faut naturellement qu’il y ait
des bénéfices au moment de l’exploitation elle-même.
Le piège s’amorce par la capacité du promoteur à construire une vision (un «mythe» dit
Helga Drummond) qui soit convaincante au départ du projet. On pourrait penser que cet optimisme soit une ruse des informaticiens. Il ne semble pas que ce soit le cas. Ils souhaitent que le
système soit le moins cher possible et livré vite. Ils ne veulent pas arnaquer leur entreprise. Ils
croient de bonne foi aux estimations qu’ils avancent.
4
Aux sources de l’optimisme informatique
Les cas similaires à Taurus et Socrate sont trop nombreux pour que ce ne soient que des
hasards. Le modèle rationnel de la VAN montre une forte vulnérabilité à l’optimisme initial. Il
convient de comprendre les raisons de ces glissements et de tenter de trouver des parades.
4-1
Historicité des projets
Un projet se déroule dans le temps. Midler (1994 [10]) montre (page 99) un graphique du
TRI prévisionnel d’une voiture selon les moments de la prévision, analogue à la figure 1
donnant le coût prévisionnel de Taurus selon les époques. Il est tout à fait illusoire de contester
le pilotage en oubliant le point de vue de chaque moment. Il est d’ailleurs à remarquer que la
IAE de Paris (Université Paris 1 - Panthéon - Sorbonne ) - GREGOR - 1998.10 -
8
Cour des Comptes ne cesse de replacer ses remarques sur Socrate par rapport au contexte des
moments de décision.
L’accent mis sur l’histoire n’excuse pas les écarts, il constitue le cadre pour les interpréter.
Notamment, le projet tel qu’on le connaît à la fin n’est pas celui du début.
4-2
L’incomplétude.
Midler affirme à propos de la Twingo "le caractère indissociable de la connaissance sur le
projet et de sa réalisation" (ibidem [10] page 98). Le projet se découvre en se faisant. Ce qu’on
en connaît au début est très limité. Conduire le projet c’est acquérir de l’information à son sujet.
Cette découverte est technique et aussi le résultat des négociations avec les divers acteurs. Les
compromis de chaque moment font évoluer le projet.
Cette incomplétude du projet, forte au démarrage, est une caractéristique encore plus
marquante des projets informatiques. Les documents de départ ne donnent que des directions.
Les besoins des utilisateurs devraient clore un «cahier des charges». Mais ces besoins n’ont
aucune raison de rester figés. Ils évoluent en fonction du métier des personnes mais aussi les
exigences croissent au fur et à mesure qu’on les satisfait.
Utilisateurs et informaticiens sont engagés dans une spirale perfectionniste afin de définir le
système idéal et éternel. Celui-ci est évidemment en retard et coûte très cher. Au contraire, avec
du «design to cost» on serait obligé de s’arrêter sans doute plus tôt.
Une petite fiction peut rendre ce propos plus clair. Si, avec nos méthodes traditionnelles en
informatique, on avait voulu définir en 1984 un logiciel de traitement de texte, on aurait passé
trois ans avec les utilisateurs à découvrir les spécifications de Word 7. On aurait mis ensuite
quatre ans, ou plus, pour écrire le programme et corriger ses erreurs. Quand le produit aurait été
commercialisé, le marché aurait déjà occupé par le produit de Microsoft. On aurait eu le bon
produit mais trop tard. À l’inverse les premières versions de Word étaient rustiques, pas très
fiables. Mais avec un prix très bas elles ont envahi le marché. Ensuite seulement, elles se sont
enrichies avec les fonctionnalités dont le besoin apparaissait aux utilisateurs d’après l’usage des
versions précédentes. La domination de Microsoft montre le succès de cette démarche progressive. Il a été très rentable de sortir une succession de produits de traitement de texte, chaque
version meilleure que la précédente, mais vouée aussi à être dépassée. À la demande initiale
correspondent des spécifications toujours perfectibles. Bill Gates y a ajouté des contraintes de
temps qui ont constitué la véritable maîtrise du projet.
En ayant en tête l’idée d’un programme figé résolvant les problèmes pour une grande période
de temps, on est toujours en retard et on complique les spécifications.
4-3
La complexité
Les projets informatiques sont complexes, non pas seulement à cause de la technique mais
aussi en raison du réseau social dans lequel s’insèrent les applications.
La technique est compliquée, certes, à cause des innovations. Mais l’apprentissage permet
de la maîtriser. D’autre part, dès qu’une technique devient plus mûre, apparaissent sur le marché
les outils logiciels pour en disposer facilement. La construction d’interfaces conviviales
compense la complication croissante.
La vraie complexité qui subsiste dans les projets est celle du corps social dans lequel l’informatique va être utilisée. L’organisation de la Bourse de Londres offrait une complexité considérable. Pesaient sur le projet Socrate la taille de la SNCF, la sensibilité des acteurs
gouvernementaux, du grand public, des syndicats etc..
Pour faire face à cette complexité, les méthodes informatiques ont séparé les rôles entre les
«maîtres d’ouvrage» représentant le client, les utilisateurs, la direction de l’entreprise et les
« maîtres d’œuvre », informaticiens, réalisateurs du projet. Les uns commandent, les autres
IAE de Paris (Université Paris 1 - Panthéon - Sorbonne ) - GREGOR - 1998.10 -
9
obéissent. Les uns décident et payent, les autres proposent et exécutent. Cette séparation est
copiée de celle du bâtiment où les architectes affirment depuis longtemps une expertise de
"maîtrise d’ouvrage". Au contraire, en informatique, ce métier n’a pas vraiment de fondements
professionnels. On ne sait pas comment l’exercer, on ne forme personne à le faire.
Or la séparation entre ces deux rôles, qui existe aussi aux Etats-Unis, est contradictoire avec
les conclusions de la recherche sur la gestion de projet. Une fois encore citons Midler. Il affirme
(ibidem [10] page 186) «la globalité de la compétence projet». En séparant les rôles, en les enserrant
dans une démarche méthodologique formelle, on se prive d’opportunités imprévisibles, on
pousse les acteurs à privilégier des rationalités locales qui masquent les pistes d’amélioration
au niveau de l’ensemble. L’informatique réussie est le résultat de l’interdépendance étroite entre
acteurs qui ont une vision de leur succès commun.
4-4
L’évaluation sans cesse répétée
À chaque moment, les réalisateurs du projet font des choix, restreignent l’univers des possibles. Les degrés de liberté diminuent. Pour faire ces choix, Midler met l’accent sur l’évaluation
(ibidem [10] page 72). C’est sans doute vrai dans les projets automobiles et on admire le chef
de projet de la Twingo parce qu’il a su décentraliser une métrique simple pour juger le coût
d’une modification, en tenant compte à la fois de l’investissement initial et du coût de fabrication récurrent.
En informatique, on évalue rarement. Les choix techniques dépendent peu de considérations
de coûts (qui sont instables à cause de la baisse générale des tarifs) et encore moins d’anticipations de gains qui ne sont pas connus des maîtres d’œuvre. Les calculs de rentabilité sont alors
sujets à caution.
Dans le projet Twingo, on n’échappait pas à l’incertitude des coûts annoncés. On a construit
un « indicateur de qualité des chiffrages » (ibidem [10] page 103). Les acteurs ont ainsi été forcés
d’améliorer la crédibilité de leurs estimations.
L’évaluation est intéressante quand on dispose d’une pluralité de solutions. Très vite les
informaticiens n’en retiennent qu’une. Au contraire, il semble que le succès des projets vienne
du fait de considérer simultanément plusieurs solutions acceptables et de ne trancher que le plus
tard possible. Ward (1995 [19]) rapporte que l’avantage que Toyota conserve dans la durée de
mise au point d’un véhicule viendrait du fait que les choix entre les grandes options sont
retardés. On mène le projet parallèlement sur plusieurs solutions et on tranche très tard. Paradoxalement les délais sont réduits, sans doute parce que les modifications (retour arrière sur des
choix déjà faits) sont moins nombreuses.
Les maîtres d’ouvrage disposent de peu d’information sur l’éventail des solutions. Les
maîtres d’œuvre cachent les choix pour mener leur travail sur une seule solution qu’ils affirmeront être la meilleure. Entre ces deux responsabilités, l’asymétrie d’information crée une relation d’agence et le contrôle du maître d’œuvre par le maître d’ouvrage reste théorique.
4-5
L’anticipation de coûts d’exploitation
Un projet doit se mener en tenant compte de la totalité de la durée de vie du produit. Les
informaticiens ont rarement une vision claire de ce qui se passera une fois qu’ils auront délivré
l’application aux utilisateurs. Notamment, ils ne connaissent pas le coût d’exploitation et le coût
de maintenance. Peter Keen (1993 [6]) estime que le coût informatique après le démarrage est
de trois fois supérieur, en moyenne, au coût dépensé pour les études et la réalisation du logiciel.
C’est dire qu’on ne peut pas les négliger. Mais il arrive bien souvent qu’on ne sache pas évaluer
la puissance des machines nécessaires avant le démarrage en vraie grandeur. Il y sur ce point
une négligence importante des professionnels de l’informatique.
IAE de Paris (Université Paris 1 - Panthéon - Sorbonne ) - GREGOR - 1998.10 -
5
10
Conseils aux acteurs
Les sciences de gestion ne se contentent pas de constater les difficultés, elles tentent de
proposer des pistes de solutions. Les publications professionnelles par exemple conseillent les
informaticiens pour accroître leur crédibilité.
5-1
La crédibilité des informaticiens
Les auteurs préconisent des actions pour que les informaticiens rendent leurs prévisions plus
crédibles. Tout d’abord, ils doivent se rapprocher des gestionnaires, comprendre leurs préoccupations, deviner ce dont ils ont besoin avant qu’ils ne sachent le verbaliser. Ainsi Richard Nolan
(Reimus, 1997 [17]) recommande-t-il aux directeurs informatiques d’acquérir la vision des
affaires qui est partagée par l’équipe de direction.
Pour faire passer les décisions sur les projets d’infrastructure informatique (chers et très
déterminants pour le long terme), Broadbent (1997 [2]) recommande de résumer les orientations
prises par des «maximes», phrases simples exprimant en quoi les critères de choix ont été totalement calqués sur l’expression de la politique générale choisie par la direction.
De manière très concrète, Bashein (1997 [1]) met l’accent sur le fait que la compétence technique ne suffit pas. Il recommande aux informaticiens de reconquérir la confiance des dirigeants
de l’entreprise, de démontrer leur loyauté dans des relations avec le reste de l’entreprise, avec
au minimum une certaine politesse, une amabilité, un respect de l’autre et un intérêt pour lui.
C’est ensuite, dans la durée, que la confiance se construit, dans la cohérence entre les actes et
les paroles, dans la continuité des comportements.
Pour jouer complètement le rôle d’agent de changement que beaucoup d’informaticiens
s’attribuent, Markus (1997 [9]) leur conseille d’abandonner l’idée d’un déterminisme technologique. C’est dans une représentation de l’interaction de tous les acteurs, comme dans la
démarche du Développement Organisationnel (OD), que l’informaticien peut aider au succès en
catalysant le changement.
Mais il n’est pas sûr qu’on doive tout attendre des informaticiens. De nombreux messages
similaires leur ont été envoyés depuis trente ans et ils n’ont eu que peu d’écho. Les gestionnaires
doivent aussi s’impliquer dans le pilotage des projets.
5-2
La méfiance des gestionnaires
Si les estimations faites par les informaticiens sont incertaines, on peut appliquer les techniques de risque pour en tenir compte dans la décision de lancer ou poursuivre les projets. Strassmann (1990 [18]) propose de probabiliser toutes les valeurs de la VAN. Il obtient ainsi une
répartition de la rentabilité et la probabilité que le projet ne soit pas rentable.
Il est aussi possible d’utiliser la technique des arbres de décision. On choisit alors entre les
issues possibles en fonction de leur rentabilité et de leur probabilité a priori. Tout au long de
l’avancement des projets, on redécide en fonction des informations nouvelles qui réduisent
l’incertitude.
Les chiffres avancés par les informaticiens en termes de coûts et de délais peuvent être
validés par le jeu des évaluations contradictoires. On a vu que, tant dans le projet Taurus que
pour Socrate, les promoteurs du projet avaient fait taire les voix discordantes. Or les avis contradictoires sont en général intéressants pour jauger des risques, même si on doute que le débat
permette de définir une prévision meilleure, de compromis.
La décision probablement la plus importante pour améliorer la qualité des prévisions
consiste à conserver la mémoire des projets, quelque amère qu’elle soit. Bien souvent, on
s’efforce d’oublier les difficultés du passé. Il faut les garder à l’esprit pour interpréter les garde-
IAE de Paris (Université Paris 1 - Panthéon - Sorbonne ) - GREGOR - 1998.10 -
11
fous mis en place à ce moment et aussi pour commencer le processus d’apprentissage organisationnel.
L’apprentissage diffuse aussi entre les entreprises grâce aux publications et aux conseils.
Ainsi, dès 1989, les études menées par le Gartner Group montraient que le coût de la micro
informatique était 7 fois supérieur au coût visible des matériels et logiciels achetés. L’administration de réseau et le support (call desk, hot line) coûtent trois fois plus cher. Et un montant égal
doit être ajouté correspondant au temps passé par les utilisateurs à exécuter des tâches destinées
à l’outil et non à leur travail, telles que: attente au démarrage, temps de réponse des transactions,
sauvegardes, appel au support, pannes. Ces résultats ont été validés par un grand nombre
d’observations ultérieures (Legrenzi, 1997 [7] et 1998 [8]). Ils sont une bonne base pour des
anticipations dans les entreprises. Pour les fournisseurs, ils poussent à vendre des solutions qui
permettraient de diminuer les coûts annexes (support ou temps perdu des utilisateurs).
La ligne hiérarchique, aux niveaux dépendant de l’ampleur des projets, doit contrôler le
processus de développement des applications. Ce contrôle n’est pas celui d’une méfiance envers
les informaticiens, c’est celui d’une association aux décisions pour que les choix techniques
n’oublient pas le cadre des objectifs globaux de l’entreprise. L’engagement des directions générales, souvent demandé par les informaticiens pour leur faciliter le travail, est le rappel incessant
des objectifs et de l’obligation de mesurer la manière dont on les atteint.
Les projets informatiques sont-ils particulièrement dangereux pour les entreprises ? Les
sommes engagées restent modestes par rapport aux investissements effectués dans le cœur de
métier. Par exemple les 2 Milliards de francs de Socrate restent mineurs par rapport aux
18 Milliards de la ligne du T.G.V. Nord engagés à la même époque par la SNCF. Mais si les
coûts directs apparaissent faibles, l’impact est beaucoup plus important en coûts cachés par
l’influence sur les méthodes employées dans le métier lui-même.
Les technologies de l’information constituent un domaine d’investissement risqué, comme
d’autres industries informationnelles, le cinéma ou les livres par exemple. Beaucoup de productions ne trouvent pas leur équilibre économique. Certaines, en petit nombre, font de très grands
bénéfices. Il nous manque encore un savoir faire formalisé pour anticiper les chances de succès
d’une œuvre avant sa confrontation au public.
6
Bibliographie
[1]
Bashein B. J., Markus M. L., 1997, «A Credibility Equation for IT specialists», Sloan
Management Review, Summer, Vol. 38 N˚4, 35-44.
[2]
Broadbent M., Weil P., 1997, «Management by Maxim: How Business and IT Managers
Can Create IT Infrastructures», Sloan Management Review, Spring, Vol. 38 N˚3, 77-92.
[3]
Brynjolfsson, E. 1993, «The productivity paradox of information technology», Communications of ACM, Dec, Vol 36, N˚ 12, 67-77.
[4]
Cour des comptes, 1996, Rapport au Président de la République, Les éditions du journal
Officiel, Octobre, 418p.
[5]
Drummond H, 1996, Escalation in decision making, The tragedy of Taurus, Oxford
University Press, 237p.
[6]
Keen, P.G.W., 1993, Shaping the future, Business design through information technology,
Harvard Business School Press.
[7]
Legrenzi, Ch., 1997, «Une étude empirique de la productivité des travailleurs de
l’information», L’Informatique Professionnelle, N˚ 159, Décembre, 3-16.
[8]
Legrenzi, Ch., 1998, «Une nouvelle taylorisation des travailleurs de l’information»,
L’Informatique Professionnelle, N˚ 161, Février, 27-38.
IAE de Paris (Université Paris 1 - Panthéon - Sorbonne ) - GREGOR - 1998.10 [9]
12
Markus M. L., Benjamin R. I., 1997, «The Magic Bullet Theory in IT-Enabled
Transformation», Sloan Management Review, Winter, Vol. 38 N˚2, 55-68.
[10] Midler, 1994, L’auto qui n’existait pas, Interéditions, 215p.
[11] Peaucelle J.-L., 1990, La gestion de l’informatique, Editions d’Organisation
[12] Peaucelle J.-L., 1996, «Sur les pistes de la rentabilité de l’informatique», Gérer et
Comprendre Annales des Mines, déc., 27-40.
[13] Peaucelle J.-L., 1997, Informatique rentable et mesure des gains, Hermès.
[14] Peaucelle J.-L., 1997, «Mesures de la rentabilité des logiciels de GMAO», Deuxième
Congrès de Génie Industriel, Albi 3 — 5 sept., 18 pages.
[15] Peaucelle J.-L., 1998, «La productivité administrative et l’informatique: discours et
réalités», Colloque CREIS, 10 et 12 juin 1998 à Strasbourg.
[16] Peaucelle J.-L., 1998, «The paradox of cost reductions within a support department»,
Sixième conférence européenne sur les systèmes d’information ( ECIS98 , Aix en
Provence), 4 au 6 juin.
[17] Reimus B., 1997, «The IT System That Couldn’t Deliver», Harvard Business Review,
May-June, 22-35.
[18] Strassmann, P. A., 1990, The Business Value of Computers, Information Economic Press,
New Canaan, CT.
[19] Ward A., Liker J. K., Cristiano J. J., Sobek II D. K., 1995, «The second Toyota
Paradox: How Delaying Decisions Can Make Better Cars Faste» r, Sloan Management
Review, Spring, Vol. 36 N˚3, 43-61.
[20] Yourdon, Ed., 1993, «CASE and silver bullet of software engineering», CASE World 810 mars, San Francisco.
1998.10
Peut-on croire les informaticiens? Ou: de la
rationalité des anticipations concernant les
technologies de l’information
Jean-Louis Peaucelle
Professeur à l’IAE de Paris
Les papiers de recherche du GREGOR sont accessibles
sur INTERNET à l’adresse suivante :
http://www.univ-paris1.fr/GREGOR/
IAE de Paris (Université Paris 1 - Panthéon - Sorbonne ) - GREGOR - 1998.10 -
14