Aujourd'hui, la plupart des domaines métiers utilisent l'informatique pour être assistés dans leurs tâches quotidiennes. Beaucoup d'outils existent et sont régulièrement tenus à jour par les diverses entreprises qui les conçoivent. Cependant, certains domaines très spécifiques n'ont pas forcément d'outils adaptés à leurs besoins. C'est notamment le cas d'un doctorant en histoire qui réalisait dans le cadre de son projet de thèse, une étude de réseau sur la période Amarnienne au Proche-Orient (1340 avant J-C). L'étude de réseau se caractérise par la recherche et l'étude des relations et comportements qui existent entre tous les acteurs et cela dans un ou plusieurs écosystèmes parents en mettant en jeu des équations mathématiques afin de trouver des patterns – ou non – similaires.
Lors de cette réalisation j'ai eu la chance de travailler en collaboration avec un étudiant de l'université de Toulouse Jean Jaurès.
Ma mission était d'accompagner ce doctorant dans son projet en développant une interface permettant de renseigner plus simplement et rapidement les données de son étude.
Mes objectifs ont été les suivants :
Gestion de projet
Développement
L'enjeu du projet était de proposer une application simple, permettant un gain de temps important, qui se reporterait sur l'étude de réseau, sujet phare de la thèse. De plus, cet outil devait permettre d'administrer – modifier, ajouter, supprimer – ses données.
Le principal risque était la non-conformité de la base de données. En soit, une base n'a pas vraiment de règle précise quant à sa structure, elle doit être logique dans le cadre de son utilisation. Mais dans le domaine très spécifique de recherche de cet étudiant, elle ne répondait pas vraiment « aux normes » qu'on a l'habitude de voir dans des applications « plus classiques ». Le tout était d'adapter l'API et l'interface à cette base peu commune.
Lors de nos premiers entretiens, l'étudiant m'a brièvement expliqué comment il fonctionnait pour renseigner sa base de données. Ses données sont extraites des « lettres d'El Amarna » qui recensent les échanges entre le Pharaon et ses vassaux. En étudiant ces lettres, il en déduit diverses relations (guerres, aides politiques, échanges commerciaux, mariages etc) selon un lexique que lui-même a répertorié.
Le doctorant ajoutait les données uniquement en manipulant des requêtes SQL. Il avait mis en
place des
procédures (requêtes préformatées) lui permettant de renseigner la base légèrement plus vite
mais sans prendre
en compte tous les cas de figure.
De plus, la quasi-totalité de ses tables étaient reliées entre elles engendrant ainsi des relations
circulaires
– problème de conception d'une base qui fait que lorsqu'on souhaite connecter un système voulant extraire les
données, le système tourne en boucle jusqu'au crash.
Lorsqu'une donnée erronée était ajoutée, il devait supprimer par une succession de requêtes la totalité de sa
donnée avec ses relations en cherchant toutes les occurrences au travers des tables. De manière programmatique à
travers une interface, la tâche s'avère simple, mais en requêtes SQL, l'action devenait répétitive et
fastidieuse.
Nous organisions des points réguliers sur l'outil et son avancement. Ces réunions servaient aussi à poser des questions sur certains aspects qui pouvaient rester flous pour ma part.
Lors de notre premier échange, le doctorant avait rédigé un cahier des charges qui m'a permis de comprendre plus en détail sa méthodologie de sauvegarde de données, méthodologie que j'ai respecté dans la logique de l'outil pour rendre le processus automatique.
Une fois l'outil déployé, nous avons organisé quelques sessions d'accompagnement ou je guidais l'utilisateur pour la prise en main de l'interface.
Le client ayant des notions en développement, j'ai déployé un Git en début de projet afin qu'il puisse y récupérer l'outil ou tout simplement y suivre l'avancée du projet.
Une fois le projet terminé, il est primordial de continuer à faire vivre l'outil de par son utilisation mais aussi de son amélioration, ce qui nécessite de recueillir continuellement les nouveaux besoins des utilisateurs et créer une timeline de versions priorisant la liste des nouveaux besoins. Ceci a été mon cas, les nouvelles fonctionnalités étaient recueillies puis ajoutées sous forme d'issue (tâches) sur le Git du projet. Enfin, ces issues sont tenues à jour par un statut (ouvert/fermé) et une date terminée.
Le développement de l'API a été la partie fastidieuse du projet car je devais adapter l'ORM – Partie du Framework AdonisJS qui traduit les objets en programmation objets en table SQL et vice-versa – et les contrôleurs – Partie exposant les requêtes et où se trouve la logique de lecture, d'ajout, de modification et de suppression – à la base de données existantes. Ce problème venait en partie de la structure de la base qui, comme dit précédemment, ne répondait pas aux normes habituelles.
Nous avons parfois travaillé en équipe sur certaines parties du développement des contrôleurs sur des cas très spécifiques. Il me dictait la logique d'enregistrement à suivre et je codais en temps réel en testant le résultat avec lui sur une copie de la base. Travailler sur une copie permettait de ne pas altérer les données réelles.
Le choix du type d'application s'est porté sur du client lourd portable – application n'ayant pas d'installeur et qui se lance directement sur le bureau-. J'ai fait ce choix car il était inutile de développer une application web pour une seule personne. Cette application ne possède par ailleurs pas de système d'authentification car il est destiné pour un usage personnel et très spécifique. Je n'ai pas rencontré de difficulté majeure dans la réalisation de celle-ci. J'ai utilisé Flutter et le langage Dart pour le développement de cet outil.
Durant le projet plusieurs itérations ont été réalisées :
La première consistait à développer l'interface et l'API puis d'adapter et connecter le tout à la base de données afin d'avoir au plus vite une version à tester.
La deuxième grande itération a concerné la correction de bug. J'ai demandé à plusieurs reprises dans différentes étapes du projet au doctorant de tester l'application. Il me faisait un retour sur les erreurs qu'il pouvait recenser, je les corrigeais ensuite avec lui. La plupart des bugs rencontrés venait de l'API et de la logique d'enregistrement des données de certains contrôleurs.
Enfin, la dernière étape a été consacrée à sortir une version dont l'objectif était la refactorisation de code – ceci consiste à enlever le superflu, optimiser le code, le redécouper afin qu'il soit plus visible… –.
Ce projet a été l'occasion d'en apprendre plus dans le domaine de l'histoire sur une époque
reculée.
Il m'a aussi permis de travailler officiellement avec une université dans le cadre de mon auto-entreprise, et
d'en découvrir un peu plus sur la manière dont se passe une thèse en doctorat (Phase de recherche et d'analyse,
exploitation des données, constatations, suppositions...).
L'entreprise a exprimé sa satisfaction dans le fait d'avoir à sa disposition un outil performant, facile d'utilisation et permettant un gain de temps important. Cet avis favorable a permis l'émergence de nouvelles idées concernant l'ajout de fonctionnalités et ainsi donner corps à de futures versions dans le GIT du projet.
Les aspects abordés durant ce projet m'ont permis de venir renforcer mes compétences
d'architecture logicielle et Fullstack.
L'expérience acquise tout au long de ces années m'a permis de développer seul cette
application.
L'étudiant a exprimé sa satisfaction d'avoir à sa disposition un outil performant et qui lui
facilite grandement son travail. Ceci lui a permis de consacrer plus de temps dans l'exploitation et l'étude de
ses données dans le cadre de sa thèse.
Il m'a recontacté peu de temps après pour échanger sur des améliorations et
ajouts de fonctionnalités qu'il serait possible de faire.
Il m'a notamment parlé d'une étape
importante, une fonctionnalité à ajouter, permettant, une fois la totalité des données renseignées, d'en valider
la cohérence (relations, doublons etc pour ne pas fausser les calculs statistiques).
Mon regard critique : A mes yeux, la plus-value a été de pouvoir proposer un outil efficace dans un projet de recherches qui mêle histoire, science et mathématique. Même si mon application n'est qu'un fragment du projet final de ce doctorant, il va sans dire qu'il en est une étape importante.
J'aurais pu essayer d'approfondir davantage le besoin sur certains points, durant nos réunions, comme par exemple, la logique de sauvegarde des données qui suivait un schéma particulier. Cette logique n'était pas simple à comprendre, il a fallu y revenir plusieurs fois durant le projet car il manquait à chaque présentation de l'outil, quelque chose d'essentiel.
Le fait de travailler en équipe a renforcé en moi l'idée qu'il est important d'associer les techniques et compétences de chacun. Et même dans un cadre professionnel, ou chaque individu est spécialisé, il est important de partager ses connaissances. Cela est d'autant plus enrichissant et satisfaisant lorsque c'est réalisé dans un but commun.