Réponse courte. La recherche d'une application n'est pas un champ qui cherche le mot exact dans le nom du produit : c'est un index construit à partir de plusieurs champs par produit, nom en français, nom en arabe, synonymes et variantes en lettres latines, référence, marque, conditionnement ; une normalisation qui unifie les formes de l'arabe, retire les accents et sépare les unités des nombres ; des synonymes écrits à la main avec le gérant, parce qu'aucun moteur ne sait que « zit » est de l'huile ni que « smid » est de la semoule ; une tolérance aux fautes réglée, une faute dès cinq lettres, deux dès neuf ; un classement où les règles de texte viennent d'abord, mots trouvés, fautes, proximité, puis les règles métier, disponibilité, prix pour ce client, produits déjà commandés, jamais comme filtres silencieux ; un jeu de deux cents requêtes réelles rejoué à chaque changement ; et un journal des zéro résultat qui est la source des synonymes suivants. Six semaines, dont la première sans toucher au moteur.
Ce guide s'adresse au fondateur installé en France dont le portail ou la marketplace affiche « aucun résultat » à des clients qui tapent en darija, au grossiste en Algérie dont les détaillants appellent le commercial parce qu'ils ne trouvent pas le produit dans l'application, et à celui qui compare des devis où « recherche » tient en un mot. Il ne traite pas de la recherche dans les documents par IA, décrite dans le guide sur l'IA dans l'application, mais s'y relie à la fin ; il décrit ce qui se construit entre la frappe du client et la liste des résultats.
Ce que les chiffres disent
La tolérance aux fautes est réglable, pas magique. La documentation de Meilisearch, moteur de recherche ouvert que nous utilisons souvent, dit que la tolérance aux fautes est activée par défaut, qu'une faute est acceptée à partir de cinq caractères et deux à partir de neuf, et qu'une faute sur la première lettre compte double ; ses règles de classement par défaut s'appliquent dans l'ordre mots, fautes, proximité, attribut, tri, exactitude, et des règles personnalisées, un champ numérique trié, se placent à la fin. Pour l'arabe, la même documentation annonce la segmentation de l'article « ال » et une normalisation par décomposition, conversion des chiffres et retrait des marques non espacées ; elle ne dit rien des formes de l'alef, que nous unifions nous-mêmes avant l'indexation. Ce que cela impose : « huille » retrouve « huile », « الزيت » retrouve « زيت », mais « zit » ne retrouve rien sans un synonyme écrit par quelqu'un.
La base de données sait déjà beaucoup. PostgreSQL, que la plupart de nos applications utilisent, fournit une recherche plein texte avec des dictionnaires en chaîne, dont un dictionnaire filtrant qui retire les accents et des radicalisateurs Snowball qui, selon la documentation, « reconnaissent tout » et se placent donc en fin de chaîne ; la page ne liste pas les langues, et nous ne comptons pas sur un radicalisateur pour l'arabe dialectal. Son extension de trigrammes mesure la similarité de deux chaînes avec un seuil par défaut de 0,3, ignore les caractères non alphanumériques, et ses index accélèrent les recherches `LIKE` et `ILIKE` ; c'est ce qui suffit pour un back-office de quelques milliers de références. Ce que cela impose : la première question n'est pas « quel moteur » mais « quelle taille, quel usage, et qui va l'exploiter ».
Ce qui n'existe nulle part : un dictionnaire de la darija en lettres latines. « zit », « zite », « zeit », « smid », « sokar », « 7lib » pour le lait avec le chiffre pour la lettre : chaque entreprise a le sien, et il se construit à partir de ce que ses clients tapent vraiment. C'est pourquoi le chiffre à lire n'est pas le nombre de recherches mais la part de zéro résultat, requête par requête, avec le client et l'heure, et pourquoi la première semaine du projet se passe avec les commerciaux et le téléphone du gérant plutôt qu'avec un moteur. Ce que nous n'avons pas trouvé : une mesure publique de l'usage de la darija latine dans les recherches en Algérie ; ce que nous voyons au pilote est que c'est la première cause de zéro résultat sur un catalogue alimentaire, et nous le disons comme une observation, pas une statistique.
Une recherche « zit 5l », de la frappe au résultat
Une recherche ne se décrit pas par son moteur mais par ce qui arrive à ce que le client tape, lettre par lettre, jusqu'au résultat et au journal.
La frappe : le détaillant écrit « zit 5l », en darija, en lettres latines, sans accent, sans espace avant l'unité, et la recherche se lance à chaque lettre. La normalisation met en minuscules, sépare « 5l » en « 5 l », et consulte les synonymes : « zit » devient aussi « huile » ; une faute aurait été tolérée à partir de cinq lettres. La correspondance se fait sur le document produit, qui n'est pas une ligne de base de données mais un ensemble de champs indexés : le nom en français retrouve « huile » et « 5 l », le nom en arabe aurait retrouvé « زيت » sans l'article, et le champ synonymes, écrit à la main la première semaine, retrouve « zit » lui-même.
Le résultat affiche le nom dans les deux langues, la disponibilité et le prix pour ce client, parce que deux détaillants ne voient pas le même catalogue au même prix, comme le guide sur le portail B2B le décrit. Le journal écrit la requête, le nombre de résultats, le temps de réponse, puis le clic ; et chaque semaine, la part de zéro résultat et la liste des termes qui n'ont rien donné, qui est la source des synonymes suivants. Une recherche qui ne journalise pas ne s'améliore jamais : elle échoue de la même façon pour le même mot pendant des mois.
Construire l'index, en six étapes
Derrière le résultat, six étapes, et la troisième est celle qu'aucun moteur ne fait à votre place.
Les champs : pour chaque produit, le nom en français, le nom en arabe, les synonymes et variantes en lettres latines, la référence, le code-barres, la marque, la catégorie, l'unité et le conditionnement ; un document par produit, avec un poids par champ, la référence pesant plus que la description. La normalisation : minuscules, accents retirés, formes de l'alef et taa marbuta unifiées, chiffres arabes et latins alignés, unités séparées des nombres ; appliquée à l'index et à la requête, de la même façon. Les synonymes : écrits à la main avec le gérant et les commerciaux, deux cents lignes la première semaine, darija latine vers le nom en français, abréviations, anciennes références, marques prononcées autrement ; stockés dans votre base, versionnés, et vérifiés sur le jeu de requêtes.
L'index : un moteur dédié pour un catalogue consulté depuis le téléphone, ou l'index plein texte et trigrammes de la base pour un back-office ; un document par produit, rafraîchi à chaque modification de prix ou de stock, parce qu'un résultat qui montre un prix d'hier fait perdre une commande. Les règles métier : disponibilité, prix pour ce client, produits déjà commandés, produits de la tournée, nouveautés, placées après les règles de texte comme règles de classement, jamais comme filtres qui font disparaître un produit. Le jeu de requêtes : deux cents requêtes réelles avec le bon produit attendu, rejouées à chaque changement de synonymes, de normalisation ou de règles, avec une note ; la livraison est refusée si la note baisse, sur le même principe que les tests décrits dans le guide sur la livraison.
«Aucun moteur ne sait que « zit » est de l'huile ; c'est un synonyme que quelqu'un écrit, et le journal des zéro résultat dit lesquels manquent.»
Pourquoi le résultat 1 est en premier
Le classement est ce que le client voit sans le savoir : la même requête, les mêmes produits, et un ordre qui décide s'il commande ou s'il appelle le commercial.
Les règles de texte d'abord : le produit qui contient tous les mots de la requête passe devant celui qui n'en contient qu'un ; sans faute devant avec faute ; les mots proches l'un de l'autre devant les mots éloignés. C'est l'ordre par défaut des moteurs courants, et il ne se discute pas. Les règles métier ensuite : en stock devant en rupture, mais la rupture reste visible, parce qu'un produit qui disparaît fait croire au détaillant qu'il n'existe plus ; le prix pour ce client, parce qu'un produit à son tarif négocié mérite de monter ; les produits qu'il a déjà commandés, parce qu'il cherche souvent la même chose. Ces règles s'écrivent avec le gérant la quatrième semaine, et elles changent par métier : une pharmacie classe par date de péremption, un distributeur par tournée.
Ce qui ne doit jamais classer : la marge, sauf si le gérant le demande par écrit et l'assume ; et aucune règle ne doit faire passer devant un produit qui ne contient pas les mots de la requête. Les parts de la figure sont illustratives ; ce qui ne l'est pas, c'est que chaque règle a un poids écrit, que le jeu de requêtes mesure l'effet de chaque changement de poids, et que le détaillant qui tape une référence exacte ou un code-barres obtient ce produit seul, en premier, avant toute recherche de texte.
Six requêtes réelles, et ce que le moteur doit faire
Six requêtes que nous relevons sur les journaux de recherche des applications que nous construisons, et ce que le moteur doit faire pour chacune.
La darija en lettres latines est la première cause de zéro résultat sur un catalogue alimentaire : « zit », « smid », « sokar », avec leurs variantes ; seuls des synonymes écrits à la main la retrouvent, et la liste vit avec le journal. L'arabe avec ou sans article, avec ou sans points et voyelles : article retiré, formes unifiées, marques ignorées, et le même résultat dans les deux écritures ; c'est la normalisation de la deuxième étape. La faute de frappe : une faute tolérée dès cinq lettres, deux dès neuf, la première lettre comptant double, et le résultat exact toujours premier ; les mots courts, « lait », « thé », n'ont pas de tolérance et sont couverts par les synonymes.
La référence ou le code-barres : correspondance exacte avant toute recherche de texte, un seul résultat, en premier ; c'est la requête du prévendeur qui scanne, décrite dans le guide sur l'application de terrain. Le mot générique : « huile » donne des dizaines de résultats, et c'est le classement qui travaille, disponibilité, déjà commandés, prix, avec des facettes marque et conditionnement pour affiner. Rien ne correspond : zéro résultat journalisé avec le client et l'heure, produits proches suggérés plutôt qu'une page vide, et la liste relue chaque semaine ; c'est la ligne qui améliore toutes les autres.
Quatre façons de construire la recherche
Quatre approches, et le choix dépend de la taille du catalogue, de l'usage et de qui exploitera le service, pas de la mode.
L'index de la base, plein texte et trigrammes, suffit jusqu'à quelques dizaines de milliers de produits pour un back-office ou une recherche interne : accents retirés par un dictionnaire filtrant, fautes par similarité de trigrammes avec un seuil réglable, synonymes par table ; rien de plus à héberger ni à surveiller, mais pas de découpage de l'article arabe ni de recherche à la frappe sur un gros catalogue. Le moteur dédié ouvert, auto-hébergé, est notre choix habituel pour un catalogue client, un portail B2B ou une marketplace : fautes tolérées par défaut, règles de classement ordonnées, arabe segmenté, synonymes natifs, recherche à la frappe en quelques dizaines de millisecondes sur un index de cette taille, à mesurer ; c'est un service de plus à héberger, sauvegarder et mettre à jour, selon le guide sur l'hébergement.
Le même moteur en service géré évite de l'exploiter soi-même, au prix d'un abonnement en devise à payer depuis l'Algérie, décrit dans le guide sur le paiement du cloud, et de données de catalogue hébergées chez l'éditeur, à décider par contrat. La recherche sémantique par vecteurs comprend « huile pour friture » sans synonyme et répond à des questions en langage naturel sur des documents ; elle ne garantit pas la référence exacte et se combine au classement texte plutôt que de le remplacer ; c'est la fonction décrite dans le guide sur l'IA dans l'application, et elle a son coût par document et par requête. Aucune des quatre ne connaît « zit » : les synonymes restent à écrire, quel que soit le moteur.
«Un produit en rupture descend dans la liste ; il ne disparaît pas, sinon le détaillant croit qu'il n'existe plus.»
Vu ailleurs : Meilisearch, PostgreSQL, et ce qui se transpose
Deux sources disent l'essentiel. La documentation de Meilisearch dit que la tolérance aux fautes est activée par défaut avec des seuils de cinq et neuf lettres, que les règles de classement s'appliquent dans un ordre écrit, et que l'arabe est segmenté et normalisé ; ce qui se transpose, c'est que les fautes et l'arabe standard sont réglés par configuration, et que tout le reste, la darija latine, les unités, les règles métier, est à construire. La documentation de PostgreSQL dit qu'un dictionnaire filtrant retire les accents, que les radicalisateurs se placent en fin de chaîne, et que les trigrammes mesurent une similarité avec un seuil de 0,3 ; ce qui se transpose, c'est qu'un back-office n'a pas besoin d'un moteur de plus.
Ce que ces sources ne disent pas : quels mots vos clients tapent, quelle part de zéro résultat vous avez aujourd'hui, et quelles règles métier votre gérant veut voir classer ; la première semaine du projet y répond, avec le journal de l'application existante quand il y en a un, et avec les commerciaux quand il n'y en a pas.
Les règles d'une recherche qui retrouve
Six règles, écrites la première semaine et relues à chaque ajout de synonymes. Les requêtes réelles avant le moteur : ce que les clients tapent, collecté auprès des commerciaux et dans le journal, décide des champs, des synonymes et du jeu de requêtes. La même normalisation à l'index et à la requête, arabe et latin. Les synonymes sont à vous, dans votre base, versionnés, pas dans la console d'un éditeur. Les règles métier classent, elles ne filtrent pas : un produit en rupture descend, il ne disparaît pas. La référence exacte gagne toujours. Le zéro résultat est le chiffre lu chaque semaine, avec la liste des termes, et chaque terme ajouté aux synonymes est rejoué sur le jeu de requêtes.
Une septième règle porte sur le devis : « recherche » n'est pas une exigence, c'est une phrase ; l'exigence s'écrit « index sur les champs nom français, nom arabe, synonymes, référence, code-barres ; normalisation arabe et latine ; deux cents synonymes écrits avec le gérant ; une faute tolérée dès cinq lettres ; classement texte puis disponibilité, prix client, déjà commandés ; jeu de deux cents requêtes avec note mesurée à la recette ; journal des zéro résultat ; recherche à la frappe sous cinquante millisecondes mesurée », et elle se vérifie comme le guide sur le cahier des charges le recommande. Un devis qui chiffre « un champ de recherche » a chiffré un `LIKE`.
Six applications, et ce que leur recherche doit retrouver
Six applications que nous construisons souvent, et pour chacune ce que la recherche doit retrouver en premier, décidé la première semaine.
- Le portail de commande B2B, décrit dans le guide dédié. Darija latine et arabe vers le catalogue, prix pour ce client dans le classement, code-barres exact ; zéro résultat lu chaque semaine avec les commerciaux.
- La marketplace, décrite dans le guide dédié. Des milliers de vendeurs, des noms de produits écrits de mille façons ; normalisation forte, synonymes par catégorie, facettes, et disponibilité par vendeur dans le classement.
- L'application de terrain des prévendeurs, décrite dans le guide dédié. Scan du code-barres avant tout, puis recherche hors ligne sur l'index local décrit dans le guide sur le mode hors ligne ; les produits de la tournée en premier.
- Le grossiste pharmaceutique, décrit dans le guide sur la chaîne du froid. Dénomination commune et nom commercial comme synonymes l'un de l'autre, dosage et forme comme champs, date de péremption dans le classement.
- L'espace propriétaire d'un appartement, décrit dans le guide dédié. Recherche dans les quittances, états des lieux et travaux par date, locataire et montant ; l'index de la base suffit.
- Le tableau de bord du gérant, décrit dans le guide dédié. Recherche d'un client, d'une commande ou d'une facture par numéro, nom ou téléphone, avec fautes ; trigrammes de la base, pas de moteur de plus.
Le calendrier 2027
Le calendrier est celui d'une recherche complète en six semaines, dont la première sans toucher au moteur et une de recette avec de vrais détaillants.
La semaine 0 à 1 collecte les requêtes réelles et écrit les synonymes : les mots que les clients tapent vraiment, relevés auprès des commerciaux, dans le téléphone du gérant et dans le journal de l'application existante s'il y en a un ; deux cents synonymes écrits et signés. La semaine 1 à 2 fixe les champs et la normalisation, arabe et latine, les unités, et le jeu de deux cents requêtes avec le bon produit attendu. La semaine 2 à 3 installe le moteur ou l'index de la base, charge les documents, branche la réindexation à chaque modification, et mesure la recherche à la frappe. La semaine 3 à 4 écrit les règles métier et les facettes avec le gérant, chaque poids mesuré sur le jeu de requêtes.
La semaine 4 à 5 est la recette : la note sur le jeu de requêtes, le zéro résultat compté, et dix détaillants réels qui cherchent devant nous, parce que l'équipe tape toujours le bon nom. La semaine 5 à 6 est le pilote : journal lu chaque semaine, synonymes ajoutés, note rejouée, et la part de zéro résultat qui baisse de semaine en semaine est le chiffre qui dit que la recherche vit. Chaque lot est démontré et recetté comme le guide sur la livraison le décrit.
Ce qui fait échouer la recherche
Les recherches que nous reprenons ont presque toujours échoué pour l'une de ces raisons.
- Le champ `LIKE`. Exact, lent sur un gros catalogue, et muet : personne ne sait ce que les clients ont tapé sans résultat.
- Pas de synonymes. Le moteur tolère les fautes, mais « zit » n'est pas une faute ; c'est un mot que personne n'a écrit.
- L'arabe non normalisé. « الزيت » et « زيت » sont deux mots différents ; le client tape l'un et le produit porte l'autre.
- La rupture filtrée. Le produit disparaît ; le détaillant croit qu'il n'existe plus et commande ailleurs.
- La recette sur les noms exacts. L'équipe cherche « Huile de tournesol 5 L » et tout marche ; le détaillant cherche « zit » et rien ne marche.
- L'index qui retarde. Le prix a changé ce matin ; la recherche montre celui d'hier.
- Pas de journal. La recherche échoue de la même façon pour le même mot pendant des mois, et personne ne le sait.
Questions fréquentes
Les questions que nous recevons de fondateurs installés en France, de gérants en Algérie et d'équipes qui comparent des devis.
- Pourquoi mes clients ne trouvent-ils pas le produit alors qu’il existe ?
- Parce qu'ils ne tapent pas le nom que porte le produit : « zit » pour huile, « الزيت » avec l'article, « huille » avec une faute, ou l'unité collée au nombre. Un champ qui cherche le mot exact ne retrouve rien ; un index avec normalisation, synonymes écrits à la main et tolérance aux fautes retrouve les trois premiers, et le journal des zéro résultat dit lesquels manquent encore.
- La recherche comprend-elle la darija en lettres latines ?
- Aucun moteur ne la connaît : « zit », « smid », « sokar » et leurs variantes sont des synonymes écrits à la main avec le gérant et les commerciaux la première semaine, deux cents lignes pour un catalogue alimentaire, puis complétés chaque semaine à partir des requêtes sans résultat. Les synonymes sont stockés dans votre base, pas chez un éditeur.
- Et l’arabe avec ou sans article, avec ou sans voyelles ?
- La normalisation s'en charge : article « ال » retiré, formes de l'alef et taa marbuta unifiées, marques de voyelles ignorées, chiffres arabes et latins alignés, appliquée de la même façon à l'index et à la requête. Un moteur dédié fait une partie de ce travail par défaut ; le reste, nous l'ajoutons avant l'indexation, et le jeu de requêtes le vérifie.
- Combien de fautes la recherche tolère-t-elle ?
- Une faute à partir de cinq lettres, deux à partir de neuf, une faute sur la première lettre comptant double : ce sont les réglages par défaut d'un moteur courant, et ils se changent. Les mots courts, « lait », « thé », n'ont pas de tolérance et sont couverts par les synonymes ; et le résultat exact reste toujours premier.
- Faut-il un moteur de recherche en plus de la base de données ?
- Pas toujours. Pour un back-office ou une recherche interne jusqu'à quelques dizaines de milliers de références, l'index plein texte et trigrammes de la base suffit, sans service de plus. Pour un catalogue consulté depuis le téléphone, un portail B2B ou une marketplace, un moteur dédié ouvert, auto-hébergé, apporte la recherche à la frappe, les fautes, l'arabe segmenté et les règles de classement ; c'est un service de plus à héberger, et il est à vous.
- Combien de temps pour construire la recherche ?
- Six semaines pour une recherche complète : une pour les requêtes réelles et les synonymes sans toucher au moteur, une pour les champs, la normalisation et le jeu de requêtes, une pour l'index, une pour les règles métier, une de recette avec dix détaillants réels, une de pilote avec le journal. Chaque lot est démontré et recetté sur le jeu de requêtes.