Le processus de développement

 Le processus de développement

Trois dimensions de rétroaction

Malgré ce fait, la confrontation avec le monde pratique nous a apporté un nombre important d’éléments et le dispositif en a profité considérablement. Les interactions avec les usagers / testeurs peuvent être divisées en trois catégories : – Recherche de bugs : dans le travail d’écriture informatique il n’est guère possible d’éviter des erreurs de toute sorte ; des fautes de programmation, des inconsistances au niveau de l’interface, des comportements imprévus, etc. Il est évidemment impossible pour le designer / programmeur de repérer ces bugs tout seul et pendant les tests de procspace, nous en avons découvert un grand nombre grâce aux indications fournies parles testeurs ou par observation de l’outil dans l’usage. – Nouvelles fonctions : dans un contexte où les usagers sont, de façon croissante, de bons connaisseurs du monde informatique et des outils d’information et de communication, il devient possible de les considérer comme une source explicite d’idées précises concernant les formes et fonctions de l’outil. Un certain nombre de caractéristiques du dispositif, par exemple le système de gestion des droits, la question des formats de fichiers acceptés par l’outil et les fonctions de notification (par email et flux RSS), ont été conçues et réalisées après une demande explicite de la part des usagers. – Les difficultés : cette troisième source de renseignement est probablement la plus intéressante parce que elle nous a permis de voir à quel point il est difficile de réunir l’ouverture structurelle et la facilité d’usage. On pourrait penser que la création d’un outil semi-structuré 243 Le CIERA (Centre interdisciplinaire d’études et de recherches sur l’Allemagne) est un organisme, basé à la Sorbonne, qui rassemble dix universités et institutions dans le but de construire un réseau, en sciences humaines, de recherches sur l’Allemagne. Métatechnologies et délégation – 347 – serait plus simple, parce qu’une bonne partie de la morphologie finale de l’outil dépend des membres du groupe, mais rien ne serait plus faux. L’aménagement de l’ouverture, sa mise en interface et sa pédagogie, sont des tâches délicates, longues et laborieuses parce que de petits détails peuvent décider de la façon dont les usagers se représentent cognitivement et, par conséquent, utilisent les fonctionnalités du dispositif. En ce sens, le travail sur les différents prototypes a été extrêmement éclairant parce qu’il nous aidait à expliciter et mettre à jour les difficultés et problèmes et montrait à quel point le contexte social et le design d’interfaces sont déterminants pour le succès d’un dispositif informatique. Ces trois types de retours des testeurs sur l’outil étaient en partie des interventions et indications directes et en partie des interprétations de notre part des comportements des usagers et du fonctionnement de l’outil. Même dans un contexte participatif comme nous avons essayé de le mettre en place de façon embryonnaire, le choix de prendre en compte une demande, critique ou suggestion reste du côté des créateurs. Cela nous montre qu’un design orienté-société reste appuyé sur un fond de bonne volonté de la part des développeurs qui se manifeste avant tout dans l’organisation du processus de développement.

Le dispositif social

Dans notre petite expérience, nous avons rapidement compris que le succès d’un processus participatif dépend largement de ce qu’on pourrait appeler le « dispositif social », c’est-à-dire l’organisation des relations entre les créateurs et les usagers, mais aussi des usagers entre eux. Lorsqu’on parle d’une symétrie de confiance, il faut insister sur le mot confiance et le penser dans toute sa profondeur, et non pas comme un slogan facile qui se réduit à une ouverture de façade vers les autres, sans corps ni constance. C’est seulement dans le processus de développement que nous avons pleinement compris que la mise en place d’un rapport de confiance ne représente pas un simple choix, mais un immense travail sur le plan social. Il n’est guère suffisant d’accorder le droit de suggestion et de critique aux usagers, parce que l’asymétrie qui existe toujours entre eux et les créateurs, sur le plan des connaissances ainsi que sur celui du pouvoir décisionnel, ne peut pas être éliminée par la seule décision abstraite de la rééquilibrer. En ce sens, la réussite d’un processus participatif dépend en grande partie de l’existence d’un sentiment de sécurité de la part des usagers par rapport aux développeurs, mais aussi, dans le cadre d’un collecticiel, par rapport aux autres usagers. La mise en place d’un environnement qui inspire ce sentiment n’est pas quelque chose qui se fait dans un ou deux ateliers de test, comme nous avons du le remarquer. La différence entre le recours à une série de tests et un véritable processus participatif n’est pas stricte mais graduelle. L’investissement de temps, d’effort et d’empathie de la part des créateurs qui est nécessaire pour arriver au second est considérablement plus élevé que pour le premier et demande finalement de bonnes connaissances en sciences sociales, surtout en dynamique de groupe, ainsi que Métatechnologies et délégation – 348 – de l’expérience dans le domaine. Nous avons certainement beaucoup profité des retours, suggestions et observations des usagers mais nous avons aussi du comprendre que notre budget en temps et investissement personnel n’était pas suffisant pour alimenter un véritable design participatif au sens non-métaphorique du terme.

L’architecture

En ce qui concerne la réalisation technique de l’outil, nous avons dès le départ travaillé avec les technologies du Web afin de garantir une homogénéité entre l’espace de recherche (le Web) et l’espace de gestion (l’outil). L’absence de seuil technologique entre ces deux espaces permet aux usagers de rester dans le même environnement et de se connecter au système à partir de tout ordinateur en ligne. Pour ne pas pénaliser certains clients, nous avons essayé de faire appel aux plug-ins aussi peu que possible. Sur le plan de la méthodologie de développement, nous avons fait appel aux conseils et stratégies du extreme programming (XP). L’architecture modulaire du logiciel nous permet d’ajouter des fonctions très rapidement, sans mettre en danger le fonctionnement de l’ensemble et l’agilité du processus fait que chaque changement peut être testé de façon immédiate. La refactorisation du code améliore les performances et surtout la lisibilité, nécessaire dans notre objectif de publier notre système sous une licence open source.

La base

Le coeur de procspace est constitué par une base de données mySQL qui contient tous les documents dans leur format d’origine, comme version traduite en HTML (pour les documents PDF), en tant que texte « nettoyé » (sans balisage) et finalement en tant que vecteur où chaque dimension représente un mot unique et sa valeur le nombre des occurrences. Ce traitement est effectué par les agents de veille et de vectorisation et il prépare le document pour les traitements qui interviennent par la suite. Un middleware, écrit en PHP, se charge de l’acheminement des flux de la base de données vers l’interface et vice-versa, de la gestion des usagers et de la communication avec le système d’agents. Métatechnologies et délégation – 349 – Schéma du système et des agents de procspace 

Les agents

Les agents du système chargent les documents correspondant aux URL spécifiées par les usagers, surveillent d’éventuels changements de ce document en enlèvent des informations de formatage (balises). Sous forme d’agents sémantiques, ils sont également responsables de tout le travail de datamining : utilisant un modèle vectoriel classique [Salton 1989], ils 1) calculent la similarité sémantique entres les documents dans l’espace d’information, créant ainsi une structure hypertextuelle indépendante de l’outline hiérarchique ; 2) clustérisent des nœuds à partir des distances sémantiques qui existent entre eux pour proposer un accès alternatif et automatique aux ressources dans le système ; 3) extraient des mots-clé de chaque article, dossier et profil d’utilisateur pour les passer, par le biais de l’agent de recherche et à travers le protocole SOAP, à Google ; les documents remontés par le moteur de recherche sont, par la suite, téléchargés, vectorisés et comparés avec le vecteur du document de départ afin de reclasser les résultats selon la « perspective » sémantique (lexicale) représentée par l’ensemble des documents dans la base. Cela permet de faire usage du vaste index du moteur commercial sans pour autant se livrer complètement à son algorithme de ranking. Nous comprenons ce geste comme une sorte de « contre-lecture » [Hall 1980] algorithmique du texte proposé par Google. Au lieu d’accepter les résultats en tant que tels, ils sont, dans le cas du contexte d’un nœud, rerankés ou, dans le cas de la recherche « manuelle », classés dans la structure des dossiers élaborée par les usagers. Dans le deuxième cas, l’outline prend la fonction d’une ontologie (dans sons sens informatique) primitive.