VeilleTech — 2026-09-22

01 SÉCURITÉ Faille

npm : trois clones de mathjs cachent un implant

SafeDep18 septembre3 min de lecture

SafeDep et JFrog décrivent un implant d'accès à distance caché, chiffré, dans trois copies npm de mathjs : mathmain, mathsbase et math-universe. Il ne s'active ni à l'installation ni à l'import, mais quand lusolve() reçoit une matrice précise, dont le facteur L sert de mot de passe. Cinq versions sont touchées ; aucun appelant n'a encore été identifié.

Versions piégées : mathmain@1.0.0, mathsbase@1.0.1, math-universe@1.0.0, 1.0.1 et 1.0.2 — mathsbase@1.0.0 et 1.0.2 sont propres
Déclencheur : lusolve() sur la matrice `[[1,1,1],[1,2,3],[1,3,6]]` ; mot de passe = JSON de L, `[[1,0,0],[1,1,0],[1,0.5,1]]`
Fichiers à chercher sous `lib/cjs/utils/` : `event.js`, `is.js`, `graph.js`, `fraction.js`, `bignumber/type.js` ; commande via Slack, Telegram et contrat Base Sepolia `0xac0bfC4C48A679b667732128278EACBA1c191894`

Un paquet qui dort jusqu'à ce qu'on lui tende la bonne matrice ne se voit à aucune analyse. Il se voit dans votre lockfile.

Lire la fiche Source

02 SYMFONY Article

Symfony 8.2 : Messenger gagne outbox et claim check

Symfony21 septembre2 min de lecture

Symfony 8.2 ajoute à Messenger deux options de transport. `outbox` écrit le message en base dans la transaction de l'application, puis un relais le transmet au broker. `claim_check` range les messages trop gros dans un pool de cache PSR-6 et n'envoie qu'une référence vérifiée par somme de contrôle.

`outbox: db_outbox` sur le transport cible ; `db_outbox` = transport Doctrine sur la même connexion ; relais : `messenger:consume db_outbox`
`claim_check: { cache_pool, max_size }` — au-delà de `max_size` octets (corps + en-têtes), le message va dans le pool PSR-6 (Redis, Valkey, Memcached, PDO…)
Ordre non garanti par l'outbox ; pool dédié avec `default_lifetime` plus long que délais, retries et file d'échec, sinon `ClaimCheckNotFoundException`

Deux motifs que tout le monde réécrivait à la main. Symfony les livre, avec leurs limites écrites.

Lire la fiche Source

03 SYMFONY Article

Symfony UX 3.5 : la pagination, et des tests à revoir

Symfony21 septembre3 min de lecture

Symfony UX 3.5 livre `symfony/ux-pagination`, un paginateur sans JavaScript à trois stratégies, ainsi que le support de Twig 4. Le rendu des attributs de composants passe désormais par Twig : le HTML produit change pour les booléens, `null`, `aria-*` et les tableaux, ce qui fait échouer les tests qui comparent ce rendu.

`symfony/ux-pagination` (expérimental) : numérotée, lookahead sans `COUNT`, curseur bidirectionnel ; `<twig:ux:pagination>` en thèmes défaut, Bootstrap, Tailwind
Rendu des attributs délégué à Twig : exige `twig/twig` ^3.24 et `twig/html-extra` ^3.29 ; assertions HTML à régénérer (composants, `ux_icon()`, `ux_map()`)
Autocomplete sans Doctrine via `AutocompleterInterface` ; route `ux_entity_autocomplete` dépréciée au profit de `ux_autocomplete`

La pagination tant attendue arrive enfin. Avec elle, un rendu qui change assez pour faire rougir votre CI.

Lire la fiche Source

04 LARAVEL Article

Difflock juge vos migrations sur la vraie base

Laravel News21 septembre2 min de lecture

Difflock 1.0 analyse les migrations Laravel sans les exécuter et les compare au schéma réel et au volume des tables, pour signaler ce qu'une base de test vide ne montre pas. Il enregistre aussi un instantané du schéma pour détecter les dérives, s'intègre à la CI par codes de sortie et expose un serveur MCP pour les agents.

`composer require heyosseus/difflock --dev` puis `php artisan difflock:doctor` — PHP 8.3, Laravel 12 ou 13, MySQL, MariaDB, PostgreSQL, SQLite
`difflock:lint`, `difflock:diff --save` (→ `database/difflock/schema.json`), `difflock:check --ci` : code 0 OK, 1 risque ou dérive, 2 contrôle impossible
`php artisan migrate` n'est pas protégé : seul `difflock:migrate` bloque ; historique existant accepté avec `difflock:lint --all --accept`

Une migration se relit contre la base qu'elle va toucher, pas contre celle des tests.

Lire la fiche Source

05 CLOUDFLARE Discussion

Cloudflare Python Workers : FastAPI, Django et Postgres

Cloudflare Blog21 septembre2 min de lecture

Après deux ans de préversion, Python Workers est en disponibilité générale. Les bindings Cloudflare s'utilisent en Python natif, FastAPI, Flask et Django tournent via des connecteurs ASGI et WSGI, et des sockets réimplémentés ouvrent Postgres et MySQL via Hyperdrive. La PEP 783, acceptée, standardise la compilation des paquets natifs vers WebAssembly.

`Default = asgi.entrypoint(app)` pour FastAPI ; `wsgi.entrypoint(app)` pour Django ; plus de `to_js()` pour appeler Queues, R2, D1
Sockets réimplémentés sur l'API `connect` : `asyncpg`, `aiomysql` via Hyperdrive ; `requests` et `httpx` passent par `fetch` (openai, langchain, mcp)
PEP 783 acceptée (plateforme PyEmscripten), prise en charge par `cibuildwheel` ; exemples : `cloudflare/python-workers-examples`

Python n'est plus l'invité des Workers. Reste à savoir si vos dépendances ont fait le voyage.

Lire la fiche Source

06 DEVOPS Discussion

Linear : quatre fois plus de tests, une CI plus rapide

Linear21 septembre3 min de lecture

Linear a vu sa suite de tests presque quadrupler depuis janvier sous l'effet des agents de code, tout en faisant baisser l'attente d'une pull request de plus de 6 à un peu plus de 5 minutes et en divisant environ par deux le temps machine par test. Le billet chiffre chaque levier : runners, tsgo, checkout, installation filtrée, regroupement de tâches et Vitest sans isolation.

Runners tiers : −34 % en moyenne ; `tsgo` : −73 % sur `tsc` ; lint sans type puis Oxlint : −68 % sur l'API
Checkout à profondeur limitée : détection des changements de 26 à 8 s en médiane ; `pnpm install` filtré de 44-73 s à 16-18 s ; 7 contrôles en 2 jobs = 87 000 minutes/mois
Vitest `isolate: false` sur fichiers déclarés : ~17 % d'économie mensuelle, shard le plus lent de 300-379 s à ~195 s

Quand les agents écrivent la majorité des tests, la CI devient le vrai goulot. Mesurez-la avant qu'elle ne vous mesure.

Lire la fiche Source

07 LLM Discussion

Kev : un modèle qui ne répond que par des probabilités

jaredpalmer/kev21 septembre3 min de lecture

Jev, de TypeSafe AI, inaugure les « modèles de décision » : du texte en entrée, des probabilités typées en sortie (oui/non, choix, note). Kev en propose une version ouverte sous Apache 2.0, en 0,8, 4 et 9 milliards de paramètres sur Qwen3.5, compatible avec l'API de Jev et exécutable localement. Kev-9B approche Jev sur des données inédites, mais reste lent sur Mac.

Types de questions : `noul` (probabilité de oui), `choice` (1 à 255 options + distribution), `score` (2 à 255 niveaux) ; endpoint `POST /v1/systemone`
Kev-0.8B, Kev-4B, Kev-9B (LoRA rang 16 + tête de pointage sur Qwen3.5-Base) ; nouvelles sources : 0,822 pour Kev-9B contre 0,857 pour Jev (dev)
Sur Apple M5 en bf16 : 329 ms (0.8B), 779 ms (4B), ~2 s (9B) ; les versions Qwen3 (`jaredpalmer/kev-4b@qwen3`) restent plus rapides sur Mac

Un modèle qui ne parle pas ne peut pas vous baratiner. Il ne peut pas non plus vous dire pourquoi il s'est trompé.

Lire la fiche Source

08 IA Article

Hugging Face tokenizers v1 : 3 à 30 fois plus rapide

Hugging Face21 septembre3 min de lecture

La version candidate de tokenizers v1 encode 3 à 30 fois plus vite que la v0.23 sur un seul thread, avec des identifiants de tokens strictement identiques. Les gains viennent d'un découpage SIMD sans regex, d'un cache de mots, d'une boucle de fusion sans allocation et d'appels par lots. Seule la crate Rust est disponible ; les liaisons Python suivront pour la 1.0.0.

`cargo add tokenizers --pre` ; encodage seul, sans le code d'entraînement : `--no-default-features --features http`
Mesuré sur Apple M4 Max : ×3 (t5-base) à ×30 (gpt2) sur un thread ; 76 % d'un passage à l'échelle linéaire sur 8 cœurs
Découpage SIMD pour GPT-2, cl100k, o200k, Tekken, DeepSeek ; ailleurs, retour au chemin regex. Python non mesuré, prévu pour 1.0.0

Même entrée, mêmes tokens, jusqu'à trente fois moins de temps. Le GPU, lui, n'attendra plus.

Lire la fiche Source

VeilleTech — feed du mardi 22 septembre