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.

Chez Mozilla, l’accord d’un responsable de module n’est ni un accès de commit ni une promesse de livraison de Firefox

Dossier

Chez Mozilla, l’accord d’un responsable de module n’est ni un accès de commit ni une promesse de livraison de Firefox

Les règles publiques de Mozilla séparent des actes que le langage courant rassemble volontiers. Un responsable de module ou l’un de ses pairs peut accepter une modification dans le périmètre du module; une personne peut obtenir séparément une autorisation d’écrire dans un dépôt…

6 sept. 2026
Le modèle derrière la pile d’étiquettes : la RFC 9902 et le contrat opérationnel du routage segmenté IS-IS

IETF

Le modèle derrière la pile d’étiquettes : la RFC 9902 et le contrat opérationnel du routage segmenté IS-IS

Un seul leaf d’activation peut commencer à annoncer les extensions IS-IS de routage segmenté, mais une activation sûre dépend des ressources d’étiquettes SR, indépendantes du protocole, déjà configurées en dessous. La RFC 9902 rend cette jonction explicite: le commutateur…

6 sept. 2026
Les bits que TCP a gardés pour l’avenir

Histoire d'Internet

Les bits que TCP a gardés pour l’avenir

En 1981, TCP a laissé six positions de son en-tête sans fonction immédiate. Leur valeur historique tient à la règle qui accompagnait ce vide: les émettre à zéro, ne pas leur attribuer de sens privé et réserver leur évolution à une future norme. En 2001, deux de ces positions sont…

6 sept. 2026
Le bit qui a donné un sens au numéro d’accusé de réception TCP

Histoire d'Internet

Le bit qui a donné un sens au numéro d’accusé de réception TCP

Un champ de 32 bits peut être présent dans chaque segment TCP sans toujours constituer une information valide. Le bit ACK indique quand ce numéro devient la frontière cumulative de séquence attendue.

6 sept. 2026
Les procès-verbaux « perdus » de l’IETF étaient là. L’archive a besoin d’un manifeste d’intégrité

IETF

Les procès-verbaux « perdus » de l’IETF étaient là. L’archive a besoin d’un manifeste d’intégrité

Un lien muet peut faire passer un document conservé pour un document disparu. C’est ce qui s’est produit avec deux séances de l’IETF 84: les fichiers existaient dans une copie des actes, mais les anciennes pages ne savaient plus les atteindre. La correction apportée au serveur…

6 sept. 2026
Le nombre qui indiquait à TCP où commençaient les données : Data Offset

Histoire d'Internet

Le nombre qui indiquait à TCP où commençaient les données : Data Offset

Le champ Data Offset donne la limite fiable entre l’en-tête TCP — options et remplissage compris — et le premier octet de données applicatives.

6 sept. 2026
L’en-tête qui n’a jamais été envoyé : pourquoi TCP somme des adresses IP

Histoire d'Internet

L’en-tête qui n’a jamais été envoyé : pourquoi TCP somme des adresses IP

TCP ne transporte pas un en-tête supplémentaire pour protéger ses adresses d’extrémité. Il reconstruit plutôt, aux deux bouts, quelques informations fournies par IP avant de vérifier sa somme de contrôle.

6 sept. 2026
Ces deux fanions qui occupent une position : pourquoi TCP compte SYN et FIN

Histoire d'Internet

Ces deux fanions qui occupent une position : pourquoi TCP compte SYN et FIN

TCP numérote les octets, mais réserve aussi une position logique à deux événements de contrôle. SYN ouvre l’espace de séquence avant les données et FIN le termine après le dernier octet: tous deux bénéficient ainsi des mêmes mécanismes d’accusé de réception et de retransmission…

5 sept. 2026
Le PUSH qui n’a jamais été une frontière de message : le drapeau PSH de TCP

Histoire d'Internet

Le PUSH qui n’a jamais été une frontière de message : le drapeau PSH de TCP

Une demande de progression dans un flux d’octets n’est pas une enveloppe de message.

5 sept. 2026
La connexion oubliée par une extrémité : la réinitialisation d’une connexion TCP semi-ouverte

Histoire d'Internet

La connexion oubliée par une extrémité : la réinitialisation d’une connexion TCP semi-ouverte

Quand une extrémité redémarre, elle peut oublier une connexion que l’autre croit encore établie. Le prochain échange révèle alors que leurs états de connexion ne coïncident plus: le segment RST met fin à l’état obsolète et laisse place à une nouvelle négociation.

5 sept. 2026
Qui décide du correctif ? Le pouvoir réel d’ISC sur BIND et Kea

Tendances institutionnelles mondiales

Qui décide du correctif ? Le pouvoir réel d’ISC sur BIND et Kea

Le pouvoir d’Internet Systems Consortium ne ressemble pas à celui d’un régulateur. Pour les versions prises en charge de BIND et Kea, il s’exerce surtout dans une séquence technique: coordonner l’information sur une vulnérabilité, organiser la production d’un correctif, publier…

5 sept. 2026
Quand les deux côtés ont frappé à la porte : l’ouverture simultanée de TCP

Histoire d'Internet

Quand les deux côtés ont frappé à la porte : l’ouverture simultanée de TCP

*Le handshake TCP n’impose pas toujours un client et un serveur: deux hôtes peuvent commencer ensemble et synchroniser une seule connexion.*

5 sept. 2026
L’hôte qui devait attendre avant de parler : le temps de silence de TCP après un redémarrage

Histoire d'Internet

L’hôte qui devait attendre avant de parler : le temps de silence de TCP après un redémarrage

Après un redémarrage, un hôte peut sembler propre parce qu’il a oublié une partie de son passé. Le temps de silence de TCP transforme cette perte de mémoire en délai contrôlé: les anciens segments doivent disparaître avant que de nouveaux numéros de séquence réutilisent le même…

5 sept. 2026
Le reset qui a mis fin trop tôt à l’attente : le risque d’assassinat de TIME-WAIT

Histoire d'Internet

Le reset qui a mis fin trop tôt à l’attente : le risque d’assassinat de TIME-WAIT

Un état TCP conservé après la fermeture peut sembler encombrant. RFC 1337 a montré qu’un paquet ancien pouvait provoquer une chaîne de réponses — ACK, puis RST — capable de supprimer prématurément la protection contre les doublons retardés.

5 sept. 2026
La deadline qui n’était pas un minuteur de retransmission : le USER TIMEOUT TCP

Histoire d'Internet

La deadline qui n’était pas un minuteur de retransmission : le USER TIMEOUT TCP

Une retransmission tente encore la livraison; le USER TIMEOUT décide quand cette attente doit prendre fin.

5 sept. 2026
L’offre qui n’était pas une négociation : comment le MSS TCP bornait chaque direction

Histoire d'Internet

L’offre qui n’était pas une négociation : comment le MSS TCP bornait chaque direction

Chaque SYN peut contenir une limite de réception propre à l’émetteur. Ces deux limites peuvent différer: le MSS ne fixe ni une taille commune de paquet ni la MTU du chemin.

5 sept. 2026
Le handshake qui devait se souvenir du précédent : comment le RFC 5746 a lié la renégociation TLS

Histoire d'Internet

Le handshake qui devait se souvenir du précédent : comment le RFC 5746 a lié la renégociation TLS

La renégociation TLS pouvait authentifier un nouveau handshake sans prouver quelle histoire de connexion l’avait précédé. Le RFC 5746 a transformé cette continuité en état cryptographiquement vérifiable.

5 sept. 2026
Le voisin resté dans le cache après être devenu inaccessible : comment la RFC 7048 a séparé basculement et oubli

Histoire d'Internet

Le voisin resté dans le cache après être devenu inaccessible : comment la RFC 7048 a séparé basculement et oubli

La troisième sollicitation sans réponse ne détruit plus forcément la dernière indication utile: IPv6 peut écarter un voisin du choix de route tout en conservant son adresse de couche liaison pour une nouvelle recherche.

5 sept. 2026
L’adresse qui parlait avant d’être déclarée unique : les limites du DAD optimiste

Histoire d'Internet

L’adresse qui parlait avant d’être déclarée unique : les limites du DAD optimiste

Une adresse IPv6 nouvellement configurée pouvait commencer à transporter du trafic avant la fin de la vérification d’unicité, mais elle ne pouvait pas encore agir comme un voisin pleinement établi.

5 sept. 2026
Le milieu vulnérable d’une migration TACACS+ sécurisée : RFC 9887 et le coût d’une double voie d’authentification

IETF

Le milieu vulnérable d’une migration TACACS+ sécurisée : RFC 9887 et le coût d’une double voie d’authentification

Un client TACACS+ utilisant TLS ne doit pas revenir au non-TLS lorsque la négociation TLS échoue. Pourtant, une migration peut conserver temporairement des serveurs TACACS+ non-TLS distincts pour les équipements qui ne peuvent pas changer en même temps. Cette coexistence n’est…

5 sept. 2026