8 min de lecture - Notre stack open source : les choix d'architecture d'Exceev

Chaque décision de framework est un pari. Vous pariez que ce langage, ce runtime, cet ensemble de conventions aura encore du sens dans trois ans — quand la base de code sera dix fois plus volumineuse, quand la moitié de l'équipe aura changé, et quand les besoins auront dérivé vers un territoire que personne n'avait anticipé.

Nous nous sommes trompés sur certains de ces paris au fil des années. Mais la stack sur laquelle nous nous sommes arrêtés — TypeScript partout, Angular et NestJS en binôme, Next.js pour le contenu, Playwright et Jest pour les tests — a fait ses preuves sur des dizaines de projets clients et sur nos propres produits. Le bénéfice : moins de friction à l'onboarding, une sécurité de typage de la base de données jusqu'au navigateur, et des patterns qui se transposent d'un projet à l'autre sans devoir tout repenser. Cet article explique le raisonnement derrière chaque couche.

Le pari TypeScript

La décision la plus lourde de conséquences que nous ayons prise ne portait pas sur un framework. Elle portait sur un langage.

TypeScript tourne partout dans notre stack : frontend, backend, scripts de build, infrastructure as code, suites de tests. Cela peut sembler rigide, et ça l'est, honnêtement. Mais cette rigidité est rentable.

Quand une API NestJS retourne un ProjectResponse, le frontend Angular consomme exactement la même interface TypeScript. Modifiez un champ dans le DTO, et le compilateur hurle immédiatement chez tous les consommateurs — pas la QA trois semaines plus tard, pas un client qui remonte un bug. Dans un monorepo, cela suffit à éliminer des catégories entières de bugs d'intégration.

L'autre point crucial dans un cabinet de conseil : les gens changent de projet en permanence. Les périmètres évoluent, quelqu'un part en congé, une nouvelle mission démarre et a besoin de renfort. Quand tout le monde écrit du TypeScript, un ingénieur Angular peut relire une pull request NestJS sans changer de langage mental. Un profil backend peut passer sur le frontend et corriger un bug sans deux jours de montée en compétence. Un seul linter, un seul formatter, un seul test runner, un seul gestionnaire de paquets. Les réflexes se transmettent.

TypeScript est-il le meilleur langage pour toutes les tâches ? Non. Python l'emporte pour le ML. Go compile en binaires minuscules. Rust offre une sécurité mémoire dont nous ne pouvons que rêver. Nous y avons recours quand le projet l'exige. Mais 90 % de ce que nous construisons, ce sont des applications web, des API et de l'outillage — et pour cela, un langage unique bat une stack polyglotte à tous les coups.

La symétrie frontend-backend

Angular et NestJS n'ont pas été choisis indépendamment l'un de l'autre. Nous les avons retenus en binôme, parce qu'ils pensent le code de la même manière.

Les deux reposent sur des modules — les imports de composants standalone d'Angular et le système de modules de NestJS tracent les mêmes frontières autour des fonctionnalités. Les deux s'appuient sur des décorateurs — @Component, @Injectable, @Controller, @Guard — si bien que le modèle mental se transpose directement. Les deux sont prescriptifs sur l'emplacement des choses. Routes, services, guards, interceptors, pipes : chacun a sa place canonique. Un nouvel ingénieur peut naviguer dans la base de code dès le premier jour, sans visite guidée.

Ce parti pris est précisément l'intérêt. Quand nous créons un nouveau projet, personne ne débat de la structure des dossiers ni ne s'écharpe sur les conventions de nommage. Le framework a déjà tranché, et nous avons accepté de le suivre. Cela libère les discussions d'architecture pour ce qui compte vraiment.

Angular pour les interfaces produit

FormAI, notre générateur de formulaires propulsé par l'IA, tourne sur Angular. Tout comme SoarUI, notre système de design Angular interne. Angular est notre choix par défaut dès qu'il s'agit d'un état complexe, d'arbres de composants profonds, et d'un horizon de maintenance qui se compte en années.

L'évolution récente d'Angular rend ce choix plus facile à justifier. Les Signals apportent une réactivité fine sans avoir à greffer une bibliothèque de gestion d'état. Les composants standalone ont fait disparaître le boilerplate des NgModules qui alourdissait Angular. Et la trajectoire de mise à niveau d'Angular — politiques de dépréciation, schematics de migration, cadence de sortie prévisible — compte énormément quand on maintient des bases de code d'entreprise faites pour durer.

NestJS pour les API et les services

NestJS reproduit Angular côté serveur. Les controllers correspondent aux composants. Les services sont injectables. Les guards et les interceptors gèrent les préoccupations transversales. Si vous connaissez l'un, vous savez lire l'autre.

L'avantage concret : les code reviews gagnent en qualité. Un ingénieur frontend qui relit une PR backend en comprend déjà les patterns. Le vocabulaire partagé — modules, providers, guards, interceptors — évite d'avoir besoin d'un glossaire pour discuter architecture.

NestJS nous offre aussi une flexibilité de transport. La même logique de service fonctionne en HTTP, en WebSockets, en gRPC, ou via des files de messages. Quand un projet démarre comme une API REST et a besoin par la suite de fonctionnalités temps réel, nous ne repartons pas de zéro — nous ajoutons une couche de transport.

La place de Next.js

Oui, nous faisons tourner deux frameworks frontend. On nous pose souvent la question.

La répartition est simple : Next.js s'occupe du contenu, Angular des applications. Ce site, notre blog, les pages marketing — tout est en Next.js. Les priorités y sont le SEO, la génération statique, et la rédaction de contenu en MDX sans se battre avec le système de build. Next.js excelle à cela. Routing basé sur les fichiers, optimisation des images, SSR — c'est taillé exactement pour ce type de surface.

FormAI, SoarUI, les dashboards clients — c'est Angular. État complexe, interactions poussées, réutilisation de composants. Problème différent, outil différent.

Nous n'utilisons pas Next.js pour des applications. Nous n'utilisons pas Angular pour des sites de contenu. Le chevauchement est quasi nul, et le coût de maintenir deux frameworks reste faible comparé au coût de forcer un framework à faire un travail pour lequel il n'a pas été conçu.

Comment nous testons

Deux outils, une frontière nette entre les deux.

Jest couvre tout ce qui se situe en dessous du navigateur. Logique de service, fonctions utilitaires, endpoints d'API, requêtes en base de données, rendu de composants isolés. Pour Angular, nous l'associons à Angular Testing Library ; pour NestJS, au module de test de NestJS. Même API d'assertion, même approche de mocking, même configuration. Un ingénieur qui change de projet n'a pas besoin de réapprendre la suite de tests.

Playwright couvre tout ce qui se passe dans le navigateur. Nous avons abandonné Cypress il y a environ dix-huit mois, principalement parce que Cypress n'arrêtait pas de nous mentir — tests flaky, hacks cy.wait(2000) partout, et de vrais tests cross-browser quasiment impossibles. Playwright nous a donné Chromium, Firefox et WebKit depuis une seule suite, des auto-waits fiables, un support multi-onglets pour les flux OAuth, et des workers parallèles qui exécutent notre suite E2E en 3 minutes au lieu de 12.

La règle est stricte : Playwright teste les parcours utilisateur (authentification, soumission de données, workflows multi-étapes). Jest teste les unités et l'intégration. Nous ne laissons pas les deux empiéter l'un sur l'autre. C'est cette frontière qui garde les deux suites rapides et maintenables.

Pourquoi cela compte plus que n'importe quel choix isolé

Aucun de ces outils n'est objectivement la « meilleure » option de sa catégorie. Vous trouverez des benchmarks où un autre framework l'emporte, des articles de blog qui plaident pour un autre outil de test, et des raisons valables de choisir un autre langage. Nous le savons. Nous les avons lus.

Mais la valeur ne réside dans aucun outil pris isolément. Elle réside dans le fait qu'ils fonctionnent tous de la même manière. L'onboarding prend des jours au lieu de semaines, parce que les patterns sont déjà familiers. Un ingénieur d'un projet peut relire une PR sur un autre projet et repérer de vrais problèmes. Les bibliothèques partagées — validation, flux d'authentification, clients API, composants d'interface — circulent d'un projet à l'autre sans être réécrites. Quand quelque chose casse à 2 h du matin, la personne qui débogue sait déjà où regarder.

Cette cohérence est la décision d'architecture qui compte le plus chez Exceev. Pas de savoir quel framework est théoriquement le meilleur, mais quel ensemble de frameworks crée le plus de valeur une fois utilisé ensemble, sur des dizaines de projets, année après année.

Si vous évaluez votre propre stack — que vous lanciez un cabinet de conseil ou repensiez un existant — optimisez pour l'ensemble, pas pour chaque brique isolée. Le meilleur framework est celui que votre équipe sait utiliser correctement partout. Et si vous voulez un avis extérieur sur votre stack, nous serions ravis d'en discuter.