Retour sur l’évènement NG Baguette Angular Moderne 2026

NG Baguette Angular 2026 a une nouvelle fois réuni la communauté Angular francophone autour des dernières innovations, bonnes pratiques et retours d’expérience du développement web moderne.

Présents pour partager, apprendre et nous inspirer des retours d’expérience de la communauté Angular, nous avons eu l’opportunité d’assister à des conférences enrichissantes.

Un grand merci aux organisateurs d’Angular Devs France pour cette édition ainsi qu’à l’ensemble des speakers pour la qualité de leurs interventions et leur partage d’expérience.

AI-Assisted TDD in Angular

Le piège du « Vibe-Coding »

Quand il s’agit d’intégrer l’IA dans nos lignes de code, le piège est de basculer d’un extrême à l’autre : le rejet total ou la confiance aveugle. L’utilisation non encadrée d’agents IA crée rapidement une illusion de productivité : fatigue de relecture, dérive des spécifications et coûts qui explosent lorsque l’IA part dans la mauvaise direction.

La Solution : Le « Charted Coding »

Cette approche propose de conserver le développeur au centre du processus grâce à un flux de travail TDD strictement contrôlé et guidé par l’humain.
Le principe est simple : le premier livrable n’est pas le code mais une spécification Markdown stricte et approuvée par les humains.

L’IA accompagne ensuite le développeur à travers plusieurs étapes.

En résumé, l’objectif n’est pas d’automatiser les décisions d’architecture mais de préserver le modèle mental du développeur tout en bénéficiant de la vitesse d’exécution de l’IA.

Ressources

📘 Cookbook (recettes techniques détaillées)
🗂️ Slides : Pragmatic-angular-testing
👤 Speaker : Younes Jaadi

Signal Forms

Le problème : Reactive Forms ne séparent pas nativement le Form Model du Domain Model

Les Reactive Forms peinent à s’intégrer dans le paradigme Signal-first d’Angular : verbosité excessive, typage strict absent par défaut. Mais le vrai enjeu architectural est ailleurs, il est dans la couche de conversion entre le Form Model et le Domain Model.

• Form Model : comment l’UI suit et représente la donnée.
• Domain Model : ce que la logique métier attend.

Sans une séparation stricte entre ces deux modèles, les responsabilités de présentation et de métier s’imbriquent, ce qui rend le code beaucoup plus complexe à comprendre et à maintenir.

La solution : Signal Forms

Les nouvelles APIs de formulaires réactifs réduisent fortement le boilerplate. L’état du formulaire est directement piloté par un Signal : synchronisation automatique et typage strict de bout en bout. Cette approche facilite la gestion propre de la couche de conversion entre Form Model et Domain Model, sans laisser les contraintes de l’UI contaminer la logique métier.

En résumé

Signal Forms propose une alternative orientée Signals aux Reactive Forms, réduit le besoin de synchronisation manuelle avec RxJS, et impose une séparation nette entre la représentation UI de la donnée et ce qu’attend réellement la logique métier.

Ressources

📘 Slides officielles
🗂️ Articles
👤 Speaker : Manfred Steyer

Zoneless

Zone.js intercepte toutes les opérations asynchrones pour déclencher la détection de changements mais à un coût élevé : cycles de détection inutiles au moindre événement, stack traces illisibles, bundle alourdi, et frictions récurrentes avec async/await.

La solution : Zoneless Change Detection

Sans Zone.js, la détection de changements devient ultra-ciblée : seuls les Signals et les marquages manuels déclenchent une mise à jour du DOM. La migration se fait en 4 étapes :

1. Remplacer le provider : provideZoneChangeDetection() → provideZonelessChangeDetection()
2. Nettoyer angular.json : supprimer la référence à zone.js
3. Retirer les imports : zone.js et zone.js/test dans le code
4. Désinstaller la dépendance : purger zone.js du projet

Ce qu’on y gagne

• Performance : détection des changements déclenchée uniquement lorsque nécessaire
• Bundle plus léger : temps de chargement et de démarrage réduits
• Stack traces propres : diagnostic plus précis
• Contrôle total : les mises à jour sont pilotées explicitement par le développeur et les Signals

En résumé

Zoneless, c’est passer d’une détection de changements globale et aveugle à une réactivité chirurgicale pilotée par les Signals pour plus de contrôle.

Ressources

📘 Article
🗂️ Documentation
👤 Speaker : Brygida Fiejdasz

Harness Testing en Angular

Le problème : des tests couplés au DOM

Utiliser les sélecteurs DOM (querySelector, By.css, …) dans les tests unitaires Angular est une fausse bonne idée. Certes, c’est rapide au début, mais cela crée un couplage fort avec le DOM. Résultat ? La moindre modification HTML casse vos tests, même si la logique métier reste intacte. Mieux vaut privilégier l’abstraction pour garantir la maintenabilité à long terme.

La solution : Component Test Harnesses

Tester le comportement plutôt que le DOM : les Component Test Harnesses fournissent une API métier qui rend les tests Angular plus stables et plus faciles à maintenir.

1. Réduction du couplage avec le DOM : les changements de structure HTML n’impactent plus systématiquement les tests.
2. Meilleure lisibilité : les scénarios de test décrivent des intentions fonctionnelles plutôt que des détails d’implémentation.
3. Maintenance simplifiée : lorsqu’un composant évolue, les adaptations sont centralisées dans le harness plutôt que dispersées dans l’ensemble de la suite de tests.
4. Réutilisation accrue : plusieurs tests peuvent s’appuyer sur le même harness, favorisant la cohérence et limitant la duplication de code.

En résumé

Les Component Test Harnesses découplent les tests de la structure HTML, améliorant leur stabilité et leur maintenabilité, tout en offrant une API orientée métier plutôt qu’une dépendance aux détails du DOM.

Ressources

📘 Angular CDK Component Harness Documentation
👤 Speaker : Ezéchiel Amen AGBLA

Angular Resources

Le problème : Trop de complexité pour des besoins simples

RxJS est puissant, mais souvent trop complexe pour un simple chargement de données : opérateurs, souscriptions et synchronisation avec les Signals alourdissent le code.

La solution : Angular Resources

Les Angular Resources introduisent une approche plus déclarative pour gérer les opérations asynchrones, en les intégrant directement dans le modèle basé sur les Signals.

Trois avantages clés:

1. Réduction du code d’orchestration : une resource() suffit pour gérer un cas de chargement simple, sans composition d’opérateurs RxJS.
2. Gestion native des états : les états de chargement, de succès et d’erreur sont exposés de manière standardisée et directement exploitables dans le template.
3. Réactivité intégrée : les dépendances en Signals déclenchent automatiquement les rechargements, sans logique supplémentaire de souscription ou de coordination.

En résumé

Angular Resources apporte une API plus simple et plus intégrée au modèle Signals pour les cas courants de récupération de données.

Ressources :

🗂️ Documentation
📘 Article
👤 Speaker : Alain Chautard

NGRX SignalStore

Le problème : les Signals locaux ne suffisent pas à l’échelle entreprise

Les Signals locaux gèrent bien l’état d’un composant, mais dans une app enterprise, ils montrent vite leurs limites : duplication de logique, absence de conventions partagées, difficulté à maintenir une cohérence globale entre données serveur, cache client et état UI.

La solution : NgRx SignalStore

NgRx SignalStore s’impose comme le pont idéal entre état serveur et état client, en séparant clairement lecture et écriture :
• État serveur : accès direct aux ressources HTTP, sans intermédiaire.
• État client : indirection intentionnelle pour piloter le comportement de l’UI.

Avec un support natif des patterns Command et Event, NgRx SignalStore permet à chaque équipe de choisir le bon outil pour chaque mutation d’état sans compromettre l’architecture globale.

En résumé

NgRx SignalStore comble le fossé entre la réactivité locale des Signals et les exigences d’une architecture enterprise sans la verbosité du NgRx Store classique.

Ressources :

🗂️Documentation
📘 Article
👤 Speaker : Alex Okrushko

Modern Angular Architecture

Le problème : Le pattern « Smart vs. Dumb » à l’épreuve des architectures modernes

Longtemps incontournable, le pattern Container/Presenter a montré ses limites avec la montée en complexité des applications frontend. Les arbres de composants profonds, le passage intensif de propriétés et la prolifération des événements produisent des architectures fragiles et coûteuses à maintenir.

Le vrai défi du passage à l’échelle n’est pas la structure de dossiers, c’est la maîtrise du flux de données.

La solution

Trois ruptures mises en avant :

1. Standalone Components : fin des NgModules
2. Encapsulation de l’état avec les Signals : chaque composant définit de façon autonome la tranche de données dont il a besoin, sans dépendre d’un composant parent pour la délégation.
3. Inspiration cross-framework : Intégrer les meilleures pratiques (inspirées de React, Vue ou Svelte) pour offrir un modèle de composition plus moderne, tout en respectant la philosophie et la rigueur d’Angular.

En résumé

Angular invite à réévaluer certaines architectures adoptées pour pallier des limitations désormais disparues. Le flux de données peut ainsi retrouver sa simplicité.

Ressources

🗂️ Documentation
📘 Vidéo
👤 Speaker : Rainer Hahnekamp

Implémenter un Design System au-dessus d’Angular Material

Le problème : le piège du « tout from scratch »

Construire un Design System d’entreprise hautement personnalisé ne nécessite pas de réécrire les primitives UI accessibles from scratch. Pourtant, face aux limites des solutions clés en main sur une architecture multi-équipes avec micro-frontends, le réflexe est souvent de tout recréer au prix d’un effort considérable.

La solution : une surcouche sur Angular Material

La stratégie la plus efficace reste de surcharger et construire directement sur Angular Material, en s’appuyant sur l’Angular CDK et les fondations ARIA. La conformité aux standards d’accessibilité est intégrée nativement, tout en conservant un contrôle visuel total.

C’est exactement l’approche du Criteo Design System :

1. Surcharge propre des styles : écraser la charte graphique de Material sans casser son fonctionnement interne.
2. Micro-frontends : le Design System comme ciment de la plateforme, pour une expérience invisible pour l’utilisateur final.
3. Optimisation des performances : gestion fine du CSS, du thémage et du lazy loading pour ne pas alourdir les bundles.

En résumé

Inutile de repartir de zéro. S’appuyer sur Angular Material comme fondation solide, c’est le meilleur équilibre entre cohérence, accessibilité garantie et identité de marque.

Ressources

🗂️ Documentation
📘 Article
👤 Speaker : Sylvain Dedieu

Code Type-Safe

Le problème : le typage manuel, source de bugs runtime

Définir ou dupliquer les types manuellement à plusieurs endroits crée une dette de maintenance silencieuse : si la source change, la propagation est manuelle et faillible.
Un typage trop lâche prive TypeScript de sa capacité de protection, et les erreurs de structure explosent directement en production.

La solution : la dérivation de types

Faire travailler le compilateur à notre place en dérivant les types complexes depuis une source de vérité unique. TypeScript devient un garde-fou actif dès la compilation, rendant les APIs littéralement impossibles à mal utiliser.

Trois techniques illustrées par des cas concrets :
1. Outils natifs : combiner Mapped Types, Conditional Types et infer pour extraire ou transformer la structure d’un type existant.
2. Signal Forms typées : dériver automatiquement le type des Signals d’un formulaire depuis l’interface du modèle de données, garantissant un typage strict de bout en bout.
3. Utilitaire de mutation RxJS : une signature qui calcule dynamiquement ses types de retour et ses états d’erreur en fonction des observables passés en entrée.

En résumé

Un bon type TypeScript ne se déclare pas, il se dérive. Moins de duplication, plus de sécurité et un compilateur qui détecte les erreurs avant l’utilisateur.

Ressources

🗂️ Slides
📘 Article
👤 Speaker : Romain Geffrault