Le fichier d’index était une porte de sortie : l’expérience ALIWEB, 1993–1994

Résumé

• ALIWEB confiait à chaque fournisseur d’information le choix des ressources à décrire, tout en maintenant la collecte et la recherche dans un service central.
• Le pilote de 1994 montre qu’un index modeste pouvait alimenter d’autres catalogues ; il ne prouve ni une couverture complète du Web ni une adoption générale.

À la fin de 1993, publier un document sur le Web ne suffisait plus : encore fallait-il le trouver. Les listes manuelles donnaient du contexte, mais leurs auteurs ne pouvaient suivre chaque déplacement ni chaque nouveau service. Un robot pouvait découvrir davantage de pages, au prix de requêtes répétées sur les serveurs ; il risquait aussi de perdre la structure qui donnait du sens à un ensemble de ressources.

Le 30 novembre 1993, Martijn Koster présenta ALIWEB comme une expérience d’indexation « distribuée » du Web. Chaque serveur devait signaler son contenu dans un fichier local ; un site unique récupérerait ces fichiers et les traiterait ; la base commune pourrait ensuite être interrogée sur le Web. Selon son article de conférence, le pilote fonctionnait déjà chez NEXOR depuis octobre. Dans son annonce du 30 novembre, Koster parlait d’une première étape, pas d’une solution définitive, et formulait une promesse remarquable : lorsque de meilleurs dispositifs apparaîtraient, les données devraient pouvoir être réutilisées ou converties facilement.

Cette promesse éclaire l’architecture. ALIWEB ne décentralisait pas le moteur de recherche ; il répartissait le contrôle de l’index. L’administrateur d’un site choisissait les documents et services à signaler et rédigeait leur description. L’exploitant d’ALIWEB conservait la liste des serveurs inscrits, fixait la fréquence des récupérations, validait le format, assemblait les notices acceptées et faisait tourner l’interface de recherche. Le fournisseur décrivait son propre site ; le service central déterminait le chemin par lequel cette description devenait repérable ailleurs.

Le fichier d’entrée était un texte préparé, souvent nommé /site.idx, fondé sur les modèles de l’Internet Anonymous FTP Archives (IAFA). Ces champs attribut-valeur pouvaient décrire plusieurs objets : type de modèle, titre, URI, description et mots-clés, par exemple. Le système n’essayait pas de déduire le sens de chaque page à partir de son balisage. Il donnait à ceux qui connaissaient la structure du site les moyens d’en signaler les principaux points d’entrée, sans aplatir son organisation interne. L’exemple de Koster décrit les ressources Perl de NEXOR et leur manuel, pas chaque fichier du serveur.

La participation reposait tout de même sur un petit contrat opérationnel. L’administrateur enregistrait le serveur, le port et le chemin du fichier, indiquait un contact responsable et pouvait fixer un intervalle minimal entre deux récupérations. ALIWEB vérifiait la présence du fichier et son format avant d’accepter l’inscription. Un processus Perl distinct relisait les index, récupérait les versions modifiées et reconstruisait la base selon une tâche UNIX cron. On pouvait interroger cette base depuis le formulaire Web d’ALIWEB ou l’intégrer à un autre catalogue, dont le CUI W3 Catalog.

La différence avec un robot explorant le Web était pratique, non absolue. ALIWEB automatisait la récupération et l’assemblage, mais demandait un fichier d’index désigné plutôt que de suivre tous les liens et de télécharger tous les documents accessibles d’un serveur. La charge de collecte baissait et le fournisseur pouvait conserver le contexte. En contrepartie, une page absente de l’index fourni pouvait rester invisible, même si un robot aurait pu l’atteindre. La fraîcheur des résultats dépendait autant du fichier du fournisseur que du travail de collecte.

Les chiffres publiés par Koster montrent à la fois l’usage et ses limites. Au moment de l’article, 54 hôtes étaient inscrits et la base comptait 310 notices. Le formulaire de recherche d’ALIWEB recevait en moyenne 80 requêtes par jour ; le CUI W3 Catalog utilisait sa base pour plus de 8 000 requêtes hebdomadaires. Ces nombres attestent l’existence d’un service fonctionnel et d’une intégration utile. Ils ne mesurent ni la part du Web indexée, ni la qualité des résultats, ni le nombre de serveurs capables ou disposés à maintenir un fichier valide.

Les difficultés d’inscription apparurent tôt. Certains administrateurs enregistraient un hôte sans fournir d’index, semble-t-il parce qu’ils avaient trouvé le formulaire sans avoir compris le dispositif. L’équipe développa la documentation et ajouta une vérification immédiate de la présence et du format du fichier. Des erreurs subsistaient : elles étaient consignées, puis un script lancé manuellement avertissait la personne responsable. La décentralisation n’éliminait donc pas la maintenance ; elle la déplaçait de l’exploration de chaque page vers la création, la validation et la mise à jour d’un index choisi.

« Manuel » ne signifiait pas nécessairement « saisi à la main pour toujours ». Koster jugeait acceptable qu’un logiciel génère le fichier, à condition que les métadonnées restent assez riches pour orienter la recherche. En 1995, un autre projet d’archives décrivit des modèles IAFA mis à jour à partir des changements de fichiers et transformés en index texte, Gopher et HTML. Cet article de conférence du W3C montre que le format pouvait alimenter différentes interfaces ; il ne prouve pas que le corpus d’ALIWEB ait migré ni que le service ait été largement adopté.

La croissance faisait apparaître une seconde limite. Koster reconnaissait qu’une base unique pour tout le Web risquait de devenir trop lourde. Il envisageait plusieurs issues : répartir la collecte, répliquer l’accès aux recherches, séparer les bases par sujet ou organiser une hiérarchie de services ALIWEB. Il s’attendait aussi à ce que les fichiers d’index puissent être convertis automatiquement vers de futurs répertoires. Ce sont des options évoquées dans l’article, pas des fonctions dont le déploiement est établi. Leur intérêt tient au fait que le format était censé survivre au collecteur central du pilote.

Une enquête de 1994 sur la recherche d’information en réseau décrivait encore un domaine jeune, où le contrôle de classification et d’autres fonctions étaient peu répandus. ALIWEB côtoyait les listes manuelles, le CUI W3 Catalog et des approches robotisées comme JumpStation ou la base d’URL de RBSE ; ce n’était pas le premier outil de recherche du Web. Sa contribution plus circonscrite consistait à montrer comment des descriptions choisies à la source pouvaient être collectées automatiquement puis réutilisées.

La Note 65 de Heng Lu sur la primauté du code en fonctionnement fournit une lecture rétrospective, pas une preuve de la pensée de Koster : un format peut promettre la portabilité, mais seuls des systèmes qui l’adoptent en pratique rendent cette portabilité réelle. L’article documente un pilote ALIWEB et l’utilisation de sa base par le W3 Catalog. Il ne documente ni adoption universelle, ni mandat sur les éditeurs du Web, ni migration achevée. La distinction historique utile est donc triple : les fournisseurs décidaient de ce que leurs sites disaient ; ALIWEB décidait de ce qui entrait dans son index commun ; les systèmes futurs restaient libres de réutiliser le fichier sans reprendre le service central du pilote.