04 — Liste de contrôle du lancement : 154 items vérifiables#

Liste opérationnelle de tout ce qui doit être fait et vérifié avant l'ouverture publique du mardi 17 novembre 2026, 09:00 (heure de l'Est).

Règle qui gouverne ce document : chaque item porte un critère de vérification observable. Un item sans critère observable n'est pas un item, c'est une intention. « Fait » ne se déclare pas sur une impression, ni sur un rapport d'agent, ni sur un code de retour : il se déclare sur un résultat constaté dans l'interface réelle, après rechargement.

Version : 1.0 — 17 août 2026 Statut : Référence active Amont : 01-pre-lancement.md · Aval : 02-jour-j.md · Autorité : ../00-brief-commun.md

Sommaire#

1. Comment lire et employer cette liste
2. Bloc DB — Défauts bloquants à corriger
3. Bloc PQ — Produit et qualité
4. Bloc CJ — Conformité et juridique
5. Bloc IS — Infrastructure et supervision
6. Bloc FC — Facturation et catalogue
7. Bloc CV — Contenus et visuels
8. Bloc PP — Presse et partenaires
9. Bloc SS — Support et service
10. Bloc MO — Mesure et outillage
11. Bloc IE — Interne et équipe
12. Synthèse, charge par rôle et calendrier des échéances
13. Dépendances critiques
14. Signature de sortie

1. Comment lire et employer cette liste#

1.1 Structure d'un item#

1.2 Les rôles#

1.3 Les cinq statuts admis#

Il n'y a pas de statut « presque fait ». Un item est fait ou il ne l'est pas. Il n'y a pas non plus de statut « non atteint » : un item non atteint est Bloqué avec une date, ou Reporté par écrit avec un motif. Une case vide n'existe pas dans ce document.

1.4 Les cinq erreurs de vérification interdites#

Ces cinq erreurs ont un coût connu. Elles sont nommées ici pour qu'un vérificateur puisse refuser un « fait » sans avoir à se justifier.

1.5 Répartition des 154 items#

2. Bloc DB — Défauts bloquants à corriger#

Ce bloc a priorité sur tous les autres. Il rassemble les huit défauts mesurés dans le produit au 17 août 2026, plus quatre items de vérification qui leur sont attachés. Chacun est déclaré aux pilotes dès le 1ᵉʳ septembre 2026 dans le pacte pilote : un utilisateur ne doit jamais découvrir seul un défaut que nous connaissions.

Un item de ce bloc ne peut porter que trois statuts au 16 novembre 2026 : Fait — vérifié, ou Reporté par écrit avec formulation publique ajustée, ou Bloqué avec une date de levée. « À faire » au 16 novembre déclenche le critère de report AR6 de 02-jour-j.md §7.2.

2.1 Principe de vérification propre à ce bloc#

2.2 Les 12 items#

2.3 Formulations publiques qui découlent de chaque report#

Si un item de ce bloc est Reporté par écrit, la formulation publique suivante s'applique et aucune autre.

3. Bloc PQ — Produit et qualité#

Ce bloc couvre les parcours que le produit doit tenir le 17 novembre. Il ne couvre pas les fonctionnalités à construire : il couvre ce qui existe et doit être prouvé.

Principe de vérification : chaque parcours est mené de bout en bout, par une personne qui n'a pas écrit le code, sur l'environnement servi, avec un rechargement complet à la fin. Le résultat attendu est la donnée persistée, pas l'écran de succès.

Ce que ce bloc ne couvre pas : les fonctionnalités non livrées, qui relèvent du bloc DB ou de la feuille de route ; l'ESG, qui n'est ni vendu ni conditionné ; les personas d'extension E01 à E08, qui n'existent pas.

4. Bloc CJ — Conformité et juridique#

Ce bloc protège deux choses : les personnes dont nous détenons les données, et la crédibilité de nos affirmations. Un manquement ici ne se rattrape pas par un correctif technique.

Principe de vérification : chaque item produit une pièce écrite, datée et conservée. Une conformité qui ne laisse pas de trace n'est pas vérifiable, donc pas conforme.

Ce que ce bloc ne couvre pas : une certification d'accessibilité — nous n'en avons aucune et nous ne l'affirmons pas ; la formulation contractuelle de résidence des données auprès de chaque sous-traitant, qui relève de la décision D01.

5. Bloc IS — Infrastructure et supervision#

Ce bloc répond à une question unique : saurons-nous que quelque chose ne va pas, avant que l'utilisateur nous le dise ?

Principe de vérification : toute sonde et toute alerte est éprouvée par une panne volontaire. Un instrument en panne ne se signale pas : il répond. Le seul moyen de savoir qu'une sonde regarde vraiment est de lui montrer un défaut et de vérifier qu'elle crie.

Ce que ce bloc ne couvre pas : l'architecture d'hébergement et sa localisation contractuelle, qui relèvent de la décision D01.

6. Bloc FC — Facturation et catalogue#

Le catalogue est l'autorité unique du prix, du droit d'accès et de la facturation. Une divergence entre ce qui est affiché et ce qui est facturé a déjà coûté de l'argent à des clients par le passé — c'est de cet incident qu'est né le catalogue unifié. Ce bloc empêche la récidive.

Principe de vérification : tout contrôle porte sur deux couches — ce que l'interface affiche et ce que la facturation applique. Un contrôle qui ne regarde qu'une couche certifiera « cohérent » une base qui ne l'est pas.

Ce que ce bloc ne couvre pas : la politique de gratuité durable du forfait Gratuit, qui relève de la décision D03, et le sort des paliers historiques, qui relève de D04.

7. Bloc CV — Contenus et visuels#

Ce bloc couvre tout ce qu'un prospect, un client ou un journaliste lira. Une seule affirmation fausse dans ce bloc annule le travail des neuf autres.

Principe de vérification : aucun contenu ne part sans une relecture par une personne autre que son auteur, portant explicitement sur les 10 affirmations interdites et les chaînes de nom de code interne.

Ce que ce bloc ne couvre pas : toute page en anglais présentant le produit comme bilingue — le produit est unilingue français ; le portail de documentation peut être bilingue, c'est un site distinct.

8. Bloc PP — Presse et partenaires#

Principe de vérification : un envoi n'est pas une preuve de réception. Chaque contact presse est confirmé par un accusé nominatif, pas par un journal d'envoi.

Ce que ce bloc ne couvre pas : tout contenu commandité ou payé — il n'entre pas dans ce plan et se signalerait comme tel s'il existait.

9. Bloc SS — Support et service#

Principe de vérification : le support se vérifie de l'extérieur. Un message envoyé depuis une adresse externe, chronométré jusqu'à la réponse humaine.

Ce que ce bloc ne couvre pas : un engagement de délai de réponse contractuel, qui n'est pas pris au lancement et ne doit donc être affirmé nulle part.

10. Bloc MO — Mesure et outillage#

Une mesure fausse coûte plus cher que pas de mesure : elle produit une décision fausse avec de la confiance.

Principe de vérification : chaque mesure est recalculée à la main sur un échantillon et comparée à la valeur du tableau de bord. Écart admis : moins de 1 %.

Ce que ce bloc ne couvre pas : toute mesure d'usage individuel employée à des fins autres que l'amélioration du produit — l'usage n'est pas revendu et ne sert à aucun ciblage externe.

11. Bloc IE — Interne et équipe#

Principe de vérification : une consigne comprise se restitue. Chaque item de formation se vérifie en demandant à la personne de redire la règle sans la lire.

Ce que ce bloc ne couvre pas : la charge de travail des semaines suivantes, traitée dans 03-calendrier-90-jours.md.

12. Synthèse, charge par rôle et calendrier des échéances#

12.1 Charge par rôle#

Lecture de la charge : le RQ, le RC et le RSC concentrent la charge de vérification, de rédaction et de service. Si un renfort est possible, il va là, et il y va avant le 1ᵉʳ octobre 2026 — pas en novembre, où une nouvelle personne coûte plus qu'elle n'apporte.

12.2 Calendrier des échéances par semaine#

Constat de charge : 51 items échoient le lundi 16 novembre 2026, dont 43 sont des vérifications finales. C'est trop pour une journée si le travail n'a pas été fait avant. Parade : les 45 items du 6 novembre sont conçus comme la vraie date de livraison ; le 16 novembre ne doit contenir que de la vérification. Toute livraison qui glisse au 16 novembre est signalée en comité de lancement le vendredi 13.

12.3 Répartition des statuts au 17 août 2026#

Ce tableau se met à jour à chaque comité de lancement hebdomadaire, le vendredi à 10:00. Une part de « Fait — vérifié » inférieure à 40 % au vendredi 30 octobre 2026 déclenche un arbitrage de périmètre par le DG.

12.4 Items dont l'échec déclenche un report du lancement#

13. Dépendances critiques#

flowchart LR
    n01["DB-11<br/>Nom de code retire"] --> n02["DB-12<br/>Balayage des surfaces"]
    n02 --> n03["CJ-11<br/>Verification exhaustive"]
    n04["DB-01<br/>Ecart de catalogue"] --> n05["FC-01<br/>Controle coherent"]
    n05 --> n06["FC-02<br/>Prix affiche = prix facture"]
    n06 --> n07["PQ-03<br/>Souscription payante"]
    n06 --> n08["CV-02<br/>Page de prix"]
    n09["DB-05<br/>Export execute"] --> n10["DB-06<br/>Perimetre etendu"]
    n10 --> n11["CJ-03<br/>Page des limites"]
    n12["DB-07<br/>Resiliation Client"] --> n13["DB-08<br/>Resiliation mobile"]
    n13 --> n11
    n14["DB-09<br/>Deux facteurs"] --> n11
    n11 --> n15["CV-18<br/>Relecture finale"]
    n08 --> n15
    n03 --> n15
    n16["MO-01<br/>Tableau de bord"] --> n17["MO-02<br/>Etoile polaire"]
    n16 --> n18["MO-12<br/>Temoin negatif"]
    n17 --> n19["IE-09<br/>Decision de pre-vol"]
    n18 --> n19
    n15 --> n19
    n07 --> n19
    n20["IS-01<br/>Capacite"] --> n21["IS-02<br/>Repetition de charge"]
    n21 --> n22["IE-02<br/>Repetition generale"]
    n23["IS-12<br/>Plan de repli eprouve"] --> n22
    n22 --> n19
    n24["PQ-26<br/>Gel de code"] --> n19
    n19 --> n25["IE-10<br/>Decision d ouverture<br/>17 novembre 08h45"]

13.1 Les cinq chaînes qui ne tolèrent aucun retard#

13.2 Règle de traitement d'un blocage#

14. Signature de sortie#

14.1 Contrôle de sortie par bloc — lundi 16 novembre 2026, 18:00#

Chaque propriétaire de bloc signe la ligne de son bloc. Une ligne non signée vaut « non passé ».

14.2 Ce que la signature engage#

14.3 Décision de pré-vol#

La décision est prononcée par le DG le lundi 16 novembre 2026 à 18:00 (heure de l'Est), écrite, horodatée et signée dans l'heure. Elle est diffusée à toute l'équipe avant 19:00, quelle qu'elle soit.

Kaxentra — dossier de lancement. Document interne, version 1.0 du 17 août 2026. Marque publique : Kaxentra. Éditeur : i2t Digital. Les éléments marqués [HYPOTHÈSE] ne sont pas publiables en l'état. Les personas d'extension communautaire (E01–E08) décrivent des fonctionnalités non livrées.