Planifie et organise la synchronisation de la collecte des données de ton QE Score
- Simon CHAMPENOIS
- 29 mars
- 4 min de lecture
Dernière mise à jour : il y a 2 jours
Le QE Score est un indicateur vivant : pour qu’il reflète fidèlement la réalité d’une application, il doit être alimenté en données fraîches et à jour. Une collecte ponctuelle ou trop espacée peut fausser l’analyse et masquer des dérives en cours. C’est pourquoi il est crucial de mettre en place une stratégie de collecte régulière, voire quotidienne, pour certaines sources de données comme SonarQube, Jira ou GitLab. Cette régularité permet d'assurer la fiabilité, la réactivité et la précision du score, offrant ainsi une vision en temps réel de la qualité des projets. Le choix du mode de collecte – synchrone ou asynchrone – devient alors stratégique.
Les défis de la collecte des métriques qualité
Disparité des outils : Tests UI, API, sécurité, performance, qualité de code… Les métriques sont dispersées sur différents outils et plateformes.
Fréquence et mise à jour des données : Certaines mesures sont en temps réel, d’autres mises à jour moins fréquemment, ce qui complique leur analyse.
Complexité d’intégration : Récupérer et centraliser ces données demande souvent des développements spécifiques et du temps.
Le mode synchrone : immédiat, fiable, mais plus exigeant
Le mode synchrone repose sur un fonctionnement événementiel : chaque fois qu’un événement se produit (ex. : une analyse SonarQube se termine, un ticket Jira change de statut, un commit est effectué sur GitLab, un automate de test fonctionnel se termine), la donnée est immédiatement envoyée vers la base de données ou le Google Sheet.
✅ Avantages :
Données en temps réel : les informations sont à jour dès qu’un événement survient.
Moins de requêtes inutiles : on évite de "scraper" ou d'interroger régulièrement les APIs, ce qui diminue la charge réseau et le coût API.
Fiabilité accrue : le QE Score reflète exactement la réalité du moment.
⚠️ Inconvénients :
Implémentation plus complexe : il faut que chaque outil dispose d’un module d’envoi (ex. : webhook, event hook, service externe).
Dépendance aux outils : tous les outils ne supportent pas forcément ce type d’intégration sans ajout ou adaptation.
Maintenance supplémentaire : en cas de changement d’API ou d’événement, il faut mettre à jour les modules d’envoi.
Le mode asynchrone : simple à déployer, mais moins réactif
Le mode asynchrone fonctionne par interrogation périodique : un script ou le Google Sheet lui-même vient récupérer les données depuis les APIs à intervalles définis (toutes les heures, toutes les nuits, etc.).
✅ Avantages :
Facile à mettre en place : pas besoin de modifier les outils ou d’ajouter des modules, un simple appel d’API suffit.
Standardisé : fonctionne avec tous les outils disposant d’une API, sans configuration complexe.
Idéal pour un premier niveau d’automatisation : permet d’avoir des données relativement fraîches sans gros effort technique.
⚠️ Inconvénients :
Données potentiellement obsolètes : il peut y avoir un décalage entre le moment où un événement se produit et celui où il est récupéré.
Requêtes régulières, parfois inutiles : si les données n’ont pas changé, les appels API sont redondants et consomment des ressources.
Moins adapté aux usages temps réel : un QE Score mis à jour uniquement la nuit ne reflètera pas les évolutions de la journée.
Une approche hybride : combiner le meilleur du synchrone et de l’asynchrone pour son QE Score
La solution la plus efficace pour garantir un QE Score fiable et à jour est souvent une approche hybride, combinant les deux modes de collecte : synchrone pour les données critiques et facilement disponibles en temps réel, et asynchrone pour les autres.
🧩 Comment ça fonctionne ?
Pour certaines données, le mode synchrone est simple à mettre en place. Par exemple, à la fin d’un pipeline CI/CD, un appel automatique est fait pour envoyer directement les résultats SonarQube (dette technique, couverture des tests, etc.) dans la base ou le Google Sheet.
Pour les données qui ne disposent pas encore de mécanisme d’envoi ou qui sont plus difficiles à intégrer, on complète avec un mode asynchrone, basé sur des planifications régulières.
📅 Des fréquences adaptées à chaque type de données :
Sécurité du code : failles de sécurité peuvent être récupérées plusieurs fois par jour.
Tests fonctionnels et de performance : une récupération quotidienne suffit, souvent après une exécution planifiée la nuit.
Qualité Projet (ex. : tickets ouverts, bugs) : toutes les 2h ou 4h selon le rythme du projet.
Activité GitLab : 1 à 2 fois par jour pour suivre les commits, MRs, etc.
✅ Avantages de cette approche :
Permet une transition progressive vers le synchrone, sans tout implémenter d’un coup.
Optimise l’effort technique : les ressources sont investies en priorité là où l’impact sur la fraîcheur des données est le plus fort.
Évite les gaspillages de ressources sur des données peu évolutives.
⚠️ Point de vigilance :
Demande une bonne organisation : il faut cartographier les sources de données, suivre leur fréquence de mise à jour, et ne pas oublier certaines données.
🔐 Conclusion : Le succès du QE Score repose autant sur la qualité du calcul que sur la fraîcheur et la fiabilité des données. Une approche hybride bien organisée est donc la clé pour garantir sa pertinence et la confiance des utilisateurs.
Et pour vous, quel est la meilleure solution de planification de collecte de la données ?
hybride
asynchrone
synchrone
autre approche
Comments