Ajouter comme source préférée sur Google
Imaginez que votre agence gère le centre d’aide WordPress d’une entreprise spécialisée dans les logiciels de prise de rendez-vous. Les clients ne cessent de demander au service de support comment reporter des rendez-vous récurrents. Les instructions existent déjà, mais une recherche sur « déplacer mes rendez-vous du vendredi » ne mène pas au guide correspondant.
Le client souhaite tester la recherche par IA. Au lieu de compter sur les clients pour saisir les mots exacts d’un article, ce système pourrait associer leur question à un guide ayant une signification similaire. La première version renverrait des liens vers la documentation existante.
Le choix d’un prestataire soulève une question plus épineuse. Le service que vous recommandez aujourd’hui conviendra-t-il encore au site l’année prochaine ? Vous ne pouvez pas le garantir, et le client ne devrait pas avoir besoin de cette garantie avant que vous ne commenciez.
Vous pouvez conserver les guides d’origine dans WordPress et mettre en place l’intégration de manière à ce que le remplacement du service de recherche n’implique pas de refaire entièrement le centre d’aide.
Cet article retrace ce projet, depuis un essai limité jusqu’à une utilisation à plus grande échelle. Il explique quelles parties de la configuration doivent rester sous votre contrôle et comment l’hébergement peut donner à votre équipe la marge de manœuvre nécessaire pour s’adapter, quels que soient l’outil d’IA, les tendances ou l’intégration que vous choisirez.
Vous ne pouvez pas attendre d’avoir des certitudes
Voici un scénario possible. Votre développeur commence à comparer des services au moment même où un autre fournisseur annonce un nouveau produit de recherche. Le client vous transmet l’annonce : « Devrions-nous attendre celui-ci ? »
Pendant ce temps, le service de support continue d’envoyer le lien vers le même article.
Avant tout achat, votre agence peut chercher à comprendre pourquoi la recherche actuelle ne trouve pas le guide. Il est possible que le centre d’aide stocke les articles dans un type de publication personnalisé que la configuration actuelle de la recherche ne prend pas en compte. Ou bien l’article désigne les rendez-vous récurrents sous le terme « gestion des séries », une expression que les clients utilisent rarement.
Ces problèmes nécessitent bien sûr des solutions différentes. Les développeurs peuvent vérifier si la recherche WordPress inclut les articles du centre d’aide, et un rédacteur peut ajouter les termes utilisés par les clients et préciser quelles instructions s’appliquent à la version actuelle du logiciel.
Les tickets de support récents vous fournissent de véritables questions à tester. L’équipe d’assistance sait déjà quel guide répond à chaque question, ce qui est utile. Tester ces questions sur le site permet de mettre en évidence les lacunes de la recherche, sans avoir à deviner ce que les clients pourraient saisir.
La recherche sémantique constitue un autre moyen d’améliorer ce système. Elle utilise l’apprentissage automatique pour trouver du contenu dont la signification est similaire à celle de la requête, même lorsque la formulation diffère. Cela permet de relier des expressions telles que « déplacer mes réservations du vendredi » à d’autres expressions comme « reprogrammer des rendez-vous récurrents ».
La documentation sous-jacente reste toutefois essentielle. Si deux guides décrivent des versions différentes du logiciel de réservation, le service de recherche doit disposer d’informations suffisantes pour les distinguer.
Votre agence peut résoudre ces problèmes de contenu tant que la décision d’achat n’est pas prise. Lorsque vous testez la recherche par IA, vous disposez d’une bibliothèque mieux organisée et d’un ensemble de questions à comparer.
WordPress reste la source du contenu
La résiliation de l’abonnement à la recherche ne devrait supprimer aucun guide du site WordPress du client. Les rédacteurs continuent de travailler dans WordPress. Le fournisseur de recherche conserve une copie indexée du contenu que l’intégration lui transmet.
Cette distinction est importante lorsque vous envisagez un remplacement. Votre agence doit reconstituer l’index de recherche à partir des articles originaux, sans dépendre du fournisseur sortant pour récupérer la seule copie disponible.
Pour ce centre d’aide, les types de publications personnalisés permettent de distinguer les guides des articles de blog. Un champ personnalisé ou une taxonomie peut identifier la version du logiciel de réservation couverte par chaque guide. Ces informations font partie intégrante de l’article dans WordPress, où les rédacteurs peuvent les mettre à jour.
Le code d’indexation envoie le texte et les métadonnées pertinents au service de recherche. Il conserve également une référence à l’identifiant de l’article WordPress afin qu’un résultat de recherche renvoie vers le guide approprié.
Les exportations du fournisseur méritent toujours une attention particulière. Votre équipe peut configurer des synonymes ou des règles de classement dans le tableau de bord du service. Ces réglages devront peut-être être exportés ou documentés séparément avant la clôture du compte. Ils ne doivent pas constituer le seul endroit où vous consignez quels guides couvrent la version actuelle du logiciel.
Les modifications doivent également être répercutées dans l’index. Lorsqu’un éditeur remplace des instructions obsolètes, l’intégration doit mettre à jour ou supprimer le contenu indexé correspondant. Si cette étape n’est pas effectuée, la recherche continuera à renvoyer une réponse qui ne figure plus dans la bibliothèque de ressources.
Les guides publics facilitent la première prise en main. Si le client ajoute ultérieurement de la documentation réservée aux membres, l’intégration devra appliquer les règles d’accès du site avant d’afficher des résultats restreints ou d’envoyer des extraits à un modèle de génération de réponses. Le simple fait de savoir qu’une personne se connecte ne permet pas de déterminer quels articles son adhésion lui autorise à lire.
Comment faciliter la gestion des changements de fournisseur
Le champ de recherche peut rester dans le thème WordPress tandis qu’une extension gère l’API du fournisseur. Le thème transmet la requête à l’extension, qui envoie la requête et convertit la réponse au format attendu par le site.
Par exemple, l’extension peut associer les identifiants de documents du fournisseur aux identifiants d’articles WordPress. Le thème affiche alors les guides correspondants en utilisant leurs titres WordPress et leurs permaliens. L’ajout d’un nouveau fournisseur nécessite un travail d’intégration, tandis que la mise en page du centre d’aide peut rester pratiquement inchangée.
La « recherche par IA » nécessite également une définition plus précise avant que vous ne puissiez estimer ce travail.
Dans un système basé sur les intégrations, un modèle convertit le texte d’un article en représentations numériques appelées « embeddings ». Un index de recherche stocke ces représentations. Le système convertit la requête d’un visiteur en une représentation compatible et recherche le contenu pertinent.
Un grand modèle linguistique peut ensuite utiliser les extraits récupérés pour générer une réponse, si la fonctionnalité inclut cette étape. Le renvoi de liens vers des articles pertinents ne nécessite pas de réponse générée.
Votre agence pourrait acquérir l’ensemble de ces fonctionnalités auprès d’un fournisseur de recherche gérée. Une autre implémentation pourrait recourir à des services distincts. Dans tous les cas, le développeur doit savoir quelle partie est concernée par la modification proposée.
Il est souvent possible de remplacer le modèle qui rédige les réponses tout en conservant l’index de recherche existant. Changer de modèle d’encodage implique généralement de régénérer les encodages des documents et de reconstruire l’index. Les scores de pertinence peuvent également varier d’un fournisseur à l’autre ; votre développeur doit donc vérifier si le seuil existant permet toujours de sélectionner des résultats utiles.
Il convient de noter les données récentes compilées dans l’enquête 2025 d’Andreessen Horowitz menée auprès de 100 DSI d’entreprises. Cette enquête indique que 37 % des DSI utilisent au moins cinq modèles, contre 29 % lors de l’enquête précédente. Pour ce client hypothétique, un seul service pourrait suffire, mais la préoccupation pratique consiste à comprendre ce qu’impliquerait un remplacement ultérieur.
Une petite extension peut assurer cette séparation sans transformer le projet en un framework compatible avec tous les fournisseurs imaginables. La manière dont elle est codée et configurée devrait permettre de clarifier suffisamment le travail de remplacement pour pouvoir l’estimer.
Donner aux expérimentations une portée gérable
Vingt guides publics sur la gestion des rendez-vous fournissent à l’équipe suffisamment de matière pour un premier test utile. Le personnel d’assistance fournit les questions posées par les clients et identifie l’article censé répondre à chacune d’entre elles.
Le développeur effectue ces requêtes via le moteur de recherche existant et le service d’essai. Le guide approprié apparait-il parmi les premiers résultats ? La recherche fait-elle la distinction entre la modification d’un seul rendez-vous et celle de tous les rendez-vous futurs d’une série ?
Le test doit également inclure des questions auxquelles la documentation ne peut pas répondre. Une requête concernant une fonctionnalité non prise en charge ne doit pas diriger les clients vers des instructions sans rapport simplement parce que la formulation semble similaire.
Si l’essai inclut des réponses générées automatiquement, celles-ci doivent faire l’objet d’une vérification distincte. Une réponse peut citer le guide correct tout en présentant une étape de manière erronée. Le personnel d’assistance doit vérifier si un client suivant cette réponse est en mesure de mener à bien la tâche.
Une période d’essai de quatre semaines laisse au client suffisamment de temps pour décider s’il souhaite continuer à utiliser cet outil spécifique. Le budget doit également être plafonné. Si le fournisseur n’impose pas de plafond de dépenses strict, l’outil doit comporter des limites d’utilisation qui bloquent les nouvelles demandes payantes avant que le budget convenu ne soit épuisé. Une simple alerte par e-mail ne suffit pas à bloquer les facturations ; il est donc préférable de s’y préparer à l’avance.
L’étude de Deloitte intitulée « 2026 State of AI in the Enterprise » indique que seuls 25 % des personnes interrogées mettent en production environ 40 % de leurs expériences en matière d’IA ; il est donc important de comprendre que cet outil n’est peut-être pas la solution la plus adaptée.
Se préparer à des changements dans la charge de travail
La phase d’essai fonctionne suffisamment bien pour que le client souhaite en faire la promotion dans sa newsletter. Quelques collègues du service de support testant des recherches lors d’une réunion ne vous permettront pas de savoir comment l’intégration gère ce type d’audience.
Supposons que l’extension WordPress effectue une requête API synchrone pour chaque recherche. Son thread PHP reste occupé tant qu’elle attend la réponse externe. Plusieurs recherches lentes effectuées simultanément peuvent réduire la capacité disponible pour d’autres requêtes non mises en cache.
C’est une raison suffisante pour tester les recherches simultanées avant l’envoi de la newsletter. Votre développeur peut mesurer le temps de réponse des résultats tout en vérifiant si le reste du site reste réactif. Les limites de débit imposées par le fournisseur externe doivent également être prises en compte dans ce test.
Les couts d’utilisation méritent la même attention. Un visiteur peut effectuer plusieurs requêtes. Si la fonctionnalité génère des réponses, la quantité de texte envoyée au modèle et renvoyée par celui-ci peut avoir une incidence sur la facturation au token. Les journaux de requêtes de la période d’essai vous fournissent une estimation plus précise que la simple multiplication du nombre de visiteurs par le cout d’une recherche.
L’indexation génère une charge de travail en dehors des sessions des visiteurs. La mise à jour d’un guide devrait normalement actualiser son contenu indexé, plutôt que de régénérer les représentations pour l’ensemble du centre d’aide. Le développeur doit vérifier ce que l’extension ou le service choisi effectue réellement lorsqu’un éditeur clique sur « Mettre à jour ».
L’extension peut rester sélective. Si les clients trouvent les liens utiles mais lisent rarement les résumés générés, le client peut conserver la recherche sémantique et désactiver la génération de réponses. La séparation de ces réglages leur offre un moyen concret de réduire les couts sans supprimer l’amélioration à laquelle ils accordent de l’importance.
Raisons de reconsidérer la question
Le retrait par un fournisseur de l’API utilisée par votre extension entraine un changement de planning. L’annonce d’un nouveau modèle peut attendre qu’il y ait une raison de l’étudier.
La distinction entre les composants est ici utile. Si votre agence choisit et appelle directement un modèle, elle doit suivre la disponibilité de ce modèle. Un service de recherche géré peut gérer les changements de modèle en interne, tandis que votre équipe surveille les notifications de son API et la qualité de ses résultats.
Les questions issues de la période d’essai constituent un petit ensemble de tests de régression. Un développeur peut les exécuter après une mise à jour importante du fournisseur ou sur un remplacement proposé. Les résultats attendus rendent la discussion sur une « meilleure recherche » beaucoup plus précise.
Pour la requête relative aux rendez-vous récurrents, le guide actuel apparait-il toujours parmi les premiers résultats ? Si la fonctionnalité génère une réponse, préserve-t-elle la distinction entre la modification d’une seule réservation et celle de la série de rendez-vous ?
Les comparaisons nécessitent un contenu source cohérent. Tester un fournisseur par rapport aux articles du mois dernier et un autre par rapport à des guides réécrits ne vous apprend pas grand-chose sur les fournisseurs eux-mêmes. Le rapport de test doit identifier la révision du contenu ainsi que la configuration pertinente du modèle ou du service.
Les tickets de support peuvent ajouter de nouvelles requêtes à mesure que les clients rencontrent des lacunes. Une solution de remplacement est alors confrontée aux questions qui posent réellement problème sur ce site.
Le cout peut également justifier un nouvel examen. Un modèle moins onéreux pour les réponses générées peut convenir au client, à condition que les réponses restent exactes. Un score de référence général vous fournit des informations moins utiles que les performances observées sur la documentation propre au client.
Opter pour un hébergement qui vous laisse une marge de manœuvre
Un site de staging WordPress est un excellent moyen de permettre aux développeurs d’installer un outil de remplacement tandis que les clients continuent d’utiliser la recherche en production. Kinsta fournit des environnements de staging pour ce type de travail, avec le module de staging premium disponible pour les tests nécessitant davantage de ressources.
La configuration de la recherche externe doit également être séparée. Le clonage de WordPress peut copier les réglages d’extensions qui pointent vers l’index de production. Avant de lancer une tâche d’indexation sur l’environnement de staging, le développeur doit configurer un index de test et des identifiants dotés des droits d’accès appropriés. Sinon, un test en staging risque de modifier les résultats de recherche en production.
La surveillance des performances des applications de Kinsta facilite l’analyse du volet WordPress de l’intégration. Lorsque l’APM est activé, votre développeur peut examiner les requêtes externes côté serveur et les requêtes de base de données lentes. Les appels côté navigateur nécessitent des diagnostics au niveau du navigateur. L’APM n’affiche pas toutes les requêtes effectuées par le navigateur d’un visiteur.
Ces traces permettent de déterminer si WordPress passe la majeure partie d’une recherche lente à attendre le fournisseur. Une capacité d’hébergement supplémentaire ne réduira pas le temps de réponse de ce fournisseur.
Lorsque les tests identifient une contrainte de capacité PHP, MyKinsta propose des ajustements des ressources PHP dans le cadre des options de plan disponibles. Un plus grand nombre de threads PHP permet de traiter davantage de requêtes simultanées, mais le fait de répartir le même pool de mémoire entre davantage de threads réduit la mémoire disponible pour chacun d’entre eux. Les comparaisons de performances nécessitent également des ressources de staging et des réglages de mise en cache qui reflètent raisonnablement l’environnement de production.
À mesure que votre agence effectue des tests sur un plus grand nombre de sites, les points de terminaison de l’API Kinsta permettent à vos outils internes de récupérer les détails de l’environnement ou de créer des environnements de staging. L’équipe peut automatiser cette préparation sans donner au moteur de recherche le contrôle du compte d’hébergement.
C’est toujours votre agence qui décide si la solution de remplacement est suffisamment performante pour être mise en production. L’environnement d’hébergement offre un espace pour tester cette décision et analyser les résultats.
Les engagements dans la proposition
La formulation « Ajouter une recherche IA » laisse trop de place à l’interprétation. Votre devis peut couvrir des liens vers des articles pertinents, tandis que le client s’attend à un chatbot capable de rédiger des réponses complètes.
La proposition doit décrire ce que les clients verront concrètement. Pour ce projet, l’engagement initial pourrait porter sur la recherche sémantique dans vingt guides publics, les réponses générées faisant l’objet d’une décision distincte.
Quelques questions permettent de clarifier les limites restantes :
- Quel problème cette phase d’essai vise-t-elle à résoudre ? Les clients ne parviennent pas à trouver les instructions actuelles relatives à la gestion des rendez-vous. Les requêtes de test convenues reflètent ces demandes de support.
- Qu’est-ce qui reste sous le contrôle du client ? WordPress conserve les guides d’origine et leurs métadonnées. L’agence documente les réglages de recherche qui n’existent que dans le tableau de bord du prestataire.
- Qu’est-ce qui dépend de ce service ? La proposition identifie l’intégration de la recherche dans le centre d’aide et toutes les API de modèles qu’elle appelle. Les autres sections du site continuent d’utiliser leur système de recherche existant.
- Comment le client peut-il mettre fin à l’expérimentation ? Un réglage permet de rétablir la recherche existante. La procédure d’arrêt interrompt également les tâches d’indexation planifiées et résilie les services payants superflus.
- Quels sont les critères justifiant un déploiement à plus grande échelle ? Le client définit ce qui constitue un résultat pertinent et le temps d’attente acceptable pour les visiteurs. L’utilisation observée pendant la période d’essai sert de base à l’estimation des couts d’exploitation.
Le déploiement à plus grande échelle nécessite un budget spécifique pour l’indexation du reste de la bibliothèque et les tests dans des conditions d’utilisation plus intensive. Le fait de fournir une estimation distincte pour ces travaux permet au client d’évaluer la période d’essai avant de s’engager.
La proposition peut également désigner la personne chargée d’examiner les résultats à l’issue des quatre semaines. À défaut, le prochain renouvèlement de l’abonnement pourra entrainer la reconduction automatique du projet.
Marge de manœuvre pour la prochaine décision
Le client du logiciel de prise de rendez-vous peut déterminer si la recherche sémantique aide les clients à trouver le guide des rendez-vous sans s’engager auprès d’un prestataire pour les cinq prochaines années.
Les articles d’origine restent dans WordPress. Si la période d’essai s’avère décevante, le client conserve les améliorations rédactionnelles et revient à la recherche existante. En cas de succès, votre agence dispose d’éléments probants pour justifier un déploiement à plus grande échelle.
Un futur changement de prestataire nécessite tout de même du travail. Quelqu’un devra adapter l’intégration de l’API et tester les résultats. Selon la nature du changement, la reconstruction de l’index peut prendre du temps et entraîner des coûts d’utilisation. Le fait de séparer ces tâches du reste du site facilite leur planification.
C’est un type de contrôle utile à proposer à un client. Vous pouvez expliquer ce à quoi il s’engage aujourd’hui et ce qu’impliquerait un choix différent ultérieurement.
L’hébergement WordPress infogéré de Kinsta fournit à votre équipe des environnements de staging et des outils de performance pour accompagner ces décisions. Votre agence peut tester dès maintenant une fonctionnalité d’IA utile, tout en disposant d’une marge de manœuvre claire pour la modifier à mesure que les besoins du client évoluent.
Carlo est un passionné de webdesign et de développement frontend. Il joue avec WordPress depuis plus de 10 ans, notamment en collaboration avec des universités et des établissements d'enseignement italiens et européens. Il a écrit des dizaines d'articles et de guides sur WordPress, publiés à la fois sur des sites web italiens et internationaux, ainsi que dans des magazines imprimés. Vous pouvez trouver Carlo sur X et LinkedIn.
