Il y a un moment si ordinaire que nous ne le remarquons pas du tout.

Vous branchez un câble réseau dans une prise murale. La prise vient d’un fabricant allemand, le câble de Taïwan, le commutateur en dessous de Californie, le routeur derrière de Suède. Et ça marche. Non pas parce que tous les acteurs sont gentils entre eux. Mais parce qu’ils respectent tous le même corpus de règles : IEEE 802.3 — Ethernet.

Ça paraît banal. C’est banal. Et c’est précisément pour cela que c’est remarquable.

Ce qu’est vraiment une norme

Une norme n’est pas un logiciel. Ni un appareil. Ni un produit. Une norme est un accord. Un langage commun dans lequel humains et machines communiquent sans se connaître personnellement.

À la plus petite échelle, cela signifie : les fiches s’emboîtent. À la plus grande : internet fonctionne. Entre les deux s’étend un monde de spécifications qui définissent comment les données sont codées, transmises, interprétées et confirmées — afin que des millions d’appareils qui ne se sont jamais connus puissent dialoguer.

Une fois qu’on a compris cela, on voit le monde numérique avec d’autres yeux. Non pas comme une collection de boîtes magiques, mais comme un tissu d’accords que quelqu’un, un jour, a rédigés.

Sans normes, pas d’écosystème numérique

L’internet tel que nous le connaissons serait impossible sans normes. TCP/IP, défini dans les RFC de l’IETF, est le protocole qui relie chaque appareil au réseau. HTTP, lui aussi spécifié dans des RFC, est le fondement du World Wide Web. DNS traduit les noms en adresses. TLS chiffre les connexions. SMTP transporte les courriers électroniques. BGP achemine les paquets de données autour de tout le globe.

Aucune de ces technologies n’appartient à une entreprise. Aucune n’est secrète. Chacune est couchée sur papier, publiée, lisible par tous, implémentable par tous. C’est précisément cette ouverture qui a permis à l’internet de croître — non comme le produit d’un seul vendeur, mais comme un écosystème auquel chacun pouvait participer.

Si l’on avait construit l’internet de manière propriétaire, il n’aurait jamais atteint cette ampleur. Il y aurait eu de nombreux petits réseaux qui ne se parleraient pas. C’est exactement à quoi ressemblait le monde des télécommunications avant les normes : des solutions isolées qui ne fonctionnaient que dans leurs propres murs.

Qui écrit les règles

Les normes ne tombent pas du ciel. Elles sont fabriquées — par des institutions dont la tâche est de négocier des accords susceptibles de rassembler une majorité.

L’IETF (Internet Engineering Task Force) maintient la série des RFC. « RFC » signifie Request for Comments — un nom modeste pour l’archive documentaire la plus importante d’internet. N’importe qui peut soumettre un RFC. N’importe qui peut participer aux discussions. Les décisions ne se prennent pas à la majorité, mais par rough consensus — consensus approximatif. C’est lent, parfois frustrant, et c’est la raison pour laquelle les RFC sont si robustes.

L’IEEE (Institute of Electrical and Electronics Engineers) est responsable des normes de la couche physique : Ethernet, le Wi-Fi (802.11), la radio Bluetooth. Partout où des bits transitent par des câbles ou par l’air, une norme IEEE régit généralement la manière.

L’ISO (Organisation internationale de normalisation) couvre tout, des formats de papier (le fameux DIN-A4 est une norme ISO) aux codes de pays jusqu’à la gestion des processus. Le W3C définit la structure du web — HTML, CSS, XML. L’ECMA standardise des langages de programmation comme JavaScript. L’UIT coordonne les télécommunications internationales.

Ces instituts ne sont pas des autorités dotées de pouvoir. Ce sont des scènes sur lesquelles des groupes d’intérêts négocient. Fabricants, chercheurs, administrateurs, gouvernements — chacun apporte sa perspective. La norme qui en résulte est un compromis. Et les compromis ne sont jamais parfaits, mais souvent assez bons pour tenir le monde ensemble.

Le prix de la normalisation

Les normes sont laborieuses. Quiconque a déjà lu une spécification le sait. Elles sont sèches, pédantes, pleines de cas limites et de conditions particulières. Ce n’est pas un hasard — c’est la conséquence de devoir envisager toutes les situations concevables avant que le document ne soit achevé.

Une norme ne se crée pas en quelques semaines. Souvent, cela prend des années. Des comités se réunissent, des brouillons circulent, des commentaires sont collectés, intégrés, commentés à nouveau. Des querelles sur des détails peuvent mobiliser des mois — savoir si un champ doit faire 16 ou 32 bits, si un délai d’attente se mesure en secondes ou en millisecondes.

Cela ressemble à du gaspillage. Dans le temps qu’il faut pour négocier une norme, une entreprise aurait pu lancer trois produits sur le marché. Et c’est précisément la tentation : être rapide, rester propriétaire, dominer le terrain seul.

Mais celle qui y cède paie un autre prix plus tard.

Quand les normes se font concurrence

Il n’y a pas toujours l’unique norme. Souvent, plusieurs coexistent, et le marché décide — pas toujours rationnellement.

Tout le monde connaît la blague : « Il existe quatorze normes concurrentes. Créons-en une qui les unifie toutes. Maintenant il y en a quinze. » Elle touche un nerf parce qu’elle est vraie. REST contre SOAP. Markdown contre AsciiDoc. YAML contre TOML contre JSON. USB-C contre Lightning contre MagSafe. VHS contre Betamax.

Les normes concurrentes coûtent des ressources. Des adaptateurs, des traducteurs, des couches de compatibilité — tout cela existe parce que le monde ne s’est pas entendu sur une seule solution. Dans certains cas, une norme s’impose parce qu’elle est techniquement supérieure. Dans beaucoup de cas, parce qu’elle est opportune, bon marché ou bien commercialisée. Parfois, une guerre de tranchées de plusieurs décennies subsiste, où les deux camps coexistent et personne ne gagne vraiment.

Malgré tout : des normes concurrentes valent mieux que pas de norme du tout. Car là où une norme existe, l’interopérabilité est possible. Là où il n’en existe aucune, règne le monopole de celui qui contrôle le marché.

Ce qui distingue les normes ouvertes des normes propriétaires

Un protocole propriétaire fonctionne — tant que le fournisseur existe, que la licence est payée et que l’intérêt demeure. Que le fournisseur disparaisse, que la stratégie change ou que le prix double, il ne reste qu’un système qui ne parle plus à rien.

Une norme ouverte, en revanche, n’appartient à personne et à tous. Elle peut être implémentée par quiconque. Elle survit aux entreprises, aux époques, aux bouleversements technologiques. SMTP est plus ancien que la plupart des sociétés actuelles. HTTP fonctionne encore, alors que le monde autour s’est totalement transformé.

Cela a un effet secondaire rarement évoqué : les normes ouvertes réduisent les déchets. Les appareils qui communiquent selon des normes ouvertes peuvent être utilisés plus longtemps, combinés, réparés. Ceux qui dépendent d’interfaces propriétaires jettent du matériel dès que le fournisseur arrête de le soutenir. Les déchets électroniques sont aussi, entre autres, un problème de normalisation.

Le piège du lock-in

C’est ici que cela devient inconfortable. Car les solutions propriétaires sont rarement accidentelles — elles sont souvent délibérées.

Un fournisseur qui développe son propre protocole n’agit pas nécessairement par méchanceté. Souvent, cela commence de manière pragmatique : une fonctionnalité que la concurrence n’a pas, une intégration qui ne fonctionne qu’avec son propre produit, une optimisation de performances qui ne s’applique qu’avec sa propre pile. C’est légitime.

Ce qui se passe ensuite pose problème. Dès qu’un client a migré vers ce système propriétaire — importé ses données, aligné ses processus, formé son personnel —, l’encerclement commence. Chaque intégration supplémentaire fonctionne mieux avec le produit maison. Chaque extension lie davantage. Chaque année qui passe rend une sortie plus coûteuse, plus lente, plus risquée.

C’est cela, le vendor lock-in : le déplacement stratégique du rapport de force. Le client choisit une fois — et ne décide plus jamais. Le fournisseur n’a plus à convaincre, seulement à conserver. Les prix peuvent augmenter, les niveaux de support fusionner, les fonctionnalités être repoussées vers des licences supérieures. Le client ne peut pas partir. Il peut seulement payer.

Les normes ouvertes brisent cette logique. Là où une norme s’applique, le fournisseur peut être remplacé. Les données peuvent être exportées, le protocole est compris de tous, l’intégration est traçable. Le client reste souverain — et c’est précisément cette souveraineté que les modèles économiques propriétaires redoutent.

Ce n’est pas un hasard si les lobbyistes les plus agressifs contre la normalisation viennent toujours de ceux qui ont le plus à perdre : les propriétaires d’écosystèmes fermés. Normalisation signifie concurrence. Et concurrence signifie devoir fournir des efforts.

Comprendre et déboguer

Quiconque exploite une infrastructure l’apprend vite : les problèmes sont inévitables. Ce qui compte, c’est de pouvoir les comprendre.

Avec une norme ouverte, je peux lire la spécification. Je peux retracer ce qu’un paquet doit contenir, à quoi une réponse doit ressembler, d’où provient une erreur. Je peux capturer une connexion et voir ce qui se passe — parce que les formats sont documentés.

Avec un protocole propriétaire, je vois des octets. Et je vois un contrat de support.

Ce n’est pas un avantage abstrait. C’est la différence entre une soirée où je résous un problème et une semaine passée à attendre une réponse d’un système de tickets étranger.

Ce que cela a à voir avec libcom.de

Chez libcom.de, nous comptons sur les normes ouvertes depuis plus de deux décennies. Par fidélité aux principes ? Non, par pratique. Les systèmes fondés sur des RFC et des normes IEEE se comprennent, se réparent et se développent — même quand le fournisseur initial est oublié depuis longtemps.

Une bonne part de notre travail consiste à aider les clients à sortir des impasses propriétaires et à migrer vers des infrastructures normalisées et interopérables. Cela signifie parfois que nous sommes plus lents qu’une promesse produit séduisante. Mais cela signifie aussi que ce que nous construisons fonctionne encore dans cinq ans — et peut être compris par quelqu’un d’autre.

Si vous vous demandez si votre IT dépend trop de solutions propriétaires, ou si normaliser vos systèmes aurait du sens : écrivez-nous à contact@libcom.de. Nous faisons un inventaire honnête — sans pression commerciale, avec le regard sur ce dont votre infrastructure a besoin à long terme.

Les normes ne sont pas glamour. Personne ne raconte à ses enfants qu’il a négocié aujourd’hui un compromis sur un champ de 32 bits. Mais sans ces compromis, il n’y aurait ni internet, ni web, ni courriel, ni réseau téléphonique fonctionnant au-delà des frontières.

Elles sont le fondement le plus ennuyeux qui tienne le monde ensemble. Et c’est peut-être très bien qu’elles soient ennuyeuses — car ennuyeux veut dire fiable. Et fiable, c’est ce qu’une infrastructure doit être.