Sujet
Cycle de vie logiciel et dépendance fournisseur
Au sein de la facette Sujet, la veille thématique Cycle de vie logiciel et dépendance fournisseur rassemble des articles qui partagent un même sujet, un même signal ou un même thème de suivi. Cette page offre aux lecteurs un parcours plus riche à travers les reportages associés, les preuves issues de sources publiques, les acteurs du marché et les implications pour l’infrastructure, avec suffisamment de contexte pour comprendre pourquoi le sujet compte pour les mouvements d’entreprises, les décisions de gouvernance, l’exposition régionale et le risque opérationnel. Les lecteurs peuvent comparer les signaux récurrents, les organisations concernées, les preuves publiques, le contexte du marché, la continuité de service, les achats, la concurrence, la conformité et les questions de planification stratégique liées au sujet, au lieu de se contenter d’une liste succincte d’articles correspondants. Elle explique ce que couvre le sujet, quels acteurs ou politiques de l’infrastructure sont impliqués, quelles preuves étayent la couverture et pourquoi le sujet peut être important pour les opérateurs, les clients, les investisseurs et les lecteurs de politiques publiques.

Histoire d'Internet
La boîte avait disparu du répertoire, pas de toutes les sessions : RFC 2180
Un client avait reçu `OK` après la suppression de `FOO`. Un autre, déjà installé dans la boîte, pouvait encore lire et modifier son contenu. En 1997, RFC 2180 a traité cette divergence non comme une anomalie à masquer, mais comme le prix explicite d’une liberté d’implémentation…

Histoire d'Internet
RFC 2143 : un bus rapide ne donnait pas à chaque hôte le droit de répondre
Sur une liaison SCSI, la vitesse pouvait séduire un concepteur de grappes de stations de travail. Mais partager un câble ne suffisait pas à constituer un réseau de pairs. La proposition de 1997 devait franchir deux seuils distincts: recevoir une commande venue d’un autre hôte et…

Universitaires
Nancy Leveson : quand aucun composant ne tombe en panne
Un système peut respecter les spécifications de chacune de ses pièces et produire néanmoins une situation dangereuse. Nancy Leveson a déplacé l'enquête vers les décisions, les informations disponibles et les contraintes que l'ensemble devait maintenir.

IETF
Composite ML-KEM dans CMS : l’approbation IESG révèle une chaîne de dépendance encore ouverte
Le 18 septembre 2026, l’IESG a approuvé `draft-ietf-lamps-cms-composite-kem-03` comme Proposed Standard dans une Protocol Action. Cette étape est importante, mais elle ne clôt ni la production RFC ni la chaîne de dépendance technique: le document CMS se trouve dans la file du RFC…

Histoire d'Internet
Une connexion TCP s'éteint, sa mémoire demeure : l'hypothèse du RFC 2140
En 1997, une succession de petites connexions Web pouvait contraindre TCP à refaire sans cesse ses premières estimations. Joe Touch proposa de conserver certains résultats au niveau du couple de machines. Mais un temps de trajet observé n'est pas un état de session, et une…

IETF
ACTN entre paquets et optique : deux avis demandent qui répond de l’état du réseau
Un orchestrateur peut décrire toutes les étapes d’une modification et perdre pourtant la certitude de son résultat après un redémarrage. Deux évaluations de l’IETF, l’une consacrée à la sécurité et l’autre à l’exploitation, demandent au projet ACTN/POI de rendre cette incertitude…

Histoire d'Internet
Le serveur comprenait la commande, pas nécessairement son lecteur : RFC 2130
Un protocole peut recevoir exactement les octets attendus et produire malgré tout un texte mal identifié ou inutilisable pour la personne à qui il s'adresse. Le rapport de l'atelier IAB sur les jeux de caractères, publié sous le numéro RFC 2130, a séparé ces réussites au lieu de…

Histoire d'Internet
Mary Shaw et le protocole entre les boîtes
En 1994, Mary Shaw formulait un problème que les schémas d'architecture savent encore dissimuler: nous donnons des noms précis aux boîtes, mais nous laissons souvent les lignes sans grammaire. L'appel de procédure reste un mécanisme utile; il ne suffit pas à décrire un flux, un…

IETF
L’approbation de JPEG XS ne prouve pas une mise à niveau opérationnelle
L’IESG a approuvé la révision RTP adaptée à la troisième édition de JPEG XS. Cette décision ouvre la voie à la publication, mais elle ne remplace ni le numéro RFC, ni la mise à jour IANA, ni la négociation entre deux équipements, ni un essai de décodage en conditions réelles.

Histoire d'Internet
RFC 2127 : débrancher une interface ne prouvait pas la fin de l’appel
Pour raccrocher, le modèle de la RFC 2127 demandait de supprimer une relation dans `ifStack`. Ce geste très précis révèle toute l’architecture: l’accès physique, la signalisation, le canal porteur et l’interface supérieure formaient des états distincts, dont aucun ne suffisait à…

IETF
RFC 10040 abandonne le type LCAF 5, mais Experimental n’est pas un plan de migration
RFC 10040 attribue à LISP un nouvel encodage Geo-Location et déprécie l’ancien type Geo-Coordinates. Cette publication établit une nouvelle référence commune; elle ne prouve ni l’adoption du code, ni l’interopérabilité, ni l’achèvement d’une migration.

Histoire d'Internet
RFC 2169 : une route HTTP n’est pas une autorité sur la ressource
En 1997, RFC 2169 proposait une idée volontairement étroite: employer HTTP pour interroger un résolveur au sujet d’un URN. La convention rendait une question transportable; elle ne donnait ni propriété ni pouvoir sur la ressource à l’hôte qui répondait.

Dossier
RFC 9647 : une route Babel « sélectionnée » ne suffit pas à prouver le service
Une ligne de route Babel peut afficher `selected = true` alors que la chaîne de preuves reste incomplète entre le datastore YANG, la politique effectivement appliquée à l’interface, l’échange authentifié avec le voisin, l’installation dans le plan de transfert, la reprise après…

IETF
WebAuthn 2026–2028 : le passage critique entre réadhésion, engagement juridique et gouvernance durable
Le 11 septembre 2026 marque un changement de gouvernance pour le Web Authentication Working Group de W3C: un nouveau mandat entre en vigueur, une nouvelle phase de participation s’ouvre et les organisations concernées doivent renouveler leur engagement envers la charte et la…

Histoire d'Internet
Le FAS a rendu son verdict ; le commutateur devait encore l’exécuter
RFC 2124 centralisait la décision d’admission sans confondre cette décision avec l’état obtenu dans le commutateur. Son échange de messages racontait quatre histoires distinctes: autoriser, exécuter, réconcilier et compter.

Histoire d'Internet
RFC 2123 : le relevé de flux était le produit d’un jeu de règles
Le compteur NeTraMet ne conservait pas « le trafic ». Il répondait à une question choisie: quels protocoles examiner, quels attributs garder, dans quel sens lire une conversation et quelle finesse accepter quand la mémoire se raréfiait. RFC 2123 a rendu visible cette fabrication…

Histoire d'Internet
Le lien ouvrait une session, pas un objet : la frontière VEMMI de la RFC 2122
Un lien `vemmi` ressemblait à une adresse Web, mais il ne promettait aucun fichier à récupérer. La RFC 2122 se servait du navigateur comme d’un point d’aiguillage vers un client distinct, une connexion continue et un dialogue d’accès. Le clic désignait l’entrée; il ne prouvait ni…

Histoire d'Internet
Sophie Wilson et la preuve rapportée par le premier silicium ARM1
Le 26 avril 1985, les premiers ARM1 arrivent chez Acorn. La carte de second processeur les attend déjà, tout comme le système Tube et BBC BASIC. Leur démarrage immédiat n'est pas la preuve qu'un processeur RISC réussit naturellement du premier coup: c'est le reçu visible d'un…

Histoire d'Internet
La racine coordonnait les accords, elle ne gouvernait pas l’annuaire mondial : RFC 2120
À première vue, la racine de l’arbre X.500 semblait déjà résoudre le problème. En pratique, la norme laissait ses administrateurs face à une tâche qui croissait plus vite que l’arbre: chaque DSA de premier niveau devait conclure des accords bilatéraux avec tous les autres. RFC…

Histoire d'Internet
La remise à zéro était dans le paquet suivant : la reprise MPPC de la RFC 2118
La RFC 2118 a donné à Microsoft Point-to-Point Compression une mémoire continue et un signal de reprise remarquablement bref. Quand une perte rompait l’historique partagé, le récepteur demandait une remise à zéro; pourtant, c’était le paquet de données suivant, marqué `FLUSHED`…
