Site WWW de Laurent Bloch
Slogan du site

ISSN 2271-3905
Cliquez ici si vous voulez visiter mon autre site, orienté vers des sujets moins techniques.

Pour recevoir (au plus une fois par semaine) les nouveautés de ce site, indiquez ici votre adresse électronique :

Peut-on mesurer :
La densité idéelle d’un programme d’ordinateur
Article mis en ligne le 29 septembre 2007
dernière modification le 12 juin 2018

La question de la présence d’idées dans les programmes d’ordinateur n’est pas dépourvue d’enjeux : épistémologiques tout d’abord, puisqu’il faut encore entendre, surtout dans la bouche des élites intellectuelles, que l’informatique ne serait qu’un simple outil, et qu’un programme ne saurait être considéré comme une création de l’esprit ; mais aussi économiques, à l’heure où menacent les brevets sur les logiciels, or les brevets sont destinés à protéger des idées originales, et il convient de se demander de quelles idées il s’agit, et comment les caractériser.

Qu’est-ce qu’un logiciel, sinon une suite d’idées ? Un logiciel de taille moyenne, disons de quelques centaines de milliers de lignes, comporte de l’ordre de cent mille idées, dont toutes ne sont sans doute pas originales. Comment préciser cette intuition de la présence d’idées ?

La revue Technique et science informatique, dans son volume 22 (numéro 1 de 2003) dirigé par Véronique Viguié-Donzeau-Gouge, Didier Bert et Henri Habrias, a publié un article de Daniel Dollé, Didier Essamé et Jérôme Falampin consacré à l’écriture du logiciel de contrôle et de pilotage de la ligne de métro sans conducteur METEOR construite par Siemens à Paris. On y apprend que le noyau de sécurité de ce logiciel a été développé par la méthode B, qui consiste à élaborer la preuve de la correction du programme en même temps que son code, ce qui fournit une démonstration formelle de justesse. Pour ce type de logiciel, il ne serait en effet pas acceptable de s’en remettre, pour la démonstration de justesse, à l’attente de la manifestation des erreurs, il faut une certitude raisonnable qu’aucune erreur ne viendra provoquer un accident.

Un article de Jean-Raymond Abrial dans le même numéro nous donne quelques détails sur la programmation de ce noyau de sécurité du logiciel de METEOR : la génération automatique, à partir des spécifications écrites en langage B, des 100 000 lignes de code en langage Ada engendra 30 000 obligations de preuve, dont la plupart furent satisfaites automatiquement par le système ; il resta 2 500 démonstrations rétives à l’automatisation, à effectuer par les ingénieurs, ce qui demanda plusieurs mois de travail. Il est possible de dire que ce logiciel comporte 30 000 idées, dont 2 500 idées difficiles, ou originales, pour 100 000 lignes de texte.

N’est-ce pas à dire qu’un tel logiciel, de taille somme toute modeste si on le compare aux dizaines de millions de lignes du système d’exploitation de l’ordinateur au moyen duquel vous lisez cet article, pourrait faire l’objet de 2 500 brevets ? Nous voyons bien que ce serait une mauvaise idée, qui rendrait l’exercice de la programmation particulièrement périlleux. Chaque ligne écrite risquerait d’enfreindre un des milliers de brevets d’ores et déjà déposés par les grandes entreprises informatiques, et dont l’objet, souvent décrit de façon générale et vague, englobe toute une collection de méthodes de programmation.

Il serait intéressant de comparer cette « densité idéelle » à celle d’un objet matériel complexe, avion, auto ou train : un ingénieur d’Alstom ou de l’Aérospatiale pourrait peut-être répondre à cette question. Tout en sachant qu’une grande partie de la complexité d’un avion contemporain est faite de logiciel...