Migration EV-WYSIWYG

Voici un projet réalisé dans le cadre de mon stage de 3ᵉ année, effectué chez EasyVista, stage à l’issue duquel j’ai obtenu mon Bachelor. Durant cette période, plusieurs projets techniques m’ont été confiés, dont l’un des principaux portait sur la modernisation d’un éditeur interne à l’entreprise.

Ce projet, nommé Ev-WYSIWYG, est né de l’utilisation, au sein des produits EasyVista, d’un éditeur WYSIWYG (What You See Is What You Get). Ce type d’éditeur permet aux utilisateurs de formater du contenu (texte enrichi, couleurs, tableaux, images, etc.) via une interface visuelle, sans avoir à manipuler directement du code HTML/CSS.

L’éditeur utilisé par l’entreprise était Froala Editor, un éditeur riche, extensible grâce à un système de plugins.

Un plugin est un module logiciel ajouté à un programme existant afin d’en étendre les fonctionnalités sans modifier son cœur applicatif. Dans ce contexte, les plugins permettaient d’ajouter ou de personnaliser des fonctionnalités spécifiques telles que la gestion des couleurs de texte, l’insertion d’éléments personnalisés, la modification du comportement de certains boutons ou encore l’ouverture de fenêtres modales d’interaction avec le contenu sélectionné.

EasyVista développait ainsi ses propres plugins métiers afin d’adapter l’éditeur aux besoins spécifiques de ses produits.

Cependant, l’architecture initiale reposait sur AngularJS, framework aujourd’hui obsolète et non maintenu officiellement. Les plugins développés en interne étaient donc fortement couplés à cette technologie.

Avec le temps, plusieurs problématiques sont apparues :

1. AngularJS n’étant plus maintenu, le projet devenait techniquement fragile et difficile à faire évoluer.
2. Les vues contenaient un volume important de code, rendant la lecture et la maintenance complexes.
3. L’ajout de nouvelles fonctionnalités augmentait le risque de dérive vers un code spaghetti, c’est-à-dire un code désorganisé, peu lisible et difficile à maintenir.
4. La testabilité du projet était limitée.

Face à ces constats, il était nécessaire d’engager une refonte technique afin de répondre aux problématiques de maintenabilité, d’évolutivité et de robustesse identifiées au sein de l’architecture existante.

L’objectif principal du projet Ev-WYSIWYG était de faire évoluer l’architecture de l’éditeur interne en migrant les plugins existants d’AngularJS vers une stack plus pérenne, basée sur React et TypeScript.

Il s’agissait notamment de renforcer la maintenabilité du code, de limiter la dette technique accumulée au fil des évolutions précédentes et d’instaurer une base technique plus robuste et évolutive.

Un second objectif consistait à développer de nouveaux plugins dans cette nouvelle stack technologique.

Enjeux

L’enjeu résidait dans la réussite d’une migration structurée, sans reproduire les limites de l’ancienne architecture. Il ne s’agissait pas simplement de réécrire le code en React et TypeScript, mais de repenser l’organisation du projet afin d’obtenir un éditeur moderne, maintenable et plus fiable sur le long terme.

Le projet devait également permettre d’assurer une intégration cohérente des nouveaux plugins dans cette nouvelle architecture. Chaque plugin devait pouvoir s’ajouter à l’éditeur de manière claire et structurée, sans complexifier l’ensemble du système.

La migration vers une nouvelle stack technologique comportait plusieurs risques.

Le premier risque concernait la perte ou l’altération de fonctionnalités existantes. Les plugins développés sous AngularJS étaient déjà intégrés aux produits de l’entreprise. Une mauvaise compréhension de leur fonctionnement pouvait entraîner des régressions ou des comportements différents dans la nouvelle version.

Un autre risque résidait dans la complexité de la migration elle-même. Reprendre un code existant, parfois dense et peu structuré, nécessitait une phase d’analyse approfondie. Une transposition mal maîtrisée aurait pu reproduire les mêmes problèmes d’organisation que l’ancienne architecture.

Le projet présentait également un risque d’intégration. Les nouveaux plugins devaient fonctionner correctement avec l’éditeur et s’inscrire dans une architecture commune. Une mauvaise structuration aurait pu compliquer l’ajout de futures fonctionnalités.

Enfin, le changement de technologie impliquait une phase d’adaptation. L’adoption de React et TypeScript nécessitait de mettre en place de nouvelles pratiques de développement et d’assurer une cohérence dans leur utilisation.

Ce projet a été réalisé durant mon stage au sein du service Recherche et Développement d’EasyVista. Dans le cadre de cette première mission, je travaillais principalement avec mon maître de stage, Monsieur Younes B., qui m’encadrait et m’accompagnait dans la découverte de l’environnement technique et des pratiques de l’entreprise.

Étant encore en phase d’intégration, je n’étais pas directement impliqué avec l’ensemble de l’équipe de développement. Mon maître de stage jouait donc un rôle central dans le suivi du projet : il me transmettait les consignes, m’expliquait les conventions utilisées dans le code et me guidait dans la compréhension du projet existant. Lorsque je rencontrais des difficultés, je pouvais lui demander de l’aide afin d’obtenir des explications ou des pistes de réflexion pour avancer.

Ces échanges réguliers m’ont permis de développer ma communication professionnelle, notamment dans la manière de présenter un problème, d’expliquer mes choix techniques ou de demander des clarifications lorsque cela était nécessaire. Les retours de mon maître de stage m’ont également aidé à m’adapter progressivement aux attentes et au rythme de travail du service.

Dans le cadre du projet, des échanges avaient également lieu avec l’équipe UX/UI. Celle-ci testait les plugins développés afin de vérifier leur comportement et leur intégration dans l’éditeur. Lorsque des ajustements étaient nécessaires, ces retours permettaient d’apporter des améliorations ou des corrections afin de garantir une expérience utilisateur cohérente.

Ainsi, l’organisation humaine autour de ce projet reposait principalement sur un accompagnement étroit entre un maître de stage et son stagiaire, tout en intégrant ponctuellement les retours d’autres équipes impliquées dans la validation du produit.

Cahier des charges et compréhension du projet

La première étape consista en l’étude du cahier des charges qui m’avait été transmis par mon maître de stage. Celui-ci présentait les objectifs du projet, les spécifications fonctionnelles et techniques, ainsi que les livrables attendus.

Grâce à cette phase, j’ai pu comprendre les attentes liées à la migration des plugins et prendre connaissance des contraintes techniques du projet. En parallèle, mon maître de stage m’a présenté le fonctionnement général de l’éditeur et l’architecture existante afin de me familiariser avec l’environnement dans lequel j’allais intervenir.

Cette analyse était essentielle pour définir une ligne directrice claire avant de commencer le développement. Elle m’a permis d’identifier les éléments à migrer, de mieux appréhender le fonctionnement des plugins et d’organiser progressivement les tâches à réaliser.

Analyse du code AngularJS

Pour analyser le code existant, j’ai sélectionné un plugin parmi ceux devant être migrés afin d’étudier sa structure et de comprendre son intégration dans l’éditeur.

Cette analyse m’a permis d’observer l’organisation du code utilisée dans l’ancienne architecture. Les plugins reposaient sur AngularJS et combinaient souvent plusieurs responsabilités dans un même fichier, mêlant la logique métier, la gestion des interactions avec l’éditeur et l’affichage de l’interface utilisateur. Avec le temps et l’ajout de nouvelles fonctionnalités, cette organisation avait conduit à un code dense et parfois difficile à lire.

De plus, AngularJS étant un framework aujourd’hui (et à l’époque de mon stage déjà) obsolète, certaines pratiques utilisées dans le projet rendaient l’évolution du code plus complexe. La structure des plugins manquait parfois de modularité, ce qui compliquait la compréhension globale et augmentait le risque de reproduire une organisation peu claire lors de la migration.

Ce processus d’analyse était donc essentiel afin d’identifier le comportement fonctionnel des plugins et de comprendre comment ils interagissaient avec l’éditeur. Il m’a permis de définir les éléments à conserver et ceux qui devaient être réorganisés dans la nouvelle architecture basée sur React et TypeScript.

Conception de la nouvelle architecture

Enfin, la conception pouvait commencer et elle consistait à avoir une organisation efficace pour la coupler à la stack React et TypeScript. Nous voulions une architecture fiable et maintenable, complètement éloignée de la précédente.

Pour cela, j’ai choisi d’organiser les différents éléments du plugin en utilisant le modèle MVC (Modèle – Vue – Contrôleur). Ce dernier consiste à séparer une application en trois parties distinctes : le Modèle, qui gère les données et la logique métier ; la Vue, qui correspond à l’interface utilisateur ; et le Contrôleur, qui fait le lien entre les interactions de l’utilisateur et les actions effectuées sur l’application. Cette séparation m’as permis de mieux structurer le code et de limiter les dépendances entre les différentes parties du programme.

Dans cette logique, j’ai créé une classe « PluginFactory » afin de centraliser la création des plugins et de garantir qu’ils respectent tous une structure similaire. Cette approche permit de standardiser la manière dont les plugins étaient construits et intégrés à l’éditeur, tout en évitant la duplication de code.

En parallèle, une autre classe appelée « PopupFactory » a été mise en place afin de gérer la création des fenêtres modales utilisées par certains plugins. En effet, certains plugins nécessitent l’ouverture d’une interface permettant à l’utilisateur d’interagir avec l’éditeur, par exemple pour sélectionner une couleur ou modifier un élément du texte. La centralisation de cette logique permettait d’assurer un comportement cohérent entre les différents plugins et de simplifier leur développement.

Structure du projet

Avec le changement de stack technique, il m’a également été demandé de redéfinir la structure du projet. Les projets existants étaient initialement organisés selon une approche manyrepo (ou multi-repository), où chaque projet possède son propre dépôt de code indépendant.

Dans ce type d’organisation, chaque dépôt contient ses propres dépendances et modules. Cette approche peut fonctionner pour des projets isolés, mais elle devient plus complexe à maintenir lorsque plusieurs projets partagent les mêmes ressources ou librairies. Dans notre cas, certains modules communs devaient être générés et maintenus séparément dans chaque dépôt, ce qui entraînait des duplications et compliquait la gestion des mises à jour.

Afin de simplifier cette organisation, le projet a été restructuré sous la forme d’un monorepo. Un monorepo est une approche de gestion du code source dans laquelle l’ensemble des projets et des composants d’une application est regroupé dans un seul et même dépôt. Autrement dit, les différentes parties du système (applications, librairies, modules ou plugins) sont centralisées dans un référentiel unique.

Cette organisation permet notamment de mutualiser les ressources communes. Les modules partagés peuvent être générés et maintenus une seule fois, puis utilisés par l’ensemble des projets concernés.

Migration et développement des plugins

De retour sur le plugin analysé précédemment, j’ai commencé à le redévelopper en suivant la nouvelle architecture mise en place dans le projet. L’objectif était de reproduire son fonctionnement tout en l’intégrant dans la nouvelle stack basée sur React et TypeScript.

Le développement a consisté à reconstruire les différentes fonctionnalités du plugin afin qu’il puisse interagir correctement avec l’éditeur. Dans le cas du plugin étudié, celui-ci permettait de modifier la couleur du texte sélectionné dans l’éditeur et d’ouvrir une fenêtre permettant à l’utilisateur de choisir ou d’ajouter une couleur.

Il a donc fallu adapter la logique du plugin afin qu’il puisse récupérer le texte sélectionné dans l’éditeur, appliquer les modifications souhaitées et mettre à jour le contenu affiché. Cette partie demandait également de s’assurer que le plugin s’intégrait correctement dans l’interface de l’éditeur et qu’il respectait le comportement attendu.

Au fur et à mesure du développement, plusieurs tests ont été réalisés afin de vérifier le bon fonctionnement du plugin et de corriger les éventuels problèmes rencontrés lors de son intégration dans l’éditeur.

Tests et validation

Lorsque je terminais le développement d’un plugin, plusieurs phases de tests étaient réalisées afin de vérifier son bon fonctionnement au sein de l’éditeur. Ces tests consistaient principalement à s’assurer que les différentes fonctionnalités du plugin répondaient correctement aux actions de l’utilisateur et que les modifications apportées au contenu de l’éditeur étaient bien appliquées. Il était important de vérifier que le plugin ne provoquait pas de comportements inattendus au sein de l’éditeur Froala. Différents scénarios d’utilisation ont donc été testés afin de s’assurer de la stabilité de la fonctionnalité.

Par ailleurs, l’équipe UX/UI a également pu tester le plugin afin de vérifier son intégration dans l’interface et l’expérience utilisateur associée. Les retours obtenus ont permis d’apporter certains ajustements afin d’améliorer le comportement ou l’affichage du plugin.

Pour la mise en œuvre de ce projet, l’entreprise a fait le choix d’adopter une stack moderne basée sur React et TypeScript. Cette transition technologique visait principalement à améliorer la maintenabilité du projet, à structurer davantage le code et à réduire les risques d’erreurs lors du développement.

Choix des technologies

React & TypeScript

React est une bibliothèque JavaScript largement utilisée pour la création d’interfaces utilisateur interactives. Son approche basée sur des composants réutilisables permet de structurer l’interface de manière claire et modulaire. Cette organisation facilite la séparation des différentes parties de l’application et rend le code plus lisible et plus simple à faire évoluer.

L’utilisation de TypeScript vient compléter cette approche en apportant un système de typage statique au langage JavaScript. TypeScript permet de définir des types pour les variables, les fonctions ou encore les objets, ce qui rend le code plus explicite et limite certaines erreurs dès la phase de développement.

La combinaison de React et TypeScript permet ainsi de développer des applications web plus robustes et mieux structurées. Le typage apporte davantage de sécurité et facilite la maintenance du code, tandis que l’approche par composants de React favorise la modularité et la réutilisation.

Dans le cadre du projet Ev-WYSIWYG, cette stack technologique permettait donc de proposer une architecture plus claire et plus maintenable.

ESLint

Afin de garantir une qualité de code homogène au sein du projet, l’outil ESLint a également été utilisé. ESLint est un outil d’analyse statique du code qui permet de détecter certaines erreurs potentielles et de faire respecter des conventions de développement d’EasyVista. Son utilisation permet de maintenir un code cohérent entre les différents développeurs et d’éviter certaines mauvaises pratiques.

Outils complémentaires

GitHub + Jenkins

Le versioning du code était assuré via GitHub, qui permet de centraliser le dépôt du projet et de suivre l’évolution du code au fil du développement.

Dans le cadre du projet, GitHub était également couplé à Jenkins, un outil d’intégration continue permettant d’automatiser certaines étapes liées au développement notamment les tests unitaires et d’intégration.

Jenkins permet de lancer des processus automatisés lors de la mise à jour du code, ce qui contribue à sécuriser les évolutions du projet et à vérifier que les modifications n’introduisent pas de problèmes dans l’application.

Azure DevOps

La gestion des tâches et le suivi des demandes étaient réalisés à l’aide d’Azure DevOps. Cet outil permet d’organiser le travail sous forme de tickets décrivant les différentes fonctionnalités à développer, les corrections à effectuer ou les améliorations à apporter. Chaque ticket correspond à une tâche précise, ce qui facilite la planification du travail et le suivi de l’avancement du projet.

Ce projet avait pour but de migrer les plugins vers une stack plus moderne afin d’accompagner l’évolution de l’éditeur Froala utilisé au sein des produits de l’entreprise. Cette migration, associée à la restructuration du projet, a permis de mettre en place une base technique plus claire et mieux organisée.

Le résultat du projet a été concluant. Les plugins ont pu être redéveloppés dans la nouvelle architecture et intégrés correctement à l’éditeur. La structure mise en place a ensuite pu être réutilisée progressivement dans d’autres projets de l’entreprise, ce qui a permis d’harmoniser l’organisation du code et de faciliter le développement de nouvelles fonctionnalités.

Sur le plan personnel, ce projet représentait ma première mission en tant que stagiaire développeur front-end au sein du service R&D. Il m’a permis de mettre en pratique mes compétences techniques et humaines apprises à l’ESIEA dans un contexte professionnel réel, notamment en matière d’analyse de projet, de compréhension d’un code existant et de développement dans une nouvelle architecture et de communication. Les échanges avec mon maître de stage et avec l’équipe UX/UI m’ont aidé à mieux comprendre l’importance de la collaboration dans la réalisation d’un projet logiciel.