lundi 3 août 2026

Digest court

Journée sans release : le blog Angular n'a rien publié depuis le 17 juillet et le dernier tag stable reste la ligne 22.1.x, avec un 22.2.0-next en cours d'intégration. L'actualité utile est donc côté API, pas côté version : Signal Forms a discrètement uniformisé ses règles conditionnelles autour d'une option when, ce qui change la signature de hidden, disabled et readonly par rapport aux exemples v21 encore visibles dans la doc de référence. En parallèle, injectAsync et son option prefetch méritent un vrai passage en revue : c'est le premier mécanisme de lazy loading côté injecteur, pas côté route. Les deux sujets touchent du code que tu écris tous les jours dans un back-office. On les traite en mini-cours plutôt que d'attendre une release.

Top 1 — Signal Forms : les règles conditionnelles se normalisent

• hidden(path, { when }) : la condition passe désormais par un objet d'options, aligné sur disabled et readonly.
• Champ caché ≠ champ absent : un champ hidden ne contribue plus à la validation ni à l'état touched/dirty du parent, mais reste dans le modèle.
• Pas d'attribut DOM : [formField] n'applique aucun hidden sur l'élément — tu gardes la responsabilité du @if dans le template.
• disabled renvoie une raison : la lambda peut retourner une chaîne explicative au lieu de true, exploitable dans l'UI.

Top 2 — Injection paresseuse : injectAsync et onIdle

• injectAsync(() => import(...)) : le bundle du service n'est chargé qu'au premier appel effectif.
• { prefetch: onIdle } : Angular précharge le bundle dès que le navigateur est inactif, via requestIdleCallback.
• Contrainte : le service injecté doit être auto-provisionné (@Service() ou providedIn: 'root').

Rien de neuf non plus côté écosystème build : Rolldown reste le bundler stable annoncé avec 22.1, et TypeScript 6 la baseline depuis 21.2.

→ Analyse complète : 2026-08-03_detail.md

Digest court

Le cycle .NET 11 avance sans annonce fracassante : la Preview 7 est buildée (11.0.0-preview.7) mais Microsoft n'a pas publié de billet dédié, et la page « What's new » du portail Learn reste calée sur la Preview 6. On regarde donc le fond plutôt que le communiqué. Deux mouvements se dégagent. Côté EF Core 11, le générateur SQL continue son travail de fond : Contains sur collections primitives JSON bascule sur JSON_CONTAINS au lieu d'OPENJSON, les CAST inutiles sont supprimés du SQL, et MaxBy/MinBy deviennent traduisibles. Côté BCL, quatre nouveaux types Stream permettent d'exposer de la mémoire déjà en RAM comme un flux sans la recopier. Trois sujets à impact direct sur du code backend PostgreSQL/SQL Server, traités en mini-cours.

Top 1 — EF Core 11 : le SQL généré se rapproche du SQL qu'on écrirait

• JSON_CONTAINS : b.Tags.Contains("ef-core") ne passe plus par OPENJSON, à condition d'activer le niveau de compatibilité 170.
• EF.Functions.JsonContains() : appel direct de la fonction, avec chemin JSON et mode de recherche.
• EF.Functions.JsonPathExists() : test d'existence d'un chemin, traduit en JSON_PATH_EXISTS.
• Attention : la traduction est abandonnée si EF ne peut prouver qu'un des deux côtés est non-nullable.

Top 2 — EF Core 11 : MaxBy/MinBy et nettoyage des CAST

• MaxByAsync / MinByAsync : traduits en TOP(1) … ORDER BY <clé> DESC, plus de matérialisation côté client.
• Suppression des CAST no-op : CAST([Name] AS nvarchar(max)) sur une colonne déjà nvarchar(max) disparaît, ce qui redonne l'usage des index.

Top 3 — .NET 11 : quatre Stream sans copie

• ReadOnlyMemoryStream, WritableMemoryStream, ReadOnlySequenceStream, StringStream : exposer de la mémoire existante comme flux, sans allocation de tampon intermédiaire.
• Cible : APIs qui exigent un Stream alors que tu as déjà un ReadOnlyMemory<byte>, un ReadOnlySequence<byte> (pipeline Kestrel) ou une string.

→ Analyse complète : 2026-08-03_detail.md

Digest court

vLLM a publié la v0.26.0 — 411 commits, 212 contributeurs — et deux changements y méritent mieux qu'une ligne de changelog. Le premier est structurel : le backend d'attention se choisit désormais par groupe de KV-cache, et la fenêtre glissante devient une capacité déclarée du backend plutôt qu'un cas spécial câblé dans le moteur. C'est le socle pour servir proprement les architectures hybrides, qui mélangent couches à attention complète et couches à fenêtre glissante — devenues la norme chez Qwen, Gemma ou les MoE récents. Le second est un réglage de précision : head_dtype permet de garder le lm_head en fp32 alors que le reste du modèle tourne en bf16 ou en 4 bits. Deux sujets d'ingénierie d'inférence, à comprendre si tu auto-héberges un modèle ouvert.

Top 1 — vLLM v0.26.0 : un backend d'attention par groupe de KV-cache

• Sélection par groupe : chaque groupe de couches partageant une configuration de cache peut recevoir un backend distinct.
• Fenêtre glissante déclarée : le support SWA devient une capacité annoncée par le backend, vérifiée au démarrage.
• Conséquence : les modèles hybrides SWA + attention complète cessent d'être des cas particuliers, et le préfixe-cache partiel devient possible sur ces modèles.
• Contexte : torch.compile, disposition KV repackée, et FlashInfer 0.6.14 dans la même release.

Top 2 — head_dtype : garder la tête de génération en fp32

• Problème : quantifier tout le modèle dégrade surtout la dernière projection, celle qui produit les logits sur le vocabulaire.
• Solution : --head-dtype float32 isole le lm_head du reste de la quantification.
• Portée : étendu au chemin LoRA, avec une voie rapide torch.mm côté ROCm.
• Effet de bord : la même release cesse d'upcaster les logits en fp32 dans le sampler — les deux réglages se répondent.

Sur le radar

Transformers 5.13.0 devient la dépendance de référence de vLLM, et les modèles TeleChat, Persimmon et Fuyu sont retirés — vérifie tes déploiements figés avant de monter de version.

→ Analyse complète : 2026-08-03_detail.md

Digest court

Deux failles à traiter, et le même schéma dans les deux : la vulnérabilité n'est pas dans une fonction exotique mais dans un comportement documenté d'un outil de confiance, détourné par un enchaînement inattendu. Gitea corrige CVE-2026-60004, un RCE 9.8 où un simple utilisateur avec droit d'écriture sur un dépôt transforme un patch en hook Git actif — et comme l'inscription est ouverte par défaut, un visiteur peut créer ce compte lui-même. Fastjson traîne CVE-2026-16723, une exécution de code non authentifiée dans les applications Spring Boot packagées en fat-JAR, avec exploitation observée et aucun correctif 1.x publié. Le point commun : dans les deux cas, la configuration par défaut est ce qui rend l'attaque praticable.

Top 1 — Failles à traiter aujourd'hui

• Gitea CVE-2026-60004 (CVSS 9,8) : versions 1.17 à 1.27.0, corrigé en 1.27.1. PoC public. Mitigation partielle : couper l'inscription ouverte.
• Fastjson CVE-2026-16723 (CVSS 9,0) : versions 1.2.68 à 1.2.83 dans un fat-JAR Spring Boot. Pas de correctif 1.x. Palliatif : -Dfastjson.parser.safeMode=true.

Top 2 — Ce que ces deux cas t'apprennent

• Le changelog ment par omission : le correctif Gitea est listé sous « MISC : refactor git patch apply », pas sous SECURITY. Lire les advisories, pas les release notes.
• Le périmètre dépend du packaging : Fastjson n'est exploitable que via le loader de fat-JAR Spring Boot. WAR Tomcat/Jetty et JAR simples ne sont pas concernés.
• Écart entre observation et catalogue : ThreatBook et Imperva rapportent de l'exploitation, l'évaluation CISA-ADP du 23 juillet marque none et la faille n'était pas au KEV. Les sources n'expliquent pas la divergence.

Sur le radar

Une faille snap-confine donnant root local sur installations Ubuntu desktop par défaut, et OpenSSL « HollowByte » (déni de service via requêtes TLS de 11 octets) — à suivre si tu exposes des services Linux.

→ Analyse complète : 2026-08-03_detail.md