Domaine principal
Infrastructure
Au sein de la facette Domaine principal, l'analyse Infrastructure 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
Après le PHP, le label OAM arrivait à la sortie — à condition qu’elle sache le lire : RFC 3429
Dans un réseau MPLS, retirer une étiquette avant le routeur de sortie peut alléger son travail. Mais une trame de diagnostic ne devient pas pour autant un paquet ordinaire. En 2002, le RFC 3429 a réservé une valeur pour que l’OAM reste reconnaissable après ce retrait, tout en…

Histoire d'Internet
Le premier profil AAL2 commun devait encore être associé aux services : RFC 3441
Deux passerelles pouvaient obtenir une liste commune de profils AAL2 sans avoir encore décidé quelles lignes transporteraient la voix, les données en bande vocale ou le fax. RFC 3441 distingue l’intersection des profils, les préférences de service, l’établissement du support ATM…

Tendances télécoms nationaux Europe et Moyen-Orient
Les 500 Tbit/s d’e& exigent des routes vérifiables, pas un effet d’échelle
e& vise plus de 500 Tbit/s de capacité internationale d’ici 2030, contre 20 aujourd’hui selon le groupe. Son réseau et ses services de gros donnent à cette ambition un socle opérationnel; le financement du projet, la capacité réellement commercialisable et l’indépendance des…

Tendances services cloud Europe et Moyen-Orient
En rachetant TechWolf, SAP acquiert une carte du travail — et la responsabilité de ses preuves
SAP veut intégrer le graphe de travail de TechWolf à SuccessFactors tout en maintenant l’accès des clients non-SAP. L’intention est stratégique, mais les conditions commerciales et les droits sur les données restent inconnus tant que l’opération n’est pas conclue.

Tendances centres de données Amérique du Nord
PDN finance deux systèmes B300, mais pas avec le même risque de principal
Professional Diversity Network a engagé environ 1,177 million de dollars dans deux systèmes NVIDIA B300. Pourtant, les contrats ne prévoient pas un seul chemin de retour du capital: le premier repose sur un loyer indépendant du chiffre d’affaires, mais résiliable et exposé à la…

Tendances centres de données Amérique du Nord
Axe détient les GPU, Duos garde le site : une échéance liée au refinancement
La vente de Columbus sépare les serveurs du campus qui les héberge. Son économie dépend d’une créance vendeur qui peut devenir exigible lorsque le nouveau propriétaire emprunte sur le matériel acquis.

Entreprises services cloud mondiales
almazcloud.network : l'audit de cohérence d'une identité d'opérateur que rien ne soutient
Un opérateur qui se présente comme un fournisseur de services cloud « tout nouveau et progressif » vend des interconnexions d'entreprise à des prix en dollars, promet un peering physique direct avec les plus grands réseaux de Russie et affiche une vitrine commerciale complète. La…

Entreprises institutionnelles mondiales
G42 : une autorisation d'exportation qui expire toute seule — le compte à rebours de 2027 comme vraie contrainte
Abu Dhabi a obtenu ce que peu de pays hors des États-Unis ont jamais décroché: un accès aux puces américaines les plus avancées pour ses entreprises d'intelligence artificielle. Mais la règle publiée en juillet 2026 par le Bureau of Industry and Security (BIS) contient une clause…

Histoire d'Internet
REGISTER prenait fin ; son chemin servait ensuite : RFC 3327
La liaison répond à « où joindre l’UA ? »; elle ne répond pas à « par quels relais devra passer la prochaine requête ? ». RFC 3327 a donné à ces deux questions des réponses distinctes: le registrar gardait le Contact, tandis qu’un Path ordonné accompagnait cette liaison pour…

Histoire d'Internet
Dans TLS, AES arriva en douze choix, pas en un seul : RFC 3268
En 2002, TLS a accueilli AES sans changer la poignée de main. L’ajout prit pourtant la forme de douze suites nommées: le chiffrement ne décidait ni de l’échange de clés ni de l’authentification.

Histoire d'Internet
La clé aléatoire ne réparait rien. Elle empêchait l’échec de parler : RFC 3218
Un destinataire CMS pouvait refuser un message avant même d’en examiner le contenu. Ce diagnostic semblait précis et utile, mais sa répétition transformait une différence interne en service de déchiffrement pour l’adversaire. RFC 3218 imposa alors un geste paradoxal: inventer une…

Histoire d'Internet
L’URL n’était plus une case à part : RFC 3305
Au début du Web, la distinction semblait limpide: l’URL indiquait où aller; l’URN nommait une ressource sans dépendre de son emplacement. En 2002, un groupe de planification commun au W3C et à l’IETF a soutenu, dans la RFC 3305, que cette séparation trop nette compliquait la…

Histoire d'Internet
La confirmation disait que le NAK avait été entendu, pas que la réparation était arrivée : RFC 3208
PGM a rendu la fiabilité multicast praticable en comprimant les retours. Les récepteurs signalaient les trous, les routeurs confirmaient et fusionnaient ces demandes, puis la réparation ne suivait que les branches concernées. Cette économie avait une limite nette: un NCF…

Histoire d'Internet
Un milliard d’internautes n’aurait pas suffi : RFC 3271
En 2002, Vint Cerf prévoyait plus d’un milliard d’internautes avant la fin de 2005, tout en précisant que cela ne représenterait qu’environ 16 % de la population mondiale. Ce décalage transforme « Internet est pour tout le monde »: non plus un slogan de croissance, mais une série…

Histoire d'Internet
IPsec authentifiait chaque paquet, pas forcément l’utilisateur dans le tunnel : RFC 3193
Le tunnel sécurisé de RFC 3193 n’était pas un objet unique. L2TP connaissait la session, le pair et le port finalement choisis; IKE connaissait l’identité négociée et les sélecteurs de l’association de sécurité. Le document a dû organiser leur dialogue, puis rappeler qu’une…

Histoire d'Internet
Des blocs réutilisables pouvaient échouer ensemble : RFC 3269
Le multicast fiable ne se résumait pas à assembler des pièces réutilisables. La RFC 3269 exigeait que chaque bloc RMT déclare ses limites et dépendances, puis que le protocole complet explique leur articulation.

Histoire d'Internet
Le plan d’adressage était plein à 87 %, alors que la plupart des adresses restaient libres : RFC 3194
RFC 3194 a donné un pourcentage à la douleur des plans d’adressage hiérarchiques. Mais 87 % de densité d’hôtes ne signifiait pas 87 adresses occupées sur cent. Pour un espace de 32 bits, le tableau arrivait à environ 240 millions d’objets, soit à peine 5,6 % des valeurs…

Histoire d'Internet
Le numéro de téléphone n’est devenu une adresse mail qu’auprès de la passerelle : RFC 3191
Un numéro pouvait traverser le courrier électronique sans que chaque serveur soit autorisé à le composer. RFC 3191 a placé l’instruction téléphonique dans la partie gauche de l’adresse, puis confié au domaine de droite le choix de l’unique passerelle capable de l’interpréter. La…

Histoire d'Internet
Sur le réseau, l’échantillon était valide ; sur la bande, il signalait une panne : RFC 3190
Un lecteur DV et un paquet RTP pouvaient recevoir le même nombre et raconter deux histoires contraires. Pour l’un, c’était l’absence d’un son lisible. Pour l’autre, c’était le son lui-même. RFC 3190 a dû organiser cette contradiction avant de transporter le moindre canal.

Histoire d'Internet
Le numéro était national. Sa persistance dépendait pourtant d’un service concret : RFC 3188
Une bibliothèque nationale pouvait attribuer un nom destiné à durer des siècles. Le nom ne conservait pourtant aucun octet par lui-même. Dans RFC 3188, la persistance reposait sur des catalogues, des archives, des résolveurs et des institutions capables de continuer leur travail…
