Fess : un moteur de recherche d'entreprise auto-hébergé sur OpenSearch

Le problème que Fess traite, et pour qui

Chercher dans les documents d'une organisation ne se réduit pas à brancher un index. Il faut découvrir les sources, les parcourir régulièrement, extraire le texte de formats binaires, appliquer des droits, puis exposer une interface. Fess prend en charge cette chaîne complète. Le README le présente comme un serveur de recherche d'entreprise installable sur toute plateforme disposant d'un runtime Java, et insiste sur un point : la connaissance préalable d'OpenSearch n'est pas nécessaire, car l'outil se configure via une interface d'administration dans le navigateur.

Le public visé est donc une équipe informatique interne, pas un développeur qui veut ajouter une barre de recherche à une application. Les cas d'usage listés dans le README sont explicites : sites web, systèmes de fichiers, bases de données et fichiers CSV. Le projet fess-site-search est décrit comme une alternative gratuite à Google Site Search, à intégrer dans un site existant. Si votre besoin est d'indexer une table unique pour un back-office, la machinerie décrite ici est disproportionnée.

Crawlers, connecteurs et index OpenSearch

L'architecture repose sur trois briques. Un crawler intégré collecte les documents depuis les cibles configurées. Un moteur d'indexation les transforme en documents indexés dans OpenSearch. Une couche de recherche restitue les résultats avec facettes, tri et suggestions.

La collecte se décline en trois familles de configuration, nommées dans le README : Web, File et Data Store. La troisième est la plus étendue, avec une liste de connecteurs maintenus dans des dépôts séparés : Confluence/Jira, Box, CSV, bases de données, Dropbox, Elasticsearch, Git, Gitbucket, G Suite, JSON, Office 365, S3, Salesforce, SharePoint et Slack. Chaque connecteur est un plugin, ce qui signifie que la couverture réelle dépend de ce que vous installez, pas du cœur de Fess.

Le format des documents traités inclut Microsoft Office, PDF et archives ZIP. Sur les droits, le README mentionne un filtrage des résultats par rôle et permission, ainsi qu'une authentification unique via LDAP, OpenID Connect, SAML, SPNEGO et Microsoft Entra ID. L'analyse linguistique couvre plus de vingt langues, interface comprise. Le point de conception à retenir : OpenSearch reste le moteur, Fess est la couche qui le pilote. Vous héritez donc des contraintes d'exploitation d'OpenSearch, même si vous n'avez pas à écrire de requêtes.

Démarrage : paquets, Docker et ligne de commande

Les prérequis sont nets : Java 21 ou plus récent pour les paquets ZIP, RPM et DEB, et OpenSearch comme moteur. Les images Docker embarquent OpenSearch ; pour les autres modes d'installation, il faut le mettre en place séparément.

Pour un essai rapide depuis l'archive ZIP, le README donne ces commandes :

$ unzip fess-<version>.zip $ cd fess-<version> $ ./bin/fess

Les images Docker sont publiées sur ghcr.io, et un fichier Docker Compose est disponible dans le dépôt docker-fess, sous compose. Une fois lancé, l'interface de recherche répond sur http://localhost:8080/ et l'administration sur http://localhost:8080/admin/, avec admin/admin comme identifiants par défaut. La séquence d'usage est décrite ainsi : enregistrer les cibles sur les pages Web, File ou Data Store, puis lancer le crawler depuis la page Scheduler.

Côté développement, il faut Java 21 et Maven. Les plugins OpenSearch se récupèrent avec mvn antrun:run, l'exécution se fait via la classe org.codelibs.fess.FessBoot, et la construction d'un paquet passe par mvn package, puis mvn rpm:rpm ou mvn jdeb:jdeb selon le format. La génération de code utilise mvn dbflute:download, mvn dbflute:freegen et mvn license:format. Les tests d'intégration exigent un serveur Fess démarré avec OpenSearch, la disponibilité se vérifie par curl -s "http://localhost:8080/api/v1/health", et les données de test proviennent du dépôt fess-testdata cloné dans /tmp/fess-testdata. La commande de test complète est mvn test -P integrationTests avec les propriétés test.fess.url et test.search_engine.url.

Les limites que le README laisse visibles

La première contrainte est structurelle : Fess n'est pas autonome. Sans OpenSearch, il ne fonctionne pas, sauf en Docker où l'image l'embarque. Cela implique de dimensionner, sauvegarder et mettre à jour un moteur de recherche en plus de l'application. Le README ne décrit aucune procédure de sauvegarde ni de restauration.

La deuxième concerne les identifiants par défaut. admin/admin est documenté sans réserve apparente, ce qui est acceptable pour un essai local et problématique dès que l'instance est exposée. Le matériel fourni ne précise pas si un changement forcé est imposé au premier démarrage.

La troisième touche à la couverture fonctionnelle réelle. Les connecteurs vivent dans des dépôts distincts, avec leurs propres rythmes de publication. Le README ne donne aucune indication sur la compatibilité entre une version de Fess et une version de connecteur, ni sur ce qui se passe lorsqu'un connecteur n'est plus maintenu. C'est une zone d'ombre à évaluer au cas par cas.

Enfin, le délai de démarrage est mentionné indirectement : les tests d'intégration demandent d'attendre que Fess soit prêt, ce qui peut prendre jusqu'à 60 secondes. À l'échelle d'un déploiement, cette attente se répercute sur les procédures de redémarrage et de supervision.

Face à Elasticsearch et aux moteurs intégrés

La comparaison la plus directe est celle avec OpenSearch et Elasticsearch utilisés directement. Ces moteurs fournissent l'indexation, la recherche et l'API, mais pas la collecte. Il faut écrire ses propres pipelines d'ingestion, gérer l'extraction de texte des PDF et des fichiers Office, et construire une interface. Fess apporte précisément cette couche, au prix d'une dépendance à sa façon de configurer les choses.

L'autre alternative est le moteur de recherche intégré à une application, du type bibliothèque d'indexation embarquée. Le compromis est inverse : contrôle total sur le schéma et le cycle de vie, mais aucune découverte automatique de sources, aucun connecteur SaaS, aucune interface d'administration. Fess se justifie quand le nombre de sources dépasse ce qu'une équipe veut coder à la main. Il perd son intérêt quand la recherche est un composant interne dont le schéma change à chaque déploiement applicatif.

Un point mérite d'être noté : le README positionne Fess comme une alternative à Elasticsearch dans les sujets du dépôt, alors que le moteur sous-jacent est OpenSearch. La nuance est réelle, mais elle porte sur le fournisseur du moteur, pas sur le modèle d'exploitation.

Maintenance, montée de version et licence

Le rythme de publication est soutenu : fess-15.8.0 en août 2026, fess-15.7.0 en juin 2026, fess-15.6.1 en mai 2026. Le dépôt n'est pas archivé et le dernier push est daté de septembre 2026. Cette cadence implique une charge de suivi : chaque version peut toucher les plugins OpenSearch, qui sont téléchargés séparément via mvn antrun:run pour les installations hors Docker.

La licence est Apache-2.0, ce qui autorise l'usage commercial, la modification et la redistribution, avec conservation des mentions de licence et du fichier NOTICE. La commande mvn license:format suggère que les en-têtes de licence sont normalisés dans le code. Cela ne dit rien du régime des plugins tiers ni des données que vous indexez, questions qui dépassent le périmètre du dépôt et relèvent d'une analyse juridique propre.

Le coût de maintenance réel se situe moins dans Fess que dans l'ensemble Fess plus OpenSearch plus connecteurs. Une montée de version se prépare en vérifiant la compatibilité des trois, et le README ne fournit pas de matrice pour cela. C'est le principal travail d'exploitation à anticiper.

IA, RAG et recherche sémantique : ce que le dépôt annonce

La description du dépôt mentionne la recherche sémantique, le RAG et le MCP parmi les sujets associés, aux côtés de termes comme ai-search et llm. Le README, dans la portion fournie, ne détaille aucune de ces fonctions : il liste la recherche plein texte, les facettes, le tri, les suggestions, les crawlers, les formats de documents, l'administration, l'API REST, le filtrage par rôle, l'authentification unique, le multilinguisme et l'extensibilité par plugins.

Il faut donc être prudent. Les sujets d'un dépôt décrivent une intention ou un positionnement, pas une garantie de fonctionnalité documentée. Avant de retenir Fess pour un usage de recherche sémantique, la seule démarche fiable consiste à consulter la documentation du site officiel et les notes de version correspondantes. Le matériel disponible ici ne permet pas de trancher sur la maturité de ces fonctions, ni sur les modèles ou les formats d'embedding pris en charge.

Ce qui est confirmé, en revanche, c'est le mécanisme d'extension : plugins de data store, d'ingestion, de script (Groovy, OGNL) et de thème. Un déploiement qui veut ajouter du traitement de texte personnalisé passe par là, pas par une option de configuration.

Conclusion éditoriale

Fess convient aux équipes qui doivent indexer un patrimoine documentaire hétérogène (sites internes, partages de fichiers, bases de données, SaaS) et qui acceptent d'exploiter une JVM et un cluster OpenSearch. Il ne convient pas si vous cherchez uniquement une recherche applicative intégrée à votre code, ou si vous ne pouvez pas faire tourner Java 21 et OpenSearch. Avant de vous engager, vérifiez deux points dans le dépôt : la version d'OpenSearch attendue par la branche que vous déployez, et le contenu de MIGRATION.md si vous venez d'un autre fournisseur, car c'est là que se trouvent les contraintes de reprise des données.

Sources officielles

1. codelibs/fess on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases