Rechercher dans 50 000 e-mails en quelques millisecondes : comment fonctionne l’index local de MailVault

Saisissez un mot dans MailVault et les résultats les plus récents sont à l’écran avant même que vous ayez fini d’appuyer sur la touche. Pour vérifier que cela tient quand une boîte aux lettres est vraiment volumineuse, nous avons construit un coffre de 50 000 messages et chronométré la recherche. La requête la plus lente que nous ayons lancée a pris 14 millisecondes.

Cet article donne les chiffres réels, ce qui a été mesuré et ce qui ne l’a pas été, ainsi que la technologie qui les sous-tend : une petite base de données SQL simple qui vit à l’intérieur de votre coffre.

Le test

Nous avons généré 50 000 messages d’environ 3.3 KB chacun, dans la forme multipart HTML plus texte brut que prend le vrai courrier. Ils étaient répartis sur trois dossiers (Boîte de réception, Archives et Envoyés, environ un tiers chacun), avec des mots connus placés à des fréquences connues : « invoice » dans 5 % des messages, « budget » dans 8 %, « meeting » dans 6 %, plus des mots japonais et accentués pour éprouver la recherche non anglophone. Chaque message est passé par le véritable analyseur MIME et le véritable code d’indexation de MailVault, dans une version release.

La machine était un Mac mini Apple M4 avec 16 GB de mémoire. Elle n’était pas au repos : d’autres compilations tournaient dessus pendant les tests, il faut donc lire les temps comme ce que vous obtenez sur un ordinateur occupé. Chaque requête a été exécutée six fois, trois sur une version d’essai du correctif et trois sur le code fusionné. Les chiffres ci-dessous correspondent à la plage observée sur ces exécutions, et chaque temps couvre la recherche plus la construction des lignes de résultat que vous voyez dans la liste.

Les résultats

50,000 messages · Apple M4 · warm cache · 6 runs each

query                    matches   rows shown   time
invoice                  ~2,500    500          7.1 – 7.5 ms
budget meeting           246       246          13.4 – 14.1 ms
update 4999              15        15           13.5 – 14.0 ms
会議 (Japanese)         1,529     500          4.3 – 4.6 ms
last 7 days, no words    1,008     500          1.0 ms

first index build        11 s      (10.9 – 11.9 s)
index size on disk       225 MB
status check             5 ms

Deux choses se lisent dans ce tableau. D’abord, le temps n’est pas lié au nombre de résultats : 15 correspondances ont pris plus de temps que 2 500, car ce qui coûte du temps, c’est la forme de la requête (une expression de deux mots demande plus de travail qu’un seul mot), et non la quantité de courrier renvoyée. Ensuite, la liste affiche au plus les 500 correspondances les plus récentes et l’indique lorsqu’il y en a davantage, de sorte que l’affichage des résultats représente un travail borné, quel que soit le nombre de messages correspondants.

Le coût ponctuel est la construction de l’index : environ onze secondes pour 50 000 messages, soit environ 4 000 messages par seconde, et 225 MB d’espace disque. Elle se fait en arrière-plan, vous pouvez continuer à utiliser MailVault pendant ce temps, et ensuite seuls les messages nouveaux et modifiés sont indexés.

À quoi ressemblent 1 ms et 7 ms

Les millisecondes sont difficiles à se représenter, voici donc une règle graduée. Un écran à 60 Hz se redessine toutes les 16.7 ms, et même la recherche la plus lente ici s’est terminée à l’intérieur d’un seul rafraîchissement. La recherche en ergonomie utilise les mêmes trois seuils depuis 1993 : sous 0.1 seconde, la réponse paraît instantanée ; jusqu’à 1 seconde, le fil de votre pensée reste intact ; à 10 secondes, votre attention est partie. Quatorze millisecondes, c’est environ un septième du seuil « instantané ». Le filtre par date, à 1 ms, est cent fois en dessous.

Courrier serveur, archive et sauvegarde : une seule recherche

MailVault garde côte à côte trois sortes de courrier : les messages synchronisés depuis votre serveur, les messages que vous avez archivés et les messages restaurés depuis une sauvegarde. Ils finissent tous sous forme de fichiers dans le même coffre, donc ils vont tous dans le même index. Dans le test, le courrier se trouvait dans un dossier Boîte de réception, un dossier Archives et un dossier Envoyés, et une seule requête couvrait le tout. L’origine d’un message ne change rien à la vitesse à laquelle il est retrouvé.

Le courrier qui n’est que sur le serveur et n’a jamais été téléchargé ne se trouve pas dans le coffre, donc l’index local ne peut pas le connaître. Pour ce cas, MailVault interroge aussi le serveur, et les résultats locaux indexés apparaissent en premier pendant que le serveur répond. Cette partie dépend de votre fournisseur, nous ne publions donc aucun chiffre pour elle. Premium peut rechercher jusqu’à cinq boîtes serveur à la fois au lieu d’une.

Le disque de sauvegarde externe est une seconde copie froide. La recherche s’exécute sur votre coffre de travail, et les résultats sont marqués lorsqu’une copie existe aussi sur le disque de sauvegarde.

La technologie : une base de données SQL très rapide et très simple

Il n’y a ni serveur de recherche ni service cloud. L’index est un unique fichier SQLite à l’intérieur de votre coffre, et SQLite est probablement la base de données la plus largement déployée au monde. MailVault utilise son moteur de recherche plein texte, FTS5, avec un tokenizer trigram : chaque mot est stocké sous forme de fragments de trois lettres qui se chevauchent. C’est pourquoi vous pouvez saisir « voic » et trouver « invoice », sans caractères génériques ni règle de mot exact. Les accents sont ignorés, de sorte que « reunion » trouve « Réunion ». Le japonais et le chinois, qui n’utilisent pas d’espaces entre les mots, passent par une seconde table conçue pour eux.

La vitesse vient de trois décisions simples :

• La recherche n’ouvre jamais un fichier de message. Tout ce dont la liste a besoin (expéditeur, objet, date, dossier, indicateurs) est stocké dans la ligne de l’index. Pendant le test à 50 000 messages, l’analyseur de courrier n’a pas été appelé une seule fois pendant la construction des résultats.
• Un fichier, un processus. L’index appartient à l’assistant en arrière-plan de MailVault, ouvert une seule fois et gardé prêt. Il n’y a rien à démarrer et rien à envoyer sur un réseau.
• Votre disque reste la source de vérité. L’index est une donnée dérivée. S’il est un jour endommagé, MailVault le reconstruit à partir de vos messages enregistrés et ne touche jamais aux messages eux-mêmes.

Elle fonctionne hors ligne, et rien ne quitte votre ordinateur.

Pièces jointes et images (Premium)

La recherche gratuite couvre les expéditeurs, les objets et le corps des messages. Premium ajoute le texte à l’intérieur des pièces jointes, dans le même index et le même champ de recherche :

• Texte des pièces jointes. Les fichiers PDF, Word, Excel et PowerPoint sont lus et leur texte est indexé, de sorte qu’une recherche sur un numéro de contrat trouve le message dont le PDF le contient.
• Texte des images et des scans sur macOS. MailVault utilise le framework Vision d’Apple sur votre Mac pour reconnaître le texte des photos, des captures d’écran et des pages numérisées, puis l’indexe. La reconnaissance s’exécute sur l’appareil. Windows et Linux n’ont pas cette étape.

Un résultat qui n’existe qu’à l’intérieur d’une pièce jointe est marqué d’un trombone, pour que vous sachiez pourquoi un e-mail au contenu anodin est apparu. Nous n’avons pas chronométré l’extraction du texte des pièces jointes dans ce test : elle dépend de vos fichiers, et elle s’exécute une fois par pièce jointe en arrière-plan plutôt qu’au moment de la recherche.

Comment les autres clients décrivent leur recherche

Nous n’avons pas testé les autres applications de messagerie, et aucune de celles ci-dessous ne publie de temps de recherche à 50 000 messages ; il s’agit donc d’une comparaison de conceptions, pas de chronomètres :

• Apple Mail : Apple indique que la première indexation de Spotlight peut prendre des heures, voire des jours selon la quantité de données, et que Mail peut afficher un avis signalant que l’indexation n’est pas terminée.
• Outlook pour Windows utilise l’index de Windows Search, et Microsoft précise que les résultats peuvent être incomplets tant que l’indexation n’est pas terminée, que seul le courrier mis en cache localement est indexé, et que les éléments plus anciens peuvent être masqués lorsqu’une recherche renvoie trop de résultats.
• Thunderbird conserve un index global dans sa propre base de données. Son gestionnaire de bogues contient de longs signalements d’indexation qui ralentit sur les grandes boîtes aux lettres, dont celui d’un utilisateur faisant état de plusieurs jours pour 36 000 messages. Ce sont des témoignages d’utilisateurs sur du matériel plus ancien, qui ne sont pas directement comparables à notre test.

Notre choix de conception est l’inverse du choix habituel : nous indexons votre propre copie enregistrée, la conservons dans un petit fichier unique, et gardons le chemin de la requête assez court pour que la réponse se mesure en millisecondes.

Ce que ce test ne montre pas

La boîte aux lettres est synthétique. Le vrai courrier comporte des messages plus gros et plus désordonnés, l’index sera donc plus volumineux chez vous si vos messages sont longs, même si une requête parcourt toujours l’index et non vos fichiers. Les temps sont mesurés à cache chaud : la première recherche après un redémarrage lit davantage sur le disque. Le test couvre les objets, les expéditeurs et les corps de messages, pas le texte des pièces jointes, et il a été réalisé sur une seule machine.

Vous pouvez refaire la mesure vous-même : le benchmark est le test Rust ignoré search_index_bench_50k_real_parser dans l’arborescence des sources de MailVault, et il affiche tous les chiffres ci-dessus.

Sources : Apple Support, Spotlight indexing ; Microsoft Support, Outlook search issues ; Mozilla Bugzilla 585429. Benchmark mesuré le 21 septembre 2026.