Résumé

  • En janvier 1997, RFC 2068 a inscrit 402 Payment Required dans HTTP/1.1, puis l’a déclaré « réservé pour un usage futur ».
  • RFC 2616, RFC 7231 et RFC 9110 ont gardé la même réserve. HTTP ne fournit toujours ni prix commun, ni défi de paiement, ni règle de règlement pour ce code.

Le numéro est arrivé avant la caisse

RFC 1945 décrivait le code d’état comme un résultat destiné aux machines et publiait la liste des valeurs reconnues pour HTTP/1.0. Dans la série des erreurs client, 401 Unauthorized était suivi de 403 Forbidden : 402 n’y figurait pas. Le texte autorisait toutefois des codes d’extension. Le numéro pouvait donc circuler comme extension; le catalogue ne lui donnait simplement aucune définition propre. RFC 1945 §§6.1.1–6.1.2

La spécification HTTP/1.1 de janvier 1997 a rendu 402 visible. RFC 2068 l’a ajouté à la grammaire des codes et lui a consacré la section 10.4.3. Sa règle tenait en une phrase : « This code is reserved for future use. » Le libellé annonçait une barrière financière; le texte normatif n’expliquait pas comment la franchir. RFC 2068 §§6.1.2, 10.4.3

Un code peut signaler un résultat. Il ne fabrique pas les pièces d’une transaction. La définition de 402 ne précise ni montant, ni devise, ni bénéficiaire, ni justificatif de paiement, ni confirmation, ni règlement, ni procédure de contestation. Un serveur peut détailler ses propres conditions dans la réponse; HTTP ne les rend pas réutilisables d’un service à l’autre.

401 sait quoi demander; 402 garde le guichet vide

Le code voisin 401 montre à quoi ressemble un échange partagé. RFC 9110 impose qu’une réponse 401 contienne WWW-Authenticate avec au moins un défi applicable. Le client peut examiner le mécanisme et déterminer comment fournir ses identifiants. La section 15.5.3 ne donne rien d’équivalent à 402 : elle répète la réserve, puis s’arrête. RFC 9110 §§15.5.2–15.5.3

Cette absence laisse une tâche précise aux développeurs d’applications. Pour protéger une ressource par un paiement, le service doit définir ce qui est dû, la preuve attendue, le destinataire du paiement et la conduite à tenir en cas de refus ou d’échec du règlement. Le code HTTP marque le refus; l’application construit la caisse, le reçu et la suite de l’échange.

Le futur a été reconduit plusieurs fois

En juin 1999, RFC 2616 a repris la même phrase à la section 10.4.3. RFC 7231 l’a répétée en 2014. RFC 9110 l’a encore reprise en 2022. Le numéro de section a changé; la réserve, elle, a voyagé d’une génération d’HTTP à la suivante. Les révisions ont renouvelé la sémantique du protocole sans fournir les règles de paiement manquantes. RFC 2616 §10.4.3 · RFC 7231 §6.5.2

Les RFC ne nomment pas le système de paiement envisagé par leurs auteurs. Une note de conception datée qui l’identifierait modifierait cette histoire. Les textes publiés donnent un nom au code et conservent sa réservation; ils ne livrent pas son origine.

Dans la page consultée pour cet article, mise à jour le 15 septembre 2025, le registre IANA classe toujours 402 sous « Payment Required » et renvoie à la RFC 9110, § 15.5.3. Registre IANA des codes d’état HTTP

Le coût remonte jusqu’au développeur

C’est là que l’économie d’une interface logicielle apparaît. Un protocole partagé peut éviter à chaque équipe de reconstruire les mêmes règles dans une documentation privée. Le 402 d’HTTP ne le fait pas. Le client de l’acheteur et le serveur doivent s’accorder au niveau de l’application sur le tarif, la preuve, les identifiants, les reprises et la finalité du paiement. Les développeurs prennent en charge l’intégration et la maintenance; chaque service garde la main sur ses conditions.

Le code nomme donc une situation sans constituer une interface de paiement. Il avertit le client que l’accès dépend d’un paiement. Il ne lui offre aucune méthode commune pour remplir cette condition. Dans HTTP, la caisse reste une règle locale munie d’un numéro standard.

Sources