Horizon temporel
Pluriannuel
Dans la facette Horizon temporel, les analyses à horizon temporel Pluriannuel sont organisées selon la période pendant laquelle un signal devrait rester pertinent. La page aide à distinguer les changements opérationnels immédiats des évolutions à plus long cycle — gouvernance, investissements, normes et infrastructures — qui peuvent s’étendre sur plusieurs trimestres ou années. Elle relie les hypothèses de calendrier aux preuves publiques, aux acteurs concernés, au contexte de marché, à l’exposition des clients, à la pression réglementaire et à la planification des infrastructures, afin que le lecteur puisse déterminer si un développement est urgent, stratégique ou encore en attente d’éléments de confirmation. Elle explique aussi comment l’horizon temporel modifie le sens d’un signal, quelles organisations peuvent être exposées et quelles décisions d’infrastructure appellent une action à court terme ou un suivi à long terme.
Histoire d'Internet
Le hachage qui resta quand les clés changèrent : comment SSH lia l’authentification à une session
Une connexion SSH peut renouveler les clés qui protègent ses paquets sans fermer le terminal ni recréer chaque canal. Pour que cette continuité ne soit pas une simple supposition, le protocole conserva une trace de son premier échange: un hachage que les renouvellements suivants…
Histoire d'Internet
Le nombre qui grandissait à chaque cache : comment HTTP Age mesurait une réponse, pas l’objet
Un document ancien de plusieurs années peut parvenir avec `Age: 120`. Ces deux minutes ne datent ni le texte ni la ressource: elles expriment l’estimation qu’un cache transmet sur une réponse produite ou validée par l’origine. HTTP a ainsi rendu le temps cumulable sans créer de…
Histoire d'Internet
Le bit qui fermait le message : comment ONC RPC redonna des limites au flux TCP
Un appel distant peut être découpé entre dix segments TCP, tandis qu’une seule lecture peut contenir plusieurs appels. La fiabilité conserve l’ordre, pas la ponctuation. ONC RPC ajouta donc une règle minuscule: une longueur pour chaque fragment et un bit qui ne fermait le record…
Histoire d'Internet
Le message arrivé en plusieurs messages : comment MIME a confié le réassemblage au destinataire
Dans le courrier électronique des années 1990, un même objet pouvait rencontrer plusieurs plafonds de taille sans qu’aucun relais ne voie l’ensemble du trajet. MIME n’a pas transformé le réseau en assembleur central: il a fait voyager des messages autonomes, puis donné au…
Tendances mondiales des services cloud
Le RPO de Box progresse de 15 %, mais l'usage élargi des contenus peut peser sur les marges
Le carnet contractuel de Box s'épaissit sans dégradation visible de la marge brute. Le risque se situe plus loin dans la chaîne: un droit d'usage vendu aujourd'hui ne dit pas combien de fichiers, d'appels API ou de traitements d'IA le client consommera demain, ni à quel coût pour…
Histoire d'Internet
La condition qui transformait une plage en totalité : comment HTTP If-Range a gardé les fragments dans une même version
Après une coupure, le client possédait déjà le début d’une représentation. Demander la suite semblait n’être qu’une affaire de position. Mais si la ressource avait changé entre-temps, la même position ouvrait une autre suite d’octets. HTTP a résolu ce doute en donnant à une seule…
Histoire d'Internet
La trace qui grandissait à rebours : comment Path empêchait un relais Usenet de renvoyer l’article
Dans un réseau de diffusion par inondation, reconnaître un doublon ne suffisait pas: les octets avaient déjà fait l’aller-retour. Usenet inscrivit donc dans chaque article une trace modifiable, construite par les relais eux-mêmes, afin d’éviter le renvoi inutile sans transformer…
IETF
Ari Keränen et la paire de candidats qui a gagné avant que le succès soit établi
Dans une chronologie ICE, la paire sélectionnée peut être parfaitement identifiable alors que l'application ne sait toujours pas expliquer l'absence de son, l'échec d'une admission ou la fin de l'autorisation d'émettre. Le protocole a rendu une décision de chemin, pas un verdict…
Histoire d'Internet
Le lien qui ne quittait jamais le message : comment Content-ID reliait les parties MIME
Une page HTML reçue par courrier pouvait afficher une image désignée comme par une URL, sans qu'aucune requête ne sorte vers le Web. L'adresse commençait par `cid:` et conduisait à une autre partie du même message. Cette apparente simplicité reposait sur une distinction exigeante…
Histoire d'Internet
Un Call-ID, plusieurs dialogues : comment les tags SIP ont nommé une bifurcation
Une invitation adressée à une seule identité pouvait faire sonner plusieurs terminaux et produire plusieurs réponses. SIP n'a pas transformé le Call-ID en numéro d'appel universel: chaque pair a fourni un tag afin de nommer séparément le contexte qui survivrait à l'invitation.
Tendances centres de données mondiales
NVIDIA détient 2,8 Md$ d’avances clients. Son RPO n’a pas le même périmètre
Un encaissement peut précéder la livraison, une obligation contractuelle peut précéder la facture et un chiffre d’affaires peut être comptabilisé avant la clôture qui suit le paiement. Les nouveaux chiffres de NVIDIA décrivent ces étapes, mais ne les fusionnent pas.
IETF
Erik Nordmark et le voisin devenu périmé avant d’être inaccessible
Dans le cache voisin d’IPv6, `STALE` ne décrit pas un équipement défaillant: il signale qu’une preuve positive a vieilli. Cette nuance permet de continuer à acheminer des paquets tout en exigeant une nouvelle confirmation, sans transformer une adresse mémorisée en certitude…
Histoire d'Internet
La connexion s'est éteinte, pas la séance : comment RTSP a détaché l'état de TCP
Le câble logique qui transportait PLAY pouvait céder sans que le serveur oublie le film, les flux déjà préparés ni leur état. RTSP a rendu cette continuité possible grâce à un contexte temporaire nommé séparément de la connexion, sans jamais promettre que ce nom suffisait à…
Histoire d'Internet
Le bit qui interdisait de faire semblant : les extensions critiques X.509 face au changement
Une autorité pouvait signer une règle qu'un ancien logiciel n'avait jamais apprise. X.509 v3 n'a pas résolu ce décalage en déclarant tout nouveau champ obligatoire. Il a placé, à côté de la valeur, un choix plus précis: l'ignorance est-elle tolérable, ou doit-elle arrêter la…
Tendances services cloud Amérique du Nord
Chez DigitalOcean, les 25 premiers clients pèsent 20 % du chiffre d’affaires, mais l’ARR IA englobe tout le compte
La croissance de DigitalOcean se concentre désormais dans deux périmètres qui se recoupent peut-être sans être équivalents: les très grands clients et les comptes qui utilisent au moins un produit d’IA. Les publications financières ne permettent pas encore de passer de ces…
IETF
Carsten Bormann et le Token qui reliait une réponse, pas une personne
Dans une trace CoAP, deux nombres peuvent sembler raconter la même histoire. L’un suit pourtant la mécanique d’un message, l’autre la continuité d’une requête. Les confondre transforme un outil de corrélation en certificat imaginaire.
Histoire d'Internet
Le numéro qui a dit adieu pour que le flux continue : comment RTP résolvait les collisions SSRC
Le récepteur avait déjà associé un numéro de 32 bits à une suite, une horloge et des rapports. Puis le même numéro est arrivé d'un autre chemin. RTP ne pouvait pas transformer cette coïncidence en identité certaine: il fallait conserver l'ambiguïté, retirer le libellé en conflit…
Histoire d'Internet
Un XID, deux exécutions : pourquoi RPC avait besoin d’une mémoire au-delà du numéro de réponse
Le même identifiant peut revenir avec la même demande sans que le serveur sache encore s’il s’agit d’un travail déjà accompli. RPC a su rattacher une réponse à un appel; NFS a montré combien coûte la preuve qu’un effet ne s’est produit qu’une fois.
IETF
Fernando Gont et le fragment qui devait annoncer la suite
Un pare-feu voit l’adresse IPv6, lit un décalage égal à zéro et sait qu’il tient le premier morceau. Pourtant, le port TCP sur lequel repose sa règle peut se trouver dans le morceau suivant. La RFC 7112, coécrite par Fernando Gont, a supprimé cette devinette en imposant au…
Tendances mondiales des services cloud
Le CRM Salesforce de Veeva est plafonné à 150 % par client avant sa sortie en 2030
L'ancien CRM ne s'arrête pas d'un coup: il se resserre. Le contrat avec Salesforce autorise encore Veeva à servir sa base historique, mais ferme l'entrée aux nouveaux clients, limite l'extension de chaque compte et impose deux échéances distinctes pour le support puis la vente.