Domaine principal
Infrastructure Internet
Au sein de la facette Domaine principal, l'analyse Infrastructure Internet regroupe les articles par domaine principal afin que les lecteurs puissent suivre un périmètre précis de l'infrastructure Internet, de la gouvernance, des marchés de connectivité ou du capital numérique. Cette page rassemble les articles associés, les preuves publiques, les institutions, les entreprises, les personnes, l'exposition régionale, les dépendances opérationnelles et le contexte de marché qui pourraient sinon être répartis entre différentes pages de catégories. Elle explique le domaine, la classe d'acteurs probable, le contexte de marché ou de gouvernance, ainsi que les sources que les lecteurs devraient utiliser pour comparer les signaux. Opérateurs, analystes et lecteurs de gouvernance peuvent voir comment un même domaine se manifeste à travers les événements, les profils, les évolutions de marché, les preuves issues de sources publiques, les dépendances régionales et les décisions d'infrastructure à plus long cycle au fil du temps.

Histoire d'Internet
Une requête vide pouvait révéler les présences en ligne : la frontière de Name/Finger
En 1977, une requête réduite à CRLF pouvait demander à un hôte la liste de ses utilisateurs présents. Le réseau transportait la demande; le site choisissait la réponse et ses champs.

Histoire d'Internet
Le plan triennal pour un annuaire Internet : RFC 1107
En juillet 1989, le RFC 1107 décrivait une voie possible vers un annuaire de personnes pour les réseaux de recherche. Son calendrier tenait en trois ans; son statut rappelait aussitôt que la communauté Internet n’avait pas engagé cette activité de recherche. La différence entre…

Universitaires
Kurtis Heimerl : le service local ne signifie pas le contrôle de l’opérateur
Un réseau cellulaire communautaire promet davantage qu’un signal moins cher: il permet à un territoire d’adapter ses communications là où un opérateur national voit peu de rentabilité. Les travaux de Kurtis Heimerl montrent à la fois cette possibilité et sa limite. Les équipes…

Histoire d'Internet
Le serveur de noms ne diffusait pas les datagrammes de groupe : RFC 1001 et RFC 1002
Un annuaire peut indiquer où un nom est enregistré sans acheminer le message vers tous ceux qui le portent. Dans la proposition NetBIOS sur TCP publiée en mars 1987, la diffusion d’un datagramme de groupe relevait d’un autre rôle logique. Les deux RFC distinguaient ces fonctions…

Tendances télécoms nationaux Europe et Moyen-Orient
L’accord d’OFN avec iQ prolonge FIG par voie terrestre, sans encore prouver le service de bout en bout
OFN ajoute un fournisseur terrestre nommé au projet de débarquement de FIG en Irak. L’accord fait avancer l’architecture annoncée, mais les informations publiques ne permettent pas encore d’évaluer le service complet, ses responsables ni sa résilience réelle.

Histoire d'Internet
Le raccordement Ethernet était commun ; l’IGP ouvert manquait encore : RFC 1009
En 1987, pour relier les passerelles de fournisseurs différents dans le contexte du NSFNET, la National Science Foundation a fixé un point de raccordement familier: Ethernet, accompagné au minimum de liaisons série. Le même texte reconnaissait qu’aucun IGP ouvert ne permettait…

Histoire d'Internet
La recherche d’Archie ne pouvait pas être plus à jour que sa dernière liste FTP
Archie a rendu consultables des archives FTP anonymes dispersées sur le réseau en recueillant leurs listes de répertoires. Cette nuance définit le service: il pouvait indiquer un nom et un emplacement, mais le fichier restait sur une autre machine et l’index ne décrivait que ce…

Entreprises télécoms nationaux Europe et Moyen-Orient
Les économies d’IA de Deutsche Telekom doivent encore passer l’épreuve de la trésorerie
Deutsche Telekom relève l’ambition affichée pour l’IA, mais les 2,5 milliards d’euros annoncés à l’horizon 2030 désignent des économies brutes de coûts indirects. Le point décisif est de relier cette mesure aux dépenses, au capital mobilisé et aux activités réellement…

Histoire d'Internet
Si le serveur ne pouvait pas annuler, la RFC 1036 lui disait de s’arrêter là
Un message de contrôle pouvait circuler comme les autres nouvelles d’Usenet, mais son autorité dépendait de ce que chaque serveur possédait et pouvait vérifier lui-même. La RFC 1036 fixait une limite nette: si le système ne pouvait pas annuler l’article demandé, il ne devait pas…

Histoire d'Internet
La licence visait le logiciel, pas le protocole : la frontière tracée par Gopher en 1993
Le 11 mars 1993, l’équipe Gopher du Minnesota publie dans un groupe Usenet une note qui commence par vouloir calmer les rumeurs. La formule retenue par la mémoire collective tient en quelques mots: les usages commerciaux devraient payer. Le texte, lui, distingue les services…

Entreprises télécoms nationaux Amérique du Nord
Coentreprise fibre d’AT&T : l’accès ouvert dépendra de son client d’ancrage
AT&T veut réunir Forged Fiber 37 et Gigapower avec GIP et CPP Investments. La répartition du capital est annoncée; les règles de gros qui donneront un contenu concret à l’« accès ouvert » ne le sont pas. AT&T reste au cœur de la relation client et avait été désignée comme client…

IETF
Avec le RFC 10065, l’identifiant de groupe déclenche une règle sans prouver son application
Un accusé de réception RADIUS peut montrer qu’un NAS a reçu une valeur de groupe; il ne démontre pas, à lui seul, que la règle voulue filtre le trafic en aval. Le RFC 10065 clarifie le transport de cette valeur, tandis que la preuve d’application reste à construire dans chaque…

Histoire d'Internet
Un port ne suffisait pas : RFC 675 a intégré le réseau au nom du socket
Un service peut garder le même point d’entrée local tout en répondant à des interlocuteurs différents. RFC 675 nomme ces échanges par les deux sockets d’extrémité; la question du port local vient ensuite, quand il faut comprendre comment chaque nom reste distinct à travers les…

Dossier
Après l’incident Philippines–Singapour, « rétabli » ne suffit pas
Le 2 octobre, des sondes ont relevé une forte hausse de latence entre les Philippines et Singapour sans pouvoir désigner un câble. InfiniVAN a ensuite annoncé le rétablissement de son segment C2C; les opérateurs ont, eux, décrit leurs propres déroutages et retours à la normale.…

Histoire d'Internet
La prise avait quatre broches : NORDUnet et le choix européen des protocoles
En mai 1988, un réseau de recherche nordique demanda aux États-Unis une liaison vers NSFNET tout en prévoyant de transporter plusieurs services déjà utilisés dans la région. Sa « prise » à quatre broches répondait à une question plus difficile qu’un choix de protocole: pouvait-on…

Récits
Le poste ancien s’est tu. Son bail IPv4, lui, reste.
Un masque DHCPv4 en /32 peut calmer un client ancien qui ne sait pas utiliser l’option IPv6-Only Preferred. L’adresse accordée, les paquets entrants encore possibles et le pool qui porte le bail restent des sujets d’exploitation.

Histoire d'Internet
La balise était un seul jeton, pas une carte de navigation : RFC 1766
RFC 1766 découpait une balise de langue en valeur principale et sous-balises séparées par des traits d’union, tout en demandant aux applications de traiter la chaîne entière comme un jeton. Cette structure ordonnait un espace de noms partagé; elle ne dessinait pas un parcours…

IETF
Syslog pouvait signaler la qualité de son horloge. L’opérateur devait encore en définir les limites : RFC 5424
Lorsqu’un incident se joue entre plusieurs machines, une heure affichée à la milliseconde donne facilement une impression de certitude. RFC 5424 prévoit justement un moyen de joindre au journal ce que l’émetteur sait — ou ne sait pas — de sa propre mesure du temps.

Histoire d'Internet
Avec WAIS, un document pouvait nourrir la recherche suivante : la boucle de pertinence de la RFC 1625
Un lecteur pouvait saisir quelques mots, joindre un document — ou un simple passage — et demander à WAIS de trouver des textes similaires. La réponse était une citation classée, pas un ensemble de résultats conservé ni le document lui-même. La RFC 1625 décrit ce choix discret…

IETF
Dans le tunnel EAP-FAST, le type 6 changeait de sens : RFC 5421
Le RFC 5421 a placé un code EAP familier dans un nouveau cadre: le type 6 restait associé au Generic Token Card, mais, à l’intérieur d’un tunnel EAP-FAST, il sélectionnait un échange interne au format différent. Le texte imposait une séparation stricte entre ces usages et son…
