Profil
Research
Research rassemble les profils des personnes, entreprises, institutions et autres entités couvertes par BTW.MEDIA, afin que les lecteurs puissent comparer les sujets derrière ses reportages. La page permet de comparer les profils publics, les événements associés, les dossiers de preuves, les changements de responsabilités, l’ampleur des activités, l’exposition aux instances de gouvernance, les liens organisationnels et la pertinence sur le marché, tout en distinguant les fiches des organisations et des personnes de la simple chronologie de l’actualité. Les lecteurs peuvent comprendre qui ou ce que représente le profil, sur quelles sources publiques il s’appuie, comment il se relie aux entreprises, aux infrastructures, aux marchés, aux instances de gouvernance ou aux événements, et quels changements méritent une attention continue à mesure que le sujet évolue.
Entreprises services cloud mondiales
Les engagements de Meta pèsent 279 milliards de dollars, mais la capacité déployée reste un autre débat
Meta Platforms a fixé un cadre de dépenses gigantesque: 278,99 milliards de dollars de baux de centres de données pas encore commencés au 30 juin 2026, 68 milliards de dollars supplémentaires signés en juillet, et un cap des dépenses d'investissement 2026 ramené à 130–145…
IETF
La pratique était déclarée. Son exécution restait à prouver : RFC 3647
Deux autorités de certification présentent des documents construits selon les mêmes rubriques. L’équipe d’interopérabilité peut enfin comparer leurs engagements sans réinventer le vocabulaire. Mais l’alignement des titres ne dit pas si les cérémonies, les contrôles et les délais…
Histoire d'Internet
Assez de symboles reconstruisaient l’objet. L’émetteur ignorait encore qui avait terminé : RFC 3450
ALC a rendu la multidiffusion fiable extensible en supprimant la conversation de réparation avec chaque destinataire. Chaque récepteur pouvait reconstruire l’objet à partir de son propre ensemble de symboles. Cette réussite n’était pourtant pas un registre de livraison…
Histoire d'Internet
Le récepteur annonçait un débit. L’émetteur devait encore imposer ses propres limites : RFC 3448
Dans TFRC, le récepteur détenait une vue privilégiée des paquets arrivés, mais pas un droit sur la capacité future. RFC 3448 transforma ses observations en données d’entrée et conserva chez l’émetteur la responsabilité du calcul, du rythme et du repli.
Récits
La chaîne d'identité d'almazcloud.network : chaque maillon vérifiable, aucune preuve qui les relie
Le site almazcloud.network, opéré sous la marque DIAMOND (« ALMAZ » en russe), vend cinq produits à prix affichés et promet une « connexion physique de peering directe » vers Yandex, Sberbank et Rostelecom. Indépendamment, le registre et les collecteurs de routage décrivent une…
IETF
Le signal OAM est revenu, pas la preuve du service : RFC 9772
Un aller-retour réussi dans un tunnel Geneve peut innocenter un segment précis sans répondre à la plainte d’un locataire. RFC 9772 vaut surtout par cette discipline: rattacher chaque mesure au VNI, au traitement et au point de terminaison réellement parcourus, puis refuser que…
Histoire d'Internet
Une adresse partagée exigeait des identités uniques en coulisses : RFC 3446
Anycast permettait à plusieurs points de rendez-vous multicast de présenter une même entrée proche. Il ne les transformait pas en une seule machine. RFC 3446 tenait parce que l’adresse offerte aux sources était commune, tandis que les identités utilisées entre répliques restaient…
IETF
Le réseau a proposé un DNS. La machine gardait encore le choix : RFC 3646
Dans une gouvernance saine de la configuration, une annonce n’est jamais confondue avec un ordre exécuté. RFC 3646 fournit au client DHCPv6 une liste préférentielle de résolveurs et une liste de recherche, mais laisse à la politique locale, au résolveur et à l’application les…
Histoire d'Internet
Un seul enregistrement DNS portait des clés qui ne partageaient pas la même confiance : RFC 3445
Le premier enregistrement `KEY` promettait un annuaire commun à plusieurs cryptographies. L’expérience montra une facture cachée: le DNS ne pouvait demander qu’un type entier, et la signature couvrait tout le RRset. Des clés administrées, validées et compromises de façons…
IETF
Le message s’est déchiffré. L’expéditeur restait à prouver : RFC 9750
Un audit d’acquisition peut valider une promesse de chiffrement tout en laissant intacte la question décisive: quelle preuve désigne réellement un client précis ? L’architecture MLS de la RFC 9750 oblige à séparer le secret partagé du groupe, la signature individuelle…
IETF
La signature était valide. L’autorisation restait à établir
Dans une console d’exploitation, un contrôle cryptographique vert ressemble facilement à une décision complète. Pourtant, RFC 3645 ne confond pas les rôles: GSS-TSIG peut établir un contexte de sécurité et authentifier un message DNS, mais le texte exclut expressément…
Histoire d'Internet
Le lien physique savait ce que le terminateur du tunnel ne voyait pas : RFC 3437
L2TP éloignait le contrôle PPP du support qu’il devait configurer. RFC 3437 ne rendit pas ce contrôle au concentrateur d’accès: il organisa un échange où le bord décrivait ses souhaits et ses limites, puis recevait les paquets qui attestaient la négociation réelle.
IETF
Le certificat connaissait l’usage de la clé, pas le compte à qui la confier : RFC 9734
Une nouvelle finalité X.509 peut empêcher une clé de messagerie de voyager comme un passe-partout TLS. Elle ne transforme pas pour autant cette clé en preuve complète du compte, du terminal, de l’autorisation et du résultat. RFC 9734 rend une affirmation plus précise…
IETF
Le port était visible, le service restait une hypothèse
Une étiquette de colis aide le transporteur sans décrire tout ce que contient le carton. Un numéro de port joue parfois ce rôle: il facilite le rendez-vous entre extrémités, mais l'équipement traversé ne reçoit pas pour autant une preuve de l'application, de l'utilisateur ou de…
Histoire d'Internet
Chaque flux sécurisé coûtait une connexion TLS : RFC 3436
SCTP réunissait plusieurs flux de messages et plusieurs chemins réseau dans une association. RFC 3436 choisit de ne pas fondre leur sécurité: chaque flux bidirectionnel protégé reçut sa propre connexion TLS, avec son propre état et ses propres contraintes.
Histoire d'Internet
L’entité notifiée recevait les commandes, sans résoudre la relève : RFC 3435
Un commutateur pouvait pointer vers un agent d’appel de secours sans savoir si celui-ci possédait l’état légitime et complet de l’appel. RFC 3435 organisait la destination des messages, mais ne transformait pas ce pointeur en arbitre de la relève.
IETF
Le compteur s’est tu au moment où la liaison se dégradait
Deux instruments peuvent être exacts et pourtant raconter des histoires différentes. L’un additionne chaque erreur depuis sa mise en service. L’autre range les secondes dans des états, puis cesse d’incrémenter certains compteurs lorsque la dégradation devient grave. RFC 3637 a…
IETF
L’étiquette de mesure a déplacé le flux qu’elle devait observer : RFC 9714
Une mesure peut compter parfaitement les mauvais paquets. RFC 9714 introduit un Flow-ID Label pour l’Alternate Marking dans MPLS, tout en avertissant que son insertion peut modifier le choix ECMP: le jumeau instrumenté risque alors de quitter le chemin du trafic qu’il devait…
Histoire d'Internet
Le zéro après un sondage échoué n’était pas une mesure : RFC 3434
Une courbe tombe à zéro et l’œil croit voir le réseau s’arrêter. RFC 3434 obligeait pourtant le système à conserver une autre possibilité: l’agent n’avait peut-être rien mesuré, et le zéro n’était que le contenu imposé d’un champ dont l’état disait « indisponible ».
Histoire d'Internet
Un nombre avait besoin d’une échelle, d’une précision et d’une heure : RFC 3433
Un entier remonté par un capteur de châssis avait l’apparence d’un fait. RFC 3433 montrait qu’il ne devenait une mesure lisible qu’avec son type, son échelle, sa précision, son état et l’histoire de sa mise à jour.