Le mot expérimentation est réservé à des situations dans lesquelles les variables intervenant directement sur le système, c’est à dire les données en entrée et sortie, mais aussi l’environnement et les variables concomitantes27 sont contrôlés. En recherche d’information, un test en laboratoire donne la garantie de pouvoir contrôler simultanément ou seulement quelques-uns uns des quatre facteurs : Utilisateurs, base de données, recherche et contraintes de recherche. C’est la raison pour laquelle ces tests ont été construits de toute pièce. Dans un test opérationnel, ces facteurs ne sont pas, ou sont plus difficilement, complètement contrôlables. . [ROB92]
Un exemple classique de test en laboratoire est le test de Cranfield présenté précédemment. Nous pourrons aussi citer l’évaluation du système SMART [SAL92] déjà décrite.
Le conflit entre les expérimentations en laboratoire et opérationnelles est un conflit entre d’un côté un contrôle total sur les variables opérationnelles, la mesurabilité et la répétabilité des tests, et de l’autre le réalisme. Dans les premiers temps de l’évaluation, la question du réalisme, centrée sur le besoin, la requête et le jugement de pertinence, rendait inévitable des tests avec des utilisateurs en situation ayant des besoins non fictifs. De plus, avec des systèmes de plus en plus interactifs, il devenait vraiment difficile de simuler le comportement d’un utilisateur. Ces facteurs furent les grands arguments en faveur des tests opérationnels, en dépit du fait qu’ils sont difficiles à mettre en oeuvre.
La combinaison optimale d’un test serait de le faire démarrer en laboratoire, en analysant les combinaisons de facteurs dans des conditions contrôlées, puis de migrer ensuite vers des tests opérationnels effectuant des contrôles et analyses moins larges. Le travail de OKAPI [MIT85] en est un bon exemple. L’expérience CIRT décrite précédemment représente la phase opérationnelle d’une série d’expérimentations utilisant des méthodes probabilistes.
OKAPI est un catalogue expérimental en ligne crée en 1985. La première expérimentation [MIT85], avait pour but de tester un système incluant une stratégie de recherche par termes pondérés et une présentation ordonnée des réponses. L’analyse des fichiers de connexion des utilisateurs effectuant une recherche ainsi qu’un bref interrogatoire de satisfaction a permis de fournir un diagnostic pour améliorer la recherche par sujet. Ces données ont permis de construire une pseudo collection test.
Lors de la deuxième expérimentation effectuée sur OKAPI en 1987, de nouveaux mécanismes ont été introduits pour améliorer le rappel : la lemmatisation, la correction automatique, et des tables de références croisées. Un test opérationnel a été mené. Deux machines ont été placées dans une bibliothèque, l’une contenant une version complète du module de lemmatisation, l’autre une version plus simple28. Une troisième version ne contenant aucuns des nouveaux modules a été mise en place comme référence. Les trois versions ont été exploitées à partir de certaines requêtes enregistrées lors de la première expérimentation, requêtes choisies car elles étaient répétables. En plus des tests comparatifs de recherche, une étude a été menée auprès des utilisateurs. Ceux-ci ont déclaré, en concordance avec les tests comparatifs précédents, avoir bien perçu l’amélioration de la recherche sur les nouvelles versions.
La troisième expérimentation qui couplait des tests en laboratoires et des tests opérationnels a été menée en 1990 [WAL90]. Elle avait pour but de tester une version plus interactive. A partir des besoins identifiés des utilisateurs actuels, des thèmes représentatifs ont été choisis. Ils ont permis de créer un ensemble de sujets. Les utilisateurs ont sélectionné un sujet et effectué leur recherche sur deux versions, l’une comprenant un module d’expansion automatique de la question, et l’autre ayant en plus des facilités de navigation. Un bref interrogatoire a été mené après la recherche. Les jugements de pertinence ont été donnés à la fois directement par les utilisateurs, en suivant une échelle de valeurs communes, et par des juges extérieurs.
Rappelons que les tests en laboratoire faits sur OKAPI, ont été menés à partir du fichier des connexions29 . Or ce dernier ne donne pas d’information quant à l’identité de l’utilisateur ; si bien que l’on ne sait pas s’il a effectué plusieurs requêtes sur un sujet particulier et si la connexion analysée est la première, la deuxième,... Le système proposant en effet un module d’expansion de la question, l’évaluation n’aurait donc pas dû être uniquement menée sur le plan question / document mais sur le plan document / état de la recherche / session , et inclure une temporalité. En effet, comme nous l’avons dit précédemment (chapitre II-2), suite à une interrogation la connaissance de l’utilisateur, l’état de son savoir sur un sujet change. Sa capacité à utiliser les compétences du système s’améliore aussi. En effet, un changement dans le comportement de recherche a été nettement observé lors de ces expérimentations, en particulier dans l’usage fait du module d’expansion. La comparaison de deux sessions d’interrogation, seulement en fonctions de la pertinence de la question pour l’utilisateur, ne sera donc pas complète, car les données initiales seront différentes.
Robertson [ROB92] a référencé plusieurs travaux concernant la continuité de la recherche ainsi que l’évolution des jugements de pertinence d’utilisateurs effectuant des interrogations successives.
Le désavantage de faire des tests opérationnels est qu’on ne peut les généraliser à d’autres systèmes avec le même degré de confiance. Le test opérationnel permet souvent de faire des conclusions sur le système comme un tout, et non pas sur certains aspects individuels. Les tests opérationnels sont plus proches de la réalité mais apportent moins d’information. En effet, moins de variables sont contrôlées ou mesurées, il est donc plus difficile d’attribuer les résultats observés à des causes particulières.
C’est à dire les variables annexes.
Les résultats n’ont pas montré de différence flagrante pour les utilisateurs entre les deux versions.
Fichier enregistrant l’ensemble des actions effectuées lors de la connexion d’un utilisateur (sa requête, ses reformulations, les documents consultés, les références sauvegardées,...) ainsi que le temps passé.