Loi de Postel

Janvier 1980, RFC 761. Jon Postel — l'éditeur des Request for Comments, gardien discret des protocoles du jeune Internet — glisse dans la spécification de TCP une section 2.10 sobrement intitulée « Robustness Principle » : « be conservative in what you do, be liberal in what you accept from others ». Le principe, déjà esquissé en 1979 dans la spécification d'IPv4, visait l'interopérabilité : des implémentations écrites par des équipes différentes devaient se comprendre malgré leurs défauts. Bob Braden le durcira en 1989 dans la RFC 1122, avec une consigne préventive restée célèbre : programmez comme si le réseau était peuplé d'entités malveillantes.

Le web doit une part de sa croissance à cette tolérance : les navigateurs ont toujours affiché le HTML bancal plutôt que de le rejeter — au point que HTML5 a fini par standardiser l'algorithme exact de digestion du code invalide. Le design d'interface a ensuite adopté la loi telle quelle, en changeant un mot : l'utilisateur est l'autre système avec lequel il faut interopérer. Formulaires, champs de recherche, commandes vocales — accepter l'entrée humaine telle qu'elle vient, produire une sortie stricte. Le designer britannique Mark Boulton l'a même étendue aux organisations et aux design systems.

Le principe possède sa contre-littérature, et elle est instructive. Dès 2001, Marshall Rose observe dans la RFC 3117 que la tolérance permet aux implémentations défectueuses de survivre des années avant d'être identifiées — à un coût de correction croissant. En 2018, Florentin Rochet et Olivier Pereira démontrent qu'on peut exploiter le principe de robustesse au sein même du protocole de Tor pour compromettre ses protections d'anonymat. Et en 2023, la RFC 9413 de Martin Thomson et David Schinazi formalise le paradoxe : à force de tolérer les défauts, on les enracine, jusqu'à imposer des implémentations « compatibles bug pour bug ».

Transposée à l'interface, la loi renverse la charge de la preuve : chaque validation stricte en entrée est un transfert de travail de la machine vers l'humain. La recherche sur les formulaires converge — les rejets de pure forme, numéro de téléphone saisi avec espaces, majuscule dans l'adresse email, date tapée en toutes lettres, comptent parmi les causes documentées d'abandon, alors que la normalisation côté machine coûte quelques lignes de code. La règle opérationnelle en découle : ne demander une correction que lorsque l'intention est réellement ambiguë, jamais lorsque seul le format est en cause. L'erreur affichée doit être l'exception, pas la routine.

Les interfaces conversationnelles sont la loi de Postel devenue produit : un grand modèle de langage accepte par construction les fautes, les langues mélangées, les demandes floues et les briefs contradictoires — le rêve de tolérance en entrée que les formulaires n'ont jamais atteint. L'enjeu bascule donc entièrement sur l'autre moitié de la loi, la sortie conservatrice : formats structurés, function calling, validation systématique de ce que le modèle produit avant de l'injecter dans un CRM, un devis ou un email client. Pour le marketing, c'est un déplacement historique : le coût de la mise en forme, longtemps payé par le client, est enfin porté par le système.

Le risque est exactement celui que Braden et la RFC 9413 décrivaient : une entrée trop libérale est une surface d'attaque. L'injection de prompt — glisser des instructions malveillantes dans un texte que l'agent va lire — est l'exploitation directe du principe de robustesse appliqué aux LLM. Une marque qui branche un agent IA sur ses données clients doit donc être libérale sur la forme mais méfiante sur le fond : filtres en amont, validation des sorties, périmètre d'action limité. Tolérance n'a jamais voulu dire naïveté, et Postel lui-même parlait de prudence.