Signaux à surveiller
Edge computing
De plus en plus de logique migre au bord du réseau. Cloudflare Workers, Deno Deploy, Vercel Edge Functions - le backend se rapproche physiquement de l’utilisateur. Les bases de données suivent avec Turso (SQLite edge) et PlanetScale. L’impact est mesurable : des latences sous les 50ms partout dans le monde, sans gérer de CDN complexe.
AI-native UI
Les interfaces générées dynamiquement par des LLMs changent la donne. Vercel v0 génère du React depuis un prompt. GitHub Copilot ne se limite plus au code - il comprend le contexte du projet entier. La question n’est plus “est-ce que l’IA va remplacer les devs” mais “comment concevoir des interfaces qui s’adaptent en temps réel à l’utilisateur”.
Local-first
CRDTs et sync sans serveur central. Des outils comme Automerge et Yjs permettent la collaboration temps réel sans backend. Linear et Figma ont montré que le local-first offre une UX supérieure : l’app répond instantanément, la sync est transparente. Le défi reste la résolution de conflits sur des structures complexes.
WASM everywhere
WebAssembly sort du navigateur. WASI permet de l’exécuter côté serveur, Fermyon Spin et Wasmtime proposent des runtimes légers. Le cas d’usage le plus excitant : des plugins universels écrits une fois, exécutables partout. SQLite compile en WASM, ffmpeg compile en WASM - la portabilité est réelle.
Nouveaux signaux 2026
2026-01-20 - Écosystème Astro/Vite
Vite 6 stabilise son API d’environnement, ouvrant la porte à des intégrations plus profondes. Astro 5 en profite avec des builds plus rapides et un support natif des View Transitions. Le combo Astro + Vite est devenu le standard pour les sites content-first. J’ai testé ça sur ce jardin - le DX est incomparable.
2026-02-10 - Claude Code et le dev assisté par IA
L’arrivée de Claude Code change ma façon de travailler. Ce n’est pas juste de l’autocomplétion - c’est un agent qui comprend le contexte du projet, navigue dans les fichiers, et propose des modifications cohérentes. J’ai testé ça sur Summoner pour générer des composants, et le gain de temps est réel sur les tâches répétitives.
2026-02-15 - WebContainers
StackBlitz a ouvert la voie avec les WebContainers : un environnement Node.js complet qui tourne dans le navigateur. Les implications sont énormes pour l’éducation, les démos interactives et le prototypage. Plus besoin d’installer quoi que ce soit - tout tourne dans un onglet.
2026-02-28 - Lit et les Web Components
Lit 3 simplifie les Web Components standards. Contrairement à React ou Vue, les composants Lit sont des éléments HTML natifs, utilisables partout sans framework. Pour un design system comme Totem, la question se pose : faut-il migrer les composants SCSS vers des Web Components interopérables ?
2026-03-05 - SQLite everywhere
SQLite n’est plus juste une base embarquée. Avec Turso (libSQL distribué), Litestream (réplication S3), et le support WASM natif, SQLite devient une option sérieuse pour le web. Le pattern “une base par utilisateur” offre une isolation naturelle et des performances excellentes.
À creuser
Ces sujets sont encore des pousses. Il faut les arroser avec de la lecture et de l’expérimentation. L’objectif est de connecter chaque signal à un projet concret pour ancrer la théorie dans la pratique.
Grille de priorisation
Pour décider quoi creuser en premier, je classe chaque signal selon deux axes :
| Signal | Impact potentiel | Facilité de test | Priorité |
|---|---|---|---|
| Edge computing | Haut | Moyen | A |
| AI-native UI | Très haut | Facile | A |
| Local-first | Moyen | Difficile | B |
| WASM everywhere | Haut | Moyen | B |
| Astro/Vite | Haut | Facile | A |
| Claude Code | Très haut | Facile | A |
| WebContainers | Moyen | Facile | B |
| Lit/WC | Moyen | Moyen | C |
| SQLite everywhere | Haut | Facile | A |
Les signaux en priorité A sont ceux que j’intègre activement dans mes projets. Les B sont en observation. Les C sont des curiosités à surveiller de loin.
La priorité évolue vite : SQLite everywhere était en C il y a six mois, c’est maintenant en A depuis que Turso a stabilisé son offre et que j’ai testé le pattern sur Summoner. La veille n’est pas une liste figée - c’est un flux permanent à réévaluer.
Méthode de veille
Ma veille repose sur trois canaux :
- Newsletters : JavaScript Weekly, Node Weekly, CSS-Tricks. Lecture rapide le lundi matin.
- Repos GitHub : suivre les releases des projets clés (Astro, Vite, Lit). Les changelogs sont souvent plus instructifs que les articles.
- Expérimentation directe : le meilleur moyen de comprendre un signal est de l’essayer sur un projet réel. Ce jardin sert souvent de bac à sable.
- Conversations entre devs : les retours d’expérience d’autres développeurs filtrent le bruit. Un signal qui revient dans trois conversations différentes mérite qu’on s’y arrête.
Le piège classique de la veille, c’est de lire sans faire. Chaque signal intéressant devrait déboucher sur un prototype, même minimaliste. C’est pour ça que ce jardin sert de terrain d’expérimentation - tester un signal sur un vrai projet ancre la théorie dans la pratique.