GitLab + IA = votre tableau de bord PM/QA : comment on transforme les flux de tickets en décisions portfolio

GitLab est une source de vérité phénoménale. C'est aussi un outil de reporting médiocre.

Si vous avez déjà ouvert l'onglet « Insights » de GitLab et tenté d'en tirer une décision réelle — « est-ce que ce prestataire tient ses délais ? on livre plus vite ce mois-ci ? la QA trouve vraiment plus de bugs ou ouvre juste plus de tickets ? » — vous savez de quoi on parle. La donnée existe. Le récit, non.

Depuis trois ans, on construit et affine une pile de tableaux de bord au-dessus de GitLab qui donne aux équipes PM, QA et finance quelque chose d'actionnable : rapports hebdomadaires narrés par IA, détection d'anomalies, et vue portfolio multi-projets, avec la discipline coût qui vient du fait d'utiliser un outillage déjà payé.

Voici l'écriture honnête de ce qu'on a construit, ce que ça coûte, et où ça bat — et où ça perd contre — Jira + Atlassian Intelligence.

Pourquoi les tickets GitLab seuls ne racontent pas l'histoire

Une équipe d'ingénierie de taille moyenne génère 500-2000 événements de tickets par semaine sur GitLab : ouvertures, fermetures, changements de label, time-tracking, liens vers MR, commentaires. Ce sont des événements bruts. Ce ne sont pas des décisions.

Les quatre questions qu'un directeur de l'ingénierie pose réellement chaque lundi :

1. Est-ce qu'on est dans les temps ? Vélocité, débit, blocages, SLA prestataires.
2. Où sont les risques ? Anomalies — pics de bugs soudains, stories bloquées, prestataires en retard.
3. Qu'est-ce qui demande ma décision ? Escalades que l'équipe n'a pas résolues seule.
4. Quelle est l'histoire de coût ? Où sont parties les heures cette semaine, et est-ce que ça valait le coup ?

L'onglet « Insights » natif de GitLab ne répond à aucune de ces questions. Il vous montre des graphiques. Les graphiques sont des faits. Le récit manque.

C'est le trou qu'on comble.

Ce qu'on a construit : trois tableaux de bord au-dessus de GitLab

On ne fait pas tourner un outil de dashboard générique. On a construit trois tableaux de bord opinés, à but étroit, chacun calibré pour un lecteur précis :

Tableau de bord 1 — Vélocité PM (pour le chef de projet)

• Stories ouvertes / fermées / en cours par projet par semaine.
• Time-tracking réel vs estimé, par assigné et par prestataire.
• Chemin critique : quels tickets bloquent quels jalons.
• Narratif hebdomadaire écrit par IA : « Projet X a livré 18 stories cette semaine, en baisse depuis 24 la semaine dernière. La baisse est concentrée sur le refactor d'authentification (3 stories bloquées sur l'environnement de test d'intégration, hors service depuis mardi). Action : débloquer l'environnement de test ou accepter le glissement du jalon M3. »

Le narratif est le différentiateur. Un PM junior obtient le même contexte du lundi matin qu'un PM senior assemblerait après vingt minutes de clics. Le tableau de bord fournit la donnée structurée ; un LLM (Claude Sonnet 4.6 dans notre config par défaut) la transforme en prose.

Tableau de bord 2 — Santé QA (pour le lead QA)

• Taux d'arrivée de bugs, par sévérité, par composant, par rapporteur.
• Temps moyen jusqu'à la QA, jusqu'à la merge, jusqu'à la fermeture.
• Détection de tests instables — tickets réouverts plus de deux fois.
• Narratif IA sur les anomalies uniquement : « L'arrivée de bugs sur le module checkout a triplé cette semaine (de 4 à 14). La plupart des rapporteurs sont externes (utilisateurs en production), pas la QA interne. Probable régression en production depuis le déploiement du 8 mai. Recommandation : rollback ou priorité hotfix. »

On affiche délibérément les anomalies, pas le firehose. Le lead QA n'a pas besoin de lire un rapport hebdomadaire de 12 pages ; il a besoin de savoir ce qui a changé.

Tableau de bord 3 — Performance prestataires (pour le directeur de la livraison)

Si vous opérez un engagement PMaaS avec plusieurs prestataires ou freelances, c'est le tableau de bord qui rentabilise tout le reste. Métriques par prestataire :

• Heures facturées vs heures estimées.
• Taux de livraison à temps.
• Taux de fuite de défauts (bugs trouvés post-merge par story livrée).
• Conformité au change-control — ont-ils déposé de vraies demandes de changement pour les changements de périmètre en cours de route ?
• Narratif IA : « Prestataire A a livré 14 stories cette semaine, 12 à l'heure, taux de fuite défauts 7%. Prestataire B a livré 9 stories, 4 en retard, taux de fuite défauts 22%. Prestataire B a raté le gate QA sur 3 sprints consécutifs. Recommandation : escalade au prochain comité de pilotage. »

C'est de cela qu'agrège le pipeline du résumé exécutif mensuel — mais à cadence hebdomadaire et avec granularité par prestataire.

La couche IA : où est (vraiment) la magie

La couche IA fait trois jobs, et seulement trois :

1. Génération du narratif hebdomadaire

Chaque dimanche soir, un job planifié extrait les données GitLab de la semaine, les normalise dans un prompt structuré, et demande à un LLM d'écrire un narratif de 200 mots par tableau de bord. Le prompt est verrouillé :

Tu écris un narratif hebdomadaire PM. Utilise uniquement les données fournies.
Ne fabrique jamais de métriques. Si un chiffre manque, dis-le.
Format : TL;DR (une phrase), Top movers (2-3 puces), Risques (1-2 puces),
Recommandation (une phrase avec un verbe).
Ton : PM senior à directeur de l'ingénierie. Pas de langage marketing.

Le narratif arrive le lundi à 7h sur un canal Slack et en haut du tableau de bord. Le PM le lit avant le daily, a le contexte pour 80% des questions, et utilise le daily pour les 20% restants.

2. Détection d'anomalies

On n'utilise pas de ML pour ça. On utilise de simples statistiques glissantes — la médiane sur 4 semaines plus 1,5× l'écart interquartile comme borne supérieure. Tout ce qui dépasse est marqué. Le job de l'IA n'est pas de détecter l'anomalie ; c'est de l'expliquer. Étant donné les données marquées et le contexte GitLab associé (commentaires de tickets, merge requests, commits), le LLM rédige l'explication et l'action recommandée.

Cette séparation compte. Les stats sont déterministes et bon marché ; l'explication IA est la partie où le LLM ajoute vraiment de la valeur. Inverser ça (demander au LLM de détecter les anomalies) est la meilleure manière de dépenser une fortune en tokens tout en obtenant des faux positifs.

3. Extraction d'actions

En bas de chaque narratif hebdomadaire, le LLM extrait jusqu'à cinq actions, chacune formatée comme un corps de ticket GitLab brouillon — titre, description, labels suggérés, assigné suggéré. Le PM peut créer le ticket d'un clic depuis le tableau de bord. C'est la fonctionnalité à plus forte rentabilité de la pile : elle convertit « j'ai lu le rapport » en « j'ai créé trois tickets » en 30 secondes.

La vue multi-projets (portfolio)

Pour les organisations qui font tourner 4+ projets (typique pour un engagement PMaaS ou une entreprise multi-produits), on ajoute une couche portfolio :

• Un groupe GitLab → un portfolio.
• Chaque projet remonte ses métriques vélocité, QA, prestataires.
• Les anomalies inter-projets remontent — « Prestataire C livre plus vite sur Projet X mais le taux de défauts a explosé sur Projet Y ; coût de context-switching probable. »
• Export trimestriel pour comité de pilotage : PDF, charté, avec les quatre narratifs IA cousus ensemble et un résumé exécutif en page 1.

Le flux de données est direct :

GitLab API (REST + GraphQL)
   ↓
Postgres (normalisé, dédupliqué, indexé temporel)
   ↓
Agrégations style dbt (vélocité, QA, vues matérialisées prestataires)
   ↓
UI Dashboard (Next.js, Recharts)
   ↓
Job narratif LLM (cron, hebdomadaire)
   ↓
Post Slack + email + export PDF

Coût infra total pour un portfolio de 4 projets : ~140 $/mois (Postgres sur un plan managé, une petite VM pour le cron, coûts API LLM autour de 8 $/semaine pour les quatre narratifs). Le plus gros poste est l'ingénierie — les tableaux de bord eux-mêmes ont demandé environ 6 semaines d'ingénierie senior pour construire, affiner et durcir. On redéploie la pile pour de nouveaux clients en 3-5 jours maintenant que le template existe.

Comparatif coût : cette pile vs Jira + Atlassian Intelligence

La comparaison honnête, pour une organisation d'ingénierie de 50 personnes sur un portfolio de 4 projets :

Là où Jira gagne : prêt à l'emploi pour les équipes qui ont besoin de tableaux de bord génériques et n'ont pas de capacité d'ingénierie pour maintenir une pile custom. L'effet réseau d'Atlassian (chaque PM junior connaît Jira) réduit le coût d'onboarding.

Là où cette pile gagne : vous utilisez déjà GitLab, vous voulez des dashboards performance-prestataires (Jira n'a pas d'équivalent natif), vous voulez des narratifs IA personnalisés à votre ton, et vous ne voulez pas payer 20 K $/an par 50 utilisateurs pour du reporting.

Pattern d'implémentation (pour les équipes qui veulent construire ça en interne)

Si vous préférez construire vous-même plutôt qu'acheter la nôtre, le chemin est :

Étape 1 — Streamer les événements GitLab vers Postgres

// Pseudo-code pour le job d'ingestion
const since = await db.getLastSyncTimestamp('issues');
const issues = await gitlab.issues.all({
  group: 'votre-portfolio',
  updated_after: since,
  per_page: 100
});
 
for (const issue of issues) {
  await db.upsertIssue(issue);
  await db.recordEvents(issue.id, issue.events);
}

Lancez-le toutes les 15 minutes. Soyez courtois avec l'API GitLab (les rate limits existent). Backfill 90 jours au premier run ; incrémental ensuite.

Étape 2 — Définir les vues matérialisées

CREATE MATERIALIZED VIEW velocity_weekly AS
SELECT
  project_id,
  date_trunc('week', closed_at) AS week,
  COUNT(*) FILTER (WHERE state = 'closed') AS closed_count,
  COUNT(*) FILTER (WHERE state = 'opened') AS opened_count,
  SUM(time_spent_minutes) AS time_spent_minutes
FROM issues
WHERE closed_at > now() - interval '12 weeks'
GROUP BY project_id, date_trunc('week', closed_at);

Refresh hebdomadaire via cron. Pour les vues QA et prestataires, même pattern avec d'autres filtres.

Étape 3 — Envelopper un appel LLM autour de la donnée structurée

const data = await db.getWeeklyDigest({ projectId, week });
const prompt = buildNarrativePrompt(data); // template verrouillé
const narrative = await llm.complete(prompt, {
  model: 'claude-sonnet-4-6',
  max_tokens: 400,
  temperature: 0.2
});
await slack.post(`#pm-${projectId}`, narrative);

Le prompt verrouillé est toute la raison pour laquelle ça marche. Ne laissez pas le LLM être créatif ; laissez-le être un traducteur de données structurées vers la langue naturelle.

Étape 4 — Livrez le tableau de bord, pas la donnée

Rendu en Next.js + Recharts. La section haute du dashboard est le narratif IA, le bas ce sont les graphiques de support (au cas où quelqu'un est en désaccord avec le narratif et veut vérifier). Cachez agressivement — les tableaux de bord se reconstruisent sur planning, pas à chaque page-load.

Où cette approche échoue

On se disqualifie d'abord. Ne construisez pas ça si :

• Vous avez moins de 3 projets actifs. La couche portfolio est overkill ; GitLab natif + un all-hands hebdomadaire suffit.
• Vous n'avez pas de PM ou pas d'engagement PMaaS. Les tableaux de bord sans lecteur sont de la décoration. Embauchez le lecteur d'abord.
• Vous ne faites pas confiance aux narratifs LLM pour de la consommation exécutive. On ne peut pas argumenter contre ça — mais dans ce cas, construisez sans la couche IA (les tableaux structurés battent quand même l'onglet Insights de GitLab).
• Votre équipe est déjà sur Jira et heureuse. Le coût de migration est réel. Le calcul ne bascule que si vous êtes déjà sur GitLab.

Ce qu'on construit pour nos clients

Notre engagement PMaaS embarque cette pile de tableaux de bord :

• Déploiement 3-5 jours sur votre portfolio GitLab.
• Narratifs IA calés sur votre ton (on miroite votre style de communication PM existant).
• Distribution Slack/email/PDF aux lecteurs que vous spécifiez.
• Export trimestriel pour comité de pilotage, charté.
• Session mensuelle d'ajustement pour adapter les prompts à l'évolution de votre business.

Le tableau de bord est livré dans notre engagement PMaaS — typiquement aux côtés d'un audit prestataire, d'un comité de change-control, et du résumé exécutif mensuel.

Questions fréquentes

Est-ce que ça marche avec GitLab auto-hébergé ? Oui. Les endpoints API sont identiques entre GitLab.com et auto-hébergé (CE/EE 14.x+). Pour l'auto-hébergé on déploie en général sur le même réseau pour réduire la latence du job d'ingestion.

Les narratifs IA peuvent-ils être en arabe ou en anglais ? Oui. On passe la langue cible en paramètre du prompt et on verrouille le LLM sur l'arabe MSA ou l'anglais. La couche de données structurées est agnostique à la langue.

Quid de la précision du time-tracking ? Le tableau de bord n'affiche que ce qui est dans GitLab. Si votre équipe ne loggue pas le temps, le graphique vélocité-vs-estimé sera vide. On aide les clients à mettre en place une discipline de time-tracking avant la mise en production du dashboard.

Peut-on intégrer Jira aussi ? On ne le recommande pas — mais techniquement oui, en écrivant un job d'ingestion Jira API parallèle au job GitLab. Les vues matérialisées et les prompts LLM en aval sont agnostiques de l'outil.

Le code source est-il disponible ? Pas en open-source. La pile fait partie de notre engagement PMaaS. Les patterns dans cet article sont à vous.

Vous voulez le tableau de bord sur votre portfolio GitLab ?

Réservez un audit PMaaS — on vous montrera à quoi ressemble votre donnée à travers ce prisme avant tout engagement.

Ou lisez le playbook résumé exécutif mensuel et le guide reporting performance prestataires pour le contexte PMaaS plus large.