Réindexation : les leçons de Notion pour les PME

Une étude de cas qui dépasse largement le moteur de recherche

L'article « Rebuilding Notion's lexical search reindexer », signé par Aravind Selvan, Calder Lund et Gaurang Sadekar et publié sur le blog de Notion, raconte la refonte complète du mécanisme qui reconstruit l'index de recherche de l'outil. À première vue, le sujet paraît réservé aux géants du logiciel : des milliards de blocs de contenu, des clusters de recherche, des pipelines de calcul distribué.

Pourtant, les problèmes décrits sont familiers à beaucoup d'entreprises bien plus modestes. Un traitement de données qui prend trop de temps, qui exige qu'un ingénieur le surveille en permanence, qui dépend d'un système tiers capricieux et qui se termine avec des « trous » dans les résultats : c'est exactement ce que vivent de nombreuses PME avec leurs synchronisations CRM/ERP, leurs imports de catalogues, leurs migrations de base de données ou leurs traitements nocturnes.

Chez comm.it, nous accompagnons des TPE et PME sur l'automatisation des processus métier, l'IA, le réseau et le développement de logiciels cœur de métier. Ce retour d'expérience illustre très bien la démarche que nous défendons. Plutôt que de résumer l'article, nous en tirons ici les enseignements concrets et expliquons comment ils se traduisent dans nos projets.

Le point de départ : une opération critique devenue un frein

Selon l'équipe de Notion, la réindexation hors ligne (reconstruire tout l'index à partir d'un instantané de la base de données) était nécessaire dans plusieurs situations : ajouter une nouvelle fonctionnalité de recherche, modifier la façon dont le texte est analysé (par exemple une meilleure tokenisation pour les écritures non latines), changer de version du moteur ou ouvrir une nouvelle région.

Le problème : cette opération se déroulait environ une fois par trimestre, durait plusieurs semaines, nécessitait une surveillance constante et se terminait avec des écarts notables. Le tableau final de l'article résume l'ancienne situation :

• une réindexation complète de plus de deux semaines ;
• une phase de rattrapage d'environ deux jours ;
• une cohérence des données d'environ 90 % ;
• 1 à 2 ingénieurs mobilisés pendant deux semaines ;
• 5 à 10 alertes d'astreinte par exécution ;
• deux pipelines distincts à maintenir et des dépendances externes dans le chemin critique.

Après la refonte, l'opération s'achève en moins de deux jours (l'introduction évoque même moins de 24 heures), le rattrapage prend moins d'une heure, la cohérence atteint 100 %, l'intervention humaine tombe sous les deux heures et les alertes disparaissent. Surtout, l'équipe souligne que le vrai changement est culturel : ajouter un champ cherchable n'est plus un projet d'un mois, mais quelques jours de travail.

C'est là le cœur du sujet pour une entreprise : la vitesse et la fiabilité d'un traitement technique fixent un plafond à la vitesse d'innovation. Si chaque évolution de votre CRM exige une migration risquée de trois semaines, vous ferez moins d'évolutions.

Leçon n° 1 : un traitement par lots n'a rien à faire sur une infrastructure temps réel

L'ancien système de Notion reposait sur une flotte de conteneurs exécutant le même code que l'indexation en ligne. L'avantage était séduisant : une parité parfaite entre le traitement temps réel et le traitement de masse, « gratuitement ». L'inconvénient était structurel : un runtime mono-thread qui n'exploitait qu'un cœur par processus, une mémoire dupliquée dans chaque worker, et des écritures qui passaient par la même voie que le trafic des utilisateurs, avec tous les verrous et contrôles de version associés.

La conclusion des auteurs est limpide : la réutilisation du code ne suffit pas à justifier de faire tourner une charge batch sur un environnement conçu pour des services en ligne.

Ce que cela signifie pour une PME

Nous rencontrons très souvent ce schéma. Une entreprise lance un import massif de données (historique clients, factures, fiches produits) en utilisant l'API standard de son CRM ou de son ERP, celle qui sert aussi aux utilisateurs au quotidien. Résultat : l'import est lent, il ralentit l'application pour tout le monde, et il échoue à mi-parcours sur une limite de débit.

Lorsque comm.it conçoit une automatisation ou une intégration, nous distinguons systématiquement :

• les flux temps réel (création d'un contact, mise à jour d'une commande), traités événement par événement ;
• les flux de masse (reprise d'historique, recalcul, réconciliation), traités par lots avec des outils et des chemins d'accès adaptés : imports en fichier, écriture directe en base lorsque c'est possible et sûr, fenêtres de traitement hors heures de production.

Cette séparation simple évite bien des incidents et rend chaque flux plus facile à dimensionner.

Leçon n° 2 : sortir les dépendances externes du chemin critique

Première étape de la refonte chez Notion : supprimer les requêtes en direct vers l'entrepôt de données Snowflake pendant l'indexation. Ces requêtes servaient surtout à récupérer des métadonnées absentes des fichiers d'entrée. L'équipe les a remplacées par un traitement nocturne qui précalcule ces informations dans des fichiers plats stockés sur un stockage objet.

Les bénéfices décrits sont doubles : le débit d'indexation ne dépend plus de la disponibilité de l'entrepôt, et l'équipe Recherche ne concurrence plus l'équipe Data pour les ressources de calcul. Et, point essentiel, cette étape a rendu possible la suite : sans dépendance externe vivante, le traitement pouvait être déplacé n'importe où.

Ce que cela signifie pour une PME

Dans un ERP ou un logiciel métier sur mesure, le chemin critique est souvent encombré d'appels externes : vérification d'un numéro de TVA, calcul de frais de port via un transporteur, appel à un service de géocodage, interrogation d'un outil comptable. Chacun de ces appels est un point de défaillance. Si le service tiers est lent ou indisponible, c'est toute la chaîne qui s'arrête.

Notre approche consiste à identifier ce qui peut être précalculé ou mis en cache :

• les référentiels qui changent peu (tarifs, barèmes, listes de pays, catalogues) sont synchronisés à intervalle régulier plutôt qu'interrogés à chaque opération ;
• les enrichissements non urgents sont traités de manière asynchrone, dans une file d'attente, sans bloquer l'utilisateur ;
• les appels indispensables sont encadrés par des délais d'expiration, des reprises automatiques et un mode dégradé clairement défini.

C'est souvent le levier le plus rentable d'un projet d'optimisation : on ne réécrit rien de fondamental, on retire simplement des fragilités.

Leçon n° 3 : migrer par étapes vérifiables plutôt que tout réécrire

La tentation de l'équipe était de tout jeter et de repartir de zéro. Elle y a résisté, pour deux raisons que nous trouvons exemplaires :

1. La logique qui transforme un bloc Notion en document indexable était le code le plus risqué du pipeline. Elle encodait des années de cas particuliers : résolution des permissions par document, sémantique de suppression, formatage des champs. La réécrire d'un coup risquait d'introduire des régressions silencieuses.
2. L'équipe voulait que chaque étape soit vérifiable indépendamment, avec un rayon d'impact limité. Déboguer plusieurs changements simultanés sur un système critique est extrêmement difficile.

La refonte a donc été découpée en quatre étapes, chacune déployée et validée avant la suivante. Fait remarquable : le code le plus sensible (la génération des documents) est resté inchangé pendant que l'équipe refondait la manière d'écrire les données. Il n'a été porté vers un nouveau langage et un nouvel environnement qu'une fois le reste stabilisé.

Ce que cela signifie pour une PME

C'est probablement la leçon la plus utile pour nos clients. Remplacer un vieux logiciel métier, un CRM maison ou un ensemble de macros devenues ingérables est souvent perçu comme un projet « tout ou rien ». Or les règles métier accumulées au fil des années (remises particulières, cas de facturation atypiques, droits d'accès spécifiques) sont précisément ce qui fait la valeur de l'existant… et ce qui disparaît en silence lors d'une réécriture précipitée.

Chez comm.it, nous privilégions une migration incrémentale :

• cartographier les règles métier et les flux existants avant d'écrire une ligne de code ;
• isoler la logique la plus sensible et la conserver telle quelle le plus longtemps possible ;
• remplacer couche par couche (stockage, interfaces, automatisations), chaque étape étant mise en production et validée avant la suivante ;
• garder un chemin de retour à chaque étape.

Cette méthode semble plus lente sur le papier. En pratique, elle évite les bascules ratées qui coûtent des semaines de correction et la confiance des utilisateurs.

Leçon n° 4 : prouver la parité par la validation automatique

Pour l'étape la plus risquée (le portage de la génération de documents), les analyses de Notion décrivent deux validateurs exécutés automatiquement en intégration continue à chaque modification :

• un validateur agrégé, qui compare le nombre de documents et leur répartition par type entre l'ancienne et la nouvelle implémentation ;
• un validateur champ par champ, qui échantillonne les documents de façon stratifiée par type de bloc (pour que les types rares soient toujours couverts) et compare chaque valeur.

Au moment de la bascule, la parité était quantifiée jusqu'à une poignée de différences acceptables, principalement l'ordre de certains tableaux. Même un détail comme la détection de langue a été traité avec rigueur : l'équipe a recompilé la même bibliothèque native pour obtenir un résultat identique octet pour octet.

Ce que cela signifie pour une PME

Lors d'une migration de données ou du remplacement d'un outil, la question « est-ce que tout est bien passé ? » reçoit trop souvent une réponse approximative : quelques vérifications manuelles, un utilisateur qui « n'a rien remarqué ». Les problèmes apparaissent des semaines plus tard, quand un client ne retrouve pas sa facture ou qu'un commercial découvre des contacts manquants.

Nous intégrons dans nos projets des contrôles automatisés inspirés de cette logique :

• comptages et totaux comparés entre l'ancien et le nouveau système (nombre de clients, montants facturés par période, nombre de commandes par statut) ;
• comparaisons détaillées sur des échantillons représentatifs, en veillant à couvrir les cas rares et pas seulement les plus fréquents ;
• exécution répétable de ces contrôles, pour pouvoir les relancer après chaque correction.

L'IA peut d'ailleurs aider ici : pour classer des écarts, repérer des anomalies dans des données textuelles ou rapprocher des enregistrements proches. Mais elle vient en complément d'une validation déterministe, jamais à sa place.

Leçon n° 5 : livrer des artefacts, pas des écritures

Un autre changement majeur décrit dans l'article : au lieu d'écrire les documents un par un dans le moteur de recherche (le débit plafonnait autour de 200 000 documents par seconde), l'équipe a produit directement des instantanés au format natif du moteur, restaurables en quelques heures. Pour cela, chaque tâche de calcul fait tourner un nœud embarqué configuré exactement comme la production, en reproduisant la même logique de routage et de versionnement.

La conséquence est puissante : puisque le résultat n'est qu'un ensemble de fichiers, les déploiements atomiques et le retour arrière deviennent triviaux. Si un nouvel instantané pose problème, on restaure celui de la veille.

Ce que cela signifie pour une PME

Le principe se transpose bien au-delà de la recherche. Préparer une nouvelle version d'une base, d'un catalogue ou d'une configuration à côté de la production, la valider, puis basculer d'un coup, c'est le moyen le plus sûr de faire évoluer un système. Pour nos clients, cela se traduit par :

• des environnements de préproduction fidèles à la production ;
• des sauvegardes et instantanés systématiques avant toute opération lourde, avec une procédure de restauration testée ;
• des bascules planifiées et réversibles, plutôt que des modifications progressives directement sur l'outil utilisé par les équipes.

Leçon n° 6 : l'infrastructure physique compte encore

L'article contient un passage instructif sur le matériel. L'équipe a d'abord utilisé des volumes de stockage réseau pour ses tâches de calcul. Deux murs sont apparus : la capacité (certains fragments de l'index ne tenaient pas sur le volume) et le débit d'écriture séquentielle, qui bridait le traitement. Le passage à des disques NVMe locaux a rendu possible le traitement des plus gros fragments et nettement amélioré le débit. L'équipe a aussi constaté que deux tâches partageant le même disque l'épuisaient, et a ajouté un nettoyage systématique des fichiers locaux en cas d'échec d'envoi.

Ce que cela signifie pour une PME

C'est un rappel que nous partageons souvent : un traitement « lent » ne vient pas toujours du logiciel. Il peut venir d'un NAS saturé, d'un réseau local sous-dimensionné, d'un serveur aux disques trop lents, ou d'une liaison entre sites qui devient le goulot d'étranglement lors des sauvegardes. Notre double compétence réseau et logiciel nous permet de diagnostiquer l'ensemble de la chaîne : poste, réseau, stockage, application. Et de dimensionner correctement l'infrastructure avant de chercher à optimiser le code.

Leçon n° 7 : rattraper les changements grâce au versionnement

Dernière étape de la refonte : supprimer le second pipeline chargé de rattraper les modifications effectuées pendant la construction de l'index. Plutôt que de réconcilier après coup, Notion a choisi de collecter les changements au fil de l'eau : les écritures en direct sont redirigées vers des index temporaires pendant que l'instantané se construit, puis fusionnées dans l'index restauré.

La clé de la sûreté de l'opération est le versionnement des documents : une version plus récente l'emporte toujours, et un conflit laisse intacte la donnée la plus fraîche. L'équipe le formule ainsi : la fraîcheur vient des versions, pas de l'hypothèse que les fenêtres de traitement sont parfaitement disjointes. Elle reconnaît aussi une limite et la traite explicitement : un élément passé de « actif » à « supprimé » pendant la fenêtre de rattrapage nécessite une étape dédiée de détection des doublons fantômes.

Ce que cela signifie pour une PME

Toute migration d'un outil en production pose la même question : que faire des données saisies pendant la bascule ? Les réponses improvisées (« on gèle la saisie pendant trois jours », « on ressaisira à la main ») coûtent cher. En concevant les synchronisations bidirectionnelles et les automatisations avec un horodatage ou un numéro de version fiable sur chaque enregistrement, on rend les opérations rejouables sans risque d'écraser une donnée plus récente. Et en traitant explicitement les cas limites (suppressions, fusions de fiches), on évite les incohérences qui empoisonnent un CRM pendant des mois.

Comment comm.it transforme ces principes en valeur

Le retour d'expérience de Notion montre qu'une bonne architecture n'est pas qu'une affaire de performance : c'est ce qui permet à une équipe d'évoluer vite, sans peur de casser la production. Voici comment nous appliquons ces principes avec nos clients.

Pour vos CRM et ERP

• Audit des flux existants et identification des dépendances fragiles.
• Développement sur mesure ou adaptation d'outils existants, avec une migration progressive qui préserve vos règles métier.
• Contrôles de cohérence automatisés lors des reprises de données.

Pour vos automatisations

• Séparation claire entre flux temps réel et traitements par lots.
• Orchestration des tâches planifiées avec reprises automatiques, journalisation et alertes pertinentes, pour qu'aucun traitement ne dépende d'une surveillance humaine permanente.
• Opérations idempotentes et versionnées, que l'on peut relancer sans risque.

Pour vos projets d'IA et de recherche documentaire

Rendre ses documents internes facilement retrouvables, ou alimenter un assistant IA avec la connaissance de l'entreprise, suppose exactement ce que décrit l'article : un index à jour, cohérent, qui respecte les droits d'accès de chaque utilisateur et que l'on peut reconstruire quand les besoins évoluent. Nous concevons ces chaînes d'indexation avec la même exigence de fiabilité et de contrôle des permissions.

Pour votre infrastructure

• Diagnostic du réseau, du stockage et des serveurs lorsque des traitements ralentissent.
• Dimensionnement adapté aux charges réelles, y compris les pics liés aux sauvegardes et aux traitements nocturnes.
• Mise en place de sauvegardes restaurables et testées.

En résumé

L'histoire racontée par Notion se résume en quelques idées simples, valables quelle que soit la taille de l'entreprise :

• utiliser le bon outil pour le bon type de charge ;
• retirer les dépendances externes du chemin critique ;
• migrer par étapes vérifiables, en protégeant le code métier le plus sensible ;
• prouver la parité par des contrôles automatisés ;
• préférer des bascules atomiques et réversibles ;
• ne pas négliger l'infrastructure physique ;
• s'appuyer sur le versionnement pour gérer les changements concurrents.

Appliqués avec méthode, ces principes transforment des opérations redoutées en routines, et libèrent du temps pour ce qui compte vraiment : faire évoluer vos outils au rythme de votre activité.

Source : « Rebuilding Notion's lexical search reindexer », par Aravind Selvan, Calder Lund et Gaurang Sadekar, blog de Notion.

Prêt à transformer ces enjeux en avantage concurrentiel ? Contactez comm.it pour en discuter.

Source : Rebuilding Notion’s lexical search reindexer