Dans un récent article sur la question du moteur de recherche de votre projet web, nous disions :
C’est vrai, mais alors pourquoi un tel engouement pour Algolia, ce Search as a Service ?
La solution fonctionne et elle est tarifée de manière raisonnable et contrôlée, mais cela n’explique pas tout. Alors pourquoi ?
Il y a essentiellement deux raisons à ce succès.
La première est une approche pragmatique du projet. L’association d’un coût maîtrisé et raisonnable à un délai de mise en route réduit est tout à fait à même de vous convaincre d'adopter un Search as a Service comme Algolia.
Le coût qui va de trente-cinq à quelques milliers de dollars par mois est directement lié aux dimensions du projet : volume des données et nombre d’opérations d’indexation.
Comme c’est une solution Search as a Service, le coût comprend l’hébergement et l’infogérance de l’ensemble.
La seconde se rapporte à l’expérience utilisateur (UX), tant supportée ces dernières années, à juste titre.
On ne le dira jamais assez, l’expérience utilisateur est un facteur fort de la réussite d’un projet. Un utilisateur déçu ou frustré… renonce. Vous voulez savoir quelles recherches mener pour mieux comprendre vos utilisateurs ? Lisez notre article sur la question !
C’est pourquoi la conception centrée sur l’utilisateur est devenue une règle métier pour les projets web, en particulier lorsque le projet s’adresse au client final, et pas seulement en B2C.
Processus de conception centrée sur l’utilisateur
Dans ce domaine, le SaaS Algolia apporte deux points très intéressants.
Tout d’abord, la recherche instantanée (instant search) permet d’afficher et mettre à jour les résultats de la recherche au fur et à mesure de sa saisie, dès le premier caractère.
Comme le fonctionnement de Google me direz-vous ?
Certes, mais Algolia s’appuie sur les documents et les indexes qu’on lui a défini. Google Custom Search permet une démarche dans le même esprit mais avec beaucoup moins de contrôle, et donc moins de pertinence.
C’est cette fonction qui (a) fait le succès du SaaS Algolia.
Le second point est plutôt destiné aux développeurs, les librairies d’interface utilisateurs pour la recherche (Search UI). Au-delà du fait qu’elles existent et qu’elles sont complètes et efficaces, le Search as a Service Algolia les accompagnent d’une documentation détaillée et de guides pour leur mise en œuvre. C’est un véritable atout pour l’obtention d’interfaces ergonomiques et solides.
Que ce soit pour la mise en place de facettes, d’autocomplétion ou de la mise en œuvre de la recherche instantanée, chaque possibilité ou combinaison est documentée.
En bonus, on ajoute une interface d’administration et de suivi statistique bien construite qui permet de surveiller et contrôler la fonction recherche d’un projet avec précision.
Alors pourquoi diable ne pas choisir Algolia sans réfléchir davantage ?
Parce que ce n’est jamais bon de ne pas réfléchir !
Mais surtout, parce que la solution Algolia a – elle aussi – ses défauts et ses limites. Le défaut principal de la solution est lié au mode SaaS.
C’est une solution propriétaire et unifiée pour l’ensemble des clients. La première conséquence est que la solution est inexploitable en environnement fermé (pour certains intranets par exemple) ou sécurisé pour raison légale.
La seconde conséquence est que le réglage fin de la solution (tuning) et le développement de solutions spécifiques sont limités.
Ensuite, la solution a aussi quelques défauts, par exemple la synchronisation d’URL qui ne permet pas la transmission de paramètres autres que ceux d’Algolia ou la gestion de certaines fonctions utilisateurs qui associées à la pertinence nécessitent chacune un index. Nul doute que le Search as a Service Algolia corrigera ces défauts dans le futur, mais quand ?
Enfin, si les solutions SaaS ont l’avantage d’inclure l’infogérance, elles ont l’inconvénient d’inscrire vos projets dans les évolutions du produit, qu’elles leur conviennent ou pas.
Certes, les solutions plus classiques comme ElasticSearch ou Solr peuvent évoluer dans une direction qui ne convienne pas, mais la version que vous avez mise en œuvre restera supportée au moins durant le temps qui vous sera nécessaire pour vous retourner. Vous voulez savoir quelle solution choisir entre ElasticSearch et Solr ? C'est par là !
Cela dit, les solutions SaaS ont de plus en plus de succès et le rachat de Swiftype par Elastic en novembre dernier ne le dément pas.
Algolia n’est pas la seule offre du marché des solutions SaaS pour la recherche. Nous avons souhaité faire un focus dessus parce qu’elle a un succès mérité et qu’elle bénéficie d’une belle levée de fonds pour progresser et se développer encore.
Mais il y a des alternatives et non des moindres.
Amazon, une des plus grandes sociétés du monde propose Amazon CloudSearch qui s’intègre naturellement dans AWS et propose un bon niveau fonctionnel même s’il subsiste des lacunes comme l’auto complétion ou la recherche géographique.
Google Custom Search n’est pas vraiment une solution SAAS mais elle peut y être assimilée pour des projets pour lesquels la fonction de recherche revient à un paramétrage de Google pour le contenu du site.
Microsoft Azure Search est une offre similaire à Amazon CloudSearch, propriétaire et efficace. Son principal défaut est de ne s’intégrer que dans certains environnements : .NET, AngularJS et iOS.
D’autres produits sont disponibles en mode SaaS ou en mode solution. Par exemple le produit néerlandais Site Search OpenIndex est encore confidentiel bien que prometteur. De son côté, Swiftype offre SaaS basée sur ElasticSearch est bien connue. Elle a été rachetée en novembre 2017 par la société Elastic, ce qui tend à prouver que la tendance SaaS pour ce marché s’amplifie.