$for(author-meta)$ $endfor$ $if(date-meta)$ $endif$ $if(keywords)$ $endif$ $for(css)$ $endfor$ $if(math)$ $math$ $endif$ $if(toc)$ $endif$

title: Corps du rapport de stage LP MIND
author: Guillaume Brioudes https://myllaume.fr/

Cette année universitaire en licence professionnelle Médiation de l'information numérique et des données a été un déclencheur sur tous les plans : personnel, estudiantin et professionnel. Je suis sortis de deux ans de formation en DUT Métiers du multimédia de de l'internet, plus comme un exécutant qu'un technicien ; avec un savoir-faire déconnecté de mon outil et de mon matériau. Cette année j'ai trouvé une intention, un dessein dans une pratique plus mature de la programmation : instancier un environnement numérique et non plus simplement développer une interface.

Cela s'est déroulé en plusieurs temps. D'abord trouver les notions documentaires, fondamentales sur le web, et observer, travailler la donnée. En abordant respectivement à l'échelle macro puis micro l'information, j'ai pu appréhender tout à fait différemment les outils que je devais développer. Ensuite, nous avons critiqué nos usages de l'informatique faisant écho à la culture web, à celle de nos métiers, la médiation. Dans un dernier temps j'ai pu largement réviser et aborder sous un angle différent plusieurs notions, parfois acquises. Je vous propose de revenir en détail sur différentes expériences d’enseignement dans une première partie de ce rapport.

Le dernier temps de cette formation a été le stage. Comme à l'issue de mon DUT — pour ce second stage en développement web — ça a été une période de remise en question de nombreuses compétences et connaissances. Si l'on revient sur les deux premiers temps de formation évoqués précédemment, j'ai effectué en stage un travail interdisciplinaire, entre la documentation et la gestion de données, tout en mettant en application les nouveaux outils informatiques que l'on m'a apportés durant l’année. Nous évoquerons cette expérience dans la deuxième partie de ce rapport.

Ma venue en licence professionnelle MIND a été motivée par le désir de changer de voie, sans changer de métier. Je voulais rester développeur dans la perspective d'œuvrer à l'intégration web de bases de connaissances et non pas de marchandises. Cette année a été porteuse de nouvelles compétences dans ce sens. Elle m'a aussi permis de mettre des mots sur certains concepts, certaines notions que j'avais pressenties, mais sans arriver à les expliquer. Avec ce nouveau bagage, j'entrevois comment en tant que développeur web je peux aborder les enjeux de l'information numérique. J'aimerais pour cela me préparer dans une ultime session, en master Document numérique et humanités digitales, avec l'intention d'obtenir une spécialité en ingénierie documentaire, en parallèle de ma pratique principale de développeur web. Nous terminerons ce rapport en évoquant mon projet professionnel tel que je peux désormais l’envisager.

Enseignements

Cette année est la dernière de mon premier cycle universitaire. Si les études professionnelles ont vocation à mettre l’accent sur la pratique plutôt que les cours théoriques, j’ai trouvé cette année un excellent équilibre, ainsi que le prolongement de ce que j’avais débuté deux ans plus tôt.

Retour sur les compétences du DUT

Le DUT Métiers du multimédia et de l'Internet m'a formé dans principalement deux domaines majeurs : l'infographisme et le développement web ; ainsi que dans deux domaines mineurs : la communication des organisations et l'audiovisuel. Sur ces quatre domaines j'ai pu revenir brièvement cette année, toujours avec des exercices pratiques.

En audiovisuel et photographie nous avons effectué des travaux sur l'interview, un mode que je n'avais pas encore pratiqué, qui plus est avec un matériel et des logiciels inconnus. C’était un retour frais sur ce que j’avais déjà pu apprendre avec des enseignants aux compétences nouvelles : mes enseignants de cinéma et audiovisuel précédents n’étaient pas photographes et ne nous faisaient pas pratiquer un genre journalistique. J’ai pu réviser le cadrage, la lumière et apprendre de nouveaux éléments théoriques. J'ai également retrouvé les outils Adobe pour quelques travaux et les précieux conseils de Monsieur Stéphane Caro et Monsieur Clément Borel. Lors des cours de base de données, j’ai pu réviser mes bases théoriques et découvrir le logiciel Access.

Finalement, revenir sur des notions et pratiques du mon DUT aura toujours été l’occasion de réviser et d’apprendre quelques nouvelles compétences.

Vers les notions documentaires

Pour trouver la licence professionnelle j’ai commencé par chercher sur le web « licence professionnelle base de données ». Mon stage de fin de DUT me l’avait clairement fait comprendre : c’était vers cette voie que je devais aller. J’avais en entreprise travaillé quelques interfaces – tant côté code que côté utilisateur – reliées à des bases de données et cela m’avait fasciné de voir ce qui était possible de réaliser en terme d’affichage, d’automatisation, mais aussi d’architecture. Avec cette requête, j’ai trouvé des formations, mais logiquement orientées vers l’ingénierie informatique. C’était trop éloigné du web, de ses langages et de ses desseins.

Ensuite, j’ai cherché « licence professionnelle secrétariat », domaine que j’ai pu rapidement entrevoir dans mes expériences associatives, seconde intuition professionnelle. J’occupe en association un poste de « centralisateur-passeur d’information », de médiateur, mais je ne connaissais pas le terme. Toutefois, ce sont des formations encore une fois logiquement orientées vers les ressources humaines et/ou financières. J’ai trouvé la requête « licence professionnelle documentation » après avoir fait une dernière fausse route vers « journalisme » pensant que c’était là que j’aurais pu écrire de l’information et la diffuser sur le web – ce qui a toujours été mon intention.

Tout ce temps il m’a manqué l’idée de médiation. Les interfaces superposées aux architectures logicielles rejoignent les besoins documentaires des organisations sur l’axe de la médiation de l’information numérique. J’ai appris à ne pas me contenter d’extraire une information, mais d’imaginer sa valorisation, sa rencontre avec l’usager (éditorialisation).

Documentation

Je n’avais jamais parlé de documentation auparavant. Mes enseignants de DUT avaient évoqué les ontologies lors des cours sur le référencement web, mais trop brièvement pour que je comprenne l’importance de ce sujet, encore moins du web sémantique.

Avec Monsieur Christophe Dubois, nous sommes revenus sur des notions fondamentales de base de données là où je ne m’y attendais pas : identifiants (ISBN, ISSN etc.), espaces de nom (ontologie, thesaurus), classement (« vues » de base de données) et valorisation. Le cours sur les métadonnées de Monsieur Arthur Perret est venu fixer ces liens entre documentation et bases de données avec en plus une ouverture vers le web sémantique. Avec Monsieur Olivier Le Deuff j’ai aussi pu reconsidérer, nommer, de nombreuses pratiques que je poursuivais en association. Il s’agit des étapes de vie du document, de ses formats et utilisation. Tout cela avec beaucoup de nuances entre les différents métiers de la bibliothéconomie.

Mon premier apprentissage fondamental aura été de comprendre que ces métiers sont à l’origine de nos pratiques numériques modernes, donc avec une influence sur les pratiques de développement web. Pour améliorer mes compétences en programmation, il fallait aussi que je revienne sur cette histoire du traitement documentaire afin de prendre du recul.

Nous avons aussi eu l’occasion de pratiquer l’édition micro-documentaire transcanal avec monsieur Jean-Christophe Bouniol. Ce cours a fonctionné comme un projet : pendant un mois nous avons publié, tous les jours, dans la continuité d’une ligne éditoriale de médiation, mais surtout pour différentes plateformes. C’était pour moi une nouvelle manière de rencontrer un problème complexe fait de multiples interfaces avec une variété d’utilisateurs. Ce sont autant de facteurs qui déterminent le contenu. C’est cette même problématique que nous avons rencontrés lors des deux premiers projets de l’année.

Le premier projet était commandé par l’équipe pédagogique. Deux équipes de six étudiants devaient fournir différents contenus formant un dossier au sujet des villes intelligentes (« smart cities »). Il s’agissait d’une série de rapports : un format long pour expliquer le sujet, un classement de villes intelligentes selon des critères et indicateurs choisis et enfin le rapport d’une extraction de pages web sur le sujet. Enfin, il fallait fournir une vidéo. C’est de ce dernier produit dont je me suis chargé ; j’ai enregistré ma voix par-dessus une présentation PowerPoint animée. Le nombre important de livrables à rendre en une semaine a forcé les groupes à se répartir la réalisation selon les spécialités de chacun, cultivant des compétences propres – c’était pour moi l’occasion d’utiliser PowerPoint d’une autre manière, pour produire du contenu vidéo. Finalement, nous avons tous pu en apprendre plus sur les villes intelligentes, ce qui nous a permis de mieux comprendre les enjeux du troisième et dernier projet de l’année.

Le deuxième projet était une commande de Monsieur Vincent Bergeot. L’Éducation Nationale a décidé de former les élèves du secondaire à la contribution sur OpenStreetMap tandis que les enseignants ont été peu ou non formés à son utilisation. L’objectif était de créer des guides tant pour les enseignants que pour les élèves afin de faciliter l’utilisation de OpenStreetMap et de ses différents services. Je me suis principalement occupé du site type wiki qui a été mis à disposition. J’y ai rédigé une série de tutoriels à destination des enseignants ainsi qu’un outil pour se téléporter sur la vue satellite d’une ville au hasard dans trois pays européens et ainsi y contribuer.

Données

J’ai retrouvé les données sous différentes formes : graphique, structuré, non structuré ou encore invisible. Nous avons travaillé tant sur leur exploitation que leur représentation et par différents moyens. Si la partie logicielle parcourue avec monsieur Amar Lackel (R, RStudio et MyWebIntelligence) a été la plus complexe à saisir, c’était la première fois que j’arrivais effectivement à « brasser » une masse importante de données. Une expérience renouvelée avec monsieur Clément Borel sur OpenRefine et en vue d’une nouvelle pratique : la datavisualisation.

J’ai pu pleinement mettre ces enseignements cités en pratique pour le troisième et dernier projet de l’année. Il a été commandé par la société Datactivist. Il s’agissait de vérifier que certaines communes françaises publient des données d’utilité publique comme les subventions aux associations ou les horaires des transports en commune. Il s’agissait aussi d’évaluer ces données, leur degré d’ouverture, d’utilisabilité. Nous avons eu des difficultés techniques qui se sont transformées en opportunité : le logiciel censé nous permettre de mettre en place le site était obsolète et j’ai donc pu créer un équivalent en PHP. J’avais pour modèle le site https://index.okfn.org/ et ai rassemblé et traité les nombreuses données récoltées par mes camarades pour offrir une interface de lecture dynamique avec JavaScript et notamment la bibliothèque de code2 DataTables.

Ça a été ma première réalisation du genre et elle entre dans le cadre d’un terme que je découvrirais plus tard, l’éditorialisation. Il s’agit notamment de mettre en place des dispositifs de lecture, en l’occurrence le tableau et les différents témoins colorés pour présenter dynamiquement les données.

Ces différentes problématiques autour de la donnée rejoignent indirectement la dernière catégorie d’enseignement que j’ai souhaité aborder ci-après. Nous avons en effet tout au long de ces cours pris soin de stocker les données dans des formats ouverts et de les traiter avec des outils libres.

Méthode numérique

En parallèle de ma candidature à la licence professionnelle MIND, j’ai été accepté à la faculté de lettres de l’université de Strasbourg pour la deuxième année en Sciences du langage. Dans la continuité de ma baccalauréat littéraire, j’espérais pouvoir y aborder autrement les langages informatiques et y éprouver ma culture de l’écris dans l’optique de pouvoir améliorer mes méthodes de programmation et de gestion de l’information. La licence professionnelle MIND m’a permis de réaliser cela.

Nous avons fait plus que créer des fichiers, que d’utiliser des outils. Avec Monsieur Vincent Bergeot et Monsieur Arthur Perret, j’ai pu apprendre à considérer et gérer autrement mes données personnelles, mes fichiers, pour arriver à une certaine « hygiène numérique ». Cela s’est fait progressivement et en profondeur.

Culture du logiciel libre

Cette critique de nos usages a d’abord été portée par Monsieur Vincent Bergeot. Nous avons évoqué nos outils de stockage, d’inscription et de représentation de la donnée. Ainsi, il nous a largement fait part de son engagement pour le logiciel libre et la protection de la vie privée qui m’a personnellement beaucoup influencé. L’idée de retrouver une autonomie informatique, de se forcer à investir davantage son outil m’a semblé essentielle, surtout en tant que professionnel du domaine en formation.

Pour la mise en application, j’ai d’abord entièrement abandonné l’écosystème de Microsoft que j’avais pleinement adopté deux ans plus tôt. Je rédigeais mes textes et mails, concevais mes tableurs et présentations avec la suite Office. Je les stockais dans le cloud OneDrive et gérais mes mails sur le service Outlook. La séparation a été radicale : j’ai installé un service cloud* libre (Pydio) sur mon propre serveur web depuis lequel je gère mes mails et ai commencé à utiliser les logiciels de la suite LibreOffice. Pour ce dernier point, j’ai clairement été mis en difficulté par l’interface chaotique.

Organisation de l’information

En parallèle de son enseignement sur les métadonnées, et plus tard durant mon stage, Monsieur Arthur Perret a été d’une grande aide pour mettre en place un nouveau système de gestion de connaissances souple et robuste. D’abord souple dans sa capacité à s’adapter aux nombreux langages et logiciels libres existants, puis robuste par sa nature, plein texte, pour des applications pérennes.

Il s’agit notamment d’aller plus loin dans la critique des logiciels de traitement de texte (Word, Writer, Pages etc.). S’ils sont pour la plupart propriétaires, même les libres fournissent des fichiers à la fois complexes et opaques, incompatibles avec la démarche d’« hygiène numérique » que j’avais débuté. À l’inverse, les fichiers plein texte sont exactement à l’image de ce qu’on en fait. C’est un matériau que je connais bien en tant que développeur et le fait de prolonger l’utilisation de mes logiciels de développement pour inscrire globalement mes textes (markdown), données (CSV, YAML) et présentation (HTML, avec RevealJs) m’a paru sein et accessible.

C’était aussi me donner la possibilité d’être moi-même l’acteur de la valorisation de ce que j’écris : développer un écosystème documentaire personnel avec des logiciels comme Pandoc, LaTeX, Zettlr, Obsidian et même un logiciel conçu par mes soins avec NodeJs. J’ai donc abandonné à son tour LibreOffice pour ne garder que mes éditeurs de texte (Visual Studio Code, BBEdit, Notepad++).

De plus, Monsieur Arthur Perret avait en cours expliqué l’intérêt et les principes de la méthode auto-documentaire du Zettelkasten que j’ai mis en place pour accumuler des fiches et visualiser une arborescence (logiciel Obsidian) de mes connaissances en humanités numériques. Je l’ai notamment utilisé pour rédiger l’article scientifique faisant suite au présent rapport.

Enfin, j’ai remis en question mes pratiques de développement web pour concevoir des architectures plus légères (lowtech). Il s’agit de générer des pages statiques (HTML et CSS brute) en déportant le travail de création des pages du serveur vers un logiciel local, sur l’ordinateur du développeur. Le traitement est ainsi effectué une seule fois, comme un cache. Ce logiciel va générer les pages ne laissant en ligne que quelques fichiers légers qui ne nécessitent ni l’intervention du serveur, ni du navigateur de l’internaute pour naviguer dans la page. C’est une économie de temps et d’énergie importante.

Organisation de la classe

La classe était très hétérogène, une vraie richesse durant les projets et travaux de groupe où nous avons pu profiter des spécialités de chacun. Certains étaient plus à l’aise à l’écrit, d’autres en réalisation multimédia. Quelques-uns ont su prendre la place de leader et guider les autres durant les projets pour ordonner le travail et croiser les idées.

Ce fut pour moi l’occasion d’apprendre à travailler avec des personnes qui n’ont pas les mêmes spécialités techniques que moi, pas le même vocabulaire et pourtant un intérêt commun. Dans ce sens il était nécessaire d’expliquer les démarches que j’ai pu proposer et de partager la conception des contenus des sites que j’ai pu développer au cours de l’année.

Stage

Pendant quatre mois j’ai pu intégrer l’équipe du projet de recherche HyperOtlet en tant que développeur web. J’étais sous la responsabilité de Monsieur Olivier Le Deuff et sous l’égide du laboratoire MICA. Mon maître de stage a veillé tout du long à un échange entre ce que je pouvais apporter à l’équipe et les compétences, opportunités professionnelles que j’allais tout au long du stage développer. Ce fut une expérience très riche et dont je ressors plus spécialisé et plus sûr de mon avenir professionnel.

Vous trouverez en annexe du présent rapport une fiche technique présentant les personnes et structures qui m’ont accueilli pour ce stage. Il débute le 22 avril 2020, décalé de quelques semaines en raison de la pandémie de COVID-19.

Télétravail

Le confinement avait débuté un mois plus tôt et le stage s’est intégralement déroulé en télétravail avec quelques rendez-vous en présentiel à partir de juin.

Équipement

Je suis resté en contact avec mon maître de stage et son équipe par mail principalement, mais aussi via la messagerie instantanée Google Hangouts qui nous a également permis de faire des visioconférences. Avec nos échanges quotidiens, toute l’équipe a pu suivre l’avancée de mon travail.

J’ai largement profité de mon installation, construite durant l’année universitaire, avec l’acquisition d’un hébergement web flexible, pour mettre en ligne mes prototypes sans encombrer le serveur dédié au projet de recherche.

Outils et pratiques

J’ai également contribué en utilisant les logiciels et pratiques acquises quelques mois et semaines plus tôt. J’ai pu réutiliser des outils découverts lors de l’année universitaire, mais aussi mettre en pratique les connaissances mobilisées en début de confinement. Il a été une période très riche où j’ai pris beaucoup de temps pour pratiquer le développement web afin de répondre aux derniers devoirs des enseignants, mais aussi à l’occasion d’un projet personnel.

Le stage a été en lui-même un temps de formation aux outils numériques, même au-delà de la pratique du développement web. Monsieur Arthur Perret et Monsieur Henry Sergent ont pris le temps de me montrer de nouveaux outils, de nouvelles pratiques. Cela m’a considérablement aidé, d’abord à organiser et ensuite à retranscrire mon travail à l’écrit. Plus largement, j’ai pu comprendre certains enjeux du projet de recherche par une exploration, voire une mise en pratique, des questions autour du document numérique.

Missions

J’ai eu durant ce stage trois missions. Elles se chevauchent avec dans un premier temps le développement de la deuxième version de l'Otletosphère, ma mission principale. L’ouverture de ce projet nous permet d’aborder la deuxième mission, le GraphLab. Le développement de l’Otletosphère a continué, se nourrissant de ce deuxième projet tandis qu’en parallèle débute la rédaction d’un article sur les outils d’auto-documentation réticulaire.

Les deux missions de développement ont été largement documentées par mes soins. Vous pourrez retrouver les deux journaux en annexe de ce rapport. Ils témoignent de la richesse des projets et de mon travail sur les données et les questions de développement.

Concernant la troisième mission, l’article scientifique qui suit ce rapport est la première partie théorique de ma contribution au papier sur les outils d’auto-documentation réticulaire. Ce fut l’occasion de confirmer mon appétence pour la retro-ingénierie des outils documentaires et la rédaction au sujet des pratiques de programmation.

Otletosphère

L'Otletosphère est un logiciel de visualisation d'une cartographie relationnelle des personnalités et institutions liées à Paul Otlet (1868 – 1944). Cet homme, son Traité de documentation, est le sujet principal du projet de recherche HyperOtlet.

Déjà-là

Tandis que l’équipe de recherche est en grande partie mobilisée pour concevoir une base de données ouverte au web sémantique, l'Otletosphère est un premier moyen de faire de la visualisation de données avec une ambition plus modeste, mais déjà une source d’interrogation. Elle questionne Paul Otlet, mais aussi les techniques (dispositifs de visualisation et de développement) qui peuvent permettre de concevoir l’expérience d’un humain de manière réticulaire.

Jean David, ancien stagiaire responsable du développement, avait déjà disposé les différents éléments qui composent le logiciel. Il s’agit de trois pages : l’accueil, la « base de données » et le « à propos ». L’accueil contient un graphe où figurent les différentes personnes et institutions gravitant autour de Paul Otlet. Des boutons permettent de contrôler son affichage : déplacement, tri des entités. Cliquer sur une entité permet de consulter sa notice : une série d’information comme son nom, ses dates extrêmes, une brève présentation. La deuxième page, présente ces mêmes personnes, mais sous forme de cartes. Elles présentent le nom, titre et une description de chaque personne au survol. Une dernière page présente les collaborateurs et institutions participant au projet.

Cahier des charges

Les différentes techniques qui ont été utilisées pour réaliser la première version de l'Otletosphère m’étaient inconnues. Aussi, le code source avait été retravaillé dans différents fichiers par plusieurs personnes avec peu de commentaires et de documentation. Monsieur Henry Sergent a alors été d’une grande aide et m’a guidé pour que je puisse comprendre le système en place. Il s’agit d’une arborescence web standard : trois fichiers HTML correspondant aux trois pages avec un fichier CSS et trois fichiers JavaScript, dont deux dédiés à l’affichage de l’accueil et le dernier dédié à la « base de données ».

L’injection des données est asynchrone entre les deux visualisations ; c’est une extraction via l’API de GoogleSheet depuis un tableur en ligne. Je propose à Monsieur Olivier Le Deuff et Monsieur Arthur Perret de retravailler l’ensemble du flux de données du projet : le tableur, les injections et la circulation. Cela pour assurer la pérennité du site, ne pouvant compter indéfiniment sur l’API de Google Sheet, et pour la lisibilité globale du projet. Il est décidé de revoir également l’interface, de la moderniser. Ainsi, tout en conservant les éléments, j’ai retravaillé tout ce qui est relatif au flux et à l’affichage. Monsieur Olivier Le Deuff m’a accordé une grande liberté pour les choix d’interface et de documentation me permettant de proposer des solutions que les collaborateurs ont quotidiennement pu questionner, améliorer.

Plus tard, l’équipe a souhaité rendre le code source de ce logiciel public et mettre en place une documentation afin de faciliter la réutilisation globale et la modification du projet.

Contribution

J’ai tout d’abord remis en place les éléments de la première version, à commencer par le graphe et les outils de filtre. J’ai réutilisé la même bibliothèque de code que Jean David, VisJs et ai rapidement retrouvé un résultat semblable. J’ai également affiché la barre latérale (notice) et la liste des entités (la « base de données ») sous forme de cartes. La disposition des éléments est alors la même que pour la première version du site avec une injection cette fois synchrone vers le graphe et les cartes.

La commande la plus urgente a été l’ajout d’un moteur de recherche pour retrouver rapidement une entité dans le graphe. J’ai recouru à une deuxième bibliothèque de code, FuseJs. Elle permet d’explorer rapidement un tableau de données d’après une requête en suggérant des entrées proches de la saisie. Très rapidement j’ai pu présenter ce programme, bien inscris dans le flux : filtrer les entités du graphe influence également les résultats de recherche.

Une fois les éléments disposés, j’ai proposé une première interface. J’ai trouvé pertinent, tant pour des raisons esthétiques que pratiques, d’empiler ce qui était trois pages séparées. Cela rend l’interface dynamique, agréable à utiliser. Il est plus aisé de faire des renvois entre le graphe et la « base de données » (désormais section « Fiches »). Enfin, cela simplifie le développement qui en centré non pas sur la conception d’une interface, mais sur un flux de données permettant de générer les différents affichages. La question esthétique est arrivée en dernière.

Des fonctionnalités ont été ajoutées pour rendre la lecture du graphe plus interactive avec des effets au survol et à la sélection. J’ai pu proposer quelques ajouts supplémentaires comme la gestion de l’historique du navigateur, actualisé à chaque changement d’entité, avec la possibilité d’aller et venir via les commandes du navigateur. J’ai également lié les affichages « Réseau » et « Fiches » : cliquer sur une des cartes provoque un zoom sur cette même entité dans le graphe.

Cette deuxième version du site est beaucoup plus interactive au détriment de l’accessibilité depuis les petits écrans. Avec la bibliothèque Bootstrap, j’ai pu rapidement rendre la page plus flexible, mais non pas responsive.

Le code est alors contenu dans une multitude de fichiers concaténés en un seul et cela grâce à l’outil de développement GulpJs. J’ai ainsi pu isoler les programmes et réduire la charge mentale du développement, tout en assurant un chargement rapide du logiciel par l’utilisateur. Afin de rendre la lecture du code plus aidée, j’ai recouru à la notation orientée objet3. Au niveau des données, elles sont extraites de fichiers JSON exportés depuis le tableur complété par les collaborateurs. La mise à jour des données est certes plus complexe4, mais aussi pérennisée et adaptée à un logiciel ouvert.

Le code a été déployé en libre accès sur GitHub qui héberge également la documentation. Elle contient différents tutoriels pour mettre en place l’outil de développement GulpJs et modifier les fonctionnalités centrales comme le remplissage des données, la traduction, la modification du volet etc..

Tout au long du stage, le code a été refactorisé au fil de mes découvertes et essais. L'Otletosphère pour sa deuxième version est une réussite approuvée par l’ensemble de l’équipe, après deux mois de développement. C’est pour moi un projet très enrichissant et dont je suis fier.

GraphLab

Suite à l’ouverture du projet Otletosphère est venue l’idée de le réutiliser afin de représenter les équipes de laboratoires scientifiques – une autre cartographie relationnelle. Pour ce nouveau projet on réutilise certains programmes de l’Otletosphère.

Cahier des charges

Ce nouveau projet doit tout comme l’Otletosphère être ouvert. L’objectif est de le proposer à différents laboratoires pour qu’ils puissent présenter leur équipe.

Contrairement à l’Otletosphère les différentes personnes ne vont pas graviter autour d’une entité. Par la nature du projet, on sait qu’elles sont liées au laboratoire. Les liaisons vont davantage retracer les collaborations directes. Il peut d’agir de la rédaction d’un article commun, du travail collaboratif sur un projet de recherche. Ainsi il sera possible pour l’utilisateur de considérer les liaisons internes du laboratoire.

Pour chaque personne on pourra présenter les différents sites institutionnels (HAL, Cairn, theses.fr, Researchgate etc.) et index d’autorité (Wikipedia, IDRef, Google Scholar etc.) sur lesquels elle est présente. Ainsi, l’utilisateur pourra exploiter un double maillage, à la fois interne (graphe) et externe depuis une modale (boîte de dialogue).

Si l’affichage « base de données » de l’Otletosphère est conservé pour afficher les différents projets et articles (à l’origine des liaisons de graphe) réalisés par le laboratoire, un nouvel affichage sous forme de cartes fait son apparition. Selon leur titre, une carte dédiée à chaque personne est placée sur une pile dédiée. Il est possible de déplier la pile ou simplement de faire défiler les cartes. Ainsi, l’utilisateur peut davantage se concentrer sur les personnes que sur leurs relations dans une interface plus sobre.

Architecture

La principale difficulté a été l’architecture du projet. Contrairement à l’Otletosphère, le GraphLab n’est pas présenté sur une page unique, mais sur trois pages, une pour chaque interface. Or la modale doit être affichée sur les interfaces « graphe » et « cartes ». L’interface « références » est isolée, accessible uniquement lorsque l’on indique depuis la modale vouloir consulter les références d’une personne. Or les données concernant les liens (d’une personne à une référence et réciproquement) entre les personnes sont utiles pour générer le graphe, la modale, mais inutiles pour les cartes et la liste des références. Or il serait complexe (limitant donc l’ouverture du projet) de créer un programme pour chaque interface, plus un quatrième pour la modale ; le logiciel complet doit être un tout cohérent. J’ai dans un premier temps ignoré cette dernière problématique pour me concentrer sur l’affichage.

Une fois l’affichage réalisé, j’ai cherché un moyen de rendre le logiciel cohérent. À côté du stage j’avais décidé de m’auto-former à NodeJs, logiciel formidable dont l’API est en JavaScript, augmenté de quelques fonctionnalités comme le require. Il s’agit dans un premier fichier (un module) de développer un programme court, de l’exporter et de le récupérer dans un autre fichier (matrice, cible de nombreux modules). Ainsi, depuis la matrice, il est possible de faire appel ou non, un fois ou plus, à des programmes isolés. C’est le degré extrême de la programmation orienté objet, quand les class deviennent des éléments physiques (sous la forme d’un fichier) appelés à volonté. Malheureusement, ce comportement n’est pas natif de JavaScript, et inconnu de la plus part des navigateurs web.

La bibliothèque RequireJs permet d’imiter ce système. Je l’avais approché avec GulpJs sur l’Otletosphère, mais une simple concaténation des fichiers ne suffit plus dès lors qu’il s’agit de contrôler l’ordre et l’import des programmes au sein du logiciel et non plus via un outil externe qui complique le développement en requérant une compilation à chaque modification et une maintenance régulière. L’API de RequireJs est très simple et d’une grande efficacité. Pour chaque affichage, un fichier « main.js » (matrice) appel les différentes dépendances (modules) nécessaires. Par exemple, le programme (module dédié) de la modale appel directement le module de chargement des données : la modale est indépendante d’un échec de chargement des données dans l’affichage « graphe » ou d’un appel des données particulier comme dans l’affichage « cartes ». De plus, RequireJs permet d’appeler très simplement les données depuis les fichiers JSON dédiés. Un système souple et robuste grâce à une bibliothèque et ses contributeurs et contributrices bénévoles.

Article documentation réticulaire

Le projet de recherche HyperOtlet porte notamment sur les pratiques documentaires numériques. Monsieur Arthur Perret explore largement cet axe et Monsieur Olivier Le Deuff a voulu mettre à profit ma nouvelle appétence pour le sujet et rassemblé les connaissances de l’équipe en un article. C’était aussi pour lui l’occasion de m’offrir la possibilité de co-écrire une première publication.

Cahier des charges

Je devais proposer une première version d’un article mêlant retro-ingénierie et aide à l’utilisation de logiciels. L’objectif était dans la première partie de retracer l’origine théorique de ces logiciels, de ceux qui les ont précédé, mais aussi dans un second temps d’en extraire une méthodologies pour le lecteur qui souhaiterait se lancer dans un tel chantier documentaire. Cet article sera retravaillé par l’équipe et finalement publié.

Les logiciels dont il est question sont des éditeurs Markdown. C’est un langage de balise léger prévu pour la mise en forme rapide de page web et qui convient dont très bien à la rédaction de documents en texte brute. Ce matériau présente de nombreux avantages parmi lesquels sa pérennité et sa plasticité. Ces logiciels proposent également de mettre en place une documentation personnelle réticulaire, c’est à dire une base de connaissances dont les fichiers sont reliés. Cela favorise la sérendipité, la découverte fortuite d’une idée nouvelle par la jonction d’autres.

J’ai abordé ce sujet avec des paradigmes de développement : les notions d’instance, d’objet, de dépendance, d’arborescence etc.. C’était une manière d’apporter un point de vue nouveau pour un sujet traité sur le Web principalement par des documentalistes et amateur·ice·s de développement personnel. J’ai mis à profit mes compétences en programmation et ma pratique naissante de l’auto-documentation et ainsi pu progresser sur les deux plans.

Contribution

J’ai pris un premier temps de recherche, de lecture. J’ai ainsi pu enrichir ma propre base de connaissances (mise en place quelques semaines plus tôt) en notant des idées et citations d’articles et livres. J’ai cherché et utilisé les logiciels, commencé une catégorisation et enfin débuté la rédaction.

J’ai d’abord pensé à utiliser Git pour versionner ma rédaction et à rédiger les trois parties de l’article sur des fichiers différents. Diviser ainsi la rédaction ne m’a finalement pas semblé pertinent. J’ai pensé que cela allait m’empêcher de considérer globalement mon texte et ainsi de tenir un propos cohérent.

Cet article était une occasion de présenter une méthodologie, mais aussi de critiquer la mienne. Pendant la rédaction je me suis rendu compte que je passais régulièrement d’une partie à l’autre, à saisir une idée à un endroit et à me dire qu’il fallait également que je l’introduise plus avant, différemment. Après la rédaction je me rends compte que j’avais besoin d’avoir un système modulaire, de diviser mon texte en idées pour pouvoir en appeler certaines plusieurs fois, les présenter sous différentes formes.

Ces modules, idées, étaient disposés dans ma base de connaissances. J’aurais pu davantage m’appuyer sur elle en élaborant un plan de mon texte, non pas à gros traits, mais en donnant un ordre à mes fiches. Les idées devaient être inscrites dans cet ordre pour former le texte. Ainsi, cet article aurait été une instance de ma base de connaissances. Multiplier ce type d’instance est peut-être la solution pour produire des contenus régulièrement.

Apprentissage

J’estime avoir fourni un code source à la fois lisible et pérenne en ayant franchi une étape pour inscrire un code plus abstrait. Abstrait dans le sens où, bien que le lexique soit le plus explicite possible et qu’il évoque des éléments réels, concrets, la programmation des artefacts (fonctions, objets, prototypes) est plus explicative que fonctionnelle. Je donne moins d’instructions concrètes au moteur et plus de détails sur les procédures aux humains. En effet, le paradigme de la programmation objet, largement utilisé dans le code source, est lourd (performances machine) et bavard (lecture humaine), mais rend le code « KISS » et « DRY », répondant à deux des maximes de la programmation : « Keep It Simple Stupid » et « Don't Repeat Yourself ». Gardez votre code simple et ne vous répétez pas. La programmation objet et sa version plus légère, la programmation fonctionnelle, permettent en effet de déclarer une arborescence de méthodes (fonctions) et de travailler avec des combinaisons d’artefacts plutôt que de les réécrire.

Si en DUT Métiers du multimédia et de l’Internet on m’avait introduit ces notions, c’est la première fois où je les déploie à bon escient et aussi profondément. De plus, j’ai pu faire l’expérience de la force et de la souplesse de cette architecture au cours du développement et lors du basculement d’une partie des objets de l’Otletosphère vers le GraphLab.

Dépendances

J’ai rencontré pour la première fois grâce à ce projet une cascade de besoins auxquels je ne pouvais pas répondre seul dans des délais raisonnables. Afficher un graphe, mettre en place un moteur de recherche, permettre de « requérir » un module JavaScript étaient des tâches que je devais déléguer à d’autres programmes. En effet, le résultat serait nécessairement meilleur car le fruit de travail de nombreu·x·ses développeuses et développeurs bien plus compétent·e·s que moi. L’API est dans le cas de ces bibliothèques simple et efficace, mais aussi documentée. Enfin, elles seront mise à jour et maintenue régulièrement tandis que je ne pourrais revenir sur le code à la fin de mon stage. C’est un choix qualitatif et pérenne.

La gestion des dépendances est une nouvelle logique de développement pour moi, plus centrée sur l’utilisation d’API1 et la liaison des fichiers. Si l’on ajoute la primauté de la gestion des données durant les projets, j’ai dû limiter la programmation procédurale (déclaration linéaire des instructions) car elle pouvait être la source de bugs difficiles à déceler dans la bobine d’instructions que je devais filer. Le paradigme de la programmation orientée objet est omniprésent en JavaScript et j’ai pu mettre à profit de nouvelles compétences pour développer cette architecture.

Gestion des données

Les tableaux sont certainement les valeurs les plus complexes à appréhender et gérer en programmation. Ils permettent aussi une gestion fine de données. Elles sont en effet stockées sous forme d’objets, un par entité (personne ou référence), afin de grouper les différentes métadonnées les affectant et ainsi de les appeler facilement. Face au besoin, j’ai découvert et utilisé les méthodes JavaScript filter, map et sort qui m’ont permis de gérer efficacement mes tableaux et les objets qu’ils stockent.

La bibliothèque VisJs inclut une série de programmes permettant également de gérer efficacement ces tableaux d’objets. Ce fût une aide précieuse devant une telle masse d’entité. J’ai dû développer différents programmes à la fois pour gérer les données, mais aussi les afficher et ainsi pratiquer la programmation d’orienté objet1 sur différentes strates6. Les instructions sont ainsi plus lisibles, détaillées et malléables.

Documentation de code

Durant ce stage j’ai lu et écris beaucoup de documentation au sujet de mon code. Le logiciel Python MkDocs m’a permis de mettre en ligne des explications sur le projet et instructions pour la réutilisation du code source. Monsieur Arthur Perret m’a également aidé à mettre en place un flux entre mon ordinateur et l’hébergeur de la documentation, GitHub, afin de la générer en plusieurs langues et de la mettre en ligne du même geste. Ce flux est automatisé par un script Shell, encore un nouvel outil.

Documenter le code c’est aussi le versionner, nommer les étapes du développement, les collaborateurs, l’organisation mère. Pour les deux projets de développement j’ai utilisé le logiciel Git ainsi que la plateforme GitHub. J’ai pu assurer mon travail de programmation, tester des fonctionnalités avec la possibilité d’annuler rapidement leur intégration dans le cas où elles ne fonctionnaient pas. Le code a été entreposé sur une page GitHub dédiée au projet HyperOtlet et peut y être consulté, téléchargé, dupliqué. C’est la première fois que je peux suivre ce processus de manière aussi complète.

Projet professionnel

Mes premières années d’étude supérieures ont été déterminantes pour mon projet professionnel. Je m’étais déjà intéressé au développement web avant d’entrer en DUT Métiers du multimédia et de l’Internet et cette première étape de professionnalisation a confirmé mon métier. Toutefois, les perspectives en programmation à l’issu de ce DUT se concentrent sur le secteur de la vente, du web marketing. C’est un milieu tendu par la concurrence et mes recherches de stage ne m’ont pas permis de visiter une entreprise innovante dans son domaine, prenant le temps d’interroger les pratiques de développement moderne, d’accessibilité. Mon stage de fin de cursus m’a permis d’entrevoir des pistes de réflexion, d’innovation en étant accompagné d’un spécialiste. Je me suis rendu compte que le processus de développement m’intéressait plus que les produits finaux, des sites marchands.

J’ai décidé de poursuivre mes études, peut-être par automatisme – la norme étant la licence de trois ans, et les études étant valorisante tant professionnellement que personnellement –, peut-être par crainte de ne pouvoir intégrer une entreprise qui me permette de travailler sur des projets d’utilité publique et dont la conception est optimisée pour les humains, utilisateurs et développeurs, mais aussi pour le web, les robots. Voyant arriver la fin d’un deuxième cursus, je refais le point sur mes aspirations alors que je me suis engagé dans un deuxième cycle universitaire.

Culture métier

Le développement web est une culture très particulière. J’aime mon métier pour ses pratiques, mais aussi sa communauté. Un professionnel est en permanence en train de structurer, d’écrire, de normaliser de documenter, mais on ne le fait jamais seul ; il y a toujours une développeuse ou un développeur qui s’est posé la même question que nous, un·e autre qui a apporté une solution voire une bibliothèque2 entière pour y pallier. Les développeuses et développeurs partagent souvent la culture de l’open source ou du libre et la satisfaction d’avoir un peu dompté une machine qui contrôle peu à peu l’humanité. Les femmes et les hommes qui ont créé et maintiennent la plupart des supports, langages de programmation, bibliothèques, frameworks – très souvent bénévolement – les ont offert à l’humanité. Faire de leur travail notre matériau nous oblige dans une certaine mesure à perpétuer ce qui constitue peu à peu l’histoire d’une profession.

Parmi ces gens on retrouve de très nombreu·x·se autodidactes, une chance pour ces personnes de rapidement apprendre un métier et de trouver un emploi, ainsi que pour les employeuses et employeurs. En effet, tout le monde peut apprendre à programmer sur Internet, et c’est encore plus simple dès qu’il s’agit de web : avec un logiciel type bloc note et un navigateur web quelconque, on peut déjà tout développer, ou presque. On trouve des tutoriels sur les langage ainsi que sur les bibliothèques et frameworks. Ces derniers constituent une véritable pluvalue en accélérant considérablement le développement et la maintenance du code. Les maîtriser constitue une condition à l’embauche : tout le monde peut l’apprendre sur le Web, donc pas de raison de s’y soustraire.

La logique académique se veut plus progressive. Elle consiste à maîtriser des langages et architectures plutôt que les bibliothèques et frameworks à la mode. Ils permettent à l’inverse d’ignorer en partie les problématiques des langages et de l’architecture pour accélérer la programmation. Nous parlons de deux visions radicalement opposées et entre lesquels l’écart se creuse d’année en année tant les bibliothèques et frameworks se multiplient et évoluent. Je suis moi-même tiraillé entre d’un côté ma fascination pour l’architecture et la souplesse d’un système conçu de ses mains et de l’autre cet impératif de l’efficacité et de l’employabilité. Finalement, je cultive l’architecture en cours et l’apprentissage des bibliothèques et frameworks à la maison, donc moins régulièrement.

Si mon objectif – classique – était de prétendre à un poste de développeur web front-end, poursuivre mes études est un mauvais choix, et la licence professionnelle que j’ai choisi ne m’a pas mené dans ce sens. Je devrais plutôt prendre un temps d’apprentissage intensif des bibliothèques et frameworks JavaScript, puis prendre un poste dans une agence en tant que développeur junior.

Avenir professionnel

Dos à cet avenir, j’ai le plaisir de travailler un peu plus un sujet vu en cours avec Monsieur Olivier Le Deuff : les développeuses et développeurs sont des architectes. Maîtriser les bibliothèques et frameworks permet de multiplier les architectures et les modèles et je travaille dans ce sens sur mon temps personnel. Toutefois ils ne permettent pas de comprendre comment optimiser une construction, concevoir un modèle. Afin d’être capable d’innover dans ce domaine, je pense qu’il est utile de cultiver, mais aussi de critiquer ces outils. Ma poursuite d’études est la poursuite de cette analyse.

La programmation est une pratique centrée autour de l’écriture – pragmatique et normée – et de la modélisation. Par « modélisation » je fais une large référence aux travaux de conception et de schématisation des interfaces (d’utilisation et de développement).

Les fichiers qui composent un logiciel sont autant d’éléments formant une documentation technique dédiée à la résolution d’un problème ; ils contiennent du code, lequel décrit littéralement et formellement des solutions. Cette documentation est dédiée à des machines et à des humains. C’est une médiation, entre un besoin et une solution, entre un humain et une machine. Or, cette médiation est de plus en plus inaccessible pour des milliards d’usagers. C’est le fait d’humains et non de machines : nous développons délibérément des logiciels toujours plus opaques et les rares documentations sont spécialisées. Selon la culture de mon métier et ses pratiques, j’aspire à travailler (pratiquement et théoriquement) l’aspect documentaire du Web sous deux aspects : concevoir des modèles de programmation pour des sites web documentaires en documentant le tout.

Pour ce faire, une formation poussée en documentation numérique me semble indispensable pour achever le travail débuté cette année. J’aspire à devenir ingénieur de recherche, sinon ingénieur d’études. Dans tous les cas je resterai un technicien au service des usagers du web documentaire documenté.

Conclusion

Quand j’écris en introduction vouloir « instancier un environnement numérique et non plus simplement développer une interface » j’exprime cette volonté de mettre en place des systèmes documentaires reproductibles, c’est à dire avec une architecture, une documentation jointe et un code ouvert aux modifications, plutôt que des « boîtes noires » dont les fonctionnalités et l’appréhension sont limitées par la configuration même du projet. Ces logiciels, fermés, ne laissent aux utilisateurs qu’une interface d’échange sans mettre à profit le travail d’architecture et les dépendances qui ont été nécessaires à leur création. C’est regrettable quand on sait que ces logiciels reposent pour la plupart sur des programmes communautaires ouverts. L’instance c’est au contraire permettre à l’utilisateur d’entrer au cœur de l’architecture et d’un geste de réitérer le logiciel, de le dupliquer. Parce qu’on lui a donné les moyens de comprendre les programmes, l’utilisateur peut à son tour personnaliser sa version du logiciel et la proposer à d’autres qui pourront l’instancier à leur tour. C’est exactement l’idée de la licence Creative Commons, share alike, « Partage dans les Mêmes Conditions ».

Enfin, je préfère désormais parler d’environnement plutôt que d’interface, car je me rends bien compte et qu’un seul affichage ne suffit pas à explorer une base documentaire. C’est pour cela que les deux projets de développement de mon stage proposent différentes « vues » des mêmes données. La difficulté est dans le choix des affichages, des outils – en somme de l’éditorialisation de ces données —, mais aussi dans la liaison de ces interfaces. Comment guider l’utilisateur dans le récit des relations d’un homme ou d’un laboratoire et lui donner la possibilité d’aller et venir dans cette histoire avec différents points de vue. Mon travail sera de rendre aux utilisateurs la vue, sur le code et sur les histoires qu’il documente.

Voilà la grande leçon de cette année universitaire. Elle est entièrement fabriquée de notions et de concepts de développement et de documentation. Cette année m’a permis de réfléchir pour la première fois en profondeur sur mon métier. J’en tire enfin un savoir-faire. Le chemin a été court et intense bien que j’ai toujours pu prendre le temps de mettre en pratique cet apprentissage, tant durant les heures de cours que lors de travaux personnels. Ces enseignements m’ont permis de repenser entièrement ma manière d’utiliser un ordinateur, d’accumuler des connaissances ou de concevoir un site web. Je vais en master travailler une méthode académique pour compléter mes acquis techniques des trois dernières années.

4 Voir documentation

6: Voir journal GraphLab, 16/07/2020 et 21/07/2020