Partie 3 Annexes
3.3 Bilan et directions pour améliorer le quotidien du biologiste
Une avancée pour l’utilisateur final ?
De nos discussions avec les biologistes est ressortie une problématique de façon récurrente : ils sont perdus sur leur espace de travail, au milieu de l’information, et passent un temps important à croiser cette information et la synthétiser dans leur tableur favori.
Lorsqu’ils disent qu’ils sont perdus, ils n’expriment pas simplement une surcharge de leur bureau sur l’écran, encombré par un grand nombre de fenêtres. Ceci n’est qu’un symptôme et une mesure du problème, mais le problème ne se restreint pas { cela. L’utilisateur est perdu parce qu’il ne connait qu’une faible partie des sources, ne peut pas estimer leur qualité, n’a pas de moyen de contrôle, et le plus souvent ne peut pas accéder à une traçabilité suffisante. Lorsque deux annotations diffèrent, il n’a pas de moyen de savoir si l’une des deux est obsolète, et laquelle. L’utilisateur est perdu car il ne maitrise pas l’inventaire des sources, leur contenu, leur mise en forme. A tous ces niveaux, la quantité et l’hétérogénéité l’empêchent d’avoir une représentation en mémoire de cet ensemble de sources. Il se résout donc à utiliser quelques portails de référence, qui sont choisis le plus souvent suivant des critères aléatoires et subjectifs. Concernant la problématique concrète de l’utilisateur, nous avons vu que l’intégration de données ne propose { l’heure actuelle que des solutions partielles et ponctuelles. Quand bien même le besoin d’un utilisateur est rempli par un système, il possède généralement d’autres besoins auxquels il ne trouve aucune réponse efficace. Nous proposons quatre questions auxquelles les systèmes d’intégration doivent répondre pour satisfaire les besoins de l’utilisateur final :
- Combien de fenêtres l’utilisateur manipule-t-il ?
- Combien d’environnements1 distincts consulte-t-il régulièrement et directement ? - Utilise-t-il encore des copier/coller pour rassembler l’information au sein de son
tableur favori ?
- L’utilisateur doit-il avoir une connaissance et compréhension de l’inventaire des sources ?2
Ces questions sont simples. Elles permettent dès le début d’un projet de prévoir objectivement si la solution envisagée améliorera le quotidien du biologiste. A la fin du projet, elles permettent d’évaluer le bénéfice produit. Lorsque l’on prend du recul sur les approches précédemment décrites et qu’on les confronte { ces questions, on comprend rapidement pourquoi l’utilisateur final n’a pas ressenti d’amélioration significative dans son quotidien.
Un constat général sur lequel nous terminons ce bilan est qu’{ chaque besoin est proposée une approche spécifique. L’utilisateur possédant de multiples besoins, il est amené { faire cohabiter plusieurs approches sur son espace de travail. Pour unifier la perception de l’information { l’utilisateur, il est donc avant tout nécessaire d’unifier les approches de l’intégration de données.
1 Par environnement, nous considérons ici les sites, portails, logiciels et applications qu’il manipule. 2 Cette question est déjà présente dans [Cohen-Boulakia 2005]
Sociologique ou technique ?
The IGD project survived for slightly longer than a year before collapsing. The main reason for its collapse, as described by the principal investigator on the project (O. Ritter, personal communication), was the database churn issue. On average, each of the source databases changed its data model twice a year. This meant that the IGD data import system broke down every two weeks and the dumping and transformation programs had to be rewritten — a task that eventually became unmanageable. *…+ 1
Although it is tempting to treat the integration of biological databases as a technological problem, in fact the main impediment to achieving this goal is not technological but sociological. In the opinion of this author, meaningful scaleable integration cannot be achieved without the cooperation of the data providers. As long as the data providers continue to produce online databases without regard for the way in which the information will be aggregated, integration will be a monumental task. However, in the absence of accepted standards for the representation and exchange of biological data, it is far from simple for data providers to achieve the goal of making their data available in a form that can be cleanly integrated and maintained. 2 Lincoln Stein [Stein 2003]
Nous partageons l’opinion de Lincoln Stein et réalisons les mêmes constats [Stein 2003]. Le problème est sociologique plus que technique, les producteurs de données ne doivent pas « développer dans leur coin ». En témoigne la diversité d’accès aux données (fichiers, services, …), de formats (GenBank, Fasta, XML,…), et des langages de requête, la disponibilité de mises à jour incrémentales ou d’historiques, et le défaut d’utilisation de certains standards (LSID, …). L. Stein indique que la technique n’a cependant pas fourni les outils suffisants pour la représentation et l’échange des données. Aujourd’hui, de nombreux standards adaptés ont été proposés et ne sont pas utilisés pour autant. Cela s’explique ; la conception d’un entrepôt provient souvent d’un besoin de propriété de données et d’un système, de besoins nouveaux. La recherche est telle qu’il y a donc une volonté d’autonomie, d’indépendance, de se distinguer dans la communauté, tout en possédant des budgets qui obligent à établir certaines priorités : les fonctions essentielles de l’utilisateur qui dirige le projet. A chaque problème nouveau une solution nouvelle.
Pour adresser ces problèmes, plusieurs sujets doivent être traités simultanément et dirigent les choix dans notre environnement :
- L’intégration doit être peu coûteuse, et mutualisée autant que possible, afin de pallier les difficultés décrites au sein du projet IGD. Pour cela, elle doit posséder un modèle simple.
- Elle doit prendre en compte les besoins de l’ensemble des développeurs et répondre à leurs contraintes : entrepôt vs légèreté, requête SQL vs moteur de recherche textuel, …
1 Le projet IGD a survécu pendant plus d'un an avant de s'effondrer. La principale raison de cet effondrement, décrite par le principal instigateur du projet (O. Ritter, communication personnelle), était le brassage des bases de données. En moyenne, chaque base de données sources changeait son modèle deux fois par ans. Ceci signifiait que le système d'importation des données tombait en panne toutes les deux semaines et que les procédures de téléchargement et de transformation des données devaient être réécrites - une tâche qui est devenue par la suite ingérable. [...]
2 Bien qu’il soit tentant de traiter l’intégration de bases de données biologiques comme un problème technologique, en fait le principal empêchement pour atteindre cet objectif n’est pas technologique mais sociologique. D’après l’auteur, une intégration significative { l’échelle du problème ne peut être réalisée sans la coopération des producteurs de données. Tant que ceux-ci continueront à produire des bases de données en ligne sans tenir compte des méthodes d’agrégation qui leur sont appliquées, l’intégration sera une tâche monumentale. Cependant, en l'absence de standards acceptés pour la représentation et l'échange de données biologiques, il est loin d'être simple pour le fournisseur des données d'atteindre l'objectif de rendre ses données disponibles sous une forme qui peut être proprement intégrable et maintenable.
- Elle doit rendre transparentes et immédiates les fonctionnalités souvent mises de côté pour des questions de coût mais importantes : traçabilité, standards d’interopérabilité, extensibilité, etc.
- Elle doit prendre en compte les besoins des utilisateurs : proposer plusieurs solutions d’accès visuel (workflow, portails, etc.) et permettre d’accéder { l’information depuis les outils métiers. Elle doit envisager plusieurs outils métiers, et mettre à disposition des outils de visualisation polyvalents et correspondant aux besoins variés.
- L’environnement doit fédérer et attirer les décideurs et les développeurs : il doit les contraindre à être interopérables tout en réduisant le coût de leur projet, le temps de développement et en fournissant des outils pour l’utilisateur final.
Une réduction de l’hétérogénéité ?
Le témoignage apporté par le projet IGD met en évidence un constat : l’évolution rapide des sources met en échec les approches médiateur. L’entrepôt pallie ce problème : dans le cas d’un problème de connexion avec une source, le système est disponible, le problème relève de la mise { jour des données. L’entrepôt offre de plus la propriété physique des données, importante pour nettoyer les données ou pour des contraintes de performances et de confidentialité. Les entrepôts ont donc remporté un vif succès : par exemple GUS a été implanté plus de 20 fois, et AceDB plus de 50.
Cependant, en facilitant la mise en œuvre d’entrepôts, la communauté a favorisé leur multiplication. Grâce { l’intégration, certains utilisateurs disposent de sources plus adaptées. Mais plus globalement, la multiplication des sources ne fait qu’accroître le problème de l’hétérogénéité. L’intégration n’est jamais parfaite, et découle des pertes de traçabilité et de métadonnées, d’une augmentation de l’hétérogénéité et de la redondance. L’utilisateur qui veut croiser des données doit parcourir plus de sources. Il doit traiter plus d’information redondante, et plus d’information divergente. La redondance est une perte de temps, la divergence est un problème plus grave encore. Lorsqu’une donnée est mise { jour et répercutée sur une partie des sources, il n’a plus de moyen de savoir quelle est l’origine de la donnée, la version la plus { jour, la façon dont elle a été produite, la raison pour laquelle elle a été modifiée.
Une pratique courante du biologiste est d’utiliser des outils généralistes, et un portail communautaire. Lorsque les données divergent, il doit faire confiance au portail spécialisé, sans réelle preuve de la qualité et de la fiabilité des données. Le choix d’une ressource est le plus souvent assez subjectif et repose sur des critères d’esthétique et de simplicité d’utilisation de l’interface, de rapidité et de disponibilité de la source, de notoriété de l’institut propriétaire, ou sur la recommandation par des collègues, etc.
3.3.2 Directions choisies pour une réponse commune aux développeurs et utilisateurs
finaux
Le bilan précédent soulève plusieurs problèmes qui nécessitent une solution commune. Rappelons que notre problématique concrète se résume simplement : Comment réduire le nombre de fenêtres ? Comment éviter { l’utilisateur de faire des copier/coller fastidieux dans son tableur favori pour accéder à une information synthétique ? Nous somme confrontés à deux utilisateurs qui ont un pouvoir de décision :
- l’utilisateur final, le biologiste, qui manipule l’outil et pour lequel on souhaite améliorer l’accès { l’information,
- le développeur qui conçoit et implante l’outil pour l’utilisateur final, qui est généralement autonome concernant les choix techniques.
Nous sommes convaincus que l’adoption de notre solution n’est réaliste que si elle répond simultanément aux desideratas des utilisateurs et des développeurs, en s’intéressant de façon transversale à plusieurs domaines : l’intégration de données et la visualisation d’information.
Pour atteindre cet objectif, il nous semble indispensable de concilier plusieurs directions dans nos recherches. Pour réduire le nombre de fenêtres manipulées par l’utilisateur, il faut accéder { l’information au sein des outils métiers de l’utilisateur. Cet utilisateur doit pouvoir visualiser et manipuler l’information synthétisée de façon adaptée { la tâche. Les pages Web des portails ont montré leurs limites. L’information manipulée par ces outils est la même, les tâches réalisées par l’utilisateur dans différents outils sont le plus souvent liées. Il faut donc que ces applications soient interopérables. La donnée doit être centralisable, partageable entre plusieurs utilisateurs et plusieurs applications. Enfin, si notre projet vise à proposer un nouveau point de départ pour des projets l’adoptant, de nombreux outils existent (entrepôts, médiateurs, plateformes, portails, etc.). La migration ne peut être que progressive, il est donc nécessaire que notre projet s’ouvre { toutes ces approches. Les outils existants doivent pouvoir s’étendre vers notre environnement et être interopérables facilement. La suite de cette section présente ces trois directions. Nous verrons dans le chapitre suivant comment nous les concilions.
Accès à l’information depuis l’outil métier
La figure 3.6 schématise l’évolution de l’intégration du point de vue de l’utilisateur : en introduisant des systèmes d’intégration et des portails (ab), la communauté a permis de réduire le nombre de sources. Cependant, l’information n’est pas accessible directement dans l’application métier permettant l’analyse de données expérimentales. L’utilisateur est amené { consulter plusieurs portails et à ouvrir de nombreuses pages dans ces portails. Nous prônons d’intégrer l’information dans les outils métiers de l’utilisateur (bc).
Figure 3.6 – Face à de nombreux systèmes d’information (a), l’intégration a réduit le nombre de sources pour l’utilisateur au travers des portails et systèmes d’intégration (b). L’accès à l’information se fait hors de l’application métier et du contexte expérimental. L’utilisateur doit comparer de nombreuses pages Web. Nous proposons une intégration au sein du contexte expérimental (c). L’accès aux portails doit être restreint au maximum et doit pouvoir se faire à partir du contexte expérimental.
Visualisation
L’environnement permet d’accéder { une grande quantité de données complexes. Par conséquent, il est nécessaire de mettre { disposition de l’utilisateur des mécanismes de visualisation et d’interaction adaptés en s’appuyant sur l’état de l’art. Ces outils de visualisation sont par ailleurs des services attractifs pour fédérer les développeurs. L’utilisateur manipulant plusieurs applications métier, la visualisation doit homogénéiser la manipulation des données
a b
c
Applications métiers Applications métiers
Systèmes d’informations Portails intégrant plusieurs sources
entre les différentes applications et être capable de s’adapter aux différentes tâches réalisables dans ces applications : les besoins d’un utilisateur d’une veille bibliographique ne sont pas les mêmes qu’une analyse de données d’expression. L’usage diffère quand on analyse 5 gènes, 50, ou 500. Il ne s’agit pas simplement de proposer un zoom optique, mais de considérer plusieurs cas d’utilisation.
L’informatique est récente dans le quotidien du biologiste. Ce dernier utilise toujours son traditionnel cahier d’expériences. Il est donc nécessaire de pouvoir figer l’information à un instant donné, la sauvegarder sous forme de fichier, d’image et de l’imprimer pour la griffonner et la coller sur le cahier d’expériences. Plus généralement, il est important de s’ouvrir, de respecter les pratiques du métier, et de prévoir l’existence de plusieurs supports.
La donnée au centre de l’interopérabilité
Plusieurs applications coexistent, et les utilisateurs travaillent en équipe le plus souvent. Il est donc nécessaire de permettre à différentes applications de partager les mêmes données, et à différents utilisateurs d’y accéder simultanément. Les tâches réalisées au sein d’un outil et un utilisateur doivent être répercutables immédiatement dans un autre outil manipulé par une autre personne. Cela implique une centralisation des données, la gestion d’une traçabilité et l’utilisation de standards d’interopérabilité. La donnée est l’objet mais aussi le pivot de cette interopérabilité (figure 3.7).
Figure 3.7 – La donnée est l’élément central sur lequel porte l’interopérabilité. Elle est partagée par les outils et les utilisateurs. Cette fonctionnalité ne doit pas représenter une charge supplémen- taire pour le développeur, et doit être transparente pour l’utilisateur.
Socle commun et fédérateur
Notre objectif concerne { la fois l’utilisateur et le développeur. Notre hypothèse se base sur le constat de l’existence de différentes approches de l’intégration de données. Ces approches n’apportent que des réponses partielles, favorise la multiplicité d’outils tout en ne contribuant pas à leur interopérabilité. Si on souhaite homogénéiser le cadre applicatif de l’utilisateur, il faut auparavant homogénéiser celui du développeur et proposer une approche commune permettant de concilier les principaux avantages de différentes approches et pallier leurs limites. Il ne s’agit pas de les remplacer, mais de leur permettre de cohabiter (cf. figure 3.8).
Pour fédérer les développeurs, nous devons leur proposer un cadre commun pour des besoins variés. De plus, pour les attirer, nous devons leur fournir certains services (API métier, visualisation, gestion de formats de fichiers, etc.). Enfin, nous ne devons pas les repousser : les fonctionnalités supplémentaires que nous proposons doivent être accessibles sans effort pour lui (traçabilité, multiplicité des supports, etc.).
Données
Analyse de données Gestion de bibliographie Commande de sondesSystème unificateur des approches de l’intégration de données
Systèmes d’intégration
Systèmes à base de
liens/chemins Plateformes
Services Web &
Flux de tâches … Utilisation directe
Figure 3.8 – Notre approche (blanc sur bleu foncé) se positionne comme une couche unificatrice favorisant l’interopérabilité des approches existantes. Elle propose un ensemble de services et d’outils fonctionnels permettant le développement rapide d’applications métiers accédant aux données intégrées et les visualisant.