Moteurs de recherche : faites la chasse aux requêtes sans réponse ! [3/3]

Dernier billet de notre série consacrée aux bonnes pratiques pour réduire au maximum les  recherches sans réponse : nous allons voir qu’il est possible d’être moins strict dans les combinaisons de mots-clés et aussi de mettre en place des rebonds vers du contenu pertinent  en cas de requête vraiment sans réponse.

3. Requête trop précise – Recherche optionnelle

Parfois, la requête ne donne pas de résultats parce qu’elle contient de nombreux mots-clés dont la combinaison contraint fortement les résultats.

Il est utile, dans ces cas là, de proposer une recherche optionnelle où tous les mots-clés ne sont pas obligatoires : le moteur de recherche utilise alors un opérateur OU au lieu de ET entre les différents mots de la requête. Le mécanisme de pertinence fait en sorte que les documents contenant le maximum de mots-clés parmi ceux cherchés soient proposés en priorité.

Le CSA propose un mode de recherche optionnel sur son site web. En l’absence de rapport 2014, la recherche «Rapport annuel 2014 » propose des rapports plus anciens.

3.1.ScreenshotCSACliquer pour agrandir l’image

Compte tenu du bruit potentiel que la recherche optionnelle peut engendrer, il est tout de même recommandé de commencer par une requête classique et, en cas de non réponse seulement, d’exécuter une requête optionnelle en informant l’utilisateur du fait que l’on a élargi sa recherche.

4. Contenus non indexés

Parfois, vos utilisateurs cherchent des informations que vous n’avez pas indexées dans le moteur de recherche, comme par exemple l’adresse ou numéro de téléphone du service client.

Dans ce cas, il est utile de prévoir un comportement approprié du moteur de recherche qui pourra rediriger l’utilisateur vers la page concernée de votre site web. Il suffit pour cela d’intercepter un certain nombre de mots -clés pour gérer une redirection vers une page particulière, au lieu de laisser le moteur exécuter sa recherche.

Malheureusement dans certains cas, l’utilisateur cherche vraiment un contenu que vous n’avez pas. Pour autant, même dans ces cas là il ne faut pas négliger votre page de réponse.

Voici quelques éléments que vous pouvez fournir et qui peuvent aider l’utilisateur à rebondir vers d’autres contenus :

  1.  Proposer l’aide d’un conseiller :
    ssrep-assistanceCliquer pour agrandir l’image
  2. Proposer la liste des contenus les plus consultés
  3. Proposer un hit-parade des requêtes les plus fréquentes :ssrep-hitparadeCliquer pour agrandir l’image
  4. Proposer une liste éditorialisée de contenus, par  exemple les meilleures ventes pour un site marchand :ssrep-meilleuresventesCliquer pour agrandir l’image

Les exemples ci-dessus proviennent du site Oreca Store, spécialisé dans le sport automobile et où, bien que le catalogue soit extrêmement riche, on ne trouve pas de « table basse en chêne » 😉

Dans tous les cas, améliorer la pertinence de votre moteur de recherche et optimiser ses réponses est un processus continu. Une analyse régulière de vos requêtes sans réponse vous permettra d’enrichir vos dictionnaires, d’identifier les cas qui posent régulièrement problème, et de mettre en place les fonctionnalités adéquates.

Il n’est pas nécessaire d’y passer beaucoup de temps, et cela paye vraiment : 10 minutes par semaine sont largement suffisants, et vous constaterez aussitôt une amélioration réelle !

N’hésitez pas à nous faire part, en commentaire, de vos propres astuces pour satisfaire au mieux les requêtes de vos clients, ou si vous avez déjà rencontré un cas d’usage non couvert dans ces billets !

Moteurs de recherche : faites la chasse aux requêtes sans réponse ! [2/3]

Nous avons vu dans un précédent billet comment traiter automatiquement les erreurs de saisie et fautes de frappe.

Examinons maintenant un autre cas de figure :

2. Les requêtes utilisant un vocabulaire différent du vôtre

Dans ce cas l’utilisateur ne s’est pas trompé dans sa requête, mais a utilisé un vocabulaire qui n’est pas celui de vos documents ou fiches produits. Plusieurs scenarii sont possibles :

a. L’utilisation de synonymes ou abréviations

Les utilisateurs peuvent utiliser des mots différents de ceux de vos fiches, pourtant ils désignent la même chose : « gratte » au lieu de « guitare » pour un musicien de rock, « voiture » ou même « bagnole » pour « automobile », « loi Aubry » ou « loi des 35 heures » pour « loi n° 98-461 ».

Une solution basique serait de surcharger manuellement vos documents avec les différentes formes possibles des mots utilisés : cela fonctionnerait, mais c’est loin d’être la solution optimale.

Utilisez plutôt un dictionnaire de synonymes. Démarrez avec une simple liste à plat de mots ou d’expressions et listez les synonymes métier, les abréviations fréquemment employées… Ces équivalences seront appliquées automatiquement par le moteur de recherche pour optimiser la réponse à vos utilisateurs.

Chez Decathlon le terme « hula-hoop » désigne aussi un « cerceau » :

2.1.ScreenshotDecathlonCliquer pour agrandir l’image

Vous n’avez pas besoin de constituer la liste d’une seule traite, commencez par une première base, que vous enrichirez au fur et à mesure.

 

b. L’utilisation de concepts parents

Vos utilisateurs peuvent parfois utiliser des termes plus larges que ceux très spécifiques utilisés dans vos contenus. Mais on ne peut pas parler de synonymes au sens strict. Un utilisateur peut par exemple chercher « voiture » là où vos documents mentionnent des « cabriolets », ou encore chercher « sport de raquette » quand vos documents évoquent spécifiquement le « tennis », le « badminton » ou le « ping pong ».

Dans ce cas là, il est préférable de passer par un dictionnaire de concepts hiérarchisé, ou thesaurus.

A la différence de la liste de synonymes mentionnée plus haut, le thesaurus sert à organiser des termes de manière hiérarchique avec plusieurs niveaux d’information. On parle dans ce cas de concepts parents ou enfants.

Les moteurs de recherche utilisent ces dictionnaires pour répondre de manière précise à des requêtes larges ou floues, mais en aucun cas ils ne doivent répondre de manière générique à une requête très précise : il faut en effet prendre comme hypothèse que l’utilisateur qui cherche un terme très précis souhaite justement obtenir un contenu adapté.

Sur le site « Croquons la vie » de Nestlé, les « snacks » désignent les « burgers » , « tartines » et « croque-monsieur » :

2.2.ScreenshotNestléCliquer pour agrandir l’image

Les moteurs de recherche de dernière génération savent prendre en compte les niveaux de hiérarchie dans le classement par pertinence de leurs résultats.

Ainsi un moteur de recherche efficace, comme Antidot Finder Suite, va d’abord proposer des fiches qui contiennent exactement le mot recherché avant de proposer d’autres fiches qui contiennent des concepts enfants.

c. Compréhension du langage naturel

Dans d’autres cas les utilisateurs vont, en plus des mots clés significatifs, utiliser des expressions pour mieux qualifier leurs requêtes : « Inférieur à un certain prix », « Postérieur à une certaine date »… et se retrouvent sans réponse alors que avez du contenu adapté.

Prenons l’exemple suivant d’un site de e-commerce: si un visiteur saisit « Chaussures à moins de 100 euros« , cette requête risque de ne pas donner de résultats parce qu’il n’y a probablement pas de fiches de chaussures contenant « à moins de ». Et elle ne proposera pas des chaussures à 50 euros, parce que leur fiche ne contient pas « 100 ».

Il est facile pour nous humains, dotés d’un cerveau très puissant, d’interpréter la recherche et de se rendre compte qu’en fait la recherche porte simplement sur des chaussures, avec un filtre sur leur prix. Mais c’est bien plus compliqué lorsqu’il s’agit de l’expliquer au moteur de recherche !

Il existe donc, pour gérer ce genre de cas, des modules de réécriture qui servent à identifier certaines formes de requêtes et à les transmettre au moteur de recherche avec la syntaxe qu’il sait gérer au mieux.

Dans notre cas, l’expression « à moins de 100 euros » se retrouve réécrite en filtre : « prix < 100 », permettant ainsi au moteur de trouver les résultats pertinents.

 

d. Information existante mais pas sous forme de mots-clés

Dans certains cas, l’information recherchée est présente dans vos contenus, mais pas sous forme de plein texte.

Dans un catalogue de produits alimentaires par exemple, des clients peuvent rechercher le mot-clé « bio ». Mais si l’information n’existe que sous forme de case à cocher Oui / Non dans le catalogue, le moteur ne va pas retrouver le mot-clé en tant que tel dans les fiches des produits.

Le client n’aura donc pas de résultats alors qu’il existe de nombreux produits susceptibles de l’intéresser.

Dans ce cas, un traitement est à prévoir en amont. Il faut prévoir des mécanismes d’enrichissement de vos contenus qui ajoutent les mots-clés nécessaires à vos fiches avant leur indexation. Ces traitements peuvent directement être pris en charge par le moteur de recherche.

Nous verrons la semaine prochaine comment traiter les cas de requêtes sans réponse qui subsisteraient encore après mise en oeuvre des bonnes pratiques que nous vous avons présentées.

 

Moteurs de recherche : faites la chasse aux requêtes sans réponse ! [1/3]

L’objectif premier d’un moteur de recherche est de répondre de manière juste et précise aux requêtes de ses utilisateurs, en leur apportant les documents les plus pertinents.

Les requêtes sans réponses sont très déceptives et peuvent dans certains cas détourner les utilisateurs de votre site. Toutefois, ces requêtes infructueuses ne sont pas une fatalité, et voici quelques conseils pour optimiser vos réponses afin d’augmenter la satisfaction de vos utilisateurs !

Il existe plusieurs types de requêtes sans réponse qui concernent pourtant des documents/produits que vous proposez :

1. Les requêtes avec fautes d’orthographe

Elles constituent une grande partie des requêtes sans réponses. L’utilisation d’un module de correction orthographique s’avère donc incontournable.

Les correcteurs orthographiques de pointe ne se basent pas sur des dictionnaires mais sur une analyse statistique de vos contenus. Ils sont ainsi capables de suggérer des corrections de noms propres, abréviations et autres néologismes en prenant en compte ce qui se trouve vraiment dans vos documents ou fiches produits.

Vous pouvez soit proposer une correction à vos utilisateurs, soit exécuter automatiquement la recherche avec le mot corrigé.

Voici un exemple avec le Conseil Supérieur de l’Audiovisuel, dont le moteur de recherche Antidot Finder Suite suggère la correction orthographique du nom de son président Olivier Schrameck en laissant le visiteur relancer sa requête :

1.1.ScreenshotCSACliquer pour agrandir l’image

Autre exemple avec  Damart : notre moteur de searchandising  AFS@Store a été paramétré pour corriger la faute d’orthographe et relancer automatiquement la recherche :

1.2.ScreenshotDamartCliquer pour agrandir l’image

Dans les deux cas, n’oubliez pas de mentionner la requête originale ainsi que la requête corrigée, pour mieux informer vos utilisateurs.

Un autre moyen d’éviter les requêtes sans réponses dues à des fautes d’orthographe est l’usage d’un module d’auto-complétion tolérant aux fautes d’orthographe. L’utilisateur se voit proposer des suggestions de recherche dès les premières lettres saisies, et s’il en sélectionne une, sa requête sera naturellement bien formulée.

Avec l’auto-complétion de Cultura, qui utilise aussi AFS@Store, peu de chances que l’utilisateur se trompe en cherchant Michel Houellebecq :

1.3.ScreenshotCulturaCliquer pour agrandir l’image

Les suggestions d’auto-complétion peuvent être éditorialisées, elles vous permettront de mettre en valeur certaines requêtes, et donc de promouvoir les documents ou produits associés. C’est donc une solution doublement utile !

Nous verrons dans un prochain billet un autre cas de figure : comment trouver des résultats à une recherche pour laquelle l’utilisateur emploie des mots spécifiques qui ne figurent pas parmi les documents indexés…

À suivre la semaine prochaine !

 

Allons au musée en train

Troisième épisode de notre feuilleton « Enrichir des données avec Antidot Information Factory » : après avoir transformé un fichier Excel en une application de recherche, puis intégré des photos librement disponibles sur le web, nous allons maintenant ajouter une information supplémentaire pour chacun de nos musées : la gare SNCF la plus proche.

Et ce qu’il y a de bien avec l’Open Data, c’est qu’on y trouve pléthore d’informations bien utiles. Ainsi, la liste des gares de la SNCF est disponible, tout comme celle des aéroports et des stations de métro (mais pas encore pour toutes les villes…). Pour notre exemple, nous nous focaliserons uniquement sur les gares.

De la même façon que pour la liste des musées de France, les gares ont leur fichier Excel sur data.gouv.fr. Une différence importante : ce fichier contient déjà les coordonnées de géolocalisation de chaque gare :

excel_railstations

Reste à rapprocher ces lignes Excel de nos musées. L’idéal serait d’avoir un web service répondant aux requêtes telles que « Quelle est la gare la plus proche de ce point (X,Y) ? ». On y enverrait les coordonnées du musée obtenues par l’enrichissement géographique et on aurait ainsi la gare recherchée.

Un fichier Excel n’est pas un web service, bien entendu, mais heureusement nous pouvons le créer assez facilement. En effet, un service de recherche tel que celui des musées peut être vu différemment que l’on soit un être humain (via une appli web ou mobile) ou une machine (via un web service). Le moteur de recherche AFS répond en effet aux requêtes reçues dans les formats techniques tels que XML et JSON qui sont les standards d’interopérabilité applicative sur le web.

Ainsi, le fichier Excel des gares de France devient un service de recherche géolocalisé en suivant les mêmes étapes que pour les musées :

railstation_paf_chain

 

  • transformation XML du fichier Excel

 

  • séparation de chaque ligne

 

  • indexation géolocalisée

 

  • déploiement

 

 

 

Une fois ce service de recherche de gare déployé, nous allons l’utiliser dans la chaine de traitement des musées pour obtenir la gare la plus proche. Pour cela, on réutilise le module d’appel de web service en se basant sur les paramètres d’appel d’un service de recherche AFS.

Ainsi, une requête telle que :

/search?afs:service=2013&afs:feed=RailroadFR
&afs:filter=geo:dist(45.76,4.86)<10000
&afs:sort=geo:dist(45.76,4.86),ASC

renvoit un flux XML des gares SNCF situées à moins de 10 km du point (45.76, 4.86), triées par distance croissante avec ce point.

Nous pouvons alors utiliser ce service de recherche comme un web service pour trouver la gare la plus proche de chaque musée.

Pour cela, nous rajoutons un nouveau module de requête web service à la chaine de traitement sur les données des musées :

paf_chain

Il se paramètre ainsi, toujours dans le Back Office d’Antidot Information Factory :

railstation_filter_param

Il suffit alors de relancer la chaine de traitement et le tour est joué : dans la fiche signalétique de chaque musée apparaît la gare la plus proche :

web_museum_3

Cela semble un peu magique, non ?

Allons plus loin dans l’enrichissement de données avec Antidot Information Factory

Nous avons vu précédemment qu’avec la version 7.6 de nos outils, la création de chaînes de traitement de données était extrêmement simple : il est possible de réaliser une application web de recherche de musées en quelques minutes. Pour autant, nos clients utilisent Antidot Information Factory dans des projets où les chaines de traitement sont plus beaucoup plus complexes.

Afin de montrer comment AIF répond aussi à des besoins plus avancés, nous allons donc améliorer notre application « Musées de France » en enrichissant les données initiales. Nous avons retenu trois enrichissements :

  1. trouver des photos sur un site de photos en ligne (Flickr ou Wikimedia par exemple)
  2. trouver les gares SNCF les plus proches de chaque musée
  3. ajouter un contenu textuel présentant chaque musée

Des photos !

Le premier enrichissement a pour objectif de montrer qu’AIF est très à l’aise avec des données multimédia. Nous y introduirons également l’organisation des données dans chaque « objet document », que nous avions passée sous silence dans le précédent billet.

Flickr.com possède des API accessibles en web services, tout comme Google Maps. En utilisant le même module d’interrogation d’un web service, nous allons obtenir une liste de photos associées à chaque musée. Nous utiliserons ensuite un module de téléchargement qui récupérera les 3 premières photos renvoyées par Flickr.

N.B. : Les photos renvoyées par Flickr ne sont pas forcément des photos du musée en question, il peut s’agir de photos prises à proximité du musée. Nous accepterons cette simplification pour l’exemple.

Organisons nos données

Vous vous souvenez que notre base de données des musées de France était, à l’origine, un tableau Excel. Comment associe-t-on des photos à une ligne Excel ?

C’est ce que nous allons faire facilement, car Information Factory se fonde sur un modèle de données riche et organisé. Chaque ressource manipulée – ici une ligne Excel désignant un musée de France – est une mini base de données. Avec AIF, nous allons ranger les informations manipulées dans des couches de données bien identifiées, chaque couche ayant un rôle bien défini.

DocUnit-Layers-sections

La couche principale se nomme « Contents » et elle contient la transformation XML de la ligne Excel décrivant le musée.

Layer-Contents

Certaines couches ont des libellés spécifiques car elles sont destinées à des usages particuliers. D’autres sont à la disposition du créateur de la chaine de traitement.

Ainsi, les résultats de géolocalisation seront placés dans une couche de données nommée « USER_1 » :

Layer-Geo

Dans notre exemple, nous allons ranger les résultats de la recherche d’images Flickr dans « USER_2 » et nous conserverons les liens vers les 3 premières photos dans « USER_3 » :

Layer-Flickr  →  Layer-URLs

Enfin, nous rangerons ensuite les photos elles-mêmes dans les couches « USER_4 » à « USER_6 » :

Layer-Photos

Utilisons Flickr via son API

Pour faire cela, de la même façon que l’on avait appelé le web service de Google Maps, appelons celui de Flickr en lui passant en paramètre la latitude et la longitude de chaque musée :

Appel Flickr

Nous récupérons alors le contenu des ces images, sous forme de fichiers au format JPEG, que nous stockons directement dans des couches de notre objet Musée. En effet, la solution Antidot Information Factory intègre un composant de stockage NoSQL appelé Content Repository. Grâce à lui, les photos seront directement accessibles via des web services pour toute application qui en aurait besoin. C’est ainsi que le widget d’affichage d’un objet musée sur l’application web pourra présenter les 3 photos.

Voilà, nos fiches présentant les musées sont désormais illustrés de photos !

 

Nous verrons dans le prochain billet comment indiquer, pour chaque musée, quelle sont les gares SNCF les plus proches…

Comment enrichir des données en quelques clics ?

En termes simples, Antidot Information Factory est une usine pour assembler et faire tourner des chaînes de traitement de l’information. Un des points forts d’AIF réside dans le fait que ces chaînes sont modulables à souhait, ce qui garantit qu’elles pourront toujours être adaptées à la structure des contenus à traiter. Elles permettent de se concentrer sur ce que l’on veut obtenir des données initiales, d’un point de vue fonctionnel, en faisant abstraction de la complexité technique sous-jacente et sans avoir besoin de programmer quoi que ce soit.

Il nous a donc paru important que le moyen d’assembler et de maintenir de ces chaînes de traitement ne soit pas un obstacle à la créativité. C’est pourquoi nous proposons, avec la version 7.6 d’Antidot Information Factory, un éditeur de chaînes de traitement. Intégré au Back-Office Antidot, cet outil visuel en mode web permet de créer une chaine de traitement en quelques clics, en définissant simplement ce que l’on souhaite faire des données dont on dispose.

Réutiliser des données ouvertes

Prenons un exemple dans le domaine de l’Open Data, et imaginons que je veuille créer un service de découverte des musées français. Pour cela, je veux

  • télécharger la liste des musées de France sur le portail officiel data.gouv.fr, où cette ressource est disponible au format Excel
  • m’abstraire du format Excel pour pouvoir enrichir les données
  • créer un objet de contenu spécifique pour chaque musée
  • géocoder chacun de ces objets pour pouvoir les placer sur une carte
  • indexer ces données enrichies dans un moteur de recherche sémantique comme AFS
  • déployer l’application de recherche ainsi créée sur le cloud Antidot

Assembler simplement des modules de traitement

Cette suite d’actions est très facile à réaliser avec AIF, car ses 6 étapes se configurent aisément dans le Back Office Antidot, en piochant dans le catalogue des modules AIF prêts à l’emploi.

Cliquez sur rouedentee pour voir cette démonstration en haute définition.

En effet, AIF intègre plus de 60 modules catégorisés par usage :

  • connexion aux sources
  • transformation de format
  • enrichissement
  • appel à des web services externes
  • etc.

Résultat : notre application web « Musées de France »

C’est sur ce principe que notre application « Monuments Historiques » avait été réalisée l’an dernier, et c’est avec Antidot Information Factory que des clients comme Isidore, le MuCEM… travaillent désormais leurs données.

Et, grâce à AIF et à notre moteur de recherche AFS, vous profitez maintenant de notre application de découverte des musées de France, que vous pouvez même utiliser en vacances sur votre smartphone ou tablette !

Home Musées

 

Ceci n’est qu’une première étape, qui avait pour objectif de vous montrer à quel point Antidot Information Factory est simple à mettre en œuvre.

À suivre !

Dans nos prochains billets, nous vous montrerons comment AIF permet d’aller beaucoup plus loin, avec des chaînes de traitement plus puissantes… et toujours aussi faciles à assembler !

Le moteur de recherche comme socle d’applications mobiles simples et efficaces

Les fonctionnalités avancées d’un moteur de recherche moderne comme Antidot Finder Suite en font un outil logiciel particulièrement bien adapté pour servir de base à la réalisation d’une application mobile pour smartphones et tablettes conjuguant ergonomie et efficacité. Comme de surcroît AFS utilise de façon optimisée les standards du web,  il garantit la performance de votre application ou site mobile, même quand les débits réseau ne sont pas  les meilleurs.

Avec le développement du m-commerce, AFS@Store, la déclinaison pour sites marchands de notre moteur de recherche, apporte une importante valeur ajoutée pour la réalisation d’applications e-commerce mobiles incluant la recherche simplifiée dans un catalogue de produits et, le cas échéant, la recherche géolocalisée de magasins d’une enseigne. Du coup, l’application mobile contribue à générer du trafic dans les points de vente !

Recherche géographique et géopositionnement des résultats

Notre moteur de recherche AFS est très fort en géographie : il trouve des objets se situant dans une zone donnée, par exemple à une certaine distance de l’utilisateur qui active la géolocalisation de son smartphone ou de sa tablette. Lorsque beaucoup de résultats correspondent à une requête, AFS les regroupe intelligemment par zone pour vous aider à affiner la recherche. Et, de façon complémentaire, la solution AIF enrichit vos données en positionnant un élément sur une carte à partir de son adresse.

Voici un exemple parmi d’autres, chez notre client Jules, où la saisie d’un nom de ville dans la boîte de recherche du site affiche les boutiques correspondantes sur un fond de carte :

Recherche géo Jules

Aide à la saisie intelligente : suggestions automatiques et tolérance orthographique

Bien que les smartphones et tablettes intègrent un clavier tactile intelligent, la saisie des mots clés faisant l’objet d’une recherche peut encore être simplifiée par AFS : en effet, dès la saisie des premières lettres dans la boîte de recherche, AFS suggère des requêtes ciblées pour obtenir des réponses immédiatement pertinentes. Ces suggestions sont totalement paramétrables : vocabulaires issus de thésaurus, noms de marques et références de produits, mots les plus cherchés par les autres internautes…  Elles permettent à un utilisateur mobile d’être orienté très rapidement vers l’information qu’il cherche.

Tolérant aux fautes de frappe, AFS trouve ce qui est mal écrit et suggère l’orthographe donnant les bons résultats. Cette tolérance est particulièrement utile pour les marques, noms de produits, de personnes, de lieux etc : Kandinsky, Schwarzenegger, Houellebecq, Kellogg’s ou Niedermorschwihr (un village alsacien) n’ont pas de secret pour son algorithme de tolérance orthographique !

Voici un premier exemple concret chez Delhaize Direct, le supermarché en ligne du leader belge de la distribution alimentaire : un consommateur qui cherche « Kelogs » se voit automatiquement suggérer les produits de la marque « Kellogg’s »

Kelloggs

Autre exemple chez notre client Newpharma, leader belge de la pharmacie en ligne, qui vend des médicaments dons les noms sont parfois compliqués à écrire, comme ici avec « excedryn » que l’internaute peut trouver en tapant « exedrin » :

Newpharma Excedryn

Intégration aisée et optimisation des flux de données

Pour une intégration simple dans un site ou une application mobile, AFS est intégralement basé sur des standards : interrogation en web services REST et réponse via des flux XML ou JSON. Ces flux sont optimisés pour minimiser le trafic entre l’application et le serveur, afin de garantir une bonne qualité de fonctionnement même avec une connexion data mobile de qualité moyenne.Car il n’y a pas encore de 4G partout, loin de là, et même dans les grandes métropoles le débit en 3G est parfois fluctuant…

Avec son kit de widgets graphiques au standard HTML / CSS et totalement personnalisables, Antidot Finder Suite vous permet de construire très simplement l’interface de votre SBA – Search Based Application – et d’intégrer une puissante fonction de recherche  dans toute application mobile pour smartphone ou tablette.

Les avantages d’Antidot Finder Suite pour le développement d’applications mobiles sont concrètement illustrés par ces exemples de réalisations chez nos clients, que nous vous invitons à découvrir :

 Application mobile But Application mobile Cityvox Application mobile Decathlon Application mobile Delhaize

La semaine prochaine sur Documation

Antidot présente la nouvelle version de sa solution AFS@Enterprise.

Votre SI est une mine d’informations inexploitées. AFS@Enterprise en extrait toute la valeur !

Pour améliorer la performance de votre entreprise, les métiers demandent une information toujours plus riche, plus pertinente et plus opérationnelle.

Répondez à cette attente en apportant les nouveaux objets métiers contextuels à leurs besoins :

  • pour le marketing et les ventes, agréger les données des réseaux sociaux avec celles de la CRM
  • pour les RH, cartographier le réseau des compétences et des collaborateurs
  • pour le support client, consolider les bases de connaissances sur les produits
  • et pour vous ? Quelles seraient les informations utiles à votre équipe ?

 

AFS@Enterprise est la première solution industrielle qui vous apporte la révolution du Linked Enterprise Data.

Le Linked Enterprise Data (LED) est une approche innovante qui facilite la réutilisation des données et documents dispersés dans les différents silos de l’entreprise. Le LED met en cohérence et lie ces données éparses, quels que soient leur format et leur structure, dans un entrepôt unifié, agile et évolutif. Il fait émerger l’information enfouie dans les fichiers et les bases de données : l’utilisateur accède directement à une information métier pertinente et utile !

 

Venez découvrir la puissance du Linked Enterprise Data et les fonctionnalités d’AFS@Enterprise sur notre stand E16.

Vous pouvez également assister à la table ronde à laquelle participe Fabrice Lacroix mercredi 21 mars 2012 de 14:30 à 17:00 sur le thème « Agrégation et réconciliation des données » ainsi qu’à notre présentation jeudi 22 Mars 2012 de 11:30 à 12:15 sur « Le Linked Enterprise Data, une révolution annoncée dans les Systèmes d’information des entreprises. Exemples notamment chez un grand industriel« 

C’est parti pour les soldes 2012 !

Ça y est, les soldes d’hiver ont débuté ce matin ! Pas chez Antidot 😉 mais chez une partie de nos clients, qui sont des sites de e-commerce et qui vivent à partir d’aujourd’hui une période cruciale pour leur activité.

Les soldes démarrent très fort sur Internet comme dans les magasins, et cela impacte évidemment notre plateforme SaaS qui se trouve fortement sollicitée.

Illustration concrète fournie par le back-office d’AFS@Store :

Trafic sur AFS@Store le permier jour des soldes 2012Cliquer pour agrandir l’image

Le trafic sur le moteur de recherche de ce site marchand est multiplié par 6 comparativement à un jour ordinaire !

Mise à jour du jeudi 12 janvier – les statistiques par jour montrent cette énorme accroissement de trafic :

Le premier jour des soldes : 5 à 6 fois plus de trafic que les jours précédentsCliquer pour agrandir l’image

Mise à jour du lundi 23 janvier – près de 2 semaines après le début des soldes, le trafic reste supérieur à la normale :

Cliquer pour agrandir l’image

C’est en pareille circonstance qu’il est intéressant de profiter d’une plateforme mutualisée et hautement sécurisée, capable d’absorber sans difficultés de très forts pics de charge.

Si vous désirez en savoir plus sur ce que nous pouvons faire pour améliorer l’efficacité de votre site marchand, n’hésitez pas à nous contacter. Vous pouvez aussi télécharger la plaquette AFS@Store et consulter cette présentation :

 Plus de présentations d’Antidot