La vocation du produit
Aidez les acheteurs potentiels à comprendre un portefeuille immobilier, à explorer des développements individuels et à faire une demande avec un contexte utile.
À qui il s’adresse
Les personnes explorant les résidences et les propriétés commerciales à Tétouan et Cabo Negro, ainsi que l'équipe qui reçoit leurs demandes.
L’expérience produit
Le portefeuille mène à des expériences de développement distinctes. Les visiteurs peuvent inspecter des galeries et un plan directeur basé sur des points de repère, sélectionner leurs préférences de résidence et mettre ce contexte en contact. Les itinéraires français et anglais servent le même portefeuille sous-jacent.
La technologie au service de l’expérience
Le contenu partagé et le routage soutiennent la base du site, tandis que des composants de campagne distincts donnent à chaque développement principal sa propre composition. Les médias réactifs et les films à la demande gèrent le poids visuel. La validation, les enregistrements d'enquêtes privées et les reçus soutiennent le flux de contacts ; les redirections et les métadonnées connectent la reconstruction aux URL héritées connues.
Un portefeuille immobilier repensé comme une expérience digitale cohérente.
Au-delà d’une refonte visuelle
La mission Moussa Real Estate portait sur une refonte complète, guidée par six mois de préparation. Le nouveau site doit présenter l’entreprise, différencier ses programmes et accompagner l’acheteur de l’intérêt à une demande pertinente. Une nouvelle page d’accueil ne suffit pas : contenus, navigation, présentation immobilière, médias et traitement des demandes doivent fonctionner ensemble.
La refonte locale comprend 16 pages en français et en anglais, soit 32 combinaisons de page et de langue : accueil, portefeuille, sept programmes, entreprise, contact, locaux commerciaux, visites virtuelles et pages réglementaires. Cette ampleur exige de la cohérence, tout en laissant aux programmes principaux la liberté d’exprimer leur caractère.
Une base commune, des expériences immobilières distinctes
L'architecture utilise Next.js, React et TypeScript, avec un contenu de site partagé et des compositions de campagnes distinctes. Metropolis, River Residences et L’Olivier ont des traitements de couleurs, de hiérarchie, de disposition et de mouvement distincts. Les développements Amina restent accessibles via le portefeuille partagé plutôt que de se perdre derrière les campagnes phares.
Séparer le contenu partagé de la présentation de la campagne permet au site de conserver une navigation et une structure linguistique cohérentes tout en donnant à chaque développement une histoire visuelle plus spécifique. Le modèle de contenu contient des faits sur le projet, des textes bilingues et des coordonnées ; les modules de campagne contrôlent les chapitres et les interactions qui rendent chaque page différente.
La gestion des langues fait partie de cette base. Les URL racines restent en français et l’anglais utilise le préfixe /en. L’arabe attend des contenus relus et validés. Le site propose ainsi les langues documentées dans le développement, sans présenter une traduction non vérifiée comme une expérience client finalisée.
Explorer de manière interactive
Metropolis comprend un plan directeur illustré avec des points de repère sélectionnables et une visionneuse étendue. Les visiteurs peuvent inspecter l'image grâce aux commandes de zoom, de panoramique et de réinitialisation, tandis que les utilisateurs mobiles disposent de gros boutons de repère en dessous. Le plan directeur est une illustration architecturale raster avec navigation interactive, et non un modèle 3D orbitable ou une enquête certifiée.
La galerie de River traite la navigation comme faisant partie de l'expérience du navigateur. La sélection d'une image met à jour l'état de l'URL numérotée, l'action Retour restaure l'image précédente et Échap ferme la boîte de dialogue. Cela transforme une galerie d’une superposition isolée en un voyage qui peut être revisité et parcouru de manière prévisible.
Ces interactions doivent aussi rester accessibles. Les vérifications documentées portent sur la fermeture des galeries au clavier, le retour du focus et la sélection des repères sur mobile. Ces détails permettent d’utiliser l’expérience avec différentes méthodes de saisie et tailles d’écran.
Transformer l’intérêt en une demande pertinente
Le parcours de contact fait avancer le contexte. Un contrôle des préférences de résidence peut envoyer le développement sélectionné et la préférence de chambre dans le formulaire de demande, réduisant ainsi le montant qu'un visiteur doit expliquer à nouveau. Des alternatives directes par téléphone, e-mail et WhatsApp restent disponibles à côté du formulaire.
Le formulaire valide les données côté navigateur et côté serveur, enregistre une demande privée et renvoie un accusé de réception. La version locale comprend une boîte de demandes en lecture seule, stockée hors des ressources publiques. Une demande de test identifiée a été envoyée et vérifiée dans cette boîte pendant la QA documentée.
Ce mécanisme de réception fonctionne localement. L’e-mail automatique et une connexion CRM réelle ne sont pas présentés comme intégrés. La mise en production doit prévoir un stockage privé persistant et la configuration adaptée. L’étude distingue donc le traitement des demandes déjà réalisé des services encore à connecter.
Médias, vitesse et animation
La narration immobilière repose sur des images et des films de grande taille, la livraison des actifs est donc une préoccupation technique dès le départ. La reconstruction utilise des dérivés d'image réactifs, des dimensions d'image explicites, un chargement prioritaire pour les images de héros et un chargement paresseux pour les médias secondaires. Les films se chargent à la demande et la page d'accueil du mobile commence par un portrait plutôt que par le chargement automatique d'un film d'arrière-plan.
L'implémentation utilise également une typographie auto-hébergée, des replis à mouvement réduit et une boucle d'animation contrôlée par la visibilité. L'intention est de préserver l'atmosphère du développement sans que chaque appareil télécharge et anime tous les visuels en même temps.
Le rapport Lighthouse local conservé du 17 septembre indique des scores de performance mobile de 88 à 93 sur quatre pages représentatives, sans décalage de mise en page mesuré. Ce sont des mesures de laboratoire historiques, pas des données réelles actuelles ni une garantie de vitesse en production. Le rapport signale aussi des pistes d’amélioration du chargement mobile et de la compression des images.
Refondre le site en préservant ses URL
Le travail de migration mappe les chemins hérités connus et les identifiants de page WordPress vers des destinations de remplacement. Les pages françaises et anglaises ont des URL canoniques et des langues alternatives, ainsi que des métadonnées, des cartes sociales, des données structurées, un plan du site et une gestion des robots. Les routes inconnues renvoient une réponse 404 appropriée.
Les vérifications de redirection enregistrées couvrent six chemins hérités et un identifiant WordPress représentatif. Il s'agit d'une surface de migration définie et non d'une affirmation selon laquelle chaque URL entrante historique a été découverte. Une migration de production nécessite toujours du trafic réel ou des exportations de la Search Console pour identifier des alias supplémentaires et une vérification post-déploiement de l'hôte canonique et des redirections.
Processus de développement et étapes de vérification
Six mois de préparation ont défini la direction du site. La mise en œuvre la traduit en organisation des contenus, routage commun, pages propres à chaque programme, exploration interactive, demandes et migration. L’affinage visuel et les vérifications techniques se rejoignent dans le navigateur : chaque page doit rester claire, traduite, adaptée au mobile et utilisable au clavier. Les six mois désignent la préparation, pas une durée de programmation mesurée.
L'enregistrement d'assurance qualité du 17 septembre rapporte avoir réussi les contrôles de production et TypeScript, deux tests d'enquête et un balayage HTTP couvrant 32 pages, 68 actifs et sept redirections représentatives. Les principales pages du projet ont été examinées sur neuf largeurs de fenêtre allant de 320 à 1 920 pixels. Une entrée du 18 septembre documente une validation supplémentaire de la refonte de la campagne. Il s’agit de points de contrôle de vérification datés, et non d’une date de début reconstruite ou de la durée totale de construction.
La portée livrée décrite ici est la reconstruction locale. Le déploiement public, l'intégration réelle du CRM, les tests des appareils physiques et les Core Web Vitals sur le terrain ne faisaient pas partie des contrôles effectués documentés dans ces rapports. Garder ces limites claires rend l'histoire de développement plus utile : elle montre ce qui a été construit, ce qui a été testé et ce qui appartient à la prochaine étape de publication.
