Partenaire technologique — Paris & New York
Le backend que votre prochaine équipe pourra reprendre sans tout réécrire — architecture imposée, typage strict, tests exécutables.
Réponse sous 24h.
NestJS est un framework backend Node.js écrit en TypeScript. Sa particularité n'est pas technique, elle est organisationnelle : là où Express vous laisse inventer votre propre structure, NestJS en impose une. Modules, contrôleurs, services, injection de dépendances. Deux développeurs qui n'ont jamais travaillé ensemble écrivent le même code, et un nouvel arrivant retrouve ses repères en une journée plutôt qu'en trois semaines.
Cette contrainte a un coût au démarrage et un rendement à partir du sixième mois. Sur un script jetable, elle est du poids mort. Sur un produit qui va vivre plusieurs années, changer d'équipe et accueillir des fonctionnalités que personne n'avait prévues, c'est ce qui fait la différence entre un backend qu'on fait évoluer et un backend qu'on finit par réécrire.
C'est pour cette raison que NestJS est notre choix par défaut dès qu'un projet mérite une API autonome : les plateformes SaaS, les ERP métier, tout ce dont dépendent des données que l'on ne peut pas perdre. C'est la stack qui fait tourner les backends d'Asicar et d'Inventozen.
La vraie question, sur un projet NestJS, n'est jamais « savez-vous écrire un contrôleur ». Elle est : où passent les frontières entre vos modules. Un découpage qui suit vos domaines métier rend chaque évolution locale ; un découpage calqué sur les couches techniques oblige à toucher huit fichiers pour ajouter un champ. Cette décision se prend la première semaine, elle ne se corrige pas ensuite sans un chantier.
Notre rôle est de prendre cette décision avec vous et de vous expliquer ce qu'elle implique en langage d'entrepreneur, pas en langage de framework : ce que vous pourrez faire vite plus tard, ce que vous ne pourrez plus faire sans y revenir, et ce que ça coûte de se tromper. Un prestataire qui exécute un cahier des charges ne vous dira pas que le cahier des charges est le problème.
Loïc Guillebeau, fondateur de Beyond The Brackets, développe depuis ses 14 ans et a cofondé Accelerio en 2021. Il a conçu et exploité des backends dont dépendaient des inscriptions payantes le jour même de l'événement, sans possibilité de corriger le lendemain. Les arbitrages d'architecture avec de l'argent réel en jeu, il les a faits pour lui avant de les faire pour vous.
Authentification, rôles et permissions, isolation des données entre clients, facturation par abonnement, quotas. Les gardes NestJS centralisent le contrôle d'accès au lieu de le disperser dans chaque contrôleur — c'est ce qui rend l'autorisation auditable plutôt que supposée.
Gestion de stock, de production, de facturation, de parc. Ces produits accumulent des règles particulières pendant des années : le découpage en modules permet d'ajouter un domaine sans déstabiliser ceux qui tournent déjà. C'est exactement ce que nous avons construit pour Asicar.
Un site web, une application mobile, un partenaire, un back-office. Le contrat d'interface est décrit une fois, la documentation OpenAPI est générée depuis le code, et elle ne dérive pas de l'implémentation puisqu'elle en est extraite.
Imports de fichiers volumineux, génération de documents, synchronisations nocturnes, envois d'e-mails en masse. NestJS intègre les files d'attente et les tâches planifiées de façon native, avec reprise sur erreur — un traitement qui échoue en silence est pire qu'un traitement absent.
Une API Express qui a grossi sans structure, où chaque fonctionnalité prend plus de temps que la précédente. La migration se fait module par module, l'ancien et le nouveau cohabitant derrière la même URL, sans gel de la roadmap produit.
Un prestataire précédent parti sans passation, une équipe qui n'ose plus déployer. Nous commençons par un audit technique d'une journée : ce qui est sain, ce qui doit être réécrit, ce qui peut attendre — hiérarchisé et chiffré avant tout engagement.
Nous commençons par les domaines métier, pas par les endpoints. Quelles entités existent réellement dans votre activité, lesquelles doivent rester cohérentes entre elles, où passent les frontières. Les modules NestJS suivent ensuite ce découpage. Un module par domaine, des dépendances explicites entre eux : quand un module en appelle six autres, c'est le découpage qui est faux, et le framework le rend visible immédiatement.
Toute donnée qui entre dans le système est validée à la frontière, une fois, avec un schéma déclaré. Passé ce point, le code métier travaille sur des objets dont la forme est garantie et n'a plus à se défendre. Cela supprime la classe de bugs la plus banale des API — celle où une valeur inattendue traverse trois couches avant de provoquer une erreur incompréhensible en base.
L'autorisation est vérifiée côté serveur à chaque requête, dans des gardes réutilisables, jamais uniquement dans l'interface. Un contrôle d'accès qui n'existe que dans le front n'existe pas : il suffit d'ouvrir les outils de développement du navigateur pour s'en passer.
L'injection de dépendances de NestJS n'est pas une élégance d'architecte : c'est ce qui rend vos règles métier testables sans base de données ni API tierce. Nous couvrons les règles qui coûtent cher quand elles cassent — calculs de prix, droits d'accès, transitions d'état — et la chaîne d'intégration continue bloque la fusion si un test échoue.
Nous travaillons dans vos canaux : un Slack partagé, un point hebdomadaire, une préproduction accessible en permanence. Grace, notre pipeline multi-agents interne, absorbe une partie du travail répétitif — scaffolding de modules, revue de premier niveau, couverture de tests. Le code que vous recevez reste relu par un humain.
| Langage | TypeScript strict (Node.js LTS) |
|---|---|
| Architecture | Modules par domaine, injection de dépendances, gardes et intercepteurs |
| Données | PostgreSQL avec Prisma ou TypeORM, Redis pour le cache et les files |
| API | REST avec OpenAPI généré, GraphQL, WebSockets, microservices |
| Tests | Unitaires et end-to-end intégrés au framework |
| Hébergement | Conteneurs sur Scaleway, AWS ou votre cloud — selon vos contraintes de résidence des données |
| Délai d'une première API en production | 5 à 9 semaines selon le périmètre |
Express est une bibliothèque minimaliste : elle vous laisse tout décider, y compris la structure du projet. Sur un prototype, c'est un avantage. Sur un produit qui dure, chaque développeur invente sa propre organisation et le code perd sa logique commune en un an. NestJS impose modules, injection de dépendances et validation des entrées, et tourne d'ailleurs sur Express par défaut. Nous choisissons Express pour un service de quelques routes, NestJS dès qu'un produit doit être maintenu par plusieurs personnes dans le temps.
Une API métier avec authentification, gestion des droits, trois ou quatre domaines fonctionnels et une documentation exploitable se situe généralement entre 18 000 € et 50 000 €. Ce qui fait varier ce chiffre n'est pas le nombre de routes : c'est le nombre de domaines métier à modéliser et la complexité de vos règles d'autorisation — qui a le droit de voir quoi, dans quel état, à quel moment. Deux API avec le même nombre d'endpoints peuvent aller du simple au triple sur ce seul critère. Notre simulateur donne une première fourchette en une minute, une journée de cadrage donne un chiffre sur lequel on peut s'engager.
Pas toujours, et c'est souvent la première économie que nous vous faisons faire. Les Route Handlers de Next.js suffisent tant que le backend ne sert que cette application. Une API NestJS autonome devient justifiée quand plusieurs clients la consomment — une application mobile, un partenaire, un outil interne —, quand le métier évolue à un rythme différent du front, ou quand des traitements longs doivent tourner hors du cycle de requête.
Oui, et c'est la façon dont nous procédons. NestJS s'exécute sur Express : les deux cohabitent derrière la même URL pendant la migration. On déplace un domaine à la fois, en commençant par celui qui coûte le plus cher à faire évoluer aujourd'hui, et on vérifie à chaque étape que le comportement n'a pas changé. Votre roadmap produit n'est pas gelée pendant l'opération — c'est la condition qui rend ce type de chantier acceptable pour une entreprise qui a des clients.
Techniquement oui, le framework gère nativement plusieurs modes de transport. Dans les faits, nous vous déconseillerons de commencer par des microservices : la quasi-totalité des jeunes produits n'en ont pas besoin et y gagnent surtout des pannes réseau et des données incohérentes. Un monolithe modulaire NestJS bien découpé vous donne les frontières claires sans le coût opérationnel, et il s'extrait en services le jour où une équipe ou une charge le justifie réellement.
Vous, intégralement : le dépôt, la documentation OpenAPI générée depuis le code, les scripts de migration de base de données et les accès d'infrastructure. Le test qui compte n'est pas la clause du contrat, c'est de vérifier qu'un développeur extérieur peut cloner le dépôt et faire tourner le projet en local en suivant le README. C'est la question à poser à n'importe quel prestataire, nous compris.
Là où vos contraintes l'exigent, et c'est un avantage pratique de NestJS : une application NestJS se déploie en conteneur, donc elle tourne aussi bien chez Scaleway ou OVH que chez AWS. Votre choix de framework ne vous enferme chez aucun hébergeur. Par défaut nous hébergeons en Europe sur des infrastructures conformes au RGPD ; si votre secteur impose une résidence des données précise, nous en parlons au cadrage et pas à l'audit. Les comptes d'infrastructure sont ouverts à votre nom.
30 minutes avec Loïc pour auditer votre situation technique et identifier votre plus grande opportunité. Sans engagement.
Réserver un appel stratégique