Stack technique Next.js et React
Des choix que votre équipe peut vérifier
Cette page s'adresse aux équipes techniques. Elle présente ma pile technologique : les outils que j'utilise sur chaque projet, la raison de chaque choix et ce qu'il vous garantit une fois le code entre vos mains.
Tout ce qui suit est versionné dans le dépôt du projet : configuration, règles, tests et portes qualité. Rien ne dépend de ma mémoire ni d'un service que vous ne contrôlez pas. Ce site repose sur cette même base.
Le socle
Next.js et React
- Next.js 16 et React 19, avec le React Compiler : l'optimisation des rendus est faite à la compilation, pas à la main.
- Composants serveur par défaut : le navigateur ne reçoit du JavaScript que pour les parties interactives.
- TypeScript en mode strict et routes typées : un lien vers une page qui n'existe pas empêche la compilation.
- Configuration validée : une variable d'environnement manquante fait échouer le build, pas la production.
Interface et contenu
- Tailwind CSS 4, configuré en CSS : les jetons de design sont définis à un seul endroit.
- Composants bâtis sur Base UI, selon les conventions shadcn : clavier, focus et ARIA reposent sur des primitives éprouvées, habillées à votre image.
- Internationalisation avec next-intl : textes typés, et un test échoue si deux langues ne sont plus synchronisées.
- Contenu dans un CMS headless (Sanity, Contentful ou Payload) ou en MDX, avec des types générés que l'intégration continue vérifie.
Des portes qualité qui bloquent vraiment
Chaque modification passe la même série de vérifications, sur mon poste puis en intégration continue. Une vérification qui se contente d'avertir finit ignorée : ici, chacune bloque la fusion.
- Biome : formatage, ordre des imports et règles de correction, en une passe rapide.
- react-doctor : les erreurs propres à React (hooks, effets pendant le rendu, rendus inutiles), qu'un linter généraliste ne voit pas.
- TypeScript : vérification complète des types.
- knip : les fichiers, exports et dépendances que plus rien n'utilise. Le code mort ne s'accumule pas.
- Vitest et Playwright : tests unitaires, tests de composants dans un vrai navigateur et parcours de bout en bout.
- Le build de production lui-même.
Les outils qui jugent le code sont figés à une version exacte : de nouvelles règles arrivent par une mise à jour décidée, jamais du jour au lendemain. Ce que vous y gagnez : une base de code qui reste saine après la livraison, parce que les garde-fous restent dans le dépôt.
Tests et accessibilité
Tester ce que l'utilisateur fait
- Un test ne prouve quelque chose que s'il traduit une exigence réelle.
- Les parcours critiques sont joués de bout en bout, dans un vrai navigateur, sur le build qui sera déployé.
- Chaque comportement est prouvé une seule fois, au niveau le plus simple qui suffit.
- La correction d'un bogue commence par sa reproduction, telle que l'utilisateur la vit.
L'accessibilité vérifiée, pas supposée
- Analyse automatisée avec axe-core et Playwright, sur mobile et sur ordinateur.
- Vérification manuelle : les outils automatisés ne détectent qu'une partie des défauts.
- Contrastes vérifiés dès les jetons de design.
- Pour une conformité WCAG 2.2 ou SGQRI 008 3.0 attestée : audit d'accessibilité.
Des dépendances sous contrôle
Un projet web repose sur des centaines de paquets tiers. Ce site, pourtant simple, en compte 597, et chacun est une porte d'entrée possible. Chaque projet applique donc la même politique, vérifiée à chaque installation, sur mon poste comme en intégration continue :
- Une version publiée depuis moins de 24 heures est refusée : c'est la période où une version compromise circule avant d'être retirée.
- Une baisse du niveau de confiance d'une publication bloque l'installation, signe possible de prise de contrôle d'un paquet.
- Seuls les paquets autorisés un par un peuvent exécuter du code à l'installation.
- pnpm est le seul gestionnaire accepté : npm et yarn, qui ignoreraient ces règles, sont refusés.
- Les versions installées sont figées en intégration continue, et les actions GitHub sont épinglées à une révision précise, mises à jour par Dependabot.
L'IA encadrée par un système que j'ai conçu
J'utilise Claude Code au quotidien. Ce qui rend son travail fiable, c'est le cadre qu'il suit, et ce cadre est versionné dans le dépôt, comme le code.
- Des règles par projet : architecture, tests, Next.js, Tailwind. Chaque règle se charge seulement quand l'agent touche les fichiers concernés.
- La documentation de la version installée : l'agent consulte la documentation livrée avec la version de Next.js du projet, pas ses souvenirs d'une version antérieure.
- Des garde-fous automatiques : à la fin de chaque intervention de l'agent, une analyse React le bloque tant qu'un défaut subsiste.
- Une revue indépendante : avant chaque envoi, un agent distinct de celui qui a écrit le code relit la modification et relance les vérifications.
- Aucun passe-droit : le code produit avec l'IA passe exactement les mêmes portes qualité.
- Les décisions restent humaines : fusionner et déployer demandent toujours ma validation explicite.
Cet outillage s'installe dans un projet en une commande et se met à jour de la même façon. Vous récupérez un dépôt qui porte ses propres règles : votre équipe, et vos propres agents, travaillent avec les mêmes garde-fous.
En production
Hébergement et performance
- Déploiement sur Vercel, avec la même version de Node.js en local, en intégration continue et en production.
- Images optimisées et polices hébergées sur le site : aucune requête vers un domaine tiers sur giov.io.
- En-têtes de sécurité définis dans le code et testés.
Suivi et mesure
- Suivi des erreurs et des performances réelles avec Sentry.
- Mesure d'audience choisie selon vos besoins : Vercel Web Analytics ou PostHog.
- Une version Markdown de chaque page et un fichier llms.txt, pour les moteurs de réponse IA.
Mesuré, pas promis
Sur un produit à fort trafic
Sur un produit grand public à fort trafic (plus d'un million de pages chargées en 90 jours), suivi avec Sentry auprès des vrais utilisateurs, au 75e centile, en septembre 2026 :
- 1,7 s pour afficher le contenu principal (LCP) sur 7 jours, sous le seuil de 2,5 s de Google.
- 72 ms de réactivité aux interactions (INP) sur 30 jours, pour un seuil de 200 ms.
- 308 ms avant le premier octet (TTFB) sur 7 jours, contre 381 ms sur 90 jours.
Sur ce site
Mesures Lighthouse de giov.io le 27 septembre 2026, profil mobile simulé, médiane de trois passages :
- 97 en performance, 100 en accessibilité, 100 en bonnes pratiques, 100 en référencement.
- 100 dans les quatre catégories sur ordinateur.
- 0 requête vers un domaine tiers.
- 0 erreur détectée par axe-core (WCAG 2.2 A et AA) sur les pages principales, sur mobile comme sur ordinateur.
Vérifiez vous-même : PageSpeed Insights (nouvel onglet).
Pour un client
Un site complet avec CMS headless, livré en deux semaines sur cette même base.
Jusqu'au framework
En 2026, j'ai isolé une fuite mémoire du serveur Next.js 16.3, d'environ 2 Mio par requête, avec une reproduction minimale et des mesures répétables. Le correctif est livré depuis la version 16.3.5.
Pour aller plus loin
Développement
Conception et développement de sites et d'applications web avec Next.js et React : rapides, bien référencés et accessibles dès la conception.
Audit
Définition du référentiel à suivre et audit de votre projet avant ou après sa mise en production, suivi de la création d'un rapport détaillant les points à corriger selon leur niveau de priorité.
