Une base de données qui ralentit arrive toujours au pire moment : le produit grandit, les utilisateurs sont là, et soudain les requêtes qui prenaient 20 millisecondes en prennent 800. La tentation immédiate est de conclure que la base est « trop petite » et de prévoir une plus grosse machine, ou de réécrire le schéma. C’est presque toujours une erreur de diagnostic : on traite le symptôme avant d’avoir trouvé la cause.
Dans la plupart des cas observés sur des applications de PME, le problème n’est pas la capacité de la machine mais la façon dont la base est utilisée : requêtes sans index, chargement de trop de lignes, accès répétés au même disque, verrous qui s’accumulent. Avant de dépenser dans du matériel, il existe une séquence de vérifications qui règle une grande partie des cas, et c’est elle qu’on détaille ici.
Cet article donne un plan d’action ordonné pour scaler une base de données relationnelle classique (PostgreSQL, MySQL, MariaDB), avec les signaux qui indiquent quand passer à l’étape suivante. Il s’agit de réutiliser directement ce plan sur votre propre base, sans matériel neuf ni réécriture.
Mesurer avant de toucher
Aucune décision ne se prend sans chiffres. Sur une base qui ralentit, la première action est de regarder les requêtes lentes : PostgreSQL expose pg_stat_statements, MySQL son slow query log. Ces deux outils donnent la liste des requêtes qui consomment du temps, triées par durée cumulée. C’est la seule façon de savoir si le problème vient d’une requête précise ou d’une dégradation générale.
En parallèle, mesurez le taux de cache : si cache hit ratio tombe sous 95 %, c’est que les données chaudes ne tiennent pas en mémoire. Et surveillez les connexions actives : une base saturée montre souvent des centaines de connexions en attente d’un verrou. Ces trois mesures, requêtes lentes, cache et verrous, suffisent à classer le problème dans la bonne catégorie.
Ne commencez aucune optimisation avant d’avoir ces chiffres. Une optimisation sans mesure est une modification de la base sans savoir si elle servira, et elle peut dégrader le comportement des autres requêtes.
Les index : le premier levier, presque toujours sous-utilisé
La cause la plus fréquente d’une base lente est un scan complet de table sur des données volumineuses. La requête est correcte, les données sont là, mais le moteur lit chaque ligne pour en garder quelques-unes. Un index adapté transforme cette lecture de millions de lignes en une recherche de quelques dizaines.
Le réflexe utile est de prendre chaque requête lente et de regarder le plan d’exécution : l’outil EXPLAIN montre si la ligne comporte un Seq Scan et quels filtres sont appliqués. L’index se construit sur les colonnes utilisées dans le WHERE, puis dans le JOIN, puis dans le ORDER BY, dans cet ordre. Pour un filtre qui combine plusieurs colonnes, un index composite est souvent plus efficace que plusieurs index séparés.
Un piège fréquent : les index appliqués sur des colonnes transformées par une fonction. WHERE date_creation > ... utilise un index, WHERE EXTRACT(YEAR FROM date_creation) = 2026 ne l’utilise pas, car la colonne est modifiée avant la comparaison. La correction est de réécrire la condition pour qu’elle porte sur la colonne brute, sans fonction.
Réduire ce que chaque requête transporte
Une fois les index en place, le deuxième goulot est la quantité de données transportées. Une application qui charge 500 colonnes pour en afficher 5, ou qui récupère 10 000 lignes pour en montrer 50, fait travailler la base pour rien. Les opérateurs LIMIT avec pagination et la sélection explicite des colonnes réduisent cette charge sans toucher au schéma.
Le même raisonnement s’applique aux jointures : charger les lignes d’une table associée en bloc avec une ou deux requêtes préparées est souvent plus rapide que de laisser l’application déclencher une requête par ligne. Le fameux problème des N+1 requêtes, où chaque élément d’une liste déclenche sa propre interrogation, est une cause classique de ralentissement qui n’a rien à voir avec la taille de la base.
Sur les gros volumes, vérifiez aussi ce que le réseau transporte. Une application qui appelle la base depuis un autre serveur peut être limitée par la latence du lien plus que par la base elle-même. Regrouper les accès et réduire le volume renvoyé fait souvent baisser les temps de réponse plus vite qu’une optimisation du moteur.
Quand la mémoire et le disque deviennent le facteur
Si les requêtes sont indexées et légères mais que le cache reste sous les 95 %, le problème devient matériel. Les données fréquemment accédées doivent tenir en mémoire : sur un serveur dédié, attribuer 50 à 70 % de la RAM à shared_buffers (PostgreSQL) ou innodb_buffer_pool_size (MySQL) est le réglage de base. Beaucoup d’installations par défaut sont volontairement prudentes et laissent la mémoire inutilisée.
Vérifiez ensuite le type de stockage. Un disque dur mécanique qui sert de base à une application avec de l’écriture régulière est un goulot permanent : les écritures aléatoires sont lentes, et les temps de réponse sont instables. Passer sur un SSD règle ce problème sans changer une ligne de code, et c’est souvent l’achat le plus rentable. La latence d’écriture, pas la taille, est le facteur qui plombe les temps de réponse en production.
Un signal fiable pour décider : si la charge CPU de la base reste faible alors que les requêtes sont lentes, le problème est très probablement l’entrée-sortie. À l’inverse, une CPU saturée avec des requêtes pourtant indexées indique un volume de travail réel qui ne se règle pas par la configuration.
Lire les réplicas et le partitionnement
Quand la base principale est correctement configurée mais que la charge reste trop élevée, les deux leviers suivants sont structurels. Un réplica en lecture, un serveur qui reçoit une copie des données et ne sert que les requêtes en lecture, décharge la base principale de la majorité du trafic d’une application classique. La mise en place demande de rediriger les requêtes de lecture vers le réplica, et l’écart de quelques secondes entre les deux copies doit être accepté par les fonctionnalités concernées.
Le partitionnement, lui, découpe une table volumineuse en plusieurs segments selon une clé, par exemple la date : chaque segment reste de taille raisonnable, les index restent efficaces et les purges deviennent triviales, car supprimer un segment ancien est immédiat au lieu de supprimer ligne par ligne. Il s’agit d’une évolution de schéma, mais sans réécriture applicative, le moteur masque la découpe.
Ces deux solutions s’appliquent quand la base est saine mais que le volume croît : c’est le bon moment, avant que le matériel ne dicte la décision. Commencer par les index et la configuration retarde toujours ce besoin, et le rend plus simple quand il arrive.
L’accompagnement Agenticiel pour scaler vos données
Scaler une base de données demande de la méthode : mesurer, indexer, alléger, puis ajuster le matériel, dans cet ordre. Agenticiel applique cette séquence sur les applications existantes des PME, souvent sans réécriture, avec des résultats vérifiés par les mesures avant et après.
Nos équipes interviennent sur le diagnostic des requêtes lentes, la mise en place des index et des réplicas, et la reprise des bases existantes pour les préparer à la croissance. Le travail est mené par des développeurs offshore francophones, basés à Madagascar, qui pratiquent ces techniques sur des bases en production. La sous-traitance de développement vous donne accès à cette expertise sans mobiliser votre équipe interne sur un chantier long.
Notre approche consiste à traiter chaque ralentissement comme un problème mesurable plutôt que comme un prétexte à réécrire : vous gardez votre application et votre schéma, et la base gagne en capacité sans risquer le projet.