#0. Résumé en dix lignes
| Élément | Contenu |
|---|---|
| Persona | DSI / directeur TI d'une grande organisation — persona n° 6 du brief commun (§9) |
| Douleur dominante | Prouver la maîtrise de l'IA à un comité et à un auditeur |
| Ce que KySpectra apporte | Un plan de contrôle à 16 destinations, un journal d'audit à chaîne de hachage vérifiable, une séparation des devoirs appliquée par le serveur, des budgets et des plafonds d'autonomie opposables |
| Surfaces concernées | Portail d'administration — les 16 destinations du plan de contrôle ; portail client — espace de travail projet pour les 11 équipes |
| Services réels sollicités | audit-compliance-service (4113), platform-config (4112), billing-usage-service (4115), extension-registry-service (4116), agent-runtime-service (4119), user-service (4101), observability (4114), collaboration-service (4128) |
| Offre recommandée | Palier Entreprise — sur devis [Hypothèse], plafond d'autonomie N3 |
| Ce qu'on ne promet pas | La conformité automatique ; une posture durcie sans action d'exploitation ; le provisionnement automatique d'un fournisseur d'identité ; un client de référence |
| Statut de la chaîne | Plan de contrôle Livré et en ligne sur 3 environnements ; durcissement AUTH_MODE à faire ; provisionnement de fournisseur d'identité 🔴 Bloqué |
| Preuve la plus parlante | GET /audit/verify-chain : la chaîne de hachage du journal est vérifiable à la demande, et un rapport Loi 25 se génère sur une période choisie |
| Risque d'adoption | La personne attend une plateforme durcie à la livraison ; plusieurs interrupteurs de sécurité sont livrés en position permissive et exigent une décision d'exploitation |
#1. Portrait
Dominique, 52 ans, à la direction des technologies d'une organisation de 4 000 personnes. Onze équipes produit, réparties sur trois sites et deux fuseaux horaires. Un comité de direction qui se réunit chaque trimestre. Un auditeur externe qui passe une fois par an et qui, depuis deux exercices, a ajouté l'usage de l'intelligence artificielle à sa liste de contrôle. Un délégué à la protection des renseignements personnels qui, lui, écrit toute l'année.
La personne n'est pas arrivée là par la technique pure. Iel a dirigé l'exploitation, puis la sécurité, puis l'ensemble. Ce parcours lui a donné une conviction simple : une capacité que l'on ne peut pas démontrer n'existe pas, du point de vue de l'organisation. Iel a déjà vécu deux audits difficiles. Dans les deux cas, le problème n'était pas la pratique réelle des équipes — elle était correcte. Le problème était l'absence de preuve.
#1.1 Sa journée réelle
Iel arrive à 7 h 45. Trois quarts de sa journée sont des réunions : comité de portefeuille, arbitrage budgétaire, point sécurité, entretien avec un fournisseur, revue d'incident. Le quart restant est consacré à lire — des tableaux de bord, des notes du délégué à la protection des renseignements, des demandes d'exception. Iel ne code plus depuis onze ans et ne s'en cache pas. Ce qu'iel manipule, ce sont des engagements : ce que la direction a promis au conseil, ce que la direction technique a promis à la direction, ce que les onze équipes ont promis à la direction technique.
Depuis dix-huit mois, une question revient à chaque comité : « où en êtes-vous avec l'IA ? » Iel n'a pas de réponse consolidée. Iel a onze réponses partielles, toutes déclaratives.
#1.2 Sa boîte à outils actuelle
| Catégorie | Ce qu'iel utilise aujourd'hui |
|---|---|
| Portefeuille et budget | Chiffrier de portefeuille, outil de gestion de projets, budget annuel révisé deux fois |
| Gestion des accès | Annuaire d'entreprise, revue d'accès semestrielle exportée en chiffrier, validée par courriel |
| Sécurité | Outil de gestion des vulnérabilités, journal centralisé, rapports de l'équipe sécurité |
| Conformité | Registre des traitements tenu par le délégué à la protection des renseignements, en traitement de texte |
| Suivi des fournisseurs | Contrats, ententes de niveau de service, comptes rendus de comité de pilotage |
| Supervision technique | Tableaux de bord d'exploitation, tickets d'incident, rapports post-incident |
| Usage de l'IA | Aucun inventaire consolidé. Des déclarations d'équipe, des factures de fournisseurs de modèles, et des intuitions |
#1.3 Ce qui le fait juger — par la direction générale et par le conseil
- La capacité à répondre à une question du comité dans la séance, pas dans un rapport promis pour la fois suivante.
- L'absence d'incident réglementaire. Un seul suffit à effacer trois ans de bonne gestion.
- Le respect de l'enveloppe budgétaire technologique, dont la ligne « modèles et services d'IA » est devenue visible et volatile.
- La capacité des onze équipes à livrer sans que la direction technique devienne un goulot d'étranglement.
- La qualité des réponses fournies à l'auditeur externe : nombre de constats, nombre de recommandations reconduites d'une année sur l'autre.
#1.4 Ce qui l'empêche de dormir
- L'usage non déclaré. Une équipe a raccordé un agent à un dépôt de production, sans passer par personne. Iel l'apprendra par la facture ou par l'incident.
- La question de l'auditeur. « Montrez-moi la liste des actions automatisées effectuées par vos agents au troisième trimestre, avec l'identité de la personne qui les a autorisées. » Aujourd'hui, la réponse honnête est : « je ne peux pas ».
- La fuite entre entités. L'organisation héberge deux filiales sur la même plateforme. Iel n'a aucune preuve technique que les données ne se croisent pas.
- Le renseignement personnel dans un jeu de test. Iel sait que ça arrive. Iel ne sait pas où.
- La personne qui approuve sa propre demande. Pas par malveillance, par charge de travail. Et c'est exactement ce que l'auditeur cherche.
Sa phrase à lui, telle qu'iel la dirait en comité : « Je n'ai pas besoin d'aller plus vite. J'ai besoin de pouvoir répondre à trois questions sans quitter la salle : qui a décidé, qu'a fait l'IA, et comment je le prouve. »
#2. Douleurs — mécanisme de coût et fréquence
Chaque douleur est décrite avec le mécanisme par lequel elle coûte et sa fréquence observée.
| # | Douleur | Mécanisme de coût | Fréquence |
|---|---|---|---|
| D1 | Usage non déclaré de l'IA par les équipes. Onze équipes, onze pratiques, aucun inventaire central des agents, des compétences et des outils en service. | Risque encouru : une action automatisée sur un système sensible sans autorisation traçable. Décision retardée : la direction refuse d'élargir l'usage faute de visibilité, ce qui pousse les équipes à contourner. | Permanent — c'est une posture, pas un incident |
| D2 | Impossibilité de répondre à un auditeur. Les journaux existent, dispersés, non chaînés, sans garantie d'intégrité. | Temps perdu : reconstitution manuelle de traces avant chaque audit. Risque : constat formel, recommandation reconduite d'une année sur l'autre. | Annuel pour l'audit externe, trimestriel pour le comité |
| D3 | Coût des modèles non budgété. La ligne « IA » apparaît en fin de mois, sur des factures de fournisseurs, sans rattachement à un projet ni à une équipe. | Coût direct : dépassement non anticipé. Décision retardée : gel des initiatives par précaution budgétaire. | Mensuel, avec des pointes imprévisibles |
| D4 | Revue d'accès manuelle. Export d'annuaire, chiffrier, validation par courriel, réconciliation à la main. | Temps perdu : plusieurs jours-personnes par campagne. Risque : droits résiduels non révoqués, écart constaté à l'audit. | Semestriel, parfois trimestriel sur les systèmes critiques |
| D5 | Absence de séparation des devoirs opposable. La règle existe dans une politique interne ; rien dans les outils ne l'applique. | Risque encouru : une même personne demande et approuve. Coût de remédiation : contrôle compensatoire à documenter et à justifier. | À chaque campagne de contrôle interne |
| D6 | Exposition Loi 25 et RGPD. Le registre des traitements est un document ; les traitements réels sont dans des systèmes qui évoluent chaque semaine. | Risque encouru : écart entre le déclaré et le réel, sanctionnable. Temps perdu : mise à jour manuelle du registre. | Continu, avec un point de tension à chaque nouvelle mise en service |
| D7 | Renseignements personnels dans les jeux de test. Copies de production anonymisées « à peu près », dans des environnements moins protégés. | Risque encouru : fuite depuis un environnement hors production. Coût de remédiation : purge, notification, enquête. | Découvert à chaque revue d'environnement, soit 1 à 2 fois par an |
| D8 | Hétérogénéité des onze équipes. Onze manières de spécifier, de tester, de déployer, de gouverner l'IA. | Temps perdu : chaque consolidation exige une traduction manuelle. Risque : la maturité affichée est celle de l'équipe la plus faible. | Permanent, visible à chaque consolidation trimestrielle |
| D9 | Dépendance à des prestataires. Trois intégrateurs travaillent sur des systèmes internes. Ce qu'ils produisent part avec eux. | Coût direct : reprise onéreuse en fin de contrat. Risque : dépendance de fait sur un système critique. | À chaque renouvellement contractuel — 3 à 5 par an |
| D10 | Absence de preuve de non-fuite entre entités. Deux filiales sur la même plateforme, aucune démonstration technique d'étanchéité. | Risque encouru : constat majeur d'audit, contestation d'une filiale. Décision retardée : refus de mutualiser des plateformes, donc surcoût d'infrastructure. | Soulevé à chaque audit et à chaque intégration d'entité |
| D11 | Décisions de déploiement non tracées. On sait ce qui a été déployé ; on ne sait pas qui a décidé, ni sur quelle base. | Temps perdu : enquête après incident. Risque : impossibilité d'établir une responsabilité. | À chaque incident significatif — 4 à 8 par an |
| D12 | Délai d'instruction d'un incident. Rassembler les traces de cinq systèmes prend plus de temps que corriger la cause. | Temps perdu : le délai d'instruction dépasse le délai de correction. Risque : dépassement des délais de notification réglementaire. | À chaque incident de sécurité ou de confidentialité |
#3. Réponse produit — uniquement des fonctionnalités réelles
Règle appliquée : chaque ligne cite la destination du plan de contrôle ou le service réel. Une attente sans réponse aujourd'hui est signalée telle quelle.
| Douleur | Fonctionnalité KySpectra qui y répond | Où c'est dans le produit | Statut | Ce que ça change concrètement |
|---|---|---|---|---|
| D1 Usage non déclaré | Registre central d'agents : nom, nature statique ou dynamique, capacités, compétences, serveurs MCP, jetons, santé ; activation et désactivation unitaires | Destination agents du plan de contrôle — GET /agents/registry, GET /agents/list, PATCH /agents/{id} (ai-orchestrator, 4106) ; 34 agents au registre central en production |
🟢 Livré | L'inventaire cesse d'être déclaratif. Un agent absent du registre n'est pas un agent autorisé. |
| D1 Usage non déclaré | Registre à trois niveaux — compétences, outils MCP, prompts — avec adoption explicite et révocation motivée | Destination registry — extension-registry-service (4116) : /skills, /mcp/servers, /catalog/prompts, /extensions/{kind}/{id}/revoke |
🟢 Livré | Ce que les agents peuvent utiliser est une liste tenue, pas une découverte a posteriori. |
| D1 Usage non déclaré | Refus par défaut journalisé : toute action non explicitement couverte est refusée sous policy_id="deny-by-default" |
agent-runtime-service (4119), table app_policy_check ; destination policies |
🟢 Livré | La posture par défaut de la plateforme est le refus, pas la permission. |
| D2 Réponse à l'auditeur | Journal d'audit à chaîne de hachage et vérification de chaîne à la demande | Destination audit — audit-compliance-service (4113) : GET /audit/events, GET /audit/verify-chain |
🟢 Livré | L'intégrité du journal se démontre pendant la séance, pas dans une note de suite. |
| D2 Réponse à l'auditeur | Rapports de conformité Loi 25 sur période, générés et exportables | Destination audit — `GET |
POST /compliance/reports, genre loi25`, export JSON local |
🟢 Livré |
| D2 Réponse à l'auditeur | Recherche d'évènements par acteur, action, ressource, texte libre | Destination audit — GET /audit/events avec filtres |
🟢 Livré | « Qui a fait quoi, quand » devient une requête, pas une enquête. |
| D3 Coût non budgété | Budgets par portée avec limite, seuil d'avertissement et seuil critique ; jauges dépensé / restant / pourcentage | Destination budgets — billing-usage-service (4115) : `GET |
POST /budgets, PATCH |
DELETE /budgets/{id}` |
| D3 Coût non budgété | Fenêtres de quota par portée et par modèle, avec consommé et réinitialisation ; seuils 50 / 80 / 95 %, bascule de routage à 80 %, drainage à 95 % ; dépassement de budget de jetons ⇒ 402 | Destination budgets — GET /quota-windows ; budget par défaut 500 000 jetons/jour et 10 000 000/mois |
🟢 Livré | Le dépassement est arrêté par la plateforme, pas constaté en fin de mois. |
| D4 Revue d'accès manuelle | Gestion des utilisateurs et des rôles Keycloak depuis le plan de contrôle, avec permissions effectives lisibles par utilisateur | Destination users — user-service (4101) : `GET |
POST /users, PATCH |
DELETE /users/{id}, POST |
| D4 Revue d'accès manuelle | Overrides de permission avec effet, priorité et raison obligatoire, révocables | Destination users — `GET |
POST | DELETE /permissions/overrides` |
| D5 Séparation des devoirs | Séparation des devoirs appliquée par le serveur : rejet de l'auto-approbation en 409 sod/self-approval-forbidden ; acteur requis en 422 validation/sod-actor-required ; blocage préalable côté interface |
Destination governance — collaboration-service (4128), extension-registry-service : POST /extensions/{kind}/{id}/review |
🟢 Livré | La règle n'est plus une consigne : elle est un refus serveur, testé et journalisé. |
| D5 Séparation des devoirs | Trois rôles plateforme × 16 capacités, avec capacités réservées à l'administration | Destination config et modèle de rôles : viewer, platform_operator, platform_admin |
🟢 Livré | Qui peut approuver, qui peut seulement opérer, qui ne peut que lire : c'est une matrice, pas un usage. |
| D6 Loi 25 et RGPD | Rapports Loi 25 sur période et journal chaîné comme socle de preuve | Destination audit — voir D2 |
🟢 Livré | Le registre des traitements s'adosse à des évènements réels. La tenue du registre reste humaine. |
| D6 Loi 25 et RGPD | Politiques de garde-fous évaluables à la volée : motif d'action, effet autoriser ou refuser, priorité, exigence d'approbation | Destination policies — platform-config (4112) : `GET |
POST | PATCH |
| D7 Renseignements dans les tests | Jeux de données de test synthétiques | test-data-factory-service (4110) — /api/v1/test-data-factory/test-datasets |
🟢 Livré | Les environnements hors production cessent d'être une copie du réel. |
| D8 Hétérogénéité | Drapeaux de fonctionnalité avec portée globale ou par locataire et déploiement progressif de 0 à 100 % | Destination flags — platform-config : `GET |
POST /feature-flags, PATCH |
DELETE /feature-flags/{id}` |
| D8 Hétérogénéité | Configurations de modèles et d'adaptateurs centralisées, avec chemin de coffre pour les secrets et modèle par défaut | Destination models — `GET |
POST /model-configs, /adapter-configs; cheminssecret/…` |
🟢 Livré |
| D8 Hétérogénéité | État système consolidé : santé des services, indicateurs de progression, défauts, incidents, agents, brèches de niveau de service | Destination overview — observability (4114) : /board, /metrics/catalog, /gates/breaches |
🟢 Livré | Une seule page à ouvrir avant le comité. |
| D9 Dépendance aux prestataires | Rétro-ingénierie d'un dépôt existant vers sept familles d'artefacts, avec file de validation humaine et promotion de spécifications | reverse-engineering-service (4120) — POST /api/v1/reverse-engineering/jobs, GET …/validation-tasks |
🟢 Livré — prouvé en production | Ce qu'un prestataire livre devient documenté du côté de l'organisation, pas du sien. |
| D10 Preuve de non-fuite | Isolation par masquage d'existence : identifiant de locataire en désaccord avec le jeton ⇒ 404, jamais 403 | Comportement transverse de la passerelle et des services ; destination tenants |
🟢 Livré | On ne révèle même pas l'existence de la ressource d'une autre entité. C'est démontrable en séance. |
| D10 Preuve de non-fuite | Gestion des locataires : création, sélection, plan associé, registre des organisations | Destination tenants — GET /organizations, GET /billing/plans, POST /admin/tenants |
🟢 Livré | Chaque entité est un locataire avec ses propres droits. |
| D11 Décisions non tracées | Flotte d'agents : exécutions en cours, graphe d'exécution, détail d'un run, interruption d'un run avec acteur exigé | Destination fleet — agent-runtime-service : GET /runs, POST /runs/{id}/interrupt |
🟢 Livré | Une exécution automatisée est visible pendant qu'elle se produit, et arrêtable par une personne nommée. |
| D11 Décisions non tracées | Politiques d'exécution : politique réseau devant commencer par deny-, liste d'autorisation de sortie, durée maximale, politique de système de fichiers |
Destination policies — `GET |
POST | PATCH |
| D12 Délai d'instruction | Audit des appels d'outil par les agents, consultable depuis la gouvernance | Destination governance — GET /audit/tool-calls (extension-registry-service) |
🟢 Livré | L'instruction commence par une requête, pas par cinq demandes d'export. |
| D12 Délai d'instruction | Personnel IA : effectif virtuel, autonomie N0 à N3, équipes, files, tâches ouvertes, mise en pause | Destination workforce — agentic-core-service (8095) : GET /workforce/overview, /workforce/staff, PATCH /workforce/staff/{id} |
🟢 Livré — phase 1 | On met en pause un agent comme on suspend un accès. |
| D1 et D5 | Rôles IA : plafond d'autonomie par rôle virtuel, liaisons de compétences, d'outils et de prompts, découverte et import sous revue de séparation des devoirs | Destination roles — /virtual-roles/{id}/bundle, /tool-permissions, /catalog/import/discover |
🟢 Livré (drapeau REGISTRY_VIRTUAL_ROLES_ENABLED, défaut False — activation d'exploitation requise ; sinon GET /api/v1/entitlements répond 404) |
Le plafond d'autonomie est une décision écrite, révocable, plafonnée par le plan commercial. |
| Attente non couverte | Suspension d'un locataire depuis le plan de contrôle | Écart affiché dans l'interface — absent du user-service |
⚪ Planifié | À dire d'emblée : suspendre une entité reste une opération manuelle. |
| Attente non couverte | Agrégat d'exécutions d'agents inter-locataires | Écart affiché dans l'interface | ⚪ Planifié | La flotte se lit locataire par locataire. Pas de vue consolidée sur l'ensemble. |
| Attente non couverte | File de séparation des devoirs transverse | Écart affiché dans l'interface | ⚪ Planifié | Les revues se chargent par sujet, pas dans une file unique à traiter. |
| Attente non couverte | Provisionnement automatique de fournisseur d'identité | Droits d'administration insuffisants sur le serveur d'identité — 403 vérifiés | 🔴 Bloqué | Déblocage = action d'exploitation sur le compte de service. Ne jamais le présenter comme disponible. |
| Attente non couverte | Compteurs d'usage de facturation | GET /billing/usage renvoie des compteurs codés en dur |
🔴 Bloqué | Ne jamais montrer cet écran comme un relevé de consommation. Les budgets et les fenêtres de quota, eux, sont réels. |
| Attente non couverte | Application mobile pour la direction | Aucun code mobile dans le dépôt | ⚪ Planifié | Les portails sont responsives et utilisables via navigateur mobile. Rien de plus. |
#4. Semaine type — avant / après
Méthode. Les heures déplacées sont marquées [Hypothèse]. Elles ne viennent d'aucune mesure client — il n'existe aucun pilote à ce jour. La colonne « Comment le mesurer » indique une source réelle et disponible dans le produit.
#4.1 Avant KySpectra
| Jour | Activité dominante | Temps typique | Frottement |
|---|---|---|---|
| Lundi | Consolidation de l'état des onze équipes pour le point hebdomadaire de direction | 2 h 30 | Onze formats, onze niveaux de détail, aucune source commune |
| Mardi | Arbitrage budgétaire technologique, dont la ligne « modèles et services d'IA » | 1 h 30 | Facturation reçue a posteriori, sans rattachement à un projet |
| Mercredi | Préparation de la campagne de revue d'accès et suivi des exceptions | 3 h | Export d'annuaire, chiffrier, validation par courriel, réconciliation manuelle |
| Jeudi | Demandes du délégué à la protection des renseignements personnels et suivi des engagements d'audit | 2 h | Preuve à reconstituer à la main, système par système |
| Vendredi | Instruction d'un incident et préparation du prochain comité | 3 h 30 | Traces dispersées, décision de déploiement sans acteur identifiable |
#4.2 Après KySpectra
| Jour | Ce qui change | Heures déplacées [Hypothèse] |
Comment le mesurer |
|---|---|---|---|
| Lundi | La destination overview consolide santé des services, indicateurs, défauts, incidents et brèches de niveau de service en une page |
−1 h 15 de consolidation manuelle | observability (4114) — /board?scopeKind=tenant, /gates/breaches : nombre de consultations avant le point hebdomadaire |
| Mardi | La destination budgets porte les enveloppes par portée avec seuils d'avertissement et critique, et les fenêtres de quota par modèle |
−45 min d'arbitrage à l'aveugle | billing-usage-service (4115) — GET /budgets, GET /quota-windows : nombre de portées couvertes par un budget actif |
| Mercredi | La destination users donne les permissions effectives par utilisateur et les overrides motivés ; les rôles Keycloak se modifient depuis la même page |
−1 h 30 sur la campagne de revue | user-service (4101) — GET /permissions/effective, GET /permissions/overrides : nombre d'overrides portant une raison écrite |
| Jeudi | La destination audit fournit la recherche d'évènements, la vérification de chaîne et le rapport Loi 25 sur période |
−1 h de reconstitution de preuve | audit-compliance-service (4113) — GET /audit/verify-chain, `GET |
| Vendredi | L'instruction commence par GET /audit/events et GET /audit/tool-calls ; la décision de déploiement porte un acteur |
−1 h 30 sur le délai d'instruction | audit-compliance-service et extension-registry-service (4116) : délai médian entre ouverture d'incident et première trace consolidée |
#4.3 Bilan hebdomadaire
| Poste | Avant | Après [Hypothèse] |
Écart [Hypothèse] |
|---|---|---|---|
| Consolidation de l'état des équipes | 2 h 30 | 1 h 15 | −1 h 15 |
| Arbitrage budgétaire IA | 1 h 30 | 0 h 45 | −0 h 45 |
| Revue d'accès et exceptions | 3 h | 1 h 30 | −1 h 30 |
| Preuve de conformité et suivi d'audit | 2 h | 1 h | −1 h |
| Instruction d'incident | 3 h 30 | 2 h | −1 h 30 |
| Total déplacé | — | — | ≈ 6 h par semaine pour la direction technique [Hypothèse] |
Honnêteté sur le chiffre. Ces 6 heures ne sont pas un engagement contractuel. Elles décrivent une hypothèse à valider pendant la Phase 1 — pilotes fermés, du 2026-09-07 au 2026-10-04 (brief §11). Elles ne comptent que le temps de la direction technique, pas celui des onze équipes.
[Gabarit : mesure réelle du temps de consolidation et d'instruction avant/après, à collecter auprès d'au moins deux organisations pilotes de Phase 1]
#5. Valeur créée
#5.1 Valeur qualitative
| Dimension | Ce qui change pour Dominique |
|---|---|
| Capacité à répondre en séance | Les trois questions du comité — qui a décidé, qu'a fait l'IA, comment le prouver — se traitent depuis trois destinations du plan de contrôle, pendant la réunion. |
| Opposabilité | Le journal d'audit est chaîné par hachage et sa chaîne se vérifie à la demande. Une trace vérifiable a une valeur différente d'une trace exportée. |
| Posture défendable | Le refus par défaut et le masquage d'existence en 404 sont des comportements du produit, pas des politiques internes. Ils se démontrent. |
| Maîtrise budgétaire | La dépense d'IA devient une enveloppe décidée avec des seuils qui arrêtent réellement la consommation, plutôt qu'une facture commentée après coup. |
| Homogénéisation sans imposition | Le déploiement progressif de 0 à 100 % permet d'aligner onze équipes par vagues, avec retour en arrière possible. |
| Réduction de la dépendance | La rétro-ingénierie produit une documentation qui reste dans l'organisation quand le prestataire part. |
| Bilinguisme de plein droit | Le plan de contrôle est en français et en anglais avec une parité stricte de 841 clés. Un comité bilingue lit la même chose. |
#5.2 Valeur quantitative — formules visibles
Aucun gain chiffré sans formule. Les variables [Hypothèse] sont à remplacer par les mesures du pilote.
#Formule 1 — Temps de préparation d'audit récupéré
GAIN_AUDIT = (J_avant - J_apres) * C_jour * N_campagnes
| Variable | Signification | Valeur de travail |
|---|---|---|
J_avant |
Jours-personnes de reconstitution de preuve par campagne | 12 [Hypothèse] |
J_apres |
Jours-personnes avec journal chaîné et rapport Loi 25 sur période | 4 [Hypothèse] |
C_jour |
Coût interne d'un jour-personne | [Gabarit : coût jour-personne interne, à fournir par le client] |
N_campagnes |
Campagnes par an — audit externe + contrôle interne | 3 [Hypothèse] |
Application partielle : (12 − 4) × 3 = 24 jours-personnes récupérés par an [Hypothèse]. La conversion en montant exige C_jour, non fourni.
#Formule 2 — Revue d'accès industrialisée
GAIN_REVUE = (H_avant - H_apres) * N_campagnes_acces
| Variable | Signification | Valeur de travail |
|---|---|---|
H_avant |
Heures par campagne — export, chiffrier, courriels, réconciliation | 60 h [Hypothèse] |
H_apres |
Heures avec permissions effectives lisibles et overrides motivés | 24 h [Hypothèse] |
N_campagnes_acces |
Campagnes de revue d'accès par an | 2 [Hypothèse] |
Application : (60 − 24) × 2 = 72 heures-personnes par an [Hypothèse].
#Formule 3 — Dépense d'IA maîtrisée par les budgets et quotas
ECONOMIE_MODELES = D_annuelle * T_derive * T_interception
| Variable | Signification | Valeur de travail |
|---|---|---|
D_annuelle |
Dépense annuelle en modèles et services d'IA | [Gabarit : dépense annuelle réelle en modèles, à extraire des factures fournisseurs du client] |
T_derive |
Part de dépense non rattachée à un projet ou hors enveloppe | 0,18 [Hypothèse] |
T_interception |
Part de cette dérive arrêtée par les seuils 80 % et 95 % et le plafond de jetons | 0,55 [Hypothèse] |
Chiffre volontairement non produit. Sans
D_annuellefournie par le client, cette formule ne donne aucun montant. Le mécanisme, lui, est réel : bascule de routage à 80 %, drainage à 95 %, dépassement de budget de jetons rejeté en 402.
#Formule 4 — Valeur de la conformité démontrable (volontairement non chiffrée)
VALEUR_CONFORMITE = P_constat * C_audit + P_incident * C_incident_conformite
| Variable | Signification | Valeur de travail |
|---|---|---|
P_constat |
Probabilité annuelle d'un constat formel lié à la traçabilité de l'IA | [Gabarit : historique de constats d'audit sur trois exercices, à fournir par le client] |
C_audit |
Coût complet d'un audit — honoraires, mobilisation interne, remédiation | [Gabarit : coût complet d'un audit, à établir avec la direction financière du client] |
P_incident |
Probabilité annuelle d'un incident de conformité sur les renseignements personnels | [Gabarit : historique d'incidents de conformité, à fournir par le délégué à la protection des renseignements] |
C_incident_conformite |
Coût d'un incident de conformité — enquête, notification, remédiation, sanction éventuelle | [Gabarit : coût d'un incident de conformité, à établir avec le conseil juridique du client] |
Interdiction assumée. Aucune des quatre variables n'est en notre possession, et aucune ne peut être approchée honnêtement par une moyenne de marché. Cette formule est présentée vide. Nous la remplissons avec vous, avec vos chiffres, ou nous ne la remplissons pas. Toute estimation que nous produirions seuls serait une invention.
#Formule 5 — Coût de la plateforme, à mettre en regard
COUT_ANNUEL_ENTREPRISE = MONTANT_DEVIS
| Variable | Signification | Valeur de travail |
|---|---|---|
MONTANT_DEVIS |
Montant annuel du palier Entreprise | sur devis [Hypothèse] — le catalogue de plans en base porte enterprise à 0 $, c'est-à-dire « sur devis », devise CAD |
| Repère de comparaison | Palier Équipe réellement en base | 49,00 $ CAD/mois, annuel 490,00 $ CAD, slug = team [Hypothèse] sur la modalité par utilisateur |
Précision obligatoire. Le palier Entreprise n'a aucun prix arrêté. Toute grille présentée à un comité doit porter l'étiquette
[Hypothèse]et être validée par le propriétaire avant diffusion (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 — Dominique, direction des technologies
#Tâches à accomplir
| Type | Tâche | Intensité |
|---|---|---|
| Fonctionnelle | Produire un état consolidé de l'usage de l'IA pour le comité de direction | Trimestrielle |
| Fonctionnelle | Répondre aux demandes de l'auditeur externe avec des preuves recevables | Annuelle, avec préparation continue |
| Fonctionnelle | Tenir l'enveloppe budgétaire technologique, dont la ligne modèles et services d'IA | Mensuelle |
| Fonctionnelle | Conduire les campagnes de revue d'accès | Semestrielle |
| Fonctionnelle | Instruire un incident dans les délais réglementaires de notification | À chaque incident |
| Fonctionnelle | Homogénéiser les pratiques de onze équipes sans les bloquer | Continue |
| Sociale | Être la personne qui donne une réponse plutôt qu'une promesse de réponse | À chaque comité |
| Sociale | Protéger les équipes d'une injonction de conformité mal calibrée | Continue |
| Émotionnelle | Ne pas découvrir un usage d'IA par une facture ou par un incident | Continue |
| Émotionnelle | Pouvoir dire « oui, nous maîtrisons » sans se mentir | À chaque comité |
#Frustrations
| Frustration | Sévérité |
|---|---|
| Aucun inventaire consolidé des agents et des outils en service | Élevée |
| Traces non chaînées, donc contestables | Élevée |
| Facture d'IA découverte après coup | Élevée |
| Revue d'accès sur chiffrier | Moyenne |
| Séparation des devoirs qui repose sur la bonne volonté | Élevée |
| Registre des traitements décalé du réel | Élevée |
| Aucune preuve technique d'étanchéité entre entités | Élevée |
| Onze pratiques différentes à consolider à la main | Moyenne |
| Documentation qui part avec le prestataire | Moyenne |
| Instruction d'incident plus longue que la correction | Élevée |
#Attentes et gains recherchés
| Gain attendu | Nature |
|---|---|
| Répondre aux trois questions du comité pendant la séance | Crédibilité |
| Une preuve d'intégrité que l'auditeur accepte sans discussion | Réduction de risque |
| Une dépense d'IA plafonnée par la plateforme, pas par une consigne | Maîtrise budgétaire |
| Une revue d'accès qui se fait sur l'état réel du système | Gain de temps |
| Une règle de séparation des devoirs que personne ne peut contourner | Contrôle interne |
| Une démonstration d'étanchéité entre entités, en direct | Argument d'audit |
| Un alignement progressif des équipes, réversible | Conduite du changement |
#7.2 Carte de valeur — KySpectra
#Produits et services proposés
| Élément | Surface réelle | Statut |
|---|---|---|
| Plan de contrôle d'administration à 16 destinations | Portail d'administration, en ligne sur 3 environnements | 🟢 Livré |
| Journal d'audit chaîné et vérification de chaîne | Destination audit — GET /audit/verify-chain |
🟢 Livré |
| Rapports de conformité Loi 25 sur période | Destination audit — GET|POST /compliance/reports |
🟢 Livré |
| Budgets, seuils et fenêtres de quota | Destination budgets |
🟢 Livré |
| Gestion des utilisateurs, rôles Keycloak, permissions effectives, overrides motivés | Destination users |
🟢 Livré |
| Gouvernance et séparation des devoirs, audit des appels d'outil | Destination governance |
🟢 Livré |
| Garde-fous et politiques d'exécution | Destination policies |
🟢 Livré |
| Drapeaux de fonctionnalité avec déploiement progressif | Destination flags |
🟢 Livré |
| Configurations de modèles et d'adaptateurs avec chemins de coffre | Destination models |
🟢 Livré |
| Registre à trois niveaux et registre central d'agents | Destinations registry et agents |
🟢 Livré |
| Personnel IA et rôles IA avec plafond d'autonomie | Destinations workforce et roles |
🟢 Livré (rôles : drapeau à activer) |
| Locataires, état système, démonstration, configuration | Destinations tenants, overview, demo, config |
🟢 Livré (module de démonstration : drapeau à False par défaut) |
| Suspension de locataire, agrégat inter-locataires, file SoD transverse | — | ⚪ Planifié |
| Provisionnement automatique de fournisseur d'identité | — | 🔴 Bloqué |
#Solutions aux problèmes
| Frustration visée | Mécanisme produit qui la traite |
|---|---|
| Aucun inventaire consolidé | Registre central d'agents + registre à trois niveaux + refus par défaut journalisé |
| Traces contestables | Chaîne de hachage sur le journal d'audit, vérifiable par GET /audit/verify-chain |
| Facture d'IA subie | Budgets par portée avec seuils 50 / 80 / 95 %, fenêtres de quota, plafond de jetons, dépassement en 402 |
| Revue d'accès sur chiffrier | Permissions effectives par utilisateur, rôles Keycloak modifiables, overrides à raison obligatoire |
| Séparation des devoirs facultative | Rejet serveur 409 sod/self-approval-forbidden et 422 validation/sod-actor-required, blocage préalable côté interface |
| Registre des traitements décalé | Rapports Loi 25 générés sur période depuis les évènements réels |
| Étanchéité non prouvée | Réponse 404 et non 403 sur un locataire étranger — masquage d'existence |
| Onze pratiques différentes | Drapeaux de fonctionnalité par portée avec déploiement progressif de 0 à 100 % |
| Documentation qui part | Rétro-ingénierie du dépôt vers sept familles d'artefacts, promotion après décision humaine |
| Instruction trop lente | Recherche d'évènements par acteur, action, ressource ; audit des appels d'outil ; interruption de run avec acteur exigé |
#Créateurs de gains
| Gain recherché | Créateur de gain KySpectra |
|---|---|
| Répondre en séance | Trois destinations suffisent : overview pour l'état, audit pour la preuve, fleet pour l'action des agents |
| Preuve acceptée | Vérification de chaîne à la demande, exécutée devant l'auditeur |
| Dépense plafonnée | Bascule de routage à 80 %, drainage à 95 %, budget de jetons par défaut 500 000/jour et 10 000 000/mois |
| Revue d'accès rapide | Permissions effectives calculées, pas déclarées |
| Contrôle interne opposable | Séparation des devoirs testée côté serveur, pas seulement affichée |
| Alignement réversible | Un drapeau se remet à 0 % aussi vite qu'il est monté à 100 % |
| Lecture bilingue | Parité stricte de 841 clés entre français et anglais dans le plan de contrôle |
#7.3 Évaluation d'adéquation
| Tâche / frustration | Réponse produit | Niveau d'adéquation | Commentaire |
|---|---|---|---|
| Prouver l'intégrité des traces | Journal chaîné + vérification de chaîne | Fort | C'est le cœur de la proposition pour cette persona |
| Produire un rapport réglementaire sur période | Rapports Loi 25 | Fort | Livré ; la qualification juridique du rapport reste du ressort du client |
| Démontrer l'étanchéité entre entités | Masquage d'existence en 404 | Fort | Comportement transverse, démontrable en séance |
| Maîtriser la dépense d'IA | Budgets, quotas, plafond de jetons | Fort | Livré ; l'écran d'usage de facturation, lui, est factice et ne doit pas être montré |
| Industrialiser la revue d'accès | Permissions effectives + overrides motivés | Moyen à fort | Livré ; aucune campagne de recertification formelle n'est outillée |
| Opposer une séparation des devoirs | Rejets serveur 409 et 422 | Fort | Testé côté serveur ; la file SoD transverse est Planifiée |
| Disposer d'une plateforme durcie à la livraison | — | Faible, assumé | AUTH_MODE vaut dev-headers par défaut. Le durcissement est une action, pas une propriété acquise |
| Fédérer l'identité avec l'annuaire d'entreprise | — | Nul aujourd'hui | Provisionnement automatique de fournisseur d'identité 🔴 Bloqué — 403 vérifiés |
| Suspendre une entité depuis le plan de contrôle | — | Nul aujourd'hui | ⚪ Planifié — écart affiché dans l'interface |
| Consulter depuis un téléphone en comité | — | Faible | Portails responsives seulement ; aucune application mobile |
Aucun diagramme à afficher
Diagramme 2 — flowchart
#8. Objections et réponses honnêtes
| # | Objection | Réponse |
|---|---|---|
| O1 | « Est-ce que votre plateforme nous rend conformes ? » | Non, et personne ne peut le promettre. Nous ne revendiquons aucune conformité automatique. Ce que nous fournissons, ce sont des mécanismes de preuve : un journal chaîné vérifiable, des rapports Loi 25 sur période, une séparation des devoirs refusée côté serveur, un refus par défaut journalisé. La qualification juridique de votre conformité reste le travail de votre délégué à la protection des renseignements et de votre conseil. |
| O2 | « Votre plateforme est-elle durcie à la livraison ? » | Non, pas par défaut, et c'est une limite que nous assumons. La variable AUTH_MODE vaut dev-headers par défaut et n'est définie dans aucun manifeste de déploiement du dépôt. Dans ce mode, l'opérateur déclare lui-même son identité et ses rôles. Le mode strict est jwt, adossé au serveur d'identité. Passer en jwt est une action de durcissement à faire au déploiement, pas une propriété acquise du produit. Nous préférons vous le dire avant que votre équipe sécurité le découvre. |
| O3 | « Tous vos services appliquent-ils le contrôle de rôle ? » | Non. Le service agent-registry-service n'a aucune garde de rôle sur ses routes d'agents : il ne fait que résoudre le locataire. C'est un écart de sécurité réel, identifié, à corriger. Les autres surfaces citées dans ce document appliquent la hiérarchie VIEWER < EDITOR < PUBLISHER < ADMIN < OWNER < SUPERADMIN et les capacités du plan de contrôle. Nous ne présenterons pas un écart connu comme un détail. |
| O4 | « Pouvez-vous vous brancher sur notre annuaire d'entreprise ? » | Le produit s'authentifie contre un serveur d'identité compatible avec le flux Authorization Code + PKCE, et la gestion des rôles par utilisateur est livrée. En revanche, le provisionnement automatique d'un fournisseur d'identité est 🔴 Bloqué : le compte de service ne dispose ni du droit de création de royaume ni du droit de gestion des fournisseurs d'identité — 403 vérifiés. Le déblocage est une action d'exploitation côté serveur d'identité, à planifier avec vos équipes. |
| O5 | « Puis-je suspendre une entité depuis votre console ? » | Non aujourd'hui. La suspension de locataire est absente du service utilisateur, et l'interface affiche explicitement cet écart plutôt que de proposer un bouton inopérant. Vous pouvez créer un locataire, le sélectionner, lire son plan et gérer ses utilisateurs. La suspension reste une opération manuelle. C'est ⚪ Planifié. |
| O6 | « J'ai onze équipes. Puis-je voir toutes leurs exécutions d'agents sur un seul écran ? » | Non. Il n'existe pas d'agrégat d'exécutions inter-locataires : la flotte se lit locataire par locataire. L'écart est affiché dans l'interface. Si votre besoin premier est un tableau de bord consolidé sur onze entités distinctes dès le premier jour, ce point doit être arbitré avant l'engagement. |
| O7 | « Vos écrans de consommation sont-ils fiables ? » | Partiellement, et il faut distinguer. Les budgets et les fenêtres de quota sont réels : portée, limite, seuils d'avertissement et critique, consommé, réinitialisation, avec un dépassement de budget de jetons rejeté en 402. En revanche, GET /billing/usage renvoie aujourd'hui des compteurs codés en dur. Nous ne montrerons jamais cet écran comme un relevé de consommation, et vous ne devez pas fonder une décision dessus. |
| O8 | « Vous n'avez aucun client de référence à me montrer. » | Exact, et nous ne contournerons pas la question. Il n'existe aucun client payant, aucun témoignage, aucun logo à ce jour. [Gabarit : témoignage à collecter auprès d'une organisation pilote de Phase 1]. Ce que nous pouvons montrer, ce sont des preuves d'exécution sur notre propre production : rétro-ingénierie d'un dépôt public jusqu'aux spécifications, produit servi sur un sous-domaine avec certificat, régression post-déploiement réussie le 2026-08-15. |
| O9 | « Comment prouvez-vous qu'il n'y a pas de fuite entre nos filiales ? » | Par un comportement observable et démontrable en séance : un identifiant de locataire en désaccord avec le jeton produit une réponse 404, jamais 403. Nous ne répondons pas « accès refusé » — ce qui révélerait l'existence de la ressource. Nous répondons « cela n'existe pas ». Votre auditeur peut le tester lui-même sur un environnement de qualification. |
| O10 | « Un agent peut-il agir hors de ce que nous avons autorisé ? » | Le moteur de politique fonctionne en liste d'autorisations : toute action non explicitement couverte est refusée, avec policy_id="deny-by-default", et journalisée dans la table app_policy_check. Les politiques d'exécution imposent une politique réseau dont la clé doit commencer par deny-, une liste d'autorisation de sortie et une durée maximale d'exécution. Une exécution en cours peut être interrompue, et l'interruption exige une identité d'acteur. |
| O11 | « Le plafond d'autonomie fonctionne-t-il vraiment ? » | Le mécanisme est livré et testé : cap_autonomy = min(plafond du rôle, maximum du plan) sur l'échelle N0 < N1 < N2 < N3, et une valeur inconnue dégrade vers N1 — la sécurité par défaut va vers le bas. Mais le drapeau REGISTRY_VIRTUAL_ROLES_ENABLED vaut False par défaut et n'est activé dans aucun manifeste : tant qu'un exploitant ne l'active pas, GET /api/v1/entitlements répond 404. C'est une opération d'exploitation, pas un développement. Nous ne prétendons pas que c'est actif partout. |
| O12 | « Nous avons déjà une plateforme de gouvernance et un outil de gestion des accès. » | Alors la question n'est pas de les remplacer. Votre outil de gestion des accès gouverne des personnes ; ce que vous n'avez probablement pas, c'est un inventaire opposable de ce que font vos agents et une trace chaînée de leurs actions. Si votre organisation dispose déjà d'un registre d'agents, d'un journal chaîné vérifiable et d'un plafond d'autonomie par rôle, notre apport est marginal et il faut le dire. |
| O13 | « Vos interfaces affichent encore un autre nom que KySpectra. » | Oui. Le nom affiché dans l'interface est encore le nom de code interne, et il n'existe aucun fichier de logo dans le dépôt. C'est un écart de pré-lancement identifié et planifié avant le jour J, le 2026-11-10. Nous préférons vous le signaler plutôt que vous laisser le découvrir en démonstration. |
| O14 | « Combien coûte le palier Entreprise ? » | Il n'a pas de prix arrêté. Le catalogue en base porte le palier Entreprise « sur devis », et trois jeux de données de démarrage incompatibles y coexistent encore — leur nettoyage est un préalable bloquant au lancement. Toute grille que nous vous présenterions aujourd'hui porterait l'étiquette [Hypothèse]. Le seul prix réellement en base est celui du palier Équipe : 49,00 $ CAD par mois, 490,00 $ CAD en annuel, devise CAD uniquement. |
| O15 | « Combien de temps avant que ce soit utile pour mon comité ? » | Le plan de contrôle est utilisable dès la mise en service : état système, budgets, journal d'audit et vérification de chaîne ne demandent aucune préparation de données. En revanche, un rapport Loi 25 n'a de valeur que sur une période où des évènements ont été produits par vos équipes. Comptez un trimestre complet d'usage avant le premier rapport significatif. [Gabarit : durée réelle avant premier rapport de conformité exploitable, à mesurer en Phase 1] |
#9. Offre recommandée
#9.1 Le plan
Palier Entreprise — sur devis [Hypothèse], plafond d'autonomie N3.
Le palier
enterpriseexiste réellement dans le catalogue de plans en base, à 0 $, c'est-à-dire sur devis. Aucun montant n'est arrêté. Devise unique dans le code : CAD. Toute grille tarifaire présentée à un comité doit porter l'étiquette[Hypothèse]et être validée par le propriétaire avant diffusion (brief §10).
#9.2 Pourquoi ce palier pour cette persona
| Raison | Détail |
|---|---|
| Recherche en ligne pour les agents | Elle n'est activée qu'au palier Entreprise. Une organisation qui veut que ses agents s'appuient sur des sources externes actualisées n'a pas d'autre option dans la grille. |
| Volumes | 1 000 compétences, 500 outils, 200 rôles, 1 000 000 d'appels d'outil par jour. Onze équipes produit et 4 000 personnes dépassent structurellement les 25 compétences, 10 outils, 10 rôles et 5 000 appels par jour du palier Équipe. |
| Plafond d'autonomie N3 | Le palier Équipe plafonne à N2. Une organisation qui veut confier à des agents des tâches de niveau supérieur, sous surveillance, a besoin de N3 — et de la capacité de le redescendre par rôle. |
| Exigence réglementaire | Le journal d'audit chaîné, les rapports Loi 25, la séparation des devoirs opposable et l'isolation stricte entre entités sont les mécanismes qui justifient un engagement contractuel avec une organisation soumise à un auditeur externe annuel. |
| Multi-locataire | Deux filiales, onze équipes : la séparation par locataire avec masquage d'existence en 404 est un besoin structurel, pas une option. |
#9.3 Ce qui est inclus
| Inclus | Détail |
|---|---|
| Plan de contrôle complet | Les 16 destinations : état système, flotte d'agents, locataires, utilisateurs & RBAC, gouvernance & séparation des devoirs, budgets & quotas, audit & conformité, drapeaux, modèles & adaptateurs, garde-fous & exécution, registre, agents IA, personnel IA, rôles IA, démonstration, configuration |
| Modèle de rôles plateforme | 3 rôles — viewer, platform_operator, platform_admin — et 16 capacités dont tenants:manage, users:manage, rbac:edit, vault:manage, models:manage, policies:manage, registry:manage, agents:manage réservées à l'administration |
| Preuve d'audit | Journal à chaîne de hachage, GET /audit/verify-chain, recherche par acteur / action / ressource, rapports Loi 25 sur période, export local |
| Contrôle interne | Séparation des devoirs refusée côté serveur — 409 sod/self-approval-forbidden, 422 validation/sod-actor-required — et bloquée en amont côté interface |
| Gestion des accès | Rôles Keycloak par utilisateur, permissions effectives, overrides de permission avec raison obligatoire, révocables |
| Maîtrise des coûts | Budgets par portée avec seuils d'avertissement et critique, fenêtres de quota par modèle, grand livre de crédits, plafond de jetons |
| Sécurité d'exécution | Politiques de garde-fous évaluables à la volée ; politiques d'exécution avec politique réseau devant commencer par deny-, liste d'autorisation de sortie et durée maximale |
| Secrets | Chemins de coffre pour les configurations de modèles et d'adaptateurs — aucune clé en clair dans la configuration |
| Conduite du changement | Drapeaux de fonctionnalité par portée globale ou par locataire, avec déploiement progressif de 0 à 100 % |
| Isolation | Multi-locataire strict, 404 et non 403 sur un locataire étranger |
| Bilinguisme | Français et anglais à parité stricte de 841 clés dans le plan de contrôle |
#9.4 Ce qui n'est pas inclus
| Exclu | Statut réel |
|---|---|
| Conformité automatique | Jamais revendiquée — le produit fournit des preuves, pas une qualification juridique |
| Posture durcie par défaut | AUTH_MODE vaut dev-headers et n'est défini dans aucun manifeste — action de durcissement requise au déploiement |
| Garde de rôle sur le registre d'agents | agent-registry-service n'en a aucune sur ses routes d'agents — écart identifié à corriger |
| Provisionnement automatique de fournisseur d'identité | 🔴 Bloqué — 403 vérifiés sur les droits d'administration du serveur d'identité |
| Suspension de locataire | ⚪ Planifié — absente du service utilisateur |
| Agrégat d'exécutions inter-locataires | ⚪ Planifié — la flotte se lit locataire par locataire |
| File de séparation des devoirs transverse | ⚪ Planifié — les revues se chargent par sujet |
| Relevé de consommation de facturation | 🔴 Bloqué — compteurs codés en dur, à ne pas présenter comme une donnée |
| Clé de chiffrement des identifiants | Provisionnement en attente — sans elle, les nouvelles sauvegardes de facturation échouent en mode fermé |
| Compagnon IA du plan de contrôle | Navigation déterministe seulement, non raccordé à un modèle, message explicite dans l'interface |
| Flux évènementiel en direct du plan de contrôle | Sondage périodique de l'instantané d'activité, pas de flux poussé |
| Client de référence | Aucun à ce jour — aucun témoignage, aucun logo |
| Application mobile | ⚪ Planifié — aucun code mobile dans le dépôt |
#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 | Le plafond de 200 appels d'outil par jour est atteint ; besoin d'une compétence ou d'un outil personnalisé | 25 compétences, 10 outils, 10 rôles, 5 000 appels par jour, plafond N2 |
| Équipe → Entreprise | Un auditeur externe ou un délégué à la protection des renseignements demande une preuve d'intégrité de traces ; besoin de recherche en ligne pour les agents ; volumes au-delà de 5 000 appels par jour ; plusieurs entités à isoler | 1 000 compétences, 500 outils, 200 rôles, 1 000 000 d'appels par jour, recherche en ligne activée, plafond N3 |
| Entreprise → Entreprise durci | Décision du comité de sécurité de passer en posture stricte | AUTH_MODE=jwt, activation du drapeau des rôles virtuels, correction de la garde de rôle du registre d'agents, droits d'administration sur le serveur d'identité |
Essai : 14 jours sans carte, rappels à J-7, J-3 et J-1, rétrogradation vers le palier gratuit à l'expiration — conformément aux profils d'inscription configurés.
#10. Indicateurs de succès pour cette persona
#10.1 À 30 jours
| Indicateur | Cible [Hypothèse] |
Source de mesure réelle |
|---|---|---|
| Vérification de chaîne du journal d'audit exécutée avec succès | ≥ 4 exécutions | GET /api/v1/audit-compliance/audit/verify-chain |
| Locataires créés et distincts pour les entités à isoler | 2 locataires | POST /admin/tenants, GET /organizations (user-service, 4101) |
| Budgets définis avec seuils d'avertissement et critique | ≥ 3 portées couvertes | GET /budgets (billing-usage-service, 4115) |
| Utilisateurs créés avec rôles Keycloak explicitement attribués | 100 % des comptes ouverts | GET /users, POST /keycloak/users/{id}/roles |
| Destinations du plan de contrôle réellement ouvertes par la direction | ≥ 10 des 16 | Journal d'audit — GET /audit/events filtré par acteur |
#10.2 À 60 jours
| Indicateur | Cible [Hypothèse] |
Source de mesure réelle |
|---|---|---|
| Premier rapport Loi 25 généré sur une période complète | 1 rapport | POST /compliance/reports, genre loi25 |
Refus deny-by-default examinés et arbitrés |
100 % | Table app_policy_check, destination policies |
| Overrides de permission portant une raison écrite | 100 % | GET /permissions/overrides (user-service) |
Politiques d'exécution en place avec politique réseau commençant par deny- |
100 % des politiques actives | GET /execution-policies (platform-config, 4112) |
| Agents inscrits au registre central par rapport aux agents déclarés par les équipes | Écart ≤ 5 % | GET /agents/registry (ai-orchestrator, 4106) |
| Drapeaux de fonctionnalité utilisés pour un déploiement progressif d'équipe | ≥ 2 drapeaux avec rollout intermédiaire | GET /feature-flags (platform-config) |
#10.3 À 90 jours
| Indicateur | Cible [Hypothèse] |
Source de mesure réelle |
|---|---|---|
| Délai médian d'instruction d'un incident | −30 % par rapport au point de départ | [Gabarit : mesure de référence du délai d'instruction, à établir en semaine 1 du pilote] |
| Campagne de revue d'accès conduite depuis les permissions effectives | 1 campagne complète | GET /permissions/effective, comparée à l'export d'annuaire |
| Approbations bloquées par la séparation des devoirs | Rapport disponible et non nul | Rejets 409 sod/self-approval-forbidden dans le journal d'audit |
| Portées de dépense d'IA sous budget actif | 100 % des projets actifs | GET /budgets, GET /quota-windows |
| Démonstration d'étanchéité effectuée devant l'auditeur | 1 démonstration réussie | Réponse 404 vérifiée sur un identifiant de locataire étranger |
| Décision de passage en posture durcie prise et documentée | 1 décision consignée | [Gabarit : compte rendu de comité de sécurité actant le passage de AUTH_MODE en mode jwt, à produire par le client] |
#11. Accroches pour cette persona
Six accroches rédigées, avec canal recommandé. Ton : praticien à praticien, vouvoiement, aucun superlatif.
| # | Accroche | Canal recommandé | Intention |
|---|---|---|---|
| A1 | « Trois questions en comité : qui a décidé, qu'a fait l'IA, comment le prouver. » Trois destinations du plan de contrôle y répondent pendant la séance : users pour la décision, fleet pour l'action, audit pour la preuve. |
Article de fond destiné aux publics conformité, repris en note de lecture pour comité de direction | Poser l'angle exact de la persona sans promettre de gain chiffré |
| A2 | « La vitesse de l'IA, avec la traçabilité que l'audit exige. » Journal d'audit à chaîne de hachage, vérification de la chaîne à la demande, rapports Loi 25 sur période. |
Salon ou colloque du secteur public ; documentation d'appel d'offres | Slogan de conformité du brief §2, décliné pour une direction technique |
| A3 | « Votre auditeur peut vérifier lui-même. » Un appel à GET /audit/verify-chain établit l'intégrité du journal. Pas un export, pas une attestation : une vérification. |
Démonstration en direct de 10 minutes, devant l'équipe d'audit interne du prospect | Transformer une promesse en geste vérifiable |
| A4 | « 404, jamais 403. » Un identifiant de locataire en désaccord avec le jeton ne reçoit pas « accès refusé ». Il reçoit « cela n'existe pas ». Votre filiale ne peut même pas déduire l'existence des données de l'autre. |
Publication technique destinée aux responsables sécurité du secteur financier | Adresser la preuve de non-fuite entre entités, argument d'audit |
| A5 | « Personne n'approuve sa propre demande. Le serveur refuse. » 409 sur l'auto-approbation, 422 si l'acteur n'est pas déclaré. La règle n'est pas une consigne interne : c'est un comportement de la plateforme. |
Courriel de séquence destinée aux directions techniques, message 2 sur 5 | Adresser la séparation des devoirs opposable |
| A6 | « Nous ne promettons pas la conformité automatique. Nous fournissons la preuve. » Ce que nous livrons non durci, nous le disons : AUTH_MODE vaut dev-headers par défaut et le durcissement est une action d'exploitation. Nous préférons que vous l'appreniez de nous. |
Page produit, section « Ce que nous ne faisons pas » ; reprise en réunion d'avant-vente avec l'équipe sécurité | Construire la confiance par la limite assumée — différenciateur D5 du brief |
#12. Ce que nous refusons de dire à cette persona
| Formulation interdite | Pourquoi |
|---|---|
| « Conformité automatique » | Jamais revendiquée (brief §7) ; la qualification juridique appartient au client |
| « Notre plateforme est durcie par défaut » | Faux : AUTH_MODE vaut dev-headers et n'est défini dans aucun manifeste |
| « Tous nos services appliquent un contrôle de rôle » | Faux : agent-registry-service n'a aucune garde de rôle sur ses routes d'agents |
| « Nous nous connectons automatiquement à votre annuaire » | Le provisionnement automatique de fournisseur d'identité est 🔴 Bloqué |
| « Suspendez un locataire en un clic » | La suspension de locataire est absente du service utilisateur |
| « Voici la consommation réelle de vos équipes » | Les compteurs de GET /billing/usage sont codés en dur |
| « Nos clients constatent… » | Aucun témoignage n'existe (brief §15) |
| « Vue consolidée de toutes vos entités » | L'agrégat d'exécutions inter-locataires est Planifié |
| « Multipliez la productivité de vos onze équipes » | Aucun gain de productivité chiffré n'est revendiqué (brief §7) |
| « Notre application mobile pour la direction » | Aucun code mobile n'existe dans le dépôt |
| « Le meilleur plan de contrôle du marché » | Superlatif creux (brief §12) |
| « Portail business » | Il n'existe pas de troisième portail |
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.