Le Livre d'Argent

Allez, une fois n'est pas coûtume, si j'utilisais un peu mon blog pour parler de moi ? Puisque, c'est en cours d'officialisation, je quitte définitivement ma bonne vieille Université de Rouen pour venir faire mon stage – puis, si tout se passe bien, ma thèse – auprès d'un labo de Recherche publique affilié à l'Université de Lyon, j'aimerais vous présenter un peu ce qu'on fait, à l'univ de Rouen, en seconde année de master en Génie de l'Informatique Logicielle.

Tout d'abord, il faut savoir que cette année était un peu particulière, parce que nous étions la promotion la plus nombreuse qu'ait connu le département informatique de l'Université depuis longtemps : quarante-sept étudiants l'an dernier, dont quarante-deux sont restés dans l'aventure cette année. Forcément, en bon auto-stoppeur galactique, je me dis que c'était le bon nombre pour réussir.

Ensuite, il faut savoir aussi comment se passe un projet de seconde année de master, chez nous les GIL. Nos responsables de promotion énoncent, chaque année, un projet unique et suffisamment important pour nécessiter la participation de toute la promotion, mais sa publication se fait sous la forme d'un appel d'offres. La promotion est divisée en plusieurs groupes dont les membres sont tirés au sort (afin de nous mettre dans la même situation que dans la vie professionnelle, où l'on ne se regroupe pas nécessairement par affinités), et chaque groupe doit, indépendamment et en concurrence avec les autres, rédiger une réponse à cet appel d'offres.

La première phase du projet est donc cette phase où nous nous réunissons en équipe pour étudier le projet, décortiquer et comprendre les exigences formulées, et élaborer ensemble une offre – sérieuse, ce n'est pas parce que nous sommes en période électorale qu'il fallait faire des promesses intenables, au contraire – pour répondre à cette appel.

L'enjeu de cette phase ? L'équipe ayant fourni la meilleure Réponse à Appel d'Offre (ou RAO pour faire bref) se voyait confiée la charge de « Maîtrise d'Œuvre », c'est-à-dire qu'elle était chargée de répartir les tâches à effectuer entre les différentes équipes, d'être l'interlocuteur privilégié auprès de nos « clients », et de guider le développement de l'application. Bref, si nous allions tous travailler sur le projet, nous étions pour l'instant en concurrence pour en prendre la tête.

Parlons un peu du sujet de ce projet, maintenant : « ARMADA » signifie « Application de Recherche Multimodale Avancée de Documents Audiovisuels ». Je ne vais pas vous réécrire ici le document de présentation que nous avons reçu pour l'appel d'offres : il comptait une cinquantaine de pages, dont vingt pour détailler les exigences.

Sachez en tout cas qu'il devait s'agir d'un moteur de recherche, comme ceux que vous utilisez habituellement sur le net, mais spécialisé dans la recherche de vidéos. Nous devions donc mettre en place notre propre système de collecte, de traitement et d'indexation de vidéos, ainsi qu'une interface de recherche permettant à l'utilisateur de lancer des recherches en tapant des mots-clefs, mais également en parlant ou en chargeant des images. La visualisation de la vidéo devait également permettre d'en afficher le contenu audio : il fallait donc que la phase de traitement comprenne également une transcription automatique des paroles prononcées.

Il y avait par ailleurs une thématique particulière : j'ai parlé, ci-dessus, de la campagne électorale à dessein. L'objectif aurait été, en situation réelle, d'établir une application devant aider les gens à décider pour qui ils voteraient aux prochaines élections présidentielles. Nous devions donc focaliser la collecte uniquement sur les vidéos traitant de politique (donc filtrer par thématique), puis axer l'indexation dans le sens désiré (une vidéo parlant du programme d'un parti donné, par exemple, pouvait être liée au candidat de ce parti sans forcément que son nom soit prononcé).

Je pense que cette rapide description peut vous donner une idée de l'état de perplexité dans lequel nous nous trouvions lors de nos premières réunions. Certes, c'était faisable, puisque finalement, nous l'avons fait. Mais c'était « gros », et pas facile à digérer au premier abord. Nous nous sommes accrochés, ceci dit, et nous avons fait de notre mieux pour rédiger un document de RAO qui tienne la route.

Fort heureusement, il ne s'agissait pas non plus de tout développer de A à Z : une partie du travail allait être de l'intégration, c'est-à-dire de la réutilisation de briques logicielles déjà existantes. Notre objectif durant cette phase était donc également de décider sur quels logiciels nous allions nous appuyer pour fonctionner.

(Ah, une condition essentielle pour ce projet, mais qui néanmoins faisait plaisir : le code que nous produirions comme les logiciels que nous devions réutiliser devaient être placé sous licence libre).

Même si nous n'étions pas tous aussi motivés pour obtenir la Maîtrise d'Œuvre (on dit MOE, dans le jargon), je crois que nous avons presque tous (je parle de la promo entière, et pas seulement de mon équipe) fait notre possible pour faire un boulot correct. Certains avec plus de facilités que d'autres, parce que le tirage au sort ne prenait évidemment pas en compte les différentes options, et qu'il n'était pas toujours évident de trouver un créneau de réunion (pour les lieux, c'était un peu plus simple : à peu près toutes les salles vides de notre département et quelques unes des départements voisins y sont passées).

Puis finalement, nous avons rendu nos RAO, qui ont été relus par nos responsables, et ceux-ci nous ont renvoyé leurs remarques. Certaines équipes ont souffert plus que d'autres (il ressort finalement – et ce fut une agréable surprise, nous pensions être bien placés, mais « dans le peloton » – que notre RAO initiale était peut-être la meilleure).

Une fois reçues ces critiques, il nous restait moins d'une semaine pour les digérer, les prendre en compte, et préparer une soutenance durant laquelle nous allions pouvoir corriger les problèmes et convaincre le jury que nous étions l'équipe la plus qualifiée pour assumer la charge de MOE.

Cette première soutenance s'est plutôt bien passée, mais hélas, d'autres ont été encore meilleurs que nous : une autre équipe a remporté l'appel d'offre, et nous ne nous sommes retrouvés que sur la seconde marche du podium (il semble cependant que le choix ait été dur, et que nous les talonnions à quelques dixièmes de points).

Passée cette deuxième soutenance, débutait la seconde phase du projet : la phase de préparation.

Nous avons mis en commun nos différentes RAO, et notre nouvelle équipe dirigeante, en accord avec les clients et en concertation avec les autres équipes, a décidé des choix techniques de développement et de la répartition des tâches. Nous avons ensuite, en équipe, planché sur les tâches qui nous avaient été affectées, pour préparer la phase de développement.

L'Université a pu mettre à notre disposition une petite dizaine de serveurs (je précise que ce projet devait être distribué et réalisé en Architecture Orientée Services, c'est-à-dire constitué de plusieurs logiciels indépendants, pouvant tourner sur des machines différentes, chacun prenant en compte une partie spécifique et spécialisée du travail, et appelés les uns à la suite des autres pour réaliser le traitement complet), et il a également été à notre charge de les installer correctement.

J'ai d'ailleurs personnellement été pas mal impliqué pour cette étape, ayant été le membre de la promo avec le plus d'expérience des systèmes GNU/Linux (quasiment tous nos serveurs tournaient sous Ubuntu), ce qui m'a valu une position semi-officielle d'administrateur système et réseau sur le projet.

Quelques choix techniques : alors que nos confrères des années précédentes avaient plutôt fait leur choix pour SVN, nous avons opté pour le système de gestion de versions Git. Cela a éveillé quelques râleries, pas toujours argumentées et même parfois franchement trollesques, mais rétrospectivement, je pense encore que c'était le meilleur choix. Il aurait sans doute été possible de fonctionner aussi avec SVN, mais je n'aurais en tout cas pas aimé gérer ça (ceci étant, nous aurions probablement mieux pu nous organiser pour tirer un meilleur parti de cet outil).

J'anticipe un peu, mais pour l'accès partagé aux fichiers, étant donné qu'il y avait plusieurs systèmes à prendre en compte, le choix (là je n'ai pas participé à la décision, juste à la mise en place) s'est porté sur un serveur Samba. On ne l'avait pas prévu assez tôt, et on l'a fait un peu en catastrophe, surtout qu'on a eu quelques petites difficultés non-prévues, mais ça a quand même très bien marché une fois installé.

Ce fut également la phase pendant laquelle nous avons commencé à établir notre « corpus de test » : environ deux cent cinquante vidéos (axées politiques, forcément), pour une durée totale d'une vingtaine d'heures, que nous avons collecté manuellement et dont nous avons manuellement transcrit les paroles, afin de construire une « vérité terrain » de référence pour évaluer, lorsqu'il serait prêt, notre système de transcription automatique. Petite corvée, toute la promo s'y est mis, mais nous en sommes plutôt bien sorti au total.

Et puis à la fin de la phase de préparation, une nouvelle soutenance, cette fois devant l'ensemble de la promo (en plus de nos responsables qui étaient les seuls à nous écouter lors de la soutenance de RAO) : la revue de lancement, dans laquelle chaque équipe présentait ses tâches faites et à faire et son planning prévisionnel. Il y a eu quelques étincelles, mais dans l'ensemble, encore une fois, c'est à peu près bien passé.

Ensuite, débutait la véritable phase de développement : six semaines au cours desquelles nous étions à plein temps sur le projet, presque en « conditions réelles ».

Enfin, presque six semaines, parce qu'il y a eu, mine de rien, pas mal de pertes : d'abord, trois jours de cours qui n'avaient pas pu être placés ailleurs, qui ont (dé-, selon le point de vue)mobilisé une bonne partie de la promo, puis les multiples entretiens de stages, divers soucis administratifs (notamment pour les étudiants étrangers), et puis c'était aussi la période de l'année au cours de laquelle il y a le plus d'arrêts maladie. Et la soutenance finale a elle du être avancée de quelques jours. Mais on s'en est sorti.

Nous avions trois salles à notre disposition : notre salle de cours habituelle, qui recevait trois équipe, notre salle de cours secondaire (mise à disposition spécialement cette année en fonction de l'important effectif), qui en recevait deux, et puis un bureau avait été confié à l'équipe chargée de la MOE. Nous avions fait le choses sérieusement, avec un contrat et tout.

Les horaires étant à décision de chaque équipe dans la limite du raisonnable (Sans vouloir dénoncer personne, il y a une des trois salles qui était très souvent quasi-, voire entièrement, vide un certain temps avant les autres, et ce n'était pas la mienne – je reconnais que nous (surtout moi) arrivions peut-être un peu plus tard que les autres, mais pas à ce point. Enfin, chacun a fait sa part du boulot, c'est le principal).

Nous avons rencontré des difficultés plus ou moins prévisibles et plus ou moins handicapantes. Par exemple, l'équipe en charge de la collecte a eu fort à faire avec le proxy de la fac, qui nous restreignait pas mal dans les protocoles utilisables (Ça nous a purement et simplement empêché de récupérer les vidéos de certains des sites que nous devions prendre en charge), et puis ils ont réussi à faire bannir la fac entière quelques jours de YouTube et DailyMotion (les autres promos étaient ravies ^^).

La puissance des machines, également, a été problématique. L'Université nous avait en fait fourni toutes les machines qui lui restait en stock, et aucune n'était spécialement une bête de course. Nous en avions suffisamment (une petite dizaine, comme je l'ai dit) pour essayer de répartir à peu près correctement les différents services à faire tourner, mais certaines opérations avaient quand même un peu de mal à passer.

Mon équipe à moi était en charge de la partie graphique (donc les pages du site lui-même, la recherche et la visualisation, mais aussi toute la partie administration) ainsi que de la mise en place des outils d'évaluation. De cette manière, nous avons été en contact plus ou moins permanent avec toutes les autres équipes, puisque nous étions chargés d'une partie de l'intégration de leurs développements.

Le problème spécifique majeur pour notre équipe a probablement été les temps de chargements. S'il était normal pour la phase de traitement, réalisée en arrière-plan dans un processus dédié, de durer un temps assez conséquent, cela devenait beaucoup plus problématique au niveau de l'interface utilisateur. Imaginez-vous attendre plus d'une minute que la page de visualisation d'une vidéo (sans compter le temps de chargement de la vidéo elle-même, juste le contours) veuille bien finir de se charger ?

Mais nous nous sommes autant que possible débarrassés de ce problème en mettant en place des chargements différés et par petits morceaux (un gros pansement qui, dans certain cas, donne même finalement meilleure impression que si le chargement avait été plus rapide, mais fait d'un bloc), en virant certains traitements inutiles, et en faisant pré-effectuer une partie de nos traitement dans la phase d'arrière-plan plutôt que de les effectuer dynamiquement au moment d'une requête client.

D'autres soucis ont été moins bien pris en compte. Notamment, ce qui a fait quelques étincelles à un moment donné, au niveau de l'accessibilité : certains de mes camarades n'étaient pas aussi sensibilisés que moi sur ce plan, et le code que nous avons finalement mis en place aurait été assez malvenu en situation réelle(1). Cependant, comme l'a fort justement fait remarquer mon chef d'équipe, qui a fait du bon boulot de médiation, nous devions en fait réaliser un « démonstrateur », donc nous pouvions nous permettre ce genre d'écarts.

D'ailleurs, notre « démonstrateur », s'il a effectivement bien tourné en phase de démonstration, aurait été impossible à déployer ailleurs sans retouches : nous avons tous un peu codé « à la Rache », par exemple en mettant les adresses des services à contacter en dur dans le code (portabilité zéro). Une petite poussée de conscience professionnelle nous a conduit à tenter de résoudre ce problème sur la fin, mais c'était trop généralisé pour qu'on vienne à bout de tout.

Là encore, conseils aux prochains qui bosseront là-dessus : commencez toujours par ne pas mettre en dur ce qui ne doit pas l'être. C'est beaucoup plus facile que de repasser derrière plus tard pour corriger.

Je viens de parler de la démonstration : cette phase de six semaines de développement s'est conclue par une soutenance finale, une fois encore, devant nos responsables et l'ensemble de la promotion : chaque équipe a présenté ses travaux, comparé ce qui était prévu et ce qui a effectivement été réalisé, puis cela a été suivi par une démonstration du produit en action. Mise à jour : notre client a posté une vidéo de démonstration ici, si ça vous intéresse

Nous avons réussi à remplir presque toutes les exigences initiales (celles que nous n'avons pas remplies l'ayant été à cause de facteurs externes, comme ce proxy dont j'ai parlé plus tôt et dont nous ne pouvions nous débarrasser), ce qui était au delà des attentes.

Au final, ce projet était certainement une aventure humaine marquante et dont nous nous souviendrons durant une bonne partie de notre vie professionnelle. Je remercie très sincèrement l'Université et les différents intervenants pour nous avoir confié ce projet, ainsi que mes camarades pour les moments forts, autant pendant le développement qu'à côté.

Les frayeurs et les fatigues ont été nombreuses. Par exemple la journée passée à comprendre pourquoi l'écriture sur le serveur de persistance ne fonctionnait pas de façon si aberrante ; la lecture de l'ontologie qui a cessé de fonctionner juste le dernier jour, malgré une restauration dont nous ne nous sommes rendu compte qu'après coup qu'elle avait été mal effectuée ; et cet instant suprême de doute, pendant la démonstration, pendant lequel la vidéo a tardé à se charger…

Mais les bons souvenirs sont nombreux aussi. Le travail en collaboration ou en compétition amicale pour résoudre un problème ou trouver comment faire fonctionner quelque chose. La concertation pour la mise en place des meilleures solutions. Les discussions et les parties animées pendant les pauses. Les chansons qui nous distrayaient pendant qu'on codait.

Je pourrais aussi vous parler de quelques-uns des petits jeux lancés par mes camarades de promotion au cours de ce projet, mais bon, je préfère vous laisser voir avec eux pour le reste