# Fiche synthèse — Refonte outil LP (GrapesJS) ## Besoin initial Moderniser et fiabiliser l'outil interne de création de landing pages basé sur GrapesJS afin qu'il devienne l'outil principal de production de pages d'atterrissage pour les campagnes Trigger, en canaux SMS et RCS. Le besoin vise à couvrir la quasi-totalité des besoins de campagnes en interne, à améliorer le confort d'édition et la qualité visuelle des pages pour le graphiste de l'équipe marketing, à permettre l'intégration de fragments de code pour des modules interactifs personnalisés auparavant réservés à des outils tiers, et à viser un gain opérationnel cible de vingt à trente minutes par page produite. ## Ancienne méthode manuelle La version antérieure de GrapesJS utilisée dans l'outil ne bénéficiait pas des correctifs récents ni des optimisations du composant. L'ancienne méthode d'édition présentait des contraintes d'ergonomie notables, sans possibilité de zoom, avec un affichage plein écran peu confortable et un aperçu disjoint du flux de travail. Les boutons d'action manquaient de réglages directs sur les dimensions, les bordures, les espacements et les icônes, et l'intégration de fonctionnalités avancées restait restreinte. L'outil ne proposait ni gestion de palettes de couleurs par marque cliente, ni sauvegarde automatique, ni filtrage aisé des campagnes selon les modules intégrés. La production nécessitait ainsi des allers-retours vers des solutions externes telles que MyElefant ou Sinch pour concevoir certaines pages ou certains widgets sur mesure. ## Créateur L'historique Git identifie des contributions techniques de Nicolas B., Seth-Sady et, pour des évolutions plus anciennes, Thierry Maxel. Cet historique permet de retracer des interventions dans le code, mais ne remplace pas une validation RH, contractuelle ou de propriété intellectuelle sur la qualité de créateur ou de titulaire des travaux. ## Technologie choisie L'outil est intégré à l'application Wellpack Admin, développée en PHP avec Laravel 12. L'éditeur visuel repose sur GrapesJS 0.22.13, une bibliothèque qui permet de composer une landing page par glisser-déposer et d'enregistrer son contenu sous forme structurée. L'interface associe des vues Blade, du JavaScript, React 19.1.0 pour la gestion de certaines variables, Bootstrap 5.3.2 pour l'interface et Sass pour les styles. Vite 7 assure la préparation des ressources frontales. Les landing pages et leurs réglages sont sauvegardés à distance dans l'application. Les images sont gérées par une bibliothèque de médias, les droits par un module de permissions et l'authentification d'API par Laravel Passport. Les vérifications observées utilisent PHPUnit côté application, ainsi que Puppeteer et esbuild côté navigateur. La mise en forme PHP est contrôlée par Laravel Pint. Sentry est présent dans les dépendances pour le suivi d'erreurs, mais son utilisation effective sur la refonte LP n'est pas démontrée par les éléments analysés. ## Pourquoi ce choix de techno Laravel structure les accès, la sauvegarde, les formulaires, les pages parent-enfant et les données de publication dans une même application d'administration. GrapesJS apporte une édition visuelle de composants sans imposer à l'équipe Marketing d'écrire directement du HTML ou du CSS. Sa sauvegarde distante permet de conserver ensemble la structure de la page, son rendu HTML et ses styles. Blade, JavaScript et Sass permettent d'adapter l'interface de l'éditeur aux usages métier, notamment les panneaux de réglages, les aperçus et les blocs interactifs. React est employé pour une partie spécialisée de gestion des variables. Les tests PHP et navigateur permettent de vérifier à la fois les règles applicatives et le comportement visuel des contrôles, sur différentes largeurs et dans les thèmes clair et sombre. Vite et Pint rendent les livrables frontaux et PHP reproductibles à partir du code source. ## Difficultés rencontrées L'analyse porte sur 140 commits uniques ayant modifié les modules retenus de l'éditeur entre mars 2019 et septembre 2026. Parmi eux, 17 commits portent explicitement un message de correction. Les documents de reprise détaillent aussi des régressions constatées pendant la refonte de septembre 2026. Quatre sujets importants sont retenus comme difficultés élevées, car ils montrent une incertitude technique concrète, une démarche itérative documentée et une connaissance transférable à d'autres éditeurs visuels. La nouveauté et la créativité ne sont pas retenues comme démontrées : aucun comparatif daté, essai concurrentiel ou état de l'art n'a été trouvé dans le dépôt. La première difficulté concernait la cohérence entre ce que l'équipe Marketing règle dans l'éditeur et ce qui apparaît dans la landing page publiée. Le canvas de GrapesJS fonctionne dans un document séparé de l'interface d'administration, tandis que la page publiée exécute ses propres scripts. Le bloc Drive to Store combinait un exemple affiché dans l'éditeur, des réglages enregistrés, des styles CSS et un comportement de géolocalisation côté visiteur. Des réglages de taille et de couleur étaient enregistrés sans produire d'effet visible, et plusieurs situations de consultation pouvaient laisser l'utilisateur sans indication, notamment lorsqu'aucun fichier de magasins n'était configuré, que la géolocalisation était refusée ou que le fichier de données était indisponible. La deuxième difficulté concernait l'adaptation du gestionnaire de styles de GrapesJS aux composants réellement sélectionnés. Les réglages de style disponibles dépendent du type de bloc et des restrictions déclarées par celui-ci. Une adaptation purement visuelle pouvait faire réapparaître des réglages qui devaient rester indisponibles. Les réglages de transitions et de transformations se présentent en couches successives et doivent préserver le contenu déjà enregistré. Certains types de transformation ne sont pas fournis par défaut et leurs unités de mesure ne sont pas toutes valides, par exemple une translation sur l'axe Z ne peut pas utiliser un pourcentage. La troisième difficulté concernait la stabilité de l'interface de production lors des actions courantes. Les panneaux latéraux, le bouton d'ouverture des blocs, les calques, la sélection de composants, les thèmes, la largeur de l'éditeur et la navigation par clavier devaient rester cohérents après redimensionnement, changement de thème ou retour arrière. Les documents recensent notamment une couleur de sélection fondée sur une variable inexistante, des connecteurs d'arborescence reposant sur une donnée absente, une modale devenue orpheline, des actions de calques inaccessibles ou trop petites, et des superpositions du sélecteur de couleur. La quatrième difficulté concernait l'enregistrement et l'historique. GrapesJS conserve un historique de changements internes et non une suite simple d'actions métier. Une même action peut produire plusieurs entrées, certaines modifications de texte ne sont enregistrées qu'à la sortie du champ et l'annulation est indisponible pendant une saisie dans le canvas. La sauvegarde automatique écrit directement dans les données utilisées par la page publiée. Cette architecture impose de rendre l'état de sauvegarde compréhensible et d'éviter qu'un ajustement de l'interface ne modifie silencieusement la page enregistrée. ## Comment elles ont été franchies Pour la cohérence entre l'éditeur et la page publiée, les styles du Drive to Store sont désormais générés via des variables CSS communes injectées dans le code exporté, et le contenu d'exemple a été aligné sur l'affichage réel. Le dimensionnement du canvas a été recalibré sans décalage interne, et des messages explicites avec option de réessai gèrent les refus de géolocalisation ou les données absentes. Pour les styles, les réglages s'appuient directement sur le modèle natif de GrapesJS en filtrant les sections selon le composant sélectionné. Les contrôles de transformation et de transition ont été enrichis avec des sélecteurs de famille et d'axe synchronisés avec le modèle interne, tout en excluant les unités invalides et en protégeant les valeurs enregistrées lors des annulations. Pour la stabilité de l'interface, les panneaux latéraux, la barre d'outils et les calques ont été scindés en modules autonomes aux dimensions mémorisées. Les contrastes, le sélecteur de couleur, les thèmes clair et sombre ainsi que la navigation au clavier ont été fiabilisés et validés par des tests automatisés sur plusieurs largeurs d'écran. Pour la sauvegarde et l'historique, des états visuels informent l'utilisateur en temps réel de l'enregistrement en cours, des succès ou des échecs, tandis que les commandes Annuler et Rétablir reflètent l'historique effectif. L'aperçu déclenche une sauvegarde préalable et applique automatiquement la largeur de l'appareil sélectionné. ## Connaissances acquises Le projet a formalisé une méthodologie de test et d'architecture propre aux éditeurs visuels complexes, en distinguant systématiquement le modèle de données, le canvas d'édition, le rendu publié et la persistance distante. L'équipe a établi des règles de conception strictes pour les composants GrapesJS afin de garantir l'intégrité des identifiants, des styles partagés et des comportements interactifs sans altérer les données sauvegardées. Les protocoles de validation automatisée couvrent désormais la fidélité du rendu multi-appareils, les thèmes visuels, l'accessibilité clavier, l'historique d'actions et la tolérance aux défaillances de services externes. Ces acquis méthodologiques et ces mécanismes de résilience constituent un socle capitalisé et directement réutilisable pour de futurs outils de composition de contenus. ## Nom Refonte outil LP (GrapesJS). ## Description finale de l'outil L'outil permet au graphiste et à l'équipe Marketing de concevoir et de modifier des landing pages depuis l'administration Wellpack pour les campagnes Trigger SMS et RCS, en assemblant des blocs visuels tels que du texte, des boutons d'appel à l'action, des formulaires, des images, des galeries, des jeux promotionnels, des cartes de localisation et des modules Drive to Store. Il enregistre la structure de la page, les styles, les réglages de composants, les métadonnées et les médias associés. L'éditeur fournit une vue adaptée à plusieurs appareils, des réglages de style et de comportement selon l'élément sélectionné, une arborescence de calques, une gestion de pages filles, un aperçu de la page publiée, une sauvegarde automatique et manuelle, ainsi qu'un historique d'annulation et de rétablissement. Il sécurise l'usage métier par des limites de saisie, des états de sauvegarde visibles, des contrôles de chargement et des messages d'erreur pour certains composants dépendant de données externes. ## Possibilités d'évolutions et limites par rapport à l'objectif initial La refonte a abouti aux évolutions documentées de l'interface, du canvas, des styles, du Drive to Store, de la barre d'outils, des calques, des réglages, des aperçus et des contrôles navigateur, réduisant le recours à des plateformes externes pour la composition standard des pages. Le suivi de présence en temps réel a été expérimenté puis retiré, sans verrouillage collaboratif conservé. L'historique Git et les tests confirment ce retrait. Plusieurs limites restent explicitement connues par rapport aux ambitions initiales. Il n'existe pas de mode brouillon séparé de la page publiée : la sauvegarde automatique peut modifier les données utilisées en publication. La récupération locale après un échec de sauvegarde est désactivée et aucun avertissement avant fermeture n'est présent. Les nouvelles règles de CSS protégé ne sont disponibles sur les pages déjà publiées qu'après leur prochaine sauvegarde. La géolocalisation requiert HTTPS ou localhost. Les palettes de couleurs par marque cliente, le filtrage direct des campagnes par type de module interactif et l'audit complet du module de variables restent des chantiers à approfondir. Les évolutions plausibles consistent à ajouter un vrai mode brouillon, une sauvegarde locale de récupération, un avertissement avant fermeture, une gestion dynamique de palettes de couleurs par client, des fonctions de filtrage avancées, une harmonisation complète de la langue de l'interface et, après étude, des mécanismes de collaboration. S'y ajoute l'adaptation automatisée des déclinaisons de pages par intelligence artificielle, documentée dans les études d'évolution du projet, prévoyant d'extraire les nœuds textuels de l'arborescence GrapesJS pour adapter instantanément le ton, le positionnement et les arguments commerciaux à un nouveau marché cible tout en préservant strictement la structure et les styles d'origine, via une interface de cadrage métier et un traitement asynchrone sécurisé avec gestion des pannes. Ces éléments sont des perspectives documentées ou déduites des limites observées ; ils ne sont pas présentés comme terminés. ## Temps économisé Le projet vise une cible opérationnelle de vingt à trente minutes économisées par landing page produite, grâce à la réduction des allers-retours entre outils externes et à l'accès direct aux réglages visuels au sein de l'éditeur. Dans le dépôt analysé, aucune série de mesures chronométrées avant et après refonte n'est consignée. Le gain réel effectif reste donc à mesurer auprès du graphiste et de l'équipe marketing sur un échantillon représentatif de campagnes, afin de comparer le temps effectif de conception, de vérification multi-appareils et de publication par rapport à l'ancienne méthode. ## Outil ou lien vers l'outil ou le code Application : Wellpack Admin. Dépôt de code observé : C:\Users\seth.ndinga-ndinga\Documents\Projet\admin. Les principaux modules de l'éditeur sont situés dans resources/js/views/landing_website_gjs.js, resources/js/grapejs/, resources/sass/landing.scss et app/Http/Controllers/LandingWebsiteController.php. L'adresse d'accès de l'outil en environnement utilisé doit être complétée par l'équipe. ## Version La version de référence observable pour l'éditeur est GrapesJS 0.22.13. L'application utilise Laravel 12, PHP 8.4, React 19.1.0 et Vite 7. Aucun numéro de version métier distinct pour la refonte de l'outil LP ni changelog de version formel n'a été trouvé dans les éléments analysés.