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 ligne était en attente, pas la vérité du service

IETF

La ligne était en attente, pas la vérité du service

La RFC 3573 traite un cas de l'ère du modem, mais sa frontière reste actuelle: signaler un état temporaire, décider quoi en faire et constater le résultat sont trois opérations distinctes. Le LAC peut dire que la ligne est en attente. Il ne peut pas certifier la politique du LNS…

3 oct. 2026
Le serveur s’est authentifié. Il a restauré la mauvaise génération de session.

IETF

Le serveur s’est authentifié. Il a restauré la mauvaise génération de session.

Le client a vérifié le HMAC du répondant et reconnu le bon pair TLS. Quelques millisecondes plus tard, il retrouvait pourtant une file déjà acquittée, un curseur ancien et un état que l’application avait remplacé. L’échange avait authentifié les deux côtés; il n’avait pas…

3 oct. 2026
Une réponse DNS expire. La décision qu’elle transporte, parfois non

IETF

Une réponse DNS expire. La décision qu’elle transporte, parfois non

Réduire le TTL devait rendre la réorientation plus réactive. Cela a aussi donné une durée de vie à une décision prise pour l’adresse d’un résolveur, puis réutilisée par tous ses clients. RFC 3568 révèle ainsi un problème de contrôle: le cache conserve le choix, mais rarement les…

3 oct. 2026
« maxinterleave=5 » ne réserve pas cinq cases de mémoire

IETF

« maxinterleave=5 » ne réserve pas cinq cases de mémoire

Une session peut annoncer qu’elle accepte un entrelacement de cinq. Cette valeur borne ce que l’émetteur est autorisé à envoyer; elle ne montre ni la mémoire réellement réservée, ni le moment où le groupe a été reconstitué, ni la parole finalement livrée. RFC 3558 rend la limite…

3 oct. 2026
Le CRC était valide. Il ne pouvait rien dire des paires restées dans le paquet perdu.

IETF

Le CRC était valide. Il ne pouvait rien dire des paires restées dans le paquet perdu.

Le moteur reçoit trois paires de trames intactes, vérifie leurs CRC, puis voit un saut d’horodatage. La paire absente n’a pas échoué à son contrôle: elle n’est jamais arrivée pour être contrôlée. RFC 3557 oblige à séparer l’intégrité des unités reçues de la complétude de la…

3 oct. 2026
Un pair peut être authentique sans posséder toutes les adresses qu’il revendique

IETF

Un pair peut être authentique sans posséder toutes les adresses qu’il revendique

Une association SCTP se présente comme une seule relation, mais elle peut offrir plusieurs chemins. Dès que cette pluralité entre dans IKE, chaque adresse devient une affirmation distincte. Publié avec le statut Proposed Standard, RFC 3554 pose la question que les tableaux de…

3 oct. 2026
L’accusé est revenu. Le terminal n’avait pas encore reçu la rupture.

IETF

L’accusé est revenu. Le terminal n’avait pas encore reçu la rupture.

Deux horloges démarrent lorsqu’une mobilité est révoquée. La première s’arrête quand l’agent distant authentifie la révocation et renvoie son accusé. La seconde ne s’arrête que lorsque le terminal quitte effectivement l’ancien chemin. RFC 3543 organise la première avec précision…

3 oct. 2026
Le pair a cessé de répondre. La première requête, elle, n’était pas morte.

IETF

Le pair a cessé de répondre. La première requête, elle, n’était pas morte.

Le chien de garde n’a pas reçu sa réponse et le client AAA a basculé. Il a recopié sa file d’attente vers un autre agent. Ce geste rétablit un chemin, mais il n’efface pas les paquets déjà partis ni une décision qui pourrait être en train de revenir. La continuité crée alors une…

3 oct. 2026
Le délégué parlait au nom d’une institution. Le groupe de travail devait encore décider : RFC 3356

Histoire d'Internet

Le délégué parlait au nom d’une institution. Le groupe de travail devait encore décider : RFC 3356

RFC 3356 a organisé une coopération délicate: faire circuler une position institutionnelle authentique sans transférer à son porteur le pouvoir de décision de l’institution destinataire.

3 oct. 2026
Le tunnel masquait le support. Le support fixait encore l’enveloppe : RFC 3355

Histoire d'Internet

Le tunnel masquait le support. Le support fixait encore l’enveloppe : RFC 3355

Une abstraction réussie dispense les sessions PPP de connaître les cellules ATM. Elle ne rend pas le circuit virtuel infini ni immortel. RFC 3355 a précisément documenté l’endroit où le support caché continuait de gouverner le tunnel L2TP.

3 oct. 2026
Changer de clé ne supprimait pas le risque du texte connu : RFC 2405

Histoire d'Internet

Changer de clé ne supprimait pas le risque du texte connu : RFC 2405

En 1998, la RFC 2405 ne proposait pas de durée de clé universelle: elle reliait la décision à la valeur des données et aux moyens de l’attaquant. Son argument sur le texte prévisible des datagrammes montre pourquoi un calendrier de renouvellement ne rendait pas, à lui seul, DES…

3 oct. 2026
CLDAP n’a pas comblé ses lacunes de sécurité : la RFC 3352

Histoire d'Internet

CLDAP n’a pas comblé ses lacunes de sécurité : la RFC 3352

En 1995, CLDAP promettait une réponse d’annuaire plus courte en supprimant l’établissement d’une connexion. En 2003, la RFC 3352 a consigné pourquoi ce raccourci n’avait pas acquis une base suffisante pour rester sur la voie des normes — sans prétendre que tout code local avait…

3 oct. 2026
Le gatekeeper répondait. Il ne possédait pas forcément l’alias.

IETF

Le gatekeeper répondait. Il ne possédait pas forcément l’alias.

Le `hostport` conduisait à un élément H.323 joignable. Le rapport lui a attribué l’identité inscrite dans la partie utilisateur. RFC 3508 permet de diriger un appel vers une fonction; il ne certifie pas que cette fonction détient l’alias.

2 oct. 2026
Le registre du contrôleur n’est pas une preuve d’isolement

IETF

Le registre du contrôleur n’est pas une preuve d’isolement

Un conseil de gouvernance peut approuver une réservation parfaitement cohérente et néanmoins ignorer ce qui se passe lorsque les paquets arrivent sur une ressource partagée. Entre l’admission et l’exécution, la preuve change de nature.

2 oct. 2026
Le service a répondu 204. Il n’a pas certifié le contenu.

IETF

Le service a répondu 204. Il n’a pas certifié le contenu.

Le code signifiait que le service ICAP ne renvoyait aucune adaptation dans le cadre convenu. Le tableau de bord l’a traduit par « propre ». RFC 3507 sépare ces deux affirmations.

2 oct. 2026
Le courtier a contresigné l’original, pas les données qu’il avait normalisées

IETF

Le courtier a contresigné l’original, pas les données qu’il avait normalisées

Une contresignature COSE peut rattacher un intermédiaire au même objet YANG sans prouver que sa conversion, son agrégation ou sa sortie ont été fidèlement enregistrées.

2 oct. 2026
Le schéma distant a changé le message après son arrivée

IETF

Le schéma distant a changé le message après son arrivée

Les octets étaient restés identiques, mais le processeur XML a consulté une ressource extérieure qui avait changé. RFC 3470 oblige à distinguer le message reçu de l’infoset effectivement remis à l’application.

2 oct. 2026
Le serveur a livré les données avant d’authentifier le client

IETF

Le serveur a livré les données avant d’authentifier le client

Dans TLS avec PAKE, la progression de la poignée de main ne suffit pas: l’authentification du client n’est acquise qu’après vérification de son message Finished.

2 oct. 2026
Les ACK ont attendu derrière l’upload, puis sont arrivés tous ensemble

IETF

Les ACK ont attendu derrière l’upload, puis sont arrivés tous ensemble

Le récepteur avait espacé ses accusés de réception. La file montante les a retenus derrière de gros paquets, puis les a relâchés en grappe. RFC 3449 montre comment un goulot de retour peut réécrire l’horloge que voit l’émetteur.

2 oct. 2026
Le navigateur a consulté l’explication avant le clic de l’utilisateur

IETF

Le navigateur a consulté l’explication avant le clic de l’utilisateur

Un lien censé rendre le filtrage DNS compréhensible peut révéler l’adresse du lecteur et le domaine sensible avant toute décision, si l’application le précharge en arrière-plan.

2 oct. 2026