Certaines migrations de plateformes se passent sans trop d’accrocs. Celle-ci, non. Voici ce qui s’est réellement passé quand on a fait passer Schweizer Päckli d’OctoberCMS à une pile moderne Laravel et Vue 3 – et ce qui a rendu la tâche plus compliquée qu’elle ne le semblait sur le papier.
Qui est Schweizer Päckli et où est-ce qu’on est intervenu ?
Schweizer Päckli fait quelque chose de plus difficile à réaliser qu’il n’y paraît : ils vendent des colis soigneusement composés, remplis de spécialités régionales suisses authentiques, et ils font en sorte que le tout ressemble à un véritable cadeau plutôt qu’à une simple commande en ligne.
Chaque « Päckli » est assemblé avec soin pour faire découvrir au destinataire un petit bout d’une région suisse spécifique. Le contenu n’est pas générique – les produits sont sélectionnés avec une vraie attention à leur provenance régionale, et c’est ça qui donne tout son caractère au produit. Pour quelqu’un qui cherche à envoyer quelque chose qui a du sens, cette spécificité compte vraiment.
À la mi-2023, l’infrastructure technique qui soutenait tout ça commençait à montrer des signes de fatigue. Chez what., on s’est chargé d’une migration complète de la plateforme, en faisant passer Schweizer Päckli d’OctoberCMS à Laravel et Vue 3, avec Laravel Nova comme backend. Le projet s’est bouclé début 2024.
Pourquoi une migration complète était plus judicieuse que de rafistoler l’ancien système
OctoberCMS avait fait son travail. Mais les limitations s’étaient accumulées au point qu’il n’était plus réaliste de les contourner.
Ajouter de nouvelles fonctionnalités était devenu presque impossible. La dépendance aux plugins du CMS laissait peu de contrôle sur les structures de données sous-jacentes. Et l’expansion vers de nouvelles régions – un véritable objectif stratégique pour Schweizer Päckli – était pour le moins laborieuse.
L’argument en faveur d’une migration complète se résumait à ceci : quand l’architecture elle-même constitue le plafond, les améliorations incrémentielles ne font que repousser l’inévitable. Opter pour Laravel et Vue 3 a donné au projet une base solide :
- De meilleures performances et une extensibilité plus facile
- Des structures de données plus propres avec moins de dépendances aux plugins
- Un backend que le client peut gérer de manière autonome, sans avoir besoin de faire appel à une agence pour les mises à jour courantes
Les défis techniques qui ont ralenti les choses
La mise en place du SSR a été plus difficile que prévu
La partie la plus exigeante du projet a été la configuration du rendu côté serveur (SSR) pour le frontend Vue 3. Comme la boutique de Schweizer Päckli fonctionne comme une application monopage (SPA), c’est le SSR qui la rend explorable et indexable par les moteurs de recherche. Sans ça, la boutique n’existe pratiquement pas pour Google.
Les problèmes venaient d’anciennes bibliothèques JavaScript qui supposaient un environnement navigateur. Dès qu’on essaie de les rendre côté serveur, elles plantent. L’équipe a dû résoudre ces conflits un par un.
Ce qui a compliqué la tâche, c’est une contrainte supplémentaire : le frontend devait rester exactement identique à ce qu’il était auparavant. Le client ne voulait aucun changement visible dans l’interface. L’équipe a donc réécrit les composants internes tout en conservant la même apparence – ce qui a rendu un problème technique en apparence circonscrit nettement plus délicat à gérer.
Migration des données et continuité CSS
Les données existantes devaient être transférées proprement vers de nouveaux schémas, sans perte ni problème d’intégrité. Ce n’est pas le travail le plus passionnant, mais c’est souvent là que les migrations déraillent – discrètement.
La situation avec le CSS et le SCSS était similaire. Des années de feuilles de style datant de l’ère CMS venaient avec leur lot de problèmes habituels : conflits de spécificité, remplacements non documentés, styles liés à du balisage qui n’existait plus. Les faire fonctionner correctement dans les composants Vue 3, sans déclencher une refonte visuelle complète, a demandé beaucoup de patience.
Ce qu’on a appris
Le travail invisible, c’est ce qui compte le plus
Le résultat le plus significatif que personne n’a remarqué, c’est la refonte de la génération de PDF. Les documents fournisseurs ont exactement le même aspect qu’avant en surface. Mais la logique interne a été entièrement reconstruite pour gérer un volume de documents bien plus important que ce que l’ancien système pouvait supporter.
C’est un principe qui vaut la peine d’être intégré : les améliorations qui apportent le plus de fiabilité sur le long terme sont souvent celles que les utilisateurs ne voient jamais. Ce n’est pas une raison de les sauter – c’est au contraire une raison de les protéger contre toute suppression.
Une pile moderne comme condition préalable, pas comme un luxe
Sur l’ancienne plateforme, presque toutes les demandes de nouvelles fonctionnalités se heurtaient au même mur. La réponse revenait toujours à quelque chose comme : « c’est pas possible, ou ça va coûter très cher. » Ce n’est pas seulement un problème technique – ça a des conséquences directes sur l’activité.
Après la migration, ce discours a complètement changé. De nouvelles régions peuvent désormais être ajoutées depuis le backend sans travail de développement. Des fonctionnalités qui étaient auparavant hors de portée sont maintenant faciles à mettre en place.
Les tests automatisés te protègent quand la logique métier évolue
what. a introduit des cas de test qui s’exécutent avant chaque déploiement. Pour une entreprise comme Schweizer Päckli, où la logique autour des colis régionaux, des fournisseurs et des commandes évolue au fil du temps, c’est un vrai filet de sécurité. Ça permet de détecter les problèmes tôt, avant qu’ils n’atteignent les clients.
Ce qui a bien fonctionné
Quelques éléments ont été particulièrement bien mis en place :
- Configuration du CDN : les images, les fichiers JavaScript et CSS sont désormais diffusés via CDN sur les différents domaines régionaux de Schweizer Päckli. Les ressources se chargent plus vite, quelle que soit la version régionale du site sur laquelle le visiteur atterrit. Une décision relativement simple avec un impact disproportionné sur la performance perçue.
- Backend Laravel Nova : le client peut désormais gérer le contenu, les régions et les forfaits sans avoir à faire appel à what. pour les mises à jour courantes. Ce type d’autonomie réduit la dépendance vis-à-vis d’une agence et libère du temps pour les tâches qui nécessitent vraiment une expertise technique.
- Gestion des régions : ajouter une nouvelle région – ce qui demandait auparavant un effort de développement conséquent – est désormais une tâche de backend. Il existe aussi un sélecteur de région qui offre un aperçu rapide de toutes les versions régionales du site, bien utile à mesure que l’entreprise continue de se développer.
Ce qui est encore en cours
La migration était le point de départ, pas la ligne d’arrivée. Schweizer Päckli travaille activement à d’autres améliorations de la boutique – et c’est exactement la bonne approche. La nouvelle architecture prend en charge ce type de développement itératif d’une manière que l’ancien système ne permettait tout simplement pas.
Les sujets en cours incluent des améliorations de la boutique et une expansion régionale plus poussée. L’équipe ne reste pas les bras croisés.
Principaux enseignements de ce projet
Les migrations de plateformes ne sont jamais purement techniques. Les principales contraintes de ce projet étaient d’ordre non technique : conserver l’interface visuellement inchangée, migrer proprement des années de données, et contourner des bibliothèques JavaScript héritées qui n’étaient pas conçues pour les approches de rendu modernes.
Ce qui a créé la valeur la plus durable, ce ne sont pas les livrables les plus spectaculaires. La refonte des PDF, la mise en place du CDN, la suite de tests : ce sont les améliorations structurelles qui, discrètement, éviteront des problèmes pendant des années. Ce sont aussi celles qu’il est le plus facile de supprimer quand les délais se resserrent – et c’est exactement pour ça qu’il ne faut pas le faire.
Si tu utilises un CMS vieillissant et que tu cherches des raisons de repousser une migration, le coût de ce retard est probablement plus élevé qu’il n’y paraît. Chaque demande de fonctionnalité à laquelle on répond « c’est pas possible » a des conséquences commerciales, pas seulement techniques.
Si tu envisages une migration de plateforme ou une refonte de site web, what. aide les entreprises à mener à bien exactement ce type de processus, depuis les exigences et la sélection du système jusqu’à la mise en œuvre et la mise en ligne. Jette un œil aux services de refonte et de développement de sites web de what. pour voir comment on s’y prend.
