Refonte & migration
WordPress archaïque : headless ou Laravel par phases
Notre site tient debout, mais chaque nouvelle feature nous coûte le double de ce que ça devrait. On reporte la refonte depuis deux ans.
Vous partez d'un WordPress archaïque : lent, plugins fragiles, thème legacy, éditorial ou métier qui freine le produit. Je m'insère dans cet environnement tel qu'il est et je vous aide à moderniser la stack sans « tout casser » : WordPress headless (WPGraphQL ou REST, front React/Next.js), ou admin et API Laravel (REST ou GraphQL) avec migration progressive.
PM/PO technique fractionnel, avec un pied dans le code : selon le mandat, je peux développer moi-même les phases critiques de la transition, ou piloter votre équipe déjà en place (prioriser, séquencer, organiser le changement de stack). Plan écrit, phases successives, sans big bang. On en parle d'abord pour voir le temps et le besoin, puis comment mobiliser mon temps sur le mandat.
WordPress qui tient mais doit évoluer sans migration majeure (comparateur, éditorial, conversion) : voir Produit éditorial à l'échelle.
Cadrer votre refonte Planifier un appelLinkedInbonjour@lucrousseau.com
Le contexte WordPress
Je rentre dans votre WordPress actuel, tel qu'il tourne aujourd'hui, et on trace comment faire évoluer la plateforme : ce qui bloque, quelle stack tient pour le produit, sans big bang. Ce mandat vise une transformation de stack, pas l'évolution au quotidien d'un produit qui tient encore.
Votre WordPress actuel
- Stack en place : thème legacy, plugins empilés, peu d'API, perf et dette qui freinent le produit
- Dette technique et modèle de données difficile à migrer sans risque pour la production
- Équipe en maintenance corrective continue, sans feuille de route claire pour moderniser la stack
Deux pistes : headless ou Laravel API
- Headless : WordPress en CMS, WPGraphQL ou REST, front React/Next.js côté client
- Laravel : administration métier, API REST ou GraphQL, migration progressive par module
- Les deux approches enchaînées par phases, plutôt qu'un choix binaire dès le départ
Comment on avance
Fractionnel, par phases, avec un plan
Pas une refonte à temps plein embarquée chez vous : mandat par phases, rythme et mobilisation définis après un premier échange sur le besoin réel.
Je code la transition ou pilote l'équipe
Sans équipe : j'assume le build (APIs, front headless, modules Laravel) et le plan produit. Avec équipe ou agence : je pilote la séquence, les priorités et les revues, sans remplacer votre tech lead au quotidien.
Phases successives, livrables en prod
Audit, choix de piste, puis tranches qui livrent en production : couche API, premier parcours headless, module sous Laravel. Proprement et vite, sans tunnel de 18 mois sans progrès métier visible.
Stack et contrats fixés avant le build
WPGraphQL, REST, gateway GraphQL, Laravel, React, Next.js : ce qui sert votre cas, pas la stack à la mode. Contrats de données et frontières écrits pour que vos devs et moi puissions build selon les mêmes règles.
Le déroulé
Quatre étapes typiques d'un mandat refonte
Phase 0 (optionnelle) : stabilisation et critères go/no-go
Si la prod est instable, on peut commencer par stabiliser et auditer avant de trancher headless ou Laravel. Livrable : état des lieux, risques, critères pour décider si migration ou évolution continue sur la plateforme éditoriale.
Audit et choix de piste
WordPress actuel (perf, plugins, données, éditorial), puis décision documentée : headless GraphQL/REST, Laravel admin + API, ou séquence des deux.
Plan et ordre de migration
Roadmap par phases, risques, ce qu'on ne migre pas tout de suite, critères de succès par tranche. Rien de gros en build avant ce livrable.
Phases build avec valeur en prod
Strangler, feature flags, coexistence ancien/nouveau : livraison par votre équipe ou par moi selon le mandat. Chaque phase laisse le site utilisable et montre un progrès métier ou perf mesurable.
Handover et suivi allégé
Documentation, runbooks, passation vers l'équipe. Suivi fractionnel optionnel (rythme plus léger) pour tenir la cohérence après la grosse phase de migration.
Comparer
Refonte pilotée en interne vs partenaire produit-système externe
Chaque mandat se cadre par phases écrites. Plateforme éditoriale à fort trafic : la fiche Produit éditorial à l'échelle couvre l'évolution sans migration majeure ; celle-ci couvre la transformation de stack.
| Dimension | Équipe seule sur la refonte | PM/PO technique fractionnel par phases (rythme sur mesure) |
|---|---|---|
| Décision de cap | Souvent noyée dans l'exécution ; le « pourquoi » dérive. | Go/no-go, séquence et critères de succès tenus par un regard externe. |
| Rythme | Big bang ou rattrapage permanent. | Mandat fractionnel calé au besoin ; phases avec valeur livrée, pas refonte temps plein continue. |
| Rôle sur l'équipe | Tech lead interne surchargé ou absent. | Code sur phases clés ou pilotage de l'équipe existante ; plan, séquence et cohérence produit-tech. |
| Engagement | Coût salarial fixe sur toute la durée. | Mandat par phase (puis suivi optionnel plus léger si utile). |
Comment je construis
Fondations techniques
WordPress vers moderne, par étapes : headless, admin Laravel + API, ou les deux en séquence, sans couper la prod.
Objections
Questions fréquentes
Les deux sont possibles, selon ce que vous avez déjà. Je code quand il faut aller vite sur une phase technique précise et que personne n'est disponible pour le faire proprement. Je pilote quand vos devs ou votre agence ont la capacité : je priorise, séquence, clarifie les prérequis et valide la cohérence, sans micro-manager les tickets.
Ça dépend de votre contenu, de l'équipe et de la dette. Souvent : headless (WPGraphQL ou REST + front moderne) si l'éditorial WordPress reste utile ; Laravel admin + API (REST ou GraphQL) si le cœur métier doit sortir du CMS. Parfois les deux, en phases. On tranche à l'écrit avant de coder.
Les deux sont dans le périmètre. WPGraphQL ou REST côté WordPress ; GraphQL côté app ou BFF Laravel si les surfaces et consommateurs le justifient ; REST quand la simplicité et l'équipe le favorisent. Le plan de phase dit quel contrat pour quel module.
Non. Mandat par phases : on se parle pour voir le temps et le besoin requis, puis comment je mobilise mon temps (cadrage, build ou pilotage, suivi plus léger). Pas d'embarquement « refonte 40 h » : votre équipe build, je tiens le plan produit-tech et la séquence.
Non. Vos devs ou votre agence gardent le rythme opérationnel. Je clarifie le système et la séquence ; je ne gère pas les personnes ni les tickets au quotidien.
Deux à quatre semaines de cadrage évitent souvent des mois de rework. La première phase peut être précisément ce cadrage, avec un livrable : plan, architecture cible, ordre de migration.
Ce n'est probablement pas ce mandat. Pour évolution continue (stabiliser, optimiser module par module, comparateur, conversion) sans changer de stack : voir Produit éditorial à l'échelle. Ici, l'enjeu est une modernisation ou migration par phases.
Handover documenté ; suivi fractionnel optionnel si vous voulez garder la cohérence sans poste permanent. Proche du modèle Produit éditorial à l'échelle ou Lancer un SaaS ou un MVP ; voir aussi toutes les situations.
Le rythme convenu structure le travail en profondeur, pas ma disponibilité pour échanger avec vous.
En continu, je prends le temps de vous répondre sur Slack ou le canal que vous préférez. Les urgences hors périmètre passent par le cadre d'urgence défini ensemble (périmètre, priorité, délais).
Prochaine étape
Parlons de votre contexte
WordPress qui freine le produit ? Un appel pour voir comment moderniser la stack (headless, Laravel API, plan par phases) plutôt qu'un big bang sans carte.
- CourrielRéponse sous 24 à 48 hbonjour@lucrousseau.com
- LinkedInParcours ou messageVoir le profil
Pas sûr du profil ? Parcourir les situations ou faire le quiz en deux questions.