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.
