Ingestion de données

Jae 

Aujourd'hui, nous recevons Karan Singh et Pete Navarra de SearchStax, tous deux membres de l'équipe Solutions. Nous aborderons les concepts fondamentaux de l'ingestion de données du point de vue de SearchStax. Permettez-moi de commencer par une question de base : pouvez-vous nous expliquer dans quels cas l'ingestion de données est importante pour les clients SearchStax ? Est-ce uniquement pour Site Search ? Devons-nous nous en préoccuper en dehors de Site Search ? Si je pose cette question, c'est surtout pour que les nouveaux utilisateurs de SearchStax puissent bénéficier d'un contexte de base. Nous pourrions commencer par Pete, puis poursuivre avec Karan.

Pete 

Sans ingestion de données, nous n'aurions pas de résultats de recherche, car l'index serait vide. Il est donc crucial de disposer d'un processus permettant d'intégrer les données à l'index. C'est ce que l'on appelle l'ingestion. Certains appellent cela la mise à jour des API, et cela peut prendre différentes appellations. Mais au final, c'est le processus d'intégration des informations à l'index qui nous permet ensuite d'effectuer des requêtes. Est-ce uniquement pour Site Search ? Je pense que Site Search s'appuie sur Solr. Et lorsqu'il s'agit d'intégrer les résultats de recherche vidéo dans Solr, il s'agit d'ingestion de données. Est-ce uniquement pour Site Search ? Non, je pense – et Karan a beaucoup travaillé dans ce domaine – que nous devons ingérer directement dans Solr. C'est donc une question pertinente pour nos deux produits, Managed Search et Site Search.

Karan 

Oui, exactement. Je reviens sur le point de Pete : vous n'aurez ni données ni résultats de recherche si vous n'ingérez pas de données. C'est parce que Solr est un index, et pour créer un index, il faut des données. C'est pourquoi les données sont si importantes. Plus vos données sont de qualité, plus vous en avez, plus vous avez de contrôle sur la qualité des résultats de recherche. Vous aurez plus de contrôle sur les champs à utiliser pour la recherche, sur les facettes ou les options de tri. La qualité des données aura donc un impact direct sur la qualité des résultats de recherche obtenus.

Jae 

C'est tout à fait logique. Et puis, permettez-moi de poser une question secondaire : lorsque les gens découvrent la recherche (ils ont peut-être déjà travaillé sur des projets liés à la recherche, mais sans s'y intéresser directement), existe-t-il des recommandations générales ou des principes directeurs que vous donnez aux utilisateurs en matière de données ? Comment aborder ce sujet du point de vue de la recherche, car, comme vous l'avez mentionné, il est évidemment important de bien faire les choses.

Karan

Mon premier conseil est donc de vous assurer de pouvoir afficher toutes les données que vous utilisez, car un client peut avoir des données dans un référentiel, d'autres dans un autre, et des métadonnées dans un troisième. C'est la première chose à faire : afficher toutes ces données afin qu'elles puissent être intégrées à Site Search et que vous puissiez ensuite proposer une recherche par-dessus. Assurez-vous donc de pouvoir nous envoyer des données.

Jae 

Bien ! Quelque chose à ajouter, Pete ?

Pete

Parfois, la première étape consiste à comprendre quelles données envoyer. Ensuite, il faut suivre le processus. Quand on parle de données, on parle de champs. Et quand on parle de champs, on parle de contenu. Et c'est un peu plus complexe. Beaucoup de nos clients utilisent de grands systèmes de gestion de contenu qui se concentrent uniquement sur le contenu, et ce contenu contient des champs intégrés. Du coup, parfois, l'accès au contenu est un vrai casse-tête. Parfois, il s'agit d'une sélection de champs depuis le back-end du CMS. Prendre le temps de comprendre votre contenu et de comprendre quelles parties de votre page – celles qui sont révélées – sont les plus importantes avant de vous lancer dans l'ingestion facilitera grandement l'ingestion.

Jae 

Oui, nous avons abordé deux points. Le premier concerne le mécanisme permettant d'envoyer des données. Le second concerne les sources de données elles-mêmes, et même les champs, en particulier, leur correspondance. J'ai peut-être une question à ce sujet, qui revient à ce que vous avez dit, Karan. Que dois-je savoir au préalable pour savoir si je peux envoyer des données ? Quels sont les points essentiels auxquels je dois réfléchir ?

Karan

Pour déterminer si les données peuvent être envoyées, la première chose à vérifier est de pouvoir se connecter à notre système. En effet, quel que soit le système utilisé, il peut se connecter à nous via nos API. Une fois cette connexion établie, vous pouvez analyser les données elles-mêmes. Ensuite, vous pouvez examiner les champs et déterminer comment les renseigner. Et enfin, à quelle fréquence envoyer les données à Site Search ou SearchStax Managed Search, quel que soit le produit vers lequel vous envoyez les données. Vérifiez d'abord si vous pouvez vous connecter à nous, puis si vous avez trié tous les champs à nous envoyer, et enfin, envoyez les données.

Jae 

D'accord, c'est logique. Et que devons-nous encore déterminer au préalable ? Nous avons abordé plusieurs points. Je vais peut-être vous demander dans un instant si nous pouvons avoir un aperçu de Site Search lui-même. Mais quels sont les autres points que je dois absolument comprendre au niveau de l'ingestion des données ? Y a-t-il des aspects qui ne sont pas spécifiquement liés à ces domaines déjà abordés, mais qui sont tout aussi essentiels ? Il y a peut-être des processus internes, comme la propriété des données, etc. Pourriez-vous nous en dire plus à ce sujet ? Nous commencerons peut-être par vous, Pete.

Pete

Oui, en ce qui concerne les besoins préalables, comme je l'ai dit, il s'agit simplement de comprendre où se trouve votre contenu, quel est son contenu, les mécanismes, n'est-ce pas ? La plupart de notre contenu sera ingéré via un robot d'exploration. Alors, qu'allons-nous explorer ? Allons-nous explorer uniquement votre page d'accueil ? Allons-nous explorer le XML de votre site ? Je dirais qu'il faut faire quelques recherches en amont pour comprendre d'où viennent les données. Et une fois que nous savons d'où viennent les données, il faut savoir lesquelles. Par exemple, c'est un point que Karan observe presque quotidiennement. Lors de l'exploration d'un site, voulons-nous les balises méta ? Et quels champs méta de l'en-tête regardons-nous ? Souhaitons-nous que les balises H1 se distinguent par des champs distincts ? Souhaitons-nous explorer la navigation ? Je ne pense pas que la réponse soit oui. Mais lorsque vous réfléchissez aux différentes parties d'une page de votre site web, il est utile de bien comprendre celles que nous souhaitons réellement indexer. En effet, lors de l'intégration, par exemple, cela peut être très long. Il faut attendre que le client effectue cette évaluation. Il est donc important de bien comprendre à l'avance : « Nous allons intégrer de nouveaux éléments de recherche, qui seront basés sur le contenu de notre site. » Dressons la liste des contenus, des types de modèles, des types de pages et des structures d'URL. Allons-nous nous baser uniquement sur votre plan de site XML ? Votre plan de site XML est-il à jour ? Votre fichier robots.txt est-il à jour ? En fait, pour les robots d'exploration, c'est parfois encore plus important. Que ne souhaitez-vous pas que nous indexions ? Le fichier robots.txt est très utile. C'est devenu un peu technique, mais je veux dire, vraiment, c'est pour moi, surtout en tant que personne qui aide en quelque sorte à canaliser les clients dans ce parcours d'intégration de Site Search - comprendre d'où vient le contenu est vraiment la première étape lorsque nous réfléchissons à ce qu'ils doivent avoir compris au préalable.

Jae 

D'accord, c'est vraiment utile. Vous avez mentionné les clients et le fait que Karan voit cela quotidiennement. Alors, Karan, pouvons-nous vous donner la réponse ? Pourriez-vous nous donner quelques exemples de projets récents, ou même passés, où vous avez dû réaliser ce type de projet ? Pourriez-vous nous en donner un exemple relativement simple et facile, et peut-être un autre où ce n'était pas si compliqué ? Pour donner une idée de ce que ce genre de travail initial implique ?

Karan

Bien sûr, je vais vous donner deux exemples. Le premier remonte à octobre ou novembre de l'année dernière. Nous intégrions un client pour lequel nous devions utiliser nos robots d'indexation. Durant tout cet exercice, nous n'avons pas effectué les vérifications préalables nécessaires : nous demandions au client – ou il se contentait d'examiner les données, les champs indexés et les métabalises indexées. Il se fiait au comportement par défaut de tous les composants, à notre robot d'indexation par défaut, et partait du principe qu'il récupérerait tout, car chaque site web est différent. Nous devons donc nous assurer que le système utilisé est capable d'obtenir les données exactes souhaitées. Deux mois après l'intégration, nous avons constaté qu'il n'y avait aucune information dans le champ de description, c'est-à-dire le champ utilisé pour décrire la page. Or, les clients utilisent cette page, ce champ pour afficher du contenu dans les résultats de recherche. Et ils ne voyaient rien, car il n'y avait aucune donnée dans les balises de description. Voilà un exemple. L'autre exemple remonte à la semaine dernière, lors de l'intégration d'un client. Nous avons tout analysé : les différents types de pages, les métabalises présentes dans les pages, puis nous avons déterminé précisément ce que le robot d'indexation allait récupérer. Lors de cet exercice, le client a réalisé qu'il était très facile d'utiliser nos robots d'indexation : il suffit d'ajouter des données dans les méta-champs, et notre robot les récupère. Et c'est exactement ce qu'il a fait. En une journée, il a ajouté neuf champs supplémentaires aux méta-balises. Le lendemain, notre robot a tout récupéré et les a intégrés à ses données. En deux jours, nous avons pu améliorer considérablement la qualité de ses données simplement en manipulant les méta-balises. Tout cela grâce à nos exercices pratiques : il suffit d'examiner la page et de déterminer les champs à indexer. Il suffit de déterminer les données à inclure dans ces champs. C'est pourquoi cet exercice devient si important, car vous pouvez simplement terminer la partie ingestion des données en quelques jours, plutôt que de l'étaler sur des mois ou des semaines.

Pete 

Cela devient vraiment important pour les clients, car il s'agit de trouver un équilibre et de définir leurs attentes. Parfois, les clients ne sont pas préparés à la nécessité d'ajouter ces données supplémentaires à leur balise méta. Cela nécessite un effort de développement de leur part. Il se peut que nous attendions un sprint de développement ou une version de développement. Nous sommes alors dans une période d'attente, ou plutôt une période d'attente, pour l'intégration, car le client a compris : « Oh, j'ai besoin de champs supplémentaires, et je dois les déployer. » Tout cela se retrouve donc dans les prérequis initiaux. Si ces champs ne sont pas disponibles, le client devra probablement déployer un effort de développement pour les lui fournir.

Jae 

Voilà deux excellents exemples. Je comprends votre point de vue, Pete, c'est essentiel. C'est fondamental. On pourrait peut-être passer directement aux types de données eux-mêmes. C'est une question en deux parties à laquelle nous pouvons répondre ensemble. Je commencerai par vous, Karan. Quels sont les types de données les plus courants que nous prenons en charge ? Et quelles sont les différentes méthodes que nous utilisons pour chacun de ceux que vous avez évoqués ? Vous savez, le robot d'exploration et les API. On pourrait peut-être approfondir ce sujet et détailler un peu plus ce que nous faisons là-dedans.

Karan

Le type de données le plus courant est l'objet JSON. Vous pouvez créer un objet JSON et nous l'envoyer via notre API. Le contenu de cet objet JSON peut être quelconque. Si vous pouvez convertir un PDF en objet JSON, vous pouvez nous l'envoyer. Si vous pouvez convertir un fichier Excel en objet JSON, vous pouvez toujours utiliser l'API d'ingestion. Si vous avez un fichier CSV, vous pouvez l'importer via notre API d'ingestion. Si vous avez un fichier XML, même celui-ci peut être importé. En résumé, l'API d'ingestion est compatible avec de nombreux types d'objets de données. Comme je l'ai mentionné, elle est compatible avec JSON, XML et CSV. Il suffit parfois de la connecter directement à un pipeline fonctionnant sous Python ou Java, ce qui permet d'ingérer des objets Python et Java, ainsi que des objets dotnet, en utilisant les bibliothèques disponibles sur ces plateformes. Extrêmement flexible, elle peut ingérer tout type de données. Solr prend en charge tous les types de données. Les robots d'indexation peuvent également importer des données, comme des PDF, des Excel, des pages web, et bien sûr des documents Word, des PowerPoint, des fichiers VSD X. Personne n'utilise ces formats, mais notre robot d'indexation les prend en charge, ainsi que des fichiers texte et RTF. Vous disposez donc d'une bande passante importante. Vous pouvez ingérer de nombreux types de données grâce à nos robots d'indexation et à nos API d'ingestion. À vous de jouer.

Jae 

C'est super. J'apprécie. Pete, as-tu quelque chose à ajouter concernant l'importance de cette flexibilité, la façon dont le produit a été conçu et l'objectif qui l'a motivé ?  

Pete

L'un des aspects les plus intéressants – et qui pourrait être l'un de nos différenciateurs – est que nous fournissons la version native de Solr. Si Solr le permet, vous pouvez le faire, et je pense que c'est l'élément essentiel. Nous ne bloquons pas votre accès à Solr via une API native propriétaire, et vous devez vous conformer à nos standards. Pour les entreprises qui gèrent actuellement ces tâches manuellement via Solr et qui ne bénéficient pas des métriques, des analyses et de la rapidité d'ajustement offertes par Site Search, la plupart de leurs API d'ingestion fonctionneront avec la nôtre. Si elles ont déjà défini ce processus, je pense qu'il est très facile de migrer vers Site Search. Ceci dit, il est important de noter qu'une grande puissance implique de grandes responsabilités. Vous pouvez importer vos objets et données JSON dans le format de votre choix. Mais s'il ne s'agit pas d'un format unifié, avec un ensemble commun de champs d'objets JSON, l'indexation sera intéressante si les données importées ne sont pas présentées sous une forme ou une autre. En fin de compte, Solr est un moteur très flexible, ce qui rend la recherche sur site très flexible à cet égard. Pour revenir à ce que nous avons évoqué, il est important de bien comprendre que, lors du téléchargement de documents, il est important d'avoir une forme commune pour l'objet que vous intégrez dans Solr. Par exemple, nous aurons toujours ce champ de description dont Karan parlait, un champ de titre, un champ d'URL, et il est crucial de définir les champs nécessaires à l'affichage, notamment dans les résultats. Nous voulons en effet nous assurer que tous les résultats contiennent la même série de champs. C'est donc ce que j'ajouterais à cette conversation, c'est simplement de comprendre qu'il y a beaucoup de puissance ici que vous pouvez réellement obtenir en étant capable d'utiliser les API Solr natives.

Jae 

Génial. Concernant les méthodes elles-mêmes, Pete, on pourrait peut-être commencer par toi. Quels sont les avantages et les inconvénients des différentes formes de données ? Tu l'as évoqué, tu l'as en quelque sorte suggéré, avec cette phrase : « Un grand pouvoir implique de grandes responsabilités ». J'adore ça. La question est donc : en tant que client, est-il clair que je dois choisir les différentes méthodes d'ingestion de données ? Ou y a-t-il des avantages et des inconvénients ? Ou est-ce plutôt une simple correspondance un à un, et il est très clair que je devrais procéder de la même manière dans ce cas précis et différemment dans un autre ?

Pete

Je pense que dans la plupart des cas, la solution sera simple et directe. Je dirais que pour la plupart de nos clients, nous utilisons uniquement des robots d'indexation. Nous récupérons donc une page et passons au lien suivant. Nous fournissons également des modules, en fonction du système de gestion de contenu que vous utilisez. Par exemple, nous avons un connecteur Sitecore qui fonctionne avec Sitecore et qui fonctionne davantage en mode push, plutôt qu'en mode pull. Sans entrer dans les détails techniques de Sitecore, Sitecore propose des fonctionnalités prêtes à l'emploi pour gérer l'index Solr. Nous exploitons cela en fournissant un index Solr natif à Sitecore, qui constitue notre index Site Search. Ainsi, comme Sitecore indexe ses propres besoins, il est également indexé dans celui Site Search. Il crée donc déjà la forme, le style et l'ensemble spécifique de documents que nous devrions gérer avec un robot d'indexation. Nous avons la même chose côté Drupal : nous avons un module qui permet d'intégrer davantage de contenu à notre index de recherche sur site, au lieu de s'appuyer davantage sur les robots d'indexation. Je dirais que, dans l'ensemble, ce module est davantage basé sur les robots d'indexation – et pas seulement dans la recherche sur site, c'est vraiment important que pour la recherche gérée. Lorsque vous exécutez des opérations Solr classiques, il existe différentes méthodes d'intégration, notamment pour le contenu PDF. Il existe d'autres méthodes pour indexer et intégrer du contenu. Je vais laisser Karan nous en dire un peu plus, mais un bon exemple que nous observons actuellement est que de nombreux clients utilisaient le gestionnaire d'importation directe dans les versions précédentes de Solr. Dans les versions plus récentes, ils s'en éloignent pour une raison ou une autre. Il existe simplement différentes façons d'intégrer des éléments. Karan, au fait, que se passe-t-il avec ce gestionnaire d'importation directe ?

Karan

Oui, la communauté a décidé de ne plus maintenir ce module. Elle a donc converti le gestionnaire d'importation de données, qui était un module principal, en module contribué. Vous pouvez donc toujours l'utiliser. Cependant, il n'est pas maintenu par la communauté qui maintient Solr, mais par une autre communauté. Je suis presque sûr qu'il doit y avoir un chevauchement entre les deux. Mais il n'est plus maintenu par la communauté principale. Donc, si vous souhaitez continuer à l'utiliser, vous devez en assumer les risques, s'il y en a, et l'utiliser autrement. La communauté Apache Solr souhaite que les utilisateurs utilisent l'API d'ingestion, le point de terminaison de mise à jour, c'est-à-dire leur installateur. Ils ont donc beaucoup travaillé pour que l'API d'ingestion soit polyvalente et capable de gérer tout type de données. Comme je l'ai mentionné précédemment, ils souhaitent garantir la possibilité d'ingérer des données provenant de différentes sources et dans différents formats. Ils ont donc veillé à ce que ce processus devienne extrêmement simple et que les utilisateurs puissent progressivement abandonner le gestionnaire d'importation de données. C'est ce qui se passe. Si vous utilisez une méthode ancienne pour connecter Solr à vos données via un gestionnaire d'importation de données, vous pouvez toujours l'utiliser si vous le souhaitez. Mais il serait préférable de consacrer un peu de temps au développement et de migrer vers les API.

Jae 

Compris. C'est vraiment utile. Et merci pour le contexte, Pete. Je suis curieux de connaître non seulement le contexte du gestionnaire d'importation de données, mais j'ai aussi quelques questions. J'aimerais beaucoup entendre un exemple de ce que vous venez de décrire, Karan, où quelqu'un a pris la décision de le faire, en s'appuyant sur une ancienne méthodologie d'ingestion. Et puis un ou deux exemples, comme Pete a mentionné les PDF – juste pour développer ce dont il parlait, en rapport avec le fait qu'en général, c'est basé sur un robot d'indexation, et qu'il y a évidemment des connecteurs, des avantages et des inconvénients. Juste un peu de contexte pour approfondir certaines de ses affirmations, si vous avez des idées.

Karan 

Bien sûr. La raison principale de l'abandon du gestionnaire d'importation de données était la sécurité, car l'API d'ingestion est extrêmement sécurisée. Elle fonctionne sur le port 443 et bénéficie du chiffrement TLS 1.3, ce qui en fait un moyen très sécurisé d'ingestion de données. En revanche, il existait différents types de connecteurs, comme JDBC, pour se connecter à une base de données, à un flux RSS, etc. Tous fonctionnaient bien, mais n'étaient pas vraiment sécurisés. C'est pourquoi la communauté a décidé de les abandonner et de se concentrer uniquement sur l'API d'ingestion. C'est pourquoi, dans Site Search, nous nous concentrons uniquement sur l'API d'ingestion ; même nos robots d'exploration web utilisent des API d'ingestion. Nous utilisons notre propre produit, où nous utilisons notre robot d'exploration web pour récupérer les données, puis, lorsque nous les transférons vers Solr, nous utilisons les mêmes API d'ingestion que celles disponibles pour tous. Comme Pete l'a mentionné, les API d'ingestion sont extrêmement puissantes – « Un grand pouvoir implique de grandes responsabilités » – il suffit de s'assurer que les données envoyées sont cohérentes avec toutes les autres, car vous pouvez leur envoyer n'importe quelle donnée. Mais si vous envoyez des données depuis plusieurs sources, vous devez vous assurer qu'elles sont normalisées et uniformes pour toutes les sources utilisées. Ainsi, les données d'une base de données et de la seconde doivent avoir des champs similaires, afin de créer une expérience de recherche unifiée. Vous n'avez pas besoin de deux blobs de données distincts. Vous pouvez utiliser les API d'ingestion pour obtenir des données de n'importe où, en toute sécurité. Il vous suffit de vérifier que vos champs sont corrects, et le tour est joué.

Pete 

Oui, ça parle vraiment de… Jae, je sais que tu as discuté avec moi de la différence entre recherche fédérée et recherche unifiée. Et encore une fois, cela rejoint l'idée d'un index unifié sur lequel nous travaillons. Et même si vous avez tendance à fédérer vos résultats de recherche, avec cinq sites web externes différents et des systèmes différents, nous travaillons bel et bien avec un index unifié. Il est donc essentiel d'avoir un format de données et un ensemble de champs communs. Et cela rejoint tout ce dont nous avons parlé.

Jae 

C'est génial. L'un d'entre vous aurait-il une autre anecdote ou un exemple concret ? Quelqu'un est venu découvrir ce que nous pouvions faire pour lui faciliter la tâche. Il envisageait peut-être un projet d'envergure.

Karan 

En fait, cela s'est produit il y a deux semaines. Nous discutions avec l'un de nos clients et cherchions à optimiser l'utilisation de nos robots d'exploration pour récupérer les données. Nous procédions de la même manière qu'avec chaque client : nous veillons simplement à avoir accès à toutes les pages, à toutes les données et à toutes les métadonnées. Si un client constatait qu'il manquait de données de qualité accessibles publiquement, une grande partie de ses données se trouvait dans sa base de données, en arrière-plan. Ce client utilisait AEM – Adobe. Une grande partie de ses données se trouvait donc dans AEM. Lorsque les ingénieurs ont découvert l'API d'ingestion, ils ont immédiatement décidé de migrer vers une API d'ingestion, afin de contrôler totalement les données à envoyer à Site Search, leur format et les champs à inclure. Ils ne voulaient plus dépendre d'autre chose. Ils ont donc découvert l'API d'ingestion et, en un jour ou deux, ils ont complètement abandonné les robots d'exploration pour adopter les API d'ingestion. Et puis, après un jour ou deux, ils l'avaient déjà implémenté. Et en une semaine, c'était opérationnel.

Pete 

Et je dois dire que c'était intéressant, car nous nous attendions à ce qu'ils abandonnent les robots d'exploration et l'API d'ingestion lorsqu'ils ont pris la décision. Personnellement, je me suis dit : « Bon, cela signifie qu'ils vont probablement poser de nombreuses questions et que nous devrons peut-être les accompagner dans ce domaine. » Et ils nous ont répondu : « Ouais, c'est bon. Nous sommes déjà lancés, c'est prêt ; nous ne leur avons pratiquement fourni aucune assistance pour utiliser ces API d'ingestion. » Cela montre bien que nous utilisons le langage natif de Solr. Si vous connaissez Solr, vous connaissez nos API. C'était donc vraiment intéressant de voir ce déclic se produire, surtout pour une plateforme comme AEM, où nous n'avons pas encore un taux d'adoption élevé. Pour nous, c'est une plateforme relativement nouvelle. Donc, pouvoir voir à quel point c'était facile pour un client qui utilise AEM et notre produit de recherche de site, et ce partenaire ayant une idée aussi brillante du genre, hé, c'est facile, nous avons pu le faire - c'était magique à voir, je dois dire.

Jae 

J'imagine que c'est une anecdote vraiment intéressante. Et j'imagine que lorsque nous parlons des personnes impliquées dans ce processus – et vous parlez d'un déploiement Adobe, en particulier –, la taille du projet peut être complexe. Pouvez-vous nous en dire un peu plus sur les personnes impliquées dans ce processus ? Vous savez, tout le processus d'ingestion des données ? Et quel est le rôle de chaque équipe ? Nous collaborons aussi beaucoup avec des partenaires d'implémentation, bien sûr. Quel est leur rôle ? Quel est celui de SearchStax ? Aidez simplement nos téléspectateurs et auditeurs à comprendre comment cela fonctionne généralement, en commençant par Pete.

Pete 

Eh bien, tout commence par un rêve, Jae. Concernant les acteurs, tout dépend vraiment de la maturité de ceux qui dirigent les projets, et de leur implication dans le projet, qu'ils soient pilotés par le client ou par un partenaire. Pour revenir à cet exemple, et sans vouloir trop en dévoiler, il s'agissait d'un partenaire Site Search existant – ou plutôt, disons, d'un client Site Search existant sur une plateforme différente d'AEM. Nous venions de les intégrer à Site Search sur leur ancienne plateforme. Tout le monde applaudissait et se félicitait, car l'intégration était réussie, et ils étaient prêts à se lancer sur leur propre plateforme. Environ une semaine plus tard, ils sont revenus vers nous et nous ont dit : « On passe à AEM, on réécrit complètement notre système – on refait tout, on change de plateforme – et ça ne prend qu'un mois. » Et nous les avons regardés, comme pour dire : « OK, c'est parti ! » Et encore une fois, nous cherchions à déterminer le moyen le plus rapide d'y parvenir. Les acteurs impliqués… nous avions évidemment un excellent partenaire qui collaborait avec ce client. Ce client formidable avait adopté notre point de vue et notre produit et nous a dit : « C'est un excellent produit, nous voulons le transférer sur une autre plateforme. » Nous avons donc bénéficié d'une adhésion formidable de la part du partenaire et du client. Côté plateforme, même Adobe s'est impliqué et a été notre fervent défenseur. Cette excellente synergie entre la plateforme, l'équipe marketing et l'équipe technique a donc été essentielle pour un lancement aussi rapide et réussi, à mon avis, du moins en tant que superviseur sur certains aspects. C'était vraiment intéressant de voir – vous savez, Karan, d'un point de vue technique, vous pouvez probablement approfondir un peu la question, mais c'était intéressant de voir la contribution de tous ces acteurs.

Jae 

Oui, c'est vraiment agréable à entendre. Au fait, un objectif est un rêve avec une échéance, donc ce que vous dites n'est pas loin. Et puis, Karan, pourriez-vous nous donner un peu plus de contexte sur le fonctionnement quotidien ? Comment tout s'est-il déroulé ? Sans rien révéler d'important ni de sensible, mais les aspects importants étant plutôt du point de vue de ce dont nous avons parlé, qu'avez-vous pu éviter en termes de frictions, de chaos et de désorganisation du projet grâce à ce dont nous parlons ici ?

Karan 

Oui, non, vous savez quoi ? Dans tous les processus d'intégration auxquels j'ai participé, tout dépend du degré d'implication que le client attend réellement de nous. Car la plupart du temps, nous ne sommes jamais les freins. Comme nous n'avons pas vraiment d'implémentation, nous ne faisons rien ; nous installons juste un robot d'exploration, et c'est parti. La configuration des environnements ne prend qu'une journée. Et nous pouvons en configurer autant que vous le souhaitez. Et nous ne sommes jamais vraiment les freins. C'était également le cas avec ce client : comme Pete l'a mentionné, il y avait une excellente synergie entre le partenaire d'implémentation et la plateforme. Dès qu'ils ont découvert l'API d'ingestion, ils ont tous su que c'était la voie à suivre. Il n'y a eu aucun obstacle, aucun blocage, aucune objection, et tout le monde s'est aligné sur cette API d'ingestion, s'est concentré sur le sujet et, en quelques jours, a réussi son coup. Nous rencontrons parfois des clients qui ne sont pas compatibles, ou qui n'ont même pas l'expertise technique nécessaire. Dans ce cas, ils nous confient la prise de décision. S'ils n'ont pas vraiment d'expertise technique, nous leur demandons souvent d'utiliser des robots d'exploration, car c'est une approche totalement autonome. Ils n'ont qu'à se concentrer sur la création d'un site web et l'ajout de contenu. Tout le reste est géré par les balises de recherche, où notre robot d'exploration récupère les données et les aide à créer une expérience de recherche agréable. En résumé, notre niveau d'implication dépend entièrement du client, de l'accompagnement qu'il souhaite, du traitement haut de gamme qu'il recherche et de son expertise technique. Je me souviens qu'un client cherchait à tester Solr. Je crois que quelqu'un en a lancé un. Nous l'avons contacté pour lui demander comment il allait utiliser Solr et s'il avait besoin d'aide. Il nous a répondu : « Non, je sais déjà faire de la recherche vectorielle dense. Je vais utiliser Solr. » Et sans notre aide, il a implémenté la recherche sémantique sur Solr. Nous avons des clients comme eux, très techniques. Certains ont déjà testé Learning to Rank sans notre intervention, et ils comptent deux ou trois ingénieurs Solr dans leurs équipes. Notre implication dépend donc entièrement de l'expertise technique de chaque client. Nous pouvons être aussi présents que vous le souhaitez, ou aussi discrets que vous le souhaitez.

Jae 

C'est génial. C'était une conversation vraiment très enrichissante. Je vous remercie tous les deux. Un dernier mot, juste pour aider les gens à comprendre les bases ? Nous allons continuer ce type de contenu pour aborder certains des connecteurs dont Pete a parlé, et d'autres sujets. Mais avez-vous d'autres commentaires à formuler ? Karan, on peut commencer par vous.

Karan 

Oh, pour conclure, l'ingestion de données est difficile. Et c'est intimidant. Je le dis simplement. Ne vous inquiétez pas. C'est difficile pour tout le monde. On en parlera. On trouvera une solution.

Pete 

 Je pense que cela m'amène à mes dernières réflexions. En fait, il s'agit de gérer les attentes et de savoir qu'il y aura probablement du travail à faire de votre côté. Et bien sûr, cela ne concerne pas seulement l'intégration. On ne parle ici que d'intégration, n'est-ce pas ? Mais même du côté de la mise en œuvre, vous aurez des clients qui auront du travail à faire pour implémenter la recherche sur site et obtenir l'apparence souhaitée sur leur site, etc. Il faut donc savoir à l'avance, connaître les attentes et définir les attentes appropriées : l'intégration est complexe. Cela peut demander du travail préparatoire, il faut comprendre son contenu. Et si vous ne maîtrisez pas bien le sujet, notamment pour le visuel – pour les nouveaux marketeurs numériques, qui débutent peut-être dans leur entreprise et qui doivent comprendre leur site –, assurez-vous que nous ayons des personnes qui comprennent le contenu lors de notre processus d'intégration, car cela nous facilitera grandement la tâche.

Jae 

Génial. Merci à vous deux. C'était vraiment génial. J'ai hâte de participer à d'autres séances de ce genre.