Chez Forest, je travaille sur des interfaces produit, des workflows opérationnels et des intégrations de données. J’ai notamment impulsé une migration incrémentale d’Ember vers des microfrontends React et amélioré les performances du Workflow Builder sur des graphes volumineux.
Ce que Forest doit relier
Forest fournit une infrastructure destinée aux équipes qui pilotent des opérations complexes. Le produit relie des sources de données, des workflows, des permissions et des actions réalisées par des humains ou des agents.
Les interfaces ne se limitent pas à afficher des données. Elles doivent aider des équipes à comprendre un contexte, exécuter une action et suivre ce qui s’est passé sur plusieurs systèmes.
Changer de socle sans casser le rythme
Le produit possède une base Ember importante et continue d’évoluer. Introduire React ne justifie pas de remplacer automatiquement ce qui fonctionne déjà.
Nous devions choisir les périmètres où React apportait une valeur réelle, organiser sa cohabitation avec Ember et définir les fondations partagées. En parallèle, les workflows restaient connectés à plusieurs sources de données et les graphes volumineux devaient rester fluides pendant l’édition.
Ma part dans la migration
Je contribue aux interfaces produit, aux workflows opérationnels, aux intégrations de sources de données et à l’outillage interne. Mon périmètre couvre le frontend et les parties du socle fullstack nécessaires à ces parcours.
J’ai préparé la migration autour de fonctionnalités pouvant être isolées, testées et livrées progressivement.
J’ai travaillé avec l’équipe pendant la migration fonctionnalité par fonctionnalité.
Les choix d’architecture
Comparer avant de choisir
Les premières pistes exploraient notamment l’usage d’iframes et du Shadow DOM. Elles ajoutaient trop de contraintes d’intégration, en particulier autour des échanges réseau et de la communication avec l’application hôte. Les preuves de concept ont rendu ces compromis visibles avant de retenir Module Federation avec Rspack.
Migrer par frontières utiles
La migration ne suit pas un objectif abstrait de remplacement du framework. Elle avance par ensembles de fonctionnalités pouvant être isolés, testés et livrés sans fragiliser les parcours voisins. Cette approche évite une réécriture globale et conserve des déploiements séparés.
Faire cohabiter Ember et React
La coexistence fait partie de l’architecture, même si elle reste temporaire pour certains domaines. Les échanges entre les deux environnements doivent être suffisamment explicites et stables pour ne pas transformer chaque évolution en cas particulier.
Organiser les applications et les packages partagés
Le monorepo sépare les applications dans apps/ et les briques communes dans packages/. Le package UI porte les composants partagés, tandis que le package Data centralise les contrats et besoins de données réutilisables. Cette organisation améliore l’expérience de développement sans obliger tous les périmètres à être déployés ensemble.
Garder le Workflow Builder fluide
Le Workflow Builder doit rester exploitable quand un graphe devient volumineux. Le travail s’est concentré sur la virtualisation des éléments inutiles à l’écran, la réduction des repaints coûteux et la limitation du travail déclenché pendant les interactions.
Ces optimisations conservent des interactions fluides pendant l’édition, sans afficher davantage de détails que ce qui peut être documenté publiquement.
Ce que cette approche a permis
La migration peut avancer fonctionnalité par fonctionnalité sans bloquer les déploiements existants. L’architecture a donc été évaluée sur sa capacité à accompagner le produit, pas sur le remplacement d’Ember comme objectif en soi.