#0. Résumé en dix lignes
| Élément | Contenu |
|---|---|
| Persona | Ops / SRE / DevOps — persona n° 8 du brief commun (§9) |
| Douleur dominante | Déploiements sans traçabilité de décision |
| Ce que KySpectra apporte | Une machine à états de livraison non contournable, une approbation humaine attribuable, un retour arrière enregistré, et des agents IA confinés dans un espace de noms d'exécution séparé |
| Surfaces concernées | Portail client — vue delivery, vue agentops, page /approvals, page /usage · Plan de contrôle — /fleet, /budgets, /flags, /policies, /overview |
| Services réels sollicités | deploy-service (4121), agent-runtime-service (4119), platform-config-service (4112), billing-usage-service (4115), observability-board-service (4114), dependency-graph-service (4117) |
| Offre recommandée | Palier Équipe [Hypothèse] pour une équipe plateforme de 3 à 25 personnes ; Entreprise dès qu'un régulateur entre dans la conversation |
| Ce qu'on ne promet pas | Un pilote natif Azure Container Apps, Cloud Run ou ECS ; un remplacement de votre supervision ; une conformité automatique |
| Statut de la chaîne | Rollout Kubernetes Livré et prouvé en production ; pilotes nuage natifs Planifiés ; isolation dure des agents Livrée mais désactivée par défaut (RUNTIME_EXECUTOR=inline) |
| Preuve la plus parlante | Un produit tiers construit, publié et servi sur un sous-domaine avec TLS, avec rollout ré-interrogé jusqu'à convergence — prouvé en production |
| Risque d'adoption | La personne possède déjà un outillage de livraison mûr ; KySpectra doit s'y insérer, pas le remplacer — et cela doit être dit au premier échange |
#1. Portrait
Sacha, 38 ans, ingénieur·e de fiabilité de site dans une entreprise de services financiers de 900 personnes, dont 140 en technologie. Iel est arrivé·e il y a cinq ans comme administrateur·rice système, et a vu l'organisation passer de trois machines virtuelles nommées d'après des planètes à deux grappes Kubernetes, un catalogue de 60 services et une équipe plateforme de six personnes dont iel est la référence technique.
Iel n'aime pas le mot « DevOps ». Iel dit « exploitation », et iel le dit sans complexe. Ce qu'iel défend, ce n'est pas un outil : c'est une propriété. Tout ce qui atteint la production doit être explicable après coup. Iel a vécu trois post-mortems où la question « qui a lancé ça, et sur la foi de quelle décision ? » n'a jamais trouvé de réponse écrite. À chaque fois, la réunion s'est terminée par une consigne d'équipe. À chaque fois, la consigne a tenu six semaines.
Depuis dix-huit mois, une nouveauté l'inquiète : des agents IA ont commencé à écrire du code, à ouvrir des demandes de tirage, et parfois à toucher à l'infrastructure. Personne dans l'organisation n'est capable de produire la liste exhaustive de ce qu'un agent a le droit de faire.
#1.1 Sa journée réelle
Iel arrive vers 8 h 30, ouvre la console de supervision avant sa messagerie. Iel consacre en moyenne 40 % de sa semaine à des demandes entrantes — un déploiement à passer, un accès à ouvrir, un secret à faire tourner, une alerte à interpréter. Le reste va au travail de fond : correctifs de grappe, capacité, plans de reprise. Le travail de fond est toujours le premier sacrifié.
#1.2 Sa boîte à outils actuelle
| Catégorie | Ce qu'iel utilise aujourd'hui |
|---|---|
| Orchestration | Deux grappes Kubernetes, l'une gérée, l'autre sur matériel propre |
| Livraison continue | Un moteur d'intégration continue de la forge, plus des scripts maison hérités |
| Infrastructure comme code | Modules de provisionnement, dépôt séparé, revue à deux |
| Secrets | Un coffre d'entreprise, un mécanisme d'injection par agent latéral, et — honnêtement — quelques fichiers d'environnement qui traînent |
| Supervision | Métriques, journaux centralisés, traces, alertes de garde |
| Astreinte | Rotation de six personnes, une semaine sur six |
| Communication | Messagerie d'équipe, canal d'incidents, un fil « déploiements » que personne ne relit |
#1.3 Ce qui le fait juger — par ses pairs et par sa hiérarchie
- Le délai moyen de rétablissement après incident, et sa dispersion.
- Le taux d'échec des changements : combien de déploiements provoquent un retour arrière.
- La capacité de l'équipe de développement à livrer sans passer par iel.
- Le nombre d'alertes qui réveillent quelqu'un pour rien.
- La tenue devant l'audit interne : pouvoir produire, sur demande, qui a approuvé quoi.
#1.4 Ce qui l'empêche de dormir
- Le déploiement sans trace. Quelqu'un a poussé quelque chose un vendredi ; il n'existe aucun enregistrement de la décision.
- Le retour arrière qui n'a jamais été répété. On sait qu'il existe. On ne sait pas s'il fonctionne sous pression.
- L'agent qui a un jeton trop large. Un jeton d'accès à la grappe posé dans une variable d'environnement, il y a huit mois, par une personne partie depuis.
- La sonde de vivacité couplée à la base de données. Une base lente fait redémarrer les pods, et un service à réplique unique devient une panne complète.
- La question du régulateur. « Montrez-moi la liste des actions autorisées à vos agents IA. » Iel n'a pas cette liste.
Sa phrase à lui·elle, telle qu'iel la dirait en entretien : « Je ne cherche pas à déployer plus vite. Je cherche à pouvoir dire, six mois après, qui a décidé quoi et ce que la machine a réellement fait. »
#2. Douleurs — mécanisme de coût et fréquence
Chaque douleur est décrite avec le mécanisme par lequel elle coûte (temps perdu, risque encouru, décision retardée) et sa fréquence observée.
| # | Douleur | Mécanisme de coût | Fréquence |
|---|---|---|---|
| D1 | Déploiement sans décision enregistrée. Le pipeline dit qui a poussé, jamais qui a autorisé. | Risque encouru : impossible de reconstituer la chaîne de responsabilité en post-mortem ou en audit. Temps perdu : reconstitution manuelle à partir de journaux hétérogènes, plusieurs heures par incident. | À chaque déploiement en production — 10 à 40 par semaine |
| D2 | Étapes de livraison contournables. Un scan raté se contourne « exceptionnellement », puis l'exception devient la règle. | Risque encouru : vulnérabilité connue mise en production. Décision retardée : chaque exception rouvre un débat d'équipe. | 2 à 5 contournements par mois |
| D3 | Retour arrière non répété et non tracé. On sait qu'on peut revenir en arrière ; personne ne sait combien de temps ça prend ni ce que ça laisse derrière. | Risque encouru : rétablissement plus long que prévu, sous stress. Temps perdu : improvisation en pleine astreinte. | 1 à 3 fois par trimestre |
| D4 | File de demandes de déploiement. Les équipes produit ne déploient pas : elles demandent. | Temps perdu : 40 % de la semaine de l'équipe plateforme en interruptions. Décision retardée : de quelques heures à plusieurs jours pour les équipes demandeuses. | Quotidien |
| D5 | Pipelines divergents entre projets. Chaque service a son fichier, copié puis modifié à la main. | Temps perdu : une demi-journée à une journée par nouveau service. Risque : dérive silencieuse — un service n'exécute plus le scan de secrets et personne ne s'en aperçoit. | À chaque nouveau service — 8 à 15 par an |
| D6 | Agents IA sans périmètre d'exécution. Un agent tourne avec les mêmes droits que le service qui l'invoque. | Risque encouru : action non désirée sur la grappe, sur un dépôt, sur un secret. Décision retardée : la direction refuse d'élargir l'usage faute de garanties. | Permanent — c'est une posture, pas un incident |
| D7 | Secrets sans cycle de vie. Rotation manuelle, propriétaire inconnu, expiration jamais vérifiée. | Risque encouru : fuite, jeton non révoqué après un départ, audit défavorable. | Chaque nouvelle intégration externe — 1 à 2 par mois |
| D8 | Sondes de santé couplées à la base de données. La sonde de vivacité interroge la base ; une base lente fait redémarrer des pods sains. | Risque encouru : indisponibilité auto-infligée, amplifiée sur les services à réplique unique. Temps perdu : diagnostic d'incident qui accuse le mauvais composant. | 1 à 2 fois par trimestre, plus souvent en période de charge |
| D9 | Consommation d'IA sans plafond. Aucune limite par périmètre, aucune alerte avant la facture. | Risque encouru : dépassement budgétaire découvert en fin de mois. Décision retardée : gel de l'usage par précaution, donc valeur perdue. | Mensuel |
| D10 | Bascule de fonctionnalité par redéploiement. Activer ou désactiver un comportement suppose de repasser le pipeline. | Temps perdu : 20 à 60 minutes par bascule. Risque : on préfère ne pas toucher, donc on garde un comportement dégradé plus longtemps. | Hebdomadaire |
| D11 | Accès administrateur permanent aux machines. Des clés SSH de longue durée dorment dans des postes de travail. | Risque encouru : surface d'attaque permanente, révocation incertaine. | Permanent |
| D12 | Impossible de dire ce qui dépend de quoi. Avant une opération de maintenance, personne ne connaît la liste réelle des consommateurs. | Décision retardée : fenêtres de maintenance surdimensionnées « par précaution ». Risque : coupure d'un consommateur oublié. | À chaque maintenance planifiée — mensuel |
#3. Réponse produit — uniquement des fonctionnalités réelles
Règle appliquée : chaque ligne cite la surface du portail ou le service réel, avec sa route. Une douleur sans réponse aujourd'hui est signalée telle quelle, avec le statut Planifié.
| Douleur | Fonctionnalité KySpectra qui y répond | Où c'est dans le produit | Statut | Ce que ça change concrètement |
|---|---|---|---|---|
| D1 Déploiement sans décision | Approbation humaine attribuable avant rollout, avec séparation des devoirs : l'approbateur ne peut pas être le demandeur | deploy-service (4121) — POST /api/v1/deploy/deploy-runs/{id}/approve (rôle ADMIN), refus 409 deploy/approval-self ; piste d'audit GET …/deploy-runs/{id}/approvals ; portail : /approvals |
🟢 Livré | La décision devient une ligne en base — app_deploy_approval — avec approved_by, requested_by et reason. Le post-mortem a une source. |
| D1 Déploiement sans décision | Journal d'audit à chaîne de hachage couvrant les actions de plateforme, avec vérification de chaîne | audit-compliance-service (4113) ; plan de contrôle : page /audit, bouton de vérification de chaîne |
🟢 Livré | Un journal dont on peut prouver qu'il n'a pas été retouché, pas seulement consulté. |
| D2 Étapes contournables | Machine à états de livraison ordonnée et non contournable : build → test → scan → gate → deploy → monitor |
deploy-service — POST /api/v1/deploy/deploy-runs crée le run et amorce les six étapes ; avancement hors ordre refusé en 409 gate/out-of-order ; déploiement sans portes franchies refusé en 409 gate/not-passed ; l'étape deploy ne se marque jamais à la main (409 deploy/via-deploy-endpoint) |
🟢 Livré | Le contournement n'est plus une question de discipline d'équipe : il est refusé par le serveur. |
| D2 Étapes contournables | Scan réel à trois dimensions — analyse statique, dépendances, secrets — et refus honnête si un scanner manque | deploy-service — étape scan : bandit, pip-audit, gitleaks ; outil absent ⇒ 501 nommant les scanners manquants, jamais un vert fabriqué |
🟢 Livré | Vous ne recevez jamais un feu vert produit par un scanner qui n'a pas tourné. |
| D3 Retour arrière non tracé | Retour arrière enregistré, rattaché au déploiement d'origine | deploy-service — POST /api/v1/deploy/deployments/{id}/rollback (rôle ADMIN) ; l'original passe à rolled_back, une nouvelle ligne porte rollback_of |
🟢 Livré | Le retour arrière devient un objet daté et relié, répétable et mesurable. |
| D3 Retour arrière non tracé | Rollout ré-interrogé : l'état n'est « en ligne » que si la grappe le confirme | deploy-service — après application de l'image, relecture de l'état du workload ; convergence exigée : ready == updated == available == desired |
🟢 Livré — prouvé en production | Fini le « déployé » qui signifie seulement « la commande est passée ». |
| D4 File de demandes | Plan de déploiement en simulation : cible résolue, portes non franchies, approbation requise, obstacles listés — sans rien exécuter | deploy-service — POST /api/v1/deploy/deploy-runs/{id}/plan (rôle PUBLISHER), aucune infrastructure touchée, aucune écriture |
🟢 Livré | L'équipe produit voit elle-même ce qui bloque, au lieu d'ouvrir un ticket pour le demander. |
| D4 File de demandes | Mise en ligne sur sous-domaine avec TLS, rendue et appliquée par la plateforme | deploy-service — POST /api/v1/deploy/go-live/{project_id} (rôle PUBLISHER) ; rend et applique Deployment + Service + Ingress ; drapeau GOLIVE_ENABLED, défaut false ⇒ 501 honnête |
🟢 Livré — prouvé en production | L'exploitation cesse d'être le goulot d'étranglement du premier déploiement. |
| D5 Pipelines divergents | Génération de pipeline pour quatre fournisseurs — GitHub Actions, GitLab CI, Azure Pipelines, Jenkins | deploy-service — POST /api/v1/deploy/cicd/generate (rôle EDITOR) |
🟢 Livré | Un gabarit unique, régénérable, au lieu de quinze fichiers dérivés. |
| D5 Pipelines divergents | Commit réel du pipeline dans le dépôt | deploy-service — POST /api/v1/deploy/cicd/setup (rôle PUBLISHER), renvoie le commit_sha |
🟢 Livré — prouvé en développement | Le fichier arrive chez vous, pas dans un écran de notre produit. Limite assumée : côté commit, seules les forges Gitea et GitHub sont supportées ; GitLab est déclaré non supporté et renvoie une erreur typée. |
| D5 Pipelines divergents | Déclencheurs d'intégration continue externes depuis KySpectra | — | ⚪ Planifié — n'existe pas aujourd'hui | À dire franchement : vous relancez vos pipelines depuis votre forge, pas depuis notre produit. |
| D6 Agents sans périmètre | Moteur de politique en liste d'autorisations hors boucle : toute action non couverte est refusée et journalisée | agent-runtime-service (4119) — verdicts persistés dans app_policy_check ; refus explicites documentés : déploiement en production, suppression par interpréteur de commandes, sortie réseau, écriture hors espace de travail, prise de bail de secret |
🟢 Livré | Vous pouvez enfin produire la liste demandée par le régulateur : c'est une configuration, pas une intention. |
| D6 Agents sans périmètre | Espace de noms d'exécution séparé pour les agents, avec durcissement de pod | agent-runtime-service — espace de noms d'exécution distinct de celui de l'application, exécution non-root, système de fichiers racine en lecture seule, toutes les capacités retirées, élévation de privilège interdite, profil seccomp par défaut, restartPolicy: Never |
🟢 Livré | Un agent qui déraille reste dans une boîte, et la boîte n'est pas votre espace applicatif. |
| D6 Agents sans périmètre | Liste d'autorisation de sortie réseau réduite à la passerelle de modèles | agent-runtime-service — une seule route externe autorisée pour les tâches d'exécution |
🟢 Livré | La question « où mon agent peut-il appeler ? » a une réponse d'une ligne. |
| D6 Agents sans périmètre | Honnêteté sur l'isolation dure | agent-runtime-service — RUNTIME_EXECUTOR vaut inline par défaut, et le manifeste de déploiement de l'environnement de développement le fixe explicitement à inline : dans cette configuration, il n'y a pas d'isolation conteneur/réseau dure |
🟡 En cours d'activation — le mécanisme par tâche Kubernetes éphémère est livré et testé ; son activation est une opération d'exploitation | Nous ne prétendons pas que l'isolation dure est active partout. Elle se déclenche en changeant un réglage, sous votre contrôle. |
| D6 Agents sans périmètre | Interruption, suspension et reprise d'un run ; flux d'activité rejouable | agent-runtime-service — POST /api/v1/agent-runtime/runs/{id}/interrupt, …/suspend, …/resume, …/checkpoints ; flux d'événements rejouable depuis la table app_activity_event avec reprise par Last-Event-ID ; plan de contrôle : /fleet avec confirmation avant interruption |
🟢 Livré | On peut arrêter un agent en cours et rejouer exactement ce qu'il a fait. |
| D7 Secrets sans cycle de vie | Dépôt de secret au coffre, par référence uniquement | deploy-service — POST /api/v1/deploy/credentials/deposit (rôle EDITOR) : la valeur est écrite au coffre puis oubliée ; la réponse ne contient jamais la valeur, seulement la référence et la version ; 503 si le coffre n'est pas configuré, sans repli |
🟢 Livré — prouvé en développement et en production | Ce qui circule dans vos configurations, ce sont des chemins de coffre, pas des jetons. |
| D7 Secrets sans cycle de vie | Rejet des secrets en clair dans la configuration d'outils | extension-registry-service (4116) — la base ne stocke jamais de secret ; noms de secret interdits, en-têtes d'authentification interdits, détection de valeur secrète ⇒ 422 registry/tool-auth-secret ; référence obligatoire sinon 422 registry/tool-auth-missing-ref |
🟢 Livré | Le produit refuse activement de devenir un nouvel endroit où traînent des clés. |
| D8 Sondes couplées | Sonde de vivacité distincte de la sonde de disponibilité sur les services qui l'exposent | reverse-engineering-service — GET /health/live (processus seul) et GET /health (interrogation de base, 503 health/db-unavailable si indisponible) |
🟡 En cours — le motif existe mais n'est pas uniforme : plusieurs services n'exposent qu'un /health couplé à la base |
À dire honnêtement : c'est un chantier d'uniformisation identifié, pas une propriété acquise sur l'ensemble du catalogue. |
| D8 Sondes couplées | Agrégat de santé honnête, avec exclusion explicite des services non déployés | api-gateway (4100) — /health/aggregate ; un service marqué comme exclu ne fait pas basculer l'agrégat en dégradé ; plan de contrôle : page /overview |
🟢 Livré | Le tableau de santé ne crie pas au loup parce qu'un service gabarit est absent. |
| D9 Consommation sans plafond | Budgets par périmètre avec seuils d'avertissement et seuil critique, et fenêtres de quota | billing-usage-service (4115) — GET/POST /budgets, PATCH/DELETE /budgets/{id}, GET /quota-windows ; plan de contrôle : page /budgets avec jauges dépensé / restant / pourcentage ; portail client : /usage |
🟢 Livré | Le dépassement se voit avant la facture, à l'échelle du périmètre que vous choisissez. |
| D9 Consommation sans plafond | Reçu honnête : sans service de facturation joignable, aucun montant n'est inventé | Garde de crédit partagée — le reçu porte metered=false avec la raison, jamais un montant fabriqué |
🟢 Livré | Vous ne construisez pas votre refacturation interne sur une valeur devinée. |
| D10 Bascule par redéploiement | Drapeaux de fonctionnalité avec portée globale ou par locataire et pourcentage de déploiement progressif | platform-config-service (4112) — GET/POST /feature-flags, PATCH/DELETE /feature-flags/{id} ; plan de contrôle : page /flags, activation/désactivation, édition du pourcentage et de la description |
🟢 Livré | Une bascule devient une opération de quelques secondes, réversible, tracée. |
| D11 Accès permanent | Sessions bastion à certificat SSH de courte durée, signé par le coffre | deploy-service — POST /api/v1/deploy/bastion-sessions (rôle ADMIN) : certificat renvoyé une seule fois, jamais persisté ; la table de session ne contient aucune colonne secrète ; lecture ultérieure : métadonnées seules |
🟢 Livré | L'accès machine devient une session datée et expirante, pas une clé qui dort. |
| D11 Accès permanent | Politiques d'exécution : politique réseau devant commencer par un refus, liste d'autorisation de sortie, durée maximale, politique de système de fichiers | platform-config-service — politiques d'exécution ; plan de contrôle : page /policies |
🟢 Livré | La posture réseau des exécutions est déclarée et vérifiable, pas implicite. |
| D12 Dépendances inconnues | Graphe de dépendances avec arêtes sourcées : chaque arête porte une origine et une preuve non vides, imposées en base | dependency-graph-service (4117) — traversées, détection de cycles, simulation de rayon d'impact, instantanés immuables, comparaison d'instantanés |
🟢 Livré | Avant une maintenance, la liste des consommateurs est une requête, pas un sondage sur la messagerie. |
| D12 Dépendances inconnues | Scan de vulnérabilités et verdicts de licence sur les composants externes | dependency-graph-service — ingestion de nomenclature logicielle, scan de dépendances, vulnérabilités, licences ; scan désactivé ⇒ verdict unknown explicite, jamais un ok fabriqué |
🟢 Livré | Le verdict « je ne sais pas » est affiché comme tel. |
| Attente non couverte | Pilotes nuage natifs — Azure Container Apps, Cloud Run, ECS | — | ⚪ Planifié — seul le mécanisme générique « interface en ligne de commande nuage dans une tâche éphémère » est prouvé, avec un déploiement AWS réel | Ne jamais présenter les pilotes natifs comme disponibles. |
| Attente non couverte | Remplacement de votre supervision — métriques, journaux, traces, alertes | — | ⚪ Hors périmètre assumé | KySpectra affiche un tableau de bord de plateforme et des brèches de niveau de service ; il ne remplace ni votre collecte de métriques ni votre gestion d'astreinte. |
| Attente non couverte | Enregistrement DNS créé par hôte à la mise en ligne | Le client d'interface DNS existe et est testé, mais il n'est pas branché : la mise en ligne repose aujourd'hui sur un enregistrement générique préexistant sur la zone | 🟡 En cours | À dire au premier échange technique : la gestion DNS par hôte n'est pas automatisée aujourd'hui. |
#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. Elles servent à structurer une conversation de valeur, jamais à être publiées comme un résultat. La colonne « Comment le mesurer » indique la source de mesure réelle et disponible dans le produit.
#4.1 Avant KySpectra
| Jour | Activité dominante | Temps typique | Frottement |
|---|---|---|---|
| Lundi | Tri des demandes de déploiement accumulées le week-end, revue de la file | 2 h 30 | Chaque demande exige un aller-retour pour comprendre le contexte |
| Mardi | Mise en place d'un nouveau service : pipeline, secrets, espace de noms, sondes | 5 h | Copier-coller de pipeline, secret transmis à la main |
| Mercredi | Incident : redémarrages en boucle sur un service à réplique unique | 3 h de diagnostic, 1 h de correction | La sonde de vivacité accuse le mauvais composant |
| Jeudi | Revue de sécurité d'un agent IA demandée par la conformité | 2 h à reconstituer ce que l'agent a le droit de faire | Aucune liste d'autorisations centralisée |
| Vendredi | Fenêtre de maintenance sur une base partagée | 2 h de fenêtre, dont 1 h de marge « au cas où » | Liste des consommateurs inconnue |
#4.2 Après KySpectra
| Jour | Ce qui change | Heures déplacées [Hypothèse] |
Comment le mesurer |
|---|---|---|---|
| Lundi | Les équipes lancent elles-mêmes POST /api/v1/deploy/deploy-runs/{id}/plan et voient leurs obstacles ; Sacha n'arbitre que les approbations |
−1 h 30 sur la file | Nombre d'appels de plan par équipe ; délai médian entre demande et décision dans GET …/deploy-runs/{id}/approvals |
| Mardi | Pipeline généré par POST /api/v1/deploy/cicd/generate et commité par …/cicd/setup ; secret déposé par …/credentials/deposit |
−3 h sur la mise en place | Nombre de pipelines générés ; nombre de dépôts de secret réussis, avec version renvoyée |
| Mercredi | Séparation des sondes là où elle est en place, et agrégat de santé qui ignore les services exclus | −1 h de diagnostic | Écarts entre /health/live et /health ; page /overview du plan de contrôle |
| Jeudi | La liste des actions autorisées aux agents est une configuration exportable ; les refus sont dans app_policy_check |
−1 h 30 de reconstitution | Nombre de refus deny-by-default examinés ; page /policies |
| Vendredi | Liste des consommateurs obtenue par traversée du graphe de dépendances avant la fenêtre | −45 min de marge | Requêtes de traversée et simulations de rayon d'impact sur dependency-graph-service |
#4.3 Bilan hebdomadaire
| Poste | Avant | Après [Hypothèse] |
Écart [Hypothèse] |
|---|---|---|---|
| Traitement de la file de déploiement | 2 h 30 | 1 h 00 | −1 h 30 |
| Mise en place de service (amortie sur 4 semaines) | 1 h 15 / sem. | 0 h 30 / sem. | −0 h 45 |
| Diagnostic d'incident lié aux sondes | 1 h 00 / sem. (moyenne lissée) | 0 h 30 / sem. | −0 h 30 |
| Réponse aux demandes de conformité sur les agents | 0 h 30 / sem. (moyenne lissée) | 0 h 10 / sem. | −0 h 20 |
| Marge de fenêtre de maintenance | 0 h 45 | 0 h 15 | −0 h 30 |
| Total déplacé | — | — | ≈ 3 h 35 par semaine et par personne d'exploitation [Hypothèse] |
Honnêteté sur le chiffre. Ces 3 h 35 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).
[Gabarit : mesure réelle du temps passé en file de déploiement avant/après, à collecter auprès d'au moins deux équipes plateforme pilotes]
#5. Valeur créée
#5.1 Valeur qualitative
| Dimension | Ce qui change pour Sacha |
|---|---|
| Défendabilité | Iel peut répondre « voici l'enregistrement de la décision » au lieu de « je vais chercher ». |
| Réversibilité | Le retour arrière devient un objet relié au déploiement d'origine, donc mesurable et répétable. |
| Confinement | Les agents IA cessent d'être une zone grise : périmètre déclaré, espace de noms séparé, sortie réseau restreinte. |
| Délégation | Les équipes produit avancent seules jusqu'à la porte d'approbation, au lieu d'attendre l'exploitation à chaque étape. |
| Prévisibilité budgétaire | Les seuils d'avertissement précèdent la facture, à l'échelle du périmètre choisi. |
| Honnêteté d'outil | Un scanner absent produit un refus explicite, pas un feu vert. C'est ce qui rend le tableau de bord digne de confiance. |
#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 d'exploitation récupéré sur la file de déploiement
GAIN_FILE = O × H_file × R × S
| Variable | Signification | Valeur de travail |
|---|---|---|
O |
Personnes en exploitation concernées | 6 [Hypothèse] |
H_file |
Heures hebdomadaires passées sur la file avant | 2,5 h [Hypothèse], §4.3 |
R |
Part récupérée par le plan en simulation et l'approbation déléguée | 0,6 [Hypothèse], §4.3 |
S |
Semaines travaillées par an | 44 [Hypothèse] |
Application : 6 × 2,5 × 0,6 × 44 = 396 heures-personnes par an [Hypothèse].
#Formule 2 — Coût évité de mise en place de service
GAIN_SETUP = N_services × (H_avant − H_apres)
| Variable | Signification | Valeur de travail |
|---|---|---|
N_services |
Nouveaux services par an | 10 [Hypothèse] |
H_avant |
Heures de mise en place manuelle — pipeline, secrets, espace de noms | 5 h [Hypothèse] |
H_apres |
Heures avec génération de pipeline et dépôt de secret | 1,5 h [Hypothèse] |
Application : 10 × (5 − 1,5) = 35 heures-personnes par an [Hypothèse].
#Formule 3 — Valeur du retour arrière tracé
VALEUR_ROLLBACK = F_rollback × (T_avant − T_apres) × C_heure_indispo
| Variable | Signification | Valeur de travail |
|---|---|---|
F_rollback |
Retours arrière par an | [Gabarit : nombre de retours arrière par an, à extraire du gestionnaire d'incidents du client] |
T_avant |
Durée moyenne du rétablissement improvisé | [Gabarit : durée moyenne de rétablissement actuelle] |
T_apres |
Durée avec un retour arrière enregistré et répété | [Gabarit : durée à mesurer en pilote] |
C_heure_indispo |
Coût horaire d'indisponibilité du service concerné | [Gabarit : coût horaire d'indisponibilité, à établir avec le client] |
Interdiction assumée. Tant que ces quatre variables ne sont pas fournies par le client, cette formule ne produit aucun chiffre publiable. On la présente vide, on la remplit ensemble.
#Formule 4 — Dérive budgétaire évitée sur la consommation d'IA
GAIN_BUDGET = D_mensuelle × T_detection × 12
| Variable | Signification | Valeur de travail |
|---|---|---|
D_mensuelle |
Dépassement mensuel moyen constaté a posteriori | [Gabarit : dépassement mensuel moyen, à extraire des factures des 6 derniers mois] |
T_detection |
Part du dépassement évitable grâce aux seuils d'avertissement | 0,5 [Hypothèse] |
Sans
D_mensuellefourni par le client, aucun montant n'est publié.
#Formule 5 — Coût de la plateforme, à mettre en regard
COUT_ANNUEL = U × P_mensuel × 12
Avec U = utilisateurs et P_mensuel = 49 $ CAD [Hypothèse] — montant réellement présent dans le catalogue de plans en base (slug = team, 4 900 cents, devise CAD ; annuel 49 000 cents). Pour une équipe plateforme de 6 personnes : 6 × 49 × 12 = 3 528 $ CAD par an [Hypothèse].
Précision obligatoire. La modalité « par utilisateur » est une hypothèse de travail ; la base contient un prix mensuel de plan, pas une tarification par siège arrêtée. À valider par le propriétaire avant toute publication (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, ingénieur·e de fiabilité de site
#Tâches à accomplir
| Type | Tâche | Intensité |
|---|---|---|
| Fonctionnelle | Amener un changement en production sans casser le service | Quotidienne |
| Fonctionnelle | Rétablir un service après incident, le plus vite possible | Mensuelle |
| Fonctionnelle | Ouvrir et refermer des accès machine | Hebdomadaire |
| Fonctionnelle | Faire tourner des secrets et prouver la rotation | Mensuelle |
| Fonctionnelle | Répondre à une demande d'audit interne sur une action passée | Trimestrielle |
| Fonctionnelle | Tenir la capacité et le budget d'infrastructure | Mensuelle |
| Sociale | Être la personne qui dit non sans être perçue comme un frein | Continue |
| Sociale | Rendre les équipes produit autonomes sans perdre le contrôle | Continue |
| Émotionnelle | Dormir pendant sa semaine d'astreinte | Continue |
| Émotionnelle | Ne pas découvrir un accès oublié six mois après un départ | Continue |
#Frustrations
| Frustration | Sévérité |
|---|---|
| Décisions de déploiement non enregistrées | Élevée |
| Exceptions de pipeline devenues coutume | Élevée |
| Retour arrière jamais répété | Élevée |
| Interruptions permanentes par la file de demandes | Élevée |
| Agents IA sans périmètre déclaré | Élevée |
| Secrets sans propriétaire ni expiration | Élevée |
| Redémarrages auto-infligés par une sonde mal conçue | Moyenne |
| Facture d'IA découverte en fin de mois | Moyenne |
| Fenêtres de maintenance surdimensionnées | Moyenne |
#Attentes et gains recherchés
| Gain attendu | Nature |
|---|---|
| Une décision d'approbation attribuable, consultable | Défendabilité |
| Une chaîne de livraison qu'on ne peut pas contourner « juste cette fois » | Réduction de risque |
| Un retour arrière qu'on a déjà vu fonctionner | Prévisibilité |
| Des équipes qui avancent seules jusqu'à la porte | Récupération de temps |
| Une liste écrite de ce que les agents ont le droit de faire | Conformité |
| Une alerte de budget avant la facture | Maîtrise des coûts |
| Savoir qui dépend de quoi avant de couper | Sérénité de maintenance |
#7.2 Carte de valeur — KySpectra
#Produits et services proposés
| Élément | Surface réelle | Statut |
|---|---|---|
| Chaîne de livraison gouvernée à six étapes | deploy-service — runs, étapes, portes ; portail : vue delivery |
🟢 Livré |
| Approbation humaine et piste d'audit d'approbation | /approvals du portail client ; …/deploy-runs/{id}/approvals |
🟢 Livré |
| Mise en ligne sur sous-domaine avec TLS | POST /api/v1/deploy/go-live/{project_id} |
🟢 Livré — prouvé en production |
| Retour arrière enregistré | POST /api/v1/deploy/deployments/{id}/rollback |
🟢 Livré |
| Plan de contrôle d'exploitation | Portail administration — /overview, /fleet, /budgets, /flags, /policies, /audit |
🟢 Livré |
| Politique d'exécution des agents et espace de noms séparé | agent-runtime-service |
🟢 Livré (activation de l'isolation dure : opération d'exploitation) |
| Coffre de secrets par projet | POST /api/v1/deploy/credentials/deposit ; portail : /credentials |
🟢 Livré |
| Sessions bastion à certificat court | POST /api/v1/deploy/bastion-sessions |
🟢 Livré |
| Graphe de dépendances, nomenclature logicielle, licences | dependency-graph-service |
🟢 Livré |
| Pilotes nuage natifs | — | ⚪ Planifié |
| DNS par hôte à la mise en ligne | — | 🟡 En cours |
| Application mobile pour l'astreinte | — | ⚪ Planifié — aucun code mobile dans le dépôt |
#Solutions aux problèmes
| Frustration visée | Mécanisme produit qui la traite |
|---|---|
| Décisions non enregistrées | Table d'approbation avec demandeur, approbateur, motif ; refus 409 si l'approbateur est le demandeur |
| Exceptions devenues coutume | Refus serveur 409 gate/out-of-order et 409 gate/not-passed ; l'étape de déploiement ne se marque jamais à la main |
| Retour arrière jamais répété | Retour arrière comme opération de première classe, reliée au déploiement d'origine |
| Interruptions permanentes | Plan en simulation, sans effet de bord, exécutable par l'équipe demandeuse |
| Agents sans périmètre | Liste d'autorisations explicite, refus journalisés, espace de noms d'exécution séparé, sortie réseau restreinte |
| Secrets sans propriétaire | Dépôt au coffre par référence, 503 sans coffre plutôt qu'un repli silencieux |
| Redémarrages auto-infligés | Sonde de vivacité distincte là où elle est déployée, agrégat de santé qui exclut les services non déployés |
| Facture découverte trop tard | Budgets avec seuils d'avertissement et seuil critique, fenêtres de quota |
| Maintenance à l'aveugle | Traversées de graphe, cycles, simulation de rayon d'impact |
#Créateurs de gains
| Gain recherché | Créateur de gain KySpectra |
|---|---|
| Défendre une action passée | Journal d'audit à chaîne de hachage avec vérification, et rapports de conformité sur période |
| Ne jamais croire un faux vert | Refus 501 typé quand un outil manque, plutôt qu'un succès fabriqué |
| Déléguer sans perdre la main | Séparation des devoirs appliquée par le serveur, pas par une consigne |
| Confiner l'IA | Espace de noms d'exécution séparé, pod non-root, racine en lecture seule, capacités retirées, sortie réseau sur liste d'autorisation |
| Piloter la dépense | Budgets par périmètre, seuils, fenêtres de quota, reçu honnête |
| Rendre la grappe lisible | Graphe à arêtes sourcées, chaque arête portant une origine et une preuve |
#7.3 Évaluation d'adéquation
| Tâche / frustration | Réponse produit | Niveau d'adéquation | Commentaire |
|---|---|---|---|
| Enregistrer une décision de déploiement | Approbation attribuable + piste d'audit | Fort | Livré, appliqué côté serveur |
| Empêcher le contournement d'étape | Machine à états ordonnée | Fort | Livré, refus typés |
| Déployer sur Kubernetes | Rollout ré-interrogé, mise en ligne, retour arrière | Fort | Prouvé en production |
| Déployer hors Kubernetes | Mécanisme générique par interface en ligne de commande nuage | Moyen | Prouvé avec un déploiement AWS réel ; les pilotes natifs sont Planifiés |
| Confiner un agent IA | Politique de refus par défaut + espace de noms séparé | Fort en conception, moyen en configuration livrée | L'exécuteur par défaut est inline : l'isolation dure demande une activation d'exploitation |
| Uniformiser les sondes de santé | Sonde de vivacité distincte | Moyen | Le motif existe ; il n'est pas encore appliqué à tout le catalogue |
| Remplacer la supervision d'astreinte | — | Nul, assumé | KySpectra n'est ni votre collecteur de métriques ni votre outil d'alerte |
| Gérer le DNS par hôte | — | Faible | Client écrit et testé, non branché ; enregistrement générique préexistant requis |
| Intervenir depuis un téléphone en astreinte | — | Faible | Portails responsives uniquement ; aucune application mobile |
Aucun diagramme à afficher
Diagramme 2 — flowchart
#8. Objections et réponses honnêtes
| # | Objection | Réponse |
|---|---|---|
| O1 | « J'ai déjà une chaîne d'intégration continue qui marche. Pourquoi la remplacer ? » | Ne la remplacez pas. KySpectra génère un pipeline pour votre fournisseur — GitHub Actions, GitLab CI, Azure Pipelines ou Jenkins — et le commite dans votre dépôt. Ce qu'il ajoute, c'est la couche de décision : approbation attribuable, portes non contournables, retour arrière relié. Si votre besoin est un meilleur exécuteur de tâches, ce n'est pas pour vous. |
| O2 | « Encore une couche d'approbation. Ça va nous ralentir. » | Par défaut, elle est désactivée : DEPLOY_REQUIRE_APPROVAL vaut false. Vous l'activez si votre contexte l'exige. En revanche, l'ordre des étapes n'est pas négociable, et c'est délibéré : c'est ce qui rend le tableau de bord crédible. |
| O3 | « Vous prétendez isoler les agents, mais votre exécuteur par défaut est inline. » |
Vous avez raison, et nous le disons avant vous. RUNTIME_EXECUTOR vaut inline par défaut, et le manifeste de l'environnement de développement le fixe explicitement. Dans cette configuration, il n'y a pas d'isolation conteneur/réseau dure. Le mécanisme par tâche Kubernetes éphémère — espace de noms séparé, pod non-root, racine en lecture seule, capacités retirées, sortie réseau sur liste d'autorisation — est livré et testé ; son activation est une opération d'exploitation, chez vous, sous votre contrôle. |
| O4 | « Vos sondes de santé sont couplées à la base. Vous répétez notre problème. » | Sur une partie du catalogue, oui : plusieurs services n'exposent qu'un /health qui interroge la base et répond 503 si elle est indisponible. Le motif correct — /health/live pour la vivacité, /health pour la disponibilité — existe dans le produit mais n'est pas uniforme. C'est un chantier identifié, pas une propriété que nous revendiquons. |
| O5 | « Nous sommes sur Azure, pas sur Kubernetes. » | Alors soyons précis : le rollout gouverné est prouvé sur Kubernetes, en production. Le mécanisme générique « interface en ligne de commande nuage exécutée dans une tâche éphémère avec des identifiants déposés au coffre » est prouvé, avec un déploiement AWS réel. Les pilotes natifs Azure Container Apps, Cloud Run et ECS sont Planifiés. Si vous avez besoin d'un pilote natif Azure aujourd'hui, ce n'est pas pour vous aujourd'hui. |
| O6 | « Et le DNS ? Vous créez les enregistrements ? » | Non, pas aujourd'hui. Le client d'interface DNS est écrit et testé, mais il n'est pas branché : la mise en ligne repose sur un enregistrement générique préexistant sur la zone. Nous préférons vous le dire maintenant plutôt qu'en atelier d'installation. |
| O7 | « Vos chiffres de gain, vous les sortez d'où ? » | De nulle part, et nous le disons. Aucun pilote n'a encore mesuré ces gains. Les heures de la section 4 portent l'étiquette [Hypothèse] et les formules de la section 5 sont visibles pour que vous les contestiez. Les seuls chiffres que nous publions décrivent notre propre dépôt : 255 commits, environ 30 services backend déployables, plus de 3 700 tests automatisés, 3 environnements en ligne. |
| O8 | « Vous n'avez aucun client de référence en exploitation. » | Exact. [Gabarit : témoignage à collecter auprès d'un pilote de Phase 1]. Ce que nous avons, ce sont des preuves d'exécution sur notre propre production : un produit tiers construit, publié et servi sur un sous-domaine avec TLS, un rollout ré-interrogé jusqu'à convergence, un dépôt de secret réel au coffre relu indépendamment. |
| O9 | « Un outil de plus qui va devenir un point de défaillance unique. » | Le résultat reste chez vous : le pipeline est commité dans votre dépôt, le déploiement produit des objets Kubernetes standard, les secrets vivent dans votre coffre. Si KySpectra devient indisponible, votre chaîne continue de fonctionner ; vous perdez la couche de décision et le journal, pas la capacité de déployer. |
| O10 | « Vos agents vont finir par toucher à la production. » | C'est précisément ce que la configuration refuse. Le déploiement en production, la sortie réseau non listée, l'écriture hors espace de travail et la prise de bail de secret sont volontairement absents de la liste d'autorisations par défaut, donc refusés et journalisés. Un run est interruptible en cours, et son flux d'activité est rejouable depuis la base. |
| O11 | « Nous avons déjà un coffre. Vous allez en ajouter un deuxième ? » | Non. Le produit dépose dans votre coffre et ne conserve que la référence. Si le coffre n'est pas configuré, l'appel répond 503 — il n'existe aucun repli qui stockerait la valeur ailleurs. Et la configuration d'outils rejette activement tout secret en clair. |
| O12 | « Combien de temps avant que ce soit utile pour mon équipe ? » | La première valeur arrive avec la génération de pipeline et le dépôt de secret : c'est une demi-journée de travail sur un service pilote. La valeur de gouvernance — approbations, refus journalisés, budgets — arrive quand vous branchez un premier service réel sur la chaîne, ce qui suppose de décider vos portes. [Gabarit : durée médiane de mise en service d'un premier projet, à mesurer en Phase 1] |
| O13 | « Nous sommes une équipe de deux personnes. C'est surdimensionné. » | Probablement, oui. Si vous déployez moins d'une fois par semaine, sans exigence d'audit et sans agents IA dans la chaîne, la valeur marginale est faible. Commencez par le palier Découverte à 0 $ CAD [Hypothèse] et n'allez plus loin que si la question « qui a approuvé ? » vous est réellement posée. |
| O14 | « Vos interfaces affichent encore SPECTRA. » |
Oui, et c'est un écart connu, listé dans le brief : la chaîne de nom d'application vaut encore SPECTRA et il n'existe aucun fichier de logo dans le dépôt. C'est une action de pré-lancement identifiée, pas une découverte que vous nous faites. |
#9. Offre recommandée
#9.1 Le plan
Palier Équipe — 49 $ CAD par utilisateur et par mois [Hypothèse], avec bascule vers Entreprise dès qu'une exigence réglementaire entre dans la conversation.
Le montant 49,00 $ CAD/mois (et 490,00 $ CAD en annuel) est la valeur réellement présente dans le catalogue de plans en base,
slug = team, devise CAD. La modalité « par utilisateur » est une hypothèse de travail à arrêter par le propriétaire avant toute publication (brief §10).
#9.2 Pourquoi ce palier pour cette persona
| Raison | Détail |
|---|---|
| Plafond d'autonomie N2 | Suffisant pour laisser des agents produire et tester sous supervision, sans ouvrir le niveau N3 réservé aux organisations réglementées |
| Volume d'appels d'outil | 5 000 appels d'outil par jour, contre 200 au palier Découverte : c'est la différence entre évaluer et exploiter |
| Outils et compétences personnalisés | 25 compétences, 10 outils, 10 rôles — le palier Découverte n'en autorise aucun, ce qui bloque toute intégration d'outillage maison |
| Taille d'équipe | Cible de 3 à 25 personnes, ce qui correspond à une équipe plateforme et à ses correspondants produit |
#9.3 Ce qui est inclus
| Inclus | Détail |
|---|---|
| Chaîne de livraison gouvernée | Six étapes ordonnées, portes non contournables, plan en simulation, approbation, retour arrière |
| Mise en ligne Kubernetes | Espace de noms, Deployment, Service, Ingress, TLS sur sous-domaine |
| Génération de pipeline | Quatre fournisseurs, commit réel dans la forge (Gitea et GitHub côté commit) |
| Exécution d'agents gouvernée | Refus par défaut, espace de noms d'exécution séparé, interruption, suspension et reprise, flux d'activité rejouable |
| Coffre | Dépôt de secrets par référence, sessions bastion à certificat court |
| Plan de contrôle | Santé agrégée, flotte d'agents, budgets et quotas, drapeaux de fonctionnalité, garde-fous, politiques d'exécution, audit |
| Graphe de dépendances | Traversées, cycles, instantanés immuables, nomenclature logicielle, vulnérabilités, licences |
| Vérification | Test navigateur réel, analyse de base PostgreSQL réelle, tests fumigènes HTTP |
| Bilingue | Français par défaut, anglais de plein droit |
#9.4 Ce qui n'est pas inclus
| Exclu | Statut réel |
|---|---|
| Pilotes nuage natifs — Azure Container Apps, Cloud Run, ECS | ⚪ Planifié — hors de tout palier aujourd'hui |
| Déclencheurs d'intégration continue externes | ⚪ Planifié |
| Création d'enregistrement DNS par hôte | 🟡 En cours — client écrit et testé, non branché |
| Échange de jetons de registre pour ECR, ACR et GCR | ⚪ Planifié — absent |
| Provisionnement automatique de fournisseur d'identité | ⚪ Planifié — bloqué par des droits d'administration ; action d'exploitation requise |
| Recherche en ligne pour les agents | Réservée au palier Entreprise |
| Plafond d'autonomie N3 | Réservé au palier Entreprise |
| Application mobile d'astreinte | ⚪ Planifié — aucun code mobile dans le dépôt |
| Supervision, collecte de métriques, gestion d'alertes | Hors périmètre assumé |
#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'un outil ou d'une compétence personnalisés dans la chaîne | 25 compétences, 10 outils, 10 rôles, 5 000 appels/jour, plafond N2 |
| Équipe → Entreprise | Un auditeur demande la vérification de chaîne du journal et un rapport de conformité sur période ; besoin du plafond N3 ; volumes d'appels d'outil au-delà de 5 000 par jour | 1 000 compétences, 500 outils, 200 rôles, 1 000 000 d'appels/jour, recherche en ligne activée, plafond N3 |
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 |
|---|---|---|
| Un service réel branché sur la chaîne de livraison | 1 service | GET /api/v1/deploy/deploy-runs — au moins un run avec les six étapes |
| Pipeline généré et commité dans la forge | 1 | POST /api/v1/deploy/cicd/setup — commit_sha renvoyé |
| Secrets du service pilote déposés au coffre | 100 % des secrets du service | POST /api/v1/deploy/credentials/deposit — version renvoyée |
| Budgets créés avec seuils | ≥ 2 périmètres | GET /budgets du plan de contrôle, page /budgets |
| Drapeaux de fonctionnalité utilisés au moins une fois | ≥ 1 bascule | PATCH /feature-flags/{id}, page /flags |
#10.2 À 60 jours
| Indicateur | Cible [Hypothèse] |
Source de mesure réelle |
|---|---|---|
| Déploiements passés par la chaîne gouvernée | ≥ 50 % des déploiements du périmètre pilote | GET /api/v1/deploy/deploy-runs |
| Décisions d'approbation enregistrées | 100 % des déploiements en production du périmètre | GET …/deploy-runs/{id}/approvals |
Refus deny-by-default examinés et arbitrés |
100 % | Table app_policy_check ; page /policies |
| Runs d'agents interrompus ou repris depuis le plan de contrôle | ≥ 5 | POST /api/v1/agent-runtime/runs/{id}/interrupt ; page /fleet |
| Alertes de budget déclenchées avant la facture | ≥ 1, traitée | Seuils d'avertissement et seuil critique des budgets |
#10.3 À 90 jours
| Indicateur | Cible [Hypothèse] |
Source de mesure réelle |
|---|---|---|
| Retours arrière exécutés par la chaîne, sans improvisation | 100 % de succès | POST /api/v1/deploy/deployments/{id}/rollback — lignes rollback_of |
| Délai médian « demande → décision d'approbation » | ≤ 4 h [Hypothèse] |
Horodatage de app_deploy_approval |
| Part du temps d'exploitation passée en file de demandes | −40 % par rapport au point de départ [Hypothèse] |
[Gabarit : mesure de référence à établir en semaine 1 du pilote] |
| Vérification de chaîne du journal d'audit exécutée | ≥ 1 par mois, sans rupture | Page /audit du plan de contrôle, vérification de chaîne |
| Fenêtres de maintenance calibrées à partir du graphe | ≥ 2 | Traversées et simulations sur dependency-graph-service |
#11. Accroches pour cette persona
Six accroches rédigées, avec canal recommandé. Ton : praticien à praticien, vouvoiement, aucun superlatif.
| # | Accroche | Canal recommandé | Intention |
|---|---|---|---|
| A1 | « Qui a approuvé ce déploiement ? » Chez nous, la réponse est une ligne en base : demandeur, approbateur, motif, horodatage. Et l'approbateur ne peut pas être le demandeur — le serveur refuse. |
Publication technique longue sur un carnet d'ingénierie de fiabilité | Toucher D1 avec un mécanisme vérifiable, sans promesse chiffrée |
| A2 | « Une porte qu'on peut contourner n'est pas une porte. » Ordre imposé sur build → test → scan → gate → deploy → monitor. Avancer hors séquence renvoie une erreur, pas un avertissement. |
Fil court sur réseau social technique | Adresser D2 par la contrainte, pas par la discipline |
| A3 | « Votre scanner n'a pas tourné ? Vous n'aurez pas de vert. » Analyse statique, dépendances, secrets. Un outil absent produit un refus explicite qui le nomme — jamais un succès fabriqué. |
Page produit, section « Ce que nous ne faisons pas » ; reprise en présentation technique | Construire la confiance par la limite assumée — différenciateur D5 du brief |
| A4 | « Où votre agent IA a-t-il le droit d'appeler ? » Espace de noms d'exécution séparé, pod non-root, racine en lecture seule, capacités retirées, une seule sortie réseau autorisée. Le reste est refusé et journalisé. |
Intervention en conférence d'exploitation ou en rencontre d'ingénierie de fiabilité | Adresser D6 avec des propriétés vérifiables |
| A5 | « Le retour arrière, vous l'avez déjà vu marcher ? » Chez nous, c'est une opération de première classe, reliée au déploiement d'origine — donc répétable et mesurable. |
Courriel de séquence d'activation, message 3 sur 5 | Adresser D3 en parlant de rétablissement, pas de vitesse |
| A6 | « La vitesse de l'IA, avec la traçabilité que l'audit exige. » Approbation attribuable, journal d'audit à chaîne de hachage vérifiable, refus par défaut journalisé. |
Bandeau de site pour publics conformité et secteur réglementé ; affiche de salon | Slogan « conformité » du brief, décliné pour l'exploitation |
#12. Ce que nous refusons de dire à cette persona
| Formulation interdite | Pourquoi |
|---|---|
| « Déployez sur n'importe quel nuage » | Les pilotes natifs sont Planifiés ; seul le mécanisme générique est prouvé |
| « Vos agents sont isolés par défaut » | Faux : l'exécuteur par défaut est inline ; l'isolation dure demande une activation |
| « Zéro incident » | Aucune promesse de résultat non mesurée (brief §12) |
| « Conformité automatique » | Non revendiqué (brief §7) |
| « Remplacez votre supervision » | Hors périmètre |
| « Nos clients constatent… » | Aucun témoignage n'existe (brief §15) |
| « Notre application mobile d'astreinte » | Aucun code mobile n'existe dans le dépôt |
| « 10x moins d'incidents » | Superlatif chiffré interdit (brief §12) |
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.