Aider à remplir les appels à projets en humanités numériques : un bien pour un mal ?

Auteurice : Elsa Van Kote

Temps de lecture : ~8 minutes

Après une discussion avec une collègue qui me racontait les problèmes qu’elle rencontrait dans un projet en humanités numériques, j’ai fini par me poser la question : devrions-nous, en tant qu’ingénieurs spécialisés dans le domaine, aider les chercheurs et chercheuses à remplir leurs appels à projet ?

Il n’est pas rare en effet de se retrouver confronté à cette situation : quelques jours avant la date butoire de dépôt d’appel à projet, nous sommes sollicités pour insérer les mots clefs correspondants aux humanités numériques, véritable or lexical afin de donner un maximum de chance à l’équipe de décrocher ledit financement.

Liste des mots clefs à insérer : IA, entrainement de modèles, open data, HTR/OCR, XML, base de données, data visualisation, big data, web developpement.

Le cas de ma collègue

L’histoire se déroule dans un laboratoire ayant décroché un financement ANR. Ces financements sont en général assez conséquents, pouvant se compter en centaines de milliers d’euros (personnellement j’ai apporté mon aide à un projet ANR financé à hauteur de 500 000 euros).

Le sujet en lui même est incroyable d’orignialité : il s’agit d’étudier le contexte d’imprimés allant du XIIIe au XVIIIe siècle, afin de pouvoir détecter s’il s’agit d’un texte destiné à être lu à l’oral ou non, à l’écrit ou non, pour une personne ou plusieurs, lors d’un colloque ou pour un salon plus intimiste… il s’agit alors d’entrainer des modèles de reconnaissance pour détecter des vocabulaires, des contextes de phrases, de grammaire, de composition de document qui laisserait entendre tel ou tel usage.

Pour rappel, un projet ANR dispose d’un financement de trois années. À l’issu de ces trois années (et même tout au long de ces trois années), l’équipe de rrecherche doit fournir des résultats d’études scientifiques. Dans les faits, les projets ont rarement trois années complètes devant eux. Généralement ils ne démarrent pas ex-nihilo au moment du décrochage du financement : ces projets sont déjà en cours depuis une année voir plus, mais les financements permettent une accélération du processus. Qui dit argent dit plus de moyens humains et plus de potentialités en terme de mise en place de séminaires et colloques, qui sont eux-mêmes essentiels aux avancées scientifiques. Un projet arrivé au bout de son financement ANR, c’est souvent un projet qui a démarré il y a bien plus de 3 ans, mais avec les moyens du bord.

Les problèmes avec ce genre de projet arrivent très vite et sont facilement détectables. Par exemple au moment de parler d’HTR (il s’agit de reconnaissance automatisée d’écriture manuscrite) l’on se rend compte que les porteurs de projets ne voient pas ce qu’est un modèle d’entrainement, ce que peut-être la différence entre l’interface graphique escriptorium et transkribus ou bien à quoi ressemble de la structuration de texte en XML, on peut commencer à s’inquiéter de plusieurs conséquences :

• la création de fiche de poste en décalage avec les tâches à réaliser. Puisque les objectifs techniques ne sont pas compris, la rédaction d’une fiche de poste technique de recrutement d’ingénieur ne touche pas son objectif
• le recrutement malheureux de post-doctorants en recherche sur des postes d’ingénieurs alors qu’ils ne sont pas formés au numérique
• une trop grosse charge de travail reposant sur les épaules d’un.e seul.e ingénieur.e dédié au projet
• un très grand stress pour les porteurs de projet qui se rendent compte jour après jour de la quantité de travail demandé pour ce genre de projet en humanité numérique. L’IA et l’entrainement de modèles de detection est une échelle technique bien au delà de la mise en ligne d’un site web statique. Si l’on garde à l’esprit que même une mise en ligne sous forme de site web est déjà une idée qui peut cacher une multitude de défis techniques bien diverses.

La preuve en est la réaction de la porteuse de cette ANR qui, au bout d’une année de dur labeur et après avoir été exposée à toute la technicité induite par son projet de recherche aurait soufflé : “Si j’avais su, je ne me serai pas lancée là dedans…”.

Si j’avais su…

Donc, où sont les problèmes ? Car plusieurs se cachent derrière cette histoire. Je supposerais une liste de plusieurs points, sûrement non exhaustive :

• un manque discriminant de connaissances informatiques de la part des personnnels chercheurs et chercheuses les conduisant à sous estimer le travail technique nécessaire au projet

• ce manque de connaissance pousse au recrutement d’un ingénieur.e projet dont on attend de lui/d’elle de pouvoir résoudre, seul.e, toutes les questions techniques relatives au projet (développement web, développement logiciel, création et entrainement de modèles HTR et OCR, relecture des transcriptions réalisées par l’HTR et l’OCR, création et maintient de bases de données, formation des équipes aux outils numériques etc.)

• un système d’appel à projet incidieux prenant au piège les porteurs de projet car ne sélectionnant que des projets faisant mention d’un pilier humanité numérique

• un manque de réalisme de la part du jury des APP qui ne sélectionnent que des projets ayant déjà plusieurs années de production

• un manque d’expertise et de connaissances techniques du côté des jurés de projets qui ne se contentent que de valider la présence de mots clefs

• un temps de réalisation des projets trop courts compte tenu du travail technique à élaborer

• et peut-être, il faut le dire, un service trop souvent rendu par les ingénieur.e.s qui remplissent eux-mêmes les points techniques des appels à projet et fiches de postes, à la demande des collègues chercheurs… alors qu’il serait peut-être de notre devoir de vérifier avant l’implication de toute l’équipe dans les points techniques du projet.

Je sais, ça n’est pas très glorieux dit comme ça. On a tous et toutes déjà fait ça, rempli un PDF ou un PGD (le Plan de Gestion de Données, essentiel pour savoir comment gérer les donnnées pendant tout leur cycle de vie) pour aider un collègue afin qu’elle ou il puisse décrocher son financement. Mais plus le temps passe, plus je me dis que c’est peut-être une fausse bonne idée. Que le mieux serait déjà peut-être dans un premier temps de former et sensibiliser nos collègues, avant de leur permettre de se lancer dans l’aventure.

Il s’agit donc de s’attaquer à chacun de ces problèmes.

Alors sachons !

En tant que jeune femme ingénieure d’étude en contrat précaire (ouiiiii!), il est difficile de s’attaquer à des déficiences institutionnelles comme celles-ci. Je ne suis pas en mesure de modifier la durée des financments ANR, ni d’avoir un quelconque poids face aux échellons plus haut que le mien.

En revanche, des propositions simples pourraient avoir un effet sur la plupart des problèmes exposés ci-dessous :

• continuer de faire de la sensibilisation auprès des directions et des collègues ;

• délivrer une formation au numérique dès la licence afin que les étudiants puissent s’approprier une culture numérique. Il s’agit par là de former des futurs chercheuses et chercheurs à comprendre les problématiques posées par le numérique dans la recherche.

• créer des espaces de regroupement des ingénieurs projets/labos/plateformes : le but étant qu’aucun.e ingénieur.e ne se retrouve isolé.e et puisse bénéficier dès on arrivée de conseils et d’appuis de la part des ingénieur.e.s déjà présent.e.s

• la création d’un kit de bienvenue pour les ingénieurs, personnalisés dans chaque institution, disponible en ligne et en version papier afin de répondre à toutes les questions qu’il ou elle serait amené.e à se poser : comment fonctionne la structure dans laquelle je travaille ? Qui sont mes référents ? Où me diriger pour être formé.e ? Quels ont les outils et logiciels disponibles ?. Cette idée avait déjà été amenée par le compte rendu des cinq années de travail de recherche du consortium Huma-Num CAHIER (devenu ARIANE)

• placer dans les jury APP des personnes du monde de l’informatique afin qu’ils puissent juger de la pertinence du dossier

• faire passer un entretien oral aux porteurs.euses. du projet afin de vérifier qu’ils aient bien les connaissances à minima techniques et les questionnements pour ce genre de projet. Dans le cas contraire, il ou elle pourra être redirigé.e vers des ateliers de formation et invité.e à repasser un oral l’année suivante.

J’ai conscience que certaines de ces idées feront grincer des dents plus d’une personne. En revanche il est bon de rappeler, notamment concernant la dernière proposition, qu’il ne s’agit pas de prouver quelconque compétences en informatique. Mais bien de vérifier pour le jury le niveau de compréhension du contexte vers lequel le projet se dirige. Cela peut se faire par exemple avec des questions très simples : qu’est ce qu’une donnée ? une métadonnée ? la différence entre le html et la css ? pourquoi faut-il privilégier des logiciels open-source plutôt que des logiciels propriétaires ? comment décririez-vous l’instance nationale Huma-num ? dans quel milieu évolura votre équipe ? de quel accompagnement pourront bénéficier les ingénieurs du projet ? quelles formations numériques (et non pas logicielles) allez-vous proposer à votre équipe ?

Je suis bien évidement disposée à discuter de cette utopie avec qui le veut bien !