Logiciel · management de l'ingénierie

Analytique d'ingénierie : flux de livraison et métriques DORA à partir de GitLab et du tracker, en lecture seule et sous audit

Un système d'analyse interne qui lit le GitLab et le tracker d'une entreprise via un connecteur en lecture seule et montre à la direction technique flux de livraison, métriques DORA et qualité des processus, avec MFA et audit en ajout seul.

Secteur
Logiciel · management de l'ingénierie
Technologies
Python 3.12 · FastAPI · SQLAlchemy 2 + Alembic
MFA

Le défi

La direction technique voulait une vision factuelle de l'activité de développement, du flux de livraison et de la qualité des processus sur un grand GitLab auto-hébergé et un outil de suivi des tickets. Deux contraintes ont façonné tout le système. Il devait être incapable de modifier quoi que ce soit dans GitLab, quel que soit le jeton configuré. Et il devait éclairer les décisions de management sans devenir une notation automatique des personnes : chaque chiffre avait besoin de son contexte, de la taille de son échantillon et d'une mention claire quand des données manquaient.

La solution

Nous avons construit un connecteur unique par lequel passe chaque appel à GitLab. Il refuse tout par défaut, n'autorise que les requêtes GET et HEAD, n'accepte GraphQL que sous forme de documents de requête figés, protège contre le SSRF et les redirections, et refuse les jetons administrateur, à droits d'écriture ou de maintainer avant leur enregistrement. Les imports sont des upserts idempotents, et les agrégats quotidiens sont recalculés après chaque exécution. Les auteurs de commits sont rattachés à des personnes au moyen de requêtes limitées et des événements de push, et environ 98 % des commits sont attribués. Le code calcule chaque métrique ; le modèle de langage se contente de mettre en mots des agrégats déjà calculés.

Comment tout s'enchaîne

  1. 01 Import en lecture seule
  2. 02 Résolution d'identités
  3. 03 Normaliser et agréger
  4. 04 Métriques et DORA
  5. 05 Tableau de bord et questions

Ce que nous avons livré

  • Import des groupes, projets, commits, merge requests, commentaires et pipelines
  • Résolution d'identités, de l'e-mail du commit jusqu'au compte
  • Comparaison de périodes qui tient compte de la couverture des données et des jours ouvrés, avec la taille de l'échantillon affichée sur chaque ratio
  • Métriques de livraison DORA : fréquence de déploiement, délai de mise en production, taux d'échec des changements et reprises ; un niveau DORA n'est affiché que si toutes les données d'entrée sont disponibles
  • Lien avec l'outil de suivi des tickets : tâches reliées aux merge requests, incidents, temps de rétablissement et part du travail non planifié
  • Rôles et absences issus de l'API d'un système RH ou d'un export CSV
  • Tableau de bord avec vues par équipe, par projet et des auteurs non rattachés, plus des exports
  • Un serveur MCP et un panneau « interroger les données »
  • Environ 630 tests automatisés

Fonctionnalités

  • Connecteur qui refuse par défaut : GET et HEAD uniquement, documents GraphQL figés, mutations rejetées
  • Contrôle du jeton avant enregistrement : les jetons administrateur, à droits d'écriture et de maintainer sont refusés
  • Connexion multifacteur TOTP obligatoire, sans inscription publique
  • Journal d'audit en ajout seul (append-only), imposé dans PostgreSQL
  • Secrets chiffrés avec Fernet et masqués dans les journaux
  • Prompts versionnés ; seuls des agrégats sont envoyés au modèle

Intégrations

  • API REST et GraphQL de GitLab, en lecture seule
  • API de l'outil de suivi des tickets
  • API d'un système RH ou export CSV
  • API Google Gemini

Technologies

  • Python 3.12
  • FastAPI
  • SQLAlchemy 2 (async) + Alembic
  • PostgreSQL 16
  • Redis + ARQ
  • httpx
  • React 18 + TypeScript + Vite
  • pytest

Résultat

En service sur les données réelles de l'entreprise, avec une année complète importée. Les synchronisations sont lancées à la demande.

Pourquoi le modèle ne fait-il que mettre les chiffres en mots ?

Les managers prennent des décisions sur la base de ces chiffres : chacun doit donc être reproductible. Le code calcule chaque métrique à partir des données stockées, avec sa période, sa couverture et la taille de son échantillon. Le modèle de langage ne reçoit que ces agrégats, avec un prompt versionné, et les transforme en synthèse lisible ou en réponse à une question. Il ne voit jamais les commits ni les commentaires bruts et ne produit jamais de chiffre de lui-même. Si les données d’une période sont incomplètes, le tableau de bord le signale au lieu d’afficher un chiffre faussement sûr.

Parlons de votre projet

Présentez-nous votre projet