SGH Conseil

Le contexte

Sébastien a dix ans de cabinet CGPI derrière lui. Il passe de l’autre côté du métier et lance SGH Conseil, commercialisateur indépendant de programmes immobiliers à fiscalité avantageuse (Monument Historique, Malraux, Déficit Foncier, Denormandie). Sa promesse tient en une phrase : une relation d’égal à égal avec ses partenaires CGPI, pas un guichet générique de plus.

Le site qu’il avait sur Wix depuis plusieurs années ne portait plus rien de cette promesse. Pas d’espace partenaire, pas de fiches programmes détaillées, pas d’administration. Il voulait un outil à la hauteur de son positionnement premium, et surtout autonome : qu’il puisse gérer lui-même ses programmes, ses lots, ses dossiers et son blog, sans avoir à redépendre d’une agence pour chaque mise à jour.

Le défi

Tenir plusieurs objectifs à la fois, sur 11 jours de développement :

• Trois sites dans un seul projet : une vitrine taillée pour le référencement et la conversion, un espace partenaire connecté avec ses propres règles métier, et une administration complète pour Sébastien.
• Un parcours d’options critique pour l’activité : un partenaire pose une option sur un lot, cela ouvre un dossier en attente côté administration, Sébastien valide ou refuse, et le dossier progresse dans les étapes suivantes (constitution, signature, vente finalisée). Aucune marge d’erreur possible, c’est ce qui structure le chiffre d’affaires.
• Un design à l’ambiance patrimoniale, pas immobilier neuf. Vert profond, accent or, typographies Playfair Display et Cormorant Garamond. Chaque page doit évoquer la rénovation d’un bâtiment ancien, pas un programme Pinel.
• Une grille de lots lisible : numéro, type, étage, surface, prix, part travaux, foncier, loyer, statut, action. Dix colonnes qui doivent rester digestes, y compris sur un écran 13 pouces en clientèle.
• Préserver le capital SEO accumulé sur le domaine Wix, via des redirections permanentes, et garder une vitrine servie directement par le serveur (le référencement prime sur le confort d’une application côté client).
• Pas de technologie exotique, pas de service managé superflu. Le site doit pouvoir vivre plusieurs années sans maintenance lourde.

Ce que j’ai fait

Produit

• Trois profils utilisateurs clairement séparés : visiteur public, partenaire validé, administrateur (Sébastien). Trois expériences distinctes sur une même base de contenu.
• Double vue de la fiche programme : le public voit la description éditoriale et les points clés, sans prix ni lots ni documents. Le partenaire connecté voit en plus la grille de lots, les documents téléchargeables et le bouton “Poser option” sur chaque ligne disponible.
• Inscription partenaire en sas : formulaire public, compte créé “En attente”, notification à l’administrateur, validation manuelle puis email de confirmation. Personne n’entre dans l’espace partenaire sans accord explicite de Sébastien.
• Tableau de bord partenaire avec compteurs dossiers, ventes, options et programmes actifs, derniers dossiers ouverts, derniers programmes ajoutés et contact direct du fondateur.
• Mode “voir comme un partenaire” depuis l’administration : en un clic, Sébastien se met à la place d’un partenaire pour voir exactement ce qu’il voit à l’écran, utile avant un appel ou une démo.
• Administration complète sur programmes, lots, documents, dispositifs, articles, catégories de blog, utilisateurs, dossiers et options, avec un éditeur riche pour les contenus longs des fiches programmes et des articles.

Tech

• Laravel 13 avec Blade rendu côté serveur, sans Inertia ni application côté client. La justification détaillée est plus bas, dans “Stack et choix techniques”.
• PostgreSQL 16 pour la solidité des contraintes d’intégrité sur le parcours options et dossiers (transitions d’états, unicité d’une option active par lot).
• Base de données comme support pour le cache, les sessions et les files d’attente. Redis ajouterait une dépendance supplémentaire à opérer, pour un gain non mesurable à cette échelle.
• Docker en production : PHP-FPM en image légère, Nginx en reverse proxy, PostgreSQL, Mailpit en développement et Vite pour les assets. Une seule commande pour déployer : récupération du code, construction et vérification de santé.
• Sentry côté serveur et côté navigateur pour détecter les régressions sur le parcours options avant qu’elles ne remontent par les métriques commerciales.

Growth et SEO

• Sitemap dynamique, balises meta et Open Graph par page, balisage structuré sur les fiches programmes pour un affichage propre dans les résultats de recherche.
• Redirections permanentes depuis les anciennes adresses Wix pour préserver le référencement acquis.
• Maillage interne dispositif vers programmes vers articles, pensé par intention de recherche (un CGPI qui cherche un Monument Historique sur une ville précise) et non par catégorie interne.
• Socle blog prêt à accueillir le calendrier éditorial de 66 articles sur 12 mois, organisé en cinq piliers (pédagogie fiscale, actualités du marché, zooms programmes, guide partenariat, vrai ou faux). Rédaction assurée par le client.

Stack et choix techniques

J’ai volontairement choisi Blade plutôt qu’Inertia et React, à contre-courant d’un autre de mes projets (Profilia tourne en Inertia). Trois raisons assumées :

1. Blade est plus adapté que React à ce besoin précis. Le site n’a pas de forte dynamique côté client (pas de tableau de bord temps réel, pas d’interactions complexes), il repose sur des formulaires, de la navigation et une grille de lots. Introduire une application côté client ici serait disproportionné : un rendu côté serveur classique fait exactement le travail attendu, sans complexité ajoutée.
2. Le référencement prime sur le confort d’une application côté client. La vitrine est la première porte d’entrée commerciale du site, elle doit être indexable immédiatement par les moteurs de recherche, sans dépendre d’un service de rendu séparé.
3. Un code facile à faire évoluer. Plus moderne et plus souple qu’un Wordpress, assez lisible pour qu’une assistance par IA soit efficace le jour où Sébastien voudra modifier une page lui-même.

Le reste des choix suit la même logique : la base de données comme support de cache et de files d’attente (sans Redis), Docker et Nginx classiques plutôt que des outils prêts à l’emploi, pas d’ORM non standard, pas de service managé supplémentaire. Chaque dépendance en moins est un risque de panne en moins et une facture en moins à surveiller.

Résultats

Site en production. Périmètre livré : quatre dispositifs fiscaux, catalogue public et vue partenaire complète, grille de lots avec parcours options de bout en bout, tableau de bord partenaire, administration autonome sur l’ensemble du contenu (programmes, lots, documents, dossiers, articles, utilisateurs), et un socle blog prêt à accueillir un calendrier éditorial de 66 articles par an.

Si vous préparez une refonte qui doit réunir une vitrine orientée référencement, un espace client métier et une administration autonome dans un seul projet, écrivez-moi.