Un portail régional passe de 800 à 12 000 annonces en dix-huit mois. Le référencement progresse, le trafic aussi — modeste en volume global, mais chaque visiteur lance une recherche. Un filtre « trois pièces, balcon, moins de 350 000 €, rayon cinq kilomètres » déclenche une requête lourde, dix photos en chargement différé, une tuile carte, et parfois une alerte e-mail. Le mutualisé tient encore le HTML. MySQL, lui, passe de 200 ms à huit secondes sur les recherches populaires.
Un portail immobilier n'est pas un blog immobilier. La contrainte n'est pas « tenir 10 000 pages vues par jour » — c'est tenir 10 000 combinaisons de filtres sur un catalogue vivant, avec des médias lourds et un référencement qui indexe chaque fiche.
Trois piliers : indexation, médias, recherche
| Pilier | Symptôme si mal dimensionné | Levier |
|---|---|---|
| Indexation base | Recherches > 2 s, processeur MySQL à 100 % | Index composites, EXPLAIN, réplica lecture |
| Photos | Disque plein, TTFB élevé | Objet + CDN, miniatures, compression |
| Recherche | Dépassements de délai sur carte / filtres | Elasticsearch, Meilisearch, PostGIS |
Sur un portail immo, la page liste est une requête analytique déguisée en page web. Traitez-la comme telle.
Indexation : la requête qui tue avant le trafic
Les erreurs classiques reviennent sans cesse : index manquant sur (ville, type, prix, surface) alors que l'interface filtre exactement là-dessus ; ORDER BY date DESC sans index couvrant provoquant un tri sur 50 000 lignes ; jointures agence → annonce → photo sans limite sur le nombre d'images chargées.
Avant mise en production, exécutez EXPLAIN sur les dix requêtes les plus fréquentes (tableau de bord analytique ou journal des requêtes lentes). Créez un index composite aligné sur l'ordre des filtres de l'interface. Imposez une pagination (24 à 48 annonces maximum par page). Mettez en cache Redis les recherches « top » (centre-ville deux pièces, etc.) avec un TTL court.
Pour approfondir, voir Index MySQL manquant : reconnaître la requête qui fait tomber le site.
Photos : le poids invisible du catalogue
Une annonce « standard » : douze photos × 1,5 Mo = 18 Mo stockés. Multipliez par 12 000 annonces — le calcul disque explique les migrations d'urgence.
L'architecture saine passe par un téléversement vers stockage objet (Scaleway, OVH, Infomaniak Object Storage), un traitement asynchrone produisant des miniatures 800 px WebP, un CDN avec cache long sur les médias et court sur le HTML de fiche (le prix change), et une purge immédiate quand une annonce est retirée.
Ne servez jamais l'original 4000×3000 dans la liste. L'expérience de page Google et votre disque vous remercieront.
Recherche à facettes et géographique : quand MySQL seul suffit
| Volume annonces | Recherche | Recommandation |
|---|---|---|
| < 2 000 | Texte + ville | MySQL ou PostgreSQL bien indexé |
| 2 000 – 20 000 | Multi-filtres + carte | PostGIS ou Meilisearch |
| > 20 000 | Facettes + agrégations | Elasticsearch ou OpenSearch dédié |
La carte interactive multiplie les requêtes : chaque zoom correspond à une nouvelle zone géographique. Cachez les tuiles et les clusters côté serveur ou précalculez par zone.
Hébergement : au-delà du « WordPress avec cache »
Le front vitrine agence peut tenir en mutualisé. Le moteur d'annonces sur mesure, Elasticsearch, 500 Go de photos et les imports CSV massifs demandent un VPS ou un cloud avec stockage objet, workers en file d'attente et réplica de lecture si la recherche domine.
Un import nocturne d'annonces depuis un CRM peut saturer les entrées-sorties pendant que les utilisateurs cherchent le matin. Isolez les imports dans une file Celery ou un serveur worker dédié.
Le sommet : le SEO amène du trafic que votre base n'a pas prévu d'accueillir
Le marketing veut « plus d'annonces indexées ». L'exploitation doit répondre « chaque modèle de recherche a un plan de performance » — sinon vous gagnez du trafic en perdant la conversion.
Décider et avancer sans angle mort
Listez d'abord les dix recherches les plus lentes via le journal des requêtes lentes. Externalisez les médias avant d'atteindre 100 Go ou 80 % du disque. Testez un import massif combiné à du trafic recherche simultané sur staging. Activez CDN et compression sur toutes les miniatures de liste. Fixez un seuil de bascule : si la latence au 95e centile des recherches dépasse 1,5 seconde, passez à un moteur dédié ou une réplica lecture.
Comparez les hébergeurs avec stockage objet via l'annuaire et le comparateur. Pour la réplication lecture, voir Réplication de base de données : disponibilité ou lecture plus rapide ?.
Questions fréquentes
Pourquoi un portail immo sature-t-il si vite en mutualisé ?
Chaque recherche multi-critères peut scanner des milliers de lignes sans index adapté ; chaque fiche charge dix à vingt photos. Processeur, mémoire et entrées-sorties disque montent ensemble — pas seulement le trafic en pages vues.
Faut-il Elasticsearch pour un portail immobilier ?
Dès quelques milliers d'annonces actives avec recherche à facettes, un moteur dédié ou PostgreSQL avec PostGIS est plus stable que des requêtes LIKE non indexées sur MySQL.
Où héberger les photos d'annonces ?
Stockage objet et CDN ; miniatures WebP ou AVIF à l'import, jamais l'original en liste.
Comment dimensionner la recherche géographique ?
Index spatial, cache des requêtes fréquentes, pagination stricte — pas de balayage complet pour une carte.
Un portail immobilier se joue dans les index SQL et les dossiers photos — pas dans le nombre de cœurs affiché sur la fiche hébergeur.