Elasticsearch et Lucene pour un catalogue technique : ce que vous devrez construire vous-même

Commençons par ce qui est vrai

Lucene est la bibliothèque d'indexation la plus éprouvée du secteur. Elasticsearch, qui la met en cluster, fait tourner la recherche de milliers d'entreprises. Sur beaucoup de terrains, ils n'ont pas d'équivalent.

Si votre besoin ressemble à l'un de ceux-ci, ne lisez pas le reste : analyse de journaux et observabilité, recherche vectorielle à très grande échelle, agrégations analytiques sur des centaines de millions de documents, réplication entre régions, ou une équipe qui exploite déjà un cluster pour d'autres usages. Dans ces cas, Elasticsearch est la bonne réponse et Heurix n'en est pas une.

La question de cet article est plus étroite : que se passe-t-il quand on veut chercher dans un catalogue de références techniques ?

Le problème n'est pas la puissance, c'est ce qu'il faut écrire

Prenez une vis de diamètre 8, longueur 20. Dans un vrai catalogue, avec un vrai historique d'imports, elle apparaît sous ces formes :

Pour un moteur généraliste, ce sont cinq chaînes différentes. L'analyseur standard découpe le texte selon les règles de segmentation Unicode : il ne sait pas que M8 désigne un diamètre, que 20 est une longueur, ni que le tiret et le « x » jouent le même rôle de séparateur ici.

Ce que vous devrez écrire dans Elasticsearch

C'est faisable. Voici l'inventaire honnête, dans l'ordre où vous le découvrirez :

• Un analyseur personnalisé par famille de références, avec ses filtres de caractères pour normaliser les séparateurs
• Un tokeniseur à motifs (pattern_capture) pour extraire diamètre, longueur, norme, matière — un motif par attribut, par secteur
• Un graphe de synonymes maintenu à la main, avec le piège classique des synonymes multi-mots à l'indexation
• Une fonction de score sur mesure : le score par défaut, fondé sur la fréquence des termes, favorise les libellés courts — pas les références exactes
• Des champs multiples pour chaque attribut extrait, avec le mapping correspondant
• Une réindexation complète à chaque modification de mapping ou d'analyseur, car ils ne s'appliquent qu'à l'indexation

Comptez quelques semaines pour un développeur qui connaît Lucene. Davantage s'il l'apprend en chemin — et c'est le cas le plus fréquent.

Puis vient l'exploitation, qui ne s'arrête jamais

Le développement est un coût unique. L'exploitation est permanent :

• Trois nœuds minimum pour un quorum en production. Un nœud unique n'est pas de la production, c'est une démonstration.
• Dimensionnement de la mémoire JVM, du nombre de fragments, de la taille des segments. Se tromper ne provoque pas de panne : ça ralentit, progressivement.
• Montées de version avec ruptures de compatibilité, et réindexation à la clé.
• Surveillance de la santé du cluster — c'est un système distribué, avec les modes de défaillance qui vont avec.

Et un point que beaucoup découvrent tard : la question de la licence. Depuis 2021, Elasticsearch n'est plus sous Apache 2.0. Il est aujourd'hui disponible sous trois licences au choix — AGPLv3 ajoutée en septembre 2024, SSPL, et Elastic License 2.0 — mais les distributions officielles restent sous les termes d'Elastic. C'est ce changement qui a provoqué le fork d'OpenSearch par AWS, désormais sous Apache 2.0 et gouverné par la Linux Foundation. Rien de bloquant, mais une décision à prendre en connaissance de cause si vous intégrez le moteur dans un produit que vous revendez.

L'approche de Heurix : la logique métier est déjà écrite

Heurix ne remplace pas Elasticsearch sur son terrain. Il fait une chose : il livre pré-écrit le travail d'analyse que vous auriez dû produire.

Voici la sortie réelle de son moteur sur les cinq écritures ci-dessus, avec le pack de règles « outillage » :

M8x20            → DIAM_M8, LONG_20, VIS_M8X20
M8 x 20          → DIAM_M8, LONG_20, VIS_M8X20
M8X20            → DIAM_M8, LONG_20, VIS_M8X20
M 8 x 20         → DIAM_M8, LONG_20, VIS_M8X20
vis M8-20 inox   → DIAM_M8, DIAM_M8_INOX, FAM_VIS, MAT_INOX

Cinq écritures, les mêmes annotations. C'est ce qui permet à un client qui tape vis M8-20 inox de trouver un produit dont le libellé dit M8X20 A2.

Dix packs sectoriels couvrent l'outillage, l'électronique, l'industrie, l'automobile, l'électricité, la plomberie, la mode, les vins, les livres et la finance. Ce que le pack ne reconnaît pas, vous l'ajoutez depuis votre console — sans écrire d'expression régulière, en décrivant ce qu'il faut reconnaître.

Ce que Heurix ne fait pas

Autant le dire clairement, cela vous évitera une découverte désagréable :

• Pas d'analyse de journaux, pas d'observabilité, pas de tableaux de bord analytiques généralistes
• Pas de recherche vectorielle à grande échelle
• Pas d'auto-hébergement : c'est une API, pas un cluster que vous exploitez
• Des limites de volume par plan, là où un cluster que vous dimensionnez n'en a d'autre que votre matériel

Comment trancher

La question n'est pas « lequel est le meilleur moteur ». Elasticsearch est plus puissant, plus large, et il le restera. La question est de savoir si vous voulez construire et maintenir la logique d'analyse de vos références, ou la trouver déjà faite.

Si vous hésitez : la documentation de l'API est complète, et le tutoriel de cinq minutes vous dira en dix minutes si le moteur reconnaît vos références. C'est plus court qu'un premier analyseur Lucene.