Rome ne s’est pas faite en un jour. Cet adage s’applique aux villes, au réseau des lignes de métro, mais aussi à des logiciels.

Quand nous voyons le plan du métro d’une grande ville, nous pouvons nous interroger sur le processus morphogénétique qui a produit une forme aussi baroque. Car, si nous avions demandé à un ingénieur d’imaginer le meilleur plan possible, il aurait cherché à disposer les lignes et les stations de manière à ce que le trajet pour aller d’un point de la ville à un autre soit le plus court, tout en maintenant le coût total du projet inférieur au budget alloué. J’ignore quelle est la solution de ce problème d’optimisation sous contrainte, mais il est probable que ce soit une forme beaucoup plus symétrique que le plan du métro de Londres, de Paris ou de Tokyo.

Mais ce n’est pas ainsi que nous construisons les métros. En général, nous construisons une première ligne, puis quelques années après, une deuxième, puis une troisième, etc. Et, à chaque fois que nous construisons une nouvelle ligne, nous nous demandons certes comment cette ligne contribue à un projet d’ensemble, qui ne sera sans doute jamais achevé, mais surtout comment répondre à des besoins plus immédiats, par exemple de rentabilité de la nouvelle ligne. De plus, même quand un projet initial existe, chaque génération le redéfinit, parce que les techniques, les attentes et les modes évoluent et parce que des leçons sont tirées des expériences passées. Quand un projet est ainsi redéfini, les lignes déjà construites sont comparables aux contraintes géographiques et géologiques : elles sont là et elles ne peuvent plus beaucoup être modifiées.

Pour continuer à lire, inscrivez-vous !

14 jours d'essai gratuit

Lecture sans publicité, accès illimité à des milliers d’articles premium, flux personnalisé, revue de presse du jour.

J'ai déjà un compte