Chapitre 8 Projets réussis et projets ratés

Le paysage des projets informatiques offre un spectacle varié de succès, d'échecs et surtout de demi-échecs et de succès partiels. Nous en présenterons ici quelques-uns qui offrent quelques leçons intéressantes.

1 Un directeur financier motivé

Au début des années 1980, époque antérieure à la généralisation des micro-ordinateurs, j'ai dirigé l'informatique (scientifique et de gestion) d'un petit établissement de recherche (150 personnes au total à l'époque) dont la gestion financière et comptable était assurée au moyen d'une machine électromécanique en fin de contrat d'entretien. Il fallait donc informatiser la gestion. Un appel d'offres fut lancé, et le fournisseur d'un logiciel spécialisé sélectionné. Le fournisseur du matériel informatique s'en déduisait, puisque ce logiciel ne pouvait fonctionner qu'avec un modèle d'ordinateur bien déterminé. Le tout fut livré et installé sans encombre. C'est là que les choses sérieuses commencent, et dans beaucoup de cas, comme j'ai pu observer, c'est à cet instant précis que l'échec ou le succès (en général l'échec) se décide --- quand j'écris échec, on pourra m'objecter que la plupart des entreprises disposent d'un système de gestion informatisé qui fonctionne ; sans doute, mais il s'agit souvent néanmoins d'un échec au moins partiel, parce que les délais n'ont pas été tenus, que les coûts ont explosé et que le service rendu est bien inférieur aux attentes initiales.

Lorsque l'on achète un progiciel de gestion, que ce soit comme ici le produit d'une petite société provinciale ou un prestigieux logiciel intégré à plusieurs millions d'Euros la licence, la complexité de l'univers décrit est du même ordre ; une petite entreprise comme une grande a des fournisseurs, des clients, des salariés, des investissements, un capital, etc. Les bases de la comptabilité des entreprises ont été jetées à Sumer il y a près de cinq mille ans et depuis il y a eu des améliorations techniques mais pas vraiment de bouleversement conceptuel.

Le progiciel livré et installé par le fournisseur, aussi perfectionné soit-il, est une coquille vide : seuls les gestionnaires de l'entreprise sont en mesure de la remplir avec les données spécifiques qui en décriront le fonctionnement souhaité, conforme aux procédures de l'entreprise. Les données relatives directement à l'entreprise proprement dite, comme le fichier des fournisseurs ou celui du personnel, ne posent pas de problème particulier. Il y a en revanche des données qui décrivent le fonctionnement du système de gestion lui-même, qui constituent un modèle abstrait de l'entreprise, que l'on peut considérer comme un méta-langage du langage interne de l'entreprise : ce sont notamment le plan comptable, les circuits de visas et d'habilitations (les « work-flows » en langage moderne), les agrégations d'informations et les états à produire, les synthèses pour les dirigeants et les responsables de secteurs. Ces données-là posent des problèmes beaucoup plus difficiles, parce que la détermination de leur forme et de leur contenu revient à décider du mode de gestion de l'entreprise.

Le lecteur des chapitres précédents devine déjà que dans un organisme public la locution « décider comment on gère l'entreprise » pose forcément un problème à un monde conçu pour que personne n'y décide jamais rien. Mais les entreprises privées éprouvent aussi des difficultés ! Si le progiciel est bien conçu, l'adapter à la structure particulière d'une entreprise se réalise par un paramétrage, avec un minimum de développements spécifiques si certaines fonctions n'ont pas été prévues, mais on cherchera à les éviter à tout prix. Les erreurs les plus courantes dans ce travail sont parmi les suivantes, d'après mes observations directes :

le paramétrage est confié à de simples exécutants dépourvus de vision d'ensemble et qui reproduisent leur routine habituelle et ses mauvaises pratiques en les gravant dans le marbre des règles du nouveau logiciel, ce qui crée une situation aggravée par rapport à la précédente ;
le dirigeant autocratique « qui a tout dans la tête » ne souhaite pas expliciter ses règles de gestion implicites pour les instancier dans les règles écrites d'un logiciel, ou il n'en est pas capable intellectuellement, et ainsi le système informatique ne correspondra jamais à la réalité de l'entreprise ;
l'entreprise n'a rien prévu pour le paramétrage et s'en remet aux options par défaut du logiciel : pour une petite entreprise ce peut être un moindre mal, mais c'est impraticable dès que la structure est un peu vaste et complexe ;
cas souvent combiné avec le cas 1 : en renfort des exécutants dépourvus de vision, évoqués au cas 1, on a fait venir des consultants pour le paramétrage ; chacun ajoute ses prescriptions dans le plus grand désordre ; on est ici dans un cas classique de prise de décision collective sans véritable responsabilité, les opérations de paramétrage vont enfler, prendre de plus en plus de temps, aboutir à une pagaille assez générale et à une masse de développements spécifiques souvent superflus.

Bref, pour que cela se passe bien, il faut que le véritable responsable de la gestion, si possible unique, s'implique personnellement dans le processus de paramétrage. Il faut qu'il soit capable d'avoir une vision suffisamment abstraite de son activité pour pouvoir la traduire en règles explicites de fonctionnement du système d'information, et doté d'une abnégation suffisante pour confier son pouvoir à cet outil impersonnel.

L'établissement de recherche qui nous occupe dans cet exemple était à l'époque (1982) pourvu d'un directeur financier qui possédait ces qualités. Non seulement il avait une connaissance approfondie de la comptabilité publique, mais il était capable de la décrire avec un niveau élevé d'abstraction, ce qui est essentiel pour un projet d'informatisation parce que cela permet d'isoler les processus significatifs et de les faire comprendre à l'informaticien de service, qui sinon croulerait sous les détails et passerait à côté de l'essentiel. Il avait d'ailleurs soutenu une thèse sur l'histoire de la comptabilité publique, à laquelle je dois notamment la référence à l'ordonnance du Vivier-en-Brie. En outre, il ne rechignait pas à acquérir les connaissances techniques dont il comprenait qu'elles lui permettraient de mieux maîtriser son système. Autant dire que son cas était une anomalie dans le contexte français ! Il faut dire qu'il était jeune et que son rang hiérarchique était modeste, il ne sortait même pas de l'ENA.

Le progiciel acheté reposait sur un système d'exploitation particulièrement bien adapté à des tâches de gestion, le système Pick créé par Richard Pick. Ce système était construit autour d'une base de données qui contenait toutes les données, que ce soient celles du système ou celles des utilisateurs. C'est-à-dire que chaque donnée était dotée d'un nom, d'un propriétaire, d'une liste d'utilisateurs autorisés et d'une durée de vie, et ce qu'elle soit en cours d'utilisation ou stockée pour un usage ultérieur : la distinction entre mémoire vive et mémoire de stockage (les « fichiers »), si contraire à l'intuition et si difficile à comprendre pour les néophytes, était donc abolie. Ainsi, le point d'indice, qui sert de référence pour le calcul des rémunérations de la fonction publique, existait de façon unique et bien identifiée dans le système, et lorsqu'une nouvelle valeur était publiée au Journal Officiel il suffisait d'une mise à jour pour que toutes les applications en tiennent compte. La simple idée d'un système aussi génial était insupportable pour le corporatisme des informaticiens, qui ont fini par avoir sa peau : il faut dire que Pick apportait une telle simplification à la gestion que sa généralisation aurait obligé quantité de programmeurs occupés à des tâches banales et répétitives, désormais réalisables par des non-informaticiens, à trouver un travail plus exigeant.

Pour accéder aux données de la base, les manipuler et produire des états, Pick fournissait un langage de requêtes, analogue à SQL¹ mais plus simple et plus expressif, baptisé avec une certaine outrecuidance Français. Notre directeur financier ne tarda pas à en posséder une maîtrise parfaite. La façon dont il procédait était la suivante : il me téléphonait vers 6 heures pour que je passe dans son bureau, et nous travaillions devant sa console jusque vers 21 ou 22 heures ; il m'expliquait ce qu'il avait fait et les obstacles qu'il avait rencontrés, presque toujours dus à son ignorance de quelque concept de base de l'informatique ; je lui expliquais la nature de l'erreur commise, et celle du concept qu'il devait assimiler pour la corriger, par exemple la notion de variable, celle d'affectation d'une valeur à une variable, celle d'écriture d'un enregistrement dans la base. Il était motivé, doué, l'exercice à résoudre le concernait au plus haut point, donc il comprenait vite.

Il nous suffit d'une trentaine de séances vespérales de ce type réparties sur une période de six mois pour qu'il rédige des procédures adaptées à toutes les fonctions de son service. Lors des dernières séances nous nous attaquâmes à un langage de plus bas niveau, turing-équivalent, Basic, pour effectuer plus efficacement quelques opérations qui atteignaient les limites des pouvoirs de Français.

Notre homme avait acquis ainsi une maîtrise exceptionnelle du travail de son service, il en connaissait intimement les moindres ressorts, puisqu'il les avait créés lui-même. Parmi les problèmes qu'il avait résolus, il y en avait bien sûr beaucoup qui découlaient des interactions entre les procédures qu'il avait rédigées lui-même et les fonctions de base incorporées dans le progiciel livré par le fournisseur, il avait donc acquis également une excellente connaissance de ce dernier, par la lecture de la documentation ou par l'interrogation tenace des employés dudit fournisseur. Bref, il disposait désormais d'un système parfaitement adapté aux besoins de l'établissement, qu'il était capable de faire évoluer au doigt et à l'oeil quelle que soit la modification réglementaire catastrophique publiée par surprise au Journal Officiel.

En fait, dans cette expérience réussie d'informatisation, le directeur financier et moi-même avions appliqué les principes de l'eXtreme Programming sans le savoir, et pour cause. Je suis d'autant plus convaincu que c'est la seule façon raisonnable de développer un logiciel pour l'usage d'un tiers.

Ce système fonctionna à la satisfaction générale pendant cinq ou six ans. Puis il fallut en changer pour des raisons extérieures mais courantes dans le monde informatique : le constructeur de l'ordinateur utilisé se retirait de cette activité et arrêtait son service de maintenance, et la société qui avait fourni le progiciel avait cessé son activité. Tout n'était pourtant pas désespéré : il existait d'autres fournisseurs du système Pick, et d'autres progiciels assez proches de celui que nous utilisions. Il aurait donc été envisageable de réitérer le processus suivi six ans plus tôt, qui n'avait somme toute été ni trop coûteux ni trop long. Mais la principale catastrophe était irrémédiable : notre directeur financier avait eu une promotion, méritée et due d'ailleurs en partie à son succès dans l'informatisation de la gestion, il était désormais directeur-adjoint de l'établissement et estimait que ce n'était pas à lui de faire ce travail de paramétrage. La responsabilité de l'informatisation fut confiée à un collaborateur du directeur financier, qui était loin d'avoir les aptitudes intellectuelles de son ancien chef, et qui s'entoura immédiatement d'une armée de personnes plus ou moins concernées mais qui avaient toutes en commun avec lui une aptitude modérée au travail à réaliser. Je n'ai pas eu connaissance des détails de la suite de l'histoire, mais je sais par les amis que j'ai gardés dans la maison qu'elle fut longue, triste, douloureuse et coûteuse : en un mot, conforme à toutes les autres expériences d'informatisation de la gestion qu'il m'a été donné d'observer de près.

2 L'Internet

Un réseau ouvert

S'il est un succès incontestable dans l'histoire des développements informatiques, c'est bien l'Internet, et il est donc intéressant de se pencher sur la façon dont ont été créés les logiciels d'ampleur considérable qui en assurent le fonctionnement.

Pour les moins informés de ses utilisateurs, l'Internet se confond avec le WWW et éventuellement avec le courrier électronique, qui n'en sont que deux usages parmi d'autres. Le WWW est un ensemble de méthodes destinées à permettre la publication sur l'Internet de documents indépendants de la nature du serveur et reliés entre eux par des liens, les URL(Universal Resource Locator). Les URL (ces formules un peu étranges de la forme http://www.laurent-bloch.org/ qui apparaissent dans la barre d'adresses de votre navigateur) constituent un moyen très simple de désigner de façon précise et dépourvue d'ambiguïté un document quelconque sur le réseau.

L'Internet est un réseau de réseaux, un gigantesque système d'interconnexion que l'on peut comparer au système téléphonique international, même si ses principes de fonctionnement sont différents. C'est un système public : il suffit de s'abonner pour une somme modique, voir gratuitement, auprès d'un fournisseur d'accès (FAI) local pour avoir accès, le plus souvent sans paiement de redevances supplémentaires, à des serveurs dans le monde entier, ce qui n'est pas du tout le cas avec le système téléphonique international. De ce fait, l'Internet permet de publier toutes sortes de textes, d'images et d'autres informations qui seront accessibles à un public mondial, pour un coût minime. Toutes sortes d'informations dont la consultation demandait il y a dix ans de nombreuses heures de recherche dans des bibliothèques souvent accessibles aux seuls citadins des pays riches sont désormais au bout des doigts de tout un chacun.

Si la grande presse a pu faire ses choux gras des abus de cette liberté, et si la recherche d'informations sérieuses aux dépens des moins sérieuses demande, comme par le passé, une bonne connaissance de son domaine de recherche, l'arbre ne doit pas cacher la forêt, et l'existence de ce moyen de diffusion universel et bon marché représente une véritable étape dans l'histoire de la pensée et de la civilisation. Son existence a permis l'apparition d'innombrables sources de créativité dans les domaines les plus variés, et qui n'auraient sans lui jamais trouvé la voie de la publication. On trouvera dans le livre de Lawrence Lessig[69] une analyse approfondie du rôle d'un système de publication libre d'accès, et des menaces qui pèsent aujourd'hui sur lui.

Modèle en couches et principe périphérique

La charpente de l'Internet (comme de toute architecture de réseau) est constituée de protocoles, c'est-à-dire de documents qui fixent les règles imposées à un type de communication donné. Les protocoles de réseau sont généralement représentés selon une architecture en couches imaginée par le chercheur néerlandais Edsger Wybe Dijkstra (1930--2002) dans un article fameux publié en mai 1968 par les CACM (Communications of the Association for Computer Machinery), « The structure of the THE multiprogramming system » [34].

Avant d'être le plan de construction du réseau concret, l'architecture en couches est un modèle destiné à se représenter intellectuellement les choses par des abstractions. Ce modèle est utile pour « penser un objet dans lequel plusieurs logiques s'articulent » (Michel Volle, http://www.volle.com/opinion/couches.htm), lorsqu'il faut séparer différents niveaux d'abstraction. On nommera couches basses celles qui décrivent la transmission de signaux sur des supports physiques tels que câble téléphonique, faisceau hertzien ou fibre optique, tandis que les couches intermédiaires concernent l'acheminement de messages complexes à travers des réseaux à la topologie également complexe, et que les couches hautes traitent de la présentation de ces messages à travers une interface utilisateur, de l'identification de leur destinataire et de son authentification. Les ensembles de règles et de conventions qui régissent les communications entre les couches de même niveau de plusieurs systèmes communicants constituent des protocoles de communication. Les règles et les conventions qui régissent les échanges entre une couche donnée et la couche immédiatement inférieure d'un même système constituent une interface.

Une des choses qui a fait la force de l'Internet, c'est le principe « end to end », que l'on pourrait traduire, avec Solveig Godeluck [46], par le principe périphérique, ou par « l'intelligence est aux extrémités », c'est-à-dire dans les programmes installés sur les ordinateurs des utilisateurs finals ; l'architecture du réseau reste la plus simple possible, on s'interdit d'introduire au sein des infrastructures des dispositifs ou des optimisations spécifiques pour tel ou tel usage particulier. Pour implanter un nouveau protocole qui devra permettre tel nouveau mode de communication entre deux ordinateurs connectés au réseau, par exemple la téléphonie par l'Internet, tout ce qu'il faudra, c'est que ces ordinateurs soient dotés chacun des protocoles de base (Internet Protocol, ou IP, et en général Transmission Control Protocol, ou TCP), et bien sûr y installer les logiciels propres à la nouvelle application. Toutes les fonctions nouvelles seront donc implantées dans les ordinateurs aux extrémités de la communication, sans nécessiter aucune adaptation du réseau et des noeuds intermédiaires. C'est-à-dire, par exemple, que lorsque Tim Berners-Lee a voulu créer HTTP, le protocole du WWW, il n'a eu à demander l'autorisation de personne, parce que ce nouveau protocole ne nécessitait aucune modification de l'infrastructure du réseau --- bien sûr, pour que HTTP devienne un standard de l'Internet, il aura fallu ensuite quelques formalités, que nous évoquerons ci-dessous. Ce principe « end to end » garde l'infrastructure du réseau aussi simple, ouverte et favorable à l'évolution que possible.

Le fait que le contrôle de l'accès à l'Internet ne puisse être accaparé par personne garantit à ses usagers qu'ils pourront l'utiliser sans restriction tant pour y publier que pour y consulter des informations, et c'est ce qui a fait son succès, face à l'incompréhension totale des grandes entreprises de télécommunications comme de télédiffusion, qui continuent à n'y voir qu'un hybride entre TF1 et le catalogue de la Redoute. Tant pis pour elles.

Mise au point historique

Entamons cet examen par la réfutation d'une légende aussi fallacieuse que répandue et répétée ad nauseam : l'Internet n'a pas été créé selon un cahier des charges rédigé par les militaires américains en vue de préserver une capacité de communication après une frappe nucléaire. Il n'y a jamais rien eu qui ressemble de près ou de loin à un « cahier des charges de l'Internet ». Cette thèse télescope plusieurs événements liés mais distincts. Paul Baran, du think tank RAND, contractant du DoD (Department of Defense), avait posé les principes d'un système de communications dépourvu de point de centralisation unique afin de maintenir certaines liaisons même si certains noeuds venaient à être détruits. Les travaux de Baran furent publiés entre 1960 et 1964. Le même DoD, plusieurs années plus tard, en 1969, a impulsé par son agence ARPA (Advanced Research Projects Agency) la création du réseau ARPANET, qui n'était pas destiné aux communications militaires mais à faciliter la collaboration entre centres de recherches universitaires et industriels sous contrat avec l'ARPA. À sa création ARPANET reliait quatre universités : Stanford à Palo Alto, les campus de Los Angeles et de Santa Barbara de l'Université de Californie, et Utah à Salt Lake City. On pourra consulter à ce propos le livre passionnant de Katie Hafner et Matthew Lyon[52].

C'est en 1974 que Vinton Cerf (de l'université Stanford) et Robert Kahn de BBN (Bolt, Beranek & Newman) publièrent le premier article sur TCP/IP. En 1976, la clairvoyance de Vint Cerf et de Robert Kahn, le financement de BBN et les contrats de l'ARPA devenue entre temps la DARPA donnèrent naissance au protocole réseau de l'Internet, destiné à devenir TCP/IP. En 1977 ce protocole commença à fonctionner, et c'est de ce moment que l'on peut dater la naissance de l'Internet expérimental.

Nous avons déjà mentionné comme une innovation propre à l'Internet le principe périphérique (« end to end »), nous pouvons en ajouter une autre, liée à la précédente et qui a trait à la fiabilité. Voilà de quoi il s'agit : on dit qu'un protocole de transmission est fiable s'il comporte une vérification que les données émises ont été transmises sans erreur ; la vérification a lieu au moyen d'informations redondantes ajoutées aux données émises, dont on vérifie à l'arrivée la cohérence avec le corps du message. Il est en effet dans la nature des communications à distance d'être sujettes aux erreurs de transmission. Si un message a été corrompu lors de sa transmission, il faut en général prévenir son émetteur pour qu'il le réémette. Si l'on dispose d'un protocole fiable pour faire circuler des données entre deux noeuds adjacents, et si l'extrémité réceptrice de la communication vérifie l'intégrité des données, conformément au principe de l'intelligence aux extrémités, il est inutile que le protocole intermédiaire chargé de faire circuler les données dans le réseau (la couche réseau) comporte lui-même un contrôle d'erreur. Ce principe d'une couche réseau non-fiable, formulé pour la première fois par Louis Pouzin pour le réseau français Cyclades, permet une grande simplicité du protocole de réseau.

C'est en 1978 pendant une pause d'une conférence à Marina del Rey que Vint Cerf et Jon Postel tirèrent les conséquences de ce principe de la couche réseau non-fiable en divisant leur protocole en deux parties : un protocole fiable de transport de bout en bout, TCP, et un protocole réseau non-fiable, IP. Cette innovation hardie allait constituer une des forces de l'Internet, avec quelques autres qu'il n'est pas possible d'exposer ici et pour lesquelles on se reportera avec profit au livre de Katie Hafner et Matthew Lyon[52].

Un peu plus tard, en 1979, le groupe de recherche en système (Computer Systems Research Group, CSRG) de l'Université de Californie à Berkeley allait incorporer TCP/IP à une nouvelle version d'Unix, dite BSD (Berkeley Software Distribution).

En 1982 la Défense américaine adopte officiellement les protocoles TCP et IP (Internet Protocol) pour le réseau ARPANET et accepte de les distribuer gratuitement sur le réseau. C'est ainsi que s'est nouée une situation qui allait unir les destins de l'Internet, d'Unix et des logiciels libres.

Tous ces éléments ont contribué à donner naissance en 1986 à l'Internet tel que nous le connaissons, quand les centres de recherche connectés à ARPANET ont voulu communiquer avec les universités de leur choix et que la NSF (National Science Foundation) a entrepris de leur en donner les moyens en créant son propre réseau, NSFNet.

Dès le début des années 1980 ARPANET acceptait des connexions à partir d'universités non américaines. Il s'agissait souvent (dans le cas de la France notamment) de liaisons indirectes, établies par des passerelles et des relais complexes, mais qui donnaient accès au réseau ; la France eut accès au courrier électronique ainsi en 1984, mais ce n'est que le 28 juillet 1988 que notre pays fut vraiment raccordé à l'Internet par une liaison permanente en TCP/IP[53].

Organisation administrative de l'Internet

Il faut rappeler ici que l'Internet n'est la propriété de personne ni d'aucune institution, ce qui semble parfois difficile à comprendre.

Nous invitons le lecteur à quelques secondes de réflexion admirative devant un dispositif technique conçu à l'origine pour un réseau d'une centaine de noeuds et qui a pu résister à une croissance de six ou sept ordres de grandeur, d'autant plus que cette conception n'était le fait ni d'un grand groupe industriel ou financier, ni d'un gouvernement, ni d'un conglomérat de telles puissances. Mais peut-être était-ce là le secret ?

Le fonctionnement de l'Internet, à l'image de sa construction, repose sur la coopération volontaire. Nous donnons ici l'organigramme général de son organisation :

L'Internet Architecture Board (IAB) est responsable des grandes orientations et de la coordination.
L'Internet Engineering Task Force (IETF) se charge de la normalisation à court terme et émet les Requests for Comments (RFC), qui sont les documents de référence pour le fonctionnement du réseau ². Toutes les RFC sont accessibles par l'URL (Universal Resource Locator) http://www.ietf.org/rfc/ ou sur de nombreux sites miroirs. Nous ne saurions trop en conseiller la lecture : même si leur qualité littéraire est inégale elles fournissent sur l'Internet une information de première main, souvent exposée très clairement.
L'Internet Steering Group (IESG) coordonne l'IETF, dont l'effectif est devenu très important.
L'Internet Assigned Numbers Authority (IANA) centralise et contrôle les conventions relatives à l'identification des objets du réseau, et notamment veille à l'unicité des adresses.
L'Internet Corporation for Assigned Names and Numbers (ICANN) , créée en 1998 à l'initiative du gouvernement américain, supervise l'attribution des noms de domaines et des adresses.

Ainsi les décisions organisationnelles et techniques sont prises par des instances aux séances desquelles tout un chacun peut assister et participer, les séances des instances de pilotage (IAB, IESG, ICANN) étant toutefois réservées à leurs membres élus. Cette organisation coopérative ne signifie pas l'absence de rapports de force marchands ou politiques, mais elle exclut (au moins à court terme) la prise de contrôle par une entreprise unique. L'ICANN soulève bien des critiques du fait de l'influence déterminante qu'y exerce le gouvernement américain, mais il est significatif que la réaction à ce qui pourrait devenir une mainmise est rendue possible par la structure ouverte des autres instances, par contraste avec ce qui se passe à l'ISO ou à l'UIT (Union Internationale des Télécommunications).

Organisation topographique de l'Internet

Figure 8.1 : Topographie simplifiée de l'Internet

La figure 8.1 donne une représentation schématique de la topographie de l'Internet. Cette représentation est simplifiée, notamment elle est purement arborescente, alors que rien n'empêche une entreprise d'avoir plusieurs fournisseurs d'accès à l'Internet (FAI), ni un FAI d'être connecté à plusieurs centres d'interconnexion de niveau supérieur, ce qui complique le schéma et le transforme d'un arbre en un graphe connexe quelconque. Chaque noeud (ordinateur connecté, ou autre type d'équipement) est identifié par une adresse (dite adresse IP) unique à l'échelle mondiale, un peu comme un numéro de téléphone précédé de tous ses préfixes nationaux et régionaux. L'essentiel dans l'établissement d'une communication, c'est, à chaque noeud, de savoir quel est le prochain noeud sur l'itinéraire, et par quelle liaison l'atteindre. Les noeuds terminaux, origines ou destinations des communications, sont au sein des réseaux locaux de campus ou d'entreprise. Un routeur est un noeud particulier, doté de plusieurs interfaces réseau (et donc de plusieurs adresses), ce qui lui permet d'être connecté simultanément à plusieurs réseaux et de faire passer les paquets de données d'un réseau à un autre, en fonction de règles de routage qui auront été enregistrées dans sa mémoire.

Architecture de l'Internet

Les documents qui décrivent les protocoles --- et par conséquent l'architecture --- de l'Internet s'appellent des Requests for Comments (RFC)[54]. Les protocoles les plus connus sont IP (Internet Protocol) pour l'acheminement d'un paquet de données à travers un réseau complexe, TCP (Transmission Control Protocol) pour le transport d'un segment de données de bout en bout selon une connexion établie, puis au niveau applicatif SMTP (Simple Mail Transfer Protocol) pour le courrier électronique, HTTP (Hypertext Transfer Protocol) pour le WWW, FTP (File Transfer Protocol) pour le transfert de fichiers, etc.

Les protocoles sont publiés par l'IETF à partir de soumissions spontanées. Le RFC 2026 définit la procédure de validation des RFCs : une soumission doit suivre un processus nommé « standards track », qui comporte trois étapes : « Proposed Standard », « Draft Standard », et « Standard ». L'introduction d'un document dans ce processus est effectuée à l'initiative de l'IESG, qui choisit les « Proposed Standards » parmi des documents nommés « Internet-Drafts », soumis sans formalités à la discussion. Pour qu'une soumission soit examinée avec quelque chance de succès il est de coutume qu'elle soit accompagnée d'un prototype de logiciel pour l'illustrer.

Il est clair que la spontanéité des soumissions est variable, et, au fur et à mesure que l'Internet devenait un enjeu économique important, les industriels de l'informatique et des réseaux ont contribué de plus en plus intensément à la création de RFCs, mais sans que le caractère consultatif et concerté du processus soit fondamentalement altéré.

De fait, aujourd'hui, le fonctionnement de l'Internet repose sur des documents de normalisation librement accessibles à tous, contrairement aux normes ISO qui ne sont accessibles que moyennant finances. Faire payer ou non l'accès aux normes, c'est une décision lourde de conséquences, qui définit le public auquel on s'adresse. Des logiciels libres sont disponibles pour tous les usages de l'Internet : serveurs de messagerie (Sendmail, Postfix, Qmail, Exim), serveurs WWW (Apache), serveurs de noms (Bind, Djbdns), navigateurs (Mozilla)... Ce processus de création par accrétion d'une infrastructure mondiale, à la cohérence extrême, utilisée par des centaines de millions de personnes, en l'absence de tout pilotage centralisé, constitue un défi réellement fascinant pour tous les architectes de systèmes.

L'Internet est-il un système d'information ?

Le lecteur pourrait s'interroger sur le bien-fondé de la mention de l'Internet dans un ouvrage consacré aux systèmes d'information. La réponse est oui, l'Internet peut être vu comme un S.I. de plusieurs façons : d'abord, l'Internet incorpore dans son infrastructure plusieurs systèmes d'information nécessaires à son fonctionnement. Citons le système de noms de domaines (Domain Name System, ou DNS), qui permet, si l'on connaît le nom d'un serveur, de trouver l'adresse qui permettra de l'atteindre, et vice-versa. Fonctionnellement, le DNS est extrêmement simple : c'est une table à deux colonnes, dans la colonne de gauche des noms, dans la colonne de droite les adresses correspondantes. Techniquement, c'est une immense base de données distribuée sur l'ensemble de la planète, avec de fortes contraintes de disponibilité et de mise à jour, peut-être la base la plus grande et la plus complexe qui existe. L'ensemble des informations de routage, qui permettent l'acheminement des communications d'un bout à l'autre de la planète, complète ce système d'information.

L'Internet est aussi un S.I. d'un autre point de vue : lorsque l'on écrira l'histoire de la pensée à la fin du XXe siècle, nul doute qu'y figure l'invention de l'URL (Universal Resource Locator) et des moteurs de recherche, qui ont révolutionné les méthodes de recherche d'information, en abolissant toutes sortes de barrières matérielles et en réduisant de façon drastique les délais d'accès à un volume de documents inimaginable il y a vingt ans.

3 Socrate à la SNCF

La SNCF a mis en service au début de 1993 un nouveau système de réservation baptisé Socrate. Lors du lancement de ce projet l'objectif poursuivi était, pour citer le rapport de la Cour des Comptes[28], « le lancement d'un nouveau système de distribution commerciale : à la fin des années 1980, dans la perspective du développement du réseau de lignes à grande vitesse et de l'accentuation de la concurrence avec le transport aérien, il était devenu vital pour la SNCF d'entrer comme partenaire dans un système global de distribution, afin de garantir l'égalité de traitement du chemin de fer par rapport à l'avion dans les agences de voyages, qui représentent plus de 20% de sa distribution commerciale. »

La SNCF escomptait une augmentation de 50% de son trafic voyageurs entre 1986 et 1995, et dans une telle perspective le système de réservation RESA dont elle disposait à l'époque était jugé désuet ; il fallait soit le transformer soit le remplacer. En 1988 la SNCF choisit d'abandonner le système RESA et « de se rapprocher de la société AMR, filiale d'American Airlines, dont le système de distribution SABRE occupait la première place dans le transport aérien mondial. »

En fait, derrière cette décision de la SNCF peuvent se lire rétrospectivement plusieurs orientations qui ne se situent pas toutes sur le même plan et qui ne sont pas forcément liées entre elles :

Conformément au but initial, offrir aux agences de voyage un système de réservation comparable à celui des compagnies aériennes.
Modifier la politique tarifaire selon des principes nouveaux qui seront décrits ci-dessous, pour accroître les recettes commerciales.
Infléchir ses relations avec sa clientèle vers un alignement sur les principes du marketing, en s'écartant progressivement des principes du service public, notamment par le recours à la segmentation de la clientèle. La segmentation consiste à essayer d'attirer et de « fidéliser » la partie de la clientèle jugée la plus rentable, et à imposer des contraintes supplémentaires au reste de la clientèle, jugée moins intéressante.
Diminuer la dépendance de l'entreprise à l'égard de son service informatique interne en faisant appel à un prestataire extérieur.

Cette volonté multiforme de modernisation doit être appréciée dans le contexte des années 1980, marquées par de graves accidents et de grandes grèves qui ont mis en lumière la vétusté de pans entiers tant de l'infrastructure technique que de la réglementation et de la situation sociale. SABRE était un système éprouvé mais assez ancien, puisqu'il avait été conçu en 1960 par American Airlines et IBM. Il comptait de nombreuses références dans le monde du transport aérien, mais aucune dans celui du rail : pour espérer un succès à la SNCF, il aurait été nécessaire de l'adapter aux caractères propres du transport ferroviaire, et l'ampleur de ces modification avait été fortement sous-estimée lors de la phase de définition et de lancement du projet, ce qui amènera à les réaliser en catastrophe après l'ouverture du système au public.

Le lancement du système en 1993 s'est très mal passé : on peut dire sans abus que des trains circulaient en partie vides cependant que les voyageurs qui auraient souhaité les prendre restaient à quai faute d'avoir pu obtenir un billet. Les causes de cet échec étaient multiples :

le personnel ne savait pas utiliser le système ;
les bases de données qui décrivaient les trains, les itinéraires, les correspondances, les horaires et les tarifs étaient défectueuses ;
la clientèle était déroutée par la nouvelle politique commerciale et tarifaire, qui donnait une impression négative d'augmentation des coûts ;
les équipes informatiques de la SNCF ne connaissaient pas suffisamment Socrate pour en corriger les défauts.

Les dysfonctionnements du système Socrate ont été importants, ils ont entraîné pendant plusieurs années consécutives une diminution sensible de la fréquentation des trains par la clientèle. Il est certain qu'une entreprise privée non subventionnée aurait eu le plus grand mal à se relever d'un tel échec, qui n'a pu être compensé que par une ponction importante dans les finances publiques. Le rapport de la Cour des Comptes[28] est éloquent à ce sujet. On pourra également consulter les minutes d'un débat[64] organisé sur la Cinquième chaîne de télévision, et bien d'autres documents accessibles sur le WWW.

Le cas de Socrate est intéressant parce qu'il est devenu public, il a pu être analysé par des organismes de contrôle gouvernementaux et par des experts indépendants, et ces analyses ont été rendues publiques. Lorsque de tels dysfonctionnements surviennent dans une grande banque, et il en survient, ils restent le plus souvent confidentiels.

Il ressort assez clairement de la lecture des documents publiés que, dans l'échec de Socrate, les causes techniques étaient secondes par rapport aux causes afférentes à une mauvaise gestion du projet. Il suffit de regarder les rubriques du rapport de la Cour des Comptes :

La SNCF a inversé en cours de réalisation les priorités du projet, initialement destiné à permettre aux agences de voyage de réserver des places de train aussi facilement que des places d'avion, l'orientant soudain vers un objectif de maximisation des recettes commerciales.
Les problèmes posés par l'alimentation du nouveau système à partir des « données voyageurs » ont été gravement sous-estimés ; par exemple, le nombre de relations par correspondance introduites dans Socrate n'était que de 4 000, alors qu'il en aurait fallu au moins dix fois plus.
De nouveaux principes de tarification, qui ont nécessité une modification en catastrophe du cahier des charges de la SNCF, ont été introduits furtivement : le système précédent, dit « de péréquation », permettait à un usager de se présenter à un guichet SNCF pour faire l'achat d'un titre de transport qui lui garantissait, en fonction du prix payé, d'être transporté sur le même nombre de kilomètres quel que soit le moment et quelle que soit la ligne sur laquelle il devait se déplacer. La SNCF a décidé de faire disparaître la péréquation au profit d'un ajustement du rapport offre / demande ; il faut désormais gérer une offre complètement différente avec des gammes de prix variables, train par train et jour par jour ; il faut également appliquer des critères de tarification variables en fonctions des caractéristiques des voyageurs : âge, fréquence de voyage, etc. Il s'agit aussi de pouvoir traiter les services associés aux billets, comme la réservation d'hôtel à l'arrivée et la location d'une voiture par exemple.
La sensibilité de la clientèle aux prix du transport a été mal appréciée.
La formation du personnel de vente à l'exploitation du système Socrate a beaucoup laissé à désirer, notamment pour ce qui est de l'apprentissage opérationnel.
Le dialogue de la SNCF avec les associations d'usagers est resté trop strictement formel, et la communication vers le grand public a été défaillante.
L'avenir de l'exploitation du système a été longtemps hypothéqué par une situation de dépendance de l'entreprise vis-à-vis de son fournisseur et par des difficultés à maîtriser la politique tarifaire.
Le coût total de réalisation aura été en fait de l'ordre de 2,1 milliards de francs 1988, soit plus du double du devis présenté lors du lancement du projet.

Les commentaires de certains experts indépendants sont également instructifs ; ainsi Daniel Faita, chercheur au Centre de recherches « Analyse pluridisciplinaire des situations de travail » de l'Université de Provence, co-responsable de l'expertise « nouvelles technologies » pour le projet Socrate, a déclaré à Nathalie Le Breton[64] :

« Auparavant, les stratégies de vente des agents SNCF consistaient à repérer puis isoler dans la demande de l'usager les éléments permettant de réaliser une transaction à la fois satisfaisante pour l'usager et efficace en terme de prestation. En fonction de la logique de Socrate, le vendeur ne devait plus laisser libre cours à l'expression de l'usager mais guider le dialogue en lui proposant des disponibilités. C'est alors l'offre qui prévaut sur la demande...

[La démarche suivie] a abouti à ignorer que, dans les activités commerciales de la SNCF, existaient des données fondamentales --- comme la gestion du temps qui est un critère essentiel dans toute activité d'interaction --- qui ont été complètement simplifiées par la nouvelle politique commerciale de la SNCF. L'approche techniciste du projet conduisait à faire du gain de temps dans les transactions l'objectif central des réformes. Or, ceci était en contradiction avec l'une des dimensions fondamentales de cette activité commerciale...

Avec Socrate, c'est le temps employé par le système qui sert à prescrire l'évaluation du temps de transaction et non pas le temps humain qui lui intègre réflexion et interrogations et qui permet de mieux aboutir au terme de la transaction. »

Ce dernier paragraphe évoque exactement le passage de Philippe Zarifian que nous citions cite-zar-taylor pour caractériser l'organisation taylorienne du travail, laquelle se révèle aussi peu adaptée à la démarche commerciale qu'à la réalisation de systèmes informatiques.

Sur le plan technique, Socrate est une adaptation du logiciel SABRE développé pour American Airlines. L'ampleur des conséquences à tirer des différences entre transport aérien et transport ferroviaire a été nettement sous-estimée. Les équipes informatiques de la SNCF n'étaient pas en mesure d'intervenir sur le logiciel, puisque tout était externalisé. Daniel Faita note :

« Je ne voudrais pas que vous retiriez de mon exposé une impression exclusivement caricaturale. Ceci dit, il faut bien admettre que les informaticiens de la SNCF n'ont pas été impliqués, ni dans le choix du logiciel, ni dans son adaptation. Le choix a été largement guidé par des considérations théoriques qui ont ignoré de manière assez nette, d'une part, la logique de l'adaptation de l'outil et, d'autre part, les impératifs de soumission aux normes techniques propres aux transports ferroviaires. »

Bref, le projet Socrate semble bien avoir été marqué par le fantasme de l'achat de progiciel tout prêt, en négligeant la nécessaire participation des membres de l'entreprise à son adaptation aux situations concrètes.

Le soin de déterminer si les leçons de Socrate ont profité au site WWW de la SNCF, le plus fréquenté de France, est laissé au lecteur.

1: SQL (Structured Query Language) est un langage d'accès aux bases de données relationnelles normalisé par l'ISO et très répandu. Ce n'est pas un langage de programmation général (turing-équivalent selon le jargon que nous avons introduit au chapitre 4), mais il est de ce fait plus simple.
2: Citons ici le nom de Jon Postel, éditeur des RFC depuis la première en 1969 jusqu'à sa mort en 1998, et auteur ou coauteur de 204 d'entre elles, ce qui lui a conféré une influence considérable sur la physionomie du réseau.