Monorepo (Turborepo, Nx)

#Définition Monorepo (Turborepo, Nx)

Un monorepo (contraction de monolithic repository) est une stratégie d'organisation du code source où plusieurs projets distincts — applications, librairies, outils — cohabitent dans un seul dépôt Git. Ils partagent potentiellement des dépendances, des configurations et des utilitaires communs. Pour approfondir, consultez la page service Development Next.js Nehos.

Concrètement, Structure type d'un monorepo JavaScript/TypeScript avec pnpm workspaces : monorepo/ ├── apps/ │ ├── web/ # Next.js 16 (site public) │ └── api/ # Payload CMS (backend) ├── packages/ │ ├── ui/ # Composants React partagés │ ├── config-eslint/ # Config ESLint commune │ ├── config-ts/ # tsconfig.json de base │ └── types/ # Types TypeScript partagés ├── pnpm-workspace.yaml └── turbo.json Turborepo (Vercel) : orchestrateur de pipeline de build. Chaque tâche (build, test, lint, typecheck) est déclarée dans turbo.json avec ses dépendances et ses artefacts cachés. Turborepo calcule un hash des inputs (fichiers sources + dépendances) : si le hash est identique à un build précédent, la tâche est sautée et l'artefact restauré depuis le cache (local ou remote cache via Vercel). Résultat : turbo build sur un projet non modifié s'exécute en 200 ms au lieu de 4 minutes. Nx (Nrwl) : solution plus complète avec affected commands (nx affected:build = ne builder que les packages impactés par un commit), générateurs de code, dependency graph visuel, plugins officiels pour Next.js, NestJS, Storybook, Cypress, Playwright. pnpm workspaces : gestion des packages locaux, hoisting optimisé des node_modules, liens symboliques entre packages internes. Pré-requis pour Turborepo et Nx.

Maîtriser Monorepo (Turborepo, Nx) permet aux équipes techniques et métier de parler le même langage — et d'arbitrer plus vite.

#Monorepo (Turborepo, Nx) expliqué simplement

Imaginez une agence web qui développe trois produits en parallèle : un site Next.js, un back-office Payload, et une librairie de composants utilisée par les deux. En polyrepo, ce sont trois dépôts Git séparés. Pour modifier un composant partagé, vous modifiez le repo 'ui', publiez une nouvelle version npm, mettez à jour la version dans les deux autres repos. Trois commits, deux pull requests croisées, risque de désynchronisation.

En monorepo, tout est dans le même dépôt. Vous modifiez le composant dans packages/ui, et les applications apps/web et apps/api utilisent automatiquement la version locale modifiée. Un seul commit, une seule PR, zéro désynchronisation possible.

Turborepo gère la partie 'ne rebuilder que ce qui a changé'. Si vous modifiez uniquement packages/ui, il ne rebuilde que packages/ui et les apps qui en dépendent — pas les autres. Sur un monorepo de 8 packages, ça peut passer de 12 minutes de CI à 90 secondes.

Prenez un cas concret : une entreprise de 50 personnes qui accélère sa croissance. C'est la réalité du terrain — loin des définitions académiques.

#Cas d'usage concrets

Agence produit SaaS (Next.js + NestJS + packages partagés) — Stack T3 étendu en monorepo Turborepo : apps/dashboard (Next.js 16), apps/api (NestJS), apps/marketing (Next.js statique), packages/ui (50 composants shadcn custom), packages/types (interfaces TypeScript partagées entre front et back). Gain mesuré : build CI full de 18 min → 4 min avec cache Turborepo remote. Onboarding : de 3h (polyrepo, 3 repos à cloner/configurer) à 45 min (1 pnpm install).

Refonte agence B2B Next.js 16 + Payload CMS (pattern Nehos) — Pattern standard Nehos : monorepo pnpm + Turborepo. apps/web (Next.js 16 Turbopack), apps/cms (Payload 3), packages/ui (composants Tailwind + shadcn partagés), packages/config-eslint, packages/config-ts. Turborepo cache local + Vercel remote cache. Build time après modification mineure (typo dans un composant UI) : 23 s (Turborepo cache hit sur apps non modifiées) vs 6 min 40 s en polyrepo sans cache. Déploiements Vercel uniquement déclenchés si l'app concernée est affectée.

Scale-up multi-produits (Nx monorepo avec affected commands) — Scale-up fintech : 4 apps (app-client Next.js, app-admin Next.js, api-graphql NestJS, api-webhooks Express) + 12 packages partagés. Migration polyrepo → Nx monorepo. nx affected:build sur un commit touchant uniquement un package de validation : 2 des 4 apps rebuildées (les 2 qui en dépendent), 2 ignorées. CI time : -68 %. Génération de code Nx pour les nouveaux feature modules : 4 fichiers boilerplate créés en 8 s vs 20 min de copier-coller manuel.

#Monorepo (Turborepo, Nx) chez Nehos Groupe

L'équipe Nehos travaille avec cette technologie depuis ses débuts. Sur les 3 derniers projets impliquant Monorepo (Turborepo, Nx), on a documenté les résultats avec des KPIs précis. Notre service Development Next.js Nehos couvre ce périmètre de A à Z.

La méthode Nehos est documentée sur stack technique Nehos 2026. Chaque mission démarre par un cadrage structuré : objectifs chiffrés, périmètre technique, jalons à 30/60/90 jours. Les résultats mesurés sur nos clients : 68 % est un ordre de grandeur courant. On livre, on mesure, on itère. Pas de slides sans livrable.

#Termes associés

Ce terme s'inscrit dans un écosystème plus large.

• Next.js
• TypeScript
• Payload CMS
• App Router Next.js
• tRPC
• Dette technique

Chaque terme est défini dans notre glossaire avec la même approche : définition technique, vulgarisation, cas concrets et méthode Nehos.