Index de base de données :l'annuaire de votre application

Les index de base de données, expliqués simplement : chacun fonctionne exactement comme un annuaire — au lieu de lire chaque page pour trouver un nom, vous allez directement dessus. Sans index, votre base de données lit chaque ligne d'une table pour répondre à une question. Avec un index, une vraie requête sur les mêmes données est passée de 2 300 millisecondes à 2,3 — mille fois plus rapide — parce qu'elle a parcouru 47 lignes correspondantes au lieu de 500 000.

Les index sont l'outil de performance au plus fort effet de levier que vous toucherez jamais, ils ne demandent aucun changement de code, et l'IA oublie régulièrement d'en ajouter. Voici ce qu'ils sont, la règle qui couvre 90 % des cas, et les vrais chiffres de production qui montrent l'enjeu.

Index de base de données : qu'est-ce qu'un index ?

Pensez à la façon dont vous trouvez « Gonçalves » dans un annuaire. Vous ne commencez pas à la page un pour lire chaque entrée — vous exploitez le fait que le livre est trié, vous sautez près des G, et vous atterrissez sur le nom en quelques secondes. Imaginez maintenant le même annuaire avec les entrées en ordre aléatoire. Trouver un nom signifie lire le livre entier, à chaque fois, pour chaque recherche.

Ce second annuaire, c'est une table de base de données sans index. Les tables stockent les lignes sans ordre utile, si bien qu'une question comme « montre-moi les tâches de ce client » force la base à examiner chaque ligne et à garder celles qui correspondent — un balayage complet. Un index est l'annuaire trié que la base maintient à côté : une copie à recherche rapide d'une colonne (ou de plusieurs) qui lui permet de sauter directement aux lignes correspondantes.

Traduit en expérience utilisateur : 2,3 secondes, c'est une page que vos clients regardent se charger. 2,3 millisecondes, c'est instantané. Même requête, mêmes données — la seule différence est un index.

La règle : indexer chaque clé étrangère

Vous n'avez pas besoin de devenir ingénieur performance. Une seule règle couvre l'écrasante majorité des cas réels :

Indexez chaque clé étrangère, et chaque colonne que vous filtrez ou triez fréquemment.

Une clé étrangère est toute colonne qui pointe vers une autre table — le client auquel appartient une tâche, le projet que facture une facture, le statut que porte un enregistrement. Dans une base bien structurée (celle que vous obtenez en normalisant correctement), ces colonnes de référence sont partout, et c'est précisément ce que la base utilise pour relier les tables quand elle répond aux questions. Chacune reçoit un index. Pas d'exception, pas d'appréciation au cas par cas.

Au-delà, indexez les colonnes que vos écrans filtrent et trient constamment : l'organisation à laquelle appartient chaque ligne (l'ossature des applications multi-tenant, filtrée dans pratiquement toutes les requêtes), les dates de création pour les listes « les plus récents d'abord », et l'horodatage de suppression logique que presque toutes les requêtes vérifient pour masquer les enregistrements supprimés. L'habitude tient en une ligne par colonne à la création de la table — CREATE INDEX idx_tasks_project_id ON tasks(project_id); — et c'est une habitude que l'IA ne maintiendra pas à votre place : les schémas générés définissent couramment les références et sautent les index, ce qui fonctionne parfaitement dans une démo de 50 lignes et s'effondre avec 500 000.

Le livreThe Solopreneur RevolutionLuis Gonçalves sur la création d'une activité de solopreneur avec l'IA, sans quitter son emploi.Obtenir le livre →

Les index composites : la deuxième astuce de l'annuaire

Un annuaire n'est pas trié selon un seul critère — il est trié par nom de famille, puis par prénom. Cela permet de trouver tous les « Martin », ou exactement « Martin, Jean ». Ce qu'il ne peut pas faire, c'est trouver tous les « Jean » quel que soit le nom de famille — pour cela, vous êtes ramené à lire tout le livre.

Un index composite est la même structure sur deux colonnes ou plus, et il obéit à la même loi de gauche à droite. Un index sur (organisation, statut) accélère « tout pour cette organisation » et « tout pour cette organisation avec ce statut » — mais ne fait rien pour « tout ce qui a ce statut, toutes organisations confondues », car le statut est le prénom, pas le nom de famille.

La conséquence pratique : l'ordre des colonnes compte. Placez en premier la colonne par laquelle vous filtrez toujours — dans un produit multi-tenant, c'est l'organisation. Et les index composites ont un pouvoir bonus : si l'ordre de l'index correspond à l'ordre de tri de votre requête, les résultats sortent déjà triés, ce qui supprime complètement l'étape de tri.

Quand NE PAS indexer

Les index ne sont pas gratuits : chacun consomme de l'espace disque et doit être mis à jour à chaque écriture, si bien que chaque index supplémentaire ralentit un peu les insertions et mises à jour. Quatre situations où il faut s'en passer :

Les colonnes à deux valeurs. Un indicateur vrai/faux coupe la table à peu près en deux — sauter à « la moitié du livre » n'économise rien. Les petites tables. Sous environ 1 000 lignes, toute la table se lit pratiquement instantanément ; la clé primaire suffit. Les colonnes que vous ne cherchez jamais. Seules les colonnes qui apparaissent dans des filtres, des tris ou des jointures méritent un index — pas les notes en texte libre. Les colonnes qui changent constamment dans des tables à forte écriture. Chaque modification doit aussi mettre à jour l'index ; sur une table surtout écrite et rarement lue, le compromis tourne mal.

La règle d'or : chaque index doit justifier son existence par une amélioration mesurable d'une requête. L'indexation « au cas où » est la façon d'obtenir des écritures lentes et du disque gaspillé.

De vrais chiffres de production

Trois vraies mesures avant/après, chacune sur un écran courant d'un produit SaaS :

Chaque ligne raconte la même histoire : la base a cessé de tout lire et a commencé à sauter. Et le processus qui les a produites est reproductible par n'importe quel fondateur : trouvez l'écran lent, demandez à la base d'expliquer comment elle a répondu à la requête (toute base de données a une fonction « explain » — et demander à l'IA d'interpréter sa sortie marche à merveille), ajoutez l'index que l'explication désigne, mesurez de nouveau. Quand le rapport dit « 500 000 lignes parcourues pour en renvoyer 20 », vous avez trouvé votre index manquant.

12 semainesVotre carrière en entreprise n'a jamais été le planPostulez au Solopreneur Accelerator.Postuler →

Questions fréquentes

Comment trouver les index qui me manquent ?

Suivez la lenteur. Quand une page traîne, prenez sa requête, lancez la fonction explain de votre base dessus, et cherchez les balayages complets de table — le rapport indique littéralement combien de lignes ont été lues par rapport à celles renvoyées. Les tableaux de bord des bases modernes font aussi remonter les requêtes les plus lentes et suggèrent souvent directement l'index manquant. Collez le tout dans l'IA pour une interprétation en langage clair.

Peut-on avoir trop d'index ?

Oui. Chaque index taxe chaque écriture et occupe du disque, si bien qu'une table avec une douzaine d'index spéculatifs paie un vrai coût pour des requêtes hypothétiques. Commencez par la règle — clés étrangères, organisation, filtres courants — puis n'en ajoutez que lorsqu'une requête lente mesurée l'exige, et supprimez les index que rien n'utilise.

Les index accélèrent-ils aussi les écritures ?

Non — plutôt l'inverse, légèrement. Un index accélère la lecture mais doit lui-même être mis à jour à chaque changement de données, de sorte que les écritures paient une petite taxe par index. Pour un produit SaaS typique, qui lit bien plus qu'il n'écrit, le compromis vaut très largement la peine ; n'indexez simplement pas les colonnes que rien ne recherche jamais.

L'IA ajoutera-t-elle les index automatiquement ?

Parfois, de façon irrégulière — et l'oubli des index de clés étrangères est l'une des lacunes les plus courantes des schémas générés par IA, car la démo fonctionne très bien sans eux. Rendez-le explicite : dites à l'IA que chaque table qu'elle crée doit indexer ses clés étrangères et ses colonnes couramment filtrées, et relisez le schéma selon cette règle comme une checklist.