Agence Next.js
Experts Next.js
App Router & Server Components
L'App Router est notre défaut depuis Next.js 13.4 — le Pages Router, c'est du legacy qu'on maintient mais qu'on ne démarre plus. Sur nos projets Next.js, on obtient des LCP en production parmi les meilleurs du marché. Server Components, ISR, Server Actions : on les utilise au quotidien, on connaît leurs forces et surtout leurs limites — notamment le caching qui peut vous mordre si vous ne maîtrisez pas les 4 niveaux.
Ils nous font confiance — 150+ projets livrés
L'écosystème Next.js qu'on utilise au quotidien
App Router avec Server Components et Server Actions par défaut, ISR avec on-demand revalidation via webhooks. Middleware pour l'auth et les redirections SEO (next-auth v5 / Auth.js). Prisma pour l'ORM, tRPC pour le typage end-to-end en monorepo. Tailwind CSS pour le styling. Vercel pour le DX imbattable (preview deployments, analytics, Speed Insights), Docker + OpenNext/SST pour le self-hosted AWS. Sentry pour le monitoring erreurs, Vercel Analytics pour les Web Vitals. next-intl pour l'i18n, next-sitemap pour le SEO technique.
App Router & Rendu
Data & Auth
Déploiement
+20 briques Next.js maîtrisées
Découvrez nos réalisations clients
Voir tous les cas clients ›
Compass Group
Conception et développement d'un cockpit data de pilotage P&L pour le leader mondial de la restauration collective (>40 pays).
Voir le cas client ›
BTP Consultants
Socle applicatif + logiciels métiers IA — réduction de 95 % des coûts de maintenance.
Voir le cas client ›
Kinnarps
Digitalisation du parcours de commande B2B pour un groupe international (1 800 collaborateurs, 40 pays).
Voir le cas client ›
Média Participations
Conduite de 5 projets de refonte SI structurants en 12 mois pour un groupe média de référence.
Voir le cas client ›96% de nos clients continuent avec nous
“La réactivité et l’implication dans nos projets sont un gros plus.”
Erwin LEGRAND, Directeur Marketing
“Très efficaces sur les développements et de précieux conseils.”
Simon TANNAI, Cofounder & CTO
Next.js : notre framework React de référence
On a évalué Remix, Astro et Nuxt avant de standardiser sur Next.js. Remix est élégant mais l'écosystème est trop petit et l'avenir incertain depuis le pivot vers React Router 7. Astro est parfait pour les sites de contenu, mais dès qu'il y a de l'interactivité lourde, on retrouve React derrière. Nuxt ? Excellent, mais on est une équipe React — et le marché de recrutement Vue en France est nettement plus étroit. Next.js n'est pas parfait : le caching App Router est complexe (4 niveaux qui interagissent entre eux), les Server Actions ont des limitations sur les fichiers et le streaming, et Vercel pousse fort vers son infra. Mais c'est le framework avec le meilleur ratio productivité/performance/écosystème aujourd'hui.
Concrètement, on utilise ISR pour les blogs, Server Components pour les pages statiques, middleware pour les redirections SEO et l'A/B testing. On déploie sur Vercel pour la majorité de nos clients (le DX est imbattable), et en self-hosted Docker pour les clients enterprise qui ont des contraintes RGPD ou d'hébergement souverain. Notre position sur le Pages Router : on ne démarre plus aucun projet avec, mais on maintient activement ceux qui y sont — migrer vers l'App Router se fait route par route, sans big bang.
Discutons de votre projet Next.js →Une méthodologie éprouvée en 5 phases
Compréhension utilisateur
Identification des problématiques de vos utilisateurs, de vos enjeux clés à travers l'écoute active et l'analyse de marché pour cadrer le projet.
1 à 3 semainesConception & Prototypage
Création de maquettes et prototypes interactifs, testés et améliorés grâce aux retours des utilisateurs.
2 à 4 semainesDéveloppement agile
Codage en sprints d'une semaine, permettant des ajustements flexibles basés sur des tests en conditions réelles.
6 à 12 semainesTests & améliorations
Assurer la qualité et la performance par des tests rigoureux en conditions réelles.
1 à 3 semainesItérations
Mise en production et itérations basées sur les retours, les datas et les évolutions du marché.
Ce qu’on met en production réalisés pour nos clients en Next.js
Nos équipes interviennent sur des problématiques Next.js à forte complexité technique, là où la plupart des agences atteignent leurs limites :
App Router & React Server Components
Nous accompagnons régulièrement des migrations de Pages Router vers App Router. Les gains sont significatifs : réduction notable du bundle client et amélioration mesurable du LCP. On utilise les parallel routes pour les modales (plus de hack avec l'URL state), les intercepting routes pour les previews, et les route groups pour organiser les layouts par section. Gotcha majeur : les Server Components dans l'App Router ne supportent pas les event handlers — il faut bien penser ses "use client" boundaries dès l'architecture. On a développé un pattern de "client islands" qui minimise le JavaScript client tout en gardant l'interactivité là où elle compte.
SEO natif & performances
Le SEO natif de Next.js est un vrai avantage concurrentiel — à condition de bien le configurer. On utilise la metadata API avec generateMetadata dynamique, generateStaticParams pour pré-rendre des milliers de pages, et sitemap.ts/robots.ts auto-générés. L'ISR avec on-demand revalidation via webhooks, c'est ce qui nous permet de servir du contenu statique ultra-rapide tout en le mettant à jour en temps réel quand le CMS change. Piège courant : le revalidatePath ne purge pas le Router Cache côté client — il faut combiner avec router.refresh() ou les revalidateTag pour une invalidation complète.
Data fetching & caching
Le caching Next.js, c'est 4 niveaux qui interagissent et qui peuvent vous rendre fou si vous ne les comprenez pas. Request Memoization (déduplique les fetch identiques dans un même render), Data Cache (persiste les résultats fetch entre les requêtes), Full Route Cache (pré-rend les pages statiques au build), Router Cache (cache les RSC payloads côté client pendant 30s pour les pages dynamiques, 5min pour les statiques). On a passé des semaines à debugger des cas où le contenu ne se mettait pas à jour — 9 fois sur 10, c'est le Router Cache qui gardait une version stale. On documente chaque couche de cache dans nos projets et on forme systématiquement les équipes client dessus.
Déploiement & infra
Vercel reste le chemin de moindre résistance — preview deployments automatiques, analytics intégrés, Edge Functions sans config. Pour nos clients enterprise qui ne peuvent pas héberger chez Vercel (RGPD, hébergement souverain), on déploie en Docker self-hosted avec le Standalone output : l'image passe de 1.2 Go à ~150 Mo. Sur AWS, on utilise SST v3 plutôt que CDK brut — le support OpenNext est natif et ça gère Lambda@Edge + CloudFront sans 200 lignes de config. Trade-off honnête : le self-hosted perd les Edge Functions Vercel et les analytics natifs. Pour les ISR, il faut configurer un cache externe (Redis ou S3) que Vercel gère nativement.
Vivez enfin une expérience client 5✦ sans risque et garantie
La croissance fulgurante d’une agence de développement web & mobile autofinancée
Voir la parution ›
Interview de Cyrille ADAM, Co-fondateur de Yield Studio, sur le développement de l’agence
Voir la parution ›
Si l’App Store a trop de concurrents, les utilisateurs risquent de se perdre
Voir la parution ›
Développement logiciel : les entreprises sont à la ramasse et ça coûte (très) cher
Voir la parution ›
Le pari réussi des développeurs séniors à l’ère de l’IA
Voir la parution ›Nos domaines d’intervention en développement Next.js
Création d'application Next.js
On démarre chaque projet Next.js avec un template interne battle-tested : App Router, Server Components par défaut, Zustand + React Query pour le state, middleware pour l'auth (next-auth v5 ou custom JWT), et i18n avec next-intl. On a livré des apps Next.js pour du e-commerce (ISR + Shopify), du SaaS multi-tenant (middleware + row-level security), et des dashboards data (Server Components + streaming). Le piège des débutants : mettre "use client" partout et transformer Next.js en SPA classique. On forme vos équipes à penser Server-first.
Migration vers Next.js
Gatsby a perdu du terrain face à Next.js — nous accompagnons régulièrement des migrations depuis Gatsby, CRA et des SPA Vite vers Next.js, notamment pour des clients qui ont besoin de SEO. L'ISR permet des gains de temps de build considérables par rapport aux approches full-SSG. La migration se fait route par route : les deux routeurs (Pages et App) coexistent pendant la transition. Le piège : les getServerSideProps ne se traduisent pas directement en Server Components — le modèle mental est différent, et il faut repenser le data fetching, pas juste copier-coller.
TMA & évolution Next.js
Les mises à jour majeures de Next.js arrivent tous les 6 mois, et chacune apporte son lot de breaking changes — surtout sur le caching et les conventions de fichiers. On gère la montée de version pour nos clients en TMA : on teste sur une branche dédiée, on vérifie les Core Web Vitals avant/après, et on déploie en canary. Le cas le plus fréquent qu'on traite : des apps Next.js dont le caching a été mal configuré et qui servent du contenu stale aux utilisateurs.
On optimise aussi les performances des apps existantes : remplacement des getServerSideProps par des Server Components (avec des gains de TTFB mesurables), migration du fetch vers des Server Actions pour les mutations, et mise en place de monitoring Web Vitals en production.
Questions fréquentes
Si votre app a besoin de SEO ou que la performance perçue est critique, la question ne se pose même plus : Next.js. Un SPA React classique envoie une page blanche au navigateur et attend que tout le JavaScript se charge pour afficher quoi que ce soit — Google indexe mal, les utilisateurs voient un spinner. Next.js résout ça avec le SSR, les Server Components et l'ISR, avec des gains de LCP significatifs par rapport à un SPA équivalent. Le seul cas où on reste sur un SPA pur : les apps internes sans enjeu SEO (back-office, dashboards internes) où la simplicité de Vite l'emporte. Mais même là, on commence à utiliser Next.js par défaut parce que le DX est devenu excellent.
App Router, sans hésitation. Le Pages Router est en mode maintenance — Vercel ne développe plus de nouvelles features dessus. L'App Router apporte les Server Components, les Server Actions, le streaming SSR, les parallel routes, les intercepting routes, et un système de layouts imbriqués qui élimine le prop drilling de _app.tsx. Est-ce que c'est plus complexe ? Oui, clairement. Le modèle mental est différent, le caching est plus subtil, et il faut penser "Server-first". Mais le gain en performance et en maintenabilité est réel. Pour les projets existants en Pages Router, on migre route par route — les deux coexistent dans la même app, ce qui permet une transition progressive sans interruption.
Le budget dépend de la complexité du projet. Site vitrine SEO-first avec CMS headless (Sanity ou Strapi) : à partir de 25k€ — mais honnêtement, si c'est juste un site vitrine sans app logique, WordPress ou Webflow sera plus économique. Application web métier (SaaS, dashboard, plateforme) : à partir de 80k€ selon le nombre de features et d'intégrations. E-commerce Next.js + Shopify/Stripe : à partir de 60k€. On livre un premier lot fonctionnel en 6 à 10 semaines, puis on itère. Le budget précis dépend de la complexité : on le détermine après un atelier de cadrage gratuit de 2h.
Next.js est probablement le meilleur framework pour le e-commerce performant aujourd'hui. L'ISR permet de pré-générer des milliers de pages produits et de les mettre à jour en temps réel quand le prix ou le stock change via un webhook. Les Server Components réduisent significativement le JS client sur les pages catalogue — et ça se traduit directement en taux de conversion. On a intégré Next.js avec Shopify (Hydrogen est une option, mais Next.js est plus flexible), Stripe, Algolia et des PIM via GraphQL. Attention au piège du panier : le Router Cache peut servir un prix stale si on ne configure pas correctement le revalidateTag. Cette approche permet d'obtenir des scores Lighthouse élevés et des gains de conversion mesurables.
On va être transparents sur les trade-offs. Vercel : le meilleur DX du marché, preview deployments en 30s, analytics et Speed Insights inclus. Coût : plan Pro à 20$/mois/membre, mais les coûts de bandwidth et de serverless functions peuvent monter vite sur du fort trafic. AWS via SST/OpenNext : plus complexe à setup (comptez 2-3 jours de config), mais vous contrôlez tout et les coûts sont prévisibles. Docker self-hosted : le Standalone output génère une image légère, déployable n'importe où. Vous perdez les Edge Functions et les analytics Vercel, et il faut gérer le cache ISR vous-même (Redis ou S3). Notre recommandation : Vercel par défaut, AWS pour le fort trafic ou les contraintes de coût, Docker pour le souverain/RGPD strict.
Next.js donne un avantage SEO structurel que les SPA ne pourront jamais rattraper. Les Server Components envoient du HTML complet au crawler — pas besoin de rendering JavaScript côté Google. On configure systématiquement : metadata API avec generateMetadata dynamique par page, generateStaticParams pour le pré-rendu des pages catalogue/blog, sitemap.ts et robots.ts auto-générés, composant Image avec formats WebP/AVIF automatiques, et données structurées JSON-LD pour les rich snippets. Le piège SEO le plus courant qu'on corrige : les pages dynamiques sans generateStaticParams qui sont rendues à la volée et jamais mises en cache — Google les indexe, mais le LCP est mauvais et le ranking en souffre. On met en place un monitoring Core Web Vitals en production (via Vercel Analytics ou web-vitals + notre dashboard custom) pour détecter les régressions SEO avant qu'elles n'impactent le ranking.
Échangeons sur votre projet !
30 minutes, gratuit, sans engagement.
Nous contacterAppel de 30 min → Audit gratuit → Proposition sous 5 jours
