Une recherche peut répondre rapidement et être malgré tout incorrecte : afficher un enregistrement supprimé, ignorer une modification récente ou révéler un contenu que l’utilisateur ne peut plus consulter. Le défi ne consiste pas seulement à trouver du texte, mais à maintenir la cohérence des résultats avec les données et les autorisations actuelles, même en cas de retard ou de panne.
Pour concevoir une recherche textuelle PHP fiable, il convient d’abord de décider ce que l’utilisateur doit pouvoir trouver et quel délai est acceptable. Il faut ensuite choisir où exécuter les requêtes et comment maintenir tout index dérivé. La base de données doit rester la source de vérité ; l’index de recherche est une représentation reconstructible, et non un autre endroit où modifier les données.
Commencez par définir les exigences de recherche
Décrivez les requêtes réelles avant de choisir une technologie. Recherche-t-on des mots dans les titres et les descriptions, des expressions, des préfixes ou plusieurs champs ? Existe-t-il des filtres par état, catégorie, date, langue ou propriétaire ? La tolérance aux erreurs, les synonymes, la pertinence ou le tri par date sont-ils importants ?
Définissez également les objectifs opérationnels : latence acceptable, fréquence de mise à jour, volume prévu et comportement lorsque la recherche est indisponible. « À jour » peut signifier qu’une modification apparaît immédiatement ou quelques secondes plus tard. Cette différence a une incidence sur l’architecture et doit être explicite.
Utilisez des requêtes représentatives pour évaluer la qualité. Incluez des termes courants et rares, des enregistrements dont certains champs sont vides, des accents, différentes langues et des utilisateurs ayant des autorisations distinctes. Vérifiez non seulement si le résultat attendu apparaît, mais aussi si le classement et les filtres sont pertinents.
Déterminez si SQL suffit
Une requête SQL peut suffire lorsque le jeu de données et les requêtes restent gérables, que les filtres sont simples et que les capacités de recherche de la base de données répondent au besoin. Le moteur et sa configuration comptent : les fonctions de recherche en texte intégral, la normalisation et la pertinence ne sont pas identiques dans tous les systèmes. Vérifiez leurs limites avec des données et des requêtes réelles.
SQL offre un avantage pratique : les données et la recherche peuvent s’inscrire dans le même modèle de cohérence. De plus, cela évite, au départ, d’exploiter un service supplémentaire et de synchroniser un index séparé. Cela ne signifie pas que toutes les requêtes doivent rechercher des correspondances partielles dans des colonnes sans stratégie ; examinez le plan d’exécution, les index disponibles et le coût des filtres.
Envisagez un index spécialisé lorsque les requêtes nécessitent des capacités que SQL ne gère pas bien, lorsque la latence ou la charge de recherche interfère avec les opérations principales, ou lorsque la pertinence, les facettes et l’analyse de texte doivent évoluer indépendamment. C’est un choix d’architecture, et non une obligation simplement parce que l’application est un SaaS ou contient de nombreux enregistrements.
Conservez une source de vérité et définissez l’index
La base de données transactionnelle devrait faire autorité pour les créations, les modifications, les suppressions et les autorisations. Documentez les entités et les champs indexés, leur mode de transformation et l’identifiant qui permet de retrouver l’enregistrement d’origine. L’index peut contenir du texte normalisé et des champs destinés aux filtres, mais il ne doit pas devenir une copie modifiable sans processus de réconciliation clairement défini.
Les autorisations exigent une attention particulière. Décidez si l’index stocke des champs d’autorisation ou si l’application valide chaque résultat par rapport à la source de vérité. Quelle que soit l’approche retenue, une recherche ne doit pas accorder l’accès au seul motif qu’un document figure encore dans l’index. Appliquez les filtres d’accès côté serveur et considérez les changements de propriétaire, de visibilité ou de rôle comme des changements à propager également.
Si une sécurité maximale face aux retards de mise à jour des autorisations est nécessaire, vérifiez de nouveau les autorisations lors de la récupération des résultats, même si cela implique d’en écarter certains. La stratégie doit aussi prévoir ce qui se passe si cette vérification échoue : il est préférable de ne pas renvoyer des résultats non vérifiés en solution de repli.
Propagez les changements de manière récupérable
Mettre à jour la base de données puis envoyer un message à une file d’attente au cours de deux opérations indépendantes crée un risque de perte : la première peut être validée et la seconde échouer. Un modèle courant pour éviter ce problème est la file de sortie transactionnelle, ou boîte d'envoi : la transaction enregistre la modification métier et un événement en attente dans la même base de données. Un processus distinct publie ou traite ces événements et enregistre la progression.
Le consommateur met l’index à jour de manière asynchrone. Cela introduit une période pendant laquelle les données sont obsolètes, dont la durée cible doit être explicitement définie et mesurée. Si le cas d’usage exige une lecture immédiate après une écriture, prévoyez une stratégie adaptée, par exemple renvoyer l’enregistrement qui vient d’être enregistré dans la réponse ou interroger temporairement la source de vérité. Ne promettez pas une cohérence immédiate si le flux est asynchrone.
Concevez le traitement pour qu’il soit idempotent : recevoir deux fois le même événement ne doit ni dupliquer des documents ni rétablir des données antérieures. Incluez un identifiant stable de l’enregistrement et, le cas échéant, une version ou une séquence de modification. Si les événements peuvent arriver dans le désordre, empêchez une ancienne version d’écraser une nouvelle. Les nouvelles tentatives doivent être sûres et les messages impossibles à traiter doivent rester visibles pour être examinés, au lieu de disparaître silencieusement.
Traitez les suppressions et les reconstructions comme des cas normaux
Une suppression doit être propagée explicitement. Si le système efface physiquement l’enregistrement avant qu’un worker puisse le consulter, l’événement doit inclure l’identité nécessaire pour supprimer son document. Dans les flux sujets aux retards ou aux nouvelles tentatives, un marqueur de suppression — un tombstone — ou une version de suppression peut empêcher un ancien événement de recréer le résultat.
En cas de changement de schéma ou d’index endommagé, reconstruisez l’index à partir de la source de vérité, par lots de taille limitée. Enregistrez le point de progression, contrôlez les erreurs et limitez la charge sur la base de données. Pendant le remplissage d’un nouvel index, continuez à propager les changements qui surviennent au cours du processus ; sinon, l’index risque d’être obsolète avant même son activation.
Une fois le nouvel index complet et validé, basculez les lectures de façon contrôlée, par exemple au moyen d’une configuration ou d’un alias compatible avec la technologie choisie. Conservez une possibilité de retour en arrière pendant la vérification du résultat. L’activation progressive est une décision opérationnelle ; elle ne revient pas à divulguer sans contrôle des changements de produit aux utilisateurs.
Mesurez la cohérence et préparez l’exploitation
Surveillez le délai entre la validation d’une modification et sa disponibilité dans la recherche, ainsi que les événements en attente, les erreurs, les nouvelles tentatives et les échecs définitifs. Une file qui semble active peut dissimuler un événement bloqué. Définissez des alertes dont les seuils correspondent à l’objectif de fraîcheur des données et une procédure pour relancer le traitement ou réparer des documents.
Planifiez une réconciliation : comparez un échantillon, ou des ensembles complets lorsque c’est possible, entre les enregistrements qui devraient être indexés et les documents présents. Cela permet de détecter les messages perdus, les transformations défectueuses et les suppressions qui n’ont pas été propagées. Toute divergence doit entraîner une action documentée, comme réindexer un enregistrement ou reconstruire l’index.
Liste de contrôle avant la mise en production
- Les requêtes et les critères de pertinence ont-ils été validés sur des cas représentatifs ?
- La source de vérité, les champs indexés et leur transformation sont-ils documentés ?
- Les modifications et les suppressions atteignent-elles l’index même après une panne partielle ?
- Le traitement tolère-t-il les messages répétés et reçus dans le désordre ?
- Les autorisations sont-elles appliquées lors de la recherche et mises à jour lorsqu’elles changent ?
- Le délai est-il mesuré et existe-t-il une procédure de réconciliation et de reconstruction ?
- Un plan permet-il de valider le nouvel index et de revenir en arrière si les résultats se dégradent ?
La fiabilité d’une recherche textuelle PHP dépend moins du choix d’une technologie à la mode que de la définition de la cohérence, des autorisations et de la récupération. Commencez par la solution la plus simple qui répond aux exigences mesurées. Si SQL ne couvre plus les requêtes ou les performances nécessaires, adoptez un index spécialisé avec une synchronisation explicite, observable et reconstructible.
