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.

Entreprises télécoms nationaux Europe et Moyen-Orient
La filiale britannique de Cambium entre en administration judiciaire
La filiale britannique de Cambium est entrée en administration judiciaire quelques jours après la suppression de 260 emplois, laissant les clients attendre la suite du support produit et des garanties.

Tendances institutionnelles mondiales
Faille GitLab exploitée: le délai de correction est dépassé
Les opérateurs d’instances GitLab autogérées doivent appliquer un correctif urgent pouvant interrompre les systèmes à nœud unique pendant les migrations de base de données.

Tendances institutionnelles mondiales
Le délai de correction de la faille MikroTik RouterOS est dépassé
Le délai fixé par la CISA pour CVE-2026-86060 est passé, mais les routeurs corrigés peuvent encore nécessiter des vérifications afin de repérer les modifications effectuées avant la mise à jour.

Histoire d'Internet
Rob Pike et le walk 9P qui n’ouvrait rien
Dans 9P, une suite de noms peut être entièrement parcourue et recevoir tous ses qid sans qu’aucun fichier soit ouvert. Cette séparation, au cœur du travail de Rob Pike sur les espaces de noms, offre une discipline précieuse aux systèmes modernes: un reçu de protocole ne devient…

Dossier
Le décompte SHA-1 de RFC 9919 n’est pas une preuve de retrait
Le journal d’un répondeur OCSP peut montrer que les requêtes SHA-1 se raréfient. Pour mettre fin à la compatibilité sans confondre silence et migration, l’opérateur doit encore établir qui pouvait être vu, par quel chemin et pendant combien de cycles.

Dossier
L’étiquette de l’algorithme a changé, pas la clé : la frontière probante de la RFC 9709
Réécrire le nom d’un algorithme peut suffire à détourner un déchiffreur, sans casser le chiffrement annoncé. La RFC 9709 répond en faisant de l’identité encodée de l’algorithme une entrée de la clé dérivée — et oblige l’exploitation à ne plus confondre traitement réussi et…

Histoire d'Internet
L’étiquette disait JPEG, les autres identifiants disaient GIF : RFC 2158
Dans une même entrée de la RFC 2158, l’intitulé, le nom de partie de corps X.400 et la branche d’identifiant d’objet désignent GIF. Seul le champ MIME indique `image/jpeg`. Cette fissure minuscule rappelle qu’un libellé publié est une pièce du dossier, pas la preuve suffisante du…

Histoire d'Internet
Les octets changeaient, pas le caractère visé : la frontière du RFC 2070
Un navigateur de 1997 pouvait recevoir deux fichiers HTML dont les octets ne se ressemblaient pas, puis rencontrer dans chacun le même caractère abstrait. Le RFC 2070 expliquait pourquoi: l’encodage externe appartenait à la ressource concrète et au décodeur, tandis que le jeu de…

Histoire d'Internet
Un trajet était une conversion. Le retour devait encore prouver l’équivalence : RFC 2157
Un fichier pouvait franchir une passerelle X.400, conserver ses octets et revenir avec une étiquette plausible sans satisfaire pour autant la définition d’une équivalence. La RFC 2157 réservait ce mot à une paire de conversions formant un aller-retour sans perte; elle distinguait…

Histoire d'Internet
Le même Digest a ouvert deux fois la porte : la frontière anti-rejeu du RFC 2069
Deux lignes identiques apparaissent dans un journal: même utilisateur, même nonce, même URI, même réponse hexadécimale. Toutes deux sont valides. La première a-t-elle autorisé l’action et la seconde l’a-t-elle rejouée ? Le calcul du RFC 2069 ne peut pas répondre seul. Il faut…

Histoire d'Internet
Le logiciel savait le faire ; la passerelle devait encore le prouver : RFC 2156
La RFC 2156 refusait de confondre une capacité inscrite dans un produit avec la conformité de la passerelle qui transportait réellement le courrier. Une installation pensée pour un groupe fermé pouvait, par une liste de diffusion, devenir un maillon mondial sans changement de…

Histoire d'Internet
Ned Freed et le nom de fichier qu’il faut reconstruire sans jamais lui faire confiance
Un paramètre MIME peut traverser le réseau en fragments numérotés et dans un ordre quelconque. RFC 2231 permet d’en retrouver la valeur internationale, mais cette réussite syntaxique ne transforme ni un `filename` en chemin sûr, ni une étiquette en identité, ni une métadonnée en…

Dossier
Le registre indiquait la version, pas le sens : RFC 9713
Une seule colonne a suffi pour révéler une confusion coûteuse. RFC 9713 permet désormais de voir si un type d’enregistrement administratif appartient à BPv6, à BPv7 ou aux deux. Cette indication rend le registre plus exact; elle ne transforme toujours pas un entier en convention…

Histoire d'Internet
Le proxy a réécrit le numéro : la promesse locale de HTTP/1.1 dans le RFC 2068
Entre un navigateur et un serveur d’origine, un proxy pouvait recevoir une requête marquée `HTTP/1.1` puis en émettre une autre avec un numéro différent. Ce n’était pas une falsification de l’histoire du paquet, mais la conséquence d’une règle plus exigeante: chaque émetteur…

Histoire d'Internet
L’adresse était lisible, mais ce n’était pas son identité sur le fil : RFC 2155
Dans la MIB APPN de la RFC 2155, une adresse de liaison pouvait être parfaitement lisible tout en restant impropre à identifier les octets réellement transmis. La norme séparait volontairement l’étiquette d’affichage, l’objet propre au DLC, l’état de la liaison et le résultat…

Histoire d'Internet
RFC 2067 : trois libertés de format ont disparu pour faire avancer la norme
Une norme peut mûrir en se délestant. En janvier 1997, RFC 2067 retira trois formes de paquet que RFC 1374 avait autorisées, après avoir constaté qu'aucune implémentation en service ne les employait. Il fixa en même temps une frontière topologique: l'interopérabilité était…

Histoire d'Internet
La signature connaissait l’auteur, pas la réalité du lien : RFC 2154
Avec la RFC 2154, une LSA OSPF pouvait conserver la preuve de son origine pendant tout le flooding. L’intégrité du trajet devenait vérifiable. Mais le routeur d’origine pouvait toujours signer impeccablement une métrique fausse, un lien tombé ou un réseau stub inexistant.

Histoire d'Internet
Ward Christensen et l’accord de 128 octets qui laissait les extrémités libres
XMODEM n’a pas conquis les micro-ordinateurs en promettant un service complet. Ward Christensen a fixé sur la ligne un accord minuscule et vérifiable, puis laissé l’appel, le stockage, les noms de fichiers, l’interface et les perfectionnements aux machines situées aux deux…

Tendances FAI régionaux Amérique du Nord
FirstLight a fait de VETRO son référentiel réseau. Le terrain doit encore s’y réconcilier
FirstLight affirme avoir achevé sa migration vers VETRO et désigné la plateforme comme référentiel officiel du réseau. La véritable épreuve commerciale commence après ce jalon: les modifications de chantier, commandes de service, engagements de capacité et dérogations doivent…

Histoire d'Internet
RFC 2066 : le jeu de caractères était déjà le bon, mais il fallait répondre
Telnet évitait les boucles de politesse par une règle simple: ne pas accuser réception d'une demande portant sur un mode déjà actif. Le RFC 2066 a créé une exception étroite. Même s'il utilisait déjà l'un des jeux proposés, le récepteur devait répondre `ACCEPTED`, faute de quoi…
