Documentation / Qualité et gouvernance

Mesure par rapport à N−1

Comment Yuli mesure la qualité, la compare toujours à la version précédente et oblige l’agent à s’améliorer avant de tester.

Yuli mesure la qualité du code en continu et la compare toujours à la version précédente, N−1. La règle est simple : jamais en arrière, toujours en avant.

Tout se mesure automatiquement : à l’ouverture du projet, après chaque build, test ou vérification, à chaque nouveau commit et dans l’éditeur pendant que vous écrivez.

Le panneau Qualité

Il s’ouvre depuis l’indicateur de la barre d’état (par exemple, A · σ 4,5 ▲) ou depuis le panneau inférieur.

Onglet À quoi il sert
Résumé Note globale, sigma, dette, clean code, dernière mesure de l’agent, prochaines améliorations et comparaison avec N−1.
Pratiques Les 14 pratiques de clean code, leurs bénéfices et où agir en premier.
Mesure La phase de Mesure de l’agent : verdict, contrôles, avant → après et tours.
Décision Refactoriser ou faire évoluer ? Critères, matrice et critère économique.
Maintenabilité Indice de maintenabilité, complexité cognitive, duplication, couplage et dette.
Prévention Constats de sécurité, de performance, de robustesse et d’accessibilité.
Architecture Règles d’architecture du projet.
Santé des tests État de la suite de tests.
Qualité Complexité cyclomatique, Pareto des défauts, couverture et tests.
Taille Lignes, langages, composants et points de fonction.
Performances Coût par méthode du dernier profil et latence du client REST.
Statistiques Probabilités, distributions et tendances.
Six Sigma DMAIC, DPMO, niveau sigma, FPY/RTY, Cpk et carte de contrôle.
Historique Séries de chaque métrique et évolutions par rapport à N−1.
Guide Tout expliqué en termes simples, avec un moteur de recherche.

Chaque section dispose d’un bouton « ? » qui l’explique sans jargon. « Aucune donnée » n’est jamais un zéro inventé : cela indique ce qui manque pour mesurer.

Boutons de la barre

  • Actualiser : mesure à nouveau.
  • Enregistrer la version : enregistre la mesure comme version actuelle. La précédente devient N−1.
  • Ouvrir le rapport : écrit docs/quality/reporte-calidad.md et l’ouvre dans l’éditeur.

Qu’est-ce que N−1

Yuli ne conserve que deux versions : l’actuelle et la précédente. Avec Git, chaque nouveau commit avec un arbre propre constitue une version. Une nouvelle version est aussi créée lorsque vous cliquez sur Enregistrer la version et lorsque l’agent effectue une mesure.

Chaque métrique est affichée avec ▲ (amélioration), ▼ (dégradation) ou = (inchangée). Une seule métrique moins bonne suffit pour le verdict « Dégradé ».

La note

La note globale va de A à E et combine dix attributs de l’ISO/IEC 25010 : fonctionnalité, efficacité, fiabilité, robustesse, sécurité, maintenabilité, compréhensibilité, utilisabilité, portabilité et compatibilité.

Note Score Interprétation
A ≥ 80 Excellente
B ≥ 65 Bonne
C ≥ 50 Acceptable
D ≥ 35 Insuffisante
E < 35 Critique

Une vulnérabilité critique plafonne la sécurité à 59 (D) et une vulnérabilité élevée à 79 (B). Un problème sérieux n’apparaît jamais en vert.

Les 14 pratiques de clean code

Chaque pratique est un nombre assorti de son objectif, mesuré dans n’importe quel langage.

Pratique Comment elle se mesure Objectif
Descriptif Noms descriptifs et nombres magiques par KLOC ≥ 95 %
Fonctions courtes Méthodes de 60 lignes ou moins ≥ 95 %
Éviter la duplication Lignes dans des blocs répétés de 6 lignes ou plus ≤ 3 %
Code lisible Méthodes avec une complexité cognitive ≤ 15 ≥ 95 %
Gestion des erreurs Constats de robustesse par KLOC 0
Structures simples Cyclomatique ≤ 10 et imbrication ≤ 4 ≥ 95 %
Style cohérent Indentation, longueur de ligne et convention de nommage ≥ 90
Noms significatifs Variables qui ne sont pas du bruit (tmp, aux, data2) ≥ 98 %
Peu de paramètres Méthodes avec 5 paramètres ou moins 100 %
Composition plutôt qu’héritage Profondeur d’héritage ≤ 3 100 %
Classes courtes ≤ 300 lignes et ≤ 20 méthodes 100 %
Pas de code mort Code commenté, inaccessible ou inutilisé 0
Écrire des tests Fichiers contenant de la logique et dotés de leur propre test 100 %
Refactoriser en continu Régressions par rapport à N−1 0

La note de clean code est la moyenne des pratiques disposant de données. À partir de 80, l’objectif est atteint.

Six Sigma et densité de défauts

Métrique Définition
Densité de défauts Défauts pour mille lignes (KLOC), avec son intervalle de confiance à 95 %.
DPMO Défauts par million d’opportunités (chaque ligne est une opportunité).
Niveau sigma (σ) Le DPMO sur l’échelle classique : 6σ = 3,4 DPMO ; 4σ ≈ 6 210. Vert à partir de 4,5σ.
Cpk Capacité à maintenir la cyclomatique ≤ 10 : ≥ 1,33 signifie capable.
FPY / RTY Builds, tests et vérifications qui réussissent du premier coup.

Un constat de sévérité moyenne ou supérieure compte comme un défaut.

La phase de Mesure de l’agent

C’est la cinquième des 8 phases, entre Implémentation et Tests. Elle mesure uniquement le code touché par la tâche par rapport à la version de départ.

Les trois moments

Phase Quand Ce qu’elle fait
baseline Avant de modifier le code Enregistre la version de départ (N−1) de la tâche.
measure Après l’implémentation Compare le code touché à N−1 et rend un verdict.
after Lorsque les tests sont au vert Compare à N−1 et réécrit le rapport.

Quand elle est validée

Tous ces contrôles doivent être satisfaits :

  1. Rien n'a empiré par rapport à N−1.
  2. Au moins un défaut corrigé (ou aucun). Une densité inchangée ne suffit pas.
  3. Le clean code s'est amélioré dans les fichiers qui étaient en dessous du niveau d’acceptation.
  4. Code neuf propre dès le départ.
  5. La logique est testée.

Un fichier est accepté s’il compte 0 défaut et un clean code de 90 ou plus. Pour un fichier accepté, on exige seulement qu’il ne se dégrade pas.

Les verdicts

Verdict Ce qui se passe
Validé La mission passe automatiquement aux Tests.
Itérer Retour à l’Implémentation avec la liste exacte des corrections à apporter, avec fichier et ligne.
Limite de tours Les tours sont épuisés : la mission passe aux Tests et ce qui reste à faire est consigné dans la mission.
Aucun code à mesurer La tâche n’a pas touché de code.

La mesure ne peut pas être ignorée. Si l’agent tente de passer aux Tests, à la Revue ou à la Livraison avec du code non mesuré, Yuli refuse. Cela vaut aussi pour Claude Code, Kiro, Codex et Antigravity.

S’améliorer ne change jamais ce que fait le logiciel : mêmes cas d’utilisation, mêmes entrées et sorties.

Où voir le résultat

Jamais dans le chat. L’agent donne une seule ligne avec le verdict et l’avant → après. Le détail se trouve dans l’onglet Mesure et dans la barre de la mission, avec le bouton Voir dans Qualité.

Paramètres

Dans l’onglet Mesure ou dans .ai/quality.json :

Paramètre Par défaut Plage
La mesure est obligatoire avant les tests Oui —
Nombre maximal de tours implémentation ↔ mesure 3 1 à 10
Niveau d’acceptation (code propre) 90 50 à 100

S’il existe un contrat de qualité, ses valeurs d’acceptation et de tours sont prioritaires.

Dans l’éditeur

  • Au-dessus de chaque méthode : CC · CoG · MI · líneas · cobertura · costo.
  • Sur la première ligne : la note du fichier, son clean code et son évolution par rapport à N−1.
  • Indices : noms sans signification, nombres magiques ou code mort, sur la ligne exacte.

Le rapport

Un document unique, docs/quality/reporte-calidad.md, réécrit à chaque version enregistrée. Il comprend la section « Mesure de l'agent ». Les données de travail se trouvent dans .ai/state/quality/ et ne sont jamais envoyées au dépôt.

Limites, en toute transparence

  • La complexité et les règles préventives sont calculées à l’aide de motifs sur le texte. Elles peuvent produire des faux positifs. Java et JSP utilisent en plus des arbres syntaxiques.
  • Les estimations (Time-to-Market, coûts) reposent sur des modèles reconnus avec des hypothèses modifiables. Elles servent à décider, pas de budget contractuel.