Digest du jour
dimanche 26 juillet 2026
Digest court
La 22.1.0-rc.0, sortie le 22 juillet, est une release courte mais structurante pour deux publics précis. Côté intégration, Angular sait enfin démarrer une application sous un shadow root, ce qui débloque proprement les micro-frontends et les Web Components. Côté outillage, le framework enregistre en mode dev un outil in-page angular:di-graph qui expose la totalité du graphe d'injection de dépendances à un assistant IA. Les deux changements visent le même angle : rendre Angular « inspectable » et « encapsulable » par des systèmes extérieurs. Rien de cassant dans cette RC, mais deux capacités qui changent la façon dont tu embarques et dont tu debugges une app.
Top 1 — Angular 22.1.0-rc.0 : encapsulation et introspection
- Bootstrap sous shadow root :
SharedStylesHostenregistre désormais les styles dans le shadow root parent, donc une app Angular tourne isolée dans un Web Component. angular:di-graph: en mode dev, Angular publie un outil in-page qui rend le graphe DI complet, exploitable par un agent IA ou un MCP navigateur.@angular/ariaen GA : le paquet d'accessibilité est déclaré production-ready et aligné sur les Signal Forms.
Top 2 — À surveiller
- Cadence de servicing : 22.0.8 est sortie le 22 juillet en parallèle de la RC ; la 22.1.0 stable suit la fenêtre habituelle.
- Angular 20 : fin de support le 28 novembre 2026 — si tu traînes encore dessus, la fenêtre de migration se referme.
→ Analyse complète : 2026-07-26_detail.md
Digest court
La documentation EF Core 11 s'est stabilisée après la Preview 6 du 14 juillet, et trois changements méritent que tu t'y arrêtes maintenant plutôt qu'en novembre. Le premier lève une limitation vieille de plusieurs versions : les types complexes et les colonnes JSON fonctionnent enfin avec l'héritage TPT et TPC. Le deuxième est purement gratuit — EF génère du SQL plus propre pour les navigations to-one, avec 22 à 29 % de gain mesuré sur des scénarios courants. Le troisième change un défaut : les colonnes vectorielles ne sont plus projetées lors de la matérialisation d'entités, pour un facteur 9 en local et 22 contre Azure SQL. Aucun ne demande de réécriture massive, tous rendent une migration vers .NET 11 plus attractive.
Top 1 — EF Core 11 : ce qui se débloque
- Types complexes + TPT/TPC : tu peux enfin mapper un value object sur une hiérarchie table-par-type, en colonnes ou en JSON.
- Configuration par chaînage :
.Property(e => e.Details.Description)remplace le double appelComplexProperty().Property(). - Cosmos DB : types complexes, batches transactionnels par défaut et exécution bulk.
Top 2 — Performance sans effort
- Jointures to-one élaguées en split query : +29 % mesuré sur un scénario courant.
ORDER BYallégé : les clés de navigation redondantes disparaissent, +22 % mesuré.CASTno-op supprimés : les index redeviennent utilisables sur les colonnes à value converter.- Colonnes vectorielles non chargées par défaut : ×9 en local, ×22 sur Azure SQL.
Top 3 — À surveiller
- Compatibilité SQL Server :
UseSqlServerpasse par défaut au niveau 160 (SQL Server 2022) — breaking change à lire avant migration. - Calendrier : .NET 11 et EF Core 11 le 10 novembre 2026 ; .NET 8 et .NET 9 sortent de support le même jour.
→ Analyse complète : 2026-07-26_detail.md
Digest court
Deux annonces de milieu de semaine, toutes deux du côté infrastructure plutôt que modèles. Le 23 juillet, vLLM publie le plugin AFD, qui désagrège l'attention et les experts FFN d'un MoE en deux services déployés séparément — jusqu'à +11 % de débit par die sur DeepSeek V3.2 quand le ratio est bien choisi, et −47 % de TTFT médian sur le chemin prefill asynchrone. La veille, Hugging Face refond son serveur MCP autour d'un outil unique hf_fs qui remplace la douzaine d'outils précédents pour environ 1 000 tokens, et y ajoute des Sandboxes d'exécution rattachés aux buckets. Le fil rouge de la semaine : optimiser la topologie de service et le budget de contexte, plutôt que sortir un modèle de plus.
Top 1 — vLLM AFD Plugin : séparer attention et experts
- Deux services indépendants : l'attention garde le scheduler, le KV cache et le sampling ; le FFN devient un démon sans état.
- Résultats mesurés : 64A16F atteint +11,3 % de tokens/s/die à 16K et +9,0 % à 32K contre une baseline EP64 ; 48A16F fait moins bien que la baseline.
- Prefill asynchrone : TTFT médian de 15,1 s à 8,0 s à 12 req/s sur l'expérience CAM async.
- Statut : expérimental, épinglé sur vLLM 0.19.1, DeepSeek V2/V3 et GLM MoE DSA.
Top 2 — Hugging Face MCP : moins d'outils, plus de contexte utile
hf_fs: une interface unique vers repos, storage, docs et papers, avec recherche intégrée.- Sandboxes : environnements d'exécution sécurisés attachés aux buckets et repos.
- Effet direct : le budget de tokens consommé par la définition des outils s'effondre.
→ Analyse complète : 2026-07-26_detail.md
Digest court
Le bilan publié le 22 juillet par GitGuardian sur six semaines d'attaques npm et PyPI livre deux enseignements qui rendent obsolètes des réflexes de défense encore courants. Premier : le compromis de jscrambler — un fournisseur de sécurité, ironie comprise — a fait tourner un infostealer Rust qui s'exécute à l'import et non à l'installation, ce qui neutralise npm install --ignore-scripts et le nouveau défaut d'npm v12. Sa cible inclut explicitement les fichiers de configuration des assistants de code IA : Claude Desktop, Cursor, Windsurf, VS Code, Zed. Second : les paquets @asyncapi backdoorés portaient une provenance Sigstore et SLSA parfaitement valide, parce que l'attaquant contrôlait l'identité CI. La signature disait vrai. Elle ne disait simplement rien d'utile.
Top 1 — jscrambler / IronWorm : l'infostealer qui vise tes clés d'IA
- Cinq versions piégées (8.14.0 à 8.20.0) publiées le 11 juillet avec un token npm volé.
- Bascule de vecteur : les premières versions utilisaient un hook
preinstall, les suivantes s'exécutent à l'import —--ignore-scriptsne protège plus. - Cible élargie : clés AWS/Azure/GCP, tokens npm et GitHub, coffres Bitwarden, trousseaux OS, et configs MCP des assistants de code.
- Remédiation : passer en 8.22.0, faire tourner toutes les clés exposées.
Top 2 — Provenance Sigstore/SLSA : ce qu'une attestation valide ne prouve pas
- Quatre paquets
@asyncapipubliés via l'OIDC trusted publisher d'npm, avec attestations conformes. - 2,25 M de téléchargements/semaine cumulés ; fenêtre d'exposition de ~4 h, mais les lockfiles générés pendant peuvent encore résoudre vers les versions piégées.
- La leçon : la provenance prouve d'où vient un artefact, pas si le code entré dans le build était sain.
À surveiller
pull_request_target: le workflow vulnérable d'AsyncAPI était signalé depuis 58 jours.actions/checkoutv7 a des défauts plus sûrs — encore faut-il l'adopter.
→ Analyse complète : 2026-07-26_detail.md