Un complexe de trois univers à Marcory, Abidjan : restaurant, night club et salle de réception. Trois espaces publics, trois back-offices, un seul socle Laravel. Ce que cette réalisation prouve pour un groupe multi-sites en France, en Belgique, en Suisse
À Marcory, à Abidjan, le complexe Groupe Empire réunit trois activités sous une même adresse : le restaurant L'Heritage, le Calypso Night Club et la salle de réception Akwaba. Trois marques, trois équipes, trois clientèles. Un dîner, une soirée et une réception n'ont ni le même parcours, ni les mêmes questions, ni le même moment de décision.
La première vitrine disait tout cela d'un seul bloc. Un visiteur venu chercher une salle pour un séminaire y croisait l'affiche du samedi soir. Une équipe attendait la direction pour corriger un horaire ou remplacer une photo. Rien n'était faux, mais rien n'aidait vraiment à décider.
Je retrouve ce problème chez des clients en France, en Belgique, en Suisse et au Canada : un hôtel avec son restaurant et ses salles de réunion, une brasserie qui ouvre un second lieu, une franchise avec plusieurs adresses. L'identité change d'un lieu à l'autre, le socle technique reste le même.
J'ai livré une application Laravel qui alimente plusieurs espaces publics distincts. Le site du complexe sert de portail : il présente le groupe et oriente vers le bon univers. Chaque univers dispose ensuite de son propre espace, avec son identité, ses pages, ses photos, ses horaires et son discours.
Trois back-offices, un par univers. Le responsable du restaurant publie sa carte et ses horaires et traite les demandes de table. Celui du club gère les soirées et les réservations. L'équipe de la salle suit les demandes de devis pour les mariages, les séminaires et les galas. Chacun ne voit que son périmètre.
Les parcours de contact sont séparés et adaptés au métier : une réservation de table ne se remplit pas comme une demande de devis pour une réception, qui n'a rien à voir avec une réservation de soirée. Les champs, le ton et le délai de réponse attendu changent. Quand un projet traverse plusieurs univers, un dîner suivi d'une réception par exemple, le contact général coordonne et transmet à chaque équipe sans mélanger les ambiances.
Côté médias, une bibliothèque partagée : une photo déposée une fois ressort au bon format dans chaque univers. Côté référencement, chaque entité déclare ce qu'elle est dans ses données structurées, pour que Google distingue un restaurant, un club et une salle de réception au lieu de les confondre dans une page unique.
Laravel, parce que le besoin dépassait la vitrine. Trois installations séparées auraient voulu dire trois mises à jour de sécurité, trois sauvegardes, trois hébergements et trois occasions de divergence. Un seul dépôt garde le socle commun et laisse chaque univers vivre sa vie.
Le cloisonnement est structurel. Un middleware résout l'univers demandé et le rend disponible dans toute la requête ; les contenus, les médias et les demandes sont rattachés à un univers, et les requêtes sont filtrées à ce niveau. Un gestionnaire de salle n'a aucune raison d'accéder aux réservations du club, et il ne le peut pas. Les rôles et permissions suivent la même logique : chaque équipe agit dans son périmètre, la direction garde la vue d'ensemble.
Les formulaires sont validés côté serveur, protégés contre le spam et routés vers la bonne équipe, avec une journalisation minimale des demandes. Sur les données personnelles, j'applique la logique qui prévaut en Europe : on collecte ce qui sert, on explique pourquoi, on conserve le moins longtemps possible. Le complexe est en Côte d'Ivoire, la rigueur ne s'arrête pas à une frontière.
Pour les données structurées, je m'appuie sur les types décrits par schema.org, et l'ensemble tient dans une application Laravel unique. Peu de JavaScript, du cache, des images dimensionnées : beaucoup de visiteurs arrivent depuis un téléphone, parfois avec un réseau moyen. Une page lente est une page perdue, à Abidjan comme à Lyon ou à Montréal.
Chaque univers a désormais sa porte d'entrée, son discours et son équipe aux commandes. Le visiteur qui cherche une table, une salle ou une nuit trouve une réponse claire, et sa demande arrive directement au bon endroit au lieu de s'entasser dans une boîte partagée.
Un changement de carte ou d'horaire ne passe plus par une file d'attente : la personne responsable le fait, sans toucher au reste. Côté technique, une seule base de code à faire évoluer. Une correction profite aux trois univers, et la maintenance ne se multiplie pas par trois.
Ce que ce projet démontre : un groupe peut avoir plusieurs visages sans multiplier les systèmes, à condition que l'architecture soit pensée pour ça dès le départ.
Si vous gérez un lieu qui contient plusieurs offres, ce projet vous parle directement. Un hôtel avec un restaurant et des salles de séminaires, un groupe de brasseries, un club adossé à une offre de restauration, un domaine avec plusieurs espaces de réception : les identités diffèrent, la mécanique est la même.
C'est utile aussi aux réseaux et aux franchises, où chaque point de vente a besoin de sa page et de son interlocuteur sans que le siège perde la main sur le socle commun. Et aux équipes marketing qui maintiennent trois outils pour trois marques, avec trois fois les mêmes problèmes.
Si vous avez plusieurs adresses et que vous voulez être trouvé sur chacune, regardez l'offre SEO : la visibilité locale d'un groupe se construit adresse par adresse. Le détail de l'approche côté plateforme est sur la page sites et plateformes, et la note WordPress ou Laravel aide à trancher quand le métier déborde du gabarit.
Le point de départ reste simple. Décrivez-moi vos univers, je vous dis ce qui doit être mutualisé et ce qui doit rester séparé. Le diagnostic prend quelques minutes, et vous repartez avec une réponse claire sous 24 h.
Tout dépend de la manière dont vos clients décident. Si un client qui cherche une salle de réception et un client qui cherche une soirée ne se posent pas les mêmes questions, un espace dédié à chacun convertit mieux qu'une page qui résume. Le second point est opérationnel : avec un back-office par univers, la personne responsable publie et répond sans attendre la direction, et sans accéder au périmètre des autres. Si vos offres sont proches et vos équipes partagées, un site unique bien structuré reste le bon choix, je vous le dirai au diagnostic.
Avec les mêmes outils que vous : visioconférence, e-mail et documents partagés, dans un canal unique où tout reste écrit. Cotonou reste à UTC+1 toute l'année, ce qui facilite les échanges avec Paris, Bruxelles et Genève ; avec Montréal, je cale les rendez-vous sur votre matinée. Vous avez un interlocuteur unique du brief à la mise en ligne, une réponse sous 24 h, et des points d'étape réguliers plutôt qu'un silence de plusieurs semaines.
Les back-offices sont conçus pour des non-techniciens : publier une carte, changer un horaire ou retirer une photo ne demande aucune compétence particulière. Je forme les équipes et je laisse une documentation écrite. Les comptes sont nominatifs avec des rôles, donc le départ d'une personne se règle en désactivant son accès, sans casser le site ni repartir de zéro. Le code, l'hébergement et les accès restent à votre nom, vous n'êtes jamais enfermé chez moi.
Tikehub est une plateforme de billetterie, de concours à votes payants et de collecte de fonds. Je l’ai conçue pour qu’un organisateur vende, encaisse et suive sans assembler cinq outils.
Catalogue de véhicules neufs et d'occasion pour un distributeur basé à Cotonou : 41 modèles, 28 marques, prix affichés et parcours de contact unifié. Ce que cette réalisation prouve pour un concessionnaire, un importateur ou un e-commerçant en France, en
Une boutique WooCommerce pour un distributeur d'accessoires auto, où chaque fiche produit a été conçue comme une landing page autonome. Ce que cette réalisation prouve pour un e-commerçant ou un importateur en Europe et au Canada.