Pourquoi Elasticsearch, et pour quoi faire

Elasticsearch est un moteur de recherche et d’analytique distribué, bâti sur la bibliothèque Apache Lucene. Pour les plateformes fintech et assurance à fort volume que nous construisons à Abidjan, il excelle dans trois cas d’usage qui débordent souvent les capacités d’une base relationnelle classique : la recherche full-text, les agrégations analytiques, et la collecte de logs et de métriques (observabilité) via l’Elastic Stack.

La recherche full-text est le point fort historique : tolérance aux fautes de frappe, pertinence par scoring, recherche par préfixe, autocomplétion, gestion de la langue (analyseurs, racinisation). Les agrégations permettent de calculer en quasi temps réel des sommes, moyennes, percentiles et histogrammes sur des millions de documents. Enfin, couplé à Logstash ou aux agents Beats/Elastic Agent et à Kibana, l’ensemble forme une pile d’observabilité pour explorer logs, traces et métriques.

Concepts fondamentaux à maîtriser

Quelques notions structurent tout déploiement sérieux :

• Index : une collection de documents JSON, équivalent logique d’une table. Les documents sont sans schéma rigide mais bénéficient d’un mapping.
• Mapping : la définition des champs et de leurs types (text, keyword, date, numérique, geo). Le choix entre text (analysé pour la recherche) et keyword (exact, pour le tri et les agrégations) est une décision de conception critique.
• Shards (fragments) : chaque index est découpé en shards primaires, ce qui permet la distribution horizontale sur plusieurs nœuds. Le nombre de shards primaires est fixé à la création de l’index.
• Replicas (réplicas) : des copies des shards primaires, qui assurent la haute disponibilité et augmentent le débit de lecture.

Un anti-pattern fréquent est la sur-fragmentation : trop de petits shards consomment de la mémoire et dégradent les performances. Pour des données qui croissent dans le temps (logs, transactions), on privilégie des index temporels gérés par des politiques de cycle de vie (ILM) et des data streams.

Patterns d’architecture éprouvés

Le principe directeur que nous appliquons systématiquement : Elasticsearch est un read model, pas la source de vérité. La donnée canonique reste dans une base transactionnelle (PostgreSQL, par exemple), et Elasticsearch en est une projection optimisée pour la lecture.

• Capture des changements (CDC) : on synchronise la base primaire vers Elasticsearch via un flux d’événements (Debezium/Kafka) ou des jobs d’indexation. Cela découple l’écriture transactionnelle de l’indexation.
• Read models dédiés : on dénormalise les données dans des documents pensés pour les requêtes de l’interface, évitant des jointures coûteuses au moment de la lecture.
• Pistes d’audit et journaux : Elasticsearch est excellent pour stocker et explorer des événements en append-only (audit trails, logs applicatifs), avec rétention gérée par ILM.

Mises en garde honnêtes

Aucun outil n’est gratuit. Voici ce qu’un CTO doit intégrer avant de s’engager :

• Ce n’est pas une base primaire. Pas de transactions ACID multi-documents, pas de contraintes d’intégrité référentielle. Ne stockez jamais une donnée critique uniquement dans Elasticsearch.
• Cohérence à terme. L’indexation est quasi temps réel (par défaut un rafraîchissement périodique d’environ une seconde) ; une donnée écrite n’est pas instantanément cherchable. À concevoir explicitement.
• Coût opérationnel et ressources. Le cluster est gourmand en RAM (heap JVM, cache de pages) et en disque. La gestion des montées de version, des shards, des sauvegardes (snapshots) et de la sécurité exige une vraie expertise.
• Sécurité. Un cluster mal configuré et exposé est un risque majeur de fuite de données. Authentification, TLS et contrôle d’accès sont non négociables.

Conclusion

Bien cadré, Elasticsearch transforme l’expérience de recherche et la capacité analytique d’une plateforme. Mal cadré, il devient une dette opérationnelle. La clé est de le traiter comme une projection en lecture, alimentée proprement depuis votre source de vérité.

ProCode Legion, équipe d’ingénierie logicielle d’élite basée à Abidjan, conçoit et exploite ce type d’architecture pour les plateformes fintech et assurance d’Afrique francophone. Discutons de votre cas d’usage : contactez nos ingénieurs.