Enterprise JavaScript : comment ne pas se noyer dans le code d'une entreprise géante

JavaScript d'un million de lignes : entrée dans le monde de l'entreprise

Avez-vous déjà vu un projet JavaScript qui pèse plus lourd que le système d'exploitation de votre ordinateur portable ? Bienvenue dans le développement d'entreprise. Ici, il n'y a pas de place pour « j'ai vite fait écrit sur un coin de table » et « ça marchera peut-être ». Ici, le code vit pendant des années, il est lu par des centaines de développeurs, et une erreur dans un seul package npm peut paralyser une banque entière.

Enterprise JavaScript ne concerne pas les frameworks (même si React ou Angular y sont aussi présents). Il s'agit de culture, de processus et d'architecture qui permettent de gérer le chaos. Si vous voulez comprendre ce qui différencie une startup d'une grande entreprise, ou si vous vous préparez à un entretien dans une grande société, cet article est pour vous. Nous allons décortiquer les principales caractéristiques du développement JavaScript dans un environnement d'entreprise, le tout étayé par des exemples de code réels.

Monorepo vs. multirepo : le choc des titans

Dans une startup, vous avez probablement un seul dépôt sur GitHub. Dans une grande entreprise, c'est plus complexe. Vous pouvez avoir 50 microservices, une bibliothèque de composants d'interface utilisateur commune, un package séparé pour les utilitaires et encore une dizaine de projets hérités en jQuery.

Pourquoi le monorepo l'emporte-t-il ?

Les grandes entreprises (Google, Facebook, Microsoft) utilisent le monorepo. Un seul dépôt qui contient tout le code de l'entreprise. Cela simplifie le refactoring : vous modifiez une API à un seul endroit et tous les projets intègrent les changements. Mais il y a un hic : des outils comme Lerna, Nx ou Turborepo deviennent indispensables.

Exemple de structure de monorepo avec npm workspaces :

// package.json (racine)\n{\n  "name": "enterprise-monorepo",\n  "private": true,\n  "workspaces": [\n    "packages/*"\n  ],\n  "scripts": {\n    "build": "npm run build --workspaces",\n    "test": "npm run test --workspaces"\n  }\n}

Vous avez maintenant un dossier packages/ qui contient des packages individuels (par exemple, ui-kit, api-client, core). Chaque package a son propre package.json, mais les dépendances sont installées une seule fois à la racine.

Conseil : Dans une grande entreprise, n'utilisez jamais npm link manuellement. Utilisez uniquement les outils de monorepo, sinon vous risquez de vous retrouver avec un « enfer des dépendances ».

TypeScript — pas un luxe, mais une nécessité

Beaucoup pensent : « Pourquoi TypeScript, si j'écris déjà sans erreurs ? ». Dans une grande entreprise, c'est strict. Lorsque votre base de code compte 500 000 lignes et que votre équipe est composée de 30 personnes, le typage dynamique devient une source de bugs qui peuvent passer en production.

TypeScript permet de :

\n
• Créer des contrats clairs entre les modules (via des interfaces).
\n
• Simplifier le refactoring (l'IDE vous indiquera ce qui est cassé).
\n
• Réduire le nombre d'erreurs d'exécution.
\n

Exemple de la façon dont un projet d'entreprise utilise TypeScript pour décrire une API :

// types/api.ts\nexport interface User {\n  id: string;\n  name: string;\n  email: string;\n  role: 'admin' | 'user' | 'moderator';\n}\n\nexport interface ApiResponse<T> {\n  data: T;\n  status: number;\n  message: string;\n}\n\n// services/userService.ts\nimport { User, ApiResponse } from '../types/api';\n\nexport async function getUser(id: string): Promise<ApiResponse<User>> {\n  const response = await fetch(`/api/users/${id}`);\n  return response.json();\n}

Notez que ApiResponse<T> est un générique. Il garantit que la réponse du serveur aura toujours une structure prévisible. Dans une grande entreprise, c'est la norme.

Architecture : couches, modules et inversion des dépendances

Dans une startup, vous pouvez mettre toute la logique dans un composant React. Dans une grande entreprise, cela mènerait à une catastrophe. On utilise ici une architecture stricte :

\n
• Couche de présentation (UI) — Composants React/Vue/Angular qui ne font qu'afficher les données.
\n
• Couche applicative