7 min de lecture - Stack Exceev : choix d'architecture et limites

Un choix de framework repose sur des hypothèses concernant le langage, le runtime et les conventions que l'équipe pourra maintenir à mesure que la base, les exigences et les responsabilités évoluent.

La stack décrite ici emploie TypeScript sur plusieurs couches, Angular et NestJS pour les applications, Next.js pour ce site de contenu, ainsi que Jest et Playwright à des niveaux de test différents. Cet article consigne le raisonnement et les limites de ce choix ; il ne formule pas une promesse de performance sur les projets clients.

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.

Lorsqu'une API NestJS et un client Angular importent le même ProjectResponse, une rupture TypeScript peut apparaître chez les consommateurs inclus dans la même vérification de types. Cela détecte tôt certains écarts de contrat. La validation au runtime et les tests d'intégration restent nécessaires, car TypeScript ne vérifie pas seul les données reçues sur le réseau.

Dans un cabinet de conseil, les équipes changent aussi de projet. Les périmètres évoluent, une personne part en congé ou une nouvelle mission demande du renfort. Un langage commun permet à un ingénieur Angular de lire une pull request NestJS sans devoir d'abord changer de langage. Des conventions communes de lint et de formatage réduisent aussi les écarts de configuration. Cela ne rend pas les métiers frontend et backend interchangeables : la connaissance du runtime et du projet reste nécessaire.

TypeScript est-il le meilleur langage pour toutes les tâches ? Non. Chaque langage répond à des runtimes, bibliothèques et contraintes d'exploitation différents. La majeure partie du travail décrit ici concerne des applications web, des API et de l'outillage. Dans ce périmètre, un langage commun peut réduire les changements de contexte, mais ce n'est pas un argument universel contre une stack polyglotte.

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 frameworks ne sont pas identiques, mais ils partagent des concepts utiles : injection de dépendances, décorateurs, services et frontières fonctionnelles explicites. Les composants standalone d'Angular déclarent leurs dépendances de template, tandis que les modules NestJS organisent providers et controllers. Ce vocabulaire commun peut faciliter les revues sans effacer les différences entre le navigateur et le serveur.

Ce parti pris devient utile lorsque l'équipe consigne ses conventions. Il réduit les débats répétés sur les dossiers et laisse davantage de temps à la revue des flux de données, des défaillances et des règles métier.

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.

Angular présente les Signals comme un mécanisme de suivi granulaire de l'état et recommande les composants standalone pour les nouveaux développements. Ces fonctions réduisent une partie du formalisme ; elles ne dispensent pas de choisir la responsabilité de l'état, les frontières ni le processus de mise à niveau.

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 documente les applications HTTP, les gateways WebSocket et plusieurs transports de microservices. Partager des services métier entre ces points d'entrée peut être utile, mais ajouter un transport exige toujours de concevoir le protocole, les erreurs, la sécurité et les tests.

La place de Next.js

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

Notre répartition est simple : Next.js porte ce site de contenu, tandis qu'Angular porte les produits interactifs décrits ici. Next.js fournit un routage par fichiers et des API de métadonnées adaptés au blog et aux pages marketing. C'est une convention d'équipe, pas une règle générale pour toutes les organisations.

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

Les deux frameworks ont malgré tout un coût de maintenance. Nous gardons donc leurs rôles explicites et examinons les exceptions au lieu de prétendre que le chevauchement est nul.

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 certains parcours navigateur. Sa documentation décrit des contrôles d'actionnabilité ainsi que la prise en charge de Chromium, Firefox et WebKit. Ces fonctions peuvent réduire une partie des attentes manuelles et élargir la couverture ; elles ne garantissent pas une suite stable. L'isolation, les données de test et le comportement de l'application restent déterminants.

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.

La valeur ne réside dans aucun outil pris isolément. Elle vient de conventions qui rendent le code et ses responsables plus faciles à trouver d'un projet à l'autre. La validation, les clients API et les composants peuvent réduire les réécritures lorsque leurs contrats correspondent réellement. Nous vérifions ce bénéfice en revue au lieu d'attribuer à la stack un délai universel d'intégration ou de livraison.

Chez Exceev, la cohérence est un critère d'architecture parmi l'adéquation au produit, la sécurité et l'exploitabilité. La bonne question n'est pas de savoir quel framework gagne dans l'absolu, mais si l'ensemble reste compréhensible et maintenable pour le travail à réaliser.

Sources primaires

• Guide des Signals Angular, consulté le 27 août 2026
• Migration Angular vers les composants standalone, consultée le 27 août 2026
• Documentation des modules NestJS, consultée le 27 août 2026
• Gateways WebSocket NestJS, consultées le 27 août 2026
• Métadonnées Next.js, consultées le 27 août 2026
• Navigateurs pris en charge par Playwright, consultés le 27 août 2026
• Contrôles d'actionnabilité Playwright, consultés le 27 août 2026

Si vous évaluez votre propre stack, examinez l'interaction des briques et les personnes capables de les exploiter. Un framework familier reste utile seulement s'il répond aussi aux contraintes du produit, du runtime et de la maintenance. Pour un avis extérieur, nous pouvons en discuter.