Construire son moteur de recherche ou en acheter un : comment trancher

La question posée est rarement la bonne

« Combien ça coûterait de le faire nous-mêmes ? » appelle presque toujours la même réponse : Elasticsearch est gratuit, un développeur en interne coûte ce qu'il coûte déjà, et le reste semble être une question de temps. Sur le papier, construire paraît moins cher qu'acheter.

La bonne question n'est pas « combien ça coûte de construire la version 1 », c'est « combien ça coûte de la maintenir en version 40, dans deux ans, quand la personne qui l'a écrite est partie ». C'est là que l'arbitrage bascule presque toujours.

Ce que « construire » veut dire, concrètement

Un moteur de recherche pour catalogue technique, ce n'est pas installer Elasticsearch et lancer une requête match. C'est, au minimum :

La tokenisation qui distingue une référence d'un mot du langage courant — sans quoi « M8x20 » se fait découper comme trois mots sans rapport. La tolérance aux fautes calibrée par type de token — une faute sur une référence chiffrée ne doit pas se comporter comme une faute sur un nom de produit. La gestion des synonymes et des règles métier par secteur. Le classement qui priorise le stock sans écraser la pertinence. Et, dès qu'un deuxième client ou une deuxième langue de références s'ajoute, la maintenance de tout ça dans le temps.

Rien de tout ça n'est exotique. Mais chaque brique, prise séparément, prend une à trois semaines à un développeur compétent — et elles interagissent entre elles, ce qui veut dire que la troisième brique casse parfois la première.

Le vrai coût de « construire », ce n'est pas la première version. C'est le développeur qui doit se souvenir six mois plus tard pourquoi telle regex existe, pendant qu'il devrait travailler sur autre chose que la recherche.

Ce que « acheter » évite, précisément

Un moteur de recherche spécialisé n'achète pas une fonctionnalité, il achète un problème déjà résolu par quelqu'un dont c'est le métier à plein temps — pas une tâche annexe sur la liste d'un développeur produit. La différence se voit sur trois points : les cas limites déjà rencontrés (le × typographique copié depuis un PDF, la virgule décimale d'un « 2,5 mm² », les multiples façons d'écrire une même référence), la maintenance qui suit les montées de version sans mobiliser votre équipe, et le temps de mise en route — quelques jours plutôt que plusieurs mois avant le premier résultat exploitable.

Quand construire soi-même se justifie réellement

Ce n'est pas toujours le mauvais choix. Construire a du sens quand la recherche EST le produit — un moteur de recherche généraliste, pas un moteur au service d'un catalogue. Quand le volume justifie une équipe dédiée à plein temps, pas une tâche à côté. Ou quand la structure des références est tellement spécifique qu'aucune solution du marché, généraliste ou spécialisée, ne peut la couvrir sans réécriture complète.

En dehors de ces trois cas, la question à se poser est simple : est-ce que la recherche est ce qui différencie votre entreprise aux yeux de vos clients, ou est-ce un moyen d'accéder à ce qui différencie réellement votre entreprise — votre catalogue, votre expertise produit, votre relation client ? Si c'est la seconde réponse, chaque semaine passée sur le moteur est une semaine qui ne va pas sur ce qui compte.

Où se situe Heurix sur cet arbitrage

Heurix ne prétend pas remplacer un moteur généraliste sur son terrain — un catalogue de mode ou de contenu éditorial s'en sort très bien avec Algolia ou Meilisearch. Sa place est plus étroite : les catalogues où la référence elle-même porte l'information technique, et où cette information change selon le secteur.

Concrètement, ça veut dire des règles métier déjà écrites par secteur — outillage, industrie, électronique, mode, librairie, vins — plutôt qu'à écrire une par une. Un classement qui combine pertinence et disponibilité en stock sans configuration additionnelle. Et un principe simple qui traverse tout le produit : le marchand garde la main sur ses règles, rien n'est décidé à sa place de façon opaque.

Le résultat concret : un catalogue déjà exporté peut être testé en une après-midi, et une mise en production sur PrestaShop ou WooCommerce prend de deux à quatre jours — pas plusieurs mois de développement interne pour arriver au même point.

Comment trancher, sans idéologie

Trois questions suffisent généralement. Un développeur va-t-il passer plus de temps sur la recherche que sur ce qui différencie réellement votre entreprise ? Si la personne qui construit le moteur partait demain, quelqu'un d'autre pourrait-il reprendre le code en une journée ? Et le catalogue a-t-il une structure de référence assez particulière pour justifier une solution sur mesure plutôt qu'un outil déjà pensé pour ce cas ?

Si les réponses penchent vers « non », le calcul le plus honnête n'est pas construire contre acheter — c'est le temps de votre équipe technique investi ailleurs, contre un abonnement qui commence à 19 €/mois.