#0. Résumé en dix lignes
| Élément | Contenu |
|---|---|
| Persona | QA / Test Lead / SDET — persona n° 3 du brief commun (§9) |
| Douleur dominante | Couverture de test non reliée aux exigences |
| Ce que KySpectra apporte | Une couverture exprimée par critère d'acceptation, des données de test synthétiques conformes, des tests navigateur réels, des portes de qualité opposables |
| Surfaces concernées | Portail client — vue test de l'espace de travail, vues review, graph, agentops, delivery |
| Services réels sollicités | test-quality-service (4109), test-data-factory-service (4110), deploy-service (4121), spec-service (4107), observability-board-service (4114), ml-service (4126), reverse-engineering-service (4120) |
| Offre recommandée | Palier Équipe [Hypothèse], montée vers Entreprise si secteur réglementé |
| Ce qu'on ne promet pas | Une génération de tests qui remplace le jugement de test ; une automatisation robotique de bureau active par défaut |
| Statut de la chaîne | Maillon « Vérifier » Livré ; regroupement d'échecs par apprentissage En cours ; automatisation robotique navigateur désactivée par défaut |
| Preuve la plus parlante | Test navigateur exécuté sur un Chromium réel, et analyse d'une base PostgreSQL en exploitation — prouvés en ligne |
| Risque d'adoption | La personne attend un outil de gestion de campagnes de test autonome ; KySpectra relie le test à l'exigence, il ne remplace pas la stratégie de test |
#1. Portrait
Sacha, 41 ans, responsable qualité logicielle. Iel dirige une cellule de cinq personnes — trois testeurs, deux ingénieurs de test en développement — dans une entreprise de 200 salariés qui édite un logiciel de gestion pour un secteur réglementé. Iel est là depuis six ans. Avant, iel a passé dix ans dans une société de services, à faire de la recette manuelle pour des clients bancaires.
Iel a vu passer trois générations d'outillage : les scripts d'enregistrement-restitution, les cadres de test d'interface, puis les tests de composants et les tests de contrat. Iel en a tiré une conviction qui n'est pas populaire : un taux de couverture élevé n'est pas une preuve de qualité, c'est une preuve d'exécution.
#1.1 Sa réalité
Iel a un budget de temps contraint : deux jours de recette avant chaque version, quinze versions par an. Iel a une suite automatisée qui prend 47 minutes, dont 11 % d'échecs instables qu'iel doit trier à la main. Iel a un jeu de données de test qui est une copie anonymisée — mal anonymisée — de la production, et iel sait que c'est un problème dont personne ne veut parler.
Iel est celui à qui on demande, la veille d'une mise en production : « Est-ce qu'on peut y aller ? » Et iel n'a, la plupart du temps, que son intuition et un tableau de bord de couverture pour répondre.
#1.2 Sa boîte à outils actuelle
| Catégorie | Ce qu'iel utilise aujourd'hui |
|---|---|
| Automatisation d'interface | Un cadre de test navigateur moderne, exécuté en intégration continue |
| Tests de composants et unitaires | Ce que les développeurs écrivent, sur lequel iel a peu de prise |
| Gestion de campagnes | Un outil de gestion de cas de test, relié partiellement aux tickets |
| Données de test | Une extraction anonymisée de production, rafraîchie manuellement |
| Environnements | Un environnement de qualification partagé, souvent occupé |
| Rapports | Une feuille de calcul, reconstruite avant chaque comité de mise en production |
| Suivi des défauts | L'outil de tickets de l'entreprise, avec un champ « sévérité » que personne n'utilise de la même façon |
#1.3 Ce qui le fait juger
- Le nombre de défauts qui atteignent la production après une version qu'iel a validée.
- Le temps de recette : est-ce qu'iel est le goulot d'étranglement de la livraison ?
- La stabilité de la suite automatisée — un test instable coûte plus qu'un test manquant.
- La capacité à répondre à un auditeur : « Quelles exigences réglementaires sont testées, et par quoi ? »
#1.4 Ce qui l'empêche de dormir
- Le jeu de données de test. Il contient des renseignements personnels réels. Iel le sait. Le rapport d'audit de l'an prochain le saura aussi.
- Les 11 % d'échecs instables. Un jour, un vrai défaut se cachera derrière l'un d'eux, et personne ne le verra.
- La question de l'auditeur. « Montrez-moi la preuve que l'exigence de conservation des données est testée. »
- Le code produit par des agents IA. Il arrive vite, en volume, et personne ne sait ce qu'il faudrait tester en priorité.
- La version de vendredi. Iel dira oui, parce qu'iel dit toujours oui, et iel dormira mal.
Sa phrase à lui, telle qu'iel la dirait : « On me demande si on peut livrer. Je voudrais pouvoir répondre par une liste d'exigences couvertes, pas par un pourcentage de lignes. »
#2. Douleurs — mécanisme de coût et fréquence
| # | Douleur | Mécanisme de coût | Fréquence |
|---|---|---|---|
| D1 | Couverture non reliée aux exigences. Le tableau de bord affiche un pourcentage de lignes ; personne ne sait quelles exigences sont réellement vérifiées. | Risque encouru : livrer une exigence réglementaire non testée. Décision retardée : la validation de version se prend à l'intuition. | À chaque version — 15 fois par an |
| D2 | Données de test issues de la production. Anonymisation partielle, rafraîchissement manuel. | Risque encouru : exposition de renseignements personnels, constat d'audit, sanction. Temps perdu : une demi-journée par rafraîchissement. | Mensuel, avec exposition permanente |
| D3 | Échecs instables non triés. 11 % des exécutions échouent sans cause réelle. | Temps perdu : 3 à 5 heures par semaine de tri manuel. Risque : un vrai défaut masqué par le bruit. | Hebdomadaire |
| D4 | Recette manuelle avant chaque version. Deux jours mobilisés, un scénario papier. | Temps perdu : 2 jours × 5 personnes × 15 versions. Décision retardée : la livraison attend la recette. | 15 fois par an |
| D5 | Environnement de qualification indisponible. Partagé, occupé, dérivé de la production. | Décision retardée : campagne repoussée d'un à trois jours. Risque : test sur un environnement non représentatif. | 2 à 4 fois par mois |
| D6 | Contrats d'API non vérifiés entre couches. L'interface et le service divergent sans que personne ne le voie avant l'intégration. | Risque encouru : régression détectée en fin de chaîne, corrigée dans l'urgence. | 1 à 2 fois par mois |
| D7 | Aucune trace opposable de qui a validé quoi. La validation est un message de messagerie. | Risque : contestation en cas d'incident. Temps perdu : reconstitution avant audit. | 2 à 4 fois par an, avec pic avant certification |
| D8 | Changements de périmètre découverts tard. Le test est conçu sur une exigence qui a changé entre-temps. | Temps perdu : cas de test réécrits. Risque : trou de couverture invisible. | 2 à 3 fois par mois |
| D9 | Rapport de test produit à la main. Feuille de calcul reconstruite avant chaque comité. | Temps perdu : 3 à 4 heures par version. | 15 fois par an |
| D10 | Tests navigateur fragiles ou absents. Les parcours critiques ne sont pas couverts de bout en bout. | Risque encouru : défaut d'interface en production. Temps perdu : maintenance des sélecteurs. | Continue |
| D11 | Dette de test invisible. Personne ne sait quelles zones du produit sont sous-testées. | Décision retardée : la priorisation de l'effort de test se fait au ressenti. | Trimestrielle |
| D12 | Volume de code généré par IA sans stratégie de test associée. Le code arrive, la question « quoi tester » n'a pas de réponse structurée. | Risque encouru : faux sentiment de sécurité. Temps perdu : revue exploratoire non ciblée. | Continue depuis dix-huit mois |
| D13 | Base de données mal connue. Index manquants, contraintes absentes, découverts en incident de performance. | Risque encouru : dégradation en production. | 1 à 2 fois par trimestre |
#3. Réponse produit — uniquement des fonctionnalités réelles
| Douleur | Fonctionnalité KySpectra qui y répond | Où c'est dans le produit | Statut | Ce que ça change concrètement |
|---|---|---|---|---|
| D1 Couverture non reliée | Couverture des critères d'acceptation rattachée aux objets de spécification | Portail : vue test de l'espace de travail (capacité test:read, projets de type test_only) ; test-quality-service (4109) — /api/v1/test-quality/test-plans, /test-cases, /test-suites, /test-cycles, /runs |
🟢 Livré | La réponse à « peut-on livrer ? » devient une liste d'exigences couvertes, pas un pourcentage. |
| D1 Couverture non reliée | Traçabilité bidirectionnelle : un défaut remonte vers l'exigence qui l'a produit | spec-service (4107) — GET /api/v1/spec-items/{id}/traceability ; portail : vue graph, /projects/{id}/trace |
🟢 Livré | Le rapport de défauts devient exploitable par le responsable de produit. |
| D1 Couverture non reliée | Spécifications de test et dossiers de cas structurés | test-quality-service — /test-specs, /case-folders, /shared-steps, /scenarios |
🟢 Livré | Les pas partagés cessent d'être copiés-collés entre cas. |
| D2 Données de production | Données de test synthétiques conformes | test-data-factory-service (4110) — /api/v1/test-data-factory/test-datasets |
🟢 Livré | Le jeu de test cesse d'être une copie de production. C'est le point le plus défendable devant un auditeur Loi 25. |
| D2 Données de production | Nettoyage des preuves avant conservation | Drapeau EVIDENCE_SCRUB_ENABLED, valeur True |
🟢 Livré | Les captures et journaux conservés ne réintroduisent pas de renseignements personnels. |
| D3 Échecs instables | Triage d'échecs et regroupement | test-quality-service — /failure-triage, /clusters ; ml-service (4126) — /api/v1/ml pour le triage d'échecs |
🟢 Livré pour la surface de triage · 🟡 En cours pour le regroupement par apprentissage — drapeau TRIAGE_CLUSTERING_ENABLED à False par défaut |
Le tri manuel devient un tri assisté. Dire franchement que le regroupement automatique n'est pas actif par défaut. |
| D4 Recette manuelle | Sessions et cycles de test structurés, exécutions tracées | test-quality-service — /test-sessions, /test-cycles, /runs |
🟢 Livré | La recette laisse une trace exploitable au lieu d'un scénario papier. |
| D4 Recette manuelle | Exécution de recette utilisateur et test navigateur réel | deploy-service (4121) — POST /api/v1/deploy/uat/run, POST /api/v1/deploy/uat/browser |
🟢 Livré — test navigateur prouvé sur un Chromium réel en développement | Les parcours critiques s'exécutent réellement, pas en simulation. |
| D5 Environnement indisponible | Analyse dynamique en environnement éphémère, avec démantèlement garanti | reverse-engineering-service (4120) — POST /api/v1/reverse-engineering/jobs/{id}/dynamic (réponse 202), contrats observés via /dynamic/{run_id}/contracts |
🟢 Livré | L'environnement de test naît et meurt avec la campagne. |
| D5 Environnement indisponible | Exécution de code en tâches Kubernetes éphémères | agent-runtime-service (4119) — exécuteur en tâche éphémère |
🟢 Livré | L'isolation d'exécution est native, pas bricolée. |
| D6 Contrats non vérifiés | Tests de contrat, assertions inter-couches et fuzzing de contrat | test-quality-service — /contracts, /cross-layer ; drapeaux CONTRACT_FUZZ_ENABLED et CROSS_LAYER_ASSERT_ENABLED, tous deux à True |
🟢 Livré | La divergence interface / service se voit avant l'intégration. |
| D6 Contrats non vérifiés | Réconciliation statique / dynamique : verdicts confirmé, contredit, nouveau | reverse-engineering-service — GET …/jobs/{id}/reconciliation |
🟢 Livré | Ce que le code dit et ce que le système fait sont confrontés. |
| D7 Aucune trace de validation | Journal d'audit à chaîne de hachage, vérification de chaîne, rapport Loi 25 sur période | audit-compliance-service (4113) — GET /api/v1/audit-compliance/audit/events, GET …/audit/verify-chain, POST …/compliance/reports ; plan de contrôle : page /audit |
🟢 Livré | La validation devient un événement journalisé et vérifiable. |
| D7 Aucune trace de validation | Séparation des devoirs sur les décisions de revue | collaboration-service (4128) — rejet de submitted_by == reviewer_id, blocage du bouton côté interface |
🟢 Livré | Personne ne valide sa propre soumission — y compris sur une porte de qualité. |
| D8 Périmètre qui bouge | Analyse d'écart et analyse d'impact | spec-service — POST /api/v1/projects/{id}/spec/analyze, POST /api/v1/spec-items/{id}/impact |
🟢 Livré | Un changement d'exigence signale immédiatement les cas de test à revoir. |
| D8 Périmètre qui bouge | Baselines de spécification | spec-service — GET /api/v1/projects/{id}/baselines |
🟢 Livré | On teste contre un état de référence figé, pas contre une cible mouvante. |
| D9 Rapport à la main | Tableau de bord de qualité et brèches de porte | observability-board-service (4114) — GET /api/v1/observability/board?scopeKind=tenant, /metrics/catalog, /gates/breaches ; plan de contrôle : page /overview |
🟢 Livré | Le rapport de comité est une lecture, pas une reconstruction. |
| D10 Tests navigateur fragiles | Comparaison visuelle | Drapeau VISUAL_COMPARE_ENABLED, valeur True |
🟢 Livré | La régression visuelle est détectée sans écrire d'assertion pixel à la main. |
| D10 Tests navigateur fragiles | Découverte de parcours par exploration réelle, bornée par le périmètre déclaré | reverse-engineering-service — POST /api/v1/reverse-engineering/target-envs/{id}/discoveries ; 501 discovery/browser-unavailable si aucun plan navigateur n'est disponible |
🟢 Livré — avec un refus explicite plutôt qu'un faux succès | La carte des parcours vient du produit réel, pas d'une supposition. |
| D10 Tests navigateur fragiles | Automatisation robotique de navigateur | Drapeau RPA_BROWSER_ENABLED |
⚪ Désactivé par défaut (False) — à activer explicitement, ne pas présenter comme actif |
Capacité existante, posture par défaut restrictive assumée. |
| D11 Dette de test invisible | Fragmentation et cibles de test | test-quality-service — /shards, /test-targets, /e2e-flows |
🟢 Livré | La répartition de l'effort de test devient une donnée. |
| D12 Code IA non testé | Runs d'agents observables et interruption | Portail : vue agentops, page /agents ; agent-runtime-service — GET /api/v1/agent-runtime/runs, POST …/runs/{id}/interrupt |
🟢 Livré | On voit ce que l'agent produit pendant qu'il le produit. |
| D12 Code IA non testé | Refus par défaut de toute action d'agent non explicitement autorisée | agent-runtime-service — moteur de politique en liste d'autorisations, journalisation sous policy_id="deny-by-default" dans app_policy_check |
🟢 Livré | Le périmètre d'action de l'agent est testable et opposable. |
| D13 Base mal connue | Analyse réelle d'une base PostgreSQL et conseil de conception | deploy-service — POST /api/v1/deploy/db/analyze, POST /api/v1/deploy/db/advise |
🟢 Livré — prouvé en développement et en production | Les index manquants se découvrent avant l'incident. |
| Attente non couverte | Génération autonome d'une stratégie de test complète | — | ⚪ Planifié | Le produit génère des tests et relie la couverture ; il ne définit pas votre stratégie de test à votre place. |
| Attente non couverte | Adaptateurs vers tout outil de gestion de campagnes du marché | test-quality-service — /tool-adapters existe, le catalogue d'adaptateurs disponibles est limité |
🟡 En cours | Vérifier au cas par cas ; ne rien promettre sur un outil non vérifié. |
| Attente non couverte | Application mobile de suivi de campagne | — | ⚪ Planifié — aucun code mobile dans le dépôt | Portails responsives via navigateur seulement. |
#4. Semaine type — avant / après
Méthode. Heures marquées [Hypothèse], aucune mesure client n'existe à ce jour.
#4.1 Avant KySpectra
| Jour | Activité dominante | Temps typique | Frottement |
|---|---|---|---|
| Lundi | Tri des échecs de la suite de nuit | 1 h 30 | 11 % d'échecs instables, tri entièrement manuel |
| Mardi | Écriture et maintenance de cas de test | 3 h | Cas non reliés aux exigences ; pas de pas partagés |
| Mercredi | Rafraîchissement du jeu de données de test | 2 h 30 | Extraction de production, anonymisation partielle |
| Jeudi | Recette manuelle de la version | 6 h | Scénario papier, environnement partagé, occupé une partie du temps |
| Vendredi | Rapport de version, comité de mise en production | 3 h 30 | Feuille de calcul reconstruite, réponse à l'intuition |
#4.2 Après KySpectra
| Jour | Ce qui change | Heures déplacées [Hypothèse] |
Comment le mesurer |
|---|---|---|---|
| Lundi | Le triage d'échecs s'appuie sur /failure-triage ; les regroupements sont proposés quand le drapeau est activé |
−45 min | Nombre d'échecs traités par la surface de triage ; part d'échecs classés instables |
| Mardi | Les cas se rattachent à des objets de spécification ; les pas partagés sont réutilisés | −45 min, couverture mieux ciblée | Nombre de cas reliés à une exigence ; nombre de pas partagés réutilisés |
| Mercredi | Le jeu de test est généré synthétiquement par test-data-factory-service |
−2 h, et un risque de conformité retiré | Nombre de jeux générés ; disparition des extractions de production |
| Jeudi | La recette s'appuie sur des sessions tracées et un test navigateur réel via POST /api/v1/deploy/uat/browser |
−2 h 30 | Nombre de sessions de test ; nombre d'exécutions navigateur réussies |
| Vendredi | Le rapport est une lecture du tableau de bord et des brèches de porte | −2 h | Nombre de rapports générés ; nombre de brèches de porte examinées |
#4.3 Bilan hebdomadaire
| Poste | Avant | Après [Hypothèse] |
Écart [Hypothèse] |
|---|---|---|---|
| Tri d'échecs | 1 h 30 | 0 h 45 | −0 h 45 |
| Écriture et maintenance de cas | 3 h | 2 h 15 | −0 h 45 |
| Données de test | 2 h 30 | 0 h 30 | −2 h |
| Recette | 6 h | 3 h 30 | −2 h 30 |
| Rapport et comité | 3 h 30 | 1 h 30 | −2 h |
| Total déplacé | — | — | ≈ 8 h par semaine pour la cellule [Hypothèse] |
Le gain qui ne se mesure pas en heures. Retirer les renseignements personnels réels du jeu de données de test n'est pas un gain de temps : c'est la suppression d'un risque de conformité permanent.
[Gabarit : constat d'audit ou d'analyse d'impact relative à la vie privée portant sur les données de test, à obtenir du client]
#5. Valeur créée
#5.1 Valeur qualitative
| Dimension | Ce qui change pour Sacha |
|---|---|
| Défendabilité | La réponse à « peut-on livrer ? » devient une liste d'exigences couvertes et de portes franchies |
| Conformité | Les données de test cessent d'être une copie de production ; les preuves conservées sont nettoyées |
| Concentration | Le tri d'échecs devient assisté ; l'attention se porte sur les vrais défauts |
| Ancrage | Un défaut remonte vers l'exigence qui l'a produit, donc vers une décision et un responsable |
| Réalisme | Les tests navigateur s'exécutent sur un vrai navigateur ; l'analyse de base porte sur une base réelle |
| Rapport aux agents | Ce que produit un agent est observable, interruptible et borné par une liste d'autorisations |
#5.2 Valeur quantitative — formules visibles
#Formule 1 — Temps de recette récupéré
GAIN_RECETTE = N_versions × T_equipe × (H_avant − H_apres)
| Variable | Signification | Valeur de travail |
|---|---|---|
N_versions |
Versions par an | 15 [Hypothèse] |
T_equipe |
Personnes mobilisées en recette | 5 [Hypothèse] |
H_avant |
Heures de recette par personne et par version | 6 h [Hypothèse] |
H_apres |
Heures après sessions tracées et exécution navigateur réelle | 3,5 h [Hypothèse] |
Application : 15 × 5 × (6 − 3,5) = 187,5 heures-personnes par an [Hypothèse].
#Formule 2 — Temps de tri d'échecs récupéré
GAIN_TRIAGE = H_triage × R × S
| Variable | Signification | Valeur de travail |
|---|---|---|
H_triage |
Heures hebdomadaires de tri manuel | 1,5 h [Hypothèse] |
R |
Part récupérée par la surface de triage | 0,5 [Hypothèse] |
S |
Semaines travaillées par an | 44 [Hypothèse] |
Application : 1,5 × 0,5 × 44 = 33 heures-personnes par an [Hypothèse].
#Formule 3 — Coût de préparation des données de test
GAIN_DONNEES = N_rafraichissements × (H_avant − H_apres)
| Variable | Signification | Valeur de travail |
|---|---|---|
N_rafraichissements |
Rafraîchissements de jeu de test par an | 12 [Hypothèse] |
H_avant |
Heures d'extraction et d'anonymisation | 2,5 h [Hypothèse] |
H_apres |
Heures avec génération synthétique | 0,5 h [Hypothèse] |
Application : 12 × (2,5 − 0,5) = 24 heures-personnes par an [Hypothèse].
#Formule 4 — Risque de conformité retiré
VALEUR_CONFORMITE = P_constat × C_constat
| Variable | Signification | Valeur de travail |
|---|---|---|
P_constat |
Probabilité annuelle d'un constat d'audit sur les données de test | [Gabarit : à estimer avec le responsable de la protection des renseignements personnels du client] |
C_constat |
Coût d'un constat — remédiation, notification, exposition | [Gabarit : à établir avec le client] |
Aucun chiffre publiable tant que ces deux variables ne sont pas fournies par le client. Nous refusons de citer des montants de sanction non sourcés.
#Formule 5 — Défauts évités en production
GAIN_DEFAUTS = D_prod × P_couverture × C_defaut
| Variable | Signification | Valeur de travail |
|---|---|---|
D_prod |
Défauts atteignant la production par an | [Gabarit : à extraire du gestionnaire d'incidents du client] |
P_couverture |
Part évitable par une couverture reliée aux exigences et des tests de contrat | 0,25 [Hypothèse] |
C_defaut |
Coût moyen d'un défaut en production | [Gabarit : à établir avec le client] |
#Formule 6 — Coût de la plateforme
COUT_ANNUEL = U × P_mensuel × 12
Avec P_mensuel = 49 $ CAD [Hypothèse] — valeur réellement présente en base pour le plan team (4 900 cents, devise CAD). Pour la cellule de 5 personnes : 5 × 49 × 12 = 2 940 $ CAD par an [Hypothèse]. La modalité « par utilisateur » reste une hypothèse à arrêter (brief §10).
#6. Canevas de création de valeur
Aucun diagramme à afficher
Diagramme 1 — flowchart
#7. Canevas de proposition de valeur
#7.1 Profil client — Sacha, responsable qualité
#Tâches à accomplir
| Type | Tâche | Intensité |
|---|---|---|
| Fonctionnelle | Décider si une version peut être mise en production | 15 fois par an |
| Fonctionnelle | Concevoir et maintenir une couverture de test représentative | Continue |
| Fonctionnelle | Fournir un jeu de données de test utilisable et conforme | Mensuelle |
| Fonctionnelle | Trier les échecs et distinguer le bruit du défaut | Hebdomadaire |
| Fonctionnelle | Prouver à un auditeur qu'une exigence réglementaire est testée | 2 à 4 fois par an |
| Sociale | Être la personne dont le « oui » a de la valeur | Continue |
| Sociale | Ne pas être le goulot d'étranglement de la livraison | Continue |
| Émotionnelle | Ne pas signer une mise en production à l'aveugle | À chaque version |
| Émotionnelle | Ne plus manipuler des renseignements personnels réels en test | Continue |
#Frustrations
| Frustration | Sévérité |
|---|---|
| Couverture exprimée en lignes, pas en exigences | Élevée |
| Données de test issues de la production | Élevée |
| Bruit des échecs instables | Élevée |
| Recette manuelle chronophage | Élevée |
| Environnement de qualification occupé | Moyenne |
| Divergences de contrat détectées tard | Moyenne |
| Rapport reconstruit avant chaque comité | Moyenne |
| Impossible de prouver qui a validé quoi | Élevée |
#Attentes et gains recherchés
| Gain attendu | Nature |
|---|---|
| Répondre à « peut-on livrer ? » par des faits | Défendabilité |
| Un jeu de test sans renseignement personnel réel | Réduction de risque |
| Moins de bruit, plus de signal | Concentration |
| Une recette plus courte et tracée | Gain de temps |
| Un rapport qui se lit au lieu de se construire | Gain de temps |
| Une preuve de test opposable devant un auditeur | Sérénité |
#7.2 Carte de valeur — KySpectra
#Produits et services proposés
| Élément | Surface réelle | Statut |
|---|---|---|
| Vue Tests de l'espace de travail | Vue test, capacité test:read |
🟢 Livré |
| Plans, cas, suites, cycles, exécutions | test-quality-service (4109) |
🟢 Livré |
| Données de test synthétiques | test-data-factory-service (4110) |
🟢 Livré |
| Test navigateur réel et recette utilisateur | deploy-service — /uat/browser, /uat/run |
🟢 Livré |
| Tests de contrat et assertions inter-couches | test-quality-service — /contracts, /cross-layer |
🟢 Livré |
| Triage d'échecs | test-quality-service — /failure-triage |
🟢 Livré |
| Regroupement d'échecs par apprentissage | ml-service, drapeau TRIAGE_CLUSTERING_ENABLED |
🟡 En cours — désactivé par défaut |
| Analyse de base de données | deploy-service — /db/analyze, /db/advise |
🟢 Livré |
| Portes de qualité et brèches | observability-board-service |
🟢 Livré |
| Journal d'audit chaîné et rapport Loi 25 | audit-compliance-service |
🟢 Livré |
| Automatisation robotique navigateur | Drapeau RPA_BROWSER_ENABLED |
⚪ Désactivé par défaut |
| Application mobile | — | ⚪ Planifié |
#Solutions aux problèmes
| Frustration visée | Mécanisme produit qui la traite |
|---|---|
| Couverture en lignes | Couverture rattachée aux critères d'acceptation, traçabilité bidirectionnelle |
| Données de production | Génération synthétique, nettoyage des preuves |
| Bruit des échecs | Surface de triage dédiée, regroupement quand activé |
| Recette longue | Sessions et cycles tracés, exécution navigateur réelle, environnements éphémères |
| Divergence de contrat | Tests de contrat, fuzzing, assertions inter-couches, réconciliation statique/dynamique |
| Rapport manuel | Tableau de bord de qualité, catalogue de métriques, brèches de porte |
| Validation non traçable | Journal à chaîne de hachage, endpoint de vérification, séparation des devoirs |
#Créateurs de gains
| Gain recherché | Créateur de gain KySpectra |
|---|---|
| Décider avec des faits | Portes de qualité opposables et couverture par exigence |
| Tester sans risque de conformité | Jeux synthétiques et preuves nettoyées |
| Voir le vrai signal | Triage, regroupement, réconciliation |
| Gagner du temps de recette | Environnements éphémères et exécution navigateur automatisée |
| Prouver après coup | Journal chaîné vérifiable + rapport Loi 25 sur période |
| Faire confiance à l'outil | 501 explicite plutôt qu'un faux succès — y compris discovery/browser-unavailable |
#7.3 Évaluation d'adéquation
| Tâche / frustration | Réponse produit | Niveau d'adéquation | Commentaire |
|---|---|---|---|
| Relier la couverture aux exigences | Vue test + traçabilité |
Fort | Cœur du maillon « Vérifier », livré |
| Éliminer les données de production en test | test-data-factory-service |
Fort | Livré ; argument central en secteur réglementé |
| Réduire le bruit des échecs | Triage livré, regroupement en cours | Moyen | Dire clairement que le regroupement est désactivé par défaut |
| Raccourcir la recette | Sessions + navigateur réel + environnements éphémères | Fort | Livré ; navigateur prouvé en développement |
| Vérifier les contrats entre couches | Contrats, fuzzing, assertions inter-couches | Fort | Livré, drapeaux actifs par défaut |
| Produire un rapport de comité | Tableau de bord + brèches de porte + rapport Loi 25 | Fort | Livré |
| Remplacer l'outil de gestion de campagnes du marché | /tool-adapters |
Moyen | Catalogue d'adaptateurs limité — vérifier au cas par cas |
| Automatiser un poste de travail bureautique | Drapeau RPA_BROWSER_ENABLED |
Faible | Désactivé par défaut, ne pas le vendre |
| Suivre une campagne depuis un téléphone | — | Faible | Portails responsives, aucune application mobile |
Aucun diagramme à afficher
Diagramme 2 — flowchart
#8. Objections et réponses honnêtes
| # | Objection | Réponse |
|---|---|---|
| O1 | « J'ai déjà un outil de gestion de campagnes de test. » | Nous ne cherchons pas à le remplacer. Ce que nous apportons et qu'il n'a probablement pas : le lien vérifiable entre un cas de test et l'objet d'exigence versionné qu'il vérifie, et le chemin retour du défaut vers cette exigence. Si votre outil fait déjà cela avec votre source d'exigences, notre valeur est faible. Dites-le-nous, nous ne perdrons pas votre temps. |
| O2 | « Des données de test synthétiques, ça ne représente jamais la production. » | C'est une objection sérieuse et partiellement fondée. La génération synthétique ne reproduira pas toutes les singularités de vos données réelles. En contrepartie, elle retire un risque de conformité permanent. Notre position : synthétique par défaut, et vous documentez explicitement les rares cas où vous avez besoin d'autre chose. |
| O3 | « Le regroupement automatique d'échecs, ça marche vraiment ? » | Le drapeau TRIAGE_CLUSTERING_ENABLED vaut False par défaut. La surface de triage est livrée ; le regroupement par apprentissage est En cours. Nous ne vous vendons pas une capacité désactivée. |
| O4 | « Vos gains de temps de recette, vous les avez mesurés où ? » | Nulle part. Toutes les heures de la section 4 portent l'étiquette [Hypothèse]. Aucun pilote n'a mesuré ces gains ; la Phase 1 commence le 2026-09-07. Les seuls chiffres que nous publions concernent notre propre produit : plus de 3 700 tests automatisés, ~30 services backend, 3 environnements en ligne. |
| O5 | « Vous n'avez aucune référence client. » | Aucune. [Gabarit : témoignage à collecter auprès d'un pilote de Phase 1]. Ce que nous avons : un test navigateur exécuté sur un Chromium réel et une analyse d'une base PostgreSQL en exploitation, prouvés en ligne — sur notre propre production, y compris. |
| O6 | « Vos tests navigateur vont être aussi fragiles que les miens. » | Ils s'exécutent sur un vrai navigateur, avec comparaison visuelle activée par défaut. La fragilité des sélecteurs reste un problème d'écriture de test — nous ne prétendons pas l'avoir résolu. Ce que nous changeons, c'est la découverte des parcours : elle vient d'une exploration bornée du produit réel, pas d'une supposition. |
| O7 | « Et si l'outil ne peut pas exécuter un test ? » | Il vous le dit. Une découverte sans plan navigateur disponible répond 501 discovery/browser-unavailable — un refus explicite, pas un faux succès. C'est une posture produit générale : DEPLOY_LIVE vaut false par défaut, aucun déploiement n'est simulé. |
| O8 | « L'IA va générer des tests inutiles en masse. » | La génération de tests est un moyen, pas une fin. La couverture est exprimée par critère d'acceptation : un test qui ne se rattache à aucune exigence n'améliore aucun indicateur chez nous. Et l'action de tout agent est bornée par une liste d'autorisations, avec refus par défaut journalisé. |
| O9 | « Mon environnement de qualification est spécifique, vous ne pourrez pas le reproduire. » | Nous ne le reproduisons pas. L'analyse dynamique tourne dans un environnement éphémère avec démantèlement garanti, et sert à observer des contrats, pas à remplacer votre qualification. Si votre besoin est de cloner un environnement métier complexe, ce n'est pas ce que nous faisons. |
| O10 | « Mon organisation n'est pas sur Kubernetes. » | Le maillon « Vérifier » ne dépend pas de votre plateforme cible. En revanche, le maillon « Livrer » est prouvé sur Kubernetes ; les pilotes nuage natifs sont Planifiés. Si votre valeur attendue est surtout dans la livraison hors Kubernetes, attendez. |
| O11 | « Combien de temps pour voir quelque chose ? » | Un jeu de données synthétique et un premier test navigateur peuvent tourner la première semaine. La couverture par exigence suppose d'avoir des exigences : comptez une à deux semaines de promotion depuis vos documents ou votre dépôt. [Gabarit : délai jusqu'à la première couverture par exigence, à mesurer en Phase 1] |
| O12 | « Le prix ? » | Le plan Équipe est à 49,00 $ CAD par mois — c'est la valeur réellement présente dans notre catalogue de plans, en dollars canadiens. La modalité « par utilisateur » est une hypothèse de travail non arrêtée. Nous préférons vous le dire que d'inventer une grille. |
| O13 | « Vous êtes une équipe jeune. Que se passe-t-il si vous disparaissez ? » | Question légitime. Le résultat produit est du vrai code dans un vrai dépôt, avec un pipeline commité chez vous. Vos tests continuent de tourner sans nous. Ce que vous perdez, c'est le graphe de traçabilité, le journal d'audit et les portes — c'est-à-dire précisément ce que nous apportons. |
#9. Offre recommandée
#9.1 Le plan
Palier Équipe — 49 $ CAD par utilisateur et par mois [Hypothèse] — avec bascule recommandée vers Entreprise (sur devis) si l'organisation est soumise à un régime réglementaire avec audits récurrents.
Le montant 49,00 $ CAD/mois (annuel 490,00 $ CAD) est la valeur réellement en base pour
slug = team, devise CAD. La modalité par utilisateur est une hypothèse à arrêter (brief §10).
#9.2 Pourquoi ce palier
| Raison | Détail |
|---|---|
| Volume d'appels d'outil | 5 000 par jour, contre 200 au palier Découverte : une campagne de test consomme des appels d'outil |
| Compétences et outils personnalisés | 25 compétences, 10 outils, 10 rôles — nécessaires pour brancher vos propres exécuteurs |
| Plafond d'autonomie N2 | Suffisant pour des agents de vérification supervisés |
| Bascule Entreprise | Recherche en ligne activée, plafond N3, volumes 1 000 compétences / 500 outils / 200 rôles / 1 000 000 d'appels par jour |
#9.3 Ce qui est inclus
| Inclus | Détail |
|---|---|
| Vue Tests de l'espace de travail | Couverture par critère d'acceptation |
| Gestion de test | Plans, cas, suites, cycles, sessions, exécutions, pas partagés, dossiers, fragments, cibles |
| Données de test | Génération synthétique conforme, nettoyage des preuves |
| Exécution | Recette utilisateur, test navigateur réel, comparaison visuelle |
| Contrats | Tests de contrat, fuzzing de contrat, assertions inter-couches, réconciliation statique/dynamique |
| Analyse | Analyse et conseil de base de données |
| Portes | Tableau de bord de qualité, catalogue de métriques, brèches de porte |
| Traçabilité | Défaut → exigence, analyse d'impact, baselines |
| Conformité | Journal d'audit chaîné, vérification de chaîne, rapport Loi 25 |
#9.4 Ce qui n'est pas inclus
| Exclu | Statut réel |
|---|---|
| Regroupement d'échecs par apprentissage | 🟡 En cours — drapeau à False par défaut |
| Automatisation robotique de navigateur | ⚪ Désactivée par défaut |
| Catalogue complet d'adaptateurs vers les outils du marché | 🟡 En cours — à vérifier au cas par cas |
| Recherche en ligne pour les agents | Palier Entreprise |
| Plafond d'autonomie N3 | Palier Entreprise |
| Définition de votre stratégie de test | Hors périmètre assumé |
| Application mobile | ⚪ Planifié — aucun code mobile dans le dépôt |
| Pilotes nuage natifs | ⚪ Planifié |
#9.5 Chemin de montée en gamme
Aucun diagramme à afficher
Diagramme 3 — flowchart
| Étape | Déclencheur observable | Ce qui débloque |
|---|---|---|
| Découverte → Équipe | Première campagne réelle : le plafond de 200 appels d'outil par jour est atteint | 5 000 appels/jour, 25 compétences, 10 outils, plafond N2 |
| Équipe → Entreprise | Audit réglementaire récurrent, rapports Loi 25 fréquents, besoin de recherche en ligne pour les agents | Volumes Entreprise, recherche en ligne, plafond N3 |
Essai : 14 jours sans carte, rappels à J-7, J-3 et J-1, rétrogradation vers le palier gratuit à l'expiration.
#10. Indicateurs de succès pour cette persona
#10.1 À 30 jours
| Indicateur | Cible [Hypothèse] |
Source de mesure réelle |
|---|---|---|
| Jeux de données synthétiques générés | ≥ 3 | test-data-factory-service — /api/v1/test-data-factory/test-datasets |
| Extractions de production utilisées en test | 0 | Procédure interne + absence d'extraction déclarée |
| Cas de test rattachés à un objet de spécification | ≥ 30 | test-quality-service — /test-cases |
| Premier test navigateur exécuté | 1 | POST /api/v1/deploy/uat/browser |
| Première analyse de base réalisée | 1 | POST /api/v1/deploy/db/analyze |
#10.2 À 60 jours
| Indicateur | Cible [Hypothèse] |
Source de mesure réelle |
|---|---|---|
| Exigences avec au moins un cas de test relié | ≥ 60 % | Traçabilité spec-service + test-quality-service |
| Part d'échecs classés via la surface de triage | ≥ 70 % | /api/v1/test-quality/failure-triage |
| Tests de contrat actifs sur les interfaces critiques | ≥ 5 interfaces | /api/v1/test-quality/contracts |
| Brèches de porte examinées avant chaque version | 100 % | GET /api/v1/observability/gates/breaches |
| Rapport de version produit sans feuille de calcul | 100 % | Tableau de bord observability-board-service |
#10.3 À 90 jours
| Indicateur | Cible [Hypothèse] |
Source de mesure réelle |
|---|---|---|
| Durée de recette par version | −35 % par rapport au point de départ | [Gabarit : mesure de référence à établir en semaine 1 du pilote] |
| Part d'échecs instables dans la suite | −40 % | Historique des exécutions /api/v1/test-quality/runs |
| Exigences réglementaires avec preuve de test opposable | 100 % du périmètre déclaré | Traçabilité + rapport Loi 25 |
| Défauts atteignant la production | −25 % | [Gabarit : mesure de référence à extraire du gestionnaire d'incidents] |
| Vérifications de chaîne d'audit réussies | 100 % | GET /api/v1/audit-compliance/audit/verify-chain |
#11. Accroches pour cette persona
| # | Accroche | Canal recommandé | Intention |
|---|---|---|---|
| A1 | « Un taux de couverture n'est pas une réponse. » Quelles exigences sont couvertes, et par quels cas ? La question mérite une liste, pas un pourcentage. |
Publication de fond sur un média d'ingénierie de test | Toucher D1 frontalement, ton praticien |
| A2 | « Votre jeu de données de test contient-il de vraies personnes ? » Génération synthétique conforme, preuves nettoyées avant conservation. |
Webinaire conjoint qualité et protection des renseignements personnels ; secteur réglementé | Adresser D2, le levier le plus fort en contexte Loi 25 |
| A3 | « Onze pour cent de bruit, c'est onze pour cent d'attention volée. » Une surface de triage dédiée, et un regroupement quand vous l'activez — pas un moteur magique. |
Réseau professionnel, publication courte | Adresser D3 en assumant la limite |
| A4 | « Un vrai navigateur, une vraie base de données. » Test navigateur sur Chromium réel, analyse d'une base PostgreSQL en exploitation. Prouvés en ligne. |
Démonstration vidéo de 90 secondes | Adresser D10 et D13 par la preuve |
| A5 | « Quand nous ne pouvons pas, nous répondons 501. » Une découverte sans navigateur disponible le dit explicitement. Aucun déploiement n'est simulé. |
Page produit, section « Ce que nous ne faisons pas » | Construire la confiance par la limite — différenciateur D5 du brief |
| A6 | « La vitesse de l'IA, avec la traçabilité que l'audit exige. » Le défaut remonte vers l'exigence. La validation laisse un journal vérifiable. |
Salon secteur réglementé, présentation à un comité qualité | Slogan de conformité du brief, décliné pour un public qualité |
#12. Ce que nous refusons de dire à cette persona
| Formulation interdite | Pourquoi |
|---|---|
| « Zéro défaut en production » | Promesse de résultat non mesurée |
| « Tests générés automatiquement, plus rien à écrire » | Faux ; la stratégie de test reste humaine |
| « Conformité Loi 25 automatique » | Non revendiqué (brief §7) |
| « La meilleure plateforme de test » | Superlatif creux |
| « Nos clients ont réduit leur recette de X % » | Aucun témoignage n'existe |
| « Automatisation robotique incluse et active » | Le drapeau est désactivé par défaut |
| « Regroupement d'échecs par IA disponible » | Le drapeau est à False par défaut |
| « Application mobile de suivi » | Aucun code mobile n'existe |
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.