Aller au contenu principal

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.

La sonde qui ne pouvait pas déclarer la mort d’un pair inactif : les keep-alives TCP

Histoire d'Internet

La sonde qui ne pouvait pas déclarer la mort d’un pair inactif : les keep-alives TCP

Une connexion TCP inactive peut rester silencieuse sans être rompue. Le keep-alive cherche à obtenir un indice sur l’état du transport, sans transformer une seule absence de réponse en conclusion définitive.

4 sept. 2026

IETF

Un échange SSH hybride transforme la négociation en frontière de migration

Installer du code postquantique ne prouve pas qu'une session SSH l'a utilisé. La RFC 10042 définit trois méthodes hybrides associant ML-KEM à un échange elliptique éprouvé. La protection n'existe que si les deux pairs proposent la même méthode, si la négociation la retient, si…

4 sept. 2026
La fenêtre qui refusait de s’ouvrir octet par octet : comment TCP évite le Silly Window Syndrome

Histoire d'Internet

La fenêtre qui refusait de s’ouvrir octet par octet : comment TCP évite le Silly Window Syndrome

Dans TCP, disposer de quelques octets libres ne signifie pas qu’il faille les annoncer aussitôt. Cette retenue empêche une petite ouverture de fenêtre de dicter durablement la taille des segments.

4 sept. 2026
La fenêtre qui s’est refermée sans mettre fin à la connexion : le mode persist de TCP

Histoire d'Internet

La fenêtre qui s’est refermée sans mettre fin à la connexion : le mode persist de TCP

Une fenêtre de réception à zéro ordonne à l’émetteur de s’arrêter. Elle ne lui dit pourtant ni que la connexion est morte, ni comment il apprendra que le récepteur dispose de nouveau de place.

4 sept. 2026
Le nombre devenu plus difficile à prévoir hors chemin : les numéros de séquence initiaux de TCP

Histoire d'Internet

Le nombre devenu plus difficile à prévoir hors chemin : les numéros de séquence initiaux de TCP

Une connexion TCP commence par l’échange de nombres. Le changement décisif n’a pas consisté à cacher cet échange, mais à empêcher qu’un nombre observé permette de prévoir le point de départ de la connexion suivante.

3 sept. 2026
Une signature logicielle valide n’est pas une preuve durable d’autorité

Tendances institutionnelles mondiales

Une signature logicielle valide n’est pas une preuve durable d’autorité

Un résultat de vérification positif peut survivre au mandat qui rendait une publication légitime. La cryptographie reste correcte; la question manquante est de savoir qui pouvait publier, à quel moment et sous quelle règle.

3 sept. 2026
La chaîne qui rendit une clé publique crédible : la gestion des certificats PEM

Histoire d'Internet

La chaîne qui rendit une clé publique crédible : la gestion des certificats PEM

Une clé publique ne porte pas, à elle seule, la preuve de l'identité de son détenteur. Pour Privacy Enhanced Mail, la RFC 1422 organisa cette preuve autour de certificats, d'autorités de certification, de chemins de validation et d'informations de révocation.

3 sept. 2026
Le pointeur qui n’a jamais été hors bande : les données urgentes TCP

Histoire d'Internet

Le pointeur qui n’a jamais été hors bande : les données urgentes TCP

Les données urgentes TCP forment une petite surface de contrôle à longue histoire. Le bit URG donne un sens à un pointeur urgent de 16 bits, mais la RFC 793 décrivait la limite marquée de deux façons contradictoires. Cette ambiguïté est passée de la spécification aux…

3 sept. 2026
Retirer un certificat racine, c’est migrer tout un parc avant de mettre à jour un navigateur

Tendances mondiales des services cloud

Retirer un certificat racine, c’est migrer tout un parc avant de mettre à jour un navigateur

Un programme de certificats racines peut retirer sa confiance dans une version tandis que de nombreuses applications continuent de décider à partir de magasins anciens, privés ou embarqués. Le changement de sécurité n’est achevé que lorsque les vérificateurs concernés prouvent le…

3 sept. 2026
Le bitmap dit qu’une option UDP est apparue, pas ce qu’elle a fait : RFC 9870

IETF

Le bitmap dit qu’une option UDP est apparue, pas ce qu’elle a fait : RFC 9870

Le RFC 9870 donne aux exportateurs IPFIX un moyen compact d’indiquer quels types d’options UDP ont été observés dans un flux. Sa valeur tient à la modestie de cette affirmation: il conserve une présence observée, pas l’historique des paquets, la décision du destinataire ni le…

3 sept. 2026
Pour Python, un PEP accepté n’est ni un engagement de publication ni un reçu d’implémentation

Dossier

Pour Python, un PEP accepté n’est ni un engagement de publication ni un reçu d’implémentation

Dans le processus Python, une proposition, sa décision, son implémentation de référence et sa livraison ne sont pas une seule opération. Les relier est nécessaire; les confondre produit une promesse que les règles publiées ne font pas.

3 sept. 2026
Six octets ne devenaient une adresse qu’après identification du domaine : RFC 1449

Histoire d'Internet

Six octets ne devenaient une adresse qu’après identification du domaine : RFC 1449

Une suite d’octets ne porte pas son mode d’emploi en elle-même. Dans l’architecture de RFC 1449, six octets pouvaient décrire une adresse IPv4 et un port UDP, mais seulement parce qu’un identifiant distinct annonçait le domaine de transport. Effacer cet identifiant ne rendait pas…

3 sept. 2026
La base indiquait une adresse. La réponse reprit le chemin du paquet : RFC 1445

Histoire d'Internet

La base indiquait une adresse. La réponse reprit le chemin du paquet : RFC 1445

Deux coordonnées prétendaient désigner le même gestionnaire. L’une vivait dans la base locale des parties; l’autre venait d’être observée sur la requête reçue. Pour une nouvelle émission, la RFC 1445 consultait la première. Pour répondre, elle imposait la seconde, même en cas de…

3 sept. 2026
Chez Apache, un vote de publication n'est ni un veto sur le code ni une décision technique du Board

Dossier

Chez Apache, un vote de publication n'est ni un veto sur le code ni une décision technique du Board

À l'Apache Software Foundation, un committer peut modifier le dépôt, un votant qualifié peut arrêter une modification de code, un PMC peut publier un paquet officiel et le Board peut exercer une surveillance corporative. Ces actes appartiennent à la même fondation, mais…

3 sept. 2026
L'expérience du tableau RIPE : que faire après la rencontre ?

Récits

L'expérience du tableau RIPE : que faire après la rencontre ?

Un tableau de conférence a aidé chercheurs et opérateurs à se trouver. Le bilan publié par RIPE NCC invite surtout à organiser la suite: une question partagée, un échange de données consenti et des engagements qui restent à la mesure des moyens de chacun.

3 sept. 2026
L’horloge a reculé. Il fallait changer la clé : RFC 1446

Histoire d'Internet

L’horloge a reculé. Il fallait changer la clé : RFC 1446

Une frontière temporelle peut être aussi décisive qu’un secret. Dans RFC 1446, un message SNMPv2 muni du bon condensat ne devenait pas pour autant recevable: il devait encore appartenir au présent reconnu par le destinataire. Si l’on reculait ce présent tout en conservant la même…

3 sept. 2026
La clé avait changé avant l’arrivée de la réponse. Le gestionnaire devait garder les deux : RFC 1446

Histoire d'Internet

La clé avait changé avant l’arrivée de la réponse. Le gestionnaire devait garder les deux : RFC 1446

L’agent avait déjà inscrit le nouveau secret. Sa réponse fut donc construite avec cette valeur. Le gestionnaire, qui attendait justement la réponse avant de modifier sa propre base, croyait encore à l’ancienne. La RFC 1446 décrivait ainsi une transition où le bon accusé de…

3 sept. 2026

Dossier

Le nom est resté. Pas le module : ce que corrige le RFC 9890

Le RFC 9890 met fin à une ambiguïté du registre YANG: le nom et l’espace de noms désignent une lignée durable, non le contenu exact d’une révision ni le schéma réellement chargé par un serveur.

3 sept. 2026
Le module a gardé son nom. L’équipement n’a pas prouvé sa version : RFC 1442

Histoire d'Internet

Le module a gardé son nom. L’équipement n’a pas prouvé sa version : RFC 1442

Une MIB impeccablement datée peut renseigner l’histoire d’un texte sans rien certifier sur le logiciel qui répond au bout du réseau. Avec RFC 1442, les modules d’information de SNMP ont acquis une identité durable et un registre de révisions. Mais la norme a placé…

3 sept. 2026
La même application a franchi deux versions. Le proxy a changé l’opération : RFC 1452

Histoire d'Internet

La même application a franchi deux versions. Le proxy a changé l’opération : RFC 1452

L’application demandait une lecture groupée. L’ancien agent n’en vit jamais la forme. Un gestionnaire bilingue choisit SNMPv1 dans une base locale, mit à zéro les deux paramètres de répétition et transforma la requête en un seul pas suivant. La RFC 1452 appelait cela de la…

3 sept. 2026