Recherche fédérée

 Jae 

Bon, commençons par la définition générale de la recherche fédérée dans le secteur. Et en quoi cela peut-il être utile ? 

Pete 

C'est une question intéressante : existe-t-il une définition sectorielle de la recherche fédérée ? Je pense qu'il existe de nombreuses définitions différentes, utilisées de manière interchangeable, mais je pense que notre secteur considère généralement la recherche fédérée comme un concept où toutes ces données proviennent de sources différentes : six systèmes différents, deux types de systèmes de gestion différents, une base de données ou un système de fichiers. Lorsque l'on pense à la recherche fédérée, pour les entreprises et les grandes sociétés, on s'accorde sur l'idée qu'il existe une multitude de zones distinctes contenant du contenu et des données.

Par exemple, si je disais : « Je cherche quelque chose sur notre site web, mais je dois aussi consulter Google Drive », cela nécessiterait deux recherches différentes : une sur notre site web et une sur Google Drive. J'ai donc effectué une requête. Si je créais un système ou un service de recherche automatisé effectuant ces deux requêtes et obtenant un seul résultat, il s'agirait d'une recherche fédérée. On peut donc l'envisager sous différents angles. Et, franchement, c'est en grande partie là que Coveo a démarré. J'étais là à ses débuts, et ils avaient une sorte d'appliance de recherche fédérée qui explorait les fichiers locaux, les disques durs, SharePoint, et tout connecteur imaginable. Ils pouvaient explorer et intégrer tous ces différents types de contenu dans un ou plusieurs index. Chaque index correspondait donc à chaque recherche fédérée. Lorsqu'ils effectuaient des requêtes, ils les exécutaient sur tous leurs index et créaient une recherche unifiée. C'était le point de départ de Coveo. Ils ciblaient les entreprises. Là où je travaillais auparavant, nous avions un serveur d'applications d'entreprise Coveo dans nos bureaux, et ils avaient un petit widget de bureau Windows qui me permettait de rechercher ce que je cherchais, et il analysait tous nos lecteurs de fichiers. Il analysait mes e-mails et mon site web, et je pouvais trouver le contenu correspondant à mes recherches.

Ils sont donc devenus une grande entreprise de recherche, mais quand je pense à la recherche fédérée, c'est à cela que je pense. L'idée est qu'il existe différents types de systèmes sur mesure qui contiennent des données, et nous voulons pouvoir collecter ces informations.

 Jae 

Et dans le cas que vous venez de décrire, s'agissait-il d'une recherche sur le lieu de travail, comme une recherche interne d'employés ? Ah, d'accord. Ce qui est intéressant, c'est qu'avant même de parler de Coveo, vous avez évoqué les méthodes utilisées. D'une part, il y a plusieurs recherches effectuées sur différents ensembles de données – ou banques de données, devrais-je dire –, mais il y a aussi ce concept d'unification de la banque de données. Ma question est donc : pourquoi l'ont-ils appelé « fédéré » dès le départ, plutôt que « unifié », n'est-ce pas ? Car, en fin de compte, si l'on considère la fédération, il existe deux approches, comme vous venez de le mentionner. Soit on peut la faire au niveau des données, soit on peut simplement utiliser l'interface interne, c'est-à-dire la recherche elle-même, n'est-ce pas ? Avez-vous un peu de contexte à ce sujet ? 

 Pete 

Je peux émettre quelques hypothèses, n'est-ce pas ? C'était il y a peut-être 15 ans. Ça fait un moment maintenant. C'est aussi à cette époque que des services comme Active Directory et les services fédérés ont commencé à utiliser le terme « fédération ». Pour moi, c'est une approche à l'échelle de l'entreprise, et je peux partager les fonctions ou les données que j'utilise avec d'autres services. On va donc commencer à parler de fédération. Mais je pense que lorsque l'on commence à réfléchir au terme « recherche fédérée », cela vient vraiment d'une perspective marketing, ou simplement parce que les gens comprenaient facilement que le terme « fédération » désigne en réalité plusieurs systèmes interagissant les uns avec les autres. Et je pense que c'est en grande partie de là que vient le terme « recherche fédérée ».

Et pourquoi, surtout dans notre secteur, c'est, faute d'un meilleur terme, le terme familier que nous utilisons pour parler de recherche consolidée ou unifiée en général, surtout lorsqu'on commence à ajouter des robots d'indexation ? Il existe une différence nette. Et je pense que, lorsqu'on compare la recherche unifiée à la recherche fédérée – et Sameer rit à chaque fois –, il y a une différence. La principale différence avec une recherche fédérée, c'est qu'on n'unifie pas vraiment un index unique, on crée un mécanisme de requête qui efface plusieurs points de données ou sources, puis les catalogue en une seule réponse. C'est la vraie fédérée. Alors que dans une recherche unifiée, on examine toujours plusieurs systèmes, mais on le fait davantage dans une optique d'ingestion. On peut donc utiliser des robots d'indexation ou se dire : « Je vais explorer ce système, je vais explorer ce système. » On les appelle des robots d'indexation, car c'est le terme familier. En fin de compte, nous ne faisons que parcourir une API, analyser, extraire une page web ou suivre des liens. Il existe différentes fonctions que nous pouvons utiliser, ce que nous appelons un robot d'exploration. Nous utilisons tout cela pour créer un objet de données unifié, stocké dans un index unique. Nous effectuons donc ce processus de traduction où les structures de données sont complètement différentes de celles que nous lisons. Nous créons alors une interface : nous disons : « OK, nous allons prendre cette structure, la modeler selon nos besoins, et voici tous nos champs. Nous allons maintenant stocker le tout dans un index unique. » Il s'agit d'une recherche unifiée, où nos requêtes ne doivent atteindre qu'un seul index, et tout le contenu réside dans un seul catalogue.

 Jae 

J'ai entendu parler de « fédération de requêtes ». Ce que vous décrivez, ma question suivante, portait sur la raison pour laquelle tant de points de vue divergent sur la recherche fédérée. Et je pense que vous y avez déjà répondu, en substance, en disant que chacun la nomme différemment. Chacun a sa propre approche. S'agit-il simplement de différences marketing ? Y a-t-il aussi des différences techniques ? Et ce que vous décrivez, c'est qu'en termes de définition – de définition acceptée – votre exemple d'authentification était un parfait exemple, car il fallait l'appliquer dans un cadre technique très spécifique pour des raisons de conformité et d'autres exigences. Il semble donc que la recherche fédérée ait évolué avec des types similaires de… encore une fois, le mécanisme sous-jacent dictait si elle était réellement fédérée ou non. Nous en sommes maintenant au point où, dans certains cas d'utilisation, il s'agit davantage d'unifier l'expérience, n'est-ce pas ? Cela a beaucoup moins à voir avec les exigences architecturales.

 Pete 

Oui, et ce secteur cible généralement deux principaux types d'utilisateurs : les développeurs techniques, mais aussi les spécialistes du marketing numérique, même les moins expérimentés. Et pour éviter toute nouvelle formation, il est plus simple de parler de « recherche fédérée », car l'idée est déjà intégrée : je comprends la recherche fédérée, je consulte simplement plusieurs sites. Au final, l'effet est le même.

 Jae 

Alors, quel est le véritable problème que les clients tentent de résoudre ? Vous l'avez évoqué, mais j'aimerais approfondir ce sujet et y répondre de manière plus complète. En effet, et je pense que nous l'avons déjà dit, la question est : existe-t-il une recherche fédérée universelle ? Ou existe-t-il des sous-exigences très spécifiques nécessitant des fonctionnalités de recherche différentes ? Quant à l'interopérabilité des plateformes – encore une fois, en parlant de tous ces différents types de bases de données – quel est le véritable problème qu'ils cherchent réellement à résoudre ? Car je pars du principe que la recherche fédérée pure a toujours sa place, n'est-ce pas ? Mais en général, lorsque les utilisateurs expriment leur besoin d'une recherche fédérée, ils ont peut-être besoin de quelque chose de différent, comme une recherche unifiée.

 Pete

Pour répondre à votre première question, en matière de recherche fédérée, de fédération, d'entreprise, les besoins métier sont quasiment illimités. Par exemple, je dois effectuer une recherche dans un registre pour un site AS 400, et simultanément, je dois pouvoir extraire des pages Wiki de Wikipédia. Les cas d'utilisation sont multiples. 

Le défi que la plupart des marketeurs tentent de relever est double. Je pense qu'ils tentent de le résoudre en une seule action, mais ils tentent de résoudre deux problèmes. Le premier est de rendre le contenu facile à trouver et accessible pour mes utilisateurs. Au fait, ce contenu est présent sur 13 systèmes. Il est donc difficile pour un marketeur de se demander : « Comment vais-je rassembler tous ces contenus provenant de différents systèmes pour qu'un utilisateur puisse facilement utiliser son système et trouver la conférence qu'il recherche ? » C'est, selon moi, le principal défi auquel les utilisateurs sont confrontés lorsqu'ils envisagent la recherche fédérée ou unifiée. 

Je pense qu'il y a une limite aux possibilités de la recherche unifiée. Cela dépend principalement du nombre de systèmes et de la diversité des données. Prenons l'exemple d'un site web qui regroupe des articles de blog ou une bourse. Nous utilisons plusieurs robots d'exploration pour récupérer le titre, l'auteur et le titre du contenu, et même si ces systèmes représentent les données différemment, un article de blog reste un article de blog. Nous savons qu'il aura des en-têtes, un titre, une signature, du contenu et peut-être même une image. Nous pouvons donc créer des robots d'exploration qui les analyseront et les configureront. Au fait, nous souhaitons également afficher les cours de la bourse. Et ce sont des données différentes. Google résout ce problème très facilement. Google le fait, mais il analyse tout. Google est l'exemple parfait d'index unifié. Et la plupart des entreprises, des particuliers et des spécialistes marketing qui recherchent des outils de recherche pour leur site web ne cherchent pas à créer Google. Le design est une perspective complètement différente. Beaucoup souhaitent simplement que le design imite la simplicité d'utilisation de Google et se contente de la barre de recherche, mais c'est un tout autre sujet.

 Jae 

Ce que j'entends, comme vous l'avez dit, c'est qu'il existe des millions de cas d'utilisation. Mais le cœur du problème réside dans l'hétérogénéité des ensembles de données et la dispersion des données. Je souhaite donc simplifier cette expérience de recherche. Vous avez ensuite abordé un point que j'aimerais approfondir : la recherche fédérée est-elle toujours nécessaire dans certains cas ? Est-ce spécifique à un secteur ? Ou y a-t-il des secteurs spécifiques qui ont davantage besoin de la fédération que d'autres ? Et qu'en est-il au niveau des cas d'utilisation ? Voyons-nous, par exemple, certaines cartes personnalisées qui pourraient être fédérées, ou peut-être pour des raisons de conformité, de confidentialité et de sécurité, ou s'agit-il simplement d'une exigence fondamentale de recherche sur site ?

 Pete 

Je pense que vous avez posé quelques questions intéressantes. Et je pense que… je vais aborder le dernier point que vous avez mentionné, car la conformité est un élément clé lorsque nous avons commencé à nous intéresser à des aspects comme le RGPD. L'emplacement des données a été très important. Et si nous commençons à unifier les informations et à les stocker ailleurs, elles resteront conformes au RGPD. 

Ainsi, si nous intégrons des informations personnelles – ce qui, honnêtement, ne devrait jamais être le cas – dans une structure de recherche unifiée, il faut comprendre que cela est désormais soumis aux règles de conformité du RGPD, et peut-être même de la loi californienne sur la protection des consommateurs. De nombreuses réglementations sont désormais en vigueur. Et avec le temps, ces réglementations deviennent encore plus strictes. Dans ce cas, le risque que les entreprises prennent pour un index unifié peut être supérieur à la nécessité ou à la simplicité d'utilisation de cet index. À cet égard, il serait souhaitable d'avoir une fédération où « ma requête » est accéder à cet autre système protégé par le RGPD, afin de renvoyer les résultats, et non, je ne stocke ces informations nulle part ailleurs. 

Je pense donc que la conformité joue un rôle. Certains secteurs en ont peut-être plus besoin que d'autres. Mais je ne pense pas que ce soit nécessairement spécifique à un secteur. Je dirais plutôt que c'est spécifique à un cas d'utilisation. Plus important encore, je me demanderais : quelles sont les données ? Quel est le contenu et où se trouve-t-il ? Et cela influencera bon nombre de vos décisions commerciales concernant vos cas d'utilisation, selon le type de données traitées.

 Jae 

Et peut-on dire que, de manière générale, l'utilisation interne – comme la recherche sur le lieu de travail – nécessitera probablement davantage de conformité, car elle implique des données clients, potentiellement des informations personnelles identifiables, et d'autres éléments de ce type. Par rapport à une simple consultation d'un site web d'entreprise ou d'une expérience numérique informationnelle standard, non ancrée dans le e-commerce, cela ne posera généralement pas de problème majeur, n'est-ce pas ? Est-ce exact ?

 Pete 

Pas seulement la conformité, Jae. La gouvernance aussi. Je ne souhaite peut-être pas montrer les résultats de recherche à tout le monde ; j'ai peut-être des personnes privilégiées qui ne peuvent voir que certains résultats dans cet environnement de travail. 

Les normes de gouvernance jouent également un rôle. En effet, si nous devons désormais gérer les résultats de recherche sur les sites en fonction de ces critères, cela complexifie le cas d'utilisation et la solution. Mais, surtout, surtout pour les clients qui utilisent nos produits, SearchStax s'intègre parfaitement aux données déjà accessibles au public. Nous explorons simplement des sites web publics – je ne citerai pas de noms, mais nous avons un client pour lequel nous venons de terminer l'implémentation. Il stocke tous ses contrats dans un outil de gestion des ressources numériques. Nous analysons tous ces contrats et les rendons accessibles à tous. 

Donc, encore une fois, c'est une excellente utilisation de la recherche unifiée, car nous pouvons extraire les différentes parties du résultat de la requête de recherche que nous recherchons à partir de différentes parties du contrat et pouvoir toujours les fusionner avec le contenu du site Web.

 Jae 

Ce que j'entends, c'est que, surtout sur les marchés que nous desservons, l'exigence de fédération ne pose généralement pas de problème, comme vous l'avez dit. Il s'agit d'informations accessibles au public. 

Pete

Et honnêtement, si c’est une exigence, peut-être que votre outil n’est pas le meilleur.

Jae

Exactement. Changeons de contexte un instant pour parler des compétences et évoquons certaines des compétences organisationnelles dont ces équipes auront besoin pour répondre à cette exigence particulière. 

Cela sera-t-il différent de ce que l'on fait aujourd'hui ? Autrement dit, avez-vous besoin de nouvelles compétences pour résoudre cette recherche unifiée et/ou fédérée ? Ou cela ressemblera-t-il davantage à ce que vous disiez précédemment : tant que vous comprenez la méthodologie, vous avez pratiquement tout ce qu'il vous faut, n'est-ce pas ? Je pose cette question pour déterminer si cela doit être perçu comme un obstacle/un défi majeur, ou comme quelque chose de simple.

 Pete 

Je dirais que pour ce qui est des résultats de recherche sur un site web – et je parle plutôt de ma propre expérience, j'ai passé 15 ans dans le conseil où nous devons créer des solutions, voire des solutions complètes, pour des clients potentiels, pour l'ensemble de leur site web. Dans ces cas-là, la recherche sur un site web devient presque – et je déteste le dire – presque comme un enfant roux. En effet, l'accent est mis sur la page d'accueil, les pages de destination, les pages d'articles, et trois mois après le début de la planification du design, le développeur se demande : « Et la page de résultats de recherche ? »

Et puis, un concepteur crée rapidement une page de résultats de recherche qui ressemble aux résultats de recherche personnalisés de Google. 

En fin de compte, je pense qu'il est temps. Les gens ne considèrent peut-être pas les résultats de recherche comme un élément essentiel de leur site web, mais plutôt comme un élément de deuxième ou de troisième ordre. Du coup, en termes de temps et de budget, on se retrouve soudainement sans les deux. 

Ou quand il est En y réfléchissant bien, il n'existe pas vraiment de stratégie pour la recherche sur site. Beaucoup de développeurs envisagent la question des résultats de recherche comme s'ils devaient « réinventer la roue ». C'est ce que Sitecore a fait, n'est-ce pas ? Ils ont créé une API de résultats de recherche personnalisée, en quelque sorte une encapsulation autour de Solr. Ils n'ont inclus aucun kit de démarrage, aucune interface graphique ou quoi que ce soit de ce genre. C'est juste une API .NET. Les développeurs l'utilisent pour créer des pages de résultats. Ils ont donc fait tout cela de manière artisanale, car c'est en grande partie ce que fait Sitecore : ils créent leurs vues et leur interface utilisateur à la main, pour utiliser les API fournies par Sitecore.

Pour un développeur Sitecore, c'est la norme. On ne sourcille même pas quand on nous dit : « Je vais recréer une interface de recherche. » On crée une interface de recherche : elle doit contenir des résultats, un élément répétitif, et il y aura probablement des filtres à gauche, en haut ou à droite. Je ne sais pas, ça dépend de ce que mon designer veut faire. Mais je vais passer le relais. C'est loin de leur imagination de se dire : « Oh, il existe un outil que je peux simplement abandonner. » Et peut-être que « abandonner » est un terme trop édulcoré – cela nécessite une certaine implémentation –, mais nous pouvons intégrer notre accélérateur à la plupart des applications et offrir une expérience de recherche en un rien de temps. Et puis le développeur n'a pas à penser à la conception, le développeur n'a pas à penser à réinventer la roue à chaque fois, et puis on se débarrasse de l'API de recherche, qui, franchement, n'est pas ma préférée.

 Jae 

Je comprends votre point de vue, en d'autres termes, c'est comme si cela vous avait mené si loin, mais en réalité, l'essentiel du travail était encore là. Et c'est un travail vraiment mystérieux.

Pete 

Ah oui. Et la raison, c'est qu'il y a un manque d'éducation. La plupart des développeurs ignorent qu'il existe une autre façon de faire, car nous sommes tellement habitués à tout faire nous-mêmes. En gros, on le fait soi-même. Soit on s'inspire du projet précédent, soit on le réinvente. 

Quand on pense aux sociétés de conseil, c'est la règle du jeu. Quelle que soit la roue inventée lors du dernier projet, réutilisez-la, car elle est identique. Alors, elles continuent à réutiliser cette roue, même s'il existe probablement une meilleure roue.

 Jae 

Ouais. Bien sûr. Réutilise ce que tu as, d'accord ? 

 Pete 

Il est donc essentiel d'éduquer ces personnes, en particulier celles qui dirigent les développeurs et les responsables techniques, pour leur dire : « Hé, il existe une autre roue, nous pouvons vous montrer une meilleure roue ».

 Jae 

Quels conseils donneriez-vous à quelqu'un qui débute dans cette voie, confronté au problème posé par la multitude de données disséminées dans son environnement ? Quels pièges peuvent-ils éviter lorsqu'ils envisagent de mettre en place une recherche fédérée ou unifiée, selon leur point de vue ? Quels conseils leur donneriez-vous pour résoudre le problème évoqué précédemment dans leur environnement ?

 Pete 

Mon meilleur conseil est de ne pas se lancer à corps perdu dès le premier mois. Déterminez le produit minimum viable, créez un ou deux sites web externes, voire commencez simplement par installer votre système de gestion de contenu (Sitecore, Drupal, Adobe, etc.). Commencez par optimiser votre moteur de recherche, puis ajoutez d'autres sites.

Si vous essayez d'être exhaustif – ce qui est possible avec une planification adéquate, par exemple –, cela ne fera qu'allonger le délai d'adoption, ce qui complexifiera le développement global. Vous risquez alors de vous détourner de l'accélérateur, ce qui vous incitera à développer des applications personnalisées. C'est faisable, et notre système d'API le permet. J'ai oublié de mentionner un autre point concernant le développeur, car cela m'est venu à l'esprit. Dans ces scénarios – où l'on réutilise ou réinvente la roue, notamment avec l'API de recherche personnalisée de Sitecore –, on peut toujours créer des interfaces utilisateur personnalisées avec SearchStax Site Search, mais aucune application développée par un développeur n'offre, contrairement à Sitecore, les analyses, l'utilisation du tableau de bord, la possibilité d'optimisation… En fait, c'est une situation très courante chez les développeurs : les marketeurs envoient une demande au développement pour demander « Optimiser un champ ». Et c'est un effort de code. Vous l'ajoutez au backlog, l'appliquez à un sprint, vous disposez de deux semaines pour que ce sprint de développement arrive à maturité, puis de deux semaines supplémentaires pour le cycle de publication. Et ainsi, un mois plus tard, vous le faites fonctionner. C'est une pratique courante et acceptée.

Jae 

Bien. Comme vous l'avez dit plus tôt, nous avons été formés à accepter ces délais. Pourriez-vous nous donner quelques exemples – et je reviendrai peut-être sur la question précédente concernant les compétences – ? J'essaie de vous donner quelques exemples concrets. Vous avez mentionné un client avec lequel nous avons travaillé récemment. Pourriez-vous nous présenter le contexte concret, en commentant les compétences requises et en nous conseillant de ne pas trop se précipiter ? Et, sans citer le nom du client, pourriez-vous nous donner un exemple de réussite, car ils ont adopté une approche plus progressive. Vous en avez donné une version très conceptuelle, mais j'aimerais entendre un exemple plus concret.

Pete 

Concrètement, nous nous intéressons ici à deux aspects : le développeur et le marketeur. Ce dernier peut être technique ou non, peu importe. 

Du point de vue d'un marketeur, les compétences essentielles sont de comprendre les cas d'usage de son entreprise et l'importance de la recherche sur site. Il doit comprendre l'importance de la pertinence et comprendre clairement ce que recherchent ses utilisateurs et pourquoi ils le font. C'est la responsabilité du marketeur. 

Côté développeur, les compétences se situent à plusieurs niveaux. Premièrement, il faut connaître son CMS. Évidemment, pour être intégré à un CMS, il faut le connaître. Mais surtout, le développement d'API devient de plus en plus courant. On parle de « headless » – et j'utilise « headless » au sens large – tout est piloté par les API. Et notre produit SearchStax Site Search est, au final, une application axée sur les API. L'intégration de technologies front-end – qu'il s'agisse de JavaScript, de React, de View ou de n'importe lequel de ces outils – est donc un concept important. Nous fournissons même des modules d'aide. Sitecore, par exemple, propose XSA, un accélérateur d'expérience Sitecore. Nous proposons un module XSA intégré qui expose notre accélérateur et accélère encore l'expérience Sitecore. Mais le développeur doit tout de même connaître Sitecore.

Il est donc essentiel de bien comprendre vos technologies : même si nous disposons d'un accélérateur, il faudra tout de même le mettre en œuvre, avec un délai de mise en œuvre. Les cas d'usage et les personnalisations ne feront que compliquer les choses, et je pense que c'est normal. Si c'est ce à quoi vous vous engagez, si vous vous dites : « Nous voulons la promesse de SearchStax Site Search pour ce qu'il offre en back-end, à savoir la pertinence, le boosting, les promotions, toutes les fonctionnalités de SearchStax Site Search que nous apprécions vraiment – car ce sont des éléments que personne ne maîtrise vraiment », vous pouvez vous contenter de données personnalisées et d'une certaine implémentation. 

Je pense donc que c'est l'attente qu'il faut absolument exprimer : « Non, vous aurez quelqu'un qui maîtrise votre interface utilisateur, les systèmes de gestion de contenu et qui est patient », en fin de compte. C'est valable pour tout projet de développement. Un bon exemple de notre client – je dirais, pas tout à fait. Mais c'est un bon exemple où il nous a fallu avancer petit à petit, se familiariser un peu avec le produit. » Nous avons mené une démonstration de faisabilité avec eux pendant un mois ou deux, au cours de laquelle ils vont devoir fédérer leurs équipes. Ils possèdent une cinquantaine de sites web et souhaitent pouvoir afficher l'ensemble du contenu de tous ces différents sites web personnalisés dans une seule et même expérience de recherche. Nous avons envisagé la situation sous l'angle suivant : « Très bien, pourquoi ne pas simplement prendre deux de ces sites ? Prenons-en deux et voyons à quelle vitesse ils peuvent les implémenter et obtenir l'expérience de recherche souhaitée. » Cela les a vraiment aidés à se concentrer sur l'API et sur la création de résultats, et à éviter des distractions telles que : « Quels sont ces 49 autres sites web différents avec lesquels nous allons devoir intégrer ? »  

Cela a ouvert la voie, car maintenant que nous avons réalisé deux sites, ils se disent : « Oh, voyons comment nous pouvons réaliser les 50 autres. » Et cette peur de la taille du Goliath a pratiquement disparu. Ils comprennent maintenant que c'est très simple à réaliser, il suffit de le reproduire. Je pense donc qu'ils sont sur la voie du succès.

 Jae 

Oh, c'est génial. On dirait que vous avez fourni de nombreuses indications initiales sur la planification elle-même. Autrement dit, comme vous l'avez dit, il ne faut pas tout gâcher, il faut s'assurer qu'il existe un chemin logique pour progresser et comment y parvenir.

Quels conseils spécifiques avez-vous donnés ? Cette question est la dernière, mais elle s'adresse surtout aux personnes qui s'intéressent à SearchStax. Pourriez-vous leur donner des conseils pour les aider à déterminer rapidement si nous sommes une solution intéressante pour la recherche fédérée ? Pourriez-vous développer un peu ce que vous venez de mentionner avec ce client actuel ? Quelles ont été les discussions initiales pour déterminer si nous étions compatibles ? Pourriez-vous ensuite nous en dire plus à ce sujet ?

 Pete 

Ce qui était vraiment intéressant, surtout pour ce client, c'est qu'il nous a contactés dès le départ avec une approche « à la carte ». Ils avaient probablement 35 exigences différentes, allant de l'IA au traitement du langage naturel, en passant par 37 langages différents, et toutes sortes d'exigences. Et pour être honnête, pour certains de ces aspects, notre produit n'est pas encore au point. Par exemple, nous n'avons pas de traitement du langage naturel, ni beaucoup d'IA intégrée. Dans ce cas, nous devons être très transparents et honnêtes et expliquer : « Voici les fonctionnalités de notre recherche sur site. » Et donc, pour quelqu'un qui voudrait dire : « Voici les fonctionnalités qui me correspondent », quelles sont les fonctionnalités réellement requises et quelles sont vos fonctionnalités intéressantes ? Si votre atout est le traitement du langage naturel, eh bien, nous allons continuer à faire évoluer notre produit. Je ne vois pas comment notre produit SearchStax Site Search ne pourrait pas intégrer le traitement du langage naturel à l'avenir. Le produit évoluera. Mais si c'est votre exigence principale et que vous devez l'avoir dès le premier jour, nous ne pourrons pas vous aider.

Il s'agit de bien comprendre vos besoins et vos exigences dès le départ. Si vos exigences initiales sont : « J'ai juste besoin de trois sites web » – ou peut-être que le nombre de sites web ne compte même pas ? Peut-être avez-vous simplement besoin de contenu pour plusieurs sites web, disponible en cinq langues différentes.

 Jae 

Y avait-il des éléments spécifiques à l'aspect fédéré, fédéré/unifié, lors de la conversation avec le client, quant à la compatibilité ? Vous avez mentionné certaines fonctionnalités qui, au fil de votre réflexion, ont été jugées plus intéressantes. Mais concernant la fédération, y avait-il des distinctions entre les indispensables, les façons de fonctionner fédérées, et la voie que nous empruntons, celle qui est plus unifiée ?

 Pete 

Non, en fait, une fois que nous avons décrit le terme courant de fédération comme étant en réalité une indexation unifiée, ils étaient satisfaits. Car au final, et je pense que c'est là l'essentiel, n'est-ce pas ? Peu importe qu'il s'agisse d'une fédération ou d'une indexation unifiée. Je peux exécuter une requête de recherche et obtenir des résultats qui englobent tous les sites. Si cela se produit, ce qui se passe en coulisses n'intéresse généralement pas le marketeur.

 Jae 

Exact, sauf dans les rares cas évoqués précédemment, notamment en matière de conformité dans la gouvernance, mais pour la plupart des sites web publics, cela ne posera pas de problème. C'est formidable. J'apprécie beaucoup cette discussion. Je pense que, comme vous l'avez dit, il est essentiel de bien comprendre ses besoins. Nous avons abordé tout le reste, notamment les compétences, et même les points sur lesquels il faut se concentrer et être conscient, en tant que marketeur digital et développeur. Nous avons également abordé la notion de « fédération » et la façon dont les gens apprécient – j'aime le terme que vous avez utilisé, c'est simplement une utilisation courante de « fédération ». Nous avons également identifié que cela dépendra probablement davantage d'un cas d'utilisation que d'un secteur d'activité. En fin de compte, nous voulons dire qu'il faut adopter une approche logique et progressive, être réaliste : nous pouvons vous aider, nous avons le produit et les compétences de conseil interne pour vous aider à démarrer. C'était très utile et, je l'espère, utile à beaucoup de gens. D'autres commentaires pour conclure ?

 Pete 

Ne parlez pas aux inconnus. [Rires] Non, je plaisante. Non, je veux dire, la discussion a été intéressante. Et c'était formidable d'analyser et d'approfondir certains de ces aspects. On ne parle pas assez des différences entre unifié et fédéré, car je pense que les gens comprennent généralement qu'ils pourront exécuter une requête et obtenir des résultats. Mais il y a des détails cachés, et je pense qu'il faut s'assurer que vous comprenez bien vos cas d'utilisation – quelles sont vos exigences essentielles – et ensuite, nous pourrons travailler dessus, faire une démonstration de faisabilité, un essai et vous montrer comment SearchStax Site Search peut réellement fonctionner avec ces cas d'utilisation. Ensuite, nous serons également francs et vous dirons : « Hé, ce n'est peut-être pas la solution ».

 Jae

Oui, exactement. C'est une excellente plongée dans certains de ces sujets. Merci encore beaucoup, Pete.