Stickair, société pionnière de la vente d’autocollants en ligne.

Le premier module de notre projet de transformation numérique était centré sur la sélection de la plateforme adaptée à la nouvelle boutique en ligne de Stickair. L’objectif principal était de respecter la charte graphique préexistante et d’offrir une expérience utilisateur de haute qualité (client et administrateur).

Trois alternatives ont été évaluées :

1. Développement interne sur mesure :
   Cette option nécessitait une évaluation approfondie des ressources humaines et techniques disponibles. Bien que la plus flexible en termes de personnalisation, elle posait des défis en matière de délais et de coûts.
2. Solutions CMS payantes :
   Bien que robustes et riches en fonctionnalités, elles impliquaient des coûts de licence et des limitations sur la personnalisation.
3. CMS Open-Source, avec un focus sur PrestaShop :
   PrestaShop, une solution CMS open-source, a été évaluée pour son équilibre entre coût, flexibilité et fonctionnalités. Il permet une personnalisation étendue et offre une large gamme de plugins, tout en étant plus économique que les solutions payantes.

Le deuxième module fonctionnel visait le transfert sécurisé et intégral des données clients, de leur historique de commandes et des informations relatives aux produits. Cette étape a impliqué une étude préalable des schémas de bases de données existants pour évaluer la complexité de la migration et identifier les éventuels défis en matière de compatibilité et de sécurité.

Le troisième module était axé sur la migration de SignMaker. Deux options principales ont été considérées :

1. Émulation via Apache Royal :
   Apache Royal est un framework de développement qui permet de migrer des applications Flash/Flex vers des technologies web plus modernes sans refondre entièrement le code source.
2. Refactoring Complet :
   Cette option consisterait en une réécriture complète de l’application en utilisant des technologies modernes, ce qui permettrait une meilleure maintenance et évolutivité à long terme.

Le quatrième module était axé sur le renouvellement de l’infrastructure IT. L’approche s’est faite en « cloud-first », avec des services managés et serverless pour la messagerie, les bases de données et l’hébergement du code.

Dans ce contexte, la stratégie s’est centrée sur une transition technologique rapide et efficace, avec pour objectif de maintenir le niveau de service attendu par les clients tout en renforçant la sécurité globale de l’infrastructure de Stickair.

Pour ce premier module, le choix s’est arrêté sur l’utilisation de PrestaShop, une plateforme de gestion de contenu (CMS) spécialisée dans le commerce en ligne. Ce choix a été motivé par plusieurs facteurs analysés à travers une approche multidimensionnelle.

1. Open-Source :
   Conformément à une perspective axée sur la longévité et la flexibilité, une préférence a été donnée aux solutions open-source. La nature open-source de PrestaShop assure une adaptabilité élevée, soutenue par une communauté active de développeurs.
2. Expertise de l’agence :
   En tant que partenaire certifié de PrestaShop, l’expertise de l’agence Lueur Externe a été un facteur clé dans la sélection de ce CMS. Le capital de connaissances accumulé par l’agence sur cette plateforme constitue un avantage compétitif pour la réalisation du projet dans les délais impartis.
3. Coût et Licence :
   Dans une perspective de coût total de possession (TCO), l’absence de frais de licence pour PrestaShop s’aligne avec la stratégie de maîtrise budgétaire. Ce point est particulièrement pertinent lorsque l’on considère les travaux de recherche sur les coûts cachés associés aux solutions propriétaires.
4. Compatibilité et Écosystème :
   PrestaShop présente également l’avantage de disposer d’un écosystème robuste compatible avec divers services tiers tels que des banques et des transporteurs. Cela simplifie l’intégration et favorise l’inter-opérabilité.
5. Continuité Visuelle et Expérience Utilisateur :
   Enfin, PrestaShop offre des options étendues pour la personnalisation visuelle, ce qui permet de maintenir une continuité dans la charte graphique et l’expérience utilisateur, conformément aux besoins identifiés lors de la phase d’analyse stratégique.

La complexité inhérente à la migration des données clients, des historiques de commandes, et des produits a exigé une réflexion approfondie. À cet égard, la décision de choisir PrestaShop pour le front-office et le back-office a également été influencée par des analyses techniques des schémas de la base de données existante (« base legacy »).

Ces études ont permis de valider la transformation des données et le typage fort des caractéristiques nativement soutenues par PrestaShop.

Interface de Passerelle pour la Transformation des Données : À la place d’une injection directe des données dans la base de données cible, l’agence à opté pour une solution plus précise. Une interface de passerelle a été développée pour opérer la communication entre la base legacy et la nouvelle plateforme PrestaShop. Cette interface a servi à extraire les données de la base d’origine, à effectuer des transformations de données selon les spécifications de typage et d’intégrité de PrestaShop et ensuite à les transférer dans le nouveau système en utilisant l’API native de PrestaShop. Cette méthodologie a permis d’assurer l’intégrité et la conformité des données transférées, tout en respectant les contraintes d’intégrité relationnelle imposées par PrestaShop.

Bien qu’un peu plus longue que l’injection directe, cela a permis de garantir que toutes les contraintes d’intégrité et de sécurité ont été respectées, alignant ainsi la migration avec les meilleures pratiques en matière de gestion de données.

Pour le volet back-end de cette refonte, le framework Laravel a été choisi.
L’un des atouts majeurs de Laravel réside dans ses capacités avancées de gestion d’ORM (Object-Relational Mapping). Cette technologie facilite la manipulation et la gestion des données en convertissant les modèles orientés objet en tables de bases de données relationnelles. Outre ces avantages, Laravel prend nativement en charge des fonctionnalités liées à la sécurité et aux tests unitaires, ce qui a contribué à une validation continue des fonctionnalités durant le cycle de développement.

En ce qui concerne le front-end, le choix s’est porté sur Fabric.js. Cette bibliothèque JavaScript offre des possibilités avancées pour la manipulation dynamique d’objets SVG, ce qui était requis pour la représentation précise des autocollants. De plus, sa nature extensible a permis l’ajout de modules personnalisés pour répondre aux besoins spécifiques du projet.

Une nouvelle base de données a été mise en place pour stocker les données de l’application SignMaker. Elle a été conçue pour intégrer des tables dédiées aux projets, tout en conservant certaines tables du système legacy pour assurer la compatibilité ascendante (exploitation des macros de production).

La complexité du module SignMaker a requis la mobilisation de toutes les expertises de l’équipe de Lueur Externe. Le développement a été organisé en sprints agiles, chacun se concentrant sur un ensemble particulier de fonctionnalités. Cette méthode a permis une réactivité aux changements et a facilité l’adaptation aux besoins techniques évolutifs.

La décision d’un refactoring complet n’était pas sans risques. Toutefois, des stratégies de vérification ont été mises en place pour assurer la qualité du code et sa conformité.
En utilisant Laravel et Fabric.js, cette refonte a satisfait les critères fonctionnels et a aussi introduit un niveau supérieur de modularité et d’évolutivité pour la nouvelle version de SignMaker.

Stickair – SignMaker V1 – Personnalisation de véhicule

Stickair – SignMaker V2 – Personnalisation de véhicule

Le quatrième module du projet a été centré sur une transformation majeure de l’infrastructure IT.

• Messagerie avec Google Workspace
  La messagerie a été migrée vers Google Workspace, en remplacement d’un ancien serveur de messagerie hébergé qui présentait des difficultés en termes de délivrabilité des emails, de stockage et de gestion des utilisateurs. Google Workspace offre non seulement une meilleure délivrabilité, mais aussi une interface utilisateur simplifiée et une gestion des comptes plus agile.
  
  
• Gestion du Code Source et CI/CD
  Le code source a été placé dans un dépôt GitLab, intégré à une pipeline CI/CD (Intégration Continue/Déploiement Continu) qui implémente les meilleures pratiques de DevSecOps. Avant tout déploiement, le code passe par une revue automatisée grâce à SonarQube, assurant ainsi la qualité et la sécurité du code (barrières). Après cette étape, le code est empaqueté dans une image Docker, qui est ensuite stockée dans un ECR (Elastic Container Registry) privé d’AWS, prête à être déployée sur une instance EC2.
  
  
• Déploiement et Hébergement
  Pour l’hébergement, le code est déployé sur une instance EC2 (Elastic Compute Cloud) d’Amazon, automatisant ainsi le processus de déploiement. Cette approche offre l’avantage de l’élasticité, permettant à l’infrastructure de s’adapter aux fluctuations de la demande.
  
  
• Gestion des Bases de Données
  Les bases de données ont été hébergées sur un cluster AWS RDS Aurora, garantissant haute disponibilité et robustesse. Aurora est une solution de gestion de bases de données entièrement managée qui automatise des tâches telles que les sauvegardes, la réparation et les mises à jour.
  
  
• Stockage des Données
  Pour le stockage des images et des projets statiques, un bucket Amazon S3 a été utilisé. Cette solution fournit une plateforme de stockage objet fiable, élastique et sécurisée.
  
  
• Gestion Automatisée des Sauvegardes
  La totalité des opérations de sauvegarde est gérée par les services managés d’AWS, éliminant ainsi le besoin de routines de sauvegarde autrefois manuelles et de maintenance périodique.
  
  

Cycle de développement continu chez Lueur Externe – Source : Lueur Externe – Tous droits réservés