ElectroClinic

ElectroClinic est un projet de refonte et d’évolution d’une plateforme e-commerce, visant à sécuriser l’existant via une migration PrestaShop vers une version supportée, puis à préparer une nouvelle solution interne plus modulable, maintenable et optimisée pour le tunnel d’achat.

À mon arrivée sur le projet ElectroClinic, la plateforme e-commerce était déjà en production mais reposait sur une version ancienne de PrestaShop arrivée en fin de support, ce qui posait des problèmes de sécurité, de compatibilité et de maintenabilité. L’objectif immédiat était de migrer la boutique vers une version plus récente et supportée tout en garantissant la continuité de service et la conservation des données et des fonctionnalités clés. L’objectif à moyen terme était de lancer une nouvelle solution e-commerce développée en interne afin d’obtenir une plateforme plus simple à maintenir, plus modulable et plus réactive, tout en améliorant le tunnel d’achat.

J’ai d’abord tenté d’exécuter la migration via l’assistant automatique, mais la version en production était trop ancienne pour être compatible avec cet outil. J’ai donc réalisé une migration manuelle en partant d’une installation neuve de la version récente de PrestaShop et en y réappliquant les adaptations nécessaires à la main. J’ai vérifié la compatibilité des plugins et des modules existants avec la version cible afin d’éviter les régressions fonctionnelles. J’ai revu le schéma de base de données afin d’anticiper les écarts structurels entre versions et de sécuriser l’intégrité des informations. J’ai refait l’interface graphique pour l’aligner sur la charte de l’entreprise et garantir une expérience utilisateur cohérente.

Le risque principal de la migration était de provoquer un échec rendant la plateforme inutilisable et entraînant une indisponibilité du site. Un autre risque majeur concernait la perte ou la corruption de données, notamment sur les clients, commandes, produits, stocks et historiques. La migration exposait également un risque d’incompatibilité de modules pouvant casser des fonctionnalités critiques comme le paiement, la livraison ou les emails transactionnels. Elle impliquait aussi un risque de régression visuelle ou de performance, ainsi qu’un risque SEO en cas de modification d’URLs ou de mauvaise gestion des redirections.

Une fois la migration stabilisée, j’ai travaillé en autonomie sur la préparation de la nouvelle solution interne en définissant les bases fonctionnelles et techniques du projet. Il a été décidé de s’appuyer sur MySQL, Node.js, React, TypeScript et Next.js afin de construire une architecture moderne, maintenable et évolutive. J’ai conçu la maquette, rédigé des cahiers des charges, établi le schéma de la nouvelle base de données, défini une nouvelle charte graphique et produit la documentation nécessaire à la reprise du projet.

La solution interne comportait un risque de dérive de planning et de non aboutissement, car le développement complet d’une plateforme e-commerce demande un investissement important en temps et en ressources. Elle présentait un risque de couverture fonctionnelle incomplète, notamment sur les sujets complexes comme les promotions, la TVA, les retours, le back-office ou les intégrations externes. Elle impliquait aussi des risques de sécurité et de conformité liés à la gestion des données personnelles et aux parcours de paiement. Elle exposait enfin un risque de dette technique et de difficultés de maintenance si l’architecture, les tests et la documentation n’étaient pas suffisamment cadrés et partagés.

La migration vers une version plus récente de PrestaShop a été un succès et a permis de sécuriser la plateforme existante. Le développement de la solution interne n’a pas pu être finalisé en raison de la fin de ma période d’alternance, mais le cadrage, les livrables de conception et la documentation ont posé une base solide pour la suite.

Pour moi

Ce projet a permis de mener une migration e-commerce à fort enjeu en passant d’une tentative d’automatisation à une migration manuelle complète et maîtrisée. Il a renforcé des compétences techniques sur PrestaShop, la gestion de compatibilité des modules, l’analyse et l’adaptation d’un schéma de base de données, ainsi que la refonte d’interface selon une charte graphique. Il a également développé une capacité à cadrer un produit, grâce à la réalisation de maquettes, de cahiers des charges, d’un schéma de base de données cible, d’une charte graphique et d’une documentation exploitable. Le résultat le plus tangible est une expérience complète et valorisable dans un portfolio, combinant résolution de risques en production et préparation d’une refonte applicative.

Pour l'entreprise

La migration réussie vers une version récente et supportée de PrestaShop a réduit les risques liés à l’obsolescence, à la sécurité et aux incompatibilités techniques, tout en assurant la continuité de service. La remise à niveau graphique a amélioré la cohérence avec l’identité visuelle et a contribué à une expérience utilisateur plus homogène. Le lancement de la solution interne, même non finalisé, a posé des fondations solides grâce à des livrables de conception et de cadrage prêts à être repris, ce qui accélère la suite du projet et limite les coûts de relance. Enfin, cette trajectoire ouvre la voie à une plateforme interne plus modulable, plus simple à maintenir et conçue pour améliorer le tunnel d’achat à terme.

À la suite de mon départ, le développement de la solution e-commerce interne a été mis en pause, mais la plateforme PrestaShop migrée reste en production et assure la continuité des achats en ligne. Les prochaines évolutions peuvent consister à stabiliser et optimiser l’existant par des améliorations UX du tunnel d’achat, des ajustements de performance et une maintenance régulière des modules afin de conserver un socle fiable et sécurisé. En parallèle, le projet interne pourra être relancé ultérieurement à partir des livrables réalisés, en reprenant progressivement les fonctionnalités prioritaires et en cadrant une feuille de route réaliste. À court et moyen terme, la migration déjà réalisée apporte un bénéfice direct, car la boutique mieux structurée et plus moderne améliore la visibilité du site, renforce le référencement et met davantage en valeur l’offre, ce qui contribue à soutenir et augmenter les ventes en ligne.

Sur le projet ElectroClinic, j’ai vécu une expérience très formatrice parce que je suis arrivé sur une plateforme déjà en production, avec une dette technique importante et un vrai enjeu de continuité de service. Le fait de reprendre un existant vieillissant, arrivé en fin de support, m’a immédiatement placé dans une posture différente de celle d’un projet “from scratch”. Je n’avais pas seulement à “développer”, je devais d’abord sécuriser, comprendre, diagnostiquer, puis agir sans casser l’existant. Avec le recul, c’est probablement ce qui m’a le plus fait progresser : travailler avec des contraintes réelles, des risques concrets, et des impacts directs sur l’activité.

Au début, j’ai cherché la solution la plus simple et la plus sûre en tentant de lancer l’assistant automatique de migration. Cette première approche a été utile, parce qu’elle m’a permis de confirmer rapidement la limite principale : la version de production était trop ancienne pour être compatible avec ce processus. J’ai appris ici un point clé : même quand un outil “promet” une migration, il y a toujours une dépendance au contexte, et il faut savoir basculer vers une stratégie alternative sans perdre de temps. Ça m’a obligé à être plus méthodique, et surtout à accepter que le chemin le plus fiable serait une migration manuelle, donc plus longue et plus risquée si mal préparée.

La migration manuelle a été le cœur technique de mon travail, et c’est là que j’ai vraiment renforcé ma rigueur. J’ai compris que le danger principal n’était pas uniquement “réussir à installer une nouvelle version”, mais de garantir que la boutique reste fonctionnelle dans les parcours critiques. J’ai dû me concentrer sur des éléments qui, en e-commerce, n’ont pas le droit d’échouer : la navigation catalogue, le panier, le checkout, le paiement, la livraison, la création de compte, les emails transactionnels, et l’accès à l’administration. Avec le recul, je me rends compte que j’ai développé une logique de priorisation orientée impact : je ne pouvais pas me permettre de passer trop de temps sur du “cosmétique” tant que la chaîne de vente n’était pas fiable.

Sur la partie modules et plugins, j’ai été confronté à une réalité très concrète : l’écosystème PrestaShop dépend fortement de composants tiers, et une migration peut échouer simplement parce qu’un module n’est plus maintenu ou plus compatible. J’ai dû faire un travail de tri et d’anticipation, en vérifiant ce qui pouvait être conservé, ce qui devait être remplacé, et ce qu’il fallait éventuellement simplifier. Cette étape m’a appris à ne pas prendre une dépendance pour acquise. J’ai aussi compris que la compatibilité ne se limite pas à “ça s’installe”, mais à “ça fonctionne dans le flux réel”, ce qui m’a poussé à vérifier l’usage concret derrière chaque module.

La base de données a été une autre zone d’apprentissage forte. Revoir le schéma et gérer les différences entre versions m’a donné une meilleure compréhension de ce qui se cache derrière une boutique : les relations entre produits, déclinaisons, stocks, commandes, clients, adresses, statuts, taxes, etc. J’ai aussi pris conscience que la donnée est souvent le point le plus sensible : une plateforme peut sembler “marcher” tout en ayant des incohérences invisibles qui ressortiront plus tard (commandes incomplètes, clients dupliqués, règles de prix cassées). Si je devais être critique, je dirais que j’aurais gagné à formaliser davantage mes contrôles d’intégrité et à documenter précisément ce que j’ai vérifié, pour rendre la validation encore plus reproductible.

La refonte de l’interface selon la charte graphique m’a également fait grandir, parce que j’ai dû concilier contraintes techniques et cohérence de marque. J’ai appris que l’UI n’est pas qu’un “habillage” : elle influence la confiance, la lisibilité, et donc la conversion. Même si je n’avais pas forcément la main sur des tests utilisateurs, je me suis efforcé de produire une interface plus cohérente et plus alignée avec l’identité de la société. Avec du recul, je pense que j’aurais pu aller plus loin en instrumentant davantage l’effet de ces changements, par exemple en suivant des indicateurs simples comme le taux d’abandon panier ou la performance des pages clés, afin de relier le travail graphique et technique à un impact mesurable.

Ce projet m’a aussi appris à travailler avec la notion de risque, pas seulement comme une idée abstraite, mais comme un facteur qui doit orienter les décisions. Le risque principal était clair : rendre la plateforme inutilisable en production. En conséquence, j’ai développé une façon de réfléchir plus prudente : éviter les changements trop larges d’un coup, tester au maximum, sécuriser les points critiques, et prévoir des actions en cas d’anomalies. Si je suis honnête, c’est aussi un domaine où je peux m’améliorer : je pourrais structurer davantage cette gestion du risque en créant systématiquement une checklist de recette, un plan de rollback, et une documentation de mise en production, même quand le contexte est pressé. J’ai fait une partie de ce travail dans l’action, mais je pourrais le rendre plus formel et plus transmissible.

Après la migration, le basculement vers la solution interne m’a donné une perspective différente. Passer d’un existant à un projet “à concevoir” m’a permis de toucher à une dimension plus produit : définir une vision, structurer des besoins, organiser une roadmap implicite, et préparer une architecture. Le choix du stack (MySQL, Node, React, TypeScript, Next.js) m’a fait travailler ma capacité à sélectionner une base technique moderne et cohérente avec les objectifs : maintenabilité, modularité, performance, et meilleure expérience sur le tunnel d’achat. J’ai particulièrement apprécié cette partie parce qu’elle m’a donné l’occasion de produire des livrables concrets de conception : maquettes, cahiers des charges, schéma de base de données, charte graphique, documentation. J’ai compris qu’un projet ne se limite pas au code, et que la qualité de la préparation conditionne la réussite de l’implémentation.

En revanche, cette phase m’a aussi confronté à une limite importante : l’ambition d’une solution interne est élevée, et le risque de “ne pas finir” est réel si le découpage n’est pas extrêmement pragmatique. Le projet a été mis en pause après mon départ, et même si je n’en suis pas la cause directe, ça m’a fait réfléchir à ce que j’aurais pu faire différemment pour maximiser les chances de continuité. Avec le recul, je pense que j’aurais pu pousser encore plus une approche MVP très découpée, avec une liste de fonctionnalités indispensables livrables par étapes, et une définition claire de ce qui devait être “prioritaire pour créer de la valeur rapidement”. J’ai livré des bases solides de cadrage, mais j’aurais aimé laisser aussi une feuille de route encore plus opérationnelle, orientée incréments et jalons courts, pour réduire le risque de gel.

Ce que je retiens aussi, c’est que j’ai beaucoup travaillé en autonomie, et c’est une force que je peux valoriser, mais c’est aussi un point d’attention. L’autonomie est efficace, mais elle peut réduire les occasions de validation croisée, de revue de design, ou de retours utilisateurs. Sur un projet e-commerce, ces feedbacks sont précieux. À l’avenir, je veux mieux intégrer des rituels de validation, même simples : présenter plus souvent l’avancement, faire relire mes décisions d’architecture, confronter mes choix UX à des retours métier, et documenter les arbitrages. Ce sont des pratiques qui sécurisent le projet et rendent mon travail encore plus robuste.

Au final, je considère que mon apport principal sur ElectroClinic a été de remettre la plateforme dans une situation saine et durable grâce à une migration réussie, puis de préparer sérieusement une trajectoire de modernisation via une solution interne. J’ai gagné en maturité technique, notamment sur la gestion d’un existant, les dépendances, la donnée, et la fiabilité en production. J’ai aussi gagné en maturité méthodologique sur le cadrage, la documentation, et la vision produit. Mes axes de progression les plus clairs sont la formalisation (tests, validation, rollback, documentation de run), l’observabilité (mesurer l’impact et détecter les anomalies), et le découpage MVP (réduire le risque d’un projet interne trop ambitieux). Malgré la pause du projet interne, la continuité est assurée grâce à PrestaShop en production, et je garde surtout de cette expérience le sentiment d’avoir contribué à quelque chose d’utile et concret, tout en construisant une base solide de compétences pour la suite.