Aller au contenu principal

Type de contenu

Analysis

Dans la facette Type de contenu, les articles de type Analysis de BTW.MEDIA sont regroupés selon un même format éditorial, afin de permettre aux lecteurs de comparer briefings, profils, notes de risque, analyses de marché et reportages d'événements sans mélanger différents types de preuves. Cette page explique comment ce type de contenu met en perspective les événements liés à l'infrastructure Internet, les mouvements d'entreprises, les décisions de gouvernance, les signaux opérationnels et les preuves publiques sur l'ensemble du site. Les lecteurs peuvent ainsi identifier les acteurs ou systèmes d'infrastructure les plus fréquents, comprendre comment la qualité des sources modifie l'interprétation et déterminer si le contenu relève d'un profil durable, d'un événement urgent, d'un signal de marché stratégique ou d'une évolution de gouvernance. Le résultat est une page de recherche utile aux opérateurs, investisseurs, clients, analystes et décideurs publics qui doivent comprendre les conséquences, le calendrier et les preuves qui sous-tendent des formats d'articles similaires.

Le chemin le plus rapide portait l’heure sans choisir l’horloge maîtresse : les deux boucles de la RFC 891

Histoire d'Internet

Le chemin le plus rapide portait l’heure sans choisir l’horloge maîtresse : les deux boucles de la RFC 891

Dans les Fuzzballs, une même annonce HELLO nourrissait la table de routage et l’estimation du décalage horaire. Cette mise en commun économisait des échanges, mais elle ne confondait pas les pouvoirs: le délai choisissait un chemin, `CLOCK-HID` désignait la référence et l’horloge…

31 août 2026
La trame était plus longue que le datagramme : comment le RFC 894 a tenu le bourrage Ethernet hors d’IP

Histoire d'Internet

La trame était plus longue que le datagramme : comment le RFC 894 a tenu le bourrage Ethernet hors d’IP

Le RFC 894 affirme encore qu’un champ de données Ethernet a une longueur « minimale » de 1 500 octets, puis en déduit aussitôt une longueur maximale de datagramme de 1 500 octets. L’erreur n’a jamais été effacée du document publié. Elle est restée à côté de sa correction…

31 août 2026
La première réponse n’était qu’un indice : comment la RFC 887 séparait découverte et confirmation

Histoire d'Internet

La première réponse n’était qu’un indice : comment la RFC 887 séparait découverte et confirmation

Une machine pouvait interroger tout le réseau local sans connaître l’adresse d’un serveur. Mais la RFC 887 réservait un autre message pour vérifier directement le candidat trouvé. Elle faisait ainsi de la provenance de la réponse une partie du protocole.

31 août 2026
La liste disait « officiel », pas « mis en œuvre » : comment la RFC 880 séparait le statut du code en fonctionnement

Histoire d'Internet

La liste disait « officiel », pas « mis en œuvre » : comment la RFC 880 séparait le statut du code en fonctionnement

La RFC 880 recommandait TCP et consignait, dans le même mouvement, ses ambiguïtés documentaires. Le mot « officiel » n'effaçait ni les corrections attendues, ni les options mal comprises, ni la distance entre une spécification et une machine. La liste servait précisément à…

31 août 2026
La porte dérobée n’était pas une route : comment le RFC 831 contournait une partition de SATNET

Histoire d'Internet

La porte dérobée n’était pas une route : comment le RFC 831 contournait une partition de SATNET

Une seule ligne PSS arrivait à l’University College London. Il fallait pourtant y faire cohabiter le point d’accès ordinaire et un secours capable d’atteindre la moitié européenne de SATNET après une partition. Le RFC 831 ne proposait pas d’élargir le routage. Il confiait à un…

31 août 2026
La passerelle transportait les octets, pas le sens manquant : comment la RFC 875 a contesté la traduction de protocoles

Histoire d'Internet

La passerelle transportait les octets, pas le sens manquant : comment la RFC 875 a contesté la traduction de protocoles

Deux réseaux incompatibles et une boîte entre eux: le dessin semblait avoir résolu le problème. En septembre 1982, la RFC 875 a rouvert cette boîte. Qui convertissait l’adresse, décidait qu’un accusé valait livraison, rapprochait deux contrôles de flux et interprétait un signal…

31 août 2026
Le registre à jour, les machines en retard : comment la RFC 849 a partagé poussée et interrogation

Histoire d'Internet

Le registre à jour, les machines en retard : comment la RFC 849 a partagé poussée et interrogation

En mai 1983, Mark Crispin ne contestait pas le contenu du fichier maître. Il observait qu'une copie locale pouvait vieillir sans bruit. La RFC 849 a donc séparé l'annonce, le numéro de version, le transfert, le contrôle d'intégrité et la reprise après une absence.

30 août 2026
Le registre disait TCP, mais la prise devait répondre : comment la RFC 832 a mesuré le code en service

Histoire d'Internet

Le registre disait TCP, mais la prise devait répondre : comment la RFC 832 a mesuré le code en service

Un registre peut dire qu'une machine offre TCP. Il ne peut pas, à lui seul, ouvrir une connexion. En décembre 1982, les enquêtes de David Smallberg ont placé ces deux réalités dans des colonnes voisines: la déclaration du fichier des hôtes du NIC, puis ce qu'un essai Telnet, FTP…

30 août 2026
La machine sans exécutif : comment RFC 818 plaça le Telnet utilisateur derrière le port 107

Histoire d'Internet

La machine sans exécutif : comment RFC 818 plaça le Telnet utilisateur derrière le port 107

Le TC68K possédait seize prises série, une interface réseau et un minuteur, mais pas l'environnement général qu'un appel Telnet trouvait habituellement derrière le port 23. Cette absence ne fut pas comblée par un faux système de connexion. RFC 818 désigna l'application réellement…

30 août 2026
Le service de noms a failli négocier : comment la RFC 830 séparait domaines et capacités

Histoire d'Internet

Le service de noms a failli négocier : comment la RFC 830 séparait domaines et capacités

La source connaît le domaine de destination. Elle ne sait pourtant pas encore quel programme l'attend, quel transport il accepte ni même s'il propose le service demandé. La RFC 830 faisait de cet écart un élément d'architecture: localiser le domaine constituait une première…

30 août 2026
Le numéro n’en faisait pas une norme : comment la RFC 825 inscrivait l’intention dans le document

Histoire d'Internet

Le numéro n’en faisait pas une norme : comment la RFC 825 inscrivait l’intention dans le document

Dans une bibliothèque, un manuel, le compte rendu d’une réunion et une proposition controversée peuvent porter des cotes voisines. Personne n’en déduit qu’ils ont la même autorité. La série des RFC avait besoin de cette même prudence: un numéro commun permettait de retrouver des…

30 août 2026
La couche n’était pas le module : comment RFC 817 recoupait la pile

Histoire d'Internet

La couche n’était pas le module : comment RFC 817 recoupait la pile

Déporter les protocoles vers un processeur frontal semblait offrir une sortie élégante: un système spécialisé, réutilisable par plusieurs machines, débarrassait le noyau principal de sa complexité. RFC 817 remarquait le détail qui ruinait cette fuite. Il fallait encore relier les…

30 août 2026
Le message d’erreur conseillait, il ne tranchait pas : comment RFC 816 distribuait les décisions de panne

Histoire d'Internet

Le message d’erreur conseillait, il ne tranchait pas : comment RFC 816 distribuait les décisions de panne

Pendant qu’un réseau recalcule ses chemins, un message « destination inaccessible » peut décrire un instant déjà révolu. RFC 816 n’en concluait pas que les erreurs étaient inutiles. Il leur attribuait une portée précise, aux côtés du silence de la première passerelle, du délai…

30 août 2026
Le segment manquant n’arrêtait pas le suivant : RDP séparait fiabilité et ordre

Histoire d'Internet

Le segment manquant n’arrêtait pas le suivant : RDP séparait fiabilité et ordre

Dans un atelier de maintenance relié à un réseau de 1984, trois blocs arrivent, un quatrième manque, puis deux autres se présentent intacts. Le protocole RDP ne demandait pas au récepteur de mentir en déclarant que rien n’avait avancé. Il lui permettait d’attester les blocs reçus…

30 août 2026
Le nom n’était pas l’adresse : comment RFC 814 a séparé l’identité de la route

Histoire d'Internet

Le nom n’était pas l’adresse : comment RFC 814 a séparé l’identité de la route

Un hôte déménage, mais une ancienne table continue de lui attribuer son adresse précédente. La connexion réussit et atteint pourtant une autre machine. En 1982, RFC 814 a pris ce paradoxe au sérieux: le nom, l’adresse, la route et le port ne sont pas quatre façons équivalentes de…

30 août 2026
L’accusé de réception s’arrêtait à la liaison : comment PPP circonscrivait la fiabilité

Histoire d'Internet

L’accusé de réception s’arrêtait à la liaison : comment PPP circonscrivait la fiabilité

PPP pouvait rendre une liaison plus fiable sans prétendre rendre tout le trajet certain. Avec RFC 1663, deux voisins pouvaient numéroter, acquitter et retransmettre leurs trames. L’accusé reçu attestait une progression locale; il ne certifiait ni l’identité du pair, ni la route…

30 août 2026
La hiérarchie était en réalité un graphe : comment Gopher plaçait le prochain serveur dans chaque ligne de menu

Histoire d'Internet

La hiérarchie était en réalité un graphe : comment Gopher plaçait le prochain serveur dans chaque ligne de menu

L'écran promettait une arborescence paisible. Le réseau exécutait autre chose: une succession de décisions prises par des machines autonomes. Dans Gopher, une ligne de menu séparait le nom destiné au lecteur d'un sélecteur opaque, d'un hôte, d'un port et d'un type de transaction.…

30 août 2026
Le rapport ne pouvait pas condamner la liaison : PPP laissait le seuil à chaque extrémité

Histoire d'Internet

Le rapport ne pouvait pas condamner la liaison : PPP laissait le seuil à chaque extrémité

Compter les paquets perdus ne suffit pas à dire qu’une liaison est mauvaise. Avec les Link-Quality-Reports, PPP a donné aux deux extrémités une comptabilité comparable des deux sens de circulation, tout en refusant d’imposer un seuil universel ou une procédure unique de coupure.…

30 août 2026
Un lien en cachait plusieurs : comment PPP Multilink donnait une seule séquence au faisceau

Histoire d'Internet

Un lien en cachait plusieurs : comment PPP Multilink donnait une seule séquence au faisceau

L’ajout d’une ligne ne devait pas obliger le réseau à recommencer sa conversation. PPP Multilink conservait les trames propres à chaque membre, mais plaçait leurs fragments dans un ordre commun au faisceau. Ce compromis disait au récepteur comment refaire le paquet sans imposer à…

30 août 2026
Le succès qui rendait son propre flux caduc : comment XMPP redémarrait après TLS et SASL

Histoire d'Internet

Le succès qui rendait son propre flux caduc : comment XMPP redémarrait après TLS et SASL

Dans XMPP, réussir une négociation de sécurité ne permettait pas à l’ancien flux XML de poursuivre sa route. Cette réussite changeait au contraire les conditions de vérité du dialogue: la connexion TCP restait ouverte, mais les en-têtes, l’identifiant et les fonctions du flux…

30 août 2026