Aller au contenu

Matrice de prise en charge des cadriciels

Engendrée depuis le registre. Ne pas modifier à la main.

Trois rangs de support, définis par le cahier des charges (§ 2.2 du socle d'exécution) et, pour la composition du rang A, par l'arbitrage M-08.

Ce que le produit reconnaît automatiquement aujourd'hui : le rang A en entier, le rang B en partie — Python ASGI et WSGI (FastAPI, Django, Flask), Go. Le rang C est un engagement pris, dont les détecteurs et les gabarits restent à écrire : un dépôt de ce rang ne part pas en production sans configuration à ce jour.

RangEngagementCadricielsLotReconnu aujourd'huiConstruit aujourd'hui
A — venduGabarit de construction écrit et maintenu par Glowsoft, suite de conformité exécutée à chaque version, taux de réussite publié, régression bloquante.Next.js (16.2+), Nuxt 4, SvelteKit 2, Astro 5, React Router 7 / Remix, Vite (application monopage), export statique, Node générique (Express, Fastify, Hono, NestJS)L0ouioui
B — supportéGabarit écrit, tests d'intégration, correction sous 30 jours, pas d'engagement de parité fonctionnelle.Python ASGI et WSGI (FastAPI, Django, Flask), Go, Générateurs statiques (Hugo, Docusaurus, VitePress), PHP 8.3+ (Symfony, Laravel)L1 pour Python et Go, L2 pour PHPen partie — Python ASGI et WSGI (FastAPI, Django, Flask), Gooui
C — au mieuxRepli Railpack, aucun engagement, message d'avertissement affiché à la détection.Ruby, Rust, Bun, Deno, JavaL1nonNon, pas encore mesuré. Le planificateur de repli télécharge ses chaînes d'outils depuis le web ouvert, et la sortie d'une construction est fermée sur tous les nœuds (mesuré le 06/10/2026 : « tcp connect error: Network unreachable »). Décidé le 12/10/2026 : les constructions de repli sortent par un mandataire journalisé, vers une liste de domaines déclarée. Mesuré le 12/10/2026 : un dépôt Deno construit par cette voie en 24 secondes et sert sain ; Ruby, Rust, Bun et Java ne sont pas encore mesurés.

Taux de réussite de la suite de conformité — rang A

Un taux n'est publié que pour un cadriciel dont la suite a tourné ; une absence est nommée plutôt que remplie.

CadricielJetonTaux de réussite de la suite de conformité
Next.js (16.2+)nextjs98.6 %
Nuxt 4nuxt100.0 %
SvelteKit 2sveltekit100.0 %
Astro 5astro100.0 %
React Router 7 / Remixremix92.3 %
Vite (application monopage)vite100.0 %
export statiquestatic100.0 %
Node générique (Express, Fastify, Hono, NestJS)node100.0 %

Next.js — 98.6 %, conditions de la mesure

  • Suite : tests de déploiement de Next.js (test/e2e, mode deploy, filtrés par test/deploy-tests-manifest.json).
  • Version : Next.js 16.4.0, adaptateur de Bastide (TR-055). Mesuré le 2026-10-14.
  • Échantillon : 60 fichiers de test sur 1188 — liste triée des fichiers retenus par le manifeste, un sur 20.
  • Cas : 141 réussis, 1 échoués, 252 ignorés par le manifeste de Next.js ; 1 fichier(s) dont l'application n'a pas pu être déployée, comptés comme un cas échoué chacun ; 1 sorti(s) du taux pour le réseau du banc.
  • Joué dans le nuage de développement : l'étage de construction du gabarit Next.js rejoué sans conteneur (même adaptateur, même assembleur, même lanceur), Node 22 comme le gabarit par défaut, serveur Node local, aucune reprise. Ni BuildKit, ni l'image, ni l'agent, ni l'edge : ce n'est pas une mesure sur le parc. 1 fichier(s) sortis du taux parce que leur application interroge un service de Vercel que le réseau du banc ne joint pas.

Les sept autres cadriciels du rang A — conditions de la mesure

Suite de conformité de Bastide (tools/conformite-cadriciels/) : un témoin par cadriciel, et un comportement par cas — rendu à la requête, route à paramètre, route d'API, formulaire envoyé en https derrière l'edge, redirection, 404, variable lue à l'exécution, cookie, fichiers publics et à empreinte, arrêt sur SIGTERM pour un serveur ; pages, 404 du site, routes clientes et types pour un site statique.

  • Joué dans le nuage de développement : chaque témoin est construit par BuildKit depuis le Dockerfile que la plateforme engendre (plan de detect.ts, gabarit de dockerfile.ts, miroir npm en relais), puis lancé sous les contraintes de l'agent — racine en lecture seule, /tmp en mémoire, UID 10000, aucune capacité, PORT imposé. Les requêtes portent les en-têtes que l'edge pose sans passer par lui : ni l'agent, ni l'edge, ni le parc. Aucune reprise.
  • Nuxt 4 — 100.0 %, 13 cas sur 13, version 4.5.2, mesuré le 2026-10-17 (plateforme 0bbf54e2).
  • SvelteKit 2 — 100.0 %, 13 cas sur 13, version 2.70.3, mesuré le 2026-10-17 (plateforme 0bbf54e2).
  • Astro 5 — 100.0 %, 10 cas sur 10, version 5.18.2, mesuré le 2026-10-17 (plateforme 0bbf54e2).
  • React Router 7 / Remix — 92.3 %, 12 cas sur 13, version 7.18.4, mesuré le 2026-10-17 (plateforme 0bbf54e2). Échoue : un formulaire envoyé en POST depuis la page publique (https, derrière l'edge) est traité (400 « Bad Request »).
  • Vite (application monopage) — 100.0 %, 8 cas sur 8, version 7.3.7, mesuré le 2026-10-17 (plateforme 0bbf54e2).
  • export statique — 100.0 %, 9 cas sur 9, mesuré le 2026-10-17 (plateforme 0bbf54e2).
  • Node générique (Express, Fastify, Hono, NestJS) — 100.0 %, 12 cas sur 12, version 5.3.0, mesuré le 2026-10-17 (plateforme 0bbf54e2).

Les limites connues de Next.js

  • Aucun runtime d'isolats en périphérie. L'intergiciel et toute route qui déclare runtime = 'edge' s'exécutent dans le runtime Node du conteneur de l'application. C'est un non-objectif, pas un manque : le manifeste de déploiement de chaque release le dit route par route.
  • Next.js 16.2 et au-delà passent par l'adaptateur de Bastide, écrit contre l'API d'adaptateur de Next.js : serveur autonome, actifs immuables servis à part, manifeste de déploiement (sorties statiques, fonctions, intergiciel, prérendus, routage).
  • Avant la 16.2, l'application est assemblée par OpenNext (repli de rang B, TR-055) ; si l'assemblage échoue, elle est servie comme une application Node (next start sur le projet entier). Sous OpenNext, revalidateTag ne vaut que pour l'instance qui l'appelle.