Introduction
Le travail sur les fonctionnalités des diverses infrastructures étudiées dans cet ouvrage (voir chapitre Caractéristiques de quelques infrastructures de dépôt de données de la recherche) et celles existantes d’ISIDORE et NAKALA (voir chapitre Les plateformes ISIDORE et NAKALA) ont permis de réunir un groupe de travail ayant en charge de la rédaction du Cahier des clauses techniques particulières (C.C.T.P) pour le programme HNSO. Les fonctionnalités travaillées le sont dans un double objectif définissant un C.C.T.P organisé en deux parties comprenant:
Les fonctionnalités impactant les front-office (correspondant ainsi aux interfaces Web utilisées par les utilisateurs, en mode connectés et non-connectés)
Les fonctionnalités impactant les back-office (correspondants aux interfaces Web utilisées par les gestionnaires et l’équipe d’Huma-Num) d’ISIDORE et de NAKALA.
Cet ouvrage et le C.C.T.P à venir alimentent ainsi la feuille de route d’ISIDORE et NAKALA.
Contexte administratif et organisationnel
Le code de la commande publique 1 fixe le cadre réglementaire pour “les contrats conclus à titre onéreux par un acheteur ou une autorité concédante, pour répondre à ses besoins en matière de travaux, de fournitures ou de services, avec un ou plusieurs opérateurs économiques.” C’est dans ce cadre réglementaire que s’inscrit le Cahier des clauses techniques particulières (C.C.T.P). C’est un document contractuel qui fixe les clauses techniques nécessaires à l’exécution des prestations du marché. Il n’existe pas de modèle, de standard ou de norme ISO qui précisent les rubriques qui doivent figurer dans un C.C.T.P. A titre d’exemple on pourra consulter le C.C.T.P rédigé par la Mission de l’Information Géographique du Ministère de l’Ecologie, de l’Energie, du Développement Durable et de la Mer 2 pour le développement de l’application informatique PRODIGE ainsi que le C.C.T.P rédigé par la TGE Adonis pour la réalisation du moteur de recherche ISIDORE.
Rappelons que le C.C.T.P originel de la plateforme ISIDORE a été rédigé en 2008-2009 par une équipe du Très grand équipement Adonis assistée par une équipe de consultants de la société ATOS Consulting (Pouyllau et al. 2012).
Le programme HNSO se situe dans un contexte différent. Premièrement, les développements informatiques spécifiques au projet seront en partie réalisés en interne par le pôle ACCES de la TGIR Huma-Num et en partie par des prestataires de services. Deuxièmement, ces développements doivent s’inscrire dans la continuité des services existants, c’est à dire ISIDORE et NAKALA. Troisièmement, les besoins qui seront déclinés sous la forme de nouvelles fonctionnalités sont issus de différentes sources. Une première source émerge des travaux du Huma-Num Lab. Une seconde source émerge d’un dialogue avec les utilisateurs et les consortiums. Une troisième source émerge des travaux de la mission “Données” de Huma-Num. Une quatrième source émerge du pôle ACCES en charge du développement en continu et de la maintenance corrective d’ISIDORE et NAKALA.
Cette configuration organisationnelle matricielle, qui pourrait être une source de tension, nous a conduit à mettre en place une méthode de travail qui vise à minimiser, voire à supprimer, les conflits inhérents à des points de vue métiers qui ne privilégient pas toujours les mêmes critères de succès dans un environnement humain, financier et institutionnel contraint.
Méthode de travail
Il existe une abondante littérature sur le génie logiciel (Bass, Clements, et R.Kazman 2013; Bourque et Fairley 2014; Boehm et Turner 2003; Clements et al. 2010), sur les nombreux standards sur la qualité logicielle (IEEE Std. 730, ISO 25010 de la série de normes ISO 250xx, également appelée SQuaRE pour software quality requirements and evaluation), sur le cycle de vie du logiciel (ISO/CEI/IEEE 12207) et plus spécifiquement sur des normes et des rapports techniques (ISO/CEI 29110) qui visent les très petits organismes de moins de vingt personnes qui développent des systèmes d’information. Si toutes ces approches capitalisent de nombreux savoirs issus des années de pratiques, elles présentent néanmoins des risques en termes de charges organisationnelles, documentaires et sont potentiellement porteuses de sources de conflits (Longchamp 2015), notamment dans les petites organisations dans lesquelles le “donneur d’ordre” se confond avec le “client”.
Tout en s’inspirant de ces approches, notre méthode de travail s’appuie sur un dispositif socio-technique, un Gitlab, qui est le médiateur, au sens que lui donnent Akrich (1992) et Latour (1996), entre les différents acteurs qui contribuent au programme HNSO3. Le Gitlab va ainsi médier les deux approches, ascendante et descendante, du génie logiciel. L’approche descendante part de l’expression des besoins, étape pendant laquelle les besoins ou exigences sont exprimées sous la forme de phrases en langage naturelle par une équipe métier orientée besoin utilisateur (documentaliste, utilisateurs expérimentés des services, utilisateurs potentiels des services, chargé d’étude, membres de la direction de l’organisation) ( Figure 1.1). Cette approche descendante est fortement guidée par une vision de la cible à atteindre et par la volonté de fournir des services innovants aux futurs utilisateurs. Elle ignore en général les contraintes d’architecture logicielle et technique des services existants ainsi que les dépendances plus ou moins fortes entre des composants logiciels exploités par les différents services.
L’approche ascendante part de “tickets” (issues) de maintenance ou de constats d’absence de fonctionnalités recueillis par l’équipe métier en charge du développement logicielle (développeur, chef de projet, architecte logiciel). Cette approche ascendante est fortement guidée, pour ne pas dire contrainte, par différents facteurs. D’une part, par les fortes dépendances entre les composants logiciels existants et ceux à développer, et des choix d’architecture technique qui peuvent dépendre des préférences et des compétences des membres de l’équipe. D’autre part, par les contraintes temporelles des délais de réalisation et les disponibilités en ressources humaines.
Le Gitlab comme médiateur
La plateforme Gitlab s’est imposée au coeur du fonctionnement du projet et de la réflexion collective. Git et Gitlab projettent ensemble des protocoles et une série de fonctionnalités vertueuses pour la mise en place d’une dynamique collaborative de production de connaissances. D’une part, les fonctionnalités de l’outil, documentent la chronologie dans la production des écrits (code, texte, commentaires, etc.). D’autre part, l’outil est utilisé conjointement par les développeurs et les membres du projet. Nous discutons ici les éléments constitutifs de cette dynamique, avant de présenter le protocole et la méthodologie adoptés au sein de l’équipe pour répondre aux problématiques du projet [IN].
Le protocole Git
Le premier principe de Git est celui de l’inscription systématique dans un registre de toutes les contributions apportées à un texte (que celui-ci soit composé de code informatique ou d’un texte balisé par exemple) de manière incrémentale et non-réversible. Une contribution consiste en :
une série de modifications sur le texte travaillé collectivement : ajout, suppression, remplacement;
la documentation de ces modifications dans un message de validation (commit).
Ces principes de systématicité, d’incrémentation et d’un retour en arrière ou d’un effacement impossible (ou trop complexe à opérer) établissent de fait un cadre relativement rigide pour une co-écriture raisonnée.
Le second principe de Git est celui de la fusion dont le terme renvoit en informatique à la forge désignant les systèmes de gestion de maintenance collaborative de texte4. L’état d’un fichier à un commit donné correspond en fait à la fusion de toutes les modifications précédentes. Le protocole Git fait en sorte de n’inscrire en mémoire que les modifications apportées d’un état à un autre. Ainsi, l’historique de ces modifications permet en théorie de retrouver la génétique d’un texte au caractère près, modification après modification. Dans un contexte éditorial, que ce soit pour un texte scientifique, une édition savante, ou l’encodage d’un corpus dans un format donné, Git offre ainsi un protocole collaboratif particulièrement fiable, garant de la scientificité de la production.
Il faut noter par ailleurs que le protocole Git n’assure que les tâches de bas-niveau d’enregistrement, de fusion et de synchronisation. Mais ces contraintes sont incitatives à ce que les contributeurs et les contributrices d’un projet négocient et adoptent une méthode de travail collectif, autrement dit un protocole éditorial, qui leur sera propre. Ce protocole de plus haut niveau relève alors de la méthodologie scientifique, reflétant nécessairement les pratiques instituées du groupe, de la communauté ou de la discipline concernée.
La plateforme Gitlab
Au-delà de ces aspects liés à l’écriture partagée d’un texte, Git est généralement enchassé dans une plateforme plus large, comme Github, la plateforme la plus populaire de partage de code, ou encore Gitlab, plateforme équivalente développée en OpenSource. Le projet [IN] s’est appuyé sur l’instance Gitlab mise à disposition par Huma-Num pour la communauté de recherche SHS. Or Gitlab, comme Github, propose au-dessus du protocole Git une série de fonctionnalités et de services qui repoussent les usages possibles de la plateforme bien au-delà du simple partage de code. Gitlab peut être considérée comme une véritable plateforme communautaire entièrement tournée vers la collaboration.
Listons quelques-unes de ces fonctionnalités:
issues, board, milestones: ces fonctionnalités permettent une véritable gestion de projet avec la description, la caractérisation, l’organisation, l’attribution de tâches, auxquelles sont associées une discussion et un suivi de la production. À nouveau pour ces fonctionnalités élémentaires, l’équipe de travail est libre d’adopter ses propres modalités d’usage, adaptées aux besoins du projet.
wiki, snippets, readme: ces différents espaces d’écriture sont destinés à la documentation du projet, de son protocole et de ses données, ainsi qu’à la circulation de fragments de code ou d’éléments d’information à l’usage récurrent. Ces fonctionnalités s’accordent avec les besoins en documentation et en circulation de l’information propres aux approches collaboratives. La progression de ces dernières s’est en effet accompagnée d’un développement des pratiques de documentation, essentielles à la cohérence et à la pérennité du collectif.
fork, branch, pull request, merge: ces actions sont spécifiques au protocole Git, c’est-à-dire qu’elles constituent des inscriptions particulières au registre d’un répertoire de travail. Elles assurent la gestion collaborative des fichiers et des modifications, en permettant l’appropriation du répertoire, la soumission et l’évaluation par les pairs d’une contribution, la distribution des tâches d’évaluation, de correction et de validation.
history, blame, graph: ces fonctionnalités proposent diverses représentations (listes, log, comparateur ligne à ligne, visualisation en graphe des branches et des commits) des actions menées sur un répertoire. Ces représentations s’appuyent sur l’interprétation des données liées à chaque action (horodatage, identifiant interne, auteur d’une action, etc.). Dans la dynamique collaborative, ces fonctionnalités sont essentielles en cela qu’elles consolident et synthétisent les activités unitaires en une activité collective.
l’éditeur de texte, basé sur le format markdown, intègre une micro-syntaxe facilitant à l’extrême la mise en relation de tous les objets de la plateforme : contributeurs, fichiers, issues, commit, pull-request. Or cette mise en relation, qui se traduit par l’intégration automatisée d’hyperliens vers les différents objets, établit les conditions d’une nouvelle forme de collaboration, basée sur la densification du maillage entre les objets et sur un suivi distribué des actions de chaque utilisateur.
Comment cette mise en relation fonctionne-t-elle concrètement ? Chaque action sur la plateforme génère une inscription, soit au registre Git, soit à la base de données Gitlab :
un commit demande un message de validation documentant les modifications effectuées. Il est possible dans un message de commit de mentionner un contributeur, une issue, ou un pull request ;
de même dans une issue, il est possible de mentionner un contributeur, un commit ou une pull request ;
la nomemclature de nommage des branches permet de créer des liens entre une branche et une issue ;
etc.
Ainsi, quel que soit le lieu d’où l’on écrit dans l’environnement Gitlab, il est possible de mentionner et ainsi de lier les éléments entre eux. En conséquence, chaque élément mentionné se voit notifié de l’usage qui en a été fait. L’historique d’une issue liste ainsi toutes les activités liées à l’issue, c’est-à-dire, les actions dont la documentation mentionne l’issue (commit, issue, pull-request, etc.). Ce “logging” hyper-reliant permet à une équipe de partager la même vision de l’état d’avancement d’un projet. Fondamentalement, ces marqueurs permettent à chaque contributeur ou contributrice de se positionner dans les actions du collectif.
Fort de ces fonctionnalités collaboratives, l’équipe de HNSO a mis en place un protocole de travail dédié, afin de faciliter la dynamique contributive d’une part, et de transformer celle-ci en une production de connaissance itérative.
Processus de création de fonctionnalités dans le projet ISIDORE et NAKALA pour la Science Ouverte
Le processus mis en place pour l’ajout de fonctionnalités (Figure 1.2) dans ISIDORE et NAKALA a suivi plusieurs phases:
Phase d’identification: la fonctionnalité est identifiée dans un atelier C.C.T.P ou hors d’un atelier C.C.T.P. Elle peut répondre à un besoin interne ou à une demande externe. Elle est décrite dans le pad collaboratif HNSO.
Phase de création de l’issue: une fonctionnalité identifiée est transformée en issue dans le Gitlab HNSO C.C.T.P. Elle doit être décrite dans les grandes lignes avec la template5 prévue à cet effet.
Phase de révision de l’issue: l’issue créée passe en révision par les différents membres de l’équipe C.C.T.P. L’issue peut être écartée du projet si elle sort de son périmètre. Le Pôle ACCES propose une estimation du temps de réalisation de l’issue.
Phase de sélection et planification des issues: toutes les issues révisées sont compilées, triées puis planifiées en vue de leur réalisation.
Phase d’inclusion dans le C.C.T.P et validation de la faisabilité: la compilation d’issues sélectionnées est éditorialisée dans le C.C.T.P puis le plan de travail élaboré doit être validé sur sa faisabilité technique, documentaire et budgétaire avant de passer à la phase de réalisation. Les issues validées peuvent alors être éditorialisées dans le C.C.T.P. Les issues non validées repartent en phase de révision.
Phase de réalisation de l’issue: la compilation d’issues est sous la responsabilité du Pôle ACCES qui rédige les spécifications fonctionnelles pour entrer en phase de réalisation et donner naissance aux fonctionnalités.
Les issues sont classées dans des “grandes tâches” nommés “Clusters”. Ainsi, la granularité pour établir une planification de la réalisation technique ne se situe pas au niveau de l’issue. Cette option a l’avantage de ne pas exiger une trop grande précision sur les temps de développement, et de permettre une plus grande flexibilité sur l’organisation des temps de réalisation technique pour l’équipe du pôle ACCES.
L’équipe projet a identifié 4 clusters (Figure 1.3):
Qualité
Complémentarité ISIDORE/NAKALA
Facilitation des usages SHS
Visualisation de données.
Le cluster Qualité vise à l’amélioration de la qualité des métadonnées et de la découvrabilité des données grâce à l’optimisation des outils d’assistance à la recherche d’information.
Le cluster Complémentarité ISIDORE/NAKALA vise à la création de liens et et au renforcement des articulations entre les 2 plateformes pour augmenter la découvrabilité des données.
Le cluster Facilitation des usages SHS propose des fonctionnalités qui permettent de répondre aux besoins des chercheurs SHS vis-à-vis de leur utilisation des plateformes.
Le cluster Visualisation des données vise à proposer
des outils de paramétrage et de configuration de la visualisation des
données.
Conclusion
Au travers de ce travail prospectif pour l’implémentation de nouvelles fonctionnalités, les plateformes ISIDORE et NAKALA pourront connaître une importante amélioration de leur interface sur les aspects front et back office. Il est important de souligner l’intérêt de Gitlab comme médiateur pour faciliter le travail collaboratif au sein d’une équipe multidisciplinaire comme celle de la TGIR Huma-Num. Les fonctionnalités à implémenter sont décrites dans le C.C.T.P. Il y a actuellement 37 fonctionnalités, réparties dans les quatre clusters, qu’il conviendrait d’intégrer au calendrier de développement informatique des deux plateformes.
Références
Disponible à l’url: https://www.legifrance.gouv.fr/codes/id/LEGITEXT000037701019/↩︎
Disponible à l’url: https://page.hn/if5emz↩︎
Cette méthode a été élaborée en juin 2021 pendant une réunion de travail qui réunissait Mélanie Bunel, Laurent Capelli, Adrien Desseigne, Hélène Jouguet, Jean-Luc Minel, Stéphane Pouyllau et Nicolas Sauret.↩︎
Selon Violaine Louvet : « L’objectif d’une forge est d’offrir un espace d’échange permanent et de collaboration en ligne aux développeurs de logiciels, et un espace de distribution (versions publiques des logiciels développés : paquets sources, pages web) pour les utilisateurs (pour tout un chacun si la forge est publique). Elle permet ainsi de rassembler des projets et des développeurs, mais aussi d’autres personnes travaillant sur ces projets (utilisateurs, traducteurs…). » (Source : PLUME - https://www.projet-plume.org/ressource/faq-forge↩︎
Les champs de la template complète sont décris dans le C.C.T.P↩︎