Pourquoi des normes en informatique ?

Avertissement

Cette page est encore en construction ; aussi est-elle très incomplète.

Une fois terminée, elle le sera sans doute encore, mais pas pour les mêmes raisons.

Introduction : L’omniprésence des normes

De quelque côté que l’on se tourne dans l’étude de l’informatique, l’on finit toujours par retomber sur des normes.

Chaque langage de programmation a sa norme, ou plus souvent ses normes ; chaque langage de description de texte, chaque système de fichiers a ses normes. Les périphériques obéissent à des normes, ainsi que leur branchement. Les systèmes d’exploitation eux-mêmes peuvent avoir des normes à respecter, ainsi que tel ou tel format de document. La notion de norme semble dès lors régir chaque domaine de l’informatique, matériel comme logiciel, et ce en chacun de ses degrés d’abstraction.

Ces normes s’appellent ISO, IEEE, ANSI, POSIX, W3C ; elles peuvent encore porter bien des noms. Leur seul point commun est le caractère normatif, i.e la simple forme de leur rapport au logiciel ou au matériel singulier. La norme définit à la fois un idéal et un minimum : on peut réaliser des programmes ou des périphériques qui excédent la norme, non qui la contredisent.

La question que nous nous poserons ici est la suivante : pourquoi les normes occupent-elles une place aussi importante ? À partir de cette question, nous verrons quelles difficultés se posent lorsque l’on veut définir des normes, et enfin comment on peut y remédier.

Liste des exemples pris ici :

Système d’exploitation Appels système UNIX POSIX
Systèmes de fichiers FAT
ISO 9660, Rock Ridge et Joliet
Langages Langages de programmation C ANSI
BASIC
Langages de formatage de texte (X)HTML W3C
LaTeX

I - Normes et portabilité

A) Un contre-exemple historique : le langage BASIC

Le langage BASIC fut conçu en 1964 pour offrir un ensemble de possibilités «  basiques » de programmation, et être ainsi accessible au plus grand nombre possibles de débutants en programmation. Un certain nombre d’actuels programmeurs ont d’ailleurs fait leurs premiers pas avec le BASIC (à vrai dire, rares sont ceux qui ont dû commencer par le Java ou le C++).

Cette popularité eut des effets désastreux : de nombreux compilateurs furent développés sans qu’il y ait la moindre concertation horizontale. Ainsi, un programme p(X) développé par le programmeur X sur un ordinateur o(X) pouvait ne plus fonctionner sur un ordinateur o(Y), et o(X) ne pas pouvoir exécuter un programme p(Y) développé par un programmeur Y.

Ainsi, loin de devenir ce langage universel que sa popularité devait faire de lui, la BASIC est paradoxalement devenu un langage très particularisé, étroitement dépendant du compilateur pour lequel il avait été développé.

Pourquoi ? Parce qu’il n’y avait pas de normes. Et s’il n’y a pas de normes, tout est permis. On vit ainsi apparaître le BASIC-E en 1970, CBASIC ; un certain Bill Gates développa le premier interpréteur BASIC ; il y eut encore QBASIC et GW-BASIC, Visual BASIC, etc. L’ANSI s’efforça, de 1974 à 1978, de poser des standards, mais il était déjà trop tard : quatorze ans après l’apparition d’un langage, son usage était déjà trop généralisé pour que l’on pût espérer modifier le comportement des utilisateurs.

B) La norme ANSI du langage C

1. La multiplication chaotique des compilateurs C

Le langage C a lui aussi, dans un premier temps, été victime de son succès : écrit par Dennis Ritchie et Ken Thompson pour développer une version portable du système d’exploitation UNIX, il fut décrit en 1978 dans un livre devenu classique, célèbre sous le nom de K&R. Le succès du langage eut pour conséquence la multiplication des compilateurs, chacun redéfinissant le langage à sa façon.

Bien loin d’aider la programmation en C, la multiplication des compilateurs, et, partant, des versions du langage, ne pouvait que lui nuire. Il n’était plus possible d’écrire un programme dont on pût être assuré qu’il fonctionne sur n’importe quel compilateur. Par conséquent, on ne pouvait écrire un programme que pour un compilateur donné si l’on voulait qu’il fonctionne. Le K&R de 1978 était évidemment devenu obsolète, étant resté bien en deçà de toutes ces modifications ultérieures qui pour une part se recoupaient, pour une autre divergeaient absolument.

2. La normalisation du langage

C’est afin de remédier à ce chaos que l’ANSI (American National Standards Institute) décida de fixer une norme, encore valide aujourd’hui : on appelle cette norme le C ANSI, ce qui montre à quel point la norme est devenue consubstantielle au langage même ; la norme n’en est donc pas tant une interprétation possible, contingente, qu’une définition universellement valable. Désormais, si l’on veut écrire un compilateur et que l’on veut qu’il soit utilisable - et surtout portable - l’on devra se conformer aux normes définies par l’ANSI. Ce n’est plus le compilateur qui définit le langage : il ne fait que vérifier un ordre dont lui-même procède. Au dessus du programme, il y a toujours le compilateur ; mais désormais, la norme

L’essentiel du langage n’est donc plus laissé entre les mains de la diversité des interprétations possibles par chaque compilateur, mais est universelle : elle vaut d’une façon égale pour la grande diversité des compilateurs possibles, et aussi pour la quasi infinité des programmes possibles avec chacun de ces compilateurs indifféremment.

La norme n’est donc pas une contrainte extérieure et arbitraire, mais au contraire ce qui permet la portabilité d’un programme. Quel que soit le système d’exploitation et le compilateur que l’on utilise, le programme écrit en C ANSI pourra fonctionner.

C) Autres exemples

1. La norme HTML et l’interopérabilité

2. La conformité des systèmes UNIX à la norme POSIX

II - Le problème de la rétrocompatibilité

A) Position du problème

Lorsque l’on définit une norme, on évite la multiplication anarchique des interprétations ; il n’y a plus autant de normes que de compilateurs ou de périphériques, mais une seule norme pour un ensemble d’objets matériels ou logiciels.

Mais il peut arriver qu’une norme devienne obsolète. Là, il faut fixer une nouvelle norme. Ainsi, lorsque le PHP 4 a fait son temps, la norme est passée au PHP 5. Autrefois, on utilisait un interpréteur PHP 4 pour exécuter du PHP 4 ; désormais, on devra interpréter du PHP 5 avec un interpréteur supportant le PHP 5.

Mais maintenant que le PHP en est passé à la version 5, cela veut-il dire que l’on doive avoir chez soi autant d’interpréteurs PHP qu’il y en a eu de version ? Rassurez-vous : les interpréteurs PHP 5 supportent aussi les versions précédentes. Ils reconnaîtront les formes du PHP 4 et les exécuteront convenablement.

Ne vous rassurez cependant pas trop vite ! Car s’il est désormais garanti que les versions ultérieures d’un interpréteur ou d’un compilateur supportent les versions antérieures de ses normes, une chose cependant est loin d’être assurée : ce que l’on appelle la rétrocompatibilité.

Prenons un exemple pour définir cette notion de rétrocompatibilité :

  1. La norme est A ;
  2. j’écris un programme p(A) - un programme respectant la norme A - et l’exécute avec l’interpréteur i(A), qui supporte la norme A. Ça marche, et c’est normal.
  3. la norme évolue, et passe à B ;
  4. j’écris un programme p(B) : un programme respectant la norme B, qui est une évolution de A ; je peux exécuter p(B) avec l’interpréteur i(B), cela ne posera pas plus de problème que d’exécuter p(A) avec i(A) ;
  5. comme les choses sont souvent bien faites, on pourra en général exécuter p(A) avec i(B) : un interpréteur ou un compilateur gère presque toujours les versions antérieures de la norme (par exemple, le compilateur libre gcc comprend le C pré-ANSI) ;
  6. mais la question la plus importante est la suivante : peut-on exécuter p(B) avec i(A) ?

Autrement dit : peut-on, par exemple, lire avec un logiciel obéissant à une norme archaïque un fichier obéissant à une norme plus évoluée, et dont l’évolution était sans doute impensable ou encore inenvisagée à l’époque du logiciel archaïque ? Et ce, précisons-le, lorsque l’on ne possède pas de boule de cristal suffisamment puissante...

B) Les fichiers Microsoft Word : une rétrocompatibilité ratée

En fait de rétrocompatibilité, les fichiers doc édités par Microsoft Word sont un bon exemple de ratage quasi total ; on pourrait même parler de portabilité ratée en général, tant ce format génère de problèmes de ce type.

D’abord, si vous donnez un document Microsoft Word à quelqu’un qui possède la même version du logiciel que vous et le même système d’exploitation (par exemple : Microsoft Windows XP Familial), vous pourrez parfois en sortir bien surpris ! Changement du nombre de pages, effaçage intempestif de caractères pris arbitrairement, etc.

Si le problème existe déjà entre deux versions théoriquement identiques du logiciel, vous imaginez ce qui peut se passer entre deux versions produites en des temps différents...

Par conséquent, Microsoft Word représente l’archétype de ce qu’il ne faut pas faire en termes de rétrocompatibilité : un fichier donné n’est lisible que par le logiciel qui l’a généré, et ne l’est donc ni par une version antérieure, ni par une version ultérieure du même logiciel.

III - Les normes évolutives

Pour assurer une bonne rétrocompatibilité, deux principes doivent donc être observés.

D’abord, permettre à des formes évoluées de supporter des formes plus archaïques ; c’est le cas par exemple de la norme du langage LaTeX, comme l’indique Christian Rolland (LaTeX par la pratique, éd. O’Reilly, Paris 1999, p. xv) : «  Tout ce qui fonctionnait avec LaTeX il y a dix années fonctionne toujours grâce à la compatibilité de la version actuelle avec les fichiers de la version précédente. C’est une qualité notable dans un monde informatique où tout évolue si rapidement. » Cette portabilité réelle constitue d’ailleurs l’un des nombreux avantages du langage LaTeX sur le logiciel Microsoft Word.

Ensuite, et c’est ce que nous allons développer dans cette dernière partie, laisser aux formes futures une marge suffisante pour supporter les versions actuelles.

Le premier principe étant relativement simple à garantir, nous ne le développerons pas plus ici ; le second, en revanche, mérite plus d’attention.

A) Systèmes de fichiers

1. FAT 32 : un rétrocompatibilité réussie

Ne généralisons pas trop vite de l’échec de rétrocompatibilité de Word à celui de Microsoft en général : le passage du système de fichiers FAT-12 (qui est celui du MS-DOS) au FAT-32 (celui de Windows 98 et Me) a eu lieu sans gros problème de ce type.

Sans rentrer dans les détails, on pourra simplement observer que dans le système de fichiers FAT-12 de MS-DOS, les entrées d’un répertoire occupent 32 octets, occupés de la façon suivante :

Ce qui nous intéresse ici, ce sont ces 10 octets, soit environ le tiers de l’entrée du fichier dans le répertoire, qui sont inutilisés. En agissant de la sorte, Microsoft s’assurait la possibilité d’ajouter des fonctionnalités à son système de fichiers en conservant la lisibilité des fichiers antérieurs.

C’est cette possibilité qu’exploite le système de fichiers FAT-32 dans Windows 98. À la place de ces 10 bits inutilisés, le système de fichiers ajoute cinq nouveaux champs (respect de la casse pour permettre le passage au système de fichier de Windows NT, horodatation plus précise à la seconde près et non à deux secondes près, etc.). Ainsi, la compatibilité est possible :

Aussi le passage par Microsoft du système de fichiers FAT-12 au FAT-32 fut-il une réussite : la portabilité a été assurée entre deux systèmes d’exploitation séparés dans le temps, dans la mesure où le système le plus ancien est capable de supporter le plus récent. La norme a ainsi pu rendre possible sa propre évolution et assurer une rétrocompatibilité.

2. ISO 9660, Rock Ridge et Joliet

B) Les langages XML et XHTML

C’est le même effort d’évolutivité qui a présidé à la conception du langage XML. XML sont les initiales de Extensible Markup Language : et c’est ce X de l’eXtensibilité qui marque sa différence avec le HTML. Comme ces derniers langages, XML fonctionne en effet par balises ; mais contrairement à eux, le nombre de ces balises n’est pas prédéfini (XML se rapproche en ceci du SGML, dont il est une version simplifiée). Par exemple, il n’y a pas que les balises <title>, <a>, <h1>, <em>, etc., que l’on utilise en HTML. Il y en a un nombre quasi infini ; le tout, c’est d’avoir des interpréteurs sachant qu’en faire.

Des évolutions sont ainsi possibles : la norme du XML, qui comme le SGML est à proprement parler plus un méta-langage qu’un simple langage, les supporte par anticipation. C’est aussi ce qui fait l’intérêt de la norme XHTML, mise à jour, par le consortium W3C, du HTML d’une façon conforme aux lois du XML ; par exemple, le fait que toute balise ouverte doive être fermée, ce qui n’était pas une exigence en HTML Transitional 4.01 pour certaines balises comme <br> ou <li>.

XML fournit donc un exemple d’évolutivité appliquée aux langages informatiques. Ce langage révèle à quel point aujourd’hui, la rétrocompatibilité et l’évolutivité ne sont plus le fardeau d’une norme, mais l’une de ses principales dimensions, une de celles que l’on prend en compte le plus sérieusement.

Conclusion

La notion de norme est centrale dans les questions matérielles aussi bien que logicielles, car c’est elle qui permet la portabilité dans l’espace.

Mais tout aussi importante est la portabilité dans le temps : aussi est-il nécessaire que ces normes s’accompagnent de procédures ou de protocoles d’évolutivité, permettant aussi bien une compatibilité ultérieure qu’une rétrocompatibilité.

Haut de page