Démarrer un nouveau projet Angular

Avant de démarrer le développement d’une nouvelle application Angular il est important de prendre le temps pour se poser les questions techniques nécessaires afin de prendre les bonnes décisions fondamentales et donc de pouvoir intégrer dès le démarrage du nouveau projet les bonnes bases d’architecture et de configuration pour votre projet web. Vous trouverez ci-dessous une checklist des différentes options possibles lors du lancement d’un nouveau projet en entreprise.

• Workspace: Il faut premièrement se poser la question de quel outil utiliser pour générer le noyau de l’application. Dans la plupart des cas il est recommandé d’utiliser Angular CLI car la configuration et les mises à jour seront presque automatiques. Cependant il est aussi possible d’utiliser Nx pour créer un monorepository de différents projets et librairies Angular. Il existe aussi d’autres alternatives moins connues comme ngx-rocket, wizdm, jhipster…
• Angular config: Angular permet de configurer précisément les règles de compilation afin de sécuriser le code contre les erreurs. Les nouveaux projets sont créés en mode strict par défaut (strictTemplates, strictInjectionParameters, strictInputAccessModifiers), si vous travaillez sur un projet plus ancien nous vous recommandons de regarder en détail ces règles dans la documentation officielle : Angular compiler options.
• Typescript config: Le flag strict du compilateur TypeScript, activé par défaut dans les nouveaux projets Angular, active toutes les règles de vérification de typage strict telles que noImplicitAny, noImplicitThis, alwaysStrict, strictBindCallApply, strictNullChecks, strictFunctionTypes, strictPropertyInitialization et useUnknownInCatchVariables. Plus de détails dans la documentation officielle : TypeScript compiler options. Afin de garder votre base de code propre, il est également recommandé d'activer noUnusedLocals et noUnusedParameters.
• Rules: Les règles de formatage structurent le visuel de votre code, par exemple le nombre de caractères par ligne, tandis que les règles de qualité du code imposent l’utilisation des meilleures pratiques de codage. L'approche recommandée consiste à utiliser Prettier pour le formatage du code et à laisser ESLint avec angular-eslint (installé avec ng add angular-eslint) s'occuper de la qualité du code. TSLint et Codelyzer sont obsolètes : si un projet existant les utilise encore, migrez-le vers ESLint.
• Tooling: Dans une entreprise il est important de mettre en place certains outils afin d’industrialiser sa façon de travailler et d’automatiser au maximum les tâches répétitives. C’est pourquoi nous recommandons de mettre en place un hook pour chaque git commit (par exemple avec Husky et lint-staged), un outil de monitoring type Sentry, un système d’intégration et de déploiement continus CI/CD et pourquoi pas également Storybook afin de pouvoir partager avec votre équipe vos composants communs.
• UI css: Lors de l’initialisation du projet vous devez également savoir quel type de langage de style vous souhaitez utiliser, en effet pour un petit projet ou un site web il est encore possible d’utiliser le langage CSS natif mais pour un projet d’envergure il semble plus adapté d’utiliser un outil de préprocesseur tels que SASS ou LESS. Ces deux outils ont des fonctionnalités assez similaires, en bref ils permettent d’élargir les fonctionnalités de CSS (mixins, variables, nesting, inheritances, functions) cependant SASS est largement l’outil le plus utilisé aujourd’hui. Notez que le CSS natif supporte désormais les variables et le nesting, et que Tailwind CSS est une alternative utilitaire populaire supportée par Angular CLI.
• Util lib: Il existe des centaines de librairies third-party pour l’écosystème Angular, il n'y a pas besoin de toutes les utiliser cependant certaines sont bien utiles, nous recommandons de visiter notre page concernant les librairies dans la partie ressources.
• UI lib: Concernant l’interface utilisateur il y a encore le choix, la librairie officielle Angular Material et son Component Dev Kit (CDK) fournissent déjà un ensemble de composants et de primitives UI. Cependant il existe une dizaine d’autres librairies UI plus complètes, nous recommandons de parcourir chacune d’entre-elles sur la page librairies depuis la section ressources.
• Store lib: La gestion de l’état de votre application est également très importante. Pour des besoins simples, des signaux Angular dans des services suffisent souvent, pour des applications plus grandes il est possible d’utiliser une librairie externe telle que NgRx (Store ou SignalStore) ou NGXS. Notez que Akita n’est plus maintenue.
• Translations lib: L’internationalisation de l’application est également à prévoir dès le démarrage du projet, à l’heure actuelle il existe trois solutions reconnues : le package officiel @angular/localize (avec la commande ng extract-i18n), Transloco ou ngx-translate. Nous recommandons Transloco pour ses fonctionnalités avancées faciles à utiliser, par exemple le lazy loading des traductions, tandis que la solution officielle offre les meilleures performances car les traductions sont compilées au build.
• Change detection: Historiquement la détection des changements reposait sur la librairie Zone.js, qui déclenche une détection après chaque événement asynchrone. La détection des changements zoneless, stable depuis Angular 20.2 et utilisée par défaut dans les nouveaux projets depuis Angular 21, la déclenche plutôt à partir des signaux, du pipe async et des événements du template, ce qui améliore les performances et facilite le débogage. Combinez-la avec la stratégie OnPush pour de meilleurs résultats.
• Rendu: Décidez dès le début si vous avez besoin du rendu côté serveur ou du pré-rendu avec @angular/ssr, par exemple pour le SEO ou les performances. Il peut être activé à la création du projet avec ng new --ssr.
• Build et tests: Les nouveaux projets utilisent le builder application basé sur esbuild avec un serveur de développement Vite, et Vitest est le lanceur de tests unitaires par défaut depuis Angular 21 (Karma est obsolète). Pour les tests end-to-end nous recommandons Playwright ou Cypress.
• Structure du routing: Tous les projets Angular utilisent le mécanisme de routing associé à une sortie principale (primary outlet). Cependant pour certaines interfaces utilisateur complexes comprenant plusieurs parties distinctes il peut être utile de configurer le routing pour avoir des sorties secondaires (secondary outlets).
• Structure de l'UI: De plus en fonction de la complexité de l'UI il est possible de gérer l’affichage des différents blocs de plusieurs manières : composants simples, embedded views, view teleportation (portals), blocs @defer...