Algolia et Elasticsearch partagent un objectif commun, indexer du contenu pour le retrouver rapidement, mais pas la même philosophie de configuration : l’un expose un ensemble de réglages de pertinence prêts à l’emploi via son interface et son API, l’autre demande de déclarer explicitement chaque comportement recherché dans un mapping et une requête function_score. Ce cas retrace la migration d’une équipe qui quitte Algolia pour Elasticsearch, sur une extension WordPress à fort volume de contenu, afin de réduire un coût d’abonnement devenu disproportionné par rapport au trafic réel.
Le contexte du cas
L’extension indexait son contenu vers Algolia depuis plusieurs années, avec un classement personnalisé combinant popularité, fraîcheur de publication et disponibilité en stock. L’export d’Algolia fournit les documents bruts, mais aucun de ses réglages de pertinence ne se transfère automatiquement vers un autre moteur : ce sont des paramètres propres au fonctionnement interne d’Algolia, sans équivalent formel exportable.
Ce qui se reconstruit à la main
Le classement personnalisé (custom ranking)
Algolia applique son classement personnalisé comme un critère de tri secondaire, après la pertinence textuelle stricte, configuré simplement en désignant un ou plusieurs champs numériques. Sous Elasticsearch, ce comportement doit être recréé explicitement via une requête function_score, qui combine le score de pertinence textuelle avec un facteur calculé à partir des champs concernés :
{
"query": {
"function_score": {
"query": { "multi_match": { "query": "chaise scandinave", "fields": ["titre", "description"] } },
"functions": [
{ "field_value_factor": { "field": "popularite", "factor": 1.2, "missing": 0 } },
{ "gauss": { "date_publication": { "origin": "now", "scale": "30d" } } }
],
"score_mode": "sum",
"boost_mode": "multiply"
}
}
}Cette requête ne se devine pas depuis les réglages Algolia exportés : elle doit être écrite et testée manuellement, champ par champ, jusqu’à retrouver un ordre de résultats jugé équivalent par les équipes métier.
Les synonymes
Les synonymes déclarés dans le tableau de bord Algolia (« canapé » relié à « sofa », par exemple) ne sont ni exportables en l’état, ni compatibles tels quels avec la syntaxe attendue par Elasticsearch, qui utilise un filtre d’analyse dédié déclaré dans le mapping de l’index :
"filter": {
"synonymes_mobilier": {
"type": "synonym",
"synonyms": [ "canape, sofa", "chaise, siège" ]
}
}Chaque paire doit être ressaisie manuellement, ce qui est aussi l’occasion de vérifier que la liste initiale n’a pas accumulé, au fil des années, des entrées devenues obsolètes.
La tolérance aux fautes de frappe
Algolia applique une tolérance aux fautes activée par défaut et ajustée finement selon la longueur des mots. Elasticsearch propose un mécanisme comparable via le paramètre fuzziness sur une requête match, mais son comportement diffère sensiblement sur les mots courts, ce qui impose une phase de test spécifique plutôt qu’une simple transposition de valeur.
Ce qui se transfère sans difficulté
À l’inverse, la structure des documents eux-mêmes (titre, description, prix, catégorie) se transfère sans perte via un script d’export-import classique, chaque document Algolia devenant un document Elasticsearch avec le même identifiant, réutilisé comme clé primaire dans les deux systèmes le temps de la bascule.
La bascule : double indexation, pas de coupure sèche
Plutôt que de couper Algolia du jour au lendemain, l’équipe a maintenu une double indexation pendant plusieurs semaines : chaque publication d’article déclenchait un envoi vers les deux moteurs simultanément, pendant que l’équipe ajustait la requête function_score jusqu’à obtenir un classement jugé satisfaisant par comparaison directe avec les résultats Algolia sur les mêmes recherches types.
Notre verdict
Migrer d’Algolia vers Elasticsearch n’est jamais une opération d’export-import simple : c’est une reconstruction manuelle et assumée de la logique de pertinence, qui demande un budget de temps largement sous-estimé si l’on ne considère que le transfert des documents. Pour une équipe qui dispose des compétences internes pour maintenir des requêtes function_score dans la durée, l’économie réalisée sur l’abonnement justifie cet effort ; dans le cas contraire, le coût de maintenance additionnel mérite d’être comparé honnêtement à l’économie visée avant de se lancer.
