Tableau de bord décisionnel de la production scientifique du site Grenoble Alpes, alimenté exclusivement par des données réelles issues des deux API ouvertes citées dans l'offre : HAL et OpenAlex. Il intègre une brique de fiabilisation et de réconciliation des deux sources et des analyses scientométriques reconnues.
Contexte : démonstration réalisée pour candidater au poste de data analyst de l'UGA. L'outil cible de l'établissement est DigDash (propriétaire). La démarche complète (connecteurs API, fiabilisation, modélisation, indicateurs, restitution dynamique, gestion des filtres) est ici reproduite sur une stack ouverte et équivalente. La logique métier est identique ; l'outil s'apprend.
- Aperçu
- Fonctionnalités clés
- Des données 100 % réelles
- Architecture
- Démarrage rapide
- Le pipeline d'ingestion
- Analyses & justification scientifique
- Extensibilité
- Déploiement
- Tests & qualité
- Limites & honnêteté scientifique
- Licence
Le tableau de bord couvre, sur le périmètre « production scientifique » de l'offre, sept volets :
- Vue d'ensemble : volume de publications, accès ouvert, h-index, et évolutions annuelles (corpus complet : 140 638 publications OpenAlex).
- Composition de la production : types de documents harmonisés, voies de l'accès ouvert, supports et auteurs les plus actifs.
- Impact : indices bibliométriques (h, g, i10), distribution des citations, loi de Lotka.
- Signaux émergents : détection de rafales sur les dynamiques thématiques.
- Réseau de collaboration : communautés d'institutions partenaires.
- Qualité des données : réconciliation HAL × OpenAlex.
- Explorateur d'articles : navigation interactive en direct, fiche détaillée en pop-up.
- Réconciliation HAL × OpenAlex : appariement déterministe (DOI) puis probabiliste (blocking + similarité de Jaccard), avec rapport de recouvrement et écart de taxonomie. C'est le cœur « qualifier, fiabiliser, réconcilier » de la fiche de poste, rendu visible.
- Détection de fronts émergents par l'algorithme de rafales de Kleinberg, superposée à une heatmap topic × année. Rarement vu dans un outil opérationnel.
- Réseau de collaboration avec détection de communautés (Louvain) et disposition ForceAtlas2, le tout précalculé hors-ligne pour un rendu léger.
- Explorateur d'articles en direct : chaque filtre interroge l'API OpenAlex, chaque publication ouvre une pop-up avec résumé reconstruit, métadonnées et liens DOI / OpenAlex.
- Indices bibliométriques reconnus : h-index (Hirsch), g-index (Egghe), i10, loi de Lotka.
- Connecteur de fichiers internes (CSV) : ingestion d'un export de gestion comme 3ᵉ source, avec contrôle de cohérence (couverture DOI vs OpenAlex) et une section Contrats de recherche financés (financements compétitifs nationaux et européens) couvrant le périmètre valorisation.
Aucune donnée fictive. Tout chiffre affiché provient de :
| Source | Rôle | Licence |
|---|---|---|
| OpenAlex | Volumétrie, citations, topics, collaborations, accès ouvert | CC0 1.0 |
| HAL (CCSD) | Dépôts, types francophones (thèses, HDR, communications), DOI pour la réconciliation | — |
| Fichiers internes (CSV) | Export HAL (publications) + scanR — financements de la recherche (contrats, MESR) ingérés via le FileConnector |
CC-BY / Licence Ouverte |
Les « fichiers internes » de l'offre (exports de gestion confidentiels) sont
matérialisés par des fichiers réels publics équivalents : un export de
publications (HAL) et les contrats de recherche de l'UGA issus de l'export scanR
des financements (MESR, data.gouv.fr — ANR, PIA, H2020, Horizon Europe, FP7…,
2005-2025). Régénération : npm run internal.
Les indicateurs de tête sont calculés sur le corpus complet via les
agrégations group_by d'OpenAlex. Les analyses nécessitant les notices
individuelles (réseau, loi de Lotka, résumés) reposent sur un échantillon
documenté (voir POC.md).
Séparation stricte ETL → data marts → restitution, qui préfigure le modèle d'un entrepôt décisionnel (le futur SID de l'établissement).
Connecteurs API → Fiabilisation → Modèle (data marts) → Restitution
(HAL + OpenAlex) (dédup, taxonomie, JSON versionnés (dashboard
réconciliation) Next.js)
pipeline/ # ETL — exécuté par `npm run pipeline`
├── connectors/ # interface Connector + OpenAlex + HAL + client HTTP
├── transform/ # taxonomie, normalisation, réconciliation
├── analytics/ # bibliométrie, Lotka, Kleinberg, tendances, réseau
├── marts/ # schémas + builders purs + orchestrateur
data/marts/ # data marts JSON générés (données réelles)
src/
├── app/ # page + routes API (drill-down live, santé)
├── components/ # KPI, charts, topics, network, quality, papers
└── lib/ # types, formatage, couleurs, accès marts
Principe de maintenabilité : aucun fichier monolithique (tous < ~200 lignes),
une responsabilité par module, et deux points d'extension déclaratifs (registre
de KPI et interface Connector). Voir docs/architecture.md.
Prérequis : Node.js >= 20.
# 1. Dépendances
npm install
# 2. Configuration (optionnelle — tout fonctionne sans)
cp env.example .env.local
# 3. Générer les data marts à partir des API réelles (HAL + OpenAlex)
npm run pipeline # ~2-3 min ; écrit data/marts/*.json
# npm run pipeline:dry # vérifie seulement la connectivité des API
# 4. Lancer le tableau de bord
npm run dev # http://localhost:3000Autres commandes :
npm run build # build de production
npm run typecheck # vérification TypeScript stricte
npm run test # tests unitaires (Vitest)
npm run lint # lint Next.js / ESLintNote WSL2 /
/mnt/c: sur un dossier monté Windows, npm ne crée pas toujours les liens dansnode_modules/.bin. Lancer alors les binaires directement, ex.node node_modules/next/dist/bin/next dev, ou installer le projet sur le système de fichiers Linux. Sur Vercel, GCP, AWS, Azure ou macOS,npm run …fonctionne normalement.
Le pipeline est piloté par un unique fichier de configuration,
pipeline/config.ts. Pour cibler un autre
établissement, il suffit d'y changer l'identifiant OpenAlex et l'acronyme HAL
(ou de définir les variables d'environnement correspondantes), puis de relancer
npm run pipeline. Tout le tableau de bord se met à jour.
Stratégie d'appels :
- Agrégats corpus complet :
group_by(volumétrie, types, accès ouvert, topics, journaux, auteurs). - Séries temporelles :
group_byrépété par année (matrice topic × année). - Notices individuelles : pagination par curseur (échantillon, top-cités, notices HAL avec DOI).
| Analyse | Méthode | Référence |
|---|---|---|
| h-index | h tel que h publications ont >= h citations | Hirsch, PNAS, 2005 |
| g-index | g tel que le top g cumule >= g² citations | Egghe, Scientometrics, 2006 |
| Productivité des auteurs | Loi de Lotka, ajustement log-log | Lotka, J. Wash. Acad. Sci., 1926 |
| Fronts émergents | Détection de rafales (automate 2 états, Viterbi) | Kleinberg, KDD, 2002 |
| Communautés de collaboration | Optimisation de modularité (Louvain) | Blondel et al., J. Stat. Mech., 2008 |
| Disposition du réseau | ForceAtlas2 | Jacomy et al., PLoS ONE, 2014 |
| Réconciliation HAL/OpenAlex | Record linkage (blocking + similarité) | Fellegi & Sunter, 1969 ; Christen, 2012 |
| Tendances | CAGR, régression linéaire (MCO) | — |
Justification détaillée, hypothèses et limites : POC.md et docs/methodology.md.
Le projet est conçu pour évoluer sans réécriture :
- Ajouter un indicateur de tête : une entrée dans
src/components/kpi/registry.ts. - Ajouter une source de données (Crossref, ScanR, Scopus, fichiers internes
du SID) : implémenter l'interface
Connector(pipeline/connectors/types.ts). - Harmoniser un nouveau type de document : une ligne dans
pipeline/transform/taxonomy.ts. - Ajouter un mart / une analyse : un builder pur dans
pipeline/marts/.
La cible recommandée est Vercel (éditeur de Next.js, déploiement en un clic). Le projet reste un Next.js standard, déployable partout. Détails et commandes pas-à-pas : docs/deployment.md.
npm i -g vercel
vercel # préversion
vercel --prod # productionDéfinir si besoin les variables OPENALEX_MAILTO,
NEXT_PUBLIC_INSTITUTION_OPENALEX_ID, HAL_STRUCT_ACRONYM,
NEXT_PUBLIC_INSTITUTION_NAME. Les data marts étant versionnés, aucun service
externe n'est requis au runtime (hors explorateur live).
Conteneur autoscalé, idéal pour rester dans l'écosystème GCP.
gcloud artifacts repositories create uga --repository-format=docker --location=europe-west1
gcloud builds submit --tag europe-west1-docker.pkg.dev/PROJECT/uga/dashboard
gcloud run deploy uga-dashboard \
--image europe-west1-docker.pkg.dev/PROJECT/uga/dashboard \
--region europe-west1 --allow-unauthenticated- Le plus simple : AWS Amplify Hosting (connecter le dépôt Git, build
npm run build). - Conteneur : pousser l'image sur ECR puis déployer sur ECS Fargate ou App Runner.
- Statique + SSR : adaptateur OpenNext vers Lambda + CloudFront + S3.
- Azure Static Web Apps (preset Next.js) pour un déploiement Git natif.
- Azure Container Apps : pousser l'image sur Azure Container Registry puis
az containerapp up.
Toutes ces cibles consomment le Dockerfile standard d'une application Next.js
(voir docs/deployment.md).
- Tests unitaires des algorithmes (Vitest) : h/g/i10, Lotka, Kleinberg, réconciliation, normalisation, taxonomie.
- TypeScript strict (
noUncheckedIndexedAccess, pas deany). - Build de production et
typecheckpropres.
npm run test && npm run typecheck && npm run build- Les indices h/g/i10 sont estimés sur les publications les plus citées de l'établissement ; la base est explicitement indiquée dans l'interface.
- Les analyses « notices » (réseau, Lotka, résumés) reposent sur un échantillon temporel borné et documenté, pas sur le corpus intégral.
- OpenAlex et HAL ont des périmètres et des taxonomies différents : c'est précisément ce que le volet réconciliation mesure et explicite.
- Aucune donnée n'est inventée ; en l'absence d'une information (par ex. résumé), l'interface l'indique.
Code sous licence MIT (voir LICENSE). Données : OpenAlex (CC0), HAL (CCSD). Ce logiciel ne redistribue aucun texte intégral.
Auteur : Thomas Berchet — démonstration pour l'Université Grenoble Alpes.