Sommaire
Dans les coulisses d’Internet, rien n’est laissé au hasard : protocoles, formats et langages naissent d’un patient travail de consensus. Dans Search Off the Record, Martin Splitt et Gary Illyes (Google Search) ont expliqué comment l’IETF, le W3C, le WHATWG ou encore ECMA transformaient des idées en standards qui rendaient le Web fiable, interopérable et durable.
Pourquoi les standards comptent
Les standards du Web sont ces règles partagées qui rendent Internet prévisible, interopérable et durable. Sans eux, chaque navigateur, crawler ou serveur implémenterait “sa” version des choses, au risque de casser l’expérience utilisateur.
Du protocole HTTP aux fichiers robots.txt, de HTML à JavaScript, ces normes naissent rarement d’un coup d’éclat : elles émergent d’un travail patient de consensus, mené publiquement dans des instances spécialisées.
“Un standard”, c’est quoi au juste ?
Dans la pratique, c’est un document (spécification) adopté par une communauté de pairs sous l’égide d’un organisme. Quelqu’un propose une idée, on la discute, on l’amende, on la teste, puis on l’“élève” au rang de standard lorsqu’un niveau suffisant d’accord est atteint.
On obtient ensuite une référence stable que développeurs, éditeurs et fabricants peuvent implémenter de façon cohérente.
Qui fait quoi : panorama des instances
- IETF (Internet Engineering Task Force) : plutôt les couches “basses” et les protocoles d’Internet (TCP/IP, TLS, HTTP/3, QUIC…).
- W3C (World Wide Web Consortium) & WHATWG : le Web côté navigateur (HTML, DOM…). WHATWG maintient par exemple la “living standard” de HTML.
- ECMA / TC39 : standardisation du langage JavaScript (ECMAScript).
- RSS Advisory Board : gouvernance de RSS.
On choisit l’instance selon le périmètre (protocole réseau, langage, format, navigateur, etc.) et… la communauté la plus compétente pour porter le sujet.
De facto vs. “vrai” standard
De nombreux formats commencent comme “de facto standards”. Tout le monde les utilise, mais aucune instance ne les a formellement adoptés. Exemple souvent cité : Sitemaps (années 2005–2006) — massivement implémenté, mais longtemps sans statut officiel.
À l’inverse, robots.txt, longtemps de facto, a finalement été standardisé à l’IETF, ce qui a clarifié l’interprétation et réduit les divergences entre parsers.
Comment on choisit l’organisme de standardisation ?
On va là où :
- la compétence technique est la plus forte sur le sujet,
- les pairs susceptibles d’implémenter/relire se trouvent déjà,
- l’adoption a des chances d’être la plus large.
Ex. : un remplaçant de TCP n’a de sens qu’à l’IETF, car c’est là que vivent l’historique, les experts et les processus adaptés. Pour un format de contenu Web, W3C/WHATWG est souvent plus pertinent.
Le parcours type à l’IETF (expliqué simplement)
- Idée & brouillon (Internet-Draft) : un document initial pose le cadre.
- Working Group (WG) : vous trouvez le groupe de travail qui “adopte” votre draft (HTTP, TLS, etc.). À défaut, vous passez par la liste “dispatch” qui oriente votre proposition.
- Itérations publiques : relectures, objections, précisions… C’est lent par design : on traque les ambiguïtés et les failles possibles (sécurité, compatibilité, parsabilité, etc.).
- Les mots-clés MUST/SHOULD/MAY (en capitales) portent un poids normatif : MUST = obligatoire ; SHOULD = fortement recommandé mais contournable ; MAY = optionnel.
- On précise jusqu’aux cas limites de parsing (lignes vides, séparateurs…), car les implémenteurs s’y fient.
- Sécurité & robustesse : on anticipe les mauvais usages (ex. tailles limites pour éviter des dépassements mémoire).
- Preuves que ça marche : prototypes, implémentations de référence et tests croisés.
- Derniers examens : “Last Call” (appel aux dernières remarques) + revue par des directorates (comités transverses).
- Statut final : Proposed Standard (évolutif) ou Internet Standard (très stabilisé).
Tout est public : listes, réunions, dépôts. Participer demande surtout de l’énergie — et parfois des frais logistiques pour les rencontres en présentiel.
Pourquoi ça prend des années ?
Parce que ces textes doivent tenir longtemps et partout. Mieux vaut nitpicking aujourd’hui que casse en production demain. La lenteur est un garde-fou : elle améliore la clarté, révèle les angles morts et forge le consensus indispensable à l’adoption.
Exemple concret : robots.txt vs. Sitemaps
robots.txt: très important pour les moteurs. En le standardisant, la communauté a aligné les parsers, ouvert la voie à des implémentations open source plus fiables et allégé la charge côté éditeurs (moins d’interprétations “surprise”).- Sitemaps : format simple et largement adopté. Le bénéfice d’une standardisation formelle est moins évident (moins de zones d’ambiguïté et moins de risques).
Moralité, tout ne mérite pas d’être standardisé — il faut pondérer l’effort par le gain réel (interop, sécurité et clarté).
Et les autres standards du Web ?
- HTML : aujourd’hui maintenu comme “living standard” (WHATWG), ce qui permet d’évoluer en continu tout en gardant une référence unique et à jour.
- JavaScript (ECMAScript) : piloté par TC39 (ECMA). Le processus par étapes (stages) encadre l’arrivée des nouvelles fonctionnalités, avec implémentations d’essai côté moteurs JS et retours de la communauté.
- RSS / Atom : gouvernances distinctes (RSS Advisory Board vs. IETF pour Atom), qui illustrent bien que formats proches peuvent suivre des voies institutionnelles différentes.
Règle d’or : standardiser quand c’est utile
On ne “fait pas un standard” pour la gloire. On le fait quand il apporte :
- Interopérabilité (tous lisent la même chose et de la même façon),
- Sécurité (angles morts comblés et limites explicites),
- Clarté (moins d’ambiguïtés pour les implémenteurs),
- Adoption (une communauté prête à l’utiliser).
Sinon, un consensus de facto peut suffire.
Un processus ouvert… vraiment ouvert
Bonne nouvelle, vous pouvez contribuer. Les drafts, issues, réunions et listes sont publiques. Certaines rencontres sont payantes (logistique), mais la porte est ouverte : pas de “club fermé”. C’est l’une des forces du Web, la standardisation se fait à ciel ouvert.
