Le projet en un coup d’œil
Pages, sections, langues, contacts et configuration donnent à Maison Jean la maîtrise de ses contenus dans un CMS sur mesure.
Les tarifs évoluent régulièrement sans remettre en cause l’ensemble du site ni son exploitation quotidienne.
Symfony 8 reprend les contenus, enrichit le back-office et ajoute un catalogue de location relié aux devis, disponibilités et réservations.
Maison Jean accompagne Dawap depuis le 27 juin 2019. Le premier enjeu n’était pas de construire un logiciel de production ou une chaîne de commandes : il fallait donner à l’entreprise un site sur mesure et un espace d’administration capable de faire vivre ses pages, sections, tarifs, contacts et informations de présentation.
Cette première génération sous Symfony 2.8 a traversé plusieurs années d’exploitation. Les évolutions de tarifs de 2019, 2020, 2021, 2022, 2023 et 2024 montrent une réalité plus parlante qu’une livraison ponctuelle : le site devait rester utile, modifiable et maintenable au rythme du commerce.
En 2026, la question devient plus large. Il faut reconstruire la fondation technique sous Symfony 8, reprendre les contenus et les médias, moderniser le back-office, puis accueillir un nouveau parcours de location avec catalogue, disponibilités, devis PDF, validation et réservation.
Le chantier progresse sans sacrifier l’existant. L’ancienne application reste disponible pendant qu’une nouvelle pile est préparée et contrôlée séparément. La dernière étape documentée, le 29 mai 2026, organise une bascule de production réversible plutôt que de déclarer prématurément la migration terminée.
Cette étude de cas raconte donc un travail continu de migration d’application Symfony : préserver ce qui fait déjà tourner le site, redessiner les responsabilités du CMS, puis ouvrir de nouveaux usages sans transformer la mise en ligne en pari.
1. Un site de commerce de proximité qui doit rester simple à administrer
Présenter les univers Maison Jean, tenir les informations à jour et prolonger la relation par des services concrets
Le site public présente plusieurs facettes de Maison Jean : boucherie, buffet froid, mariage, découverte de l’entreprise, tarifs et contact. Chacune possède ses contenus propres, mais toutes doivent conserver une navigation, une identité et des informations de contact cohérentes.
L’équipe ne peut pas dépendre d’une intervention technique pour chaque correction éditoriale. Pages, sections, textes, images, horaires, tarifs ou membres de l’équipe doivent pouvoir être administrés depuis des écrans adaptés, avec un ordre et une visibilité maîtrisés.
Le temps long change aussi la nature du projet. Une architecture acceptable en 2019 finit par porter des versions vieillissantes et des conventions difficiles à maintenir. Moderniser ne consiste alors pas à redessiner seulement la page d’accueil : il faut reprendre les contenus, les données, les accès et le mode de livraison.
Enfin, le site devient le point d’entrée d’un service de location. Le visiteur doit comprendre l’offre, vérifier une disponibilité, composer une demande et obtenir un document ; l’équipe doit ensuite contrôler le dossier, réserver le matériel et suivre le planning.
2. Conserver la continuité tout en changeant de fondation
Une migration progressive, enrichie par domaines et préparée jusqu’au retour arrière
La nouvelle génération est construite dans un répertoire Symfony 8 distinct de l’application historique. Cette coexistence rend les deux états lisibles : le site en service conserve son fonctionnement pendant que le futur front, son modèle de données et son administration gagnent leur autonomie.
La reprise de l’application web est découpée par capacités. Les pages publiques et le contact forment d’abord une base fonctionnelle ; le CMS, les tarifs, la galerie, l’équipe et l’historique enrichissent ensuite le socle ; la publication sociale et la location deviennent enfin des domaines à part entière.
Le modèle évolue avec quarante migrations Doctrine. Elles rendent visibles les ajouts successifs au lieu de cacher la transformation derrière une base recréée d’un seul bloc. Onze fichiers de tests ciblent notamment le front, le CMS, le tableau de bord, le profil, la sécurité, la location et la publication sociale.
La préparation de production suit la même logique. Une pile candidate indépendante reçoit la base et les médias de préproduction, puis répond sur un domaine technique. La bascule du domaine arrive en dernier, avec sauvegardes et procédure de retour vers l’application historique.
Cette trajectoire met en évidence ce qu’un audit technique avant migration doit éclairer sur un site de cette nature : quels contenus et médias reprendre, quelles fonctions du CMS conserver, quels parcours créent des données et dans quelles conditions revenir à l’ancienne version. La décision de bascule dépend de ces réponses, au-delà du changement de framework.
3. Commencer par un site que Maison Jean peut réellement faire vivre
Le 27 juin 2019, la première génération pose le front et son administration
Le projet naît avec une structure complète de site plutôt qu’avec une page vitrine isolée. L’application possède ses contrôleurs publics, ses gabarits, ses ressources, un espace d’administration et une procédure d’installation qui prépare la configuration nécessaire.
Le contenu est pensé comme une donnée administrable. Pages, sections et sujets de contact existent dans le modèle ; les langues et la configuration complètent ce socle afin que le rendu public ne dépende pas uniquement de textes enfermés dans les gabarits.
La livraison distingue déjà les environnements. Quatre constructions Docker séparent PHP et Nginx pour la préproduction et la production. Le site peut ainsi être préparé avec les mêmes rôles techniques que ceux qui l’exécuteront ensuite.
Cette première étape donne la vraie nature du projet : un site internet sur mesure doublé d’un CMS, conçu pour durer et évoluer avec l’activité de Maison Jean.
4. Faire tenir le site public et le CMS dans une même application Symfony 2.8
Une première architecture adaptée au contexte de 2019
L’application historique repose sur Symfony 2.8. Le front affiche les pages et les sections configurées ; le back-office porte les opérations de création, modification, classement et suppression dont l’équipe a besoin pour administrer le site.
Seize contrôleurs applicatifs se répartissent entre le rendu public, la mise en page, l’envoi de fichiers, l’installation et l’administration. Onze entités décrivent notamment la configuration, les pages, les sections, les contacts, les langues et les utilisateurs.
Le modèle distingue les pages ordinaires des pages système, ainsi que les sections éditoriales des sections système. Cette séparation permet de protéger les éléments structurants tout en laissant de la liberté sur les contenus courants.
La génération n’est pas présentée comme un produit figé ou parfait. Elle remplit son rôle historique, puis devient la référence fonctionnelle à comprendre lorsque la modernisation technique s’impose.
5. Donner une place précise aux pages, sections et sujets de contact
Le back-office historique est le prolongement direct du site
Une page organise un parcours public ; une section découpe son contenu ; les variantes système conservent les éléments qui ne doivent pas être manipulés comme une page libre. Le CMS reflète ainsi la structure visible plutôt qu’une collection indistincte de champs.
Les écrans d’administration couvrent pages, pages système, sections, sections système, diapositives, configuration, contacts, sujets de contact et utilisateurs. Chaque responsabilité possède son contrôleur au lieu d’être concentrée dans une interface générique difficile à relire.
Le contact est également traité comme une donnée. Les sujets proposés au visiteur sont administrables, et les demandes reçues rejoignent leur espace de consultation. La relation entre formulaire public et traitement interne existe donc dès la première génération.
Cette granularité devient précieuse en 2026 : elle fournit une carte des responsabilités à préserver, même lorsque les classes, les routes et le stockage changent complètement.
6. Prouver la durée du projet par les mises à jour tarifaires
Le site accompagne les changements de l’activité entre 2019 et 2024
Un site d’entreprise reste utile si ses informations sensibles peuvent suivre le réel. L’historique montre des ajustements tarifaires dès décembre 2019, puis en octobre 2020, septembre et décembre 2021, novembre 2022, décembre 2023 et novembre 2024.
Ces interventions régulières disent quelque chose de la maintenance : le projet n’a pas été livré puis abandonné. Il a continué à porter une information commerciale mise à jour au fil des années.
La tarification est un bon révélateur de dette. Lorsqu’un changement récurrent demande de toucher une structure trop ancienne ou trop couplée, le coût ne vient plus du contenu lui-même mais de la difficulté à le faire évoluer sereinement.
La nouvelle génération transforme donc les tarifs en objets administrables dédiés. L’évolution métier qui revenait régulièrement dispose désormais d’un modèle, d’écrans et d’un ordre d’affichage explicites.
7. Choisir la migration quand maintenir ne suffit plus
Moderniser le socle sans réécrire l’histoire du site
Entre Symfony 2.8 et Symfony 8, les conventions de PHP, de sécurité, de persistance et de livraison ont profondément changé. Une simple mise à jour de dépendances ne peut pas absorber proprement cet écart tout en garantissant les parcours publics et administratifs.
La réponse consiste à reconstruire une application distincte. PHP 8.4, Symfony 8, Doctrine ORM 3 et les composants récents de sécurité, validation, messagerie et courrier composent le nouveau socle.
Ce choix évite de transformer l’ancien code en chantier permanent. La génération historique reste lisible et disponible ; la nouvelle architecture peut adopter ses propres domaines, ses migrations et ses tests sans imposer une transition incomplète au site en service.
C’est le cœur d’une refonte de logiciel existant : conserver les responsabilités utiles, pas les contraintes techniques qui les entouraient en 2019.
8. Faire cohabiter les deux générations jusqu’au dernier moment
L’ancien site reste la solution de repli pendant la construction de Symfony 8
Le socle Symfony 8 vit à côté de l’application existante. Cette organisation matérialise la transition : les deux générations peuvent être préparées séparément et chaque parcours basculé au moment opportun.
La coexistence protège aussi le travail de reprise. Les contenus et médias de la préproduction peuvent être importés dans une pile candidate, puis contrôlés sur un hôte technique avant que le domaine principal ne change de destination.
La production historique n’est pas modifiée pendant ces vérifications. Le changement final porte sur le routage du domaine entre deux piles déjà identifiées, et non sur une copie de fichiers réalisée directement dans l’environnement en service.
Cet arbitrage coûte davantage de préparation, mais il réduit le nombre d’inconnues réunies dans une seule opération. Code, données, médias, conteneurs et proxy peuvent être vérifiés à leur propre étape.
9. Reconstruire les parcours publics avant d’étendre le produit
Accueil, boucherie, buffet, mariage, découverte, contact et tarifs forment le socle visible
La nouvelle application expose des routes dédiées pour l’accueil, la boucherie, le buffet froid, le mariage, la découverte de Maison Jean, le contact et les tarifs. Ces pages structurantes ne dépendent pas du mécanisme de page libre pour exister.
Une route CMS complète ce noyau pour les contenus additionnels. Elle recherche une page par chemin ou par code et refuse proprement ce qui n’existe pas, ce qui maintient une frontière entre le routage connu et les pages administrables.
Les informations communes du front, comme les réglages généraux ou la visibilité de certaines sections, sont résolues dans la nouvelle application. Le back-office peut donc agir sur le rendu sans dupliquer la logique dans chaque gabarit.
Le front devient une façade stable au-dessus de plusieurs domaines : contenu, galerie, tarifs, contact, équipe et location. Cette composition prépare l’évolution sans transformer chaque nouvelle fonction en page indépendante du reste.
10. Repenser le CMS autour de pages et de sections ordonnées
Une structure éditoriale explicite sous Symfony 8
CmsPage et CmsSection portent la structure principale. L’administration permet de créer une page, de la consulter, de la modifier, de gérer son média d’en-tête et d’ordonner ses sections.
Les sections disposent de leurs propres opérations de création, modification, suppression et activation. Leur position peut être changée depuis la page, ce qui relie l’organisation éditoriale au rendu public attendu.
Le mécanisme de page CMS ne remplace pas les parcours majeurs. Il complète les routes dédiées avec une souplesse maîtrisée, sans demander au même objet de représenter indistinctement la page de contact, la location et tout contenu futur.
Cette séparation rend la maintenance plus prévisible. Une évolution du parcours de location ne fragilise pas le modèle des pages, et une nouvelle page éditoriale n’a pas besoin d’ajouter un contrôleur complet.
11. Administrer les blocs de contenu sans enfermer tout le site dans un éditeur unique
Contenus structurés, snippets et mises à jour ciblées
ContentBlock complète les pages et sections. Le back-office propose une liste, une vue des blocs, la création, la modification et la suppression des contenus administrables.
Une action de mise à jour en ligne permet de modifier un contenu ciblé. Des snippets identifiés par une clé disposent également de leur écran, ce qui convient aux fragments réutilisés qui ne justifient pas une page complète.
Le choix protège la structure du site. Les zones qui ont besoin d’un modèle précis conservent leur entité dédiée ; les textes et fragments plus souples passent par les blocs sans imposer une table particulière à chaque phrase.
Le CMS sur mesure trouve ici son équilibre : assez d’autonomie pour le quotidien éditorial, assez de structure pour éviter que toutes les responsabilités fonctionnelles disparaissent dans un champ de texte riche.
12. Relier le formulaire public à une file de demandes traitables
Le message ne se termine pas à l’envoi du courrier électronique
La route de contact accepte l’affichage et la soumission. Les données saisies sont validées, puis une ContactRequest conserve la demande dans le modèle de la nouvelle application.
Le back-office liste les demandes, ouvre leur détail et permet de basculer leur état de traitement. Une demande peut également être supprimée par une action protégée, une fois sa gestion terminée selon les règles de l’équipe.
Les informations de contact de la page d’accueil et les plages d’ouverture disposent de leur propre administration. Adresse, présentation et horaires ne sont donc pas mélangés avec les messages envoyés par les visiteurs.
Le gain observable est une continuité de parcours : le visiteur soumet depuis le front, l’équipe retrouve depuis l’administration, puis distingue ce qui reste à traiter de ce qui a déjà été pris en charge.
13. Transformer les tarifs en cartes administrables
Un besoin récurrent devient une capacité du produit
TariffCard représente les éléments tarifaires de la nouvelle génération. Le back-office peut les créer, les modifier, les supprimer, changer leur visibilité et maîtriser leur ordre.
La page publique des tarifs charge ces cartes actives au moment du rendu. La donnée affichée n’est plus seulement un morceau de gabarit à retrouver lorsqu’un prix ou une présentation évolue.
Ce modèle répond directement à l’histoire du site. Les modifications répétées entre 2019 et 2024 ne sont pas racontées comme un incident ; elles deviennent la justification d’un écran conçu pour la prochaine modification.
L’équipe gagne une action plus courte et mieux bornée. Le développeur conserve la responsabilité du composant et de ses règles ; l’administrateur peut gérer les éléments commerciaux qui doivent naturellement changer.
14. Donner aux galeries et aux médias leur propre cycle de vie
Catégories, images, ordre et visibilité dans le back-office
GalleryCategory et GalleryImage organisent les médias éditoriaux. L’administration permet de créer les catégories, d’ajouter les images, de les modifier, de changer leur catégorie et de régler leur position.
L’activation existe aux deux niveaux. Une catégorie peut être masquée sans supprimer son contenu ; une image peut être retirée du rendu tout en restant dans l’espace d’administration.
Le déplacement de position évite d’encoder l’ordre dans le nom des fichiers ou dans le gabarit. Le média devient un contenu ordonné, relié à sa catégorie et piloté depuis le même back-office que le reste du site.
La nouvelle génération prévoit aussi un traitement spécifique des images de location. Résolution de chemins et optimisation restent dans des services dédiés afin que le contrôleur ne porte pas seul le stockage et la transformation des fichiers.
15. Structurer l’équipe, les vidéos et l’histoire de Maison Jean
Des contenus de présentation qui méritent mieux qu’un bloc monolithique
TeamMember représente les personnes affichées dans la présentation de l’équipe. Chaque membre peut être créé, modifié, ordonné, activé ou supprimé depuis une interface dédiée.
TeamVideo sépare les vidéos de cette liste de personnes, tandis que TeamSectionSetting porte les réglages de la section. Une modification de la présentation globale ne demande donc pas de détourner un membre fictif ou une page générique.
TimelineEvent organise les jalons historiques. L’administration peut ajouter, modifier, masquer ou retirer un événement, ce qui donne à la page de découverte une chronologie maintenable.
Ces objets traduisent une intention éditoriale précise : Maison Jean peut faire évoluer sa présentation, son équipe et son histoire sans perdre l’ordre ni la nature de chaque élément.
16. Ajouter la location comme un domaine, pas comme un formulaire isolé
Catégories, articles, médias, prix, caution et quantité disponible
La location arrive dans la trajectoire Symfony 8 en mars 2026. RentalCategory classe l’offre ; RentalItem décrit chaque matériel ; RentalItemMedia lui associe plusieurs visuels ordonnés et activables.
Le catalogue public charge les catégories actives et les articles actifs avec leurs relations. Le visiteur peut ainsi parcourir une offre cohérente plutôt qu’une liste de libellés maintenue séparément du stock et des images.
Chaque article conserve les informations utilisées par le calcul : prix de base, prix journalier, montant de caution et quantité. Ces données restent sur l’objet proposé, puis sont recopiées dans les lignes de devis au moment de la demande.
Ce dernier point protège l’histoire commerciale. Si le tarif d’un article change plus tard, un devis déjà créé garde le nom, le prix, le nombre de jours, le total et la caution qui appartenaient à sa demande.
17. Calculer la quantité réellement disponible pour une journée
Les réservations existantes participent à la réponse donnée au visiteur
Le parcours de location demande une date de début et une date de fin, avec une règle actuelle claire : la réservation publique se fait sur une seule journée. Une période incohérente ou étendue reçoit une réponse explicite.
RentalAvailabilityCalculator rapproche les articles actifs et les réservations afin de calculer la quantité minimale disponible sur la période demandée. Le front peut interroger cette capacité par une réponse JSON dédiée.
La disponibilité n’est pas vérifiée une seule fois à l’affichage. Elle est recalculée lors de la soumission du devis, puis de nouveau au moment de sa validation, car d’autres réservations peuvent avoir été enregistrées entre ces étapes.
Cette répétition est un arbitrage métier essentiel. L’interface aide à choisir, mais seule une vérification au moment de l’action engageante peut empêcher de confirmer une quantité devenue indisponible.
18. Faire du devis de location un document et un enregistrement métier
Sélection, calcul, caution, PDF et durée de validité restent reliés
Le visiteur choisit au moins un article et une quantité. Le serveur recharge les articles par leur identifiant, ignore ce qui n’est plus actif et calcule chaque ligne à partir de la durée, du prix de base, du prix journalier et de la caution.
La somme estimée et la caution totale rejoignent RentalQuoteRequest. Chaque RentalQuoteRequestLine conserve un instantané du nom et des conditions de l’article, ce qui rend le dossier relisible même lorsque le catalogue évolue ensuite.
Le PDF du devis fait partie des éléments obligatoires du parcours. Il peut arriver comme fichier ou comme contenu encodé, puis son chemin est rattaché à la demande. Une notification est préparée après l’enregistrement réussi.
La demande reçoit enfin un jeton aléatoire et une date d’expiration à quatorze jours. Le document, ses lignes, les coordonnées du client et le futur acte de validation appartiennent ainsi au même dossier.
19. Transformer une validation de devis en réservation contrôlée
Le lien public ne suffit pas : état, jeton, expiration et stock sont revérifiés
Le lien de validation contient l’identifiant de la demande et son jeton. L’application refuse une demande introuvable, un jeton différent, un devis déjà traité ou un lien arrivé au-delà de sa date d’expiration.
Avant toute confirmation, les articles et leurs quantités sont reconstruits depuis les lignes du devis. La disponibilité est recalculée sur la date choisie afin qu’une validation tardive ne dépasse pas le stock réellement restant.
Lorsque les contrôles passent, une RentalReservation est créée. Ses lignes reprennent le matériel, son nom, sa quantité et sa caution ; la réservation devient effective et le devis reçoit son état validé avec sa date.
Le résultat est une chaîne traçable : catalogue, demande chiffrée, validation, réservation et occupation du stock. Chaque étape possède son objet au lieu d’être résumée par un courrier électronique difficile à rapprocher du planning.
20. Outiller le traitement des locations depuis le back-office
Catalogue, devis, réservations, planning et images dans un même domaine
L’administration gère les catégories et articles, leur visibilité, leurs médias et leur ordre. Les demandes de devis disposent d’une liste et d’un détail, puis peuvent être validées, refusées ou archivées selon leur état.
Les réservations ont leur propre vue. L’équipe peut créer une réservation, l’annuler, la réactiver ou la supprimer, puis consulter un planning qui rassemble les engagements enregistrés.
La gestion des images va au-delà d’un simple téléversement. Ajout, édition, suppression, réordonnancement, rotation, recadrage, effacement et réglage de lumière possèdent des actions dédiées, avec des réponses asynchrones pour les traitements concernés.
Ce périmètre fait de la location une fonctionnalité exploitable. Le front attire et collecte la demande ; le back-office permet à l’équipe d’entretenir l’offre, de décider sur les devis et de relire l’occupation du matériel.
21. Préparer une publication sociale pilotable sans la présenter comme déjà active
Programmation, canaux, états et mode simulation dans la nouvelle génération
SocialPost et SocialPostPublication distinguent le contenu éditorial de sa diffusion sur chaque canal. Une publication peut être préparée pour Facebook, Instagram ou TikTok, suivie par état et retrouvée dans le flux affiché sur le site.
Le back-office permet de créer un post, de le modifier, de choisir ses canaux et de lancer ou retirer sa publication locale. Une commande traite également les publications planifiées qui arrivent à échéance.
La configuration prévoit les adresses d’API, versions, comptes et jetons de chaque plateforme. Elle prévoit surtout un mode simulation administrable : le circuit peut être essayé sans confondre une exécution contrôlée avec une diffusion réelle.
Cette capacité reste donc formulée avec sa limite exacte. Le logiciel prépare et teste l’orchestration sociale ; les éléments disponibles ne suffisent pas à affirmer que les trois canaux publient déjà en production avec les comptes définitifs.
22. Replacer les accès administratifs dans les standards du nouveau socle
Connexion, profil, protections de formulaire et actions explicites
BackOfficeUser porte les utilisateurs de la nouvelle administration. Une route de connexion dédiée ouvre le back-office, le tableau de bord constitue son point d’entrée et le profil permet à l’utilisateur de gérer ses propres informations.
Les opérations qui modifient ou suppriment une donnée passent par des méthodes HTTP bornées et des jetons CSRF. Le front et l’administration ne partagent pas une route universelle capable d’exécuter indistinctement toutes les actions.
Les secrets de publication sociale sont lus par une configuration d’exécution qui peut combiner les réglages administrés et les valeurs d’environnement. Ils ne sont pas exposés au front ni utilisés comme contenu éditorial.
La migration modernise ainsi plus que la version du framework. Elle redéfinit les portes d’entrée, les responsabilités des contrôleurs et la façon dont une action sensible est autorisée puis tracée dans son domaine.
23. Découper Symfony 8 entre contenu, location, utilisateurs et infrastructure
Vingt-sept entités sans effacer les frontières métier
Le domaine Content rassemble pages, sections, blocs, contacts, tarifs, galeries, réglages, équipe, histoire et publication sociale. Location isole articles, médias, devis, lignes, réservations et disponibilités. User conserve l’identité administrative.
Les contrôleurs et services Symfony 8 se trouvent dans l’infrastructure. Ce découpage évite que les entités dépendent des détails du routage ou du rendu, tout en gardant des parcours lisibles pour le front et le back-office.
Vingt-deux contrôleurs exposent les pages publiques et les différentes zones d’administration. Les responsabilités volumineuses, comme le calcul de disponibilité ou le traitement des images, disposent de services spécifiques au lieu d’être répétées dans les gabarits.
L’architecture reste proportionnée au produit. Il ne s’agit pas de créer une abstraction pour chaque champ, mais de donner une frontière aux domaines qui possèdent leurs propres règles et leur propre rythme d’évolution.
24. Faire de chaque évolution de données une étape explicite
Quarante migrations Doctrine et onze fichiers de tests accompagnent le nouveau socle
Le modèle Symfony 8 ne naît pas dans son état final. Quarante migrations retracent l’ajout et l’ajustement des structures nécessaires au CMS, aux contenus, à la publication sociale et à la location.
Cette progression permet de faire évoluer une base existante sans demander sa recréation complète. Chaque changement de schéma peut être identifié, appliqué dans l’ordre et rapproché de la capacité qui l’a rendu nécessaire.
Les tests couvrent des contrôleurs du front et du back-office : pages publiques, flux social visible, CMS, blocs de contenu, tableau de bord, profil, sécurité, location et réglages de publication. Un service de résolution des chemins de médias possède également son contrôle ciblé.
La présence de ces tests ne prouve pas à elle seule une couverture totale. Elle apporte en revanche des points de contrôle concrets sur les parcours qui doivent rester stables pendant la préparation de la migration.
25. Construire une pile candidate indépendante avant de toucher au domaine
Base et médias repris, application démarrée et réponses HTTP contrôlées
La préparation du 29 mai 2026 crée une pile candidate Symfony 8 séparée de la production historique et de la préproduction. Elle possède son propre projet de conteneurs et peut être jointe par un hôte technique.
La base et les médias sont importés depuis la préproduction Symfony 8. Le candidat n’est donc pas testé uniquement avec une base vide : ses écrans doivent fonctionner avec les contenus et fichiers préparés pour le futur environnement.
Des validations HTTP sont réalisées en résolvant l’hôte technique vers le serveur candidat. La procédure demande également de contrôler l’accueil, la location et la connexion d’administration avant d’autoriser la suite.
Cette pile indépendante réduit la durée de l’étape finale. Le domaine ne doit changer de destination qu’après le démarrage des services, l’application des migrations, la présence des médias et la vérification des routes importantes.
26. Réduire la mise en production à un changement de routage maîtrisé
Le domaine quitte l’ancien proxy seulement lorsque le candidat est prêt
Le plan de production ne remplace pas les fichiers au cœur de la pile historique. Il prépare Symfony 8 ailleurs, puis retire le domaine Maison Jean de l’ancien proxy avant de l’ajouter au nouveau.
Cette séquence rend la responsabilité de chaque composant visible. L’ancienne application continue d’exister ; la nouvelle est déjà démarrée ; le proxy décide simplement laquelle reçoit la requête publique.
Les critères de décision incluent les tests applicatifs, la construction des ressources front, le contrôle des pages principales, les sauvegardes et une décision explicite sur les fonctions de courrier et de publication sociale.
Le dernier état disponible documente et prépare cette bascule. Il ne permet pas d’affirmer que le domaine public a définitivement quitté Symfony 2.8 ; la fiche conserve donc la distinction entre candidat prêt et migration achevée.
27. Prévoir le retour arrière avant d’ouvrir le nouveau site
Sauvegardes, ancienne pile intacte et fenêtre de contrôle courte
La procédure demande une sauvegarde de la base historique, une sauvegarde de la base Symfony 8 et une archive des médias. Les fichiers de la pile legacy sont également conservés dans le dossier de sauvegarde de l’opération.
Le retour arrière consiste à retirer le domaine du nouveau proxy, puis à le rétablir sur Nginx dans la pile historique. L’ancienne production restant intacte, elle peut reprendre le trafic sans reconstruction improvisée.
Le plan nomme aussi sa limite : les données écrites après la bascule ne reviennent pas automatiquement dans l’ancienne base. La fenêtre de vérification doit donc rester courte et les formulaires publics doivent faire l’objet d’une décision avant l’opération.
Cette honnêteté renforce la qualité du dispositif. Un rollback n’est pas seulement une commande technique ; il faut également savoir ce qu’il advient des contacts, devis et réservations créés pendant la période de transition.
28. Assumer quatre arbitrages qui structurent la migration
La continuité de service guide les choix techniques et fonctionnels
Premier arbitrage : reconstruire plutôt que tenter une mise à niveau directe de Symfony 2.8 à Symfony 8. L’écart de générations justifie une nouvelle fondation, tandis que l’ancien site reste la référence disponible pendant la reprise.
Deuxième arbitrage : préserver des routes dédiées pour les parcours majeurs et réserver le CMS libre aux pages complémentaires. Le front gagne en souplesse sans dissoudre contact, tarifs ou location dans une page générique.
Troisième arbitrage : revérifier le stock de location au moment de la demande puis de la validation. Une information affichée quelques minutes plus tôt n’est pas traitée comme une garantie lorsque plusieurs dossiers peuvent se croiser.
Quatrième arbitrage : livrer la publication sociale avec un mode simulation et raconter cette limite. Une intégration préparée, paramétrable et testable possède déjà de la valeur sans être présentée comme une diffusion réelle non démontrée.
29. Rendre les gains opérationnels lisibles
La solution et la procédure montrent ce qui devient plus simple, plus sûr ou plus lisible
Le contenu gagne une structure moderne. Pages, sections, blocs, tarifs, galeries, équipe, vidéos et histoire peuvent évoluer dans leur domaine, avec ordre et visibilité, plutôt que par des modifications dispersées dans les gabarits.
La relation client gagne une file de traitement. Le message public devient une demande conservée ; le devis de location devient un dossier chiffré ; sa validation devient une réservation qui compte dans la disponibilité future.
La maintenance gagne une trajectoire explicite. Migrations de données et tests ciblés accompagnent l’évolution du modèle, tandis que la pile candidate permet de vérifier code, base et médias avant le changement de domaine.
La production gagne une solution de repli. L’ancien site reste intact, les sauvegardes précèdent l’opération et le retour du domaine vers l’ancienne pile est décrit avec sa limite sur les écritures réalisées après la bascule.
30. Suivre une demande de location de la vitrine jusqu’au planning
Un parcours concret traverse le front, le calcul et le back-office
Un visiteur ouvre la page de location, choisit une journée et consulte les articles classés par catégorie. L’application calcule la quantité encore disponible à partir des réservations qui recouvrent cette date.
Il sélectionne le matériel et les quantités. Le serveur recharge le catalogue actif, recalcule les lignes, le total et la caution, contrôle le stock puis associe le PDF du devis à une demande contenant ses coordonnées.
Le dossier reçoit ses lignes figées et un lien de validation valable quatorze jours. Lorsqu’il est utilisé, l’état du devis, le jeton, l’expiration, les articles et la disponibilité sont tous contrôlés une nouvelle fois.
Une validation réussie crée la réservation et ses lignes. L’équipe peut ensuite retrouver le devis, son document, la réservation et l’occupation dans le back-office et son planning : la page publique et l’exploitation partagent enfin le même fil.
31. Achever la bascule puis observer les parcours qui écrivent des données
Le candidat est prêt ; la prochaine preuve vient de l’exploitation Symfony 8
La prochaine étape est la décision de bascule, après validation de l’environnement candidat et des critères de mise en production. Elle doit conserver la fenêtre courte prévue pour tester le domaine public sans accumuler des écritures impossibles à reprendre en cas de retour arrière.
Le contact et la location méritent une attention particulière : ils créent des données utiles dès l’ouverture. Leur surveillance permet de vérifier non seulement que les pages répondent, mais que les demandes, notifications, PDF, validations et réservations suivent leur cycle.
La publication sociale peut ensuite quitter le mode simulation canal par canal, une fois les comptes, droits, médias et réponses des plateformes contrôlés. Son activation doit rester distincte de la réussite de la migration du site elle-même.
Maison Jean illustre ainsi ce qu’une refonte de back-office sur mesure doit protéger : l’autonomie éditoriale, la continuité des données, les nouveaux services et la possibilité de revenir en arrière tant que la nouvelle exploitation n’est pas confirmée.
32. Conclusion
Pourquoi ce projet donne envie de travailler avec Dawap
Depuis juin 2019, Maison Jean n’est pas un projet résumé à une livraison. Le site Symfony 2.8 et son CMS ont accompagné plusieurs années d’évolution, notamment sur les tarifs, avant que la modernisation de la fondation ne devienne un chantier à part entière.
La génération Symfony 8 reprend les pages et les contenus, structure le contact, les tarifs, les médias, l’équipe et l’histoire, puis ajoute un domaine de location complet. Catalogue, disponibilité, devis PDF, validation, réservation et planning restent reliés par des données explicites.
La qualité du projet tient enfin à sa mise en production préparée : pile candidate indépendante, base et médias importés, contrôles HTTP, sauvegardes, changement de proxy et retour arrière documenté. C’est cette continuité que nous recherchons dans une migration Symfony : faire progresser le produit sans demander à l’entreprise de parier son site sur une bascule irréversible.
