Astro 6 : les nouveautés qui changent la donne

En résumé : Au 5 septembre 2026, migrez d’Astro 5 vers Astro 6 si vous pouvez valider Node.js, vos adaptateurs et vos plugins. Les gains les plus concrets viennent du serveur de développement aligné sur la production, des Live Content Collections, des polices intégrées et de la CSP. Testez le compilateur Rust et Sätteri séparément avant de les généraliser.

Astro 6 est surtout une évolution de la chaîne de production. Il rapproche le développement du runtime réellement déployé et intègre plusieurs besoins auparavant couverts par des assemblages maison.

Pourquoi le nouveau serveur de développement compte-t-il ?

Astro 6 reconstruit astro dev autour de l’Environment API de Vite. Le serveur de développement et le pipeline de build partagent davantage de chemins d’exécution, ce qui réduit les écarts entre l’environnement local et la production.

Le bénéfice est particulièrement visible sur les runtimes qui ne sont pas Node.js. L’adaptateur Cloudflare peut par exemple exécuter workerd pendant le développement, le prérendu et la production, avec les bindings de la plateforme disponibles localement.

À vérifier avant migration : les intégrations et adaptateurs tiers peuvent dépendre d’anciennes APIs de Vite ou d’Astro. Les intégrations officielles ont été mises à jour, mais chaque dépendance non officielle doit être testée sur ses chemins critiques.

Quand utiliser les Live Content Collections ?

Les Live Content Collections, stabilisées dans Astro 6, récupèrent les données au moment de la requête. Elles complètent les collections chargées au build sans les remplacer.

Utilisez-les pour un CMS avec prévisualisation immédiate, un catalogue dont la disponibilité change souvent ou une API interrogée avec des filtres dynamiques. Conservez les collections de build pour les contenus relativement stables : elles restent plus simples à mettre en cache et plus performantes.

Une collection live se définit dans src/live.config.ts :

import { defineLiveCollection } from 'astro:content';
import { z } from 'astro/zod';
import { cmsLoader } from './loaders/cms-loader';

const articles = defineLiveCollection({
  loader: cmsLoader({ apiKey: process.env.CMS_API_KEY }),
  schema: z.object({
    title: z.string(),
    excerpt: z.string(),
  }),
});

export const collections = { articles };

La page interroge ensuite la collection avec getLiveCollection() ou getLiveEntry(). Cette fraîcheur a un coût : les données sont chargées à l’exécution, sans persistance automatique dans le stockage de la couche de contenu. Le MDX et l’optimisation d’images ne sont pas disponibles pour ces collections live.

Que simplifie la Fonts API ?

La Fonts API unifie les polices locales et plusieurs fournisseurs. Astro télécharge et met en cache les fichiers pour les servir depuis votre site, génère des fallbacks optimisés et peut ajouter les préchargements nécessaires.

// astro.config.mjs
import { defineConfig, fontProviders } from 'astro/config';

export default defineConfig({
  fonts: [
    {
      name: 'Roboto',
      provider: fontProviders.fontsource(),
      cssVariable: '--font-roboto',
    },
  ],
});

Vous devez ensuite placer le composant <Font /> dans l’en-tête de la page et appliquer la variable CSS. Préchargez seulement les polices indispensables au contenu immédiatement visible : un préchargement excessif concurrence les autres ressources critiques.

Comment la CSP intégrée améliore-t-elle la sécurité ?

Astro 6 stabilise une API Content Security Policy pour les pages statiques et dynamiques. Une CSP limite les sources autorisées pour les scripts, styles, images et autres ressources, ce qui aide à réduire l’impact de certaines injections.

// astro.config.mjs
import { defineConfig } from 'astro/config';

export default defineConfig({
  security: {
    csp: true,
  },
});

Astro peut calculer les empreintes des scripts et styles et produire la politique correspondante. Pour une application qui charge des ressources externes, configurez explicitement les directives nécessaires et contrôlez le résultat dans le navigateur. Une CSP ne remplace ni l’échappement des données ni la correction des vulnérabilités applicatives.

Faut-il activer le compilateur Rust expérimental ?

Dans Astro 6, le compilateur Rust reste optionnel. L’équipe Astro le présente comme plus rapide, doté de meilleurs diagnostics et mieux adapté aux fonctions modernes de JavaScript, TypeScript et CSS.

npm install @astrojs/compiler-rs

// astro.config.mjs
import { defineConfig } from 'astro/config';

export default defineConfig({
  experimental: {
    rustCompiler: true,
  },
});

Ma recommandation : activez-le d’abord en intégration continue. Le compilateur Rust ne corrige pas automatiquement une structure HTML invalide. Des balises non fermées ou une mauvaise imbrication peuvent donc modifier le rendu ou faire échouer le build. Dans Astro 6, les audits de la barre d’outils de développement font aussi partie de ses limites documentées.

Sätteri est-il compatible avec les plugins Markdown ?

Astro 6.4 ajoute l’API markdown.processor et propose @astrojs/markdown-satteri, un processeur Markdown et MDX écrit en Rust. Dans cette version, unified() reste le processeur par défaut afin de préserver la compatibilité existante.

Sätteri n’exécute pas les plugins remark et rehype. Si votre contenu dépend de ces plugins, restez sur unified() ou portez-les vers les interfaces MDAST ou HAST de Sätteri. Ne changez pas de processeur uniquement sur la promesse d’un build plus rapide : comparez le rendu, les ancres, le code coloré et vos extensions sur un échantillon représentatif.

Quelles autres fonctions méritent un test ?

Astro 6 propose aussi deux fonctions expérimentales pour le rendu serveur :

• Queued Rendering remplace le rendu récursif par une approche en deux passes. Les premiers benchmarks publiés par l’équipe Astro annonçaient jusqu’à deux fois la vitesse de rendu sur leurs scénarios.
• Route Caching fournit une API indépendante de l’hébergeur pour définir la durée de cache, le stale-while-revalidate et des tags d’invalidation.

Ces résultats ne garantissent pas un gain sur votre application. Mesurez le temps de réponse, la mémoire et le comportement sous charge avant de les activer en production.

Comment migrer proprement depuis Astro 5 ?

Commencez par l’outil de mise à niveau officiel :

npx @astrojs/upgrade

Traitez ensuite les changements dans cet ordre :

1. Node.js : utilisez la version 22.12.0 ou une version plus récente en local et sur l’hébergement.
2. Dépendances majeures : contrôlez les migrations vers Vite 7, Zod 4 et Shiki 4.
3. Adaptateurs et intégrations : mettez-les à jour ensemble et consultez leur changelog.
4. Content Collections : migrez les anciennes collections vers la Content Layer API ; la compatibilité automatique historique a été retirée.
5. Application : vérifiez les routes, le rendu serveur, les formulaires, les images et le contenu en préproduction.

Une mise à niveau réussie ne se limite pas à un build vert. Exercez les parcours utilisateurs et l’environnement de déploiement réel, surtout si vous utilisez Cloudflare ou des APIs Vite personnalisées.

Conclusion

Astro 6 mérite la migration pour ses améliorations structurelles : développement plus proche de la production, données live, polices mieux intégrées et CSP native. Ces fonctions répondent à des problèmes concrets sans imposer le compilateur Rust ni un nouveau processeur Markdown.

Pour un projet Astro 5, je recommande une migration progressive : socle et adaptateurs d’abord, fonctions stables ensuite, expérimentations Rust séparément. Vous obtenez ainsi les bénéfices d’Astro 6 sans confondre mise à niveau nécessaire et optimisation facultative.

Sources

• Astro 6.0 — annonce officielle
• Guide officiel de migration vers Astro 6
• Documentation officielle des Content Collections
• Documentation officielle de la Fonts API
• Documentation du compilateur Rust expérimental d’Astro 6
• Astro 6.4 — processeur Markdown et Sätteri