38 minutes de CI cumulées par jour ouvré pour un projet, contre 6 minutes pour un autre logé sur la même organisation GitHub : voilà ce qu’a révélé la première semaine de suivi mise en place pour une équipe qui gère huit sites WordPress en parallèle pour des clients différents. Avant ce relevé, personne ne savait précisément où partait le budget de minutes d’exécution partagé entre les projets, seulement une impression diffuse que « la CI est plus lente qu’avant ».
Ce constat n’a rien d’exceptionnel : dès qu’une agence dépasse quatre ou cinq projets actifs simultanément, l’intuition individuelle ne suffit plus à répartir l’attention. Un tableau de bord simple, alimenté automatiquement, remplace cette intuition par un chiffre vérifiable, projet par projet, semaine après semaine.
Ce que le tableau doit afficher, et rien de plus
La tentation, en construisant ce genre d’outil, consiste à vouloir tout mesurer : durée par job, par étape, par test. Ce niveau de détail appartient à l’optimisation technique de la CI elle-même, un sujet distinct. Le dashboard décrit ici répond à une question différente, plus proche de la gestion de portefeuille de projets : combien de minutes de CI chaque projet a-t-il consommées cette semaine, et cette consommation augmente-t-elle ?
Quatre colonnes suffisent : le nom du projet, le total de minutes cumulées sur les sept derniers jours, la variation par rapport à la semaine précédente, et le nombre d’exécutions déclenchées. Rien de plus n’est nécessaire pour prendre une décision d’arbitrage.
Récupérer la donnée sans complexité inutile
Chaque fournisseur de CI expose une API permettant de lister les exécutions passées avec leur durée. Un script planifié, exécuté une fois par jour, interroge cette API pour chaque dépôt suivi et cumule les résultats dans un fichier structuré :
{
"semaine_du": "2024-07-15",
"projets": [
{ "nom": "intranet-cooperative-agricole", "minutes_cumulees": 266, "executions": 41 },
{ "nom": "vitrine-cabinet-notarial", "minutes_cumulees": 44, "executions": 12 },
{ "nom": "boutique-materiel-photo", "minutes_cumulees": 189, "executions": 33 }
]
}
Ce fichier alimente ensuite une page HTML statique, générée à chaque exécution du script et publiée sur un espace interne accessible à toute l’équipe. Aucune base de données ni service tiers de tableau de bord n’est nécessaire pour ce niveau de suivi.
Ce que révèle la comparaison entre projets
Sur l’exemple de l’intranet de la coopérative agricole, la consommation dépassait largement celle des autres projets, pour une raison simple une fois identifiée : chaque poussée de code déclenchait l’exécution complète de la suite, y compris pour des modifications mineures de documentation. Le problème n’était pas la lenteur de la CI, mais la fréquence de déclenchement rapportée au volume de code réellement modifié.
Une lecture par équipe, pas seulement par projet
En ajoutant une colonne indiquant l’équipe responsable de chaque projet, le tableau a également mis en évidence qu’une seule équipe concentrait l’essentiel de la consommation, information utile lors de la répartition du temps de développement pour le trimestre suivant.
Les limites à connaître avant de s’y fier
- Le total de minutes ne dit rien de l’utilité des tests exécutés : un projet peut consommer peu de minutes tout en étant mal couvert.
- La comparaison brute entre projets de tailles très différentes reste trompeuse si elle n’est pas mise en perspective avec le volume de code.
- Le dashboard doit rester consultable en une minute ; au-delà, il devient un rapport de plus que personne ne regarde.
Un chiffre cumulé sur sept jours dit souvent plus qu’une alerte ponctuelle sur une exécution lente.
En résumé
Un tableau de bord hebdomadaire du temps de CI cumulé par projet ne remplace pas un travail d’optimisation technique, mais il donne à une agence multi-projets un langage commun pour discuter de priorités. Sur ce cas, l’écart de six fois entre le projet le plus consommateur et le plus léger a suffi à justifier une revue ciblée des déclencheurs de pipeline, sans qu’aucune ligne de configuration de CI n’ait eu besoin d’être modifiée pour produire ce premier diagnostic.
