Que devient Elasticsearch en 2026 ?

J’étais hier à Elastic{On} Paris – la conférence de l’éditeur d’Elasticsearch 🔎. Dans cet article, je vais vous partager mon point de vue de développeur et consultant Elasticsearch sur les nouveautés, la direction, la transformation des usages du moteur et son écosystème.

Section intitulée l-ia-est-la-prioriteL’IA est la priorité 🤖

Elastic fait tout pour asseoir sa place dans le monde des LLM, avec beaucoup de nouveautés pour améliorer la recherche par vecteurs, leur stockage et les performances générales ; et il faut le dire : la majorité des talks de la journée en parlaient ! Il est loin le temps où nous parlions des nouveautés de Lucene 🤣

L’IA générative s’invite partout, et les premiers retours d’expérience concrets arrivent également, au fur et à mesure que les solutions s’améliorent. Nous allons de plus en plus souvent intégrer des LLM, développer des serveurs MCP, mettre de l’IA dans les workflows de nos clients, et Elastic compte bien avoir sa part du gâteau dans cette révolution technique.

Section intitulée la-recherche-hybride-s-amelioreLa recherche hybride s’améliore 👬

La recherche hybride est le fait de combiner des résultats de recherche vectorielle (KNN) avec des résultats lexicaux (BM25), afin de proposer des résultats exploitant le meilleur des deux mondes.

Un des challenges est la fusion des résultats ; et dans Elasticsearch, elle se fait avec différents « retriever » :

• RRF (Reciprocal Rank Fusion) : bon choix si on n’a pas trop de règles métier ;
• Weighted RRF : permet de donner de la pondération ;
• Linear : utilise une somme pondérée des scores originaux…

La RRF ne nécessite aucun réglage préalable, et les différents indicateurs de pertinence n’ont pas besoin d’être liés entre eux pour obtenir des résultats de haute qualité. La syntaxe vient de changer et elle ressemble maintenant à cela :

GET /retrievers_example/_search
{
    "retriever": {
        "linear": {
            "retrievers": [
                {
                    "retriever": {
                        "standard": {
                            "query": {
                                "match": {
                                    "content": "raccord coudé en laiton"
                                }
                            }
                        }
                    },
                    "weight": 2,
                    "normalizer": "minmax"
                },
                {
                    "retriever": {
                        "knn": {
                            "field": "vector",
                            "query_vector": [ // Des vecteurs de recherche
                                0.23,
                                0.67,
                                0.89
                            ],
                            "k": 3,
                            "num_candidates": 5
                        }
                    },
                    "weight": 1.5,
                    "normalizer": "minmax"
                }
            ],
            "rank_window_size": 10
        }
    },
    "_source": false
}

Elastic 9.2 apporte aussi une grosse amélioration de la performance dont ils ont beaucoup parlé : DiskBBQ.

Aujourd’hui, les vecteurs sont indexés via HNSW (Hierarchical Navigable Small Worlds), qui est un genre de graphe à plusieurs niveaux. Ce graphe est parcouru, une similarité entre chaque nœud est calculée, et chaque niveau est visité l’un après l’autre. À chaque niveau, on a de plus en plus de nœuds à parcourir, mais à la fin nous obtenons les plus « justes ».

Sur le disque, ces vecteurs ne sont pas au même endroit et donc les lire coûte cher 💸. Pour indexer dans ce graphe, il faut aussi faire des recherches, et pour merger des segments, il faut monter le graphe complet en mémoire… et ça coûte cher aussi 💸

Dans DiskBBQ, les vecteurs sont groupés par similarité. Ces vecteurs proches vont donc être localisés près les uns des autres, et la lecture sera donc séquentielle lors des recherches. Pour l’indexation, c’est aussi beaucoup mieux, car tout se passe dans le CPU.

DiskBBQ va être automatiquement appliqué à vos index si vous avez plus de 384 dimensions 👍 et la promesse est qu’il offre 95 % de réduction d’espace disque/mémoire 🚀

Un autre point d’attention est l’utilisation d’ACORN, un nouvel algorithme de recherche qui permet de filtrer efficacement les nœuds traversés dans un graphe HNSW, avec des gains annoncés jusqu’à cinq fois plus rapides sur des recherches avec beaucoup de filtres.

💡 Tout va très vite en ce moment, et chaque version du moteur apporte son lot d’optimisations ; alors, si vous utilisez des vecteurs, mettez à jour Elasticsearch !

Section intitulée le-nouvel-agent-builderLe nouvel Agent Builder 🔧

Ils passent la seconde avec la release de l’Agent Builder, qui va mettre à disposition des API et des interfaces graphiques pour la création d’agents intelligents complets.

Cela va permettre l’utilisation directe d’outils en mode conversationnel : par exemple, combiner des données météo en temps réel avec un catalogue de produits indexé pour proposer le produit le mieux adapté… et c’est clé en main dans le moteur !

L’outil se veut super complet et va permettre aux clients « Entreprise » de créer des solutions agentiques très simplement : tout se fait dans une interface Kibana. On y combine des outils, comme la recherche ES|QL, la récupération de documents par ID, nos outils custom… dans des workflows, et on les utilise soit via le chat inclus, soit par l’API. Les outils de l’agent sont aussi mis à disposition dans un serveur MCP Elasticsearch.

Beaucoup de ces features reposent sur Jina.ai, qui est maintenant la propriété d’Elastic.

La démo des Streams était aussi sympa : l’idée est d’envoyer tous les logs en vrac dans Elastic. Puis un LLM est utilisé pour les partitionner (par type, par exemple « log_apache » et « log_mysql »). Enfin, toujours via un LLM et via l’interface graphique, nous pouvons créer le pipeline ingest qui va parser/analyser notre log et le rendre exploitable – la fin des galères avec nos patterns GROK ?!

Section intitulée des-retours-d-experienceDes retours d’expérience ⭐

Section intitulée la-memoire-des-agentsLa mémoire des agents

Exploiter un agent conversationnel nécessite de conserver l’historique des conversations afin de le servir comme contexte à chaque nouvelle question.

Cet historique est problématique car il peut vite être très volumineux et donc dépasser la limite de tokens autorisée. C’est là qu’il faut ruser.

• Dans LangChain, ce n’est pas terrible : ils ont un tampon, disons 30k tokens, et le reste est oublié ;
• Utiliser un LLM pour résumer la conversation, ce n’est pas terrible non plus, car on y perd en précision.

Le papier CoALA (Cognitive Architectures for Language Agents) essaie de résoudre ce problème. Il expose les différents types de mémoire : sémantique (ce que l’on sait, le RAG), épisodique (ce qu’on a fait, les actions), procédurale (système prompt)… La solution implémentée chez le client est donc de garder tout l’historique mais de le simplifier via cette logique et de le stocker dans Elasticsearch.

Section intitulée la-recherche-par-imageLa recherche par image

L’exemple de Leroy Merlin (Adeo) était très sympa. Ils veulent proposer la recherche par image dans leur catalogue de 10 000 000 de produits. Il suffirait de prendre en photo l’objet pour le trouver – pas besoin de connaître son nom précis (« raccord de bonde en laiton coudé » 🤣).

Vous connaissez la chanson : on indexe des embeddings de nos images et on recherche en KNN. Rien de plus simple, le POC fonctionne, ça part en prod… MAIS !

Il y a des challenges :

• l’usage de la mémoire explose ;
• l’espace disque n’est pas prévisible ;
• les recherches sont lentes ;
• la pertinence n’est pas toujours au rendez-vous.

Répondre avec le top K ne suffit pas, la pertinence visuelle ne suffit pas… Il faut aussi qualifier les résultats selon des critères métier (qualité, marge, stock).

Leur solution a été de montrer l’image du client à un LLM pour créer une recherche naturelle ; au final, ils font la recherche avec l’image et avec les informations que le LLM a extrait (marque, catégorie de produit…), ce qui affine leurs résultats.

Section intitulée es-ql-en-recherche-applicativeES|QL en recherche applicative ? ⚡

ES|QL est partout dans les nouveaux produits, et on se pose donc la question : est-ce mature et pouvons-nous abandonner le QueryDSL ? Personnellement, je pense que c’est un peu tôt, et les quelques personnes avec qui j’en ai parlé le pensent aussi. Cependant, il faut bien l’admettre : ES|QL permet des choses qui ne sont pas possibles en QueryDSL et il est bien plus lisible ! L’autocomplétion est aussi vraiment complète et puissante.

J’y ai découvert la syntaxe FORK, qui permet d’exploiter la recherche hybride :

FROM index METADATA _score
| WHERE match(content, "JoliCode")
| WHERE year > 2010
-- hybrid
| FORK (WHERE semantic_content: "JoliCode")
          | SORT _score DESC)
       (WHERE match(content, "JoliCode"))
          | SORT _score DESC)
| FUSE RRF
| SORT _score DESC
| LIMIT 100
-- rerank
| RERANK "JoliCode" ON content
| SORT _score DESC
| LIMIT 10

ES|QL est aussi capable de fournir des réponses augmentées par LLM – faire un résumé des résultats, par exemple :

-- passage du résultat dans un LLM
| LIMIT 6
| COMPLETION CONCAT("Summarize : ", content) WITH "openai" AS summary

Avec un FORK en plus, la même requête va permettre d’avoir des documents, un résumé, des agrégations…

J’aime beaucoup aussi l’usage de CASE pour se passer de scripts Painless, souvent catastrophiques pour les performances.

FROM employees
| EVAL type = CASE(
    languages <= 1, "monolingual",
    languages <= 2, "bilingual",
     "polyglot")
| KEEP emp_no, languages, type

Section intitulée quelques-take-away-rapidesQuelques take-away rapides 📔

• Cela fait un moment qu’il existe le type natif semantic_text, et je vous le recommande pour vos premiers essais. Il permet de s’affranchir du chunking, des dimensions, du stockage de vecteurs… C’est le moteur qui se charge de tout, et c’est aussi simple à utiliser qu’un champ text ;
• Elastic Inference Service, c’est uniquement dans Elastic Cloud ;
• Il y aura bientôt un mode « Elastic Cloud Connect » qui permettra de bénéficier de certaines fonctionnalités Cloud tout en ayant nos data nodes on-premise ;
• Les vecteurs vont passer d’un stockage en float 32 bits à 16 bits en 9.3 sans perte de recall.
• Le Serverless va bientôt (cette année) arriver en self-hosted !

Section intitulée merci-elastic-onMerci Elastic{On} 👏

J’ai passé une journée très instructive ; j’y ai trouvé du contenu technique, j’ai échangé avec des pairs, croisé de vieilles connaissances… merci Elastic !

Il est devenu difficile de suivre l’évolution du moteur depuis la version 8, les nouvelles fonctionnalités liées à l’IA sont nombreuses, et deviennent aussi un fort point de divergence avec OpenSearch, le fork d’Amazon. En terme de recherche hybride et de confort d’utilisation (ES|QL), il y a enfin de véritables impacts techniques dans le choix de l’un ou de l’autre.

---

Cet article porte sur la conférence Elastic{on} Paris 2026.