Moteurs de recherche self-hosted 2026 : Typesense, Quickwit, Manticore
Meta-description : Comparez Typesense, Quickwit, Manticore et Meilisearch pour self-héberger votre recherche full-text en 2026 — architecture, critères de choix, tableau comparatif et adaptation PME Afrique de l’Ouest. Guide complet.
Introduction : le besoin de recherche full-text pour les PME
Tout projet numérique atteint un jour un seuil critique : la base de données relationnelle suffit pour stocker, mais devient insuffisante pour chercher. Un catalogue e-commerce de 50 000 produits, une base de connaissances wiki de 5 000 articles, un CRM avec 100 000 fiches client — tous partagent le même problème. L’utilisateur tape « chaussure cuir marron taille 42 » ou « contrat Dakar 2024 » et s’attend à des résultats pertinents en moins de 100 millisecondes, avec tolérance aux fautes de frappe, tri par pertinence et filtres dynamiques. Un LIKE '%chaussure%' en SQL ne fera jamais ce travail correctement.
La réponse naturelle a longtemps été Algolia, le SaaS de référence. Ses performances sont excellentes, son SDK JavaScript intuitif. Mais son modèle tarifaire est taillé pour des startups financées en dollars : en 2025, le plan Growth facture 0,50 $ pour 1 000 opérations de recherche au-delà du quota gratuit, et le plan Premium dépasse facilement 500 $/mois pour un usage sérieux. Pour une PME sénégalaise, ivoirienne ou malienne qui opère en FCFA, c’est simplement hors de portée. Même l’Elastic Cloud (Elasticsearch managé) ou Algolia NeuralSearch restent des lignes de budget incompatibles avec la réalité de la trésorerie des entreprises de la sous-région.
En 2026, la situation a radicalement changé. Trois moteurs open-source — Typesense, Quickwit et Manticore Search — ont atteint une maturité de production qui les rend crédibles comme alternatives self-hosted. Chacun a une philosophie différente, des cas d’usage différents, et une courbe d’apprentissage différente. Ce pilier est le guide de référence pour choisir et déployer le bon outil selon votre contexte : e-commerce, wiki, CRM, logs applicatifs ou recherche documentaire.
Ce guide pilier est le centre du cluster search-selfhost. Il dresse la vue d’ensemble et renvoie vers les tutoriels pratiques satellites pour chaque déploiement spécifique. Si vous cherchez un tutorial pas-à-pas immédiat, rendez-vous directement dans la section Tutoriels du cluster.
Pourquoi self-hoster sa recherche en 2026
La question mérite d’être posée honnêtement : pourquoi s’infliger la gestion d’un service de recherche quand des SaaS existent ? La réponse tient à cinq arguments concrets que voici dans l’ordre de leur importance pratique.
Le coût est l’argument numéro un. Typesense sur un VPS Hetzner CX22 (4 Go RAM, 2 vCPU, 4,35 €/mois en 2025) supporte sans difficulté 1 million de documents et plusieurs centaines de requêtes par seconde. Comparez ce chiffre à une facture Algolia à 300–500 $/mois pour un usage équivalent. Sur 12 mois, la différence représente plus de 3 000 $ d’économies nettes — sans compter que votre VPS peut héberger simultanément d’autres services. Pour une PME dont la marge nette est de 15–20 %, cette ligne budgétaire n’est pas anecdotique.
La souveraineté des données vient en deuxième. Envoyer vos données produit, vos fiches client ou vos documents contractuels vers un serveur Algolia en Europe ou aux États-Unis pose des questions légitimes de confidentialité. Le RGPD s’applique aux données de résidents européens, mais les réglementations locales évoluent aussi en Afrique de l’Ouest — la CEDEAO travaille sur des cadres de protection des données depuis 2023. Self-héberger signifie que vos données restent sur votre infrastructure, dans la juridiction que vous choisissez.
La personnalisation est le troisième levier. Un SaaS impose ses schémas, ses limites d’index, ses règles de ranking. Un moteur self-hosted vous donne un contrôle total sur les champs indexés, les synonymes, les règles de promotion de produits, les facettes de filtrage. Quand votre catalogue nécessite un ranking basé sur le stock local à Dakar versus Abidjan, ou quand vous devez indexer du contenu en wolof avec ses spécificités linguistiques, seul un moteur sous votre contrôle vous le permettra.
La latence réseau est le quatrième facteur. Une requête vers un datacenter parisien depuis Dakar implique 50–80 ms de latence incompressible avant même que la recherche commence. Avec un VPS hébergé à Francfort ou à Varsovie (les localisations Hetzner les plus proches de l’Afrique de l’Ouest), cette latence tombe à 30–50 ms. Avec un VPS sur un hébergeur local (OVHcloud à Dakar, si disponible, ou un acteur local comme Sonatel Business), on peut descendre à 5–15 ms. Pour une expérience de recherche instantanée — critère UX majeur — chaque milliseconde compte.
L’évolutivité contrôlée est le dernier argument. Quand votre trafic triple pendant une promotion, un SaaS vous facture proportionnellement et peut imposer des limits de taux. Un cluster self-hosted peut être dimensionné à l’avance selon vos prévisions, et un simple vertical scaling (augmenter la RAM du VPS) suffit pour absorber des pics raisonnables sans surcoût immédiat.
Ces cinq arguments ne signifient pas qu’Algolia est mauvais — c’est un excellent produit pour les startups avec un budget solide et zéro envie de gérer de l’infrastructure. Mais pour le profil PME ouest-africaine typique d’itskillscenter.io — portail de formation, boutique WooCommerce, wiki interne, CRM custom — le self-hosting est la décision rationnelle.
Les 4 contenders : Typesense, Quickwit, Manticore, Meilisearch
Le marché des moteurs de recherche open-source self-hosted compte aujourd’hui quatre acteurs principaux qui se distinguent d’Elasticsearch par leur légèreté, leur facilité d’installation et leur absence de dépendance à la JVM. Voici une présentation détaillée de chacun.
Typesense — le moteur léger écrit en Go/C++
Typesense est développé par une équipe basée aux États-Unis et sa première version stable a été publiée en 2019. Le binaire est écrit en C++ avec une couche d’API en Go, ce qui explique son empreinte mémoire remarquablement faible et ses temps de démarrage de l’ordre de la seconde. En 2026, la version 26.0 est la référence de production (selon typesense.org/docs).
L’architecture de Typesense est délibérément simple : tout l’index est conservé en RAM, avec persistance sur disque. Cette décision de conception explique ses performances de requêtes exceptionnelles — généralement sous 10 ms pour des collections de moins de 5 millions de documents — mais impose une contrainte : la taille de votre index est limitée par la RAM disponible. Pour 1 million de documents avec une douzaine de champs textuels, Typesense consomme entre 1,5 et 2,5 Go de RAM selon la longueur des textes. Un VPS à 4 Go est donc parfaitement dimensionné pour un déploiement PME standard.
Typesense propose nativement la recherche avec tolérance aux fautes de frappe (typo-tolerance), la recherche sémantique vectorielle (depuis la v0.25), les synonymes, le ranking personnalisé et les facettes de filtrage dynamique. Son API REST est bien conçue et les SDKs officiels couvrent JavaScript, Python, PHP, Ruby, Go, Java et Dart. L’interface d’administration Typesense Dashboard (disponible séparément ou via Typesense Cloud) est propre et fonctionnelle.
Le mode cluster de Typesense (Raft-based) est disponible depuis la v0.19 et permet de constituer un ensemble de 3 nœuds ou plus pour la haute disponibilité. Pour une PME, un nœud unique suffit largement ; le clustering devient pertinent à partir de 10 millions de documents ou de SLA stricts (99,9 % uptime).
L’un des atouts majeurs de Typesense pour les développeurs africains est sa documentation exemplaire : des guides de démarrage rapide, des recettes pour WooCommerce, Magento, BookStack et même des exemples spécifiques aux wikis multi-langues. La communauté Slack officielle (Typesense Community Slack) répond en général en quelques heures.
Cas d’usage idéal : e-commerce (catalogue produits, recherche instantanée front-end), CMS avec recherche, wiki d’entreprise, application mobile avec recherche offline-first, tout projet où la simplicité opérationnelle prime.
Quickwit — logs et recherche distribuée
Quickwit est un projet français (Paris), open-source sous licence AGPL-3.0, dont la première version stable majeure (v0.5) est sortie en 2023. La documentation officielle est disponible sur quickwit.io/docs. En 2026, la version 0.8.x est la référence de production.
Là où Typesense est conçu pour la recherche applicative (catalogue, wiki), Quickwit est architecturé pour un cas d’usage radicalement différent : l’ingestion et la recherche de logs à haute volumétrie. Son architecture repose sur un découplage complet entre le stockage et le calcul. Les index sont stockés sur un objet-store compatible S3 (AWS S3, MinIO, Cloudflare R2, Backblaze B2) et les nœuds de calcul sont stateless. Cette approche permet une élasticité horizontale sans la complexité opérationnelle d’Elasticsearch.
Quickwit indexe en natif le format JSON avec schéma dynamique, gère les timestamps avec une précision à la nanoseconde, et supporte les requêtes en syntaxe Lucene ainsi qu’une API compatible OpenSearch pour faciliter les migrations. Il expose également une API compatible Jaeger pour les traces distribuées, ce qui en fait un choix naturel pour les stacks d’observabilité.
En termes de performances, Quickwit est optimisé pour le write throughput plutôt que pour la latence de requête. Il peut ingérer des millions de lignes de logs par seconde sur un cluster modeste, là où les latences de recherche sont de l’ordre de 100–500 ms (acceptable pour des tableaux de bord d’observabilité, moins pour une barre de recherche utilisateur). Cette distinction est fondamentale pour le choix entre Quickwit et Typesense.
Quickwit intègre aussi une couche de recherche full-text sur documents structurés, et son équipe développe activement des fonctionnalités orientées RAG (Retrieval-Augmented Generation) pour les usages LLM. En 2026, c’est donc également un contender intéressant pour les PME qui veulent indexer des bases documentaires volumineuses (contrats, rapports, emails) et les interroger via un LLM local.
Cas d’usage idéal : centralisation de logs applicatifs (alternative open-source à Datadog ou Elastic APM), observabilité DevOps, indexation de documents structurés volumeux (millions d’enregistrements), stack RAG avec stockage objet.
Manticore Search — la puissance du SQL
Manticore Search est né en 2017 comme fork de Sphinx Search, l’ancêtre des moteurs de recherche open-source. La documentation officielle est sur manticoresearch.com/docs. En 2026, la version 6.x est stable et activement maintenue. L’équipe principale est distribuée entre la Russie et l’Europe de l’Est.
Ce qui distingue fondamentalement Manticore de tous ses concurrents, c’est son interface SQL native. Manticore comprend un dialecte SQL complet, compatible avec les clients MySQL (même port 9306, même protocole binaire), ce qui signifie que n’importe quel code PHP, Python ou Node.js qui sait parler à MySQL peut parler à Manticore sans modification de bibliothèque. Pour des équipes qui ont déjà des compétences SQL et des ORMs configurés, c’est un avantage opérationnel considérable.
Manticore supporte plusieurs types de tables : les plain tables (index statique construit depuis une source de données), les real-time tables (index mise à jour en direct via INSERT/UPDATE/DELETE comme une base SQL), et les distributed tables (sharding horizontal). La recherche full-text utilise le langage de requête SphinxQL avec des opérateurs étendus : phrase matching ("mot1 mot2"), proximité (NEAR(mot1, mot2, 5)), pondération par champ, etc.
Manticore intègre nativement le support des index columnaires pour accélérer les agrégations analytiques sur de grands volumes de données numériques, une fonctionnalité peu commune dans cette catégorie de moteurs. Il supporte aussi la recherche vectorielle (k-NN) depuis la v5.0, ce qui ouvre des cas d’usage hybrides texte + vecteur.
La performance brute de Manticore sur de grands volumes est impressionnante : les benchmarks publiés par l’équipe (sur manticoresearch.com) montrent des performances supérieures à Elasticsearch sur des workloads de log analytics, avec une consommation mémoire bien inférieure. Pour un corpus de 500 millions de lignes de logs sur un seul serveur, Manticore est crédible là où Elasticsearch nécessiterait un cluster coûteux.
La courbe d’apprentissage est douce pour les développeurs SQL, mais la documentation, bien que complète, est moins soignée visuellement que celle de Typesense ou Meilisearch. Les exemples pour des intégrations modernes (Next.js, Vue.js) sont moins nombreux. C’est un outil davantage apprécié des DBA et des équipes backend que des développeurs front-end.
Cas d’usage idéal : migration depuis Sphinx Search, applications avec codebase SQL existante importante, log analytics mono-serveur à très haute volumétrie, CRM et ERP nécessitant des agrégations complexes, équipes avec forte culture SQL.
Meilisearch — déjà couvert dans le corpus
Meilisearch (meilisearch.com) est un moteur de recherche open-source français qui partage plusieurs caractéristiques avec Typesense : binaire léger, API REST intuitive, typo-tolerance native, focus développeur. Il est déjà couvert en détail dans un article dédié du corpus d’itskillscenter.io. Nous le mentionnons ici pour compléter le panorama du marché et permettre la comparaison dans le tableau synthétique.
Meilisearch a opté pour un modèle freemium depuis 2023 (Meilisearch Cloud avec tier gratuit + plans payants), mais la version open-source reste disponible et auto-hébergeable. Ses atouts sont une expérience développeur excellente et une configuration quasi-zéro pour des cas d’usage simples. Pour un article complet sur Meilisearch, référez-vous à la section Tutoriels du cluster.
Critères de choix
Choisir un moteur de recherche self-hosted n’est pas un exercice de benchmarking abstrait. C’est avant tout une décision de contexte : quelles sont les contraintes réelles de votre projet, de votre équipe et de votre infrastructure ? Voici les sept critères qui, combinés, permettent de trancher.
1. Volume de données et fréquence de mise à jour. Typesense et Meilisearch sont optimisés pour des corpus de moins de 10 millions de documents avec des mises à jour fréquentes (e-commerce, wiki vivant). Manticore et Quickwit sont plus adaptés à des volumes massifs (des centaines de millions de records) ou à l’ingestion continue de flux de données (logs, événements temps réel). Si votre catalogue WooCommerce compte 50 000 produits mis à jour plusieurs fois par jour, Typesense est dimensionné pour ça sans effort. Si vous centralisez les logs de 20 applications, Quickwit est le bon choix.
2. Latence de requête requise. Pour une barre de recherche utilisateur (search-as-you-type), l’expérience est dégradée au-delà de 50 ms. Typesense et Meilisearch sont dans la tranche 1–20 ms pour des collections raisonnables. Manticore est dans la même tranche sur des index bien configurés. Quickwit est plus lent (100–500 ms) mais ce n’est pas son objectif premier. Choisissez en fonction de l’interaction utilisateur attendue.
3. Compétences de l’équipe. Avez-vous des développeurs PHP/SQL seniors ? Manticore sera immédiatement familier. Avez-vous une équipe JavaScript/TypeScript moderne ? Typesense avec son SDK officiel excellent sera plus rapide à mettre en œuvre. Une équipe DevOps habituée à Elasticsearch appréciera l’API compatible OpenSearch de Quickwit.
4. Contraintes mémoire et budget infrastructure. Sur un VPS à 2 Go de RAM, seul Typesense (ou Meilisearch) est raisonnablement deployable pour une collection de quelques centaines de milliers de documents. Manticore en mode real-time consomme plus de mémoire sur de grands volumes. Quickwit est le moins gourmand en RAM grâce à son architecture stockage-objet, mais nécessite un accès à un stockage objet compatible S3.
5. Recherche multilingue et support des caractères spéciaux. Si vous avez besoin d’indexer du contenu en arabe, en wolof ou dans des langues avec diacritiques spéciaux, vérifiez le support de l’Unicode normalization et des tokenizers personnalisés. Typesense supporte nativement l’arabe (tokenization RTL), le chinois, le japonais et le coréen depuis la v0.23. Manticore supporte le UTF-8 et peut être configuré avec des morphologies personnalisées. Quickwit supporte l’Unicode complet via sa bibliothèque de tokenization Rust.
6. Haute disponibilité et tolérance aux pannes. Si votre SLA impose 99,9 % de disponibilité, vous avez besoin d’un cluster multi-nœuds. Typesense (cluster Raft), Manticore (replication) et Quickwit (architecture distribuée native) supportent tous le clustering, mais avec des niveaux de maturité et de complexité opérationnelle différents. Pour la plupart des PME, un seul nœud avec une procédure de backup/restore robuste est suffisant et bien moins complexe.
7. Écosystème et intégrations. Avez-vous besoin d’une intégration native avec WordPress/WooCommerce ? Un plugin Typesense pour WooCommerce existe (WP Typesense). Avec Manticore, l’intégration se fait via requêtes SQL directes depuis PHP. Quickwit n’a pas d’intégrations CMS natives — il est orienté infrastructure et DevOps. Meilisearch a le plugin WordPress le plus mature (SearchWP / Relevanssi alternatives).
Tableau comparatif
| Critère | Typesense 26.0 | Quickwit 0.8 | Manticore 6.x | Meilisearch 1.x |
|---|---|---|---|---|
| Langage principal | C++ / Go | Rust | C++ | Rust |
| Licence | GPL-3.0 | AGPL-3.0 | GPL-2.0 | MIT |
| Index en RAM | Oui (tout en RAM) | Non (stockage objet) | Partiel (columnstore) | Oui (tout en RAM) |
| Latence requête | 1–20 ms | 100–500 ms | 1–50 ms | 1–30 ms |
| Interface principale | API REST + SDKs | API REST (compatible OpenSearch) | SQL (MySQL protocol) + REST | API REST + SDKs |
| Volume cible | < 10M docs | 100M+ docs / logs | 1M à 1B+ docs | < 10M docs |
| RAM pour 1M docs | 1,5–2,5 Go | Très faible (stockage objet) | 1–3 Go | 2–4 Go |
| Typo-tolerance native | Oui | Non | Non (fuzzy via OPTION) | Oui |
| Recherche vectorielle | Oui (v0.25+) | Oui | Oui (v5.0+) | Oui (v1.3+) |
| Multilingue / arabe | Oui (natif) | Oui (Unicode) | Oui (UTF-8) | Oui (natif) |
| Clustering HA | Oui (Raft) | Oui (natif) | Oui (réplication) | Oui |
| Plugin WordPress | Oui (WP Typesense) | Non | Non officiel | Oui (plusieurs) |
| Cas d’usage principal | E-commerce, wiki, app | Logs, observabilité, RAG | SQL-heavy, CRM, logs | E-commerce, wiki, app |
| Facilité de prise en main | Très facile | Intermédiaire | Facile pour DBA SQL | Très facile |
| VPS minimum recommandé | CX22 (4 Go / 2 vCPU) | CX22 + objet-store | CX22 (4 Go / 2 vCPU) | CX22 (4 Go / 2 vCPU) |
Ce tableau résume les différences structurelles. Le bon choix dépend de votre profil : si vous êtes une PME e-commerce ou une organisation avec un wiki interne, Typesense est le point de départ recommandé. Si vous gérez des logs ou une infrastructure DevOps, Quickwit est supérieur. Si votre équipe est SQL-native et que le volume est important, Manticore prend l’avantage.
Tutoriels du cluster search-selfhost
Ce pilier est le centre d’un cluster éditorial dédié aux moteurs de recherche self-hosted. Les tutoriels pratiques ci-dessous approfondissent chaque déploiement spécifique avec des étapes pas-à-pas testées :
Installation Typesense sur Ubuntu 22.04, configuration des collections, intégration WooCommerce via WP Typesense, indexation d’un wiki BookStack, monitoring avec Prometheus. Cible : PME e-commerce Afrique de l’Ouest sur Hetzner CX22.
Installation Quickwit 0.8, configuration d’un index de logs, intégration MinIO comme objet-store local, ingestion depuis Docker/Kubernetes via Fluentbit, tableau de bord Grafana. Cible : équipes DevOps gérant 5–20 services.
Ces deux satellites sont en cours de rédaction. En attendant, les sections de ce pilier couvrent les concepts fondamentaux et les choix d’architecture suffisants pour démarrer un déploiement de test.
Adaptation au contexte ouest-africain
Déployer un moteur de recherche self-hosted en Afrique de l’Ouest en 2026 n’est pas identique à le faire depuis Paris ou Berlin. Les contraintes d’infrastructure, les réalités économiques et les besoins linguistiques créent un contexte spécifique qui mérite d’être adressé directement plutôt que traité comme un cas marginal.
Choix du VPS et de l’hébergeur. Hetzner Cloud reste en 2026 le meilleur rapport qualité-prix pour les équipes africaines qui ne trouvent pas d’hébergement local satisfaisant. Le serveur CX22 (2 vCPU AMD, 4 Go RAM, 40 Go NVMe SSD, bande passante 20 TB/mois) est facturé 4,35 €/mois. Ce profil suffit largement pour indexer 1 million de documents Typesense avec 300–500 requêtes par seconde en pic. Si vous avez besoin de 2 millions de documents, passez au CX32 (4 vCPU, 8 Go RAM, 80 Go SSD, 8,70 €/mois) — la latence reste identique car Typesense est limité par la RAM, pas par le CPU. Scaleway (francophone, basé à Paris), OVHcloud et DigitalOcean offrent des alternatives similaires. Contabo est moins cher mais avec des performances plus variables et un support moins réactif.
Pour les équipes qui souhaitent héberger en Afrique, Orange Business, MTN Business et des acteurs comme Africa’s Talking proposent des offres cloud en croissance, mais les options de VPS standard restent limitées comparées à Hetzner. Il est raisonnable d’utiliser Hetzner (datacenter Nuremberg ou Falkenstein) pour un délai de 30–50 ms depuis Dakar ou Abidjan, et de planifier une migration locale quand les offres régionales auront atteint la parité de prix et de fiabilité.
Recherche multilingue : français, wolof et arabe. C’est l’une des différenciations clés pour le contexte ouest-africain. Le français est bien supporté par tous les moteurs grâce aux analyseurs linguistiques standards. L’arabe est nativement supporté par Typesense (tokenizer RTL, normalisation des diacritiques arabes, support des hamza et tashkeel) — c’est un avantage concret pour les sites islamiques, les CRM avec données en arabe ou les bases de données de contenu coranique. Le wolof ne dispose pas encore d’un tokenizer natif dans aucun de ces moteurs, mais il peut être traité comme une langue non-segmentée (tokenization par espace, ce qui fonctionne car le wolof est une langue à espacement régulier). Pour améliorer la recherche wolof, vous pouvez construire un dictionnaire de synonymes et de formes variantes dans Typesense, qui supporte les synonymes multilingues dans ses collections.
E-commerce et intégration CinetPay. Si vous construisez une boutique WooCommerce avec paiement mobile money via CinetPay (Orange Money, Wave, MTN Mobile Money), l’intégration de Typesense améliore radicalement l’expérience de recherche produit. Le plugin WP Typesense (disponible sur GitHub sous typesense/typesense-wordpress-plugin) synchronise automatiquement le catalogue WooCommerce vers Typesense et remplace le moteur de recherche natif WordPress par une interface de recherche instantanée. La configuration prend moins d’une heure. Le principal bénéfice pour les boutiques africaines : les catalogues qui incluent des termes en plusieurs langues (nom du produit en français, description en wolof, tags en anglais) sont mieux indexés par Typesense que par le LIKE SQL de WooSearch natif.
Wiki d’entreprise avec BookStack. BookStack (bookstackapp.com) est l’outil de wiki le plus populaire pour les PME francophones. Sa recherche native est basique et repose sur MySQL FULLTEXT — acceptable pour 500 pages, insuffisante au-delà de 5 000 pages avec des requêtes complexes. Typesense peut être intégré à BookStack via son API REST : un script de synchronisation Python (lancé via cron toutes les 5 minutes) récupère les nouvelles pages BookStack et les pousse dans Typesense. L’interface de recherche peut ensuite être remplacée par un widget Typesense InstantSearch. Ce type d’intégration est documenté dans le tutoriel satellite dédié (en cours de rédaction).
Contraintes réseau et mode dégradé. Les coupures de courant et les ruptures de connexion internet sont une réalité dans plusieurs pays de la sous-région. Pour les applications mobiles (React Native, Flutter) qui intègrent une recherche, envisagez une stratégie de cache local des résultats les plus fréquents. Typesense supporte les requêtes en mode cache côté client, et son SDK JavaScript expose une option cacheSearchResultsForSeconds qui maintient les résultats en mémoire pendant N secondes. Pour des applications avec un usage hors-ligne fréquent, une base IndexedDB locale contenant les 1 000 produits les plus populaires peut servir de fallback quand Typesense n’est pas joignable.
Monitoring adapté aux ressources limitées. Sur un VPS CX22 à 4,35 €/mois, vous ne voulez pas consacrer 1 Go de RAM supplémentaire à un stack Prometheus + Grafana complet. Une alternative légère : Typesense expose un endpoint /metrics.json natif que vous pouvez scraper avec un script cron toutes les 5 minutes et envoyer à BetterStack Telemetry (tier gratuit : 1 Go de logs/mois) ou Grafana Cloud (tier gratuit similaire). Si vous préférez un monitoring totalement self-hosted, Netdata (netdata.cloud) s’installe en une commande et consomme moins de 100 Mo de RAM.
Erreurs fréquentes à éviter
| Erreur | Cause | Solution |
|---|---|---|
| Oublier de persister le répertoire de données Typesense | Lancement du conteneur Docker sans volume -v /data:/typesense-data — toutes les données sont perdues au redémarrage |
Toujours monter un volume persistant et vérifier avec docker inspect que le bind mount est correct avant de charger les données |
| Indexer tous les champs sans définir les champs de recherche | Schéma de collection Typesense avec tous les champs en "index": true — consomme 3–4× plus de RAM que nécessaire |
Ne marquer "index": true que pour les champs effectivement recherchés ; utiliser "facet": true uniquement pour les facettes ; laisser les IDs et timestamps hors index de recherche |
| Déployer Quickwit sans objet-store configuré | Mode de stockage local par défaut de Quickwit inadapté à la production — pas de réplication, pas de scalabilité | Configurer MinIO (self-hosted) ou Backblaze B2 (très économique : 6 $/To/mois) comme backend de stockage avant tout déploiement production |
| Oublier de configurer la mémoire virtuelle Linux pour Manticore | Manticore sur les index columnaires bénéficie de vm.max_map_count=262144 — sans ce paramètre, les performances dégradent sur de grands volumes |
Ajouter vm.max_map_count=262144 dans /etc/sysctl.conf et appliquer avec sysctl -p |
| Exposer le port Typesense directement sur l’IP publique | Le port 8108 de Typesense n’est pas protégé par HTTPS nativement — la clé API circule en clair | Toujours placer un reverse proxy Nginx ou Caddy devant Typesense avec TLS, et lier Typesense sur 127.0.0.1:8108 uniquement |
| Ne pas planifier les snapshots/backups de l’index | L’index en RAM de Typesense est persisté sur disque mais sans versioning — une corruption de disque ou une fausse manipulation efface tout | Utiliser l’API Typesense POST /operations/snapshot?snapshot_path=/backup/$(date +%Y%m%d) quotidiennement via cron, et synchroniser vers un bucket objet-store externe |
| Synchroniser WooCommerce → Typesense sans gérer les produits supprimés | Les scripts de synchronisation basiques n’écoutent pas le hook before_delete_post — les produits supprimés restent indexés et apparaissent dans les résultats |
Implémenter la suppression via le hook WordPress et l’API Typesense DELETE /collections/{nom}/documents/{id}, ou utiliser une synchronisation complète hebdomadaire qui efface et réindexe la collection |
FAQ
- Q : Typesense peut-il remplacer Elasticsearch complètement ?
- R : Pour la grande majorité des cas d’usage PME (e-commerce, wiki, CRM, recherche documentaire jusqu’à 10 millions de documents), oui. Elasticsearch reste supérieur pour les workloads analytiques extrêmes (agrégations complexes sur des milliards de documents), les pipelines d’ingestion avec transformations Logstash, et les entreprises qui ont déjà un investissement Elastic (SIEM, APM, Fleet). Si vous partez de zéro pour un projet PME, Typesense est plus simple à opérer et 10–20× moins coûteux en infrastructure.
- Q : Peut-on utiliser Typesense et Quickwit ensemble sur le même serveur ?
- R : Oui, avec les bonnes précautions de dimensionnement. Sur un VPS CX32 (8 Go RAM), vous pouvez faire cohabiter Typesense (pour la recherche applicative) et Quickwit (pour les logs). Assignez explicitement des limites mémoire Docker à chaque conteneur :
--memory=3gpour Typesense et--memory=2gpour Quickwit, en laissant 3 Go au système d’exploitation et au reste de la stack. Sur CX22 (4 Go), une seule instance à la fois est recommandée. - Q : Manticore Search est-il vraiment compatible MySQL ?
- R : Partiellement. Manticore utilise le protocole binaire MySQL (port 9306) et supporte une grande partie du dialecte SQL SELECT, INSERT, UPDATE, DELETE. Cependant, ce n’est pas un remplacement complet de MySQL : il ne supporte pas les JOINs cross-index complexes, les transactions ACID complètes, ni toutes les fonctions MySQL. Pour des requêtes de recherche full-text avec filtres et tri, la compatibilité est suffisante pour utiliser un client MySQL standard (PDO en PHP, pymysql en Python).
- Q : Quelle est la différence entre la version open-source et Typesense Cloud ?
- R : Typesense Cloud est le SaaS managé proposé par l’équipe Typesense. La version open-source (GPL-3.0) disponible sur GitHub est fonctionnellement identique. Typesense Cloud apporte le provisionnement automatique, les sauvegardes managées, la haute disponibilité multi-région sans configuration et le support commercial. Pour une PME qui a les compétences pour gérer un VPS, la version self-hosted est rigoureusement identique en fonctionnalités. La seule exception est la recherche fédérée multi-tenant avancée de Typesense Cloud, qui n’est pas disponible en self-hosted.
- Q : Comment gérer la recherche en wolof avec Typesense ?
- R : Le wolof n’a pas de tokenizer dédié dans Typesense, mais il fonctionne correctement avec le tokenizer par défaut (basé sur les espaces et la ponctuation) car c’est une langue à séparation de mots par espaces. Pour améliorer la pertinence, configurez un dictionnaire de synonymes dans votre collection Typesense pour les variantes orthographiques courantes du wolof (par exemple, les alternances x / kh selon les systèmes de transcription). Ajoutez aussi les stopwords wolof courants (mots fonctionnels à faible valeur sémantique) dans la configuration de la collection via le champ
symbols_to_index. - Q : Est-il possible de faire de la recherche sémantique (vectorielle) avec ces moteurs sans GPU ?
- R : Oui. Typesense, Quickwit et Manticore supportent tous la recherche vectorielle k-NN sur des vecteurs pré-calculés. Le GPU n’est requis que pour générer les vecteurs d’embedding, pas pour la recherche. Workflow recommandé sans GPU : utilisez un service d’embedding externe comme Cohere Embed v3 (API gratuit jusqu’à 100 requêtes/minute) ou un modèle léger comme
all-MiniLM-L6-v2tournant en CPU sur votre VPS via une API locale sentence-transformers. Les vecteurs générés (384 ou 768 dimensions selon le modèle) sont ensuite stockés comme champs vectoriels dans votre collection Typesense. La recherche hybride (texte + vecteur) donne de bien meilleurs résultats que la recherche purement textuelle ou purement sémantique. - Q : Comment migrer depuis Algolia vers Typesense sans interruption de service ?
- R : La migration se fait en 4 phases. Phase 1 (préparation) : installer Typesense sur votre VPS et créer les collections avec le même schéma que vos index Algolia. Phase 2 (double-écriture) : modifier votre application pour écrire simultanément vers Algolia et Typesense pendant 2–4 semaines, le temps de valider les résultats. Phase 3 (dual-read) : implémenter un A/B test qui envoie 10 % du trafic vers Typesense et compare les métriques de pertinence (taux de clics, zéro-résultats). Phase 4 (bascule) : une fois les métriques validées, couper Algolia et router 100 % vers Typesense. L’SDK Typesense propose des méthodes compatibles avec l’API Algolia pour faciliter la migration du code client.
Pour aller plus loin
- Documentation officielle Typesense : typesense.org/docs — guide de démarrage, référence API, recettes pour WooCommerce et autres CMS.
- Documentation officielle Quickwit : quickwit.io/docs — architecture, configuration des index, tutoriels d’ingestion de logs.
- Documentation officielle Manticore Search : manticoresearch.com/docs — référence SQL complète, exemples de configuration, benchmarks.
- Satellite à venir — Déployer Typesense sur VPS Hetzner : tutoriel pas-à-pas couvrant l’installation Ubuntu 22.04, la configuration WooCommerce, l’indexation BookStack et le monitoring Netdata.
- Satellite à venir — Quickwit + MinIO pour la centralisation de logs : tutoriel couvrant l’installation de Quickwit 0.8, la configuration MinIO, l’ingestion via Fluentbit et la visualisation Grafana.
- Formation ITSkillsCenter : rejoignez notre programme de formation Infrastructure Self-Hosted pour développeurs africains qui couvre le déploiement de ces moteurs de recherche avec des projets pratiques adaptés aux contextes PME d’Afrique de l’Ouest. Renseignements sur itskillscenter.io.