app-scorecard

App Scorecard

Si un fichier LOCAL.md se trouve à côté de ce SKILL.md, lisez-le en premier — il contient les spécificités de cet espace de travail (chemins, outils, exemples) et remplace les valeurs par défaut génériques ci-dessous.

Une grille, chaque application, à chaque fois. Le but est la comparabilité : les mêmes dimensions, les mêmes ancres 0–5, les mêmes portes, de sorte qu’une application notée en mars puisse être notée à nouveau en juin et que l’écart ait un sens, et que deux applications puissent être comparées sans rediscuter les critères.

Construit à partir du rapport de recherche « What Makes an App Exceptional » (references/framework-source.md) et de recherches ciblées pour combler ses lacunes (references/research-notes.md). Exemple complet d’une exécution sur 23 dimensions (anonymisé) : assets/example-audit.html.

Principes (à lire une fois, ils régissent tout)

1. Les portes avant les notes. La sécurité, la confidentialité, les aspects juridiques, l’accessibilité et — pour toute application qui affirme des faits — l’exactitude du contenu sont non compensatoires. Un 5 en design ne peut pas compenser un 0 en confidentialité. Listez les portes ouvertes en premier ; ne faites jamais de moyenne.
2. La preuve prime sur l’opinion. Chaque note est accompagnée d’un niveau de preuve (E0 assertion → E4 durable) et chaque constat est étiqueté Observé / Inféré / Hypothèse / Inconnu.
3. N’inférez jamais le comportement à partir du code. La rétention, l’engagement, l’adéquation au marché, la satisfaction, le revenu sont inconnus sauf s’il existe de la télémétrie, des données de cohorte ou une enquête. Le code et les captures d’écran ne peuvent pas les prouver. Dites « inconnu », pas « probable ».
4. Le stade décide de la grille. Les applications pré-PMF sont jugées sur leur capacité à apprendre, pas sur le fait qu’elles aient des SLO. Voir references/stages.md.
5. La cadence plutôt que les références. Pas de rétention D7 universelle. Un outil hebdomadaire utilisé « quelques fois en deux semaines » est sain. Nommez d’abord la cadence naturelle.
6. Chaque dimension faible reçoit un plus petit correctif. Une fiche d’évaluation sans correctifs est une plainte. Une ligne, réversible, dimensionnée en heures ou jours.

Flux de travail

0 · Cadrage (5 minutes, ne pas sauter)

Fixez, en une ligne chacun : utilisateur cible · tâche principale · cadence naturelle · événement de première valeur · modèle économique · principales alternatives (y compris « ne rien faire »). Si le dépôt contient AGENTS.md / README.md, reprenez-les et citez-les. Sinon, inférez, énoncez l’hypothèse, continuez.

Choisissez ensuite le stade (references/stages.md) :

Stade	Signal	Grille
Pré-PMF	< ~100 utilisateurs actifs, pas de données de cohorte, ou Sean Ellis « très déçu » < 40 %	9 dimensions + portes
Croissance	Cohortes existantes, > 100 actifs, ou clients payants	23 dimensions + portes
Idée / spécification	Pas encore de code	grille de qualité d’hypothèse uniquement (stages.md §3)

1 · Rassembler les preuves (en parallèle si possible)

Toujours (code + déploiement) :

• Routes / écrans, surface API, authentification + autorisation (côté serveur ?)
• Tests : exécutez-les. Lint : exécutez-le. CI : lisez les workflows. Déploiement : lisez le script.
• Télémétrie : qu’est-ce qui est réellement envoyé ? (Une importation analytics qui cible une plateforme sur laquelle l’application n’est pas hébergée compte pour rien.)
• Stockage / BDD : qu’est-ce qui est écrit par utilisateur, y a-t-il suppression, y a-t-il sauvegarde.
• Confidentialité / conditions / routes de suppression. Limites de débit et quotas sur les API payantes.
• Recherches d’accessibilité : aria-, alt=, focus-visible, prefers-reduced-motion, labels.
• Couverture i18n : chaînes externalisées vs codées en dur, locales, règles de pluriel/date.
• États d’erreur / vide / chargement / hors ligne ; error.tsx / not-found.tsx au niveau des routes.
• Performances : données lourdes côté serveur ou client, mise en cache, p95 si journalisé.
• Pour les applications IA / de référence : logique d’attribution + citation, garde-fou d’ancrage, contrôles d’hallucination, provenance du corpus.

Lorsqu’ils sont disponibles (comportement) : formulaire bêta, analytics, tables de cohorte, tickets de support, résultats de l’enquête Sean Ellis, sessions observées. Ceux-ci font passer les dimensions d’« inconnu » à une note réelle. Sans eux, laissez inconnu.

Déployez des agents Explore en lecture seule pour la largeur (3 max simultanément) ; lisez vous-même le point d’entrée, la navigation, le flux principal, l’authentification et le stockage.

2 · Vérifier les portes

À partir de references/rubric.md §Portes. Chaque porte est ouverte / fermée / sans objet avec les preuves observées. Les portes ouvertes sont placées en haut de chaque sortie. Les plus courantes : pas de politique de confidentialité ni de voie de suppression lors de la collecte de PII ; paiements sans conditions ; authentification côté serveur manquante ; pas de prefers-reduced-motion avec des animations pour un public âgé ; contenu mal attribué ou non cité dans une application de référence.

3 · Noter chaque dimension

Pour chaque dimension de la grille choisie (references/rubric.md) :

• Note 0–5 en utilisant les ancres de la grille (pas les impressions).
• Niveau de preuve E0–E4 et étiquette Observé / Inféré / Inconnu.
• Cochez la liste de contrôle de la dimension : présent / partiel / manquant / inconnaissable.
• Constat d’une ligne ancré dans un fichier:ligne, une route, une configuration ou une citation.
• Plus petit correctif d’une ligne si note ≤ 3.

Pour la conception UI / UX, utilisez la sous-grille de conception visuelle dans rubric.md §Conception UX (typographie, hiérarchie, couleur, espacement, cohérence, copie). Si l’utilisateur souhaite approfondir, invoquez ui-usability-audit après la fiche d’évaluation et référencez ses notes alphabétiques.

4 · Juger

• Portes ouvertes (encore, en premier).
• Top 3 raisons de gagner · top 3 raisons d’échouer · top 3 inconnus.
• La prochaine expérience ou correction à plus fort effet de levier.
• Verdict : Go / Go conditionnel / Itérer / Non-Go, avec confiance. Règle empirique : une porte ouverte ⇒ au mieux Itérer ; toutes les portes fermées + événement de valeur instrumenté ⇒ Go conditionnel ; quatre semaines de données de rétention à la cadence naturelle ⇒ Go est envisageable.

5 · Livrer — la fiche d’évaluation visuelle est le livrable

Le message dans le chat est un résumé. L’artefact HTML publié de la fiche d’évaluation est la sortie. Ne terminez jamais une exécution sans lui ; si l’outil d’artefact n’est pas disponible (Codex, un sous-agent), écrivez le HTML dans docs/scorecards/<date>-scorecard.html dans le dépôt de l’application et envoyez/ouvrez le fichier à la place.

1. Construisez l’artefact à partir de assets/scorecard-template.html. Chargez d’abord le skill artifact-design, puis conservez exactement la structure du modèle, dans cet ordre, afin que la fiche d’évaluation de chaque application se lise de la même manière :
   1. En-tête — <App> Scorecard, stade + sources de preuves + date en surtitre, thèse en une phrase, pastille de verdict (classe go / ambre par défaut / nogo), confiance, et bande de cadrage (utilisateur · tâche · cadence · événement de valeur · alternatives).
   2. Grille en un coup d’œil — une tuile par dimension, bande de couleur du score (bleu-vert ≥ 3, ambre 2, rouge ≤ 1, gris inconnu), contour porte sur toute dimension avec une porte ouverte, et un ▲/▼ delta par rapport à l’exécution précédente lorsqu’elle existe.
   3. Portes — chaque porte sous forme de carte : ouverte (rouge) ou fermée (verte), avec les preuves observées et les noms de fichiers/routes en code.
   4. Cartes par dimension, regroupées (stratégie et économie · expérience et confiance · ingénierie et échelle, ou la liste du niveau A) : note, badge de preuve, constat de 2 à 4 phrases, liste de contrôle avec marques présent/partiel/manquant/inconnaissable, et la ligne du plus petit correctif pour tout ce qui est ≤ 3.
   5. Jugement final — trois colonnes (raisons de gagner · raisons d’échouer · inconnus critiques) et le panneau sombre « prochaine étape au plus fort effet de levier ».
   6. Note de méthode — ce qui a été lu, exécuté, refusé ; lien vers l’exécution précédente. Règles de conception : contenu réel uniquement, pas de lorem ; chaque couleur provient de l’ensemble de jetons pour que le mode sombre tienne ; pas d’émoji, pas de graphiques décoratifs ; chiffres en police tabulaire. Regardez la page rendue une fois, corrigez ce qu’elle montre, publiez.
2. Publiez avec Artifact. Titre <App Name> Scorecard, favicon 🔬 uniquement lors de la première publication. Lors d’une ré-exécution, passez l’url de l’artefact précédent afin que l’historique reste sur un seul lien (trouvez-le dans docs/SCORECARD.md).
3. Chat : lien d’abord, puis bloc de cadrage, portes ouvertes, tableau compact (dimension · note · preuve · constat), verdict. Concis. Ne dupliquez pas la prose de l’artefact.
4. Persistez une ligne dans le fichier docs/SCORECARD.md du dépôt (créez-le s’il est absent) : date · stade · portes ouvertes · notes par dimension · verdict · URL de l’artefact. Ne commitez que si l’utilisateur le demande.

Règles

• Lisez entièrement, puis notez. La grille raccourcit le jugement, jamais la lecture.
• Citez, ne paraphrasez pas, lorsqu’un testeur ou un fichier dit les choses.
• Refusez de noter ce qui ne peut pas être connu. « Inconnu » est une cellule valide et honnête.
• N’inventez pas de références. Les seuls seuils numériques que vous pouvez citer sont ceux dans references/research-notes.md (SUS 68/80, Ellis 40 %, CWV 2,5 s / 200 ms / 0,1, sévérité Nielsen 0–4, WCAG 2.2 AA, ASVS L1). Tout autre chose est une comparaison avec la propre exécution précédente de l’application.
• Même grille entre les applications. N’ajoutez ni ne supprimez de dimensions par application. Marquez n-a lorsqu’une dimension ne s’applique vraiment pas (par exemple, monétisation sur un outil interne) — n-a est enregistré, pas ignoré.
• Développement/recette uniquement si vous devez piloter l’application en direct. Jamais en production.
• Lecture seule. La fiche d’évaluation recommande ; elle ne modifie pas l’application.
• Pas d’artefact, pas d’exécution. Une fiche d’évaluation qui ne vit que dans le fil de discussion n’est pas comparable au prochain trimestre. Publiez toujours (ou écrivez le fichier HTML).

Se compose avec

• ui-usability-audit — approfondissement sur la dimension Conception UX, avant/après visuel.
• qa-sweep — PASS/ÉCHEC fonctionnel qui alimente la Fiabilité et l’UX de base.
• dev-to-prod-promotion-review — le verdict de la fiche d’évaluation est une entrée pour la porte de mise en production.
• panel-brainstorm — lorsque les « plus petits correctifs » ont besoin d’alternatives générées.