Elasticsearch et OpenSearch: histoire d'une séparation, et état de l'art

En 2023, je gérais la recherche d'un grand e-commerce français, des dizaines de points de vente entre Nice et toute la Côte d'Azur. Ils avaient été parmi les premiers à faire une chose que l'on voyait alors rarement: détacher la recherche de la plateforme de vente et la traiter comme un système à part entière. Ils avaient choisi Elasticsearch, avec Kibana à côté pour lire ce que les gens cherchaient.

C'était le bon choix, et il faut dire pourquoi: à cette époque, Elasticsearch était le seul moteur de catégorie entreprise réellement mature que l'on pouvait installer sur ses propres machines. Il n'existait pas de seconde option dont discuter.

Un an plus tard, j'orientais mes clients vers Algolia. Non par déception technique, le moteur tenait ses promesses. Pour une raison plus prosaïque: maintenir Elasticsearch en état de marche n'est pas une tâche d'administration ordinaire. Cela exige des ressources dédiées et une personne dont le niveau d'expérience pèse, au bout du compte, plus lourd sur le budget annuel que n'importe quel abonnement.

Puis vint la séparation. Depuis, je n'ai plus jamais utilisé Elasticsearch pour la recherche d'un site. OpenSearch, en revanche, je l'ai repris en main à quelques reprises, mais pour un autre métier, et j'y viens à la fin.

POURQUOI ILS SONT DEUX

L'affaire mérite deux minutes, car elle explique le marché d'aujourd'hui.

Jusqu'à la version 7.10, Elasticsearch était sous licence Apache 2.0, c'est-à-dire librement utilisable par quiconque, y compris par ceux qui bâtissaient dessus un service payant. En janvier 2021, Elastic a changé de licence, avec une cible déclarée: les fournisseurs de services cloud qui revendaient son travail sans rien restituer. La cible principale était Amazon.

En avril 2021, Amazon a pris la dernière version encore libre, la 7.10.2, et en a fait un projet à part, sous Apache 2.0. Il s'appelle OpenSearch. Kibana, le tableau de bord pour les statistiques, a subi le même sort et est devenu OpenSearch Dashboards.

Puis l'affaire s'est refermée, d'une manière que presque personne n'a racontée. En août 2024, Elastic a ajouté une troisième licence aux siennes, l'AGPL v3, qui est une licence libre reconnue comme telle: Elasticsearch est redevenu disponible à des conditions ouvertes. Un mois plus tard, en septembre 2024, Amazon a cédé OpenSearch à la Linux Foundation, autrement dit s'en est dessaisi au profit d'une fondation tierce.

Le résultat est que la raison pour laquelle ils sont deux n'existe plus aujourd'hui. La séparation, si. Et entre-temps les deux projets ont marché cinq ans chacun de son côté, ce qui, à la vitesse où va ce secteur, n'est pas rien.

CE QU'ILS SAVENT FAIRE AUJOURD'HUI SUR LE SENS

Tous deux sont équipés, et c'est la nouvelle pour qui s'était arrêté en 2021.

Tous deux disposent d'un champ sémantique qui se configure en une seule étape: on déclare que ce champ doit être traité par le sens, et le moteur se charge du reste, c'est-à-dire transformer les textes en nombres au chargement et la question en nombres à l'interrogation. Elasticsearch l'a introduit en août 2024, OpenSearch en juin 2025.

Tous deux apportent leurs propres modèles, sans obligation de passer par un fournisseur extérieur. Elasticsearch a ELSER pour l'anglais et un modèle multilingue pour le reste; OpenSearch a ses équivalents, plus la prise en charge des images et de la recherche conversationnelle.

Et tous deux font de la recherche hybride, avec les deux mêmes techniques. Hybride signifie que le moteur produit deux classements sur le même catalogue, l'un par mots et l'autre par sens, puis doit les fondre en un seul. La première méthode ne regarde que la position: un produit classé troisième dans une liste et septième dans l'autre reçoit un score calculé à partir de ces deux nombres, sans tenir compte de la force du placement. La seconde additionne les scores réels, après les avoir pondérés: sept dixièmes d'un côté, trois de l'autre. La première est plus robuste, la seconde plus pilotable. Les avoir toutes les deux est ce que l'on attend d'un outil sérieux.
Sur ce plan, prétendre qu'ils seraient restés en arrière serait faux.

LÀ OÙ LES DEUX SE SONT SÉPARÉS

Les deux paris techniques de ces dernières années disent bien où chacun pense aller.

Elastic a travaillé sur la compression. Les nombres qui représentent un texte occupent de la mémoire, et la mémoire est le poste qui fait exploser la facture d'une installation vectorielle. Depuis la version 9.1, Elasticsearch compresse automatiquement les vecteurs au-delà d'une certaine taille, avec une économie annoncée supérieure à quatre-vingt-dix pour cent par rapport à la représentation pleine. C'est un pari sur le coût d'exploitation.

OpenSearch a travaillé sur l'ampleur, et accepte des vecteurs quatre fois plus grands que ceux qu'admet Elasticsearch. C'est un pari sur ceux qui arrivent avec des modèles de recherche construits sur mesure, qui produisent ces nombres et ne veulent pas les rogner.

Dit de façon moins élégante: l'un optimise pour qui a beaucoup de données et un budget, l'autre pour qui a des exigences inhabituelles et quelqu'un capable de les gérer.

QUAND ILS CONVIENNENT À UNE BOUTIQUE, ET QUAND NON

Nous arrivons au point, et la réponse ne porte pas sur les fonctionnalités.

Elasticsearch et OpenSearch ne sont pas des moteurs de recherche pour boutiques. Ce sont des infrastructures de recherche à usage général, nées pour absorber des journaux système et de grandes quantités de documents, et la recherche produit n'est que l'un des emplois possibles. Qui les choisit n'achète pas un appareil prêt à brancher, il achète une caisse à outils: tout est dedans, et c'est à vous de le monter.

Ils ont du sens lorsqu'il existe déjà, dans l'entreprise, quelqu'un qui les administre, lorsque la recherche n'est pas le seul usage prévu, lorsque le catalogue est hors norme ou doit être interrogé de façons qu'un moteur de boutique ne prévoit pas.

Ils n'en ont pas lorsqu'on les adopte pour la recherche du site et rien d'autre. Le poste de coût déterminant n'est pas la licence, aujourd'hui ouverte des deux côtés: c'est la personne qui les maintient debout. Dimensionnement, mises à jour, mémoire, grappes de serveurs, et l'astreinte quand quelque chose s'arrête un samedi. Cette personne coûte plus que l'abonnement que l'on voulait économiser et, contrairement à l'abonnement, elle ne se résilie pas.

C'est exactement la raison pour laquelle j'ai changé de voie en 2024, et je le referais.

LÀ OÙ JE LES UTILISE ENCORE

Une précision, pour que l'article ne devienne pas un réquisitoire.

OpenSearch, je l'ai repris en main, mais pour un métier différent: conserver la connaissance d'un agent automatique, c'est-à-dire les documents dans lesquels le système puise avant de répondre. Là, il faut un entrepôt de vecteurs solide, capable d'encaisser des volumes sérieux et de rester sur ses propres machines, et la recherche produit n'a rien à y voir. Dans ce rôle il fonctionne bien et c'est un choix défendable.

Le problème n'est pas que ce soient de mauvais outils. C'est que ce sont des outils pour un autre problème.

DE QUEL CÔTÉ NOUS SOMMES, DIT CLAIREMENT

Pour la recherche d'un e-commerce, nous travaillons avec Algolia et avec Meilisearch, et nous le disons ouvertement plutôt que de feindre l'équidistance.

La raison tient en une phrase, et ce n'est pas la vitesse: l'un comme l'autre sont conçus pour ce métier et non pour un métier quelconque. Ils arrivent en sachant ce qu'est un produit, une déclinaison, une vitrine composée à la main, une recherche qui doit répondre pendant que le client est encore en train d'écrire. La recherche par le sens, ils l'ont; la recherche hybride aussi; et ils ne réclament pas en échange une personne dédiée.

Entre les deux, Algolia est un service géré et se paie en conséquence; Meilisearch peut rester sur vos propres machines, avec un effort d'administration qui demeure proportionné. Lequel des deux dépend du catalogue et de ceux qui travaillent dedans, et c'est une décision qui se prend en regardant les données réelles, pas les grilles tarifaires.

La bonne question, avant même de choisir un nom, reste celle de toujours: vous faut-il un outil de recherche, ou une installation à construire?