Engineering Analytics - livraison et développeurs

Engineering Analytics transforme les données qu’AppArch collecte déjà (merge requests, analyses, déploiements, tickets, incidents) en métriques de livraison. Une règle traverse chaque écran : un nombre qui ne peut pas être mesuré est affiché comme non mesuré, jamais comme zéro, et deux séries affichées côte à côte ne sont jamais présentées comme cause et effet.

Fiche de santé des projets (/reports/health)

Chaque score que la plateforme conserve par projet sur une seule fiche : ArchScan, ArchSecurity, Conformité, Git Health et le score dérivé de SonarQube (notes de fiabilité, sécurité et maintenabilité converties A=100 … E=20), chacun comme dernière valeur 0-100 de l’outil ou un tiret s’il n’a jamais évalué le projet.

• Consensus - la moyenne des sources présentes, toujours accompagnée de leur nombre (« sur 3 sources »). Ce n’est pas un indice pondéré et une source absente ne vaut jamais zéro.
• Évalué par - combien de projets chaque lentille a réellement examinés.
• Les outils divergent - projets où ArchScan et le score Sonar s’écartent de 20 points ou plus, avec le sens (« Sonar plus indulgent » / « Sonar plus strict »). Pas un verdict sur un outil ; un endroit où regarder.
• Toutes les lentilles au vert - chaque source évaluatrice à 80 ou plus, avec au moins deux sources.
• Constats externes - constats de sécurité ouverts GitLab et SonarQube par projet (total, critiques, élevés) listés en nombres sous le score ArchSecurity ; ils n’entrent jamais dans le consensus. Une tuile additionne les critiques ouverts de toute la fiche.
• Courbes de tendance par projet pour ArchScan et Sonar sur la période choisie, quality gate Sonar, couverture et duplication, et filtre par groupe de projets.

MR Insights (/reports/mr-insights)

Chaque merge request de chaque projet connecté est synchronisée toutes les 30 minutes : auteur, état, dates d’ouverture/merge/fermeture, qui a mergé, taille (ajouts, suppressions, fichiers modifiés) et heure de la première revue.

• Débit hebdomadaire - ouvertes, mergées et fermées par semaine.
• Liste de risques - merges notés selon la taille, l’auto-merge, l’absence d’approbation et l’absence de commentaires de revue ; les scores les plus élevés d’abord.
• Symptômes - MRs volumineuses, longues attentes de revue, auto-merges, merges non revus, avec les chiffres derrière chacun.
• Heatmap d’activité - « quand le travail atterrit » : 7 jours x 24 heures dans le fuseau horaire du lecteur, ouvertures et merges combinés. Les merges hors lundi-vendredi 08:00-19:59 heure locale sont comptés à part - non comme un verdict, mais comme une question à poser.
• Couverture de revue - part des MR fusionnées (commentaires synchronisés) ayant reçu au moins un commentaire humain compté d’une personne autre que l’auteur ; le reste a été fusionné en silence. S’appuie sur les verdicts des commentaires de revue, les accusés de réception ne comptent pas comme revue.

Les colonnes d’approbation ne couvrent que les MRs vues par ArchPilot.

Commentaires de revue (/reports/review-comments)

Chaque commentaire humain d’une merge request synchronisée est stocké à côté d’elle (GitLab, GitHub, Bitbucket Cloud et Azure DevOps ; les événements système comme « 2 commits ajoutés » et les commentaires d’ArchPilot lui-même ne sont jamais stockés). La question à laquelle l’écran répond est qui relit vraiment, et un verdict par commentaire garde le décompte honnête :

• Non jugé - compte comme travail de revue jusqu’à ce que quelqu’un dise le contraire.
• Revue - substantiel : une question, un problème, une suggestion, une décision.
• Exclu - un accusé de réception (« merci », « ok, je fais », un emoji). Retiré de tout décompte.

Un propriétaire ou administrateur du workspace fixe les verdicts à la main. Avec Paramètres des modules > ArchPilot > Classer les commentaires en attente avec l’IA activé, le fournisseur d’IA de l’installation juge toutes les 10 minutes les commentaires pas encore jugés ; le verdict d’un administrateur n’est jamais écrasé. L’interrupteur n’apparaît que si l’administrateur de l’instance a configuré un fournisseur d’IA et activé au moins une fonction d’IA. La carte IA de la page indique ce que la classification a coûté jusqu’ici (appels, commentaires jugés, jetons d’entrée et de sortie) et ce qu’a fait le dernier appel ; un administrateur peut lancer immédiatement une passe avec Classer les commentaires en attente maintenant (jusqu’à 40 commentaires, deux appels au fournisseur). La classification consomme la clé IA de l’installation et est décomptée du quota de l’assistant.

Les commentaires comptés alimentent la tuile Commentaires de revue et la répartition Qui commente de MR Insights, ainsi que la valeur Commentaires de revue du profil développeur. Les commentaires de l’auteur de la MR sur sa propre MR sont listés mais jamais comptés comme revue donnée.

AI Impact (/reports/ai-impact)

Ce que le fournisseur d’IA de l’installation a coûté à cet espace de travail - explications de constats, réponses de l’assistant et appels de classification des commentaires de revue (jetons d’entrée/sortie, régénérations, par personne et par modèle ; les deux derniers sont au niveau de l’espace de travail et ne sont comptés que dans la vue de tous les projets) à côté de ce qui a changé les mêmes semaines : score ArchScan, densité des constats ArchPilot, fonctionnalités et correctifs mergés. La note de bas de page le dit clairement : les séries sont montrées ensemble, aucune causalité n’est affirmée.

DORA (/reports/dora)

Les quatre métriques sont affichées ; les deux qui ont besoin de données d’incidents restent vides tant qu’aucune source d’incidents n’est connectée.

Métrique	Source	Notes
Fréquence de déploiement	Événements de déploiement du catalogue (Argo CD, Kubernetes, Flux)	L’heure de déploiement est une observation avec jusqu’à 10 minutes de retard, pas un webhook. Les sources Kubernetes seules signalent des tags d’image et non des commits ; elles sont comptées comme non traçables.
Lead time	Du merge (faits MR) au déploiement qui porte le commit	Par environnement ; une révision non appariée est inconnue, jamais zéro. La ventilation par étapes montre l’attente de revue, en revue et l’attente de livraison ; les deux étapes non mesurées sont dessinées en gris.
Taux d’échec des changements	Incidents ouverts dans l’heure suivant un déploiement du même service	Corrélation temporelle, pas preuve de cause - la page le dit.
Temps de rétablissement	De l’ouverture à la clôture de l’incident	Même source.

Les bandes elite/élevé/moyen/faible sont une approximation de la cadence hebdomadaire et se placent à côté du vrai nombre, jamais à sa place. Les médianes par étape sont indépendantes ; elles ne s’additionnent pas à la médiane globale.

Flux des tickets (/reports/issue-flow)

Avec une connexion Jira, les tickets sont relus toutes les 30 minutes et le flux est dérivé du changelog de chaque ticket : la première transition hors de new démarre le chronomètre, la dernière transition vers done l’arrête. Débit, temps de cycle, travail en cours et vieillissement sont rapportés avec sept alarmes (surcharge WIP, en cours obsolète, backlog vieillissant, en cours non assigné, rouvert, dominé par les bugs, faible couverture du flux). Les sous-tâches sont exclues du débit, pour qu’une équipe qui découpe chaque story en six ne paraisse pas six fois plus rapide.

Sources d’incidents

Les incidents Dynatrace et New Relic sont importés dans l’espace de travail et rattachés aux services par leur nom. Les incidents non rattachés sont comptés et affichés ; une plateforme connectée qui n’a stocké aucun incident reçoit son propre avertissement, car un jeton limité au mauvais compte se valide parfaitement puis n’alimente rien - ce que DORA lirait sinon comme un taux d’échec de 0 %.

Historique Conformité & Git Health (/reports/score-history)

Les deux scores dans le temps. La valeur hebdomadaire d’un projet est son dernier scan réussi de la semaine ; la ligne globale est la moyenne des projets scannés cette semaine-là et en indique le nombre. Les semaines sans scan sont des trous, jamais reportés. Par projet : dernier score, variation entre le premier et le dernier scan de la période, nombre de scans et courbe de tendance ; les tuiles donnent la moyenne actuelle, la variation moyenne et le nombre de projets en progrès ou en recul.

Tendance des constats de sécurité (/reports/security-trend)

Constats GitLab et SonarQube vus comme un cycle de vie. La date de détection est celle du fournisseur ; un constat est clos dès qu’une synchronisation ne le voit plus ouvert (résolu ou rejeté). À partir de ces deux dates la page reconstitue, par semaine et par source, les nouveaux constats, les clos et le reliquat ouvert en fin de semaine - reconstitué, non échantillonné, d’où un historique pour les semaines antérieures à la première ouverture de la page. Tuiles : ouverts maintenant (avec critiques), nouveaux et clos sur la période, variation nette, médiane des jours jusqu’à clôture. Tableaux par source et par projet. Les scans ArchSecurity d’AppArch sont des instantanés par exécution et restent hors de ce cycle.

Cycle de vie des ADR (/reports/adrs)

Les décisions d’architecture comme un processus : effectifs par statut, propositions ouvertes avec leur âge médian, décisions par mois selon l’issue, délai moyen de la création à la décision, taux d’acceptation, décisions remplacées, étiquettes et répartition par projet. Les propositions de plus de 30 jours sont listées de la plus ancienne à la plus récente - une proposition que personne ne tranche est une décision par défaut.

Accès et contribution (/reports/developer-access)

Pour chaque développeur synchronisé : les projets dont il est membre (selon le fournisseur), ceux où il a été actif sur la période (merge request ouverte ou commentaire de revue compté) et les adhésions dormantes - accès sans activité. Et l’inverse : contributions sur des projets où le fournisseur ne le liste pas comme membre. La dormance n’est affirmée que sur les projets dont les merge requests sont synchronisées ; la page en indique le nombre. Les comptes de service sont listés mais exclus des tuiles.

Développeurs (/developers)

Toute personne qui touche un dépôt connecté (membres et auteurs de MR) est synchronisée par projet, uniquement pour les projets où la synchronisation des développeurs est activée (désactivée par défaut). Chaque développeur a un profil (/developers/{id}) avec les projets touchés, les MRs rédigées et un score de revue basé sur ArchPilot. Les bots sont détectés à partir des signaux du fournisseur et marqués comme comptes de service ; la marque peut être posée ou retirée à la main, et une marque manuelle n’est jamais écrasée par la synchronisation.

Prérequis

• Un identifiant Git avec accès aux pull requests pour MR Insights, la heatmap et les développeurs.
• Une source de déploiement (Argo CD, Kubernetes, Flux) pour la fréquence de déploiement et le lead time.
• Jira pour le flux des tickets ; Dynatrace ou New Relic pour le taux d’échec et le temps de rétablissement.
• AI Impact nécessite le fournisseur d’IA de l’installation, configuré par l’opérateur (IA) ; il n’y a pas de clé par espace de travail.