Microservice FastAPI - collecte de la production scientifique

Le logiciel « SoVisu+ Havester » est un outil destiné à moissonner les différents référentiels qui regroupent la production scientifique des chercheurs (Hal, data.idref.fr, Scanr, OpenAlex, Pubmed Wos, Scopus...) et à convertir les métadonnées de publications vers un format commun. Il peut être interrogé pour divers types d’entités (Personne, laboratoire, institution, projet) à partir de n’importe quel identifiant (Idref, IdHal, ORCID, ResarcherId...).

Le développement a été initialisé sous licence libre.
[URL visible pour les membres Pro]
[URL visible pour les membres Pro]

**Exigences fonctionnelles**

♦ Moissonnage de plateformes de références bibliographiques
♦ Conversion vers un modèle de données commun
♦ Historique des collectes
♦ Interfaces multiples

*Exigences non-fonctionnelles**

L’équipe SoVisu + applique un référentiel qualité portant sur les aspects suivants :

- Couverture par les tests
- Conformité du code (linters)
- Accessibilité
- Traçabilité des évolutions (Github workflow)
- Automatisation du déploiement (Github actions, containerisation Docker avec Kubernetes pour cible)
- Qualité de l’architecture applicative (Design patterns)
- Performances (parallélisme ou concurrence chaque fois que nécessaire).

Toute amélioration de ce référentiel apportée par le prestataire sera appréciée.

**Modalités d’intervention du prestataire**

- Intégration à l’équipe projet

L’application est développée en collaboration par le ou les prestataires et l’équipe projet interuniversitaire. Le développement ayant déjà débuté, le prestataire est invité à inscrire son travail dans le cadre des arbitrages déjà effectués en matière de choix de technologie, d’architecture de la solution et de pratiques qualité, tout en proposant des améliorations sur tous les aspects qu’il jugera opportuns.

- Déroulement des sprints

Le développement est séquencé en phases (sprints) de 15 jours. Le prestataire a pour interlocuteur le chef de projet maîtrise d’œuvre auprès de qui il définit le détail de ses missions et auquel il rend compte. Il participe chaque fois que jugé nécessaire par le client, en présentiel ou en distanciel, à des réunions de type sprint review, sprint planning avec les parties prenantes du projet, réunions avant lesquelles les évolutions issues du sprint en cours ont été déployées dans un environnement de préproduction (fourni par le client).

Lors de chaque réunion de sprint preview, le client définit les stories à implémenter et présente les maquettes d’interfaces qui leur correspondent (soit dans un outil de wireframes type Figma soit sous une autre forme, slides, schémas ou dessins). Il met également à disposition du prestataire les exemples de données et les informations métier.

A l’issue de chaque sprint preview, certaines stories sont affectées au titulaire. Les stories assignées au titulaire donnent lieu à une qualification en “unités d'œuvre” (cf ci-dessous) afin de permettre la quantification du travail exécuté par le prestataire. La commande totale passée au prestataire au cours de la première année représentera, de façon indicative 4 UO1, 6 UO2, 10 UO3; des bons de commande successifs sont susceptibles d’être émis pour une partie de ces UO; la répartition entre unités d'œuvre de différentes nature pourra évoluer dans la limite du montant de chaque bon de commande.

- Initialisation

En début de mission, des réunions seront organisées entre le ou les prestataires et le client pour :

· Transférer au prestataire les connaissances requises sur le domaine métier
· Lui présenter l’architecture applicative de la solution en cours de développement
· Lui présenter les pratiques de l’équipe (Git, Tests, déploiement, i18n, etc.) et recueillir ses suggestions d’amélioration

**Workflow de développement**

Une fonctionnalité est réputée livrée lorsque la branche Git a été intégrée dans la branche principale de l’application et déployée dans l’environnement de préproduction. Commence alors une phase de recette d’une durée indicative de 10 jours ouvrables (hors période de vacances universitaires).

L’équipe projet crée des tickets pour chaque anomalie constatée. Le chef de projet assigne les tickets au titulaire lorsqu’ils sont du ressort de celui-ci. Le titulaire marque les tickets comme “résolus” lorsque la branche Git apportant le correctif a été intégrée dans la branche principale du projet et le correctif déployé en environnement de préproduction. Le chef de projet clôture le ticket s’il vérifie le bon fonctionnement. Durant la période de recette de la fonctionnalité, un ticket d’anomalie est traité dans le cadre de la même unité d’œuvre que celle de la fonctionnalité qui fait l’objet de la recette.

**Compétences requises**

Les technologies mises en œuvre sont :

– FastAPI, Pydantic, SqlAlchemy , Njinja2
– Javascript, SCSS, Bootstrap 5 avec Npm et Webpack (pas de framework JS ni de typescript)
– Gestion du parallélisme (asyncio, possiblité threads, multiprocessing, Celery)
– API REST/json, SPARQL, RDF
– Poetry, Black, Pytests, Babel
– Postgresql
– Github, Github Actions
– Containerisation (Docker + Kubernetes)
– RabbitMq

La familiarité avec certaine technologies (typiquement Rabbitmq, RDF) est souhaitable mais non obligatoire. Le code présent et à venir est très largement implémenté sous Asyncio.

**Définition des unités d’œuvre**

Les candidats sont invités à proposer un chiffrage pour les unités d’œuvre illustrées ci-dessous par des exemples1. Ils peuvent indiquer, à titre indicatif, un chiffrage en jour, mais durant le projet, les travaux seront rémunérés exclusivement selon le nombre d’unités d’œuvre auxquels ils auront été estimés, quel que soit le temps effectivement passé, sauf pour l’UO4 (UO d’ajustement).

Chaque unité d’œuvre inclut de façon implicite le temps passé en réunion de sprint ou en concertation avec le client. L’estimation de la charge en unités d’œuvre peut être revue a posteriori uniquement si survient un impondérable. (Ex. Une API proposée par une institution tierce s’avère dysfonctionnelle).

♦ UO1. Unité d’œuvre : story de complexité forte

Exemple 1 (développement back+tests) : Développement d’un nouveau harvester pour Pubmed. Voir par exemple le harvester Hal : [URL visible pour les membres Pro] [URL visible pour les membres Pro]

Exemple 2 (développement back+front+tests) : Fonctionnalité de purge de l’historique

Pour réduire la taille de la base, un administrateur de l’application peut purger l’historique des collectes avant une certaine date. Cette purge préserve toutes les données utiles à la poursuite des mises à jour de l’état actuel de la production scientifique.

♦ UO2. Unité d’œuvre : story de complexité moyenne

Exemple (développement back+front+tests) : écran de gestion des utilisateurs

On suppose qu’un système d’utilisateurs avec gestion de droits a déjà été implémenté côté serveur et en base de données. La story consiste à développer l’écran et l’API permettant à un user administrateur de créer/modifier/mettre à jour les comptes.

♦ UO3. Unité d’œuvre : story de complexité faible

Exemple 1 (développement back+tests) : Validation des formats d’identifiants côté serveur . Les formats des différents identifiants doivent être validés par l’API au moment de l’envoi d’une requête HTTP ou AMQP qui doivent retourner des messages d’erreur circonstanciés et ne pas lancer de collecte si les formats sont inappropriés.

Exemple 2 (développement back+tests) : Gestion de l’acquittement des messages.

Mise en oeuvre du « Ack » sur RabbitMQ (les messages non acquittés son re-présentés). L’application acquitte tous les messages pour lesquels les collectes ont été menées à bien.

♦ UO4. Unité d’œuvre : demi-journée d’ajustement

Exemple. Le client constate en réunion de sprint qu’il a oublié de de demander une option sur une fonctionnalité. Le correctif est estimé à 1/2 journée de travail.