Indicateurs et étoile polaire — KySpectra

#0. Portée, autorité et méthode

#0.1 Ce que ce document décide

Ce document fixe l'étoile polaire unique de KySpectra, l'arbre d'indicateurs qui la soutient, la source de donnée réelle de chaque mesure, les seuils d'alerte, la maquette du tableau de bord, et les garde-fous éthiques qui interdisent certaines mesures et certaines optimisations.

Il est subordonné au brief commun (Strategielancement/00-brief-commun.md). En cas de contradiction, le brief gagne et ce document doit être corrigé. Il s'aligne sur la stratégie marketing (04-marketing/01-strategie-marketing.md), qui reste la référence pour les indicateurs de canal ; ce document-ci traite des indicateurs de produit et d'entreprise.

#0.2 Trois règles de mesure non négociables

#0.3 Vocabulaire

---

#1. L'étoile polaire

#1.1 Énoncé

Étoile polaire — EGP : « Exigences gouvernées mises en production ». Nombre d'exigences distinctes qui, sur une semaine glissante, franchissent la chaîne complète — spécification acceptée, artefact produit, déploiement approuvé — avec une chaîne d'audit vérifiée valide.

Une seule étoile polaire. Toutes les autres mesures de ce document sont des explications de son mouvement, jamais des remplaçantes.

#1.2 Formule

EGP(S) = card {
  e ∈ Exigences
  | statut(e, fin de S) = « accepté »
  ∧ ∃ a ∈ Artefacts, relie(a, e)
  ∧ ∃ d ∈ ExecutionsDeDeploiement, relie(d, a) ∧ statut(d) = « approuvé » ∧ approbateur(d) ≠ soumissionnaire(d)
  ∧ verification_chaine_audit(e, a, d) = valide
}

Où S est une semaine glissante de sept jours, fuseau America/Toronto, et où chaque exigence est comptée une seule fois, à sa première traversée complète.

#1.3 Source de donnée réelle

Fréquence : calcul quotidien sur fenêtre glissante de sept jours ; publication hebdomadaire le lundi 09:00 (America/Toronto). Propriétaire : Responsable produit. Suppléant : Responsable ingénierie plateforme.

#1.4 Pourquoi celle-là, et pas une autre

Sept candidates ont été examinées. Une seule survit aux quatre tests : dit-elle la valeur réellement livrée au client ?, bouge-t-elle avant le revenu ?, résiste-t-elle à la triche ?, est-elle mesurable dans notre propre plateforme sans outil tiers ?

Trois raisons de fond en faveur d'EGP :

1. Elle mesure la promesse, pas l'usage. La phrase canonique parle d'une intention transformée en logiciel gouverné. EGP compte exactement cela. Si EGP monte sans que le client en tire un bénéfice, c'est que notre promesse est fausse — et il faut réviser la promesse, pas l'indicateur.
2. Elle est chère à falsifier. Une traversée complète exige un déploiement approuvé par une personne différente du soumissionnaire, dans un locataire distinct, avec une chaîne d'audit vérifiée. Le coût de la simulation dépasse le bénéfice de la simulation.
3. Elle réconcilie les douze personas. Le développeur, l'architecte, le responsable qualité, la personne responsable de la conformité et la direction lisent tous la même valeur, chacun pour une raison différente. Un indicateur commun évite les arbitrages tirés par une seule fonction.

#1.5 Contre-indicateurs obligatoires de l'étoile polaire

EGP n'est jamais lue seule. Trois contre-indicateurs l'accompagnent sur la même ligne du tableau de bord. Une hausse d'EGP accompagnée d'une dégradation d'un contre-indicateur est traitée comme une baisse.

#1.6 Cibles d'étoile polaire

Toutes les valeurs ci-dessous sont des [Hypothèse], à arrêter par le propriétaire. Aucune n'est un engagement.

---

#2. Arbre d'indicateurs

#2.1 Vue d'ensemble

#2.2 Lecture de l'arbre

---

#3. Indicateurs détaillés par famille

Convention de lecture des tableaux : Formule est le calcul exact ; Source réelle nomme le service de la plateforme et l'endpoint qui fournit la donnée ; Fréq. est la fréquence de calcul ; Propriétaire est un rôle, jamais une personne nommée.

#3.1 Acquisition

#3.2 Activation

#3.3 Rétention

#3.4 Revenu

⚠️ Tant que le catalogue de plans n'est pas nettoyé (préalable bloquant du brief §10.1), les indicateurs REV sont calculés en interne uniquement et ne sont ni publiés ni utilisés pour arbitrer une décision produit.

REV7 est un indicateur d'honnêteté, pas un indicateur de performance. Il compte les reçus émis sans service de facturation joignable. Sa valeur attendue est faible ; sa hausse déclenche une enquête technique, jamais une pression commerciale.

#3.5 Recommandation

REC1 n'est jamais collecté par sollicitation répétée. Une seule invitation par locataire et par trimestre, refusable, sans relance automatique. Un taux de réponse faible est un résultat, pas un problème à corriger par insistance.

#3.6 Qualité produit

Deux honnêtetés à tenir dans la lecture de QUA7 et QUA8. QUA7 : l'analyse statique de la rétro-ingénierie ne couvre réellement que Python. Les autres langages sont traités par des chemins non spécialisés. Ce ratio doit donc toujours être publié ventilé par langage, jamais en valeur globale — une valeur globale laisserait croire à une couverture multilingue qui n'existe pas. QUA8 : le service d'artefacts déclare 14 types UML, mais 5 seulement disposent d'un rendu spécialisé. QUA8 vaut donc aujourd'hui 5/14. Ce chiffre est un objectif d'ingénierie interne ; il ne doit jamais servir d'argument commercial tant qu'il n'a pas progressé.

#3.7 Santé plateforme

---

#4. Seuils d'alerte

#4.1 Convention de couleur

Les couleurs sont celles du brief §4.3 : 🟢 #0e7a50 · 🟡 #9a6912 · 🔴 #c4342f.

#4.2 Table des seuils

Les valeurs numériques de seuil sont des [Hypothèse] à arrêter par le propriétaire, sauf les trois seuils marqués absolus, qui découlent d'un comportement du produit et ne se négocient pas.

#4.3 Protocole d'escalade

---

#5. Maquette du tableau de bord

#5.1 Principes de la maquette

#5.2 Disposition

┌──────────────────────────────────────────────────────────────────────────────┐
│  KySpectra — Tableau de bord de lancement        Semaine du 2026-11-10       │
│  Fuseau America/Toronto · dernière actualisation 09:00                        │
├──────────────────────────────────────────────────────────────────────────────┤
│  ETOILE POLAIRE                                                              │
│  ┌────────────────────────────┐  ┌──────────┐ ┌──────────┐ ┌──────────┐      │
│  │  EGP                       │  │ CX1      │ │ CX2      │ │ CX3      │      │
│  │  Exigences gouvernées      │  │ jetons   │ │ retours  │ │ contour- │      │
│  │  mises en production       │  │ par EGP  │ │ arrière  │ │ nements  │      │
│  │        ——  /semaine        │  │   ——     │ │   —— %   │ │    ——    │      │
│  │  cible [Hypothèse] : ——    │  │  🟢/🟡/🔴 │ │ 🟢/🟡/🔴  │ │ 🟢/🟡/🔴  │      │
│  │  spec+artifact+deploy+audit│  │ billing- │ │ deploy-  │ │ audit-   │      │
│  └────────────────────────────┘  └──────────┘ └──────────┘ └──────────┘      │
├──────────────────────────────────────────────────────────────────────────────┤
│  BANDEAU 2 — ENTONNOIR                                                       │
│  Acquisition → Activation → Rétention, en barres empilées horizontales.      │
│  ACQ1 comptes · ACQ2 locataires · ACT1 1er dépôt · ACT3 1re exigence ·        │
│  ACT7 1er déploiement · ACT9 délai jusqu'à la 1re EGP · RET4 cohortes S+1/4/12│
├──────────────────────────────────────────────────────────────────────────────┤
│  BANDEAU 3 — QUALITE          │  BANDEAU 4 — SANTE PLATEFORME                │
│  QUA1 succès d'agents         │  SAN1 disponibilité par environnement        │
│  QUA4 portes franchies        │  SAN2 latence p95                            │
│  QUA5 tests verts             │  SAN3 taux d'erreurs serveur                 │
│  QUA6 défauts reliés          │  SAN4 intégrité de chaîne d'audit (absolu)   │
│  QUA7 rétro-ingénierie        │  SAN5 accès inter-locataires (absolu)        │
│      VENTILÉE PAR LANGAGE     │  SAN10 parité FR/EN (absolu)                 │
│  QUA8 types UML rendus 5/14   │                                              │
├──────────────────────────────────────────────────────────────────────────────┤
│  BANDEAU 5 — REVENU (interne, non publié)  │ BANDEAU 6 — COMMUNAUTE          │
│  REV2 conversion d'essai                   │ REC1 recommandation nette       │
│  REV4 jetons / budget                      │ REC2 retours déposés            │
│  REV7 reçus non métrés (honnêteté)         │ REC7 boucle fermée              │
├──────────────────────────────────────────────────────────────────────────────┤
│  PIED — Journal de mesure : 3 derniers changements de définition,            │
│  avec date, auteur (rôle), motif et effet sur l'historique.                   │
└──────────────────────────────────────────────────────────────────────────────┘

#5.3 Réalisation technique

---

#6. Garde-fous éthiques

#6.1 Principe fondateur

Nous refusons de mesurer ce que nous ne voudrions pas voir optimisé. Un indicateur n'est jamais neutre : dès qu'il est affiché, une organisation s'organise pour le faire monter. Nous nous interdisons donc certaines mesures, non parce qu'elles sont difficiles, mais parce que leur optimisation produirait un comportement contraire à nos valeurs.

Ce principe découle directement de deux valeurs du brief §3.2 : honnêteté d'ingénierie et sobriété assumée.

#6.2 Ce que nous refusons de mesurer ou d'optimiser

#6.3 Interdits d'optimisation

#6.4 Journal de mesure

Toute modification de définition, de formule, de source ou de seuil est consignée. Sans ce journal, une série temporelle n'est pas interprétable.

---

#7. Conformité Loi 25 de la mesure elle-même

#7.1 Position de principe

Nous vendons de la traçabilité. Une mesure marketing ou produit qui violerait la protection des renseignements personnels détruirait notre argument principal. La mesure est soumise aux mêmes règles que le produit.

#7.2 Application article par article de notre pratique

#7.3 Ce que nous ne ferons pas, même si c'est légal ailleurs

---

#8. Gouvernance de la mesure

#8.1 Rythme de revue

#8.2 Répartition des propriétaires

#8.3 Préalables bloquants à l'instrumentation

---

#9. Gabarits ouverts à renseigner

---

KySpectra — Plateforme agentique SDD/SDLC · par Kyrieva
Documentation : kyspectradoc.kyrieva.com · Dossier de lancement : Strategielancement/
Document interne de pré-lancement — version 1.0 du 2026-08-17. Les données marquées « [Gabarit : … ] » doivent être renseignées ou revalidées avant diffusion externe.