Business case global — KySpectra

#Avertissement de lecture — à lire avant toute autre section

Ce document est un instrument de décision, pas un argumentaire de vente. Il est écrit pour qu'un lecteur hostile puisse le vérifier ligne à ligne.

Trois conventions gouvernent tout ce qui suit :

Et trois faits qui ne changent pas selon l'humeur du lecteur :

1. Au 2026-08-17, KySpectra n'a aucun client payant, aucun revenu, aucun témoignage. Toute projection de ce document part de zéro.
2. Le produit existe et fonctionne en production. Ce n'est pas une maquette : trois environnements sont en ligne, et une chaîne continue « dépôt public → rétro-ingénierie → spécifications → construction → publication → mise en ligne » a été prouvée en navigateur réel sur l'environnement de production.
3. Aucun chiffre de marché n'est publié dans ce document. Le §8 du brief commun l'interdit tant que la source n'a pas été consultée et datée. Nous préférons un gabarit visible à une statistique inventée.

---

#Table des matières

1. Résumé exécutif
2. Le problème — mécanismes de coût, pas slogans
3. La solution et la chaîne de valeur en six maillons
4. Marché — méthode de calcul du TAM, du SAM et du SOM
5. Paysage concurrentiel par catégorie d'outil
6. Modèle d'affaires et modèle de revenus
7. Projections financières — trois scénarios vérifiables
8. Structure de coûts
9. Stratégie de mise en marché
10. Registre des risques
11. Analyse SWOT
12. Indicateurs et étoile polaire
13. Jalons datés
14. Décisions requises du propriétaire
15. Annexes

---

#1. Résumé exécutif

#1.1 En une page

Ce que nous vendons. Une plateforme agentique qui relie la spécification, les agents d'intelligence artificielle et le déploiement en une seule chaîne traçable. La formulation canonique : De l'intention au logiciel en production, gouverné.

Pourquoi maintenant. La génération de code par intelligence artificielle a déplacé le goulot d'étranglement. Écrire du code n'est plus le problème coûteux ; savoir ce qui a été écrit, pourquoi, sur la foi de quelle décision, validé par qui, et ce qui casse si on le change l'est devenu. Nous appelons cette charge la dette d'intelligibilité. Elle ne figure à aucun budget ; elle se paie en délais, en incidents et en audits impossibles.

Ce qui est réellement construit. Au 2026-08-17 : 255 commits, environ 30 services backend déployables, 9 services d'agents autonomes, plus de 3 700 tests automatisés, 3 environnements en ligne, 2 portails web livrés (client et administration), 16 destinations dans le plan de contrôle d'administration, 11 vues canoniques dans l'espace de travail projet.

Ce qui est prouvé en ligne. Import d'un dépôt public puis rétro-ingénierie vers des spécifications promues automatiquement (production) · produit tiers servi sur un sous-domaine dédié avec certificat TLS (production) · personnel virtuel d'agents, phase 1 : recrutement par l'interface, assignation de tâche, file de travail, organigramme (développement et production) · dépôt réel d'un secret dans le coffre, relu indépendamment (développement et production) · génération de pipelines d'intégration continue pour quatre fournisseurs, avec commit réel (développement) · analyse d'une base PostgreSQL en exploitation (développement et production).

Ce qui n'est pas prouvé, et que nous ne vendrons pas comme disponible. Applications mobiles (Planifié, aucun code mobile n'existe) · pilotes natifs pour les nuages publics (Planifié ; seul le mécanisme générique par ligne de commande est prouvé) · provisionnement automatique d'un fournisseur d'identité (Bloqué par des droits d'administration manquants, vérifié empiriquement par des réponses 403) · place de marché de capacités avec audience ciblée (En cours : code écrit et testé, jamais déployé).

La faiblesse commerciale centrale. Nous avons un produit et zéro preuve de marché. Aucune ligne de ce document ne compense cela. Le programme de lancement est conçu pour convertir cette asymétrie : Phase 1 (pilotes fermés, 2026-09-07 → 2026-10-04) existe précisément pour produire les premières preuves d'usage tiers.

Le préalable bloquant. Trois jeux de données de démarrage incompatibles coexistent pour le catalogue de plans, dont un porte encore un vocabulaire hérité d'un autre domaine d'activité. Tant que ce catalogue n'est pas nettoyé et unifié, aucune facturation cohérente n'est possible. C'est le risque R05 et c'est un travail de Phase 0.

#1.2 La demande de décision

#1.3 Ce que ce document démontre — et ce qu'il ne démontre pas

---

#2. Le problème — mécanismes de coût, pas slogans

#2.1 Le déplacement, énoncé sans emphase

Entre 2023 et 2026, la production de code assistée par modèle de langage est devenue courante dans les équipes logicielles. Le fait empirique à vérifier — taux d'adoption, volume de code généré, part du code produit avec assistance — relève de sources externes : [Gabarit : taux d'adoption des assistants de code chez les développeurs professionnels — source à consulter : Stack Overflow Developer Survey, JetBrains State of Developer Ecosystem, GitHub Octoverse, millésime le plus récent].

Ce que nous observons directement, sans avoir besoin d'une statistique de marché, c'est une asymétrie de vitesse : la vitesse d'écriture a augmenté, la vitesse de compréhension n'a pas bougé. La compréhension reste une opération humaine, séquentielle, coûteuse et non parallélisable.

Cette asymétrie ne coûte rien tant qu'on ajoute. Elle coûte à chaque fois qu'on revient : reprise, incident, audit, transfert de responsabilité, changement de personne.

#2.2 Six mécanismes de coût

Chaque mécanisme ci-dessous est décrit par : la chaîne causale, l'endroit du budget où il se paie, la façon de le mesurer chez soi (sans nous croire sur parole), et ce que KySpectra change, avec le statut honnête de la capacité invoquée.

---

#M1 — Re-dérivation de l'intention

Chaîne causale. Un artefact (module, requête, règle) est produit. L'intention qui l'a motivé vit dans une conversation, un fil de discussion, un ticket fermé ou la mémoire d'une personne. Six semaines plus tard, un tiers doit modifier l'artefact. Il ne dispose pas de l'intention. Il la re-dérive en lisant le code, en interrogeant des collègues, en reproduisant le comportement.

Où cela se paie. Dans le temps d'ingénierie affecté à la reprise, pas à la création. Ce temps est comptabilisé comme « développement », ce qui le rend invisible : personne n'a de ligne budgétaire « re-dérivation ».

Comment le mesurer chez soi.

1. Prendre les 20 dernières modifications non triviales du dépôt.
2. Pour chacune, chronométrer le temps écoulé entre l'ouverture de la tâche et le premier changement de code effectif.
3. Ce délai, moins le temps d'installation de l'environnement, est une approximation basse du coût de re-dérivation.

Ce que KySpectra change. L'exigence est un objet versionné, typé et relié ; les artefacts pointent vers elle et la vue de traçabilité restitue le chemin dans les deux sens. Statut : Livré (maillons 2 et 3, espace de travail projet, vues spec, graph, trace).

Gabarit de chiffrage. [Gabarit : coût horaire chargé d'un ingénieur logiciel dans le marché cible — source à consulter : Statistique Canada, TechnoCompétences, ou grille interne du client] × [Gabarit : nombre d'heures de re-dérivation mesurées par le client sur un trimestre].

---

#M2 — Écart entre le demandé et le livré

Chaîne causale. Une demande est formulée en langage naturel. Elle est traduite en tickets. Les tickets sont interprétés. Le résultat est livré. L'écart entre l'intention initiale et le livré n'est constaté qu'à la démonstration, c'est-à-dire après que le coût de fabrication a été engagé.

Où cela se paie. En reprise complète de fonctionnalité, en cycles de démonstration supplémentaires, et en érosion de la confiance entre la fonction produit et la fonction ingénierie.

Comment le mesurer chez soi.

1. Sur les 10 dernières fonctionnalités livrées, compter celles qui ont exigé une reprise après démonstration.
2. Estimer l'effort de reprise en proportion de l'effort initial.
3. Le produit des deux est le taux de gaspillage d'interprétation.

Ce que KySpectra change. La spécification n'est pas un document préparatoire : c'est la structure de données contre laquelle on vérifie. La génération assistée depuis le langage naturel produit des objets de spécification validés (validation EARS), pas des paragraphes. La vue d'analyse des écarts confronte l'attendu au réalisé. Statut : Livré (maillon 2 ; vues specify, analyze, review).

Gabarit de chiffrage. [Gabarit : effort moyen d'une fonctionnalité, en jours-personne, mesuré chez le client] × [Gabarit : taux de reprise observé] × coût journalier chargé.

---

#M3 — Vérification non reliée

Chaîne causale. Des tests existent. Ils sont verts. Personne ne peut dire quelle exigence chacun d'eux prouve. Un test vert ne fournit alors aucune information sur la conformité au besoin : il prouve seulement que le code fait ce que le test dit qu'il fait.

Où cela se paie. En incidents en production sur des chemins « couverts ». En audits où la question « prouvez-moi que l'exigence R-042 est vérifiée » n'a pas de réponse. En suites de tests qui grossissent sans réduire le risque.

Comment le mesurer chez soi.

1. Choisir 10 exigences fonctionnelles au hasard dans le cahier de charges en vigueur.
2. Pour chacune, demander à l'équipe de nommer le test qui la prouve, en moins de deux minutes.
3. Le taux d'échec de cet exercice est le taux de vérification non reliée.

Ce que KySpectra change. Génération de tests à partir des critères d'acceptation, couverture présentée par critère et non par fichier, tests navigateur réels, données de test synthétiques conformes, portes de qualité. Statut : Livré (maillon 5 ; vue test, marquée test_only dans le registre des vues).

Gabarit de chiffrage. [Gabarit : coût moyen d'un incident de production chez le client, incluant l'astreinte et la remédiation] × [Gabarit : nombre d'incidents attribuables à un défaut de couverture sur 12 mois].

---

#M4 — Preuve d'audit reconstituée a posteriori

Chaîne causale. Un auditeur, un client réglementé ou une autorité de protection des renseignements personnels demande la preuve d'une décision : qui a approuvé quoi, quand, sur la base de quel élément. La preuve n'a pas été produite au moment de la décision. Il faut la reconstituer à partir de journaux hétérogènes, de fils de discussion et de mémoires humaines.

Où cela se paie. En jours-personne d'ingénierie et de conformité mobilisés en urgence. En reports de contrats quand la preuve manque. En risque juridique quand elle est fausse.

Comment le mesurer chez soi.

1. Choisir une mise en production des trois derniers mois.
2. Demander la preuve horodatée et non répudiable : approbateur, demandeur, contenu approuvé, différence exacte déployée.
3. Chronométrer le temps de collecte, et noter si la preuve est opposable ou seulement plausible.

Ce que KySpectra change. Journal d'audit à chaîne de hachage, avec un endpoint de vérification d'intégrité. Rapport de conformité Loi 25 générable sur une période. Séparation des devoirs opposable : la machine à états de revue rejette le cas où le soumissionnaire est aussi l'approbateur, et l'interface bloque le bouton avant même l'appel serveur. Statut : Livré (plan de contrôle ; interface d'administration).

Gabarit de chiffrage. [Gabarit : coût d'un exercice d'audit chez le client, en jours-personne] × [Gabarit : fréquence annuelle des exercices]. Et, séparément, [Gabarit : montant des sanctions applicables au titre de la Loi 25 — source à consulter : Commission d'accès à l'information du Québec, texte en vigueur].

---

#M5 — Dérive architecturale

Chaîne causale. Une architecture est décidée et documentée. Le système évolue. La documentation ne suit pas. Au bout de quelques trimestres, l'architecture décrite et l'architecture réelle sont deux objets différents, et personne ne sait lequel est le plus faux. Les décisions suivantes sont prises sur la carte, pas sur le terrain.

Où cela se paie. En estimations fausses. En dépendances découvertes tardivement. En modernisations qui échouent parce qu'elles partent d'un schéma imaginaire.

Comment le mesurer chez soi.

1. Prendre le dernier schéma d'architecture officiel.
2. Le confronter aux dépendances réellement présentes dans le dépôt et aux appels réellement observés en production.
3. Compter les composants du schéma qui n'existent plus, et les composants réels absents du schéma.

Ce que KySpectra change. La rétro-ingénierie part du dépôt réel et produit sept familles d'artefacts (dont C4, modèle de données, contrats d'interface, machines à états), puis promeut automatiquement des spécifications. On repart du vrai. Statut : Livré, prouvé en production (maillon 1 ; vue artifacts).

Gabarit de chiffrage. [Gabarit : durée moyenne d'une phase de cadrage/découverte avant un chantier de modernisation, mesurée chez le client] × coût journalier chargé de l'équipe mobilisée.

---

#M6 — Plafond de délégation aux agents

Chaîne causale. Une organisation souhaite déléguer du travail à des agents automatisés. Elle ne dispose ni d'un périmètre explicite, ni d'un plafond d'autonomie, ni d'un journal opposable. Le responsable de la sécurité refuse — à raison. La délégation se limite alors à des usages sans enjeu, et le gain espéré ne se matérialise jamais.

Où cela se paie. En bénéfice non réalisé : c'est le mécanisme le plus difficile à mesurer, parce qu'il se manifeste par une absence. Il se paie aussi en dépenses d'outillage engagées puis abandonnées.

Comment le mesurer chez soi.

1. Lister les initiatives d'automatisation par agents lancées sur 18 mois.
2. Compter celles arrêtées avant la production, et noter le motif déclaré.
3. Si « gouvernance », « sécurité » ou « conformité » domine, le mécanisme M6 est actif.

Ce que KySpectra change. Registre central d'agents comme source de vérité. Capacités à trois niveaux (global, locataire, utilisateur) en refus par défaut : toute action non explicitement couverte est refusée et journalisée sous policy_id="deny-by-default". Plafond d'autonomie N0 à N3, lui-même plafonné par le plan commercial, avec dégradation vers le niveau le plus bas en cas d'incertitude. Budgets de jetons et fenêtres de quota. Statut : Livré (plan de contrôle transversal). Réserve honnête : le drapeau qui active les rôles virtuels et le plafonnement par plan est à false par défaut et n'est activé dans aucun manifeste de déploiement — c'est un travail de Phase 0, consigné au risque R05.

---

#2.3 Récapitulatif des mécanismes

#2.4 Pourquoi les remèdes existants ne referment pas la boucle

#2.5 Ce que le problème n'est pas

Poser les limites du problème évite de vendre une solution à côté.

• Ce n'est pas un problème de vitesse d'écriture. Nous ne prétendons pas écrire du code plus vite qu'un assistant d'éditeur, et nous ne le revendiquerons pas.
• Ce n'est pas un problème de méthodologie. Aucune méthode ne se maintient sans un système qui l'incarne dans des objets manipulables.
• Ce n'est pas un problème de talent. Les mécanismes M1 à M6 frappent des équipes compétentes ; ils sont structurels.
• Ce n'est pas un problème que l'on résout par un seul outil ponctuel. C'est un problème de chaîne : chaque rupture de chaîne réintroduit le coût.

---

#3. La solution et la chaîne de valeur en six maillons

#3.1 La thèse produit, en une phrase falsifiable

La spécification n'est pas de la paperasse d'avant-projet : c'est la structure de données centrale du cycle de vie.

Cette thèse est falsifiable. Elle est fausse si l'on démontre qu'une équipe peut maintenir, sur plusieurs trimestres, la traçabilité entre intention et production sans faire de l'exigence un objet de première classe. Nous n'avons pas rencontré ce contre-exemple ; nous restons ouverts à ce qu'on nous le montre.

#3.2 Vue d'ensemble de la chaîne

#3.3 Maillon par maillon

#Maillon 1 — Comprendre

Pourquoi ce maillon existe. La plupart des plateformes supposent une page blanche. Les organisations réelles n'ont pas de page blanche : elles ont un système qui tourne, dont personne ne possède la carte exacte. Commencer par comprendre est une position de marché, pas seulement une fonctionnalité.

#Maillon 2 — Spécifier

Le point non négociable. Une exigence est un objet, pas un paragraphe. Elle a une version, un type, des relations sortantes et entrantes, un état de cycle de vie. C'est ce qui rend possible tout le reste : sans objet, pas de traçabilité ; sans traçabilité, pas de preuve.

#Maillon 3 — Concevoir

#Maillon 4 — Fabriquer

#Maillon 5 — Vérifier

#Maillon 6 — Livrer

#3.4 Le plan de contrôle transversal

Le plan de contrôle n'est pas un maillon : il traverse les six.

#3.5 La chaîne de valeur économique — où la valeur se crée

Le point économique. La valeur de KySpectra ne se manifeste pas au premier passage — au premier passage, une chaîne gouvernée coûte plus cher qu'un raccourci. Elle se manifeste au retour : reprise, incident, audit, changement de personne. C'est une proposition de valeur à horizon, et cela a une conséquence commerciale directe : la démonstration doit porter sur un retour, pas sur une création. Un client à qui l'on démontre la création d'un projet neuf ne verra pas la valeur ; un client à qui l'on rétro-ingénierie son propre dépôt la verra en quinze minutes.

#3.6 Ce que la solution ne fait pas

• Elle n'écrit pas mieux la ligne suivante. Ce n'est pas un assistant de complétion et nous n'entrons pas sur ce terrain.
• Elle n'enferme pas dans un moteur propriétaire. Le résultat est du code réel, dans un dépôt réel, avec un pipeline réel.
• Elle ne remplace pas l'outil de gestion de projet. Elle déplace la source de vérité : la spécification, pas le ticket.
• Elle ne décide pas seule. L'autonomie est un plafond configuré, plafonné par le plan, dégradé vers le bas en cas de doute.
• Elle ne rend pas conforme automatiquement. Elle produit la preuve ; l'interprétation réglementaire reste humaine.

---

#4. Marché — méthode de calcul du TAM, du SAM et du SOM

#4.1 Pourquoi cette section ne contient aucun chiffre

Le §8 du brief commun est explicite : aucun chiffre de marché n'est autorisé tant qu'il n'a pas été vérifié à la source et daté. Cette section livre donc ce qui a de la valeur et que personne ne peut inventer à notre place : la méthode, les variables, et où chercher chaque variable.

Un dossier qui affirme « le marché vaut X milliards » sans méthode est invérifiable et sera démonté au premier contrôle. Un dossier qui livre la méthode se laisse contredire sur les valeurs sans perdre sa structure.

#4.2 Définitions retenues

#4.3 TAM — deux méthodes, à croiser

Nous exigeons deux calculs indépendants. S'ils divergent d'un facteur supérieur à 3, l'un des deux est faux et il faut le dire.

#4.3.1 TAM, méthode descendante (par la dépense)

Formule.

TAM_descendant = D_outillage_cycle_de_vie × P_segment_gouvernance

Précaution de méthode. Cette voie surestime systématiquement, car elle inclut des dépenses que nous ne captons pas (outils d'édition, plateformes de tickets historiques). Elle donne une borne haute.

#4.3.2 TAM, méthode ascendante (par la population)

Formule.

TAM_ascendant = N_developpeurs_professionnels × T_equipement × P_siege_annuel

Précaution de méthode. Cette voie sous-estime, car elle ignore les revenus non fondés sur le siège (plateforme, consommation, services). Elle donne une borne basse.

#4.3.3 Règle de croisement

#4.4 SAM — filtres successifs

Le SAM se construit par application de filtres explicites et discutables, dans cet ordre.

Précision de méthode sur F3. Le filtre « contrainte de traçabilité » ne doit pas être appliqué comme une exclusion sèche. Une organisation non réglementée reste un acheteur possible ; elle a simplement une propension à payer plus faible. La formulation correcte est une pondération : P_reglemente × 1,0 + (1 − P_reglemente) × k, où k est le facteur de propension du segment non contraint, [Hypothèse] k = 0,35.

#4.5 SOM — par la capacité, pas par le souhait

Le SOM ne se déduit pas d'un pourcentage arbitraire du SAM. Il se déduit de ce que notre équipe peut réellement exécuter.

Formule.

SOM_36mois = (Capacite_acquisition_annuelle × 3 ans × Taux_de_survie) × Revenu_annuel_moyen_par_compte

Contrôle de cohérence obligatoire. Si SOM_36mois / SAM > 1 % alors que nous partons de zéro client et d'une équipe de moins de dix personnes, l'hypothèse est présumée fausse et doit être révisée à la baisse.

#4.6 Segments prioritaires — critères et ordre

L'ordre ci-dessous est un jugement, pas une donnée. Les critères sont explicites pour qu'on puisse le contredire.

#4.7 Signaux de marché à surveiller

À défaut de chiffres, voici les signaux qu'il faut instrumenter dès la Phase 0 et suivre jusqu'au jour J.

---

#5. Paysage concurrentiel par catégorie d'outil

#5.1 Règles de cette section

1. Aucun dénigrement nominatif. Nous décrivons des catégories et leur logique économique. Les listes nominatives sont des gabarits à établir, à dater, et à formuler factuellement.
2. Aucune affirmation de supériorité globale. Nous affirmons une position, pas un classement.
3. Nos faiblesses sont écrites en toutes lettres. Un tableau concurrentiel où l'on gagne partout est un tableau faux.

#5.2 Grille de lecture commune

Chaque catégorie est évaluée sur le même axe : quelle portion de la chaîne intention → production elle couvre, et si elle produit une preuve opposable.

#5.3 Catégorie A — Assistants de code

#5.4 Catégorie B — Plateformes de gestion du cycle de vie applicatif (ALM)

#5.5 Catégorie C — Outils de spécification et de gestion des exigences

#5.6 Catégorie D — Plateformes internes de développement

#5.7 Catégorie E — Agents autonomes de développement

#5.8 Catégorie F — Substituts non logiciels

À ne pas oublier : le concurrent le plus fréquent n'est pas un produit.

#5.9 Notre position en une matrice

#5.10 Nos faiblesses assumées — la liste complète

Aucune de ces lignes ne doit disparaître d'une version ultérieure sans avoir été résolue, pas maquillée.

---

#6. Modèle d'affaires et modèle de revenus

#6.1 Ce qui existe réellement en base au 2026-08-17

Cette sous-section ne contient aucune hypothèse. Ce sont des faits lus dans le dépôt.

Devise unique présente dans le code : CAD. Toute mention d'euro ou de dollar américain serait aujourd'hui une invention.

Trois jeux de données de démarrage incompatibles coexistent dans le dépôt, dont un propose une grille à trois paliers sur un schéma périmé. Le nettoyage du catalogue est un préalable bloquant au lancement.

#6.2 La grille proposée — toutes les valeurs sont des hypothèses

⚠️ Rien de ce qui suit n'est une décision commerciale arrêtée.

Le fait remarquable, et vendable : le plafond d'autonomie des agents est plafonné par le plan commercial. Le mécanisme applique le minimum entre le plafond du rôle et le maximum du plan, et retombe sur N1 en cas de valeur inconnue. C'est un différenciateur rare : le contrat commercial et la politique de sécurité sont le même objet.

#6.3 Les cinq flux de revenus envisagés

Décision de méthode. Nous ne bâtissons aucune projection sur F4 et F5 dans ce document : F4 n'est pas déployé, F5 n'est pas scalable. Les projections du §7 ne reposent que sur F1 et F2, avec F3 traité comme un coût (inférence) et non comme un revenu, ce qui est la posture prudente.

#6.4 Mécanique d'entrée : l'essai

Les profils d'inscription configurés dans le produit prévoient :

Conséquence pour le modèle. Un essai sans carte maximise le volume d'entrée et minimise le taux de conversion. Les hypothèses de conversion du §7 en tiennent compte : elles sont basses par construction.

#6.5 Unités de valeur et compteurs

Une plateforme se facture bien quand l'unité facturée est celle que le client reconnaît comme la source de sa valeur.

Recommandation. Conserver le siège pour le palier Équipe, tester en Phase 1 la tarification au dépôt gouverné pour le palier Entreprise, et conserver la consommation comme plafond de sécurité et non comme facturation principale.

#6.6 Garantie d'honnêteté de facturation

Un comportement du produit mérite d'être un argument commercial explicite : sans service de facturation joignable, le reçu porte la mention metered=false — jamais un montant inventé. Le contrôle de crédit fait une pré-vérification puis un règlement avec les jetons réellement consommés. Aucune estimation n'est facturée.

C'est vérifiable, c'est rare, et c'est cohérent avec la valeur d'honnêteté d'ingénierie.

---

#7. Projections financières — trois scénarios vérifiables

#7.1 Comment lire cette section

Tout ce qui suit est une hypothèse. Il n'existe aujourd'hui aucune vente, aucun essai converti, aucune donnée d'attrition. Les tableaux ne sont donc pas des prévisions : ce sont des modèles arithmétiquement cohérents sous des hypothèses explicites, destinés à être falsifiés par les données de la Phase 1 et de la Phase 2.

Trois engagements de méthode :

1. Toutes les hypothèses sont dans un seul tableau (§7.2). Aucun chiffre n'apparaît dans les projections sans y figurer.
2. Toutes les formules sont écrites (§7.3). Le lecteur peut refaire le calcul.
3. Les scénarios ne se distinguent que par les valeurs d'hypothèses, jamais par la structure du modèle.

Devise : CAD partout. Horizon : 12 trimestres à partir du jour du lancement public.

#7.2 Tableau des hypothèses

#7.3 Formules du modèle

Toutes les projections découlent des sept formules suivantes. t désigne le numéro du trimestre, de 1 à 12.

(1)  Inscriptions(t)        = H05 × (1 + H06)^(t − 1)

(2)  Nouveaux_Equipe(t)     = arrondi( Inscriptions(t) × H07 )

(3)  Comptes_Equipe(t)      = arrondi( Comptes_Equipe(t−1) × (1 − H09) ) + Nouveaux_Equipe(t)
     Comptes_Entreprise(t)  = arrondi( Comptes_Entreprise(t−1) × (1 − H10) ) + Nouveaux_Entreprise(t)

(4)  MRR(t)                 = Comptes_Equipe(t) × H03 + Comptes_Entreprise(t) × H04
     ARR(t)                 = MRR(t) × 12

(5)  Revenu_trimestre(t)    = 3 × ( MRR(t−1) + MRR(t) ) / 2

(6)  Cout_de_service(t)     = 3 × [ moy(Comptes_Equipe) × H13 + moy(Comptes_Entreprise) × H14 ]
     Marge_brute(t)         = Revenu_trimestre(t) − Cout_de_service(t)

(7)  Acquisition(t)         = Nouveaux_Equipe(t) × H11 + Nouveaux_Entreprise(t) × H12
     Charges_fixes(t)       = H15(t) × H16 / 4 + H17(t)
     Resultat(t)            = Marge_brute(t) − Acquisition(t) − Charges_fixes(t)
     Tresorerie_cumulee(t)  = Tresorerie_cumulee(t−1) + Resultat(t)

Deux conventions à connaître.

• La formule (5) utilise la moyenne du revenu mensuel récurrent en début et en fin de trimestre. C'est une approximation prudente qui évite de compter un revenu plein pour des comptes ouverts en cours de trimestre.
• La trésorerie est assimilée au résultat, sans décalage de recouvrement ni besoin en fonds de roulement. Cette simplification est favorable ; le business plan (01-business-plan.md) applique une correction de délai de recouvrement.

#7.4 Calendrier des trimestres

#7.5 Scénario prudent

Posture. Le produit trouve peu d'écho, la conversion est faible, l'attrition est forte, l'équipe reste petite. Ce scénario n'est pas un plancher : c'est un avertissement.

Revenu mensuel moyen par compte Équipe : 245 $ CAD (5 sièges × 49 $).

Lecture du scénario prudent — sans adoucissement.

Conclusion à assumer. Dans le scénario prudent, il ne faut pas financer la croissance : il faut réduire la structure de coûts ou changer le modèle. Un ratio valeur à vie sur coût d'acquisition de 1,6 signifie que chaque compte acquis coûte presque autant qu'il ne rapporte. La réponse correcte est un pivot d'acquisition (autofinancement, communauté, partenariat de distribution), pas une levée.

#7.6 Scénario médian

Posture. Le produit trouve un écho réel dans un segment, la vente directe fonctionne modestement, l'équipe grandit avec prudence.

Revenu mensuel moyen par compte Équipe : 392 $ CAD (8 sièges × 49 $).

Lecture du scénario médian.

Point d'honnêteté. Un ratio de 7,5 sur le palier Entreprise n'est pas une bonne nouvelle : c'est le signe que l'hypothèse d'attrition H10 est probablement trop favorable. Sur un produit sans référence, avec des contrats annuels, une attrition de 5 % par trimestre est optimiste. Le premier renouvellement réel corrigera ce chiffre.

#7.7 Scénario ambitieux

Posture. Le positionnement de gouvernance rencontre un besoin aigu, un canal de distribution fonctionne, la vente entreprise démarre dès la première année.

Revenu mensuel moyen par compte Équipe : 490 $ CAD (10 sièges × 49 $).

Lecture du scénario ambitieux.

Point d'honnêteté. Ce scénario est présenté parce qu'il est demandé, pas parce qu'il est probable. Un ratio valeur à vie sur coût d'acquisition supérieur à 10 signifie presque toujours que l'attrition modélisée est irréaliste ou que le coût d'acquisition ne comptabilise pas la totalité de l'effort. Il ne doit jamais être utilisé comme argument de levée de fonds sans cette réserve écrite à côté.

#7.8 Comparaison des trois scénarios

#7.9 Analyse de sensibilité — quelles hypothèses comptent vraiment

Test à une variable, appliqué au scénario médian, mesuré sur le revenu annuel récurrent au T12.

Conclusion de l'analyse. Les trois hypothèses qui décident du sort du modèle sont, dans l'ordre : l'attrition, la croissance des inscriptions, le taux de conversion. Ce sont les trois seules qu'il faut instrumenter avant le jour J, pas après.

#7.10 Conditions de falsification — quand admettre que le modèle est faux

---

#8. Structure de coûts

#8.1 Vue d'ensemble

#8.2 Infrastructure

Coût d'infrastructure de base estimé [Hypothèse] : environ 8 500 $ CAD par mois hors charge variable, soit environ 25 500 $ CAD par trimestre. Ce montant est inclus dans H17.

Fait vérifiable à surveiller. La grappe de développement est déjà en tension de capacité : un déploiement en remplacement progressif s'y bloque faute de ressources, ce qui impose une stratégie de remplacement direct. C'est un signal avancé de coût d'infrastructure, pas une anecdote.

#8.3 Modèles de langage — le poste le plus dangereux

C'est le seul poste dont le coût croît avec l'usage utile : plus le client tire de valeur, plus nous payons.

Trois garde-fous déjà présents dans le produit.

1. Pré-vérification puis règlement : le contrôle de crédit vérifie avant l'appel et ne règle qu'avec les jetons réellement consommés.
2. Bascule de modèle à 80 % du budget : le routage passe à une famille moins coûteuse.
3. Refus explicite plutôt que dépassement silencieux : code 402.

Les trois dangers résiduels.

Hypothèse de coût d'inférence par compte Équipe [Hypothèse] : 18 $ CAD par mois au palier médian, sur les 34 $ de coût de service total (H13).

#8.4 Personnel

Coût annuel chargé retenu par équivalent temps plein : 130 000 $ CAD [Hypothèse]. [Gabarit : grille de rémunération de référence du secteur des technologies au Québec — source à consulter : TechnoCompétences, enquêtes de rémunération sectorielles].

#8.5 Ventes et acquisition

Règle de discipline. Aucune dépense publicitaire avant que le message n'ait été validé par au moins cinq entretiens de vente gagnés ou perdus avec un motif explicite. Dépenser pour amplifier un message non validé est le premier gaspillage d'un lancement.

#8.6 Coût de service par client — décomposition

---

#9. Stratégie de mise en marché

#9.1 Principe directeur

La démonstration porte sur le dépôt du prospect, jamais sur un exemple. C'est notre seul avantage démonstratif décisif : en une séance, la rétro-ingénierie produit des artefacts sur leur système. Un prospect qui voit son propre système cartographié en quinze minutes a compris la proposition sans qu'on la lui explique.

Cette règle a une conséquence opérationnelle : le parcours de démonstration doit être fiabilisé avant le jour J, y compris la règle de sortie réseau qui autorise le clonage depuis un dépôt public.

#9.2 Séquence alignée sur le calendrier du programme

#9.3 Canaux, par ordre de priorité

#9.4 Motion commerciale par segment

#9.5 Message principal par persona

Le détail vit dans les douze fiches persona-*.md et la synthèse dans 03-synthese-valeur-par-persona.md. Rappel condensé :

#9.6 Ce que nous ne dirons pas

---

#10. Registre des risques

#10.1 Échelles

#10.2 Registre

#10.3 Les cinq risques à traiter en premier

#10.4 Carte des risques

---

#11. Analyse SWOT

#11.1 Forces

#11.2 Faiblesses

#11.3 Opportunités

#11.4 Menaces

#11.5 Croisements décisifs

---

#12. Indicateurs et étoile polaire

#12.1 Étoile polaire

Nombre de chaînes tracées complétées par semaine — une chaîne tracée complétée étant définie comme : une exigence versionnée, reliée à au moins un artefact de conception, à au moins un test relié à son critère d'acceptation, et à au moins un déploiement approuvé et journalisé.

Pourquoi cet indicateur.

Valeur au 2026-08-17 : 0 — aucun locataire tiers. C'est le point de départ.

#12.2 Indicateurs par étage

#Étage 1 — Acquisition

#Étage 2 — Activation

#Étage 3 — Rétention

#Étage 4 — Revenu

#Étage 5 — Santé de la plateforme

#12.3 Rituels de suivi

---

#13. Jalons datés

#13.1 Jalons du programme de lancement

#13.2 Jalons produit au-delà du jour J

Rappel du brief. Aucune ligne du tableau 13.2 ne doit apparaître dans une publicité, une fiche de magasin d'applications ou un argumentaire commercial comme une capacité disponible. Elle peut apparaître dans une feuille de route datée, présentée comme telle.

#13.3 Vue temporelle

---

#14. Décisions requises du propriétaire

---

#15. Annexes

#15.1 Glossaire

#15.2 Sources internes de ce document

#15.3 Sources externes à consulter — liste de travail

Aucune de ces sources n'a été consultée pour la rédaction de ce document. Elles sont listées pour que le travail de sourçage soit exécutable par une autre personne.

#15.4 Journal des versions

#15.5 Contrôle de conformité de ce document

---

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.