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

Chapitre 9  Conclusion

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 : 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 : 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
Précédent Remonter Suivant