Pourquoi des normes en informatique ?

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 :

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

• définit comment le compilateur devra être fait ;
• définit les conditions d’application du compilateur au
  programme.

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...

• Dans un sens, si vous lisez un document Microsoft Word avec une
  version ultérieure du logiciel, il sera en général illisible, ou du
  moins bien mutilé. Essayez par exemple de lire un fichier généré par
  Word 2.0 sur un Microsoft Word récent : vous ne serez pas déçu.
• Dans l’autre sens, il n’y a pas grand chose à dire, car rien n’a
  été fait pour rendre possible une lecture de documents Word
  ultérieurs. Word 2.0 ne reconnaîtra tout simplement pas le fichier
  récent que vous lui donneriez à lire.

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 :

• 8 sont consacrés au nom du fichier, et 3 à son extension ;
• 1 à ses attributs ;
• 10 octets sont réservés à un usage ultérieur ;
• 2 à l’heure, 2 à la date ;
• 2 au numéro du premier bloc, 4 à la taille du fichier.

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 :

• dans le sens chronologique, car le FAT-32 supporte le FAT-12 ;
• à rebours du sens chronologique, car le FAT-12 rendait possible une
  évolution vers quelque chose comme le FAT-32.

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