Une interface IA ne fonctionne pas comme un CRUD classique
Une réponse IA peut prendre plusieurs secondes, être progressive, échouer partiellement ou nécessiter une validation humaine. L’interface doit représenter ces états explicitement.
Afficher uniquement un spinner jusqu’à la réponse finale donne une expérience pauvre et rend le diagnostic difficile.
Le frontend doit pouvoir distinguer préparation, appel modèle, génération, validation, erreur et annulation.
Signals et RxJS ont des rôles complémentaires
Les Signals sont très efficaces pour représenter l’état local d’un composant ou d’un écran : résultat courant, statut, filtres, sélection ou visibilité.
RxJS reste particulièrement adapté aux flux asynchrones, aux événements continus, aux recherches avec debounce et aux combinaisons de sources.
Dans une application IA, les deux peuvent cohabiter : RxJS pour orchestrer les flux et Signals pour exposer un état simple au template.
Gérer le streaming SSE ou WebSocket
Pour les réponses progressives, SSE est souvent suffisant lorsque le serveur pousse un flux unidirectionnel vers le navigateur. WebSocket devient utile lorsque les échanges doivent être bidirectionnels et persistants.
Le composant Angular ne devrait pas manipuler directement les détails du transport. Un service dédié doit transformer les événements techniques en événements métier.
Cette abstraction permet ensuite de changer de protocole ou de gérer la reconnexion sans contaminer toute l’interface.
Toujours rendre visibles la source et la confiance
Lorsqu’une réponse provient d’un RAG ou d’un agent, l’utilisateur doit pouvoir comprendre d’où viennent les informations importantes.
Le frontend peut afficher les documents cités, le niveau de confiance, les actions exécutées par l’agent et les points nécessitant une validation.
Cette transparence améliore la confiance et réduit le risque que l’utilisateur traite une génération comme une vérité absolue.
Ne jamais faire confiance au frontend pour la sécurité
Masquer un bouton ou une donnée dans Angular n’est pas une règle de sécurité. Les permissions doivent toujours être vérifiées côté backend.
Le frontend peut utiliser les rôles pour améliorer l’expérience utilisateur, mais chaque API exposant des données ou déclenchant une action doit refaire les contrôles.
Cette règle est encore plus importante lorsque l’interface permet de déclencher des actions d’agents IA.
Structurer le frontend par domaine
Une architecture Angular durable évite un unique dossier components contenant toute l’application. Les fonctionnalités doivent être regroupées par domaine métier.
Chaque domaine peut exposer ses pages, composants, services, modèles et adaptateurs API, avec des composants UI partagés conservés dans une couche transverse.
Cette organisation facilite le lazy loading, les tests, la maintenance et l’évolution vers des modules ou micro-frontends si le produit devient plus important.
