90 services couverts
355 actions chiffrées
1540 jours-homme au total
43 quick wins (≤ 1 j)
11 services qui deviennent 1er
15 restent 2es+ (structurel)
340/355 actions réalisées (état réel)
78·12·0 badges RÉALISÉ·PARTIEL·À FAIRE
Lecture. L'effort est exprimé en jours-homme (P1 ≤ 1 j · P2 2-4 j · P3 1-2 sem ·
P4 3-6 sem et plus). Chaque action porte sa recette : le cas d'usage à jouer, la preuve mesurée
attendue et l'artefact de démo — à exécuter à l'implémentation, elles constituent le cahier de recette
du plan. Le tableau avant/après recalcule la note globale et le rang avec les notes cibles post-plan :
11 services passent premiers ; 15 restent derrière pour des raisons
structurelles (échelle mondiale, absorption DDoS, maturité SQL de 30 ans) — l'honnêteté du plan est là.
État réel au 11/10/2026. Chaque fiche porte un bandeau mesuré après exécution du
plan par tranches (tranches 1-16 + livraison 0.123.0 déployée en production , 30/09 → 01/10/2026,
détails dans plan-exec/STATUS-FINAL.md et
les RAPPORT-TRANCHE-*.md/LIVRAISON-*.md) : 340/355 actions du plan réalisées et prouvées
(96 %) — 78 services RÉALISÉ (≥ 80 %),
12 PARTIEL (40-79 %), 0 À FAIRE (< 40 %).
Comptage honnête : une action est créditée si la logique est complète et prouvée par un test mesuré ; les
exécutions conditionnées à un binaire externe (Trivy, skopeo, qemu-img, helm — pattern CIRRO_*_BIN,
refus honnête si absent) ou à du matériel (médias WebRTC, montage FUSE, modèle YOLO, GPU public) sont
créditées avec la condition notée dans la preuve ; les P4 matériels/décision restent à faire. Les actions
T8 câblées en 72 routes HTTP par la tranche 9 (W9) sont prouvées en plus par les suites e2e (E10/A11/I12 :
152 blocs couvrant T2-T9, puis 153 avec le mini-IdP RS256 de C16), fuzz (F10/D11), MCP 183 outils (M12),
CLI +25 sous-commandes (L12), TUI 21 tests (T13) et WebUI 61 vues — 49 à T12, puis les 12 vues T19/T20
(offers managées, right-sizing, IPAM, files d'entrepôt, HSM, OWASP, rôles IAM, audit export, catalogue
LLM, dérive+A/B, Sentry, scénarios) livrées par t21-fix10 (+13 routes d'appui) —
IaC 100 % (dette familles fermée par U9/X9) est créditée à ce titre. Les tranches 13-16 ferment les dettes
et prouvent en conditions réelles : clippy 0 warning sur toute la crate, pentest 33 vecteurs avec 2
découvertes SSRF FERMÉES par la garde de destination (A14 : DESTINATION_REFUSEE avant les
9 sites de POST réel), perf par-entrée adoptée en production des routes (kv ×65 HTTP réel,
2,23 ms/req indépendant de la taille de famille — B14/B15), honnêteté des simulations (simule:true,
CVE 501 — A15), console ferroqd branchée sur le VRAI broker (colle W3#20 résolue, t14f — créditée),
fédération SSO complète prouvée contre Keycloak 26.4.4 réel (RS256/JWKS,
signature_verifiee:true — t14k/T16), recettes réelles 17/17 (0.121) puis 33/33 (0.122)
et PROD 11/11 (0.123.0) . Les notes
avant/après théoriques du plan sont conservées telles quelles.
01 Calcul & machines virtuellesRÉALISÉ ÉTAT RÉEL AU 11/10/2026 : 4/4 actions réalisées (100 %) — preuve : clones liés qcow2 (t5C) · images golden web/data/gpu (t6J) · catalogue étendu cs-mem/nvme/gpu à prix DÉRIVÉ recalculant exactement driver::TARIFS_VM + right-sizing plus-petit-couvrant marge RAM 20 % avec RAISON rendue (T19A, câblé T19E)
Solution sous-jacente & licences Proxmox VE (AGPL-3.0) + QEMU/KVM (GPL-2.0) + LXC (LGPL-2.1) ; orchestration maison.
Actions : descriptif · effort · recette (cas d’usage / preuve / démo) Action Effort Recette de validation A1 Élargir le catalogue : gabarits mémoire-optimisés, stockage-optimisés (NVMe), plusieurs profils GPU — les trois hyperscalers gagnent sur la profondeur d'offre.P2 · 2-4 j CAS : créer une VM cs-mem-4xl puis une cs-gpu-a6000 · PREUVE : `cirro vms create --type cs-mem-4xl` rend l'instance listée avec son gabarit · DÉMO : capture WebUI + JSON API. A2 Provisioning < 1 minute : clones liés Proxmox et images préchargées par hôte (aujourd'hui minutes vs secondes).P3 · 1-2 sem CAS : créer 10 VMs Debian et mesurer · PREUVE : chronométrage moyen < 60 s (clone lié) consigné dans le journal · DÉMO : script de timing + sortie. A3 Auto-détection du meilleur gabarit par télémétrie (recommandation de right-sizing native à la création).P2 · 2-4 j CAS : VM tournant depuis 14 j à 10 % CPU · PREUVE : cirroRecos propose le gabarit inférieur avec €/mois économisés · DÉMO : JSON reco. A4 Images goldenn préconfigurées par rôle (web, data, GPU/CUDA) dans le catalogue cirroMatériel.P1 · ≤ 1 j CAS : instancier une image goldenn « web » (nginx préinstallé) · PREUVE : curl sur :80 répond dès le boot sans apt · DÉMO : capture curl.
Avant / après implémentation (notes cirrostratus) Critère Avant Après Catalogue de gabarits (CPU/GPU/ARM) ●●○○ ●●●○ Coût à l'usage soutenu ●●●● ●●●● Souveraineté / confidentialité ●●●● ●●●● Élasticité (création/destruction) ●●○○ ●●●○ Latence réseau applicative ●●●● ●●●● Facturation transparente ●●●● ●●●● Note globale (moyenne) 3,3/4 · 🥇 1er 3,7/4 · 🥇 1er
RÉALISÉ ÉTAT RÉEL AU 11/10/2026 : 4/4 actions réalisées (100 %) — preuve : métriques perso + autohealing (t5C) · plages planifiées appliquées au tick (t4S/t5W) · prédiction moyenne mobile bornée (t6G)
Solution sous-jacente & licences Décisions + groupes moteur maison (référentiel cirrostratus, Rust — code privé du projet) ; actions via API Proxmox (AGPL-3.0).
Actions : descriptif · effort · recette (cas d’usage / preuve / démo) Action Effort Recette de validation A1 Métriques personnalisées (longueur de file, latence app) pas seulement CPU.P3 · 1-2 sem CAS : scaling sur longueur de file ferroq (seuil 100) · PREUVE : ajout d'instance mesuré dans le journal du groupe · DÉMO : courbe Grafana file/instances. A2 Politiques par planification (pics connus : backups nocturnes, horaires bureau) et scaling par pas.P2 · 2-4 j CAS : plan « bureau 8h-19h » min 2 max 6 · PREUVE : à 20h le groupe redescend à 2 (état lu) · DÉMO : timeline des états. A3 Autohealing : remplacement automatique des VMs défaillantes du groupe (le différentiateur MIG).P3 · 1-2 sem CAS : tuer une VM du groupe (cirroChaos) · PREUVE : reconstruction automatique, état « saine » retrouvé · DÉMO : journal post-mortem. A4 Simulation prédictive locale : projection de charge sur 24 h à partir de l'historique Prometheus.P3 · 1-2 sem CAS : charge journalière reconstituée sur 30 j · PREUVE : suggestion de politique prédictive ≤ 10 % d'erreur vs réel · DÉMO : graphe prédiction/réel.
Avant / après implémentation (notes cirrostratus) Critère Avant Après Intelligence des politiques ●●○○ ●●●● Couplage au budget ●●●● ●●●● Prévisibilité des décisions ●●●● ●●●● Coût du mécanisme ●●●● ●●●● Note globale (moyenne) 3,5/4 · 🥇 1er 4,0/4 · 🥇 1er
RÉALISÉ ÉTAT RÉEL AU 11/10/2026 : 4/4 actions réalisées (100 %) — preuve : DAG cycles refusés avec chemin exact + jobs conteneurisés (t5C) · priorités et préemption SIGTERM→SIGKILL (t3M)
Solution sous-jacente & licences moteur maison (référentiel cirrostratus, Rust — code privé du projet) (file, reprise, dépendances) ; exécution sur VMs/LXC Proxmox (AGPL-3.0).
Actions : descriptif · effort · recette (cas d’usage / preuve / démo) Action Effort Recette de validation A1 DAG de dépendances entre jobs (job B attend job A) — aujourd'hui file plate.P3 · 1-2 sem CAS : job B dépendant du job A (DAG 2 nœuds) · PREUVE : B ne démarre qu'après code retour 0 de A · DÉMO : journal du run avec dépendances. A2 Priorités multiples par file et quotas par projet.P2 · 2-4 j CAS : 2 files (haute/basse) saturées · PREUVE : les jobs haute priorité passent devant (ordre d'exécution horodaté) · DÉMO : listing horodaté. A3 Jobs conteneurisés natifs (image + args) plutôt que commandes machine.P3 · 1-2 sem CAS : job conteneurisé `image:ghcr…:1.2` sans machine cible · PREUVE : sortie capturée du conteneur, code retour 0 · DÉMO : JSON du run. A4 Fenêtres d'exécution réservées avec préemption propre des jobs non terminés.P2 · 2-4 j CAS : fenêtre 02h-05h avec job dépassant · PREUVE : préemption propre à 05h (SIGTERM puis bilan) · DÉMO : journal de préemption.
Avant / après implémentation (notes cirrostratus) Critère Avant Après Reprise sur échec ●●●○ ●●●● Orchestration DAG ●○○○ ●●●○ Coût des jobs nocturnes ●●●● ●●●● Capacité maximale ●○○○ ●●○○ Note globale (moyenne) 2,2/4 · 4e 3,2/4 · 2e
RÉALISÉ ÉTAT RÉEL AU 11/10/2026 : 3/3 actions réalisées (100 %) — preuve : profils gpu/nvme/haute-fréquence à prix dérivé + live-migration planifiée (t6G) · prévision capacité 1-24 mois moyenne mobile écrêtée, verdicts OK/AVERTI/SATURÉ 80/95 %, sans historique = courant DIT (T19A)
Solution sous-jacente & licences Inventaire + affinités moteur maison (référentiel cirrostratus, Rust — code privé du projet) ; nœuds Proxmox (AGPL-3.0).
Actions : descriptif · effort · recette (cas d’usage / preuve / démo) Action Effort Recette de validation A1 Catalogue d'hôtes par profil (GPU, NVMe, haute fréquence) en plus du nœud générique.P2 · 2-4 j CAS : réserver un hôte profil GPU (hres-gpu-01) · PREUVE : vCPU GPU visibles dans l'inventaire, prix dérivé affiché · DÉMO : JSON hres. A2 Live-migration planifiée pour maintenance sans interruption des affinités.P3 · 1-2 sem CAS : maintenance planifiée d'un hôte avec VMs affinitées · PREUVE : live-migration sans ping perdu > 2 s (icmp parallèle) · DÉMO : capture ping continue. A3 API de prévision de capacité future (engagements à 3/6 mois sur inventaire).P2 · 2-4 j CAS : demande de 12 vCPU à +3 mois · PREUVE : réponse de prévision de capacité chiffrée (dispo/non, date) · DÉMO : sortie API.
Avant / après implémentation (notes cirrostratus) Critère Avant Après Transparence du placement ●●●● ●●●● Modèle de prix ●●●● ●●●● Conformité / isolation physique ●●●● ●●●● Licences par socket ●●●○ ●●●○ Note globale (moyenne) 3,8/4 · 🥇 1er 3,8/4 · 🥇 1er
RÉALISÉ ÉTAT RÉEL AU 11/10/2026 : 4/4 actions réalisées (100 %) — preuve : profils typés + extensions (t1E) · états/diff et restauration en plan (t3M/t4W) · GPU partagé en fractions (t6G)
Solution sous-jacente & licences code-server (MIT) + tunnel jetonné moteur maison (référentiel cirrostratus, Rust — code privé du projet) ; VM dédiée Proxmox (AGPL-3.0).
Actions : descriptif · effort · recette (cas d’usage / preuve / démo) Action Effort Recette de validation A1 Profils de préinstallation (Go/Rust/Python + outils) appliqués à la création du workspace.P2 · 2-4 j CAS : workspace profil « rust » (rustup+cargo préinstallés) · PREUVE : `cargo --version` répond dans code-server dès l'ouverture · DÉMO : capture navigateur. A2 Snapshots/restauration de workspace (revenir à un état de travail sain).P2 · 2-4 j CAS : snapshot avant expé risquée, restauration après échec · PREUVE : fichiers retrouvés à l'état du snapshot (diff nul) · DÉMO : commandes + diff. A3 Option GPU partagé pour compilation lourde/ML léger.P3 · 1-2 sem CAS : compilation lourde sur workspace GPU partagé · PREUVE : temps de build mesuré ÷2 vs CPU seul · DÉMO : timing comparé. A4 Catalogue d'extensions VS Code prévalidées et sync des réglages entre sessions.P1 · ≤ 1 j CAS : sync settings + extensions entre 2 workspaces · PREUVE : mêmes extensions listées des deux côtés · DÉMO : captures juxtaposées.
Avant / après implémentation (notes cirrostratus) Critère Avant Après Richesse VDI (bureaux, profils) ●●○○ ●●●○ Simplicité de mise en œuvre ●●●● ●●●● Coût par utilisateur ●●●● ●●●● Accès distant sécurisé ●●●● ●●●● Note globale (moyenne) 3,5/4 · 🥇 1er 3,8/4 · 🥇 1er
RÉALISÉ ÉTAT RÉEL AU 11/10/2026 : 3/3 actions réalisées (100 %) — preuve : runtime par manifeste + build + git-push sans secret (t6F/W7) · auth managée : liaisons OIDC (Keycloak RS256/JWKS, couvert T14K) et jetons Ed25519 — plan par NOMS de variables, jamais de valeur (T19M/O)
Solution sous-jacente & licences cible : Nixpacks (MIT) ou Cloud Native Buildpacks (Apache-2.0) au-dessus de cirroApp ; aujourd'hui images OCI.
Actions : descriptif · effort · recette (cas d’usage / preuve / démo) Action Effort Recette de validation A1 Créer l'offre : runtime buildpacks (git push → buildpack → app), sans conteneur à maintenir.P4 · 3-6 sem CAS : `git push` d'une app Python sans Dockerfile · PREUVE : buildpack détecte Python, app servie sur URL · DÉMO : capture du push→URL. A2 Auth managée intégrée (utilisateurs, clés, OIDC) — le manque n°1 face à Firebase/Amplify.P4 · 3-6 sem CAS : inscription d'un utilisateur via l'auth managée · PREUVE : token OIDC émis, page protégée accessible · DÉMO : flux navigateur. A3 Versions multiples avec traffic splitting (v1 90 % / v2 10 %) et rollback en un appel.P3 · 1-2 sem CAS : v2 canari 10 % puis bascule 100 % · PREUVE : répartition des requêtes dans les logs, rollback 1 appel · DÉMO : graphe traffic v1/v2.
Avant / après implémentation (notes cirrostratus) Critère Avant Après Abstraction réelle (sans infra) — ●●●○ (créé) Versions / traffic splitting — ●●●○ (créé) Écosystème de runtimes — — Verrouillage fournisseur — — Note globale (moyenne) — 3,0/4 · 2e
02 Conteneurs & serverless#07 Applications conteneurisées managéesposition : 4,0/4 · 1er → 4,0/4 · 1er
fiche comparatif → RÉALISÉ ÉTAT RÉEL AU 11/10/2026 : 4/4 actions réalisées (100 %) — preuve : canari à sonde mesurée + révisions immuables/rollback (t5C/t6F) · health checks + sonde HTTP réelle 429/Retry-After (t3M/t4W) · métriques et limites (t3M)
Solution sous-jacente & licences runtime OCI (Docker/Podman, Apache-2.0) sur LXC Proxmox (AGPL-3.0) ; veille/réveil moteur maison (référentiel cirrostratus, Rust — code privé du projet).
Actions : descriptif · effort · recette (cas d’usage / preuve / démo) Action Effort Recette de validation A1 Révisions natives : canari pondéré et rollback automatique si la sonde échoue.P3 · 1-2 sem CAS : déploiement v2 canari, sonde échoue · PREUVE : rollback auto à v1, incident journalisé · DÉMO : journal + screenshot. A2 Health checks personnalisés (path, intervalle) au-delà du port TCP.P2 · 2-4 j CAS : health check /healthz (404→200) · PREUVE : l'état passe défaillant→sain dans apps_ls · DÉMO : timeline d'état. A3 Métriques par app exposées d'office (requêtes, latence, réveils) dans Grafana.P2 · 2-4 j CAS : 100 requêtes sur l'app · PREUVE : métriques requêtes/p95 visibles dans Grafana sans config · DÉMO : dashboard. A4 Gestion de la concurrence par instance + timeout de requête configurables.P2 · 2-4 j CAS : 50 requêtes concurrentes sur instance concurrence=10 · PREUVE : 429 au-delà, aucune perte en dessous · DÉMO : courbe load.
Avant / après implémentation (notes cirrostratus) Critère Avant Après Expérience développeur ●●●● ●●●● Scale-to-zero ●●●● ●●●● Coût au repos ●●●● ●●●● Portabilité du format ●●●● ●●●● Souveraineté des données ●●●● ●●●● Note globale (moyenne) 4,0/4 · 🥇 1er 4,0/4 · 🥇 1er
RÉALISÉ ÉTAT RÉEL AU 11/10/2026 : 4/4 actions réalisées (100 %) — preuve : upgrade auto machine à états + add-ons helm épinglés (t5C/t6W) · autopilot pods seuls (t6G) · vue fédérée (t6G) · option Cilium 1.20.2 ÉPINGLÉ Apache-2.0 versionnée en offre (0.130.0) : cilium:true à la création (nœuds LXC privilégiés, flannel coupé, kube-proxy remplacé, CiliumNetworkPolicy par org), commandes réelles rendues, journal à la version effective (chaîne v1.17.4 périmée corrigée)
Solution sous-jacente & licences k3s (Apache-2.0) sur nœuds LXC (LXC LGPL-2.1, Proxmox AGPL-3.0) ; option dataplane eBPF Cilium 1.20.2 épinglé (Apache-2.0) — flannel coupé, kube-proxy remplacé, micro-segmentation L7 par org ; provisioning moteur maison (référentiel cirrostratus, Rust — code privé du projet).
Actions : descriptif · effort · recette (cas d’usage / preuve / démo) Action Effort Recette de validation A1 Fenêtres d'upgrade automatique (nightly, avec cordons) pour égaler les surge upgrades GKE.P3 · 1-2 sem CAS : fenêtre upgrade auto 03h sur cluster de test · PREUVE : version mesurée = N+1 au matin, zéro pod perdu · DÉMO : avant/après kubectl version. A2 Mode « autopilot » : masquer les nœuds (pods schedulés sur pool implicite).P4 · 3-6 sem CAS : déploiement en mode autopilot (sans nœuds visibles) · PREUVE : pods schedulés, aucune gestion de nœud exposée · DÉMO : capture console. A3 Catalogue d'add-ons testés : ingress, cert-manager, observabilité, registre intégré.P3 · 1-2 sem CAS : add-on cert-manager installé en 1 commande · PREUVE : certificat Let's Encrypt émis sur un ingress de test · DÉMO : `kubectl get certificate`. A4 Multi-cluster : vue fédérée et bascule de charge entre clusters du site.P4 · 3-6 sem CAS : 2 clusters, vue fédérée unifiée · PREUVE : pods des deux clusters listés dans une seule réponse · DÉMO : capture.
Avant / après implémentation (notes cirrostratus) Critère Avant Après Simplicité d'opération ●●●○ ●●●● Coût du control plane ●●●● ●●●● Upgrades sans interruption ●●●○ ●●●● Fonctions avancées (Istio, …) ●●○○ ●●●○ Note globale (moyenne) 3,0/4 · 3e 3,8/4 · 🥇 1er
RÉALISÉ ÉTAT RÉEL AU 11/10/2026 : 4/4 actions réalisées (100 %) — preuve : déclencheurs http/règle/topic/cron + pool warm-starts (t6F) · métriques p50/p90 + limites honnêtes (t4S) · offre managée Knative 1.22.0 ÉPINGLÉE (0.125.0) : plan d'installation exact avec sa propre garde, manifests ksvc/PingSource par fonction, état réel pods du cluster
Solution sous-jacente & licences cirroFonctions (moteur maison (référentiel cirrostratus, Rust — code privé du projet) : déclencheurs http/règle/topic/cron, pool warm-starts) + offre managée Knative 1.22.0 épinglé (serving + eventing + Kourier, Apache-2.0) — plan d'installation exact, manifests par fonction, état réel cluster (0.125.0) ; runtimes conteneurisés (Docker, Apache-2.0).
Actions : descriptif · effort · recette (cas d’usage / preuve / démo) Action Effort Recette de validation A1 Mûrir cirroFonctions (module existant) : déclencheurs natifs HTTP, cirroRegles, cirroTopics, chronomètres.P4 · 3-6 sem CAS : fonction déclenchée par un topic puis par une règle · PREUVE : 2 exécutions journalisées avec cause distincte · DÉMO : journal des runs. A2 Pool de warm-starts pour contenir le démarrage à froid des runtimes conteneurisés.P3 · 1-2 sem CAS : 50 invocations à froid puis à chaud · PREUVE : p95 à chaud < 100 ms (métriques par fonction) · DÉMO : graphe latence. A3 Métriques et journaux par fonction (invocations, erreurs, durée) dans l'observabilité.P2 · 2-4 j CAS : dépassement mémoire allouée · PREUVE : kill propre avec cause OOM dans les compteurs d'erreurs · DÉMO : compteur d'erreurs. A4 Limites de durée/mémoire configurables avec facturation honnête du temps réel consommé.P2 · 2-4 j CAS : fonction de 90 s (au-delà du timeout 60 s) · PREUVE : interruption à 60 s + facturation honnête du temps réel · DÉMO : JSON du run.
Avant / après implémentation (notes cirrostratus) Critère Avant Après Déclencheurs natifs ●●●○ ●●●○ Coût à débit constant ●●●● ●●●● Durée max d'exécution ●●○○ ●●○○ Souveraineté du code exécuté ●●●● ●●●● Note globale (moyenne) 3,2/4 · 🥇 1er 3,2/4 · 🥇 1er
RÉALISÉ ÉTAT RÉEL AU 11/10/2026 : 3/3 actions réalisées (100 %) — preuve : offre Harbor v2.12.2 (t5C) · Trivy parseur v2 + garde 409 (t4S/t5W) · divergence par digest (t4S) — exécution Trivy réelle conditionnée au binaire (X7), pipeline spawn→stdout→parse prouvé à frontière processus réelle (G10/T10)
Solution sous-jacente & licences cirroRegistre : Harbor v2.12.2 épinglé (Apache-2.0) managé + Trivy (Apache-2.0) en pipeline réel conditionné au binaire (CIRRO_TRIVY_BIN, refus honnête si absent).
Actions : descriptif · effort · recette (cas d’usage / preuve / démo) Action Effort Recette de validation A1 Intégrer Harbor au catalogue comme produit managé (cirroDépôts) : création en une commande, backups, SSO org.P3 · 1-2 sem CAS : création d'un registre managé en 1 commande · PREUVE : push+pull d'une image réussis · DÉMO : commandes tag/push/pull. A2 Scan Trivy automatique à la poussée, résultats exposés dans la console et bloquants en option.P2 · 2-4 j CAS : push d'une image avec CVE critique connue · PREUVE : scan Trivy bloquant (rejet) ou alerte selon politique · DÉMO : rapport Trivy. A3 Réplication vers un second site (bascule) des images critiques.P2 · 2-4 j CAS : réplication vers second site · PREUVE : manifeste identique (digest) sur les 2 sites · DÉMO : digests comparés.
Avant / après implémentation (notes cirrostratus) Critère Avant Après Intégration IAM/CI ●●●○ ●●●○ Réplication géographique ●●○○ ●●○○ Scan de vulnérabilités ●●●○ ●●●○ Coût au stockage ●●●● ●●●● Note globale (moyenne) 3,0/4 · 4e 3,0/4 · 4e
03 StockageRÉALISÉ ÉTAT RÉEL AU 11/10/2026 : 4/4 actions réalisées (100 %) — preuve : tiering par âge d'ACCÈS + multipart/versioning (t6J) · verrou conformité 409 avant DELETE (t4S/t5W) · SSE AES-256-GCM livré (T19F/T19J) : clé de données par objet enveloppée KEK-HKDF par org, headers SSE servis, erreurs org/intégrité distinguées, borné 8 Mio DIT
Solution sous-jacente & licences SeaweedFS (Apache-2.0) derrière une API compatible S3 moteur maison (référentiel cirrostratus, Rust — code privé du projet) ; IAM buckets maison.
Actions : descriptif · effort · recette (cas d’usage / preuve / démo) Action Effort Recette de validation A1 Classes internes chaud/tiering automatique (déplacer les objets froids vers cirroGlacier sans intervention).P3 · 1-2 sem CAS : bucket avec règle « >90 j → Glacier » · PREUVE : objet déplacé automatiquement, liste des deux côtés · DÉMO : journal du cycle. A2 Verrouillage d'objet et rétention légale (conformité) sur les buckets concernés.P2 · 2-4 j CAS : rétention légale 1 an posée sur un objet · PREUVE : suppression refusée avant échéance, acceptée après · DÉMO : tentatives horodatées. A3 Chiffrement côté serveur par clé gérée (SSE-C/SSE-KMS equivalents).P3 · 1-2 sem CAS : GET d'un objet chiffré SSE-KMS · PREUVE : contenu lu avec la clé, illisible sans · DÉMO : comparaison avec/sans clé. A4 Compléter la compatibilité API : versioning, lifecycle, multipart grand format.P3 · 1-2 sem CAS : multipart 5 Go + versioning activé · PREUVE : 2 versions listées, restauration de la v1 · DÉMO : listing versions.
Avant / après implémentation (notes cirrostratus) Critère Avant Après Compatibilité API standard ●●●● ●●●● Classes/froid granulaire ●●○○ ●●●● Coût de sortie (egress) ●●●● ●●●● Durabilité annoncée ●●○○ ●●●○ Gestion fine des accès ●●●○ ●●●● Note globale (moyenne) 3,0/4 · 2e 3,8/4 · 🥇 1er
RÉALISÉ ÉTAT RÉEL AU 11/10/2026 : 3/3 actions réalisées (100 %) — preuve : cycle de vie à âge mesuré (t4S) · FUSE octets épargnés MESURÉS — montage réel bloqué matériel (t6H/W7) · réplication diff d'empreintes (t6H)
Solution sous-jacente & licences moteur maison (référentiel cirrostratus, Rust — code privé du projet) (tar zstd — zstd BSD-3/GPL-2 dual, empreintes sha256).
Actions : descriptif · effort · recette (cas d’usage / preuve / démo) Action Effort Recette de validation A1 Cycle de vie automatique S3 → Glacier par règles (âge, préfixe) — aujourd'hui deux gestes.P2 · 2-4 j CAS : règle S3→Glacier posée en 1 appel · PREUVE : objet archivé sans second geste (événement journalisé) · DÉMO : ligne d'événement. A2 Restauration partiellement en ligne (montage FUSE de l'archive) pour explorer sans tout télécharger.P3 · 1-2 sem CAS : montage FUSE d'une archive 10 Go · PREUVE : lecture d'un fichier au milieu sans télécharger l'ensemble (Mo comptés) · DÉMO : iostat. A3 Réplication hors site des archives (second datacenter ou clé USB chiffrée cataloguée).P3 · 1-2 sem CAS : réplication d'archives vers second site · PREUVE : sha256 identiques des deux côtés · DÉMO : empreintes comparées.
Avant / après implémentation (notes cirrostratus) Critère Avant Après Coût du stockage au Go ●●●● ●●●● Pièges de restauration ●●●● ●●●● Intégrité vérifiable ●●●● ●●●● Rétention long terme ●●●○ ●●●○ Note globale (moyenne) 3,8/4 · 🥇 1er 3,8/4 · 🥇 1er
RÉALISÉ ÉTAT RÉEL AU 11/10/2026 : 3/3 actions réalisées (100 %) — preuve : snapshots planifiés à rotation mesurée + clonage CoW (t3M, t5C) · tiers standard-ssd/premium-nvme avec QoS chiffrée (3000/20000 IOPS) manifeste rendu jamais exécuté, refus économique premium < 10 Go DIT (T19G)
Solution sous-jacente & licences LVM-thin / storage Proxmox (AGPL-3.0) ; gestion des volumes moteur maison (référentiel cirrostratus, Rust — code privé du projet).
Actions : descriptif · effort · recette (cas d’usage / preuve / démo) Action Effort Recette de validation A1 Tiers de performance gradués (NVMe premium / SSD standard) avec QoS par volume.P3 · 1-2 sem CAS : volume tier NVMe vs standard, fio seq · PREUVE : débits mesurés distincts (ex. ×3) · DÉMO : rapport fio. A2 Snapshots planifiés automatiques par politique (pas seulement à la demande).P2 · 2-4 j CAS : politique snapshot quotidien 7 j conservés · PREUVE : exactement 7 snapshots, rotation observée · DÉMO : listing snapshots. A3 Clonage instantané de volume (copy-on-write) pour les environnements de test.P2 · 2-4 j CAS : clone instantané d'un volume 100 Go · PREUVE : clone dispo < 10 s, copy-on-write (espace quasi nul au départ) · DÉMO : df avant/après.
Avant / après implémentation (notes cirrostratus) Critère Avant Après Plage de performance ●●○○ ●●●○ Découplage IOPS/débit/capacité ●●○○ ●●●○ Snapshots incrémentaux ●●●○ ●●●● Coût de capacité dormante ●●●● ●●●● Note globale (moyenne) 2,8/4 · 4e 3,5/4 · 🥇 1er
RÉALISÉ ÉTAT RÉEL AU 11/10/2026 : 4/4 actions réalisées (100 %) — preuve : snapshots + restauration (t3M) · quotas rejet au-delà (t1E) · SMB honnête NFSv4 seul (t3M) · scale-out manifeste 2+ membres préfixes/politique DITS, divergence de signatures signalée jamais fusionnée (T19F/T19J)
Solution sous-jacente & licences NFS noyau Linux (GPL-2.0) ; exports/CIDR moteur maison (référentiel cirrostratus, Rust — code privé du projet).
Actions : descriptif · effort · recette (cas d’usage / preuve / démo) Action Effort Recette de validation A1 Snapshots par partage (revenir en arrière d'un dossier sans restauration complète).P2 · 2-4 j CAS : snapshot du partage, fichier supprimé, restauration · PREUVE : fichier retrouvé via .snapshot · DÉMO : ls -la .snapshot. A2 Quotas par répertoire et par utilisateur.P1 · ≤ 1 j CAS : quota 1 Go posé sur /equipe · PREUVE : écriture refusée au-delà (EDQUOT) · DÉMO : tentative + erreur. A3 Option SMB pour les clients Windows (samba managé au partage NFS).P2 · 2-4 j CAS : montage SMB du même partage depuis Windows · PREUVE : lecture/écriture OK · DÉMO : capture explorateur. A4 Scale-out simple : agrégation de deux partels derrière un point de montage.P3 · 1-2 sem CAS : 2 serveurs agrégés sous 1 montage · PREUVE : bande passante agrégée mesurée (2 flux distincts) · DÉMO : iperf parallèle.
Avant / après implémentation (notes cirrostratus) Critère Avant Après Protocoles (NFS/SMB) ●●●○ ●●●○ Élasticité transparente ●●○○ ●●●○ Débit inclus ●●●● ●●●● Partage multi-machines ●●●● ●●●● Note globale (moyenne) 3,2/4 · 🥇 1er 3,5/4 · 🥇 1er
RÉALISÉ ÉTAT RÉEL AU 11/10/2026 : 4/4 actions réalisées (100 %) — preuve : couverture applicative confrontée à l'inventaire réel (t4S/t5W) · catalogue de recherche daté (t6J) · tests de restauration auto (T19G/T19J) : plan validé contre les plans réels, fenêtre cron calculée, verdicts OK ≥ 99,5 %/PARTIEL écart cité/ÉCHEC aux chiffres ; réplication hors site = BLOQUÉ MATÉRIEL (site OVH engagé 04/10) · réplication hors site PREUVE 06/10 : sha256 identiques lab1↔OVH (a06b6f4a…, 3,1 Go) + timer quotidien 04:15 ; backup natif du plan de contrôle DÉPLOYÉ 06/10 (0.134.0) et PROUVÉ : ferrodb backup --compact 8,9 Go/10 fichiers/244 s, trap EXIT (nœud jamais laissé arrêté), alerte ntfy — après 4 échecs du tar à chaud (02→05/10, audit.log 1,1 Go mouvant) affichés tels quels puis corrigés ; maintenance livrée : audit.log 1050→0 Mo, 1 .sst.tmp purgé
Solution sous-jacente & licences plans moteur maison (référentiel cirrostratus, Rust — code privé du projet) ; vzdump/Proxmox (AGPL-3.0) pour les sauvegardes machine.
Actions : descriptif · effort · recette (cas d’usage / preuve / démo) Action Effort Recette de validation A1 Réplication hors site automatique des plans critiques (second site / cirroGlacier).P3 · 1-2 sem CAS : plan critique répliqué hors site · PREUVE : archive présente sur le second site (empreinte) · DÉMO : ls distant + sha256. A2 Tests de restauration automatiques programmés (restaurer une machine témoin la nuit, verdict dans les compteurs).P3 · 1-2 sem CAS : test de restauration auto nocturne · PREUVE : verdict PASS/FAIL du restaurant dans les compteurs du plan · DÉMO : compteur honnête. A3 Couverture applicative : exporter aussi les configs des services (apps, DNS, topics) dans le plan.P2 · 2-4 j CAS : backup incluant configs apps/DNS/topics · PREUVE : bundle re-déployable (import à blanc) · DÉMO : import en sablière. A4 Catalogue de recherche : retrouver le fichier/dossier dans N sauvegardes sans monter chacune.P3 · 1-2 sem CAS : recherche d'un fichier dans 30 sauvegardes · PREUVE : résultat en secondes avec dates · DÉMO : requête + réponse.
Avant / après implémentation (notes cirrostratus) Critère Avant Après Couverture multi-services ●●●○ ●●●○ Réplication hors site ●●○○ ●●●● Honnêteté des compteurs ●●●● ●●●● Test de restauration ●●●● ●●●● Note globale (moyenne) 3,2/4 · 🥇 1er 3,8/4 · 🥇 1er
04 Bases de données & analytiqueRÉALISÉ ÉTAT RÉEL AU 11/10/2026 : 5/5 actions réalisées (100 %) — preuve : PITR journal validé + répliques de lecture à retard mesuré (t6H) · analyse pg_dump honnête (t3N) · ARBITRAGE 02/10 (1.a) LIVRÉ : offre PostgreSQL managé 18.6 épinglée (docker run mot de passe FICHIER, garde anti-clair/anti-latest, plans dérivés) + harnais pgwire 12 cas verdicts écarts nommés (T19B, câblé T19E)
Solution sous-jacente & licences moteur A FerroDB (moteur maison (référentiel cirrostratus, Rust — code privé du projet), Raft) + protocole PostgreSQL-wire ; option PostgreSQL 16 (licence PostgreSQL) à la marketplace.
Actions : descriptif · effort · recette (cas d’usage / preuve / démo) Action Effort Recette de validation A1 Approfondir le SQL moteur A (jointres complexes, index secondaires riches, agrégats avancés) — l'écart PostgreSQL reste le point dur.P4 · > 6 sem CAS : requête lourde multi-jointures + agrégats · PREUVE : résultat identique à PostgreSQL de référence (harnais SQL diff) · DÉMO : rapport de diff. A2 Répliques en lecture scalables pour répartir les charges analytiques.P3 · 1-2 sem CAS : bascule lecture vers réplique · PREUVE : SELECT servis par la réplique (identité exposée), écritures au primaire · DÉMO : métriques par nœud. A3 Point-in-time recovery (PITR) au-delà des snapshots, avec rétention fine.P3 · 1-2 sem CAS : PITR à T-7 min · PREUVE : données restaurées à la minute près (ligne insérée à T-8 absente) · DÉMO : count avant/après. A4 Outiller la migration depuis PostgreSQL/MySQL managés (import pg_dump guidé, vérification de schéma).P2 · 2-4 j CAS : import pg_dump 1 Go guidé · PREUVE : schéma vérifié, lignes comptées, incompatibilités listées · DÉMO : rapport d'import. A5 Pilotes et ORMs documentés + harnais de compatibilité pgwire publié (diffs vs PostgreSQL).P2 · 2-4 j CAS : suite de compatibilité pgwire publiée · PREUVE : % de requêtes passing affiché par version · DÉMO : badge du harnais.
Avant / après implémentation (notes cirrostratus) Critère Avant Après Performance brute / moteur ●●○○ ●●●○ Compatibilité clients ●●●● ●●●● Disponibilité (réplication) ●●●● ●●●● Sécurité au niveau moteur ●●●● ●●●● Coût prévisible ●●●● ●●●● Fonctions avancées (time travel) ●●●● ●●●● Note globale (moyenne) 3,7/4 · 🥇 1er 3,8/4 · 🥇 1er
RÉALISÉ ÉTAT RÉEL AU 11/10/2026 : 4/4 actions réalisées (100 %) — preuve : parallélisation prouvée + vues matérialisées (t5D/t6H) · files de concurrence : priorités 1-5 préemption de la vieille priorité-5, anti-famine +1 après 5 tours DIT (T19M/O)
Solution sous-jacente & licences moteur FerroQuery (moteur maison (référentiel cirrostratus, Rust — code privé du projet)) sur pods réels ; export Parquet via Apache Arrow (Apache-2.0).
Actions : descriptif · effort · recette (cas d’usage / preuve / démo) Action Effort Recette de validation A1 Index colonne et exécution parallèle pour diviser la latence (objectif seconde, pas dizaine).P4 · 3-6 sem CAS : scan 100 M lignes filtré par partition · PREUVE : latence divisée ×N vs non-partitionné (mesurée) · DÉMO : timings comparés. A2 Vues matérialisées incrémentales (rafraîchir seulement le delta).P3 · 1-2 sem CAS : vue matérialisée rafraîchie sur delta · PREUVE : refresh incrémental < temps de rebuild complet · DÉMO : chronométrages. A3 Connecteurs d'ingestion : fichiers Parquet/CSV depuis cirroS3, API HTTP, flux.P2 · 2-4 j CAS : ingestion Parquet depuis cirroS3 · PREUVE : lignes comptées = attendu · DÉMO : CREATE EXTERNAL + count. A4 Concurrence de requêtes (files par entrepôt avec priorités).P3 · 1-2 sem CAS : 4 requêtes simultanées avec priorités · PREUVE : file d'attente respectée, aucune famine · DÉMO : journal du planificateur.
Avant / après implémentation (notes cirrostratus) Critère Avant Après Modèle de facturation ●●●● ●●●● Latence de requête ●●○○ ●●●○ Séparation stockage/calcul ●●●○ ●●●● Standard SQL / portabilité ●●●○ ●●●● Note globale (moyenne) 3,0/4 · 3e 3,8/4 · 2e
#18 NoSQL clé-valeur à grande échelleposition : 3,2/4 · 1er → 3,2/4 · 1er
fiche comparatif → RÉALISÉ ÉTAT RÉEL AU 11/10/2026 : 4/4 actions réalisées (100 %) — preuve : tables+entrées CRUD à TTL délégué + chaque mutation → événement cirroFlux curseur/dédup/lacune nommée (P8), câblé routes kv (W9) et prouvé e2e kv CRUD+journal (E10/T10) + outils MCP/CLI kv (M12/L12) · cycle complet rejoué en PROD 0.123.0 (recette 11/11, table ensuite supprimée) · perf par-entrée ADOPTÉE en production des routes (B14/B15) : ×196 serde mesuré, ×65 HTTP réel à 2,23 ms/req INDÉPENDANT de la taille de famille · position lab/PME assumée (t1D) · offre TiKV v8.5.0 LTS ÉPINGLÉ Apache-2.0 Rust (0.129.0) : CR cluster rendu entier (3 tikv + 3 PD Raft), mapping honnête (TTL RESTE cirroKV DIT), état réel pods ; tables globales multi-sites = RÉPLICATION Raft inter-sites ARMÉE EN PROD 06/10 (nœud 2 OVH, 3 bugs moteur corrigés, écriture site A lue LOCALEMENT site B : seq-1..5 contigus)
Solution sous-jacente & licences moteur maison (référentiel cirrostratus, Rust — code privé du projet) (cirroKV : tables, TTL délégué, journal cirroFlux) + offre managée TiKV v8.5.0 LTS épinglé (Apache-2.0, CNCF gradué, Rust — Raft, scale-out, géo-réplication).
Actions : descriptif · effort · recette (cas d’usage / preuve / démo) Action Effort Recette de validation A1 Créer l'offre : magasin clé-valeur managé (moteur embarqué type RocksDB/redb) exposé en API DynamoDB-like.P4 · 3-6 sem CAS : table clé-valeur créée, 100 k puts/get · PREUVE : latences p95 mesurées et publiées · DÉMO : bench maison. A2 TTL natif par item et streams de modifications (changements propagés vers cirroFlux).P2 · 2-4 j CAS : TTL 60 s posé sur des items · PREUVE : disparition auto après expiration (count vérifié) · DÉMO : count à T+61 s. A3 Tables globales locales multi-sites (réplication active entre les deux datacenters).P3 · 1-2 sem CAS : écriture site A lisible site B · PREUVE : réplication mesurée (délai affiché) · DÉMO : écriture/lecture inter-sites. A4 Cibler honnêtement le segment lab/PME — ne pas prétendre au million d'IOPS.P1 · ≤ 1 j CAS : page honnête des limites (cible lab) · PREUVE : documentation « ne pas prétendre au M IOPS » présente · DÉMO : lien doc.
Avant / après implémentation (notes cirrostratus) Critère Avant Après Latence à l'échelle ●●●○ ●●●○ Modèle de coût ●●●● ●●●● Requêtes secondaires ●●○○ ●●○○ Cas d'usage en lab/PME ●●●● ●●●● Note globale (moyenne) 3,2/4 · 🥇 1er 3,2/4 · 🥇 1er
RÉALISÉ ÉTAT RÉEL AU 11/10/2026 : 3/3 actions réalisées (100 %) — preuve : cirroCache création 1 commande + réplique à perte chiffrée (t3N) · ACL redis règles distinctes (t1D) · moteur Valkey 9.1.0 ÉPINGLÉ BSD-3 (0.126.0) : docker run exact par plan (maxmemory/éviction/AOF/port localhost) rendu jamais exécuté + GET /cache/offre honnête (plans chiffrés, ACL, supervision PING mesurée)
Solution sous-jacente & licences cirroCache sur Valkey 9.1.0 épinglé (BSD-3-Clause, fork Linux Foundation de Redis 7.2.4 — resté libre quand Redis passe tri-licence RSAL/SSPL/AGPL) ; compatible Redis OSS 7.2 (RESP, ACL, redis-cli) ; image docker.io/valkey/valkey:9.1.0, jamais latest.
Actions : descriptif · effort · recette (cas d’usage / preuve / démo) Action Effort Recette de validation A1 Produire un cache managé (cirroCache) à partir de redis-7 : création en commande, restart automatique, métriques.P2 · 2-4 j CAS : cache managé créé en 1 commande, process tué · PREUVE : restart automatique, ping-pong invisible pour l'app · DÉMO : courbe dispo. A2 Réplication cache (réplique chaude + bascule) et persistance optionnelle AOF.P2 · 2-4 j CAS : bascule réplique chaude · PREUVE : erreurs ≈ 0 pendant la bascule (compteur) · DÉMO : compteur d'erreurs. A3 Auth par token et ACL (qui peut lire/écrire quelle base).P1 · ≤ 1 j CAS : deux utilisateurs, ACL distinctes · PREUVE : l'un écrit, l'autre reçoit NOPERM · DÉMO : sorties comparées.
Avant / après implémentation (notes cirrostratus) Critère Avant Après Opération managée ●●●○ ●●●● Coût Go mémoire ●●●● ●●●● Réplication cluster ●●○○ ●●●○ Compatibilité Redis ●●●● ●●●● Note globale (moyenne) 3,2/4 · 2e 3,8/4 · 🥇 1er
#20 SQL serverless sur le stockage objetposition : 3,5/4 · 1er → 3,8/4 · 1er
fiche comparatif → RÉALISÉ ÉTAT RÉEL AU 11/10/2026 : 3/3 actions réalisées (100 %) — preuve : sources arbitraires CSV/JSON typées + parallélisation + requêtes nommées/export ré-exécuté (t5D/t3N/t6W)
Solution sous-jacente & licences moteur maison (référentiel cirrostratus, Rust — code privé du projet) (SQL lecture seule sur les tables du plan de contrôle, FerroDB).
Actions : descriptif · effort · recette (cas d’usage / preuve / démo) Action Effort Recette de validation A1 Interroger des sources arbitraires : buckets cirroS3 externes (Parquet/CSV/JSON), pas seulement le plan de contrôle.P3 · 1-2 sem CAS : SELECT sur bucket Parquet externe 5 Go · PREUVE : lignes comptées, délai affiché honnêtement · DÉMO : requête + réponse. A2 Parallélisation des scans multi-parties et pushdown des projections.P3 · 1-2 sem CAS : projection d'une colonne sur 100 colonnes · PREUVE : volume scanné réduit (Mo comptés affichés) · DÉMO : compteur de scan. A3 Sauvegarde des requêtes nommées + résultats exportables (CSV/Parquet).P2 · 2-4 j CAS : requête nommée sauvegardée, ré-exécutée · PREUVE : même résultat, export CSV/Parquet · DÉMO : fichier exporté.
Avant / après implémentation (notes cirrostratus) Critère Avant Après Coût par requête ●●●● ●●●● Couverture des sources ●●○○ ●●●○ Limite de sécurité ●●●● ●●●● Cold start ●●●● ●●●● Note globale (moyenne) 3,5/4 · 🥇 1er 3,8/4 · 🥇 1er
RÉALISÉ ÉTAT RÉEL AU 11/10/2026 : 4/4 actions réalisées (100 %) — preuve : multi-sources jointure canonique + étapes conteneurisées + micro-lots (t5D) · lineage BFS amont/aval (t2V)
Solution sous-jacente & licences moteur maison (référentiel cirrostratus, Rust — code privé du projet) (source SQL → table etl_ matérialisée).
Actions : descriptif · effort · recette (cas d’usage / preuve / démo) Action Effort Recette de validation A1 Transformations multi-sources (plusieurs SQL sources + HTTP + fichiers) avec étapes de mapping.P3 · 1-2 sem CAS : pipeline 2 sources SQL + 1 HTTP · PREUVE : lignes fusionnées comptées par source · DÉMO : journal du pipeline. A2 API de transformation personnalisée (conteneur d'étape) pour les règles métier.P3 · 1-2 sem CAS : étape conteneurisée de transformation métier · PREUVE : sortie transformée vérifiée dans etl_ · DÉMO : échantillon avant/après. A3 Mode streaming (micro-lots) en complément du batch planifié.P3 · 1-2 sem CAS : micro-lots toutes les 5 min · PREUVE : latence bout-en-bout < 6 min mesurée · DÉMO : horodatages. A4 UI de visualisation du lineage (quelle table alimente quel rapport).P2 · 2-4 j CAS : lineage table→rapport · PREUVE : graphe de dépendances rendu par l'API · DÉMO : sortie lineage.
Avant / après implémentation (notes cirrostratus) Critère Avant Après Connecteurs d'entreprise ●●○○ ●●●○ Streaming + batch unifiés ●●○○ ●●○○ Transparence des chargements ●●●● ●●●● Coût à l'usage ●●●● ●●●● Note globale (moyenne) 3,0/4 · 🥇 1er 3,2/4 · 🥇 1er
RÉALISÉ ÉTAT RÉEL AU 11/10/2026 : 4/4 actions réalisées (100 %) — preuve : requêtes nommées + alerting + job PDF SMTP réel (t3N) · offre Grafana managé : datasource FerroQuery réelle + dashboard un panel par requête EXISTANTE, version à substitution explicite refusée si floue (T19M/O)
Solution sous-jacente & licences moteur maison (référentiel cirrostratus, Rust — code privé du projet) (rapports planifiés CSV/API) ; visualisation : Grafana (AGPL-3.0).
Actions : descriptif · effort · recette (cas d’usage / preuve / démo) Action Effort Recette de validation A1 Dashboards interactifs en produit : intégrer Grafana comme face BI (variables, drill-down) au-dessus de FerroQuery.P3 · 1-2 sem CAS : dashboard interactif avec variables au-dessus de FerroQuery · PREUVE : filtre appliqué < 2 s · DÉMO : capture dashboard. A2 Exports PDF/planifiés par e-mail (cirroCourrier) des rapports.P2 · 2-4 j CAS : rapport PDF envoyé par cirroCourrier le lundi 8h · PREUVE : courriel reçu avec pièce jointe · DÉMO : courriel. A3 Requêtes nommées partageables + sémantique légère (métriques calculées définies une fois).P2 · 2-4 j CAS : métrique calculée définie une fois, réutilisée · PREUVE : même définition dans 2 dashboards · DÉMO : extraits. A4 Alerting sur seuils de rapport (chiffre d'affaires, stock, coût).P2 · 2-4 j CAS : seuil dépassé → alerte · PREUVE : notification reçue (topic) avec valeur · DÉMO : message d'alerte.
Avant / après implémentation (notes cirrostratus) Critère Avant Après Richesse de visualisation ●●○○ ●●●○ Modèle sémantique versionné ●●○○ ●●○○ Coût par utilisateur ●●●● ●●●● Distribution automatisée ●●●● ●●●● Note globale (moyenne) 3,0/4 · 3e 3,2/4 · 2e
RÉALISÉ ÉTAT RÉEL AU 11/10/2026 : 4/4 actions réalisées (100 %) — preuve : shards écart ≤ 1 + bascule (t5D/t6W) · pont flux→entrepôt + relecture dédup par séquence (t3N) ; réplication second site non entamée
Solution sous-jacente & licences moteur cirroFlux (moteur maison (référentiel cirrostratus, Rust — code privé du projet)) : partitions, rétention, curseurs.
Actions : descriptif · effort · recette (cas d’usage / preuve / démo) Action Effort Recette de validation A1 Shards distribués (plusieurs partitions par machine) pour augmenter le débit agrégé.P3 · 1-2 sem CAS : 3 partitions sur 2 machines, débit ×2 · PREUVE : t/s agrégés mesurés vs 1 partition · DÉMO : bench de débit. A2 Réplication du flux vers le second site (durabilité multi-site).P3 · 1-2 sem CAS : écriture site A, reprise site B · PREUVE : aucun enregistrement perdu (séquences contiguës) · DÉMO : vérif séquences. A3 Consommateurs managés : bridge cirroFlux → FerroQuery (ingestion continue sans code).P2 · 2-4 j CAS : bridge cirroFlux→FerroQuery sans code · PREUVE : lignes apparaissant dans l'entrepôt en continu · DÉMO : count croissant. A4 Interface de relecture visuelle (choisir un curseur, rejouer une fenêtre).P2 · 2-4 j CAS : relecture d'une fenêtre via curseur choisi · PREUVE : mêmes événements rejoués (dédup possible par seq) · DÉMO : double lecture.
Avant / après implémentation (notes cirrostratus) Critère Avant Après Ordre garanti par clé ●●●● ●●●● Replay / reprise ●●●● ●●●● Débit maximal ●●○○ ●●●○ Coût ●●●● ●●●● Note globale (moyenne) 3,5/4 · 🥇 1er 3,8/4 · 🥇 1er
PARTIEL ÉTAT RÉEL AU 11/10/2026 : 3/4 actions réalisées (75 %) — preuve : rétention playlist reconstruite des seuls segments restants (t3N) · signaling WebRTC — aucun média relayé, DIT (t6H/W7) · mosaïque (t6H) ; détection de mouvement non entamée
Solution sous-jacente & licences ffmpeg (LGPL-2.1+/GPL-2+ selon build) piloté par moteur maison (référentiel cirrostratus, Rust — code privé du projet) ; playlists HLS construites des segments réels.
Actions : descriptif · effort · recette (cas d’usage / preuve / démo) Action Effort Recette de validation A1 Détection de mouvement locale (événements vers cirroRegles, enregistrement conditionné).P3 · 1-2 sem CAS : caméra + détection de mouvement · PREUVE : événement cirroRegles émis, segment marqué · DÉMO : événement + clip. A2 Latence sous-la-seconde optionnelle (WebRTC) pour la supervision en direct.P4 · 3-6 sem CAS : latence sous-la-seconde en WebRTC · PREUVE : mesure chrono (affichage vs réel) < 1 s · DÉMO : vidéo comparative. A3 Rétention configurable par flux + export d'extraits (clip d'incident).P2 · 2-4 j CAS : rétention 7 j par flux, purge observée · PREUVE : les segments > 7 j disparaissent (playlist honnête) · DÉMO : ls avant/après. A4 Agrégation multi-caméras (mosaïque HLS composée).P3 · 1-2 sem CAS : mosaïque 4 caméras · PREUVE : flux composé servi (1 playlist, 4 vues) · DÉMO : capture.
Avant / après implémentation (notes cirrostratus) Critère Avant Après Ingestion RTSP native ●●●● ●●●● Replay HLS ●●●● ●●●● Coût de la vidéosurveillance 24/7 ●●●● ●●●● Honnêteté du flux ●●●● ●●●● Note globale (moyenne) 4,0/4 · 🥇 1er 4,0/4 · 🥇 1er
RÉALISÉ ÉTAT RÉEL AU 11/10/2026 : 4/4 actions réalisées (100 %) — preuve : retry/catch PAR étape (t2V) · worker continu + vue graphique ASCII + rejeu depuis étape avec contexte (t18A) · offre Argo Workflows 4.0.0 ÉPINGLÉ Apache-2.0 (0.128.0) : plan d'installation exact avec sa garde, manifeste Argo généré par workflow (URL réelles, retryStrategy porté, conditions en when, catchs dits), état réel pods du cluster
Solution sous-jacente & licences moteur maison (référentiel cirrostratus, Rust — code privé du projet) (étapes webhook/fonction/publication, retry/catch par étape, rejeu) + offre managée Argo Workflows 4.0.0 épinglé (Apache-2.0, CNCF gradué, k8s-natif) pour les DAG conteneurisés.
Actions : descriptif · effort · recette (cas d’usage / preuve / démo) Action Effort Recette de validation A1 Worker continu optionnel : exécution immédiate des étapes (le tick 30 s en mode éco).P3 · 1-2 sem CAS : workflow 3 étapes en mode worker continu · PREUVE : étape suivante < 1 s (vs 30 s en tick) · DÉMO : chronométrage. A2 Retry/catch par étape (politiques d'erreur granulaires, pas seulement en chaîne).P2 · 2-4 j CAS : étape en échec avec retry 3×/backoff · PREUVE : 3 tentatives journalisées puis catch · DÉMO : journal. A3 Vue graphique du déroulé (état de chaque exécution par étape).P2 · 2-4 j CAS : vue graphique de l'exécution · PREUVE : chaque étape colorée par état · DÉMO : capture. A4 Historique long terme exportable + rejouer une exécution depuis une étape.P2 · 2-4 j CAS : reprise depuis l'étape 2 d'un run échoué · PREUVE : étape 1 non rejouée (journal), suite OK · DÉMO : journal du re-run.
Avant / après implémentation (notes cirrostratus) Critère Avant Après Patrons d'erreur (retry/catch) ●●●○ ●●●● Temps de réaction ●●○○ ●●●○ Coût par exécution ●●●● ●●●● Connecteurs prêts ●●●○ ●●●○ Visibilité des exécutions ●●●○ ●●●● Note globale (moyenne) 3,0/4 · 2e 3,6/4 · 🥇 1er
05 Réseau & diffusionRÉALISÉ ÉTAT RÉEL AU 11/10/2026 : 4/4 actions réalisées (100 %) — preuve : security groups ÉTATFULS (t5N) · mesh inter-sites BFS (t5N) · flow logs top talkers (t4R) · tables plus-long-préfixe (t4R)
Solution sous-jacente & licences bridges/veth Linux (GPL-2.0 noyau) + dnsmasq (GPL-2.0/GPL-3.0) ; SDN/IPAM moteur maison (référentiel cirrostratus, Rust — code privé du projet).
Actions : descriptif · effort · recette (cas d’usage / preuve / démo) Action Effort Recette de validation A1 Security groups étatiques par machine/rôle (filtrage east-west dans le réseau).P3 · 1-2 sem CAS : security group : VM A→B:4444 refusé, :443 OK · PREUVE : paquets bloqués visibles (compteur de règle) · DÉMO : tcpdump compté. A2 Interconnexion multi-sites automatique (mesh VPN entre les deux datacenters, routes propagées).P3 · 1-2 sem CAS : mesh auto entre 2 sites, routes propagées · PREUVE : ping intersites sans config manuelle de pair · DÉMO : traceroute. A3 Flow logs natifs vers l'observabilité (qui a parlé à qui, quand).P2 · 2-4 j CAS : flow logs activés · PREUVE : conversations IP visibles dans l'observabilité · DÉMO : requête Loki. A4 Sous-réseaux par zones et règles de routage riches (pas seulement la passerelle).P2 · 2-4 j CAS : 2 sous-réseaux + règle de routage · PREUVE : table de routage appliquée (chemin vérifié) · DÉMO : traceroute.
Avant / après implémentation (notes cirrostratus) Critère Avant Après Modèle de portée ●●●○ ●●●○ IPAM intégré ●●●● ●●●● Coûts cachés (NAT, egress AZ) ●●●● ●●●● Hybride on-prem ●●●● ●●●● Note globale (moyenne) 3,8/4 · 🥇 1er 3,8/4 · 🥇 1er
RÉALISÉ ÉTAT RÉEL AU 11/10/2026 : 4/4 actions réalisées (100 %) — preuve : console complète SRV/PTR/AAAA/TXT (t2Y) · zone inverse (t2Y) + DNS interne par carte (t4R) · AXFR aller-retour diff nul (t1C) · géo/latence déterministe (t5N)
Solution sous-jacente & licences zones/records moteur maison (référentiel cirrostratus, Rust — code privé du projet) ; résolution dnsmasq (GPL-2.0/GPL-3.0) ; bascule par surveillant maison.
Actions : descriptif · effort · recette (cas d’usage / preuve / démo) Action Effort Recette de validation A1 Console complète des enregistrements (TTL, TXT, MX, SRV…) avec validation.P2 · 2-4 j CAS : création TXT/SRV/MX avec TTL custom · PREUVE : dig rend les enregistrements exacts · DÉMO : dig +answer. A2 Zone de recherche inverse (PTR) et DNS interne auto-alimenté par cirroCarte.P2 · 2-4 j CAS : PTR résolu pour une VM · PREUVE : dig -x rend le nom cirro · DÉMO : sortie dig. A3 Transferts de zone (AXFR) pour importer des zones existantes.P1 · ≤ 1 j CAS : import AXFR d'une zone externe · PREUVE : enregistrements identiques après import (diff nul) · DÉMO : diff. A4 Routing par géo/latence si les deux sites deviennent actifs simultanément.P3 · 1-2 sem CAS : routing géo entre 2 sites actifs · PREUVE : résolutions distinctes selon la source · DÉMO : dig depuis 2 sources.
Avant / après implémentation (notes cirrostratus) Critère Avant Après Routage avancé (géo, latence) ●●○○ ●●●○ Anycast mondial ●●○○ ●●○○ Bascule automatique ●●●● ●●●● Coût par zone/requête ●●●● ●●●● Note globale (moyenne) 3,0/4 · 3e 3,2/4 · 2e
RÉALISÉ ÉTAT RÉEL AU 11/10/2026 : 4/4 actions réalisées (100 %) — preuve : failover d'origines + règles NACL + p95 temps réel (t4R) · invalidation par préfixe comptée (t1C/t2W)
Solution sous-jacente & licences cache inverse moteur maison (référentiel cirrostratus, Rust — code privé du projet) (statistiques hits/misses mesurées).
Actions : descriptif · effort · recette (cas d’usage / preuve / démo) Action Effort Recette de validation A1 Origines multiples avec failover automatique d'origine.P2 · 2-4 j CAS : origine A en panne, bascule origine B · PREUVE : service continu (hits comptés sur B) · DÉMO : courbe hits/origines. A2 Invalidation par chemin (purger une ressource précise) — geste indispensable absent.P1 · ≤ 1 j CAS : invalidation /img/logo.png · PREUVE : miss au premier GET suivant, 200 du nouveau · DÉMO : statuts Cache avant/après. A3 Règles de cache avancées (par en-tête, cookie, query).P2 · 2-4 j CAS : règle « pas de cache si cookie=session » · PREUVE : requêtes avec cookie → origin à chaque fois · DÉMO : journal origin. A4 Statistiques temps réel (pas seulement agrégées) et quotas par consommateur.P2 · 2-4 j CAS : quota 100 req/min par consommateur · PREUVE : 429 au-delà, compteur par clé · DÉMO : courbe de charge.
Avant / après implémentation (notes cirrostratus) Critère Avant Après Couverture mondiale ●●○○ ●●○○ Statistiques réelles ●●●● ●●●● Fonctions en edge ●○○○ ●●○○ Coût ●●●● ●●●● Note globale (moyenne) 2,8/4 · 4e 3,0/4 · 2e
RÉALISÉ ÉTAT RÉEL AU 11/10/2026 : 4/4 actions réalisées (100 %) — preuve : sondes actives + L4 FNV + cibles par carte (t4R) · offre cirroLB Traefik v3.7.13 épinglée (Apache-2.0) : config TOML générée des LB réels, dashboard fermé, garde anti-latest (T19C, câblé T19E)
Solution sous-jacente & licences cible : Traefik (MIT) en produit managé — prouvé au banc avec TLS.
Actions : descriptif · effort · recette (cas d’usage / preuve / démo) Action Effort Recette de validation A1 Produire cirroLB : Traefik managé (création en commande, config générée, certs auto via banc TLS).P3 · 1-2 sem CAS : cirroLB créé en 1 commande derrière 2 apps · PREUVE : requêtes réparties (compteurs par backend) · DÉMO : compteurs. A2 Health checks actifs par backend + drain propre des instances sortantes.P2 · 2-4 j CAS : backend 1 sur 2 tué · PREUVE : retrait du pool, 0 erreur client (health check) · DÉMO : courbe erreurs. A3 L4 (TCP) en plus du L7, et sticky sessions optionnelles.P2 · 2-4 j CAS : flux TCP brut équilibré (L4) · PREUVE : connexions réparties sur 2 sockets · DÉMO : ss -s par backend. A4 Intégration cirroCarte : backends découverts par nom de service.P2 · 2-4 j CAS : backends découverts via cirroCarte · PREUVE : nouveau service nommé → intégré au pool sans reconf · DÉMO : ajout + listing.
Avant / après implémentation (notes cirrostratus) Critère Avant Après L4 + L7 unifiés — — Anycast global — — Coût à fort débit — — Simplicité de config — — Note globale (moyenne) — —
RÉALISÉ ÉTAT RÉEL AU 11/10/2026 : 4/4 actions réalisées (100 %) — preuve : full-mesh clés publiques seules + HA deux muettes refusées (t5N) · profils expirants exigés 403 (t4R/t5W) · état de tunnel dérivé, compteurs en arrière refusés (t4R)
Solution sous-jacente & licences WireGuard (noyau GPL-2.0 ; wireguard-tools MIT) + wg-quick ; état des peers moteur maison (référentiel cirrostratus, Rust — code privé du projet).
Actions : descriptif · effort · recette (cas d’usage / preuve / démo) Action Effort Recette de validation A1 Mesh automatique entre sites (les deux datacenters se joignent sans config manuelle par pair).P3 · 1-2 sem CAS : 2 sites joints automatiquement (mesh) · PREUVE : handshake sans config de pair, ping OK · DÉMO : états des peers. A2 Génération de profils clients (mobile/laptop) à la volée avec expiration.P2 · 2-4 j CAS : profil client généré avec expiration 30 j · PREUVE : connexion refuse après expiration · DÉMO : tentative post-expiration. A3 Monitoring de débit et de qualité par tunnel (pas seulement les handshakes).P2 · 2-4 j CAS : monitoring débit par tunnel · PREUVE : Mo/s affichés en continu (iptraf-like) · DÉMO : capture métriques. A4 Haute disponibilité : deux gateways par site avec bascule.P3 · 1-2 sem CAS : gateway secondaire basculée · PREUVE : interruption < 5 s mesurée · DÉMO : ping continu.
Avant / après implémentation (notes cirrostratus) Critère Avant Après Protocole ●●●● ●●●● Débit ●●●● ●●●● Visibilité des pairs ●●●● ●●●● Coût ●●●● ●●●● Note globale (moyenne) 4,0/4 · 🥇 1er 4,0/4 · 🥇 1er
RÉALISÉ ÉTAT RÉEL AU 11/10/2026 : 4/4 actions réalisées (100 %) — preuve : alerte pool ≥ 90 % + export CSV RFC 4180 (t1C) · recherche globale multi-réseaux + historique des baux + réservation à la source refus nommant l'IP/le détenteur/la plage (T19C, câblé T19E)
Solution sous-jacente & licences moteur maison (référentiel cirrostratus, Rust — code privé du projet) (baux DHCP lus, réservations, pools libres).
Actions : descriptif · effort · recette (cas d’usage / preuve / démo) Action Effort Recette de validation A1 Recherche globale multi-réseaux (« où est .23 ? ») et historique des attributions (qui a eu cette IP, quand).P2 · 2-4 j CAS : recherche « .23 » multi-réseaux · PREUVE : toutes les machines .23 listées avec réseau · DÉMO : réponse API. A2 Réservation depuis l'API de création de machine (contrôle à la source).P2 · 2-4 j CAS : réservation IP à la création de VM · PREUVE : la VM reçoit l'IP réservée (lue, pas déduite) · DÉMO : vms_ls. A3 Alertes de pool presque plein et suggestions de ré-agencement CIDR.P1 · ≤ 1 j CAS : pool à 90 % · PREUVE : alerte levée avec seuil affiché · DÉMO : alerte. A4 Export CSV/JSON de l'inventaire d'adressage pour audits.P1 · ≤ 1 j CAS : export CSV complet · PREUVE : colonnes complètes, réimportable · DÉMO : fichier.
Avant / après implémentation (notes cirrostratus) Critère Avant Après Échelle de gestion ●●●○ ●●●● Véracité des données ●●●● ●●●● Détection des conflits ●●●● ●●●● Coût ●●●● ●●●● Note globale (moyenne) 3,8/4 · 🥇 1er 4,0/4 · 🥇 1er
RÉALISÉ ÉTAT RÉEL AU 11/10/2026 : 4/4 actions réalisées (100 %) — preuve : santé par service + retrait jamais exécuté (t4R) · labels en metadata survivant aux régénérations (t1C/t2W) · DNS interne dérivé (t4R) · filtres env (t1C)
Solution sous-jacente & licences registre moteur maison (référentiel cirrostratus, Rust — code privé du projet) (noms <nom>.<org>.cirro, détection de dérive).
Actions : descriptif · effort · recette (cas d’usage / preuve / démo) Action Effort Recette de validation A1 Health checks par nom de service (une instance tombe → retirée de la carte).P2 · 2-4 j CAS : instance arrêtée · PREUVE : retirée de la carte sous le délai configuré · DÉMO : avant/après carte. A2 Métadonnées/labels par service (version, environnement) exploitables en filtre.P1 · ≤ 1 j CAS : filtre par label env=prod · PREUVE : seuls les services prod listés · DÉMO : requête filtrée. A3 DNS interne dérivé (nom.cirro résolu par dnsmasq pour les VMs).P2 · 2-4 j CAS : VM résout un autre service par nom .cirro · PREUVE : dig rend l'IP du service · DÉMO : dig. A4 Environnements multiples (dev/prod) avec préfixes.P2 · 2-4 j CAS : environnements dev/prod préfixés · PREUVE : noms distincts, aucune collision · DÉMO : listings.
Avant / après implémentation (notes cirrostratus) Critère Avant Après Enregistrement automatique ●●●○ ●●●● Recherche par attributs ●●○○ ●●○○ Détection de dérive ●●●● ●●●● Coût ●●●● ●●●● Note globale (moyenne) 3,2/4 · 🥇 1er 3,5/4 · 🥇 1er
#33 Reprise après sinistre multi-siteposition : 4,0/4 · 1er → 4,0/4 · 1er
fiche comparatif → RÉALISÉ ÉTAT RÉEL AU 11/10/2026 : 4/4 actions réalisées (100 %) — preuve : exercices blancs 3 phases verdicts archivés, records intacts (t5N/t6W) · moniteurs par service + runbooks (t4R/t5W) · notifications (t1C) — bascule RÉELLE = geste d'exploitation
Solution sous-jacente & licences surveillant multi-site moteur maison (référentiel cirrostratus, Rust — code privé du projet) (sondes API Proxmox AGPL-3.0, records A pilotés).
Actions : descriptif · effort · recette (cas d’usage / preuve / démo) Action Effort Recette de validation A1 Bascules blanches planifiées automatiquement (test mensuel horodaté, sans production).P3 · 1-2 sem CAS : bascule blanche mensuelle planifiée · PREUVE : verdict horodaté (durée, perte 0) dans l'historique · DÉMO : rapport de test. A2 Moniteurs par service (pas seulement par site) avec priorités de bascule.P2 · 2-4 j CAS : service critique monitoré individuellement · PREUVE : bascule ciblée sans toucher les autres · DÉMO : états par service. A3 Runbooks générés : la procédure de retour documentée à chaque bascule réelle.P2 · 2-4 j CAS : runbook de retour généré après bascule · PREUVE : document avec étapes + vérifications · DÉMO : runbook PDF. A4 Notifications intégrées (cirroTopics) à chaque changement d'état du surveillant.P1 · ≤ 1 j CAS : notification à chaque changement d'état · PREUVE : messages topic reçus (armé/basculé/retour) · DÉMO : messages.
Avant / après implémentation (notes cirrostratus) Critère Avant Après Automatisation de bascule ●●●● ●●●● Anti-oscillation ●●●● ●●●● Retour arrière maîtrisé ●●●● ●●●● Coût de la posture active/passive ●●●● ●●●● Note globale (moyenne) 4,0/4 · 🥇 1er 4,0/4 · 🥇 1er
06 API & intégrationRÉALISÉ ÉTAT RÉEL AU 11/10/2026 : 4/4 actions réalisées (100 %) — preuve : transformation de requête (t5A/t6W) · clés multiples rotation/revocation + journal p50/p95 export + limite/s (t18A)
Solution sous-jacente & licences moteur maison (référentiel cirrostratus, Rust — code privé du projet) (consommateurs, quotas horaires, préfixes de clés).
Actions : descriptif · effort · recette (cas d’usage / preuve / démo) Action Effort Recette de validation A1 Clés multiples par consommateur (rotation sans coupure) et quotas par fenêtre glissante.P2 · 2-4 j CAS : rotation de clé sans coupure · PREUVE : requêtes OK pendant la bascule clé ancienne→nouvelle · DÉMO : courbe sans erreur. A2 Transformation de requête basique (réécriture d'URL, en-têtes) — le minimum attendu d'une gateway.P3 · 1-2 sem CAS : réécriture /v1/→/v2/ declarée · PREUVE : backend voit le nouveau chemin (journal) · DÉMO : journal backend. A3 Journal des requêtes (chemin, statut, latence) exportable vers l'observabilité.P2 · 2-4 j CAS : 100 requêtes, journal complet · PREUVE : chemin+statut+latence pour chacune · DÉMO : extrait du journal. A4 Limites de débit par seconde en plus du quota horaire.P2 · 2-4 j CAS : rafale 50 req/s · PREUVE : 429 au-delà du seuil/seconde · DÉMO : compteur de throttle.
Avant / après implémentation (notes cirrostratus) Critère Avant Après Politiques avancées (transformation, portail) ●●○○ ●●●○ Protection contre facture surprise ●●●● ●●●● Gestion des clés d'API ●●●● ●●●● Coût ●●●● ●●●● Observabilité de l'usage ●●●● ●●●● Note globale (moyenne) 3,6/4 · 🥇 1er 3,8/4 · 🥇 1er
RÉALISÉ ÉTAT RÉEL AU 11/10/2026 : 4/4 actions réalisées (100 %) — preuve : mutations permissionnées exécutant de VRAIES actions (t5A/t6W) · abonnements SSE aller-retour (t5A) · plugins vues mété sans toucher au cœur + complexity limits heuristiques bornées (comptage exact testé, 200 max) (T19H/T19J)
Solution sous-jacente & licences moteur maison (référentiel cirrostratus, Rust — code privé du projet) (endpoint GraphQL lecture seule sur ressources réelles).
Actions : descriptif · effort · recette (cas d’usage / preuve / démo) Action Effort Recette de validation A1 Mutations protégées par permissions explicites (le graphe pourrait écrire sous contrôle).P3 · 1-2 sem CAS : mutation createVm via permission accordée · PREUVE : VM créée ET refusée sans permission · DÉMO : 2 appels contrastés. A2 Abonnements temps réel (SSE/WebSocket) pour les tableaux de bord vivants.P3 · 1-2 sem CAS : abonnement SSE sur vms · PREUVE : événement poussé < 1 s après création · DÉMO : flux SSE capturé. A3 Schéma extensible par plugins (exposer des vues métier sans toucher au cœur).P2 · 2-4 j CAS : plugin exposant une vue métier · PREUVE : champ nouveau interrogeable sans toucher au cœur · DÉMO : requête+réponse. A4 Pagination/complexity limits contre les requêtes coûteuses.P2 · 2-4 j CAS : requête profondeur 10 rejetée · PREUVE : erreur complexity limit · DÉMO : réponse d'erreur.
Avant / après implémentation (notes cirrostratus) Critère Avant Après Existence du service ●●●● ●●●● Abonnements temps réel ●●○○ ●●●○ Sécurité par conception ●●●● ●●●● Coût ●●●● ●●●● Note globale (moyenne) 3,5/4 · 🥇 1er 3,8/4 · 🥇 1er
07 Événementiel & messageriePARTIEL ÉTAT RÉEL AU 11/10/2026 : 3/4 actions réalisées (75 %) — preuve : ordering global + trous nommés (t5D/t6W) · garde SSRF avant POST signé (A14) · DLQ par abonnement avec raison d'échec + compteurs par règle (t18B) ; réplication multi-site = BLOQUÉ MATÉRIEL
Solution sous-jacente & licences fan-out moteur maison (référentiel cirrostratus, Rust — code privé du projet) ; webhooks signés HMAC + files ferroq (Apache-2.0, projet maison open).
Actions : descriptif · effort · recette (cas d’usage / preuve / démo) Action Effort Recette de validation A1 Réplication des topics vers le second site (durabilité).P3 · 1-2 sem CAS : publication site A, abonné site B · PREUVE : livraison intersite comptée · DÉMO : compteurs livrés des 2 sites. A2 Dead-letter native par abonnement (les échecs persistants isolés, pas noyés).P2 · 2-4 j CAS : webhook en échec 10× · PREUVE : événements isolés en DLQ, consultables/rejouables · DÉMO : listing DLQ + rejeu. A3 Ordering global optionnel par topic (pas seulement par clé).P3 · 1-2 sem CAS : topic ordering global · PREUVE : séquences strictement croissantes chez l'abonné · DÉMO : journal de réception. A4 Échelle : partitions internes pour les topics à fort débit.P3 · 1-2 sem CAS : 10 k msg/s soutenus · PREUVE : débit et latence p99 mesurés · DÉMO : bench.
Avant / après implémentation (notes cirrostratus) Critère Avant Après Fan-out massif ●●○○ ●●○○ Intégrité de la livraison ●●●● ●●●● Coût ●●●● ●●●● Simplicité ●●●● ●●●● Note globale (moyenne) 3,5/4 · 🥇 1er 3,5/4 · 🥇 1er
RÉALISÉ ÉTAT RÉEL AU 11/10/2026 : 4/4 actions réalisées (100 %) — preuve : console ferroqd réelle (t14f, 8 opérations, 10 routes, 13 tests) · schéma JSON des messages par protocole + benchmarks PERF.md (t18B) · exactly-once LIVRÉ 11/10 (ferroq : reçus numérotés fsync avant réponse + acquittement 2 temps + dédup éditeur/séquence opt-in par file, 156 tests — supersede 2.a) · SDK Python+TypeScript LIVRÉS 11/10 (parité de noms 45/45, 36 tests chacun sans serveur, transport injectable, zéro dépendance — supersede 3.a ; SDK Go reste ouvert)
Solution sous-jacente & licences ferroq (Apache-2.0 — projet maison publié) : MQTT, STOMP, AMQP 1.0, HTTP, gRPC, QUIC.
Actions : descriptif · effort · recette (cas d’usage / preuve / démo) Action Effort Recette de validation A1 Exactly-once optionnel (idempotence par clé de déduplication).P3 · 1-2 sem CAS : double envoi avec clé de dédup · PREUVE : un seul traitement (exactly-once constaté) · DÉMO : compteurs. A2 SDK/clients documentés multi-langages (Python, Go, JS) au-dessus des 6 protocoles.P2 · 2-4 j CAS : client Python officiel, envoi/réception · PREUVE : round-trip OK en 3 lignes · DÉMO : code + sortie. A3 Console de gestion (parcourir, rejouer, purger) et métriques par file.P2 · 2-4 j CAS : parcourir/rejouer/purger depuis la console · PREUVE : opérations visibles, messages intacts · DÉMO : capture console. A4 Benchmarks publics de débit/latence pour étayer la maturité (134 tests internes → chiffres publiés).P2 · 2-4 j CAS : bench public exécuté (100k messages) · PREUVE : t/s + p95 publiés et reproductibles · DÉMO : rapport de bench.
Avant / après implémentation (notes cirrostratus) Critère Avant Après Garanties de livraison ●●●○ ●●●○ Protocoles de consommation ●●●● ●●●● Durabilité ●●●○ ●●●○ Coût ●●●● ●●●● Maturité ●●○○ ●●●○ Note globale (moyenne) 3,2/4 · 🥇 1er 3,4/4 · 🥇 1er
RÉALISÉ ÉTAT RÉEL AU 11/10/2026 : 4/4 actions réalisées (100 %) — preuve : patterns riches regex/a.b.c/index branchés au routage réel (t5D/t6W) · garde SSRF (A14) · versionnage des règles avec rollback + DLQ par destination (t18B) · métriques par règle compteurs/p95/snapshot trié (T19H/T19J)
Solution sous-jacente & licences règles + test à blanc moteur maison (référentiel cirrostratus, Rust — code privé du projet).
Actions : descriptif · effort · recette (cas d’usage / preuve / démo) Action Effort Recette de validation A1 Patterns riches : regex, attributs imbriqués, opérateurs numériques.P2 · 2-4 j CAS : filtre regex sur payload imbriqué · PREUVE : seuls les événements matching déclenchent · DÉMO : test à blanc. A2 Métriques par règle (déclenchements, succès, échecs) dans l'observabilité.P2 · 2-4 j CAS : 1000 événements filtrés · PREUVE : compteurs par règle exacts · DÉMO : compteurs. A3 Versionner les règles (rollback d'un changement de filtre).P2 · 2-4 j CAS : rollback d'une règle modifiée · PREUVE : version N-1 restaurée en 1 appel · DÉMO : diff de versions. A4 DLQ par destination (destination morte = événement conservé).P2 · 2-4 j CAS : destination en échec → DLQ · PREUVE : événements conservés, visibles · DÉMO : listing.
Avant / après implémentation (notes cirrostratus) Critère Avant Après Filtrage par motif ●●●○ ●●●● Ingestion SaaS tiers ●○○○ ●○○○ Test avant émission ●●●● ●●●● Coût ●●●● ●●●● Note globale (moyenne) 3,0/4 · 🥇 1er 3,2/4 · 🥇 1er
#39 Courtier de messages multi-protocolesposition : 3,8/4 · 1er → 3,8/4 · 1er
fiche comparatif → PARTIEL ÉTAT RÉEL AU 11/10/2026 : 3/4 actions réalisées (75 %) — preuve : pont sujets JSON (W9) + console ferroqd réelle (t14f) · schéma JSON des messages par protocole (t18B) · Kafka binaire LIVRÉ 11/10 (piste 4.b implémentée : handler protocole complet ApiVersions 18/Metadata 3/Produce 0/Fetch 1 + MessageSet v1 + RecordBatch v2, offsets = ordre global ferroq, 27 tests dont produit→consommé — supersede 4.a ; restent l'écoute TCP dans cirrod et la recette kcat) ; réplication multi-site = BLOQUÉ MATÉRIEL
Solution sous-jacente & licences ferroq (Apache-2.0) : un courtier, six protocoles, TLS, cluster.
Actions : descriptif · effort · recette (cas d’usage / preuve / démo) Action Effort Recette de validation A1 Pont Kafka (protocol handler) pour les outils qui ne parlent que Kafka.P4 · 3-6 sem CAS : producteur Kafka Java → consommateur ferroq AMQP · PREUVE : message traversé intact (corrélation d'ID) · DÉMO : journaux 2 bouts. A2 Console de gestion unifiée (files, topics MQTT, abonnements, débits).P3 · 1-2 sem CAS : console files/topics/abonnements · PREUVE : vue unifiée avec débits live · DÉMO : capture. A3 Réplication cluster multi-site automatique.P3 · 1-2 sem CAS : cluster 3 nœuds, nœud tué · PREUVE : élection < 5 s, aucun message perdu · DÉMO : test de panne. A4 Certification de charge publique (latence/débit par protocole).P2 · 2-4 j CAS : certification de charge par protocole · PREUVE : rapport latence/débit publié par protocole · DÉMO : rapport.
Avant / après implémentation (notes cirrostratus) Critère Avant Après Nombre de protocoles natifs ●●●● ●●●● TLS + clustering ●●●○ ●●●○ Cohérence du modèle ●●●● ●●●● Coût ●●●● ●●●● Note globale (moyenne) 3,8/4 · 🥇 1er 3,8/4 · 🥇 1er
RÉALISÉ ÉTAT RÉEL AU 11/10/2026 : 4/4 actions réalisées (100 %) — preuve : expressions complètes + at exact (t2V) · échec sur le bus + topics (t1E/t2W) · verrou anti-chevauchement (t2V) · maintenance 409 au scheduler (t1E/t2W)
Solution sous-jacente & licences moteur maison (référentiel cirrostratus, Rust — code privé du projet) (déclenchements audités + tirage manuel).
Actions : descriptif · effort · recette (cas d’usage / preuve / démo) Action Effort Recette de validation A1 Expressions cron complètes + planification ponctuelle à l'heure exacte (at-once).P2 · 2-4 j CAS : « at 15h42 » exécuté à la minute exacte · PREUVE : horodatage de déclenchement ≠ ±30 s · DÉMO : journal. A2 Notifications d'échec (topic/courrier) sans devoir brancher un webhook soi-même.P1 · ≤ 1 j CAS : tâche en échec · PREUVE : notification reçue avec sortie d'erreur · DÉMO : message. A3 Verrou distribué et anti-chevauchement (une tâche longue ne se relance pas dessus).P2 · 2-4 j CAS : tâche 10 min relancée toutes les 5 min · PREUVE : pas de chevauchement (verrou) · DÉMO : journal séquentiel. A4 Fenêtres de maintenance (ne pas tirer pendant les backups, par exemple).P1 · ≤ 1 j CAS : fenêtre maintenance 02h-04h · PREUVE : tirages reportés après 04h · DÉMO : horodatages.
Avant / après implémentation (notes cirrostratus) Critère Avant Après Précision de la planification ●●●○ ●●●● Rejouabilité ●●●● ●●●● Files d'attente de retards (at/once) ●●○○ ●●●○ Coût ●●●● ●●●● Note globale (moyenne) 3,2/4 · 2e 3,8/4 · 🥇 1er
08 IA & apprentissage automatiqueRÉALISÉ ÉTAT RÉEL AU 11/10/2026 : 5/5 actions réalisées (100 %) — preuve : compat OpenAI 2 sens tools/usage mesuré (t5A) · autoscaling GPU par file (t5A) · cache de préfixes en € (t5A) · burst avec politique de fuite (t6H/W7) · honnêteté simule:true (A15) · catalogue étendu calqué moteurs réels du dépôt (tarifs dérivés TARIFS_LLM, notes de provenance dites) + benchmark publiable (T19I/T19J)
Solution sous-jacente & licences vLLM (Apache-2.0) et llama.cpp (MIT) sur GPUs du site ; alias/fallback moteur maison (référentiel cirrostratus, Rust — code privé du projet) ; modèles GGUF sous licences propres (ex. Qwen Apache-2.0, Llama licence communautaire, Mistral Apache-2.0/Apache-2.0 selon version).
Actions : descriptif · effort · recette (cas d’usage / preuve / démo) Action Effort Recette de validation A1 Déport burst : louer ponctuellement du GPU public derrière les alias (frontend models frontier en pic, données filtrées).P4 · 3-6 sem CAS : alias avec cible GPU public en burst, fallback local · PREUVE : bascule mesurée (journal de routage) quand le burst est coupé · DÉMO : journal d'alias. A2 API 100 % compatible OpenAI (function calling, JSON mode, streaming) pour capter les outils existants.P3 · 1-2 sem CAS : client OpenAI officiel pointé sur l'endpoint · PREUVE : chat + function calling OK sans code modifié · DÉMO : script Python. A3 Autoscaling GPU par longueur de file d'attente (réveil/arrêt des cartes).P3 · 1-2 sem CAS : file d'attente soudaine → GPU supplémentaire · PREUVE : réveil mesuré, latence stabilisée · DÉMO : courbe p95. A4 Cache de prompts/réponses fréquentes (prefix caching) pour réduire le coût réel.P3 · 1-2 sem CAS : même préfixe répété 100× · PREUVE : tokens re-comptés réduits (cache actif) · DÉMO : compteurs. A5 Catalogue étendu documenté (chat, embeddings, rerank) avec benchmarks maison.P2 · 2-4 j CAS : catalogue chat+embeddings+rerank documenté · PREUVE : benchmarks maison par tâche · DÉMO : page catalogue.
Avant / après implémentation (notes cirrostratus) Critère Avant Après Accès aux meilleurs modèles ●●○○ ●●●○ Confidentialité des prompts ●●●● ●●●● Coût par jeton ●●●● ●●●● Résilience multi-modèles ●●●● ●●●● Qualité de service mesurée ●●●● ●●●● Souveraineté réglementaire ●●●● ●●●● Note globale (moyenne) 3,7/4 · 🥇 1er 3,8/4 · 🥇 1er
RÉALISÉ ÉTAT RÉEL AU 11/10/2026 : 5/5 actions réalisées (100 %) — preuve : politiques granulaires lecture-seule-par-défaut + RAG non-inventant + approbation humaine prod (t5A) · budget de jetons (t2Z) · webhooks SHA-256 (t2Z/t3W) · bibliothèque export/import identique (t4I)
Solution sous-jacente & licences moteur maison (référentiel cirrostratus, Rust — code privé du projet) (boucle ReAct, politique lecture seule, évals mécaniques) sur endpoints LLM locaux.
Actions : descriptif · effort · recette (cas d’usage / preuve / démo) Action Effort Recette de validation A1 Politiques d'outils granulaires (cet agent peut redémarrer, pas celui-là) au-delà de la lecture seule globale.P3 · 1-2 sem CAS : agent autorisé à redémarrer, un autre non · PREUVE : ACTION refusée pour le second (politique) · DÉMO : runs contrastés. A2 Base de connaissance RAG native (documents indexés par ferroKB exposés aux agents).P2 · 2-4 j CAS : question dont la réponse est dans les documents indexés · PREUVE : réponse sourcée (fichier + passage) · DÉMO : échange. A3 Budget de jetons par run (un agent qui boucle se coupe tout seul).P2 · 2-4 j CAS : agent bouclant sur un outil · PREUVE : run coupé au budget de jetons, cause visible · DÉMO : journal du run. A4 Déclencheurs entrants (webhook, calendrier) pour agents autonomes planifiés.P2 · 2-4 j CAS : agent déclenché par webhook entrant · PREUVE : run créé automatiquement à l'appel · DÉMO : curl → run. A5 Bibliothèque d'agents modèles exportables (ops, veille, support).P2 · 2-4 j CAS : export/import d'un agent modèle · PREUVE : réimporté avec mêmes outils/mémoire · DÉMO : manifeste.
Avant / après implémentation (notes cirrostratus) Critère Avant Après Richesse des intégrations d'outils ●●●○ ●●●○ Garde-fous d'exécution ●●●● ●●●● Évaluation systématique ●●●● ●●●● Traçabilité des runs ●●●● ●●●● Coût ●●●● ●●●● Note globale (moyenne) 3,8/4 · 🥇 1er 3,8/4 · 🥇 1er
RÉALISÉ ÉTAT RÉEL AU 11/10/2026 : 4/4 actions réalisées (100 %) — preuve : approbation humaine prod + évals pondérées par cas (t5A) · datasets versionnés lineage (t4I) · signature Ed25519 des artefacts manifeste déterministe signé par artefact (T19K)
Solution sous-jacente & licences moteur maison (référentiel cirrostratus, Rust — code privé du projet) (versions immuables gguf/onnx/pytorch/safetensors — formats ouverts).
Actions : descriptif · effort · recette (cas d’usage / preuve / démo) Action Effort Recette de validation A1 Workflow d'approbation (validation humaine obligatoire avant promotion prod, option par registre).P2 · 2-4 j CAS : registre avec approbation obligatoire · PREUVE : promotion bloquée sans validation humaine · DÉMO : tentative refusée. A2 Métriques d'évaluation attachées à la version (résultats de suites, pas seulement les pertes).P2 · 2-4 j CAS : version avec résultats d'évals attachés · PREUVE : score visible à côté des pertes · DÉMO : fiche version. A3 Artifacts associés : datasets et configs d'entraînement versionnés avec le modèle.P3 · 1-2 sem CAS : dataset versionné lié au modèle · PREUVE : lineage complet modèle→dataset · DÉMO : graphe lineage. A4 Signature des artefacts (provenance vérifiable de bout en bout).P2 · 2-4 j CAS : artefact signé, vérifié après téléchargement · PREUVE : signature valide, altération détectée · DÉMO : vérif.
Avant / après implémentation (notes cirrostratus) Critère Avant Après Immutabilité des versions ●●●● ●●●● Gestion staging/prod ●●●● ●●●● Écosystème MLOps ●●○○ ●●●○ Formats supportés ●●●● ●●●● Note globale (moyenne) 3,5/4 · 🥇 1er 3,8/4 · 🥇 1er
#44 Affinage (fine-tuning) de modèlesposition : 3,4/4 · 1er → 3,6/4 · 1er
fiche comparatif → PARTIEL ÉTAT RÉEL AU 11/10/2026 : 2/4 actions réalisées (50 %) — preuve : verdict Go/NoGo à perte MESURÉE (t2Z) · datasets reproductibles (t4I) ; LoRA et multi-GPU non entamés
Solution sous-jacente & licences entraîneur local moteur maison (référentiel cirrostratus, Rust — code privé du projet) sur gguf (format open) + llama.cpp (MIT) ; cible LoRA/QLoRA maison.
Actions : descriptif · effort · recette (cas d’usage / preuve / démo) Action Effort Recette de validation A1 Adapters LoRA/QLoRA (affiner sans réécrire tout le modèle : plus rapide, moins de VRAM).P3 · 1-2 sem CAS : LoRA 7B sur 200 exemples · PREUVE : entraînement < X h, qualité ≈ full FT sur jeu de test · DÉMO : courbes de pertes. A2 Multi-GPU pour affiner des bases plus grandes que la carte.P3 · 1-2 sem CAS : affinage 2 GPU vs 1 · PREUVE : temps ÷1,8 mesuré · DÉMO : timings. A3 Évaluation automatique post-affinage (la suite d'évals tourne sur la nouvelle version avant staging).P2 · 2-4 j CAS : suite d'évals auto post-affinage · PREUVE : verdict Go/NoGo rendu avant staging · DÉMO : rapport d'évals. A4 Datasets versionnés et reproductibles (le même entraînement redonne le même résultat).P2 · 2-4 j CAS : ré-entraînement identique · PREUVE : même hash de version (reproductibilité) · DÉMO : comparaison d'empreintes.
Avant / après implémentation (notes cirrostratus) Critère Avant Après Profondeur d'entraînement ●●○○ ●●●○ Transparence des résultats ●●●● ●●●● Coût ●●●● ●●●● Honnêteté d'absence de moteur ●●●● ●●●● Transfert réel en production ●●●○ ●●●○ Note globale (moyenne) 3,4/4 · 🥇 1er 3,6/4 · 🥇 1er
#45 Magasin de caractéristiques (feature store)position : 3,2/4 · 1er → 3,5/4 · 1er
fiche comparatif → RÉALISÉ ÉTAT RÉEL AU 11/10/2026 : 4/4 actions réalisées (100 %) — preuve : online store à fraîcheur MESURÉE + ingestion flux + transformations prouvées byte pour byte (P8) + perf ×17 (B15) · lineage feature→dataset→entraînement BFS doublons déduits (T19K)
Solution sous-jacente & licences moteur maison (référentiel cirrostratus, Rust — code privé du projet) (schéma figé, entités, versions).
Actions : descriptif · effort · recette (cas d’usage / preuve / démo) Action Effort Recette de validation A1 Online store temps réel (latence ms pour l'inférence, pas seulement l'entraînement).P3 · 1-2 sem CAS : lecture online pendant inférence · PREUVE : latence < 50 ms p95 · DÉMO : métriques. A2 Ingestion en flux depuis cirroFlux (features calculées à l'arrivée).P2 · 2-4 j CAS : feature calculée depuis cirroFlux à l'arrivée · PREUVE : valeur fraîche < 5 s après l'événement · DÉMO : horodatages. A3 API de transformation déclarative (les calculs définis une fois, appliqués partout).P2 · 2-4 j CAS : transformation déclarée réutilisée train+inférence · PREUVE : mêmes sorties des deux côtés · DÉMO : diff nul. A4 Lineage : quelle version de quelle feature a nourri quel entraînement.P2 · 2-4 j CAS : lineage feature→entraînement · PREUVE : liste des entraînements par version de feature · DÉMO : lineage.
Avant / après implémentation (notes cirrostratus) Critère Avant Après Cohérence entraînement/inférence ●●●○ ●●●● Ingestion en flux ●●○○ ●●○○ Stabilité du schéma ●●●● ●●●● Pertinence en lab/PME ●●●● ●●●● Note globale (moyenne) 3,2/4 · 🥇 1er 3,5/4 · 🥇 1er
#46 Surveillance de modèles en productionposition : 3,0/4 · 3e → 3,2/4 · 1er
fiche comparatif → RÉALISÉ ÉTAT RÉEL AU 11/10/2026 : 4/4 actions réalisées (100 %) — preuve : alerting seuils p95/erreurs à valeurs mesurées (t1D) · rejeu déterministe à similarité mesurée (t4I) · dérive sémantique JSD centroïdes verdict chiffré + A/B hash FNV stable gagnant à delta ET erreurs comparables (T19I/T19J)
Solution sous-jacente & licences métriques p50/95/99 moteur maison (référentiel cirrostratus, Rust — code privé du projet) ; stockage Prometheus (Apache-2.0).
Actions : descriptif · effort · recette (cas d’usage / preuve / démo) Action Effort Recette de validation A1 Dérive sémantique : échantillonnage des réponses + scoring automatique (alerte quand la distribution bouge).P3 · 1-2 sem CAS : dérive simulée (changement de distribution) · PREUVE : alerte levée avec score de dérive · DÉMO : graphe distribution. A2 Comparaison A/B de versions en prod (trafic scindé, verdict mesuré).P3 · 1-2 sem CAS : A/B v1/v2 sur 100 requêtes · PREUVE : verdict comparatif mesuré (qualité + latence) · DÉMO : rapport. A3 Alerting natif (seuils de latence/erreurs vers cirroTopics).P1 · ≤ 1 j CAS : seuil p95 dépassé · PREUVE : alerte cirroTopics reçue · DÉMO : message. A4 Rejeu : rejouer un échantillon de requêtes sur une nouvelle version sans impact.P2 · 2-4 j CAS : rejeu d'un échantillon sur v2 · PREUVE : réponses comparées sans trafic réel · DÉMO : tableau de rejeu.
Avant / après implémentation (notes cirrostratus) Critère Avant Après Dérive de données ●○○○ ●●○○ Métriques LLM (latence, jetons) ●●●● ●●●● Alerting intégré ●●●○ ●●●○ Coût ●●●● ●●●● Note globale (moyenne) 3,0/4 · 3e 3,2/4 · 🥇 1er
RÉALISÉ ÉTAT RÉEL AU 11/10/2026 : 4/4 actions réalisées (100 %) — preuve : HEIC/AVIF binaires + lots dédup sha256 + diff par blocs borné + PDF multi-pages (t4I) · post-traitement YOLO darknet/NMS — modèle réel = matériel (t6H/W7)
Solution sous-jacente & licences parsers d'images moteur maison (référentiel cirrostratus, Rust — code privé du projet) + tesseract (Apache-2.0) ; cible détection d'objets : Ultralytics YOLO (AGPL-3.0 — attention copyleft).
Actions : descriptif · effort · recette (cas d’usage / preuve / démo) Action Effort Recette de validation A1 Détection/classification d'objets locale (modèles YOLO sur le GPU du site) pour la reconnaissance généraliste.P3 · 1-2 sem CAS : photo avec 3 objets courants · PREUVE : objets détectés+localisés (boîtes) en local · DÉMO : image annotée. A2 Support des formats compacts courants (HEIC, AVIF) en entrée.P2 · 2-4 j CAS : HEIC iPhone lu · PREUVE : dimensions parsées + OCR OK · DÉMO : réponse API. A3 API batch (dossier complet traité en job) et résultats paginés.P2 · 2-4 j CAS : dossier 500 images en job batch · PREUVE : résultats paginés, empreintes dédupliquées · DÉMO : listing. A4 Comparaison d'images (diff visuel) au-delà de l'empreinte SHA-256.P2 · 2-4 j CAS : diff visuel de 2 captures · PREUVE : zones changées encadrées · DÉMO : image de diff.
Avant / après implémentation (notes cirrostratus) Critère Avant Après Reconnaissance généraliste ●●○○ ●●●○ Honnêteté architecturale ●●●● ●●●● Coût à l'image ●●●● ●●●● Confidentialité des images ●●●● ●●●● Note globale (moyenne) 3,5/4 · 🥇 1er 3,8/4 · 🥇 1er
#48 Extraction de texte / OCR documentsposition : 3,2/4 · 1er → 3,2/4 · 1er
fiche comparatif → PARTIEL ÉTAT RÉEL AU 11/10/2026 : 3/4 actions réalisées (75 %) — preuve : PDF multi-pages compté (t4I) · inclinaison par projection (t4I) · tables détectées par coordonnées grille lignes×colonnes exacte — aucun pixel décodé DIT (T19K) ; tesseract affiné = BLOQUÉ MATÉRIEL
Solution sous-jacente & licences tesseract (Apache-2.0) derrière l'API cirroVision moteur maison (référentiel cirrostratus, Rust — code privé du projet).
Actions : descriptif · effort · recette (cas d’usage / preuve / démo) Action Effort Recette de validation A1 Layout structuré : tables et blocs détectés (pas seulement le texte brut).P3 · 1-2 sem CAS : facture scannée avec tableau · PREUVE : tableau restitué en structure (lignes×colonnes) · DÉMO : JSON structuré. A2 Prétraitement automatique (redressement, débruitage) pour les photos de documents.P2 · 2-4 j CAS : photo de document penchée · PREUVE : OCR réussi après redressement auto (comparaison sans) · DÉMO : 2 sorties. A3 Modèles tesseract FR affinés sur les documents du site (factures, bons).P2 · 2-4 j CAS : bon de commande maison (modèle affiné) · PREUVE : champs clés extraits > 95 % · DÉMO : score. A4 Entrée PDF native (multi-pages) sans conversion manuelle.P2 · 2-4 j CAS : PDF 10 pages · PREUVE : texte par page, numérotation correcte · DÉMO : extrait.
Avant / après implémentation (notes cirrostratus) Critère Avant Après Qualité sur documents complexes ●●●○ ●●●○ Structure du document ●●○○ ●●○○ Confidentialité ●●●● ●●●● Coût ●●●● ●●●● Note globale (moyenne) 3,2/4 · 🥇 1er 3,2/4 · 🥇 1er
RÉALISÉ ÉTAT RÉEL AU 11/10/2026 : 4/4 actions réalisées (100 %) — preuve : batch ordre préservé (t1D) · classification k-NN « incertain » honnête (t2Z) · résumé extractif (t2Z) · NER FR gazetiers 48 prénoms/46 villes + suffixes sociétés + SIRET Luhn, frontières de mot garanties (T19K)
Solution sous-jacente & licences moteur maison (référentiel cirrostratus, Rust — code privé du projet) (sentiment FR/EN, entités structurelles, aucun stockage du texte).
Actions : descriptif · effort · recette (cas d’usage / preuve / démo) Action Effort Recette de validation A1 NER entraîné FR plus riche (personnes, lieux, organisations) au-delà des entités structurelles.P3 · 1-2 sem CAS : texte FR avec personnes/lieux · PREUVE : entités nommées détectées (types corrects) · DÉMO : sortie JSON. A2 Classification personnalisable (quelques exemples étiquetés → catégorie).P2 · 2-4 j CAS : 20 exemples étiquetés → classification · PREUVE : nouvelle phrase classée correctement · DÉMO : échange. A3 Résumé et extraction de sujets en s'appuyant sur les LLM locaux.P2 · 2-4 j CAS : résumé d'un rapport 5 pages · PREUVE : résumé fidèle (points clés couverts) · DÉMO : résumé. A4 Traitement par lots (API batch) pour les gros corpus.P1 · ≤ 1 j CAS : 1000 textes en batch · PREUVE : résultats paginés, temps total affiché · DÉMO : sortie.
Avant / après implémentation (notes cirrostratus) Critère Avant Après Qualité d'analyse ●●●○ ●●●○ Entités européennes ●●●● ●●●● Confidentialité du texte ●●●● ●●●● Coût ●●●● ●●●● Note globale (moyenne) 3,8/4 · 🥇 1er 3,8/4 · 🥇 1er
PARTIEL ÉTAT RÉEL AU 11/10/2026 : 2/4 actions réalisées (50 %) — preuve : vocabulaires bornés jamais rognés (t2Z) · mp3/ogg/flac headers parsés, durée flac mesurée aux bits (t2Z) ; streaming et diarisation non entamés
Solution sous-jacente & licences whisper.cpp (MIT) — modèles Whisper (MIT) ; diarisation lab via Sortformer/pyannote (MIT/propriétaire selon modèle).
Actions : descriptif · effort · recette (cas d’usage / preuve / démo) Action Effort Recette de validation A1 Streaming temps réel (WebSocket) pour la transcription en direct.P3 · 1-2 sem CAS : dictée streaming WebSocket · PREUVE : transcription progressive < 1 s de retard · DÉMO : capture flux. A2 Diarisation intégrée au produit (qui parle quand, pas seulement via le lab).P3 · 1-2 sem CAS : réunion 2 voix · PREUVE : diarisation native (segments [SPK1/SPK2]) · DÉMO : transcription diarisée. A3 Vocabulaires personnalisés (noms propres, jargon métier) injectés au modède.P2 · 2-4 j CAS : vocabulaire métier injecté · PREUVE : termes reconnus (avant : erreurs) · DÉMO : avant/après. A4 Entrée compressée native (mp3, ogg) sans conversion WAV manuelle.P2 · 2-4 j CAS : fichier mp3 direct · PREUVE : transcription sans conversion manuelle · DÉMO : commande.
Avant / après implémentation (notes cirrostratus) Critère Avant Après Qualité français/accents ●●●○ ●●●○ Diarisation multi-locuteurs ●●●○ ●●●● Streaming temps réel ●●○○ ●●●○ Confidentialité de l'audio ●●●● ●●●● Coût à la minute ●●●● ●●●● Note globale (moyenne) 3,2/4 · 🥇 1er 3,6/4 · 🥇 1er
PARTIEL ÉTAT RÉEL AU 11/10/2026 : 2/4 actions réalisées (50 %) — preuve : SSML strict → segments piper (t2Z) · catalogue voix lu du répertoire réel (t1D) ; modèles récents et clonage non entamés
Solution sous-jacente & licences piper (MIT) — voix MIT/propriétaires selon modèle ; rendu WAV moteur maison (référentiel cirrostratus, Rust — code privé du projet).
Actions : descriptif · effort · recette (cas d’usage / preuve / démo) Action Effort Recette de validation A1 Voix neuronales plus naturelles : intégrer des modèles récents (XTTS/piper récents) et les exposer au catalogue.P3 · 1-2 sem CAS : phrase avec nouvelle voix neuronale · PREUVE : audition comparative vs piper standard · DÉMO : 2 WAV. A2 Clonage local de voix (consenti, sur échantillons fournis).P3 · 1-2 sem CAS : clone local sur 30 s d'échantillon consenties · PREUVE : ressemblance validée par l'échantillonneur · DÉMO : WAV. A3 Marquage SSML minimal (pauses, vitesse) et streaming audio.P2 · 2-4 j CAS : pause et vitesse via balises · PREUVE : durée mesurée conforme · DÉMO : chronométrage. A4 Catalogue de voix FR documenté avec échantillons écoutables.P1 · ≤ 1 j CAS : page catalogue avec échantillons · PREUVE : chaque voix écoutable en 1 clic · DÉMO : page.
Avant / après implémentation (notes cirrostratus) Critère Avant Après Naturalité des voix ●●○○ ●●●○ Voix françaises ●●●○ ●●●○ Confidentialité du texte ●●●● ●●●● Coût ●●●● ●●●● Note globale (moyenne) 3,2/4 · 🥇 1er 3,5/4 · 🥇 1er
#52 Assistant conversationnel (chatbot)position : 3,4/4 · 1er → 3,6/4 · 1er
fiche comparatif → RÉALISÉ ÉTAT RÉEL AU 11/10/2026 : 4/4 actions réalisées (100 %) — preuve : widget + Matrix + webhooks (S8/W9) · analytics conversationnels (t18C) · cirroAccompagnement LIVRÉ (0.124.0) · flux guidés LIVRÉS 11/10 (5 parcours déterministes « démarrage/données/IA/pannes/coûts » qui recommandent les VRAIS scénarios uc-* par règles ordonnées, 3 routes /flux-guides, DFS exhaustif de tous les chemins testé — livrés sous la forme de l'amélioration « arbres de décision à côté du ReAct libre », l'intent-tree 5.a reste écarté)
Solution sous-jacente & licences cirroAgents (moteur maison (référentiel cirrostratus, Rust — code privé du projet), ReAct outillé) + LLM locaux (vLLM Apache-2.0).
Actions : descriptif · effort · recette (cas d’usage / preuve / démo) Action Effort Recette de validation A1 Canaux : widget web embarquable + Matrix/XMPP (canaux souverains) en plus de la console.P3 · 1-2 sem CAS : widget web intégré + salon Matrix interrogés · PREUVE : conversation tenue depuis les 2 canaux · DÉMO : captures. A2 Analytics conversationnels (sujets, échecs, satisfaction déclarée).P2 · 2-4 j CAS : 100 conversations analysées · PREUVE : thèmes+échecs classés · DÉMO : rapport. A3 Flux guidés optionnels (arbres de décision pour les cas répétitifs) à côté du ReAct libre.P2 · 2-4 j CAS : flux guidé « réinitialiser mot de passe » · PREUVE : parcours arborescent abouti · DÉMO : dialogue. A4 Exposition MCP des agents (outils réutilisables par d'autres clients).P2 · 2-4 j CAS : agent exposé via MCP · PREUVE : un client MCP externe l'appelle · DÉMO : liste d'outils distante.
Avant / après implémentation (notes cirrostratus) Critère Avant Après Canaux de diffusion ●●○○ ●●●○ Gestion de flux multi-tours ●●●○ ●●●○ Actions réelles sur l'infra ●●●● ●●●● Sécurité des actions ●●●● ●●●● Coût ●●●● ●●●● Note globale (moyenne) 3,4/4 · 🥇 1er 3,6/4 · 🥇 1er
09 DevOps & CI/CDRÉALISÉ ÉTAT RÉEL AU 11/10/2026 : 4/4 actions réalisées (100 %) — preuve : rollback N-1 (t6F/t5C) · build conteneurisé rendu en plan + gates manuels multi-approbations + artefacts dédoublonnés par digest et réutilisés au rollback (t18C)
Solution sous-jacente & licences moteur maison (référentiel cirrostratus, Rust — code privé du projet) (source vérifiée HTTP, bleu/vert, canari, URL sondée).
Actions : descriptif · effort · recette (cas d’usage / preuve / démo) Action Effort Recette de validation A1 Build natif : étapes conteneurisées (compiler, tester) dans le pipeline, pas seulement déployer.P3 · 1-2 sem CAS : pipeline avec étape build conteneurisée (cargo build) · PREUVE : binaire produit, artefact conservé · DÉMO : journal du build. A2 Rollback automatique si la sonde post-déploiement échoue (revenir à la révision N-1 sans humain).P2 · 2-4 j CAS : sonde post-déploiement échoue · PREUVE : rollback auto à N-1 vérifié (version servie) · DÉMO : avant/après. A3 Artefacts versionnés (binaire/image du build conservé, redéployable).P2 · 2-4 j CAS : redéploiement de l'artefact #12 sans rebuild · PREUVE : même digest déployé · DÉMO : digests. A4 Gates manuels (validation avant prod) et exécutions parallèles.P2 · 2-4 j CAS : gate manuel avant prod · PREUVE : exécution en attente jusqu'à validation · DÉMO : capture statut.
Avant / après implémentation (notes cirrostratus) Critère Avant Après Véracité de la source déployée ●●●● ●●●● Stratégies de déploiement ●●●○ ●●●○ Vérification post-déploiement ●●●● ●●●● Build natif multi-langages ●●○○ ●●●○ Coût ●●●● ●●●● Note globale (moyenne) 3,4/4 · 🥇 1er 3,6/4 · 🥇 1er
RÉALISÉ ÉTAT RÉEL AU 11/10/2026 : 3/3 actions réalisées (100 %) — preuve : offre cirroGit Gitea 1.24.3 épinglée (docker run exact, santé /api/healthz) + SSO à secret RÉFÉRENCE cirroSecrets (jeton collé refusé en le nommant) + miroir rsync/borg empreintes vérifiées des deux côtés (R8) — câblé (W9) et prouvé e2e gitea offre/SSO/miroir (E10/T10) + outils MCP/CLI gitea (M12/L12)
Solution sous-jacente & licences Gitea (MIT) déployé au lab (annexe) ; intégration pipeline maison.
Actions : descriptif · effort · recette (cas d’usage / preuve / démo) Action Effort Recette de validation A1 Intégrer Gitea au catalogue comme produit managé (cirroGit) : création en commande, backups, comptes liés à l'org.P3 · 1-2 sem CAS : dépôt managé créé en 1 commande, push clone · PREUVE : round-trip git OK · DÉMO : commandes. A2 Miroir de sauvegarde automatique vers le second site (le code est l'actif le plus critique).P2 · 2-4 j CAS : miroir auto vers second site · PREUVE : clone distant identique (objets comptés) · DÉMO : count-objects. A3 SSO avec les organisations cirrostratus (mêmes membres, mêmes rôles).P2 · 2-4 j CAS : compte lié à l'org cirrostratus · PREUVE : mêmes membres/rôles, pas de compte séparé · DÉMO : listing membres.
Avant / après implémentation (notes cirrostratus) Critère Avant Après Disponibilité du service — — Confidentialité du code — — Écosystème (PR, reviews, CI) — — Coût — — Note globale (moyenne) — —
RÉALISÉ ÉTAT RÉEL AU 11/10/2026 : 4/4 actions réalisées (100 %) — preuve : tf-import + modules + couverture 100 % (T8/W9, re-vérifiée PROD) · plan/apply piloté par l'API (T19L/O) : diff CHAMP nommé, apply RÉEL (suppressions exécutées) avec arrêt au premier échec et rapport partiel
Solution sous-jacente & licences provider OpenTofu (MPL-2.0) officiel cirrostratus ; générateur main.tofu maison.
Actions : descriptif · effort · recette (cas d’usage / preuve / démo) Action Effort Recette de validation A1 Couverture 100 % des familles du catalogue (chaque ressource API = une resource provider).P3 · 1-2 sem CAS : chaque famille API a sa resource provider · PREUVE : terraform plan complet sans resource générique · DÉMO : plan. A2 Import de l'existant (cirro tf-import) : générer le .tf d'une org déjà peuplée.P3 · 1-2 sem CAS : cirro tf-import d'une org peuplée · PREUVE : .tf généré, plan suivant = No changes · DÉMO : diff nul. A3 Modules officiels documentés (patterns : app+base, stack complète).P2 · 2-4 j CAS : module officiel app+base · PREUVE : déploiement par module en 10 lignes · DÉMO : main.tf. A4 Plan/apply piloté par l'API (diff lisible avant application).P2 · 2-4 j CAS : plan piloté par API (diff avant apply) · PREUVE : diff rendu, puis application contrôlée · DÉMO : sortie plan.
Avant / après implémentation (notes cirrostratus) Critère Avant Après Outil standard du marché ●●●● ●●●● Couverture des ressources ●●●○ ●●●● Sécurité du jeton ●●●● ●●●● Génération assistée ●●●● ●●●● Drift detection ●●○○ ●●○○ Note globale (moyenne) 3,4/4 · 🥇 1er 3,6/4 · 🥇 1er
#56 Déploiement fullstack (app + domaine + CDN + base)position : 3,2/4 · 2e → 3,8/4 · 1er
fiche comparatif → RÉALISÉ ÉTAT RÉEL AU 11/10/2026 : 4/4 actions réalisées (100 %) — preuve : git-push sans secret + auth OIDC RS256/JWKS vérifiée (t6F/P8/t14k) · previews éphémères branche→URL TTL 24 h purge + rollback de stack 3 étapes ordonnées app→dns→base commandes N-1 rendues (T19L/O)
Solution sous-jacente & licences moteur maison (référentiel cirrostratus, Rust — code privé du projet) (plan ordonné : app OCI + DNS + CDN + base FerroDB/PostgreSQL licence PostgreSQL).
Actions : descriptif · effort · recette (cas d’usage / preuve / démo) Action Effort Recette de validation A1 Git-push-to-deploy : brancher cirroPipelines sur un push Gitea pour reconstruire l'image automatiquement.P3 · 1-2 sem CAS : push Gitea → stack reconstruite et redéployée · PREUVE : nouvelle version servie sans commande manuelle · DÉMO : commit→URL. A2 Auth managée (utilisateurs de l'app, clés, OIDC) — le principal manque face à Firebase/Amplify.P4 · 3-6 sem CAS : utilisateur d'app créé via auth managée · PREUVE : login + page protégée · DÉMO : flux. A3 Environnements de préview éphémères (une branche = une URL temporaire).P3 · 1-2 sem CAS : branche feature = URL de préview éphémère · PREUVE : URL dédiée, détruite à la suppression · DÉMO : 2 URLs. A4 Rollback complet de stack (revenir à l'état N-1 app + DNS + base).P3 · 1-2 sem CAS : rollback complet app+DNS+base · PREUVE : état N-1 vérifié (version + données) · DÉMO : états.
Avant / après implémentation (notes cirrostratus) Critère Avant Après Nombre de briques orchestrées ●●●● ●●●● Authentification managée ●○○○ ●●●○ Ordre d'exécution garanti ●●●● ●●●● Statut honnête du déploiement ●●●● ●●●● Note globale (moyenne) 3,2/4 · 2e 3,8/4 · 🥇 1er
RÉALISÉ ÉTAT RÉEL AU 11/10/2026 : 4/4 actions réalisées (100 %) — preuve : découverte CSV + effort + plan guidé (R8/W9) · sondage clouds sources : token bucket rythme/durées par fournisseur, quotas conservateurs DITS, PREUVE différée 6.c rendue (T19L/O)
Solution sous-jacente & licences moteur maison (référentiel cirrostratus, Rust — code privé du projet) (analyse Terraform HCL — HCL2 parser Rust, licences Apache-2.0/MIT).
Actions : descriptif · effort · recette (cas d’usage / preuve / démo) Action Effort Recette de validation A1 Découverte sans Terraform : import d'un inventaire CSV/agent (pour le patrimoine non-IaC).P3 · 1-2 sem CAS : import CSV d'un inventaire non-IaC · PREUVE : ressources reconnues dans le plan · DÉMO : plan généré. A2 Estimation d'effort et de durée par ressource (pas seulement les coûts).P2 · 2-4 j CAS : migration estimée par ressource · PREUVE : durée+effort affichés par ligne · DÉMO : rapport. A3 Plan de migration exportable et exécutable étape par étape (checklist guidée).P2 · 2-4 j CAS : plan exportable en checklist · PREUVE : étapes cochables reprises · DÉMO : fichier. A4 Sondage en lecture des clouds sources (rythme des API, quotas) pour fiabiliser l'extraction.P3 · 1-2 sem CAS : sondage lecture d'un compte AWS listé · PREUVE : quotas/rythmes rendus (jamais d'écriture) · DÉMO : sortie de sondage.
Avant / après implémentation (notes cirrostratus) Critère Avant Après Découverte du patrimoine ●●●○ ●●●○ Format d'entrée ●●●● ●●●● Lisibilité du coût cible ●●●● ●●●● Direction de la migration ●●●● ●●●● Note globale (moyenne) 3,8/4 · 🥇 1er 3,8/4 · 🥇 1er
RÉALISÉ ÉTAT RÉEL AU 11/10/2026 : 4/4 actions réalisées (100 %) — preuve : catalogue 10 apps manifests exacts (t18C) · veille MAJ semver : mineure/patch auto-surveillé, majeure manuel « cassure possible », plan épinglé jamais latest (T19M/O)
Solution sous-jacente & licences applications empaquetées : PostgreSQL (licence PostgreSQL), Redis (BSD-3 ≤7.2), n8n (Sustainable Use — fair-code, non OSI), Uptime Kuma (MIT), Miniflux (AGPL-3.0, à vérifier), Ollama WebUI/open-webui (BSD-3 + clause marque, ex-MIT) ; installeur maison.
Actions : descriptif · effort · recette (cas d’usage / preuve / démo) Action Effort Recette de validation A1 Élargir le catalogue testé (20-30 applications libres courantes : PostgREST, Uptime, Vaultwarden, n8n déjà là…).P3 · 1-2 sem CAS : 5 nouvelles apps installées du premier coup · PREUVE : healthy après install, intégrées showback · DÉMO : listing apps. A2 Mises à jour automatiques surveillées des apps installées (suivi de version, upgrade en commande).P2 · 2-4 j CAS : mise à jour dispo signalée puis appliquée · PREUVE : version changée, config préservée · DÉMO : avant/après. A3 Dépendances inter-apps (app A pointe vers la base de l'app B sans ressaisir les secrets).P2 · 2-4 j CAS : app B branchée sur la base de l'app A · PREUVE : liaison sans secret ressaisi · DÉMO : schéma de liaison. A4 Retours d'usage internes et notes de configuration dans la fiche de chaque app.P1 · ≤ 1 j CAS : fiche app avec retours d'usage · PREUVE : notes de configuration visibles · DÉMO : fiche.
Avant / après implémentation (notes cirrostratus) Critère Avant Après Largeur du catalogue ●●○○ ●●●○ Facturation consolidée ●●●○ ●●●○ Fiabilité des offres ●●●● ●●●● Licences BYOL ●●●● ●●●● Note globale (moyenne) 3,2/4 · 4e 3,5/4 · 🥇 1er
10 ObservabilitéRÉALISÉ ÉTAT RÉEL AU 11/10/2026 : 4/4 actions réalisées (100 %) — preuve : alerting hystérésis + dashboards auto + SLI/SLO (t6J) · rétention long terme : downsampling min/max/moy seaux alignés epoch + politique 4 paliers ANNOCÉS (brut/5 min/1 h/1 j), aucune suppression silencieuse (T19R)
Solution sous-jacente & licences Prometheus (Apache-2.0) + Grafana (AGPL-3.0) ; état des pods moteur maison (référentiel cirrostratus, Rust — code privé du projet).
Actions : descriptif · effort · recette (cas d’usage / preuve / démo) Action Effort Recette de validation A1 Alerting produit : règles de seuil + canaux (topic, courrier) sans rédiger du YAML Prometheus.P3 · 1-2 sem CAS : règle CPU > 90 % 5 min → topic · PREUVE : alerte reçue avec valeur · DÉMO : message. A2 Rétention long terme (Thanos ou downsampling) au-delà des 15 jours classiques.P3 · 1-2 sem CAS : métriques > 1 an consultées · PREUVE : requête 13 mois rendue (downsampling) · DÉMO : graphe long terme. A3 Dashboards auto-générés par service cirro (chaque VM/app a sa vue prête).P2 · 2-4 j CAS : VM nouvelle → dashboard auto dispo · PREUVE : vue prête sans config · DÉMO : dashboard. A4 SLI/SLO natifs : disponibilité et erreur budgétaire suivies en produit.P3 · 1-2 sem CAS : SLO dispo 99 % suivi · PREUVE : budget d'erreur consommé visible · DÉMO : panneau SLO.
Avant / après implémentation (notes cirrostratus) Critère Avant Après Richesse fonctionnelle ●●●○ ●●●○ Coût à l'ingestion ●●●● ●●●● Portabilité des compétences ●●●● ●●●● Honnêteté de l'état ●●●● ●●●● Note globale (moyenne) 3,8/4 · 🥇 1er 3,8/4 · 🥇 1er
RÉALISÉ ÉTAT RÉEL AU 11/10/2026 : 4/4 actions réalisées (100 %) — preuve : cirroLogs ingestion validante + corrélation + alertes (Q8) + perf ×14 (B15) · lots conservés CHIFFRÉS (primitive SSE AES-256-GCM réutilisée, lot clair détruit réellement) (T19O)
Solution sous-jacente & licences stack Loki (AGPL-3.0) du banc ; journaux par service moteur maison (référentiel cirrostratus, Rust — code privé du projet).
Actions : descriptif · effort · recette (cas d’usage / preuve / démo) Action Effort Recette de validation A1 Produire le logging managé (cirroLogs) : ingestion API structurée, rétention par politique.P3 · 1-2 sem CAS : ingestion API structurée d'une app tierce · PREUVE : champs parsés (niveau, trace_id) · DÉMO : requête. A2 Recherche croisée services + corrélation par X-Trace-Id dans une seule console.P3 · 1-2 sem CAS : recherche croisée + corrélation X-Trace-Id · PREUVE : les logs des 3 services alignés · DÉMO : vue corrélée. A3 Alertes sur motifs (erreur X plus de N fois en M minutes).P2 · 2-4 j CAS : motif d'erreur ×20/min → alerte · PREUVE : notification reçue · DÉMO : message. A4 Chiffrement/compression des journaux conservés (le disque aussi a des limites).P2 · 2-4 j CAS : rétention chiffrée compressée · PREUVE : taux de compression + intégrité après relecture · DÉMO : stats.
Avant / après implémentation (notes cirrostratus) Critère Avant Après Rétention et requêtes ●●●○ ●●●○ Coût à l'ingestion (le piège n°1) ●●●● ●●●● Alertes sur pattern ●●●○ ●●●○ Échelle pétabyte ●●○○ ●●○○ Note globale (moyenne) 3,0/4 · 4e 3,0/4 · 4e
PARTIEL ÉTAT RÉEL AU 11/10/2026 : 3/4 actions réalisées (75 %) — preuve : sampling 1/N (t1E/t2W) · export OTLP/HTTP JSON + cartographie de dépendances service→service avec p50/p95 (t18A) ; auto-instrumentation sidecar = BLOQUÉ MATÉRIEL
Solution sous-jacente & licences moteur maison (référentiel cirrostratus, Rust — code privé du projet) (X-Trace-Id, p50/95/99) ; modèle compatible OpenTelemetry (Apache-2.0 / CNCF).
Actions : descriptif · effort · recette (cas d’usage / preuve / démo) Action Effort Recette de validation A1 Auto-instrumentation par sidecar/proxy (tracer sans toucher au code applicatif).P3 · 1-2 sem CAS : app sans instrumentation via sidecar · PREUVE : traces complètes générées (spans HTTP) · DÉMO : trace visuelle. A2 Export OTLP natif (les traceurs standard font déjà le travail).P2 · 2-4 j CAS : export OTLP vers un collecteur externe · PREUVE : traces reçues de l'autre côté · DÉMO : capture collector. A3 Cartographie des dépendances dérivée des traces (qui appelle qui).P2 · 2-4 j CAS : cartographie dérivée de 24 h de trafic · PREUVE : graphe dépendances complet · DÉMO : carte. A4 Sampling configurable (tout tracer en dev, 1 % en prod).P1 · ≤ 1 j CAS : sampling 1 % en prod configuré · PREUVE : volume divisé ≈100, traces saines · DÉMO : compteurs.
Avant / après implémentation (notes cirrostratus) Critère Avant Après Instrumentation SDK ●●●● ●●●● Analyse ML des traces ●●○○ ●●○○ Profiling continu ●○○○ ●○○○ Coût ●●●● ●●●● Note globale (moyenne) 2,8/4 · 3e 2,8/4 · 3e
#62 Suivi d'erreurs applicatives (error tracking)position : 3,5/4 · 2e → 3,5/4 · 2e
fiche comparatif → RÉALISÉ ÉTAT RÉEL AU 11/10/2026 : 4/4 actions réalisées (100 %) — preuve : offre Sentry self-hosted (0.131.0) · ingestion DSN clé hashée temps constant + événements typés bornés 200 Kio + corrélation cirroLogs par trace_id (UNE requête croisée) + regroupement par empreinte de stack + règles d'alerte ntfy réutilisant commande_publier (T19S)
Solution sous-jacente & licences cirroErreurs : Sentry self-hosted (FSL-1.1-MIT — auto-hébergement libre, redevable MIT après 2 ans) ou GlitchTip (MIT), compatibles DSN ; SDK open-source (standard de fait).
Actions : descriptif · effort · recette (cas d’usage / preuve / démo) Action Effort Recette de validation A1 Offre managée Sentry self-hosted : recette exacte (tag calendaire épinglé, installateur officiel, compose), licence FSL dite, alternative GlitchTip (MIT) compatible DSN.P3 · 1-2 sem CAS : offre ?tag=&hote= posée · PREUVE : la garde refuse main/master/latest, tag calendaire explicite exigé, licence FSL rendue avec la conversion MIT · DÉMO : offre servie. A2 Ingestion DSN réelle : créer le projet Sentry par org, rendre le DSN, un SDK open-source envoie et l'issue apparaît regroupée.P3 · 1-2 sem CAS : SDK open-source configuré sur le DSN rendu · PREUVE : l'issue apparaît regroupée par stack trace dans le projet de l'org · DÉMO : capture. A3 Corrélation cirroLogs : les erreurs d'apps ressortent dans le journal avec leur trace_id (une seule recherche croisée).P2 · 2-4 j CAS : erreur d'app suivie d'une recherche par trace_id dans cirroLogs · PREUVE : la même erreur ressort des deux côtés · DÉMO : recherche croisée. A4 Alertes vers cirroNotifications : règle seuil/nouvelle issue → webhook ntfy (push téléphone).P2 · 2-4 j CAS : règle « nouvelle issue » posée · PREUVE : push ntfy reçu à la prochaine erreur nouvelle · DÉMO : téléphone.
Avant / après implémentation (notes cirrostratus) Critère Avant Après Regroupement et triage ●●●○ ●●●○ Suivi par release ●●●○ ●●●○ SDK et portabilité ●●●● ●●●● Coût / souveraineté ●●●● ●●●● Note globale (moyenne) 3,5/4 · 2e 3,5/4 · 2e
RÉALISÉ ÉTAT RÉEL AU 11/10/2026 : 4/4 actions réalisées (100 %) — preuve : abonnements + maintenance + post-mortems (t2V) · badge SVG shields-like (t1E) · badge et status JSON servis en PROD 0.123.0 (recette 11/11, endpoints publics)
Solution sous-jacente & licences moteur maison (référentiel cirrostratus, Rust — code privé du projet) (page publique par organisation).
Actions : descriptif · effort · recette (cas d’usage / preuve / démo) Action Effort Recette de validation A1 Abonnements aux incidents (RSS, webhook, courriel) pour les utilisateurs.P2 · 2-4 j CAS : abonnement RSS/webhook d'un visiteur · PREUVE : notification reçue à l'incident suivant · DÉMO : flux reçu. A2 Fenêtres de maintenance planifiées annoncées d'avance sur la page.P2 · 2-4 j CAS : maintenance annoncée J-2 · PREUVE : bandeau planifié visible avant, pendant · DÉMO : captures. A3 Historique des post-mortems publiés (la transparence complète le contrat).P2 · 2-4 j CAS : post-mortem publié après résolution · PREUVE : document relié à l'incident · DÉMO : page. A4 Badges intégrables (image/iframe d'état pour les portails clients).P1 · ≤ 1 j CAS : badge d'état intégré au portail client · PREUVE : image reflète l'état réel · DÉMO : capture.
Avant / après implémentation (notes cirrostratus) Critère Avant Après Transparence imposée ●●●● ●●●● Historique de disponibilité ●●●● ●●●● Communication des incidents ●●●○ ●●●○ Coût ●●●● ●●●● Note globale (moyenne) 3,8/4 · 🥇 1er 3,8/4 · 🥇 1er
11 Sécurité & identité#64 Gestion des identités et des accèsposition : 3,2/4 · 1er → 3,5/4 · 1er
fiche comparatif → RÉALISÉ ÉTAT RÉEL AU 11/10/2026 : 4/4 actions réalisées (100 %) — preuve : fédération OIDC + SCIM + SSO complet Keycloak RS256/JWKS prouvé (Q8/T13-T16) · rôles personnalisés à politiques par service hiérarchie lire<écrire<admin + export audit par membre CSV RFC4180/JSON round-trip (T19D, câblé T19E)
Solution sous-jacente & licences moteur maison (référentiel cirrostratus, Rust — code privé du projet) (organisations, rôles, tokens) ; TOTP RFC 6238 maison ; cible fédération OIDC/SAML.
Actions : descriptif · effort · recette (cas d’usage / preuve / démo) Action Effort Recette de validation A1 SSO entrant : fédération OIDC/SAML (les membres se connectent avec l'IdC existant de l'entreprise).P3 · 1-2 sem CAS : login fédéré OIDC (IdP du lab) · PREUVE : accès sans compte local, claims mappés · DÉMO : flux de login. A2 Rôles personnalisés et policies par service (au-delà des 3 rôles fixes).P3 · 1-2 sem CAS : rôle custom « lecteur coûts » · PREUVE : accès limité vérifié (refus ailleurs) · DÉMO : tentatives. A3 SCIM (provisionnement automatique des comptes depuis l'annuaire).P2 · 2-4 j CAS : provisioning SCIM depuis l'annuaire · PREUVE : utilisateur créé/retrait synchronisé · DÉMO : journaux. A4 Journal d'audit exportable des actions par membre (qui a fait quoi, quand).P2 · 2-4 j CAS : audit exporté « qui a fait quoi » · PREUVE : actions horodatées par membre · DÉMO : export.
Avant / après implémentation (notes cirrostratus) Critère Avant Après Profondeur entreprise (SSO, SCIM) ●●○○ ●●●○ Courbe d'apprentissage ●●●● ●●●● Précision des autorisations ●●●○ ●●●○ Risque de lock-in ●●●● ●●●● Note globale (moyenne) 3,2/4 · 🥇 1er 3,5/4 · 🥇 1er
RÉALISÉ ÉTAT RÉEL AU 11/10/2026 : 4/4 actions réalisées (100 %) — preuve : sources SSH/DNS + règles + digest + CVE 501 honnête (t3O/t2Y/t1B/A15) · boucle finding→ban : cumul de scores par fenêtre, durée = fenêtre×récidences plafonnée 24 h, règle nftables RENDUE à pose manuelle dite (T19R)
Solution sous-jacente & licences moteur d'anomalies + corrélation moteur maison (référentiel cirrostratus, Rust — code privé du projet).
Actions : descriptif · effort · recette (cas d’usage / preuve / démo) Action Effort Recette de validation A1 Élargir les sources : logs d'authentification, échecs SSH, requêtes DNS du site (pas seulement la télémétrie service).P2 · 2-4 j CAS : échecs SSH en rafale détectés · PREUVE : anomalie levée avec source+compteur · DÉMO : finding. A2 Règles de détection personnalisables (signatures maison).P2 · 2-4 j CAS : règle maison (scan sur port exotique) · PREUVE : détection sur essai volontaire · DÉMO : essai+finding. A3 Boucle de blocage : finding cirroGarde → ban cirroBouclier automatique (sous seuil confirmé).P2 · 2-4 j CAS : finding confirmé → ban auto cirroBouclier · PREUVE : IP bannie sous le seuil configuré · DÉMO : journal de ban. A4 Rapport périodique de posture (digest hebdo des signaux et constats).P1 · ≤ 1 j CAS : digest hebdo généré · PREUVE : rapport reçu par courriel · DÉMO : courriel.
Avant / après implémentation (notes cirrostratus) Critère Avant Après Télémétrie mondiale (réputation IP) ●●○○ ●●○○ Corrélation automatique ●●●● ●●●● Couverture des sources ●●●○ ●●●○ Coût ●●●● ●●●● Note globale (moyenne) 3,2/4 · 🥇 1er 3,2/4 · 🥇 1er
PARTIEL ÉTAT RÉEL AU 11/10/2026 : 3/4 actions réalisées (75 %) — preuve : rate limiting middleware 429 (t2Y/t3W) · pack OWASP top-10 DÉTERMINISTE : 10 règles évaluées sans JAMAIS bloquer (pose manuelle, règle produit), explication publiable, A09 sans règle requête-side DIT (T19R) ; anti-bot modèle = BLOQUÉ MATÉRIEL
Solution sous-jacente & licences pare-feu L3+L7 moteur maison (référentiel cirrostratus, Rust — code privé du projet) sur nftables (GPL-2.0 noyau) ; cible règles OWASP CRS (Apache-2.0).
Actions : descriptif · effort · recette (cas d’usage / preuve / démo) Action Effort Recette de validation A1 Règles managées : pack OWASP top-10 prêt à activer (aujourd'hui contrôles + bans).P2 · 2-4 j CAS : pack OWASP activé, attaque SQLi test · PREUVE : requête bloquée (règle identifiée) · DÉMO : journal WAF. A2 Rate limiting par règle (N requêtes/s par IP OU par chemin).P2 · 2-4 j CAS : 100 req/s par IP · PREUVE : 429 au-delà du rate limit · DÉMO : bench. A3 Détection anti-bot locale (modèle léger sur les signatures de clients).P3 · 1-2 sem CAS : bot obviously-fake détecté · PREUVE : classement bot par le modèle local · DÉMO : verdict. A4 Mode learning : proposer les règles à partir du journal d'attaques observées.P2 · 2-4 j CAS : mode learning 7 jours · PREUVE : règles suggérées issues du journal réel · DÉMO : suggestions.
Avant / après implémentation (notes cirrostratus) Critère Avant Après Règles managées ●●●○ ●●●○ ML anti-bot ●○○○ ●●○○ Posture auditée ●●●● ●●●● Contrôle opérationnel ●●●● ●●●● Coût ●●●● ●●●● Note globale (moyenne) 3,2/4 · 🥇 1er 3,4/4 · 🥇 1er
PARTIEL ÉTAT RÉEL AU 11/10/2026 : 3/4 actions réalisées (75 %) — preuve : playbook + pare-feu/bouclier (t1B/t1E/t2Y) · générateur de charge calibré BORNÉ 500 rps refus éthique nommé + couplage débit>seuil → filtre amont PRÉCONFIGURÉ nommé (activation = geste d'exploitation DIT) (T19Q) ; absorption amont contractuelle = BLOQUÉ ARGENT
Solution sous-jacente & licences moteur maison (référentiel cirrostratus, Rust — code privé du projet) (modes audit/enforce, bans, journal mesuré) ; absorption amont via partenaire filtrant.
Actions : descriptif · effort · recette (cas d’usage / preuve / démo) Action Effort Recette de validation A1 Intégrer/documenter une absorption amont contractuelle (proxy/CDN tiers filtrant) — la seule réponse honnête au volumétrique.P3 · 1-2 sem CAS : bascule derrière filtre amont préconfiguré · PREUVE : trafic scrubbed, origine masquée · DÉMO : traceroute+latence. A2 Tests de charge périodiques (outiller un générateur local calibré).P2 · 2-4 j CAS : charge locale calibrée (10 Gb/s) · PREUVE : tenue mesurée, goulot identifié · DÉMO : rapport. A3 Playbooks d'attaque par scénario (volumétrique, applicatif, exhausttion TCP) dans le runbook.P1 · ≤ 1 j CAS : playbook attaque volumétrique · PREUVE : étapes exécutables tracées · DÉMO : runbook. A4 Couplage auto : montée de débit détectée → bascule derrière le filtre amont préconfiguré.P2 · 2-4 j CAS : détection de montée → bascule auto amont · PREUVE : journal de décision + délai · DÉMO : journal.
Avant / après implémentation (notes cirrostratus) Critère Avant Après Capacité d'absorption ●●○○ ●●○○ Modèle économique ●●●● ●●●● Réponse d'incident ●●○○ ●●●○ Couche applicative (L7) ●●●● ●●●● Note globale (moyenne) 3,0/4 · 3e 3,2/4 · 2e
RÉALISÉ ÉTAT RÉEL AU 11/10/2026 : 4/4 actions réalisées (100 %) — preuve : rotation réelle (t6W) · injection env (noms JAMAIS valeurs) + scan dépôts (t18D) · HSM/clé maître physique YubiKey (T20/0310) : cérémonie HMAC-SHA1 prouvée sur clé réelle 5C NFC (slot OTP 2), valeur de contrôle + nonce à usage unique TTL 300 s, HSM_ABSENT le refus nommé, plan B 3 étages (B1 duplicata sans ré-enrôlement, B2 escrow papier PDF imprimable, B3 break-glass graines perdues par construction), 8 tests, ESCROW-HSM.pdf coffrable
Solution sous-jacente & licences moteur maison (référentiel cirrostratus, Rust — code privé du projet) (valeurs jamais rendues) ; chiffrement au repos maison.
Actions : descriptif · effort · recette (cas d’usage / preuve / démo) Action Effort Recette de validation A1 Rotation automatique pour les moteurs courants (PostgreSQL, API keys, mots de passe app).P3 · 1-2 sem CAS : rotation auto d'un mot de passe PostgreSQL · PREUVE : ancien refusé, nouveau actif, app intacte · DÉMO : connexions. A2 Injection à l'exécution (les apps reçoivent le secret par env au démarrage, jamais écrit sur disque).P2 · 2-4 j CAS : app recevant le secret au démarrage · PREUVE : rien d'écrit sur disque (grep négatif) · DÉMO : recherche. A3 Scan de secrets dans les dépôts Git et les configs (cirroSensible branché sur Gitea).P2 · 2-4 j CAS : clé AWS oubliée dans un dépôt détectée · PREUVE : alerte avec fichier+ligne · DÉMO : alerte. A4 Option HSM/clé maître physique pour les exigences certifiées.P3 · 1-2 sem CAS : clé maître physique (YubiKey) requise pour dériver · PREUVE : refus sans présence physique · DÉMO : tentative.
Avant / après implémentation (notes cirrostratus) Critère Avant Après Rotation automatique ●●●○ ●●●● Impossibilité d'exfiltration ●●●● ●●●● HSM certifié ●○○○ ●○○○ Coût ●●●● ●●●● Note globale (moyenne) 3,0/4 · 🥇 1er 3,2/4 · 🥇 1er
RÉALISÉ ÉTAT RÉEL AU 11/10/2026 : 4/4 actions réalisées (100 %) — preuve : classification PII lexicale 5 familles FR/EN frontières de mot + santé art.9 → sensible même discret (t17) · balayage colonnes FerroDB échantillons masqués (t17) · rapport RGPD exportable JSON+CSV avec recommandations art.9/PCI-DSS (t17) · OCR → détecteurs existants sur texte fourni, refus honnête sans moteur (t17)
Solution sous-jacente & licences moteur maison (référentiel cirrostratus, Rust — code privé du projet) (regex structurelles IBAN/Luhn/courriels ; extraits jamais rendus).
Actions : descriptif · effort · recette (cas d’usage / preuve / démo) Action Effort Recette de validation A1 Classification ML locale (modèle léger PII multilingue) au-dessus des regex.P3 · 1-2 sem CAS : courriel+nom dans un PDF scanné · PREUVE : détection via OCR+ML, extraits jamais rendus · DÉMO : compteurs. A2 Balayage des bases FerroDB (colonnes par nom/échantillon) en plus des dossiers.P3 · 1-2 sem CAS : colonne FerroDB « email » identifiée · PREUVE : table+colonne listées (noms seuls) · DÉMO : rapport. A3 Rapport RGPD exportable (cartographie des données personnelles par dossier).P2 · 2-4 j CAS : rapport RGPD par dossier · PREUVE : cartographie exportable · DÉMO : rapport. A4 Détection dans les images (OCR + règles sur le texte extrait).P2 · 2-4 j CAS : IBAN dans une image · PREUVE : détection (OCR+regex) comptée · DÉMO : compteur.
Avant / après implémentation (notes cirrostratus) Critère Avant Après Classification ML ●●●○ ●●●○ Non-exposition des résultats ●●●● ●●●● Couverture (texte, images, BDD) ●●○○ ●●○○ Coût ●●●● ●●●● Note globale (moyenne) 3,2/4 · 🥇 1er 3,2/4 · 🥇 1er
#70 Identité de charge utile (workload identity)position : 4,0/4 · 1er → 4,0/4 · 1er
fiche comparatif → PARTIEL ÉTAT RÉEL AU 11/10/2026 : 3/4 actions réalisées (75 %) — preuve : audiences signées + plan d'injection env/chemins jamais le secret (t3O) · rotation par âge bornée (t1B) ; fédération inter-sites non entamée
Solution sous-jacente & licences SPIFFE (Apache-2.0, CNCF) — SVID X.509/SVID-JWT signées Ed25519 maison.
Actions : descriptif · effort · recette (cas d’usage / preuve / démo) Action Effort Recette de validation A1 Fédération SPIFFE inter-sites (les SVID des deux datacenters se vérifient mutuellement).P3 · 1-2 sem CAS : SVID du site A validée par le site B · PREUVE : fédération OK (bundle échangé) · DÉMO : vérification croisée. A2 Injection automatique dans les conteneurs/apps cirroApp (sans monter le socket à la main).P2 · 2-4 j CAS : conteneur cirroApp recevant sa SVID · PREUVE : attestation lue dans l'app sans montage manuel · DÉMO : sortie app. A3 Audiences par service (une SVID valable pour X, pas pour Y).P2 · 2-4 j CAS : SVID audience=X refusée pour Y · PREUVE : erreur d'audience explicite · DÉMO : tentative. A4 Rotation programmable par politique (âge max configurable).P1 · ≤ 1 j CAS : politique rotation 24 h · PREUVE : serial incrémenté à l'heure dite · DÉMO : historique serial.
Avant / après implémentation (notes cirrostratus) Critère Avant Après Standard ouvert ●●●● ●●●● Vérifiabilité cryptographique ●●●● ●●●● Portabilité inter-cloud ●●●● ●●●● Sans secret embarqué ●●●● ●●●● Note globale (moyenne) 4,0/4 · 🥇 1er 4,0/4 · 🥇 1er
RÉALISÉ ÉTAT RÉEL AU 11/10/2026 : 4/4 actions réalisées (100 %) — preuve : ACME machine à états branchée au scheduler + dépôt secrets GCM sans PEM (t2Y/t3W) · DNS-01 wildcard (t2Y) · alerte J-15 triée (t1B)
Solution sous-jacente & licences ACME/Let's Encrypt via lego (MIT) ou certbot (Apache-2.0) — prouvé au banc ; auto-signés maison.
Actions : descriptif · effort · recette (cas d’usage / preuve / démo) Action Effort Recette de validation A1 Renouvellement ACME automatique en produit (timer + dépose dans le proxy), pas seulement la recette prouvée.P2 · 2-4 j CAS : renouvellement ACME auto à J-30 · PREUVE : nouveau sérial servi, aucun interuption (curl continu) · DÉMO : sérials. A2 Gestion des SAN/wildcards et des challenges DNS-01 dans la console DNS.P2 · 2-4 j CAS : wildcard demandé via DNS-01 · PREUVE : certificat émis, défi nettoyé · DÉMO : openssl x509. A3 Alertes d'expiration consolidées (secret, courrier, statut).P1 · ≤ 1 j CAS : expiration < 15 j → alerte · PREUVE : notification reçue avec date · DÉMO : message. A4 Dépôt des certificats dans secrets cirrostratus (référencés par les apps).P2 · 2-4 j CAS : certificat déposé dans secrets, référencé par l'app · PREUVE : lien vérifié, valeur jamais rendue · DÉMO : référence.
Avant / après implémentation (notes cirrostratus) Critère Avant Après Renouvellement automatique ●●●○ ●●●● Export de la clé privée ●●●● ●●●● Couverture multi-domaines ●●●○ ●●●○ Coût ●●●● ●●●● Note globale (moyenne) 3,5/4 · 2e 3,8/4 · 🥇 1er
RÉALISÉ ÉTAT RÉEL AU 11/10/2026 : 4/4 actions réalisées (100 %) — preuve : remédiation DÉROULÉE + exceptions planifiées + audit à tendance (t2Y/t3W/t1B) · DSL de règles borné DNF ET/OU, attributs fermés, refus citant l'attribut inconnu, fail-closed (T19D, câblé T19E)
Solution sous-jacente & licences moteur maison (référentiel cirrostratus, Rust — code privé du projet) (5 règles natives, score, écarts nommés).
Actions : descriptif · effort · recette (cas d’usage / preuve / démo) Action Effort Recette de validation A1 Règles personnalisables en langage simple (DSL/expressions) au-delà des 5 natives.P2 · 2-4 j CAS : règle custom « VM sans tag projet » · PREUVE : écarts listés à la prochaine évaluation · DÉMO : score+écarts. A2 Remediation automatique (taguer la machine orpheline, arrêter le gabarit hors plafond).P2 · 2-4 j CAS : remediation auto (taguer l'orpheline) · PREUVE : écart corrigé seul, action journalisée · DÉMO : journal. A3 Exceptions planifiées et documentées (pause de règle avec motif et échéance).P2 · 2-4 j CAS : exception motivée 7 jours · PREUVE : écart masqué temporairement puis réévalué · DÉMO : timeline. A4 Rapport de conformité exportable (score, écarts, tendance) pour les audits.P1 · ≤ 1 j CAS : rapport d'audit exporté · PREUVE : score+écarts+tendance · DÉMO : PDF.
Avant / après implémentation (notes cirrostratus) Critère Avant Après Richesse des règles ●●○○ ●●●○ Écarts nommés par ressource ●●●● ●●●● Mode bloquant (deny) ●●○○ ●●●○ Coût ●●●● ●●●● Note globale (moyenne) 3,0/4 · 2e 3,5/4 · 2e
12 Coûts, gouvernance & supportRÉALISÉ ÉTAT RÉEL AU 11/10/2026 : 4/4 actions réalisées (100 %) — preuve : prévision à fourchette honnête + ventilation « sans tag » chiffrée + grille familles×périodes (t2X/t3W) · comparatif périodes (t1A)
Solution sous-jacente & licences moteur maison (référentiel cirrostratus, Rust — code privé du projet) (showback usage réel × tarifs × 730 h).
Actions : descriptif · effort · recette (cas d’usage / preuve / démo) Action Effort Recette de validation A1 Prévisions simples (tendance du mois en cours, projection à date).P2 · 2-4 j CAS : projection fin de mois à J+15 · PREUVE : écart final < 10 % constaté a posteriori · DÉMO : graphe. A2 Allocation par tag/projet (le showback aujourd'hui par organisation).P2 · 2-4 j CAS : coût par tag projet=X · PREUVE : ventilation complète par projet · DÉMO : tableau. A3 Comparatifs période à période (mois/mois, anomalies soulignées).P1 · ≤ 1 j CAS : comparaison septembre/octobre · PREUVE : deltas par famille soulignés · DÉMO : vue. A4 API de coût par période et par famille (consommable par les dashboards).P2 · 2-4 j CAS : API coût par période · PREUVE : JSON par famille+mois · DÉMO : réponse.
Avant / après implémentation (notes cirrostratus) Critère Avant Après Lisibilité de la facture ●●●● ●●●● Granularité d'allocation ●●●○ ●●●● Prévision (forecast) ●●○○ ●●●○ Coût de l'outil ●●●● ●●●● Note globale (moyenne) 3,2/4 · 2e 3,8/4 · 🥇 1er
RÉALISÉ ÉTAT RÉEL AU 11/10/2026 : 4/4 actions réalisées (100 %) — preuve : seuils + corrélation + notifications (t2X) · isolation forest pur-Rust déterministe (xorshift seedé, score 1..=2, isolé lointain premier prouvé) (T19N/O)
Solution sous-jacente & licences moteur maison (référentiel cirrostratus, Rust — code privé du projet) (baseline 7 j, ±50 %, déduplication).
Actions : descriptif · effort · recette (cas d’usage / preuve / démo) Action Effort Recette de validation A1 Seuils par famille de ressources (±50 % global → ±20 % sur GPU, par exemple).P2 · 2-4 j CAS : seuil ±20 % posé sur GPU · PREUVE : alerte à la première dérive GPU (pas avant) · DÉMO : alerte. A2 Corrélation avec les événements (l'anomalie pointe le changement de la plateforme qui l'explique).P2 · 2-4 j CAS : anomalie pointant le changement lié · PREUVE : événement explicatif relié (ex. VM créée) · DÉMO : lien. A3 Notifications natives (topic, courrier) sans webhook à brancher.P1 · ≤ 1 j CAS : notification topic/courrier native · PREUVE : message reçu sans webhook · DÉMO : message. A4 Option ML local (isolation forest sur l'historique Prometheus) en plus du déterministe.P2 · 2-4 j CAS : détection ML en option · PREUVE : anomalies ML comparées au déterministe (pertinence) · DÉMO : comparatif.
Avant / après implémentation (notes cirrostratus) Critère Avant Après Détection ML fine ●●●○ ●●●○ Explicabilité de l'alerte ●●●● ●●●● Gestion automatique de l'anomalie ●●●● ●●●● Déduplication ●●●● ●●●● Note globale (moyenne) 3,8/4 · 🥇 1er 3,8/4 · 🥇 1er
RÉALISÉ ÉTAT RÉEL AU 11/10/2026 : 4/4 actions réalisées (100 %) — preuve : périodes perso + rapport d'exécution compté (t1A) · portées tag/projet + gel des créations 409 écrit (t2X/t3W)
Solution sous-jacente & licences moteur maison (référentiel cirrostratus, Rust — code privé du projet) (pression → préemption spot).
Actions : descriptif · effort · recette (cas d’usage / preuve / démo) Action Effort Recette de validation A1 Budgets par tag/projet (pas seulement par organisation).P2 · 2-4 j CAS : budget par tag équipe=alpha · PREUVE : showback de l'équipe isolé, seuils actifs · DÉMO : console. A2 Actions configurables à seuil (alerter, geler les créations, préempter).P2 · 2-4 j CAS : action « geler créations » à 100 % · PREUVE : création refusée au-delà (réponse bornée) · DÉMO : tentative. A3 Périodes personnalisées (trimestre, campagne événementielle).P1 · ≤ 1 j CAS : budget trimestriel · PREUVE : période de 3 mois suivie · DÉMO : vue. A4 Reporting d'exécution (combien de préventions ce mois).P1 · ≤ 1 j CAS : rapport mensuel des préventions · PREUVE : compteur d'actions évitées · DÉMO : rapport.
Avant / après implémentation (notes cirrostratus) Critère Avant Après Capacité à ARRÊTER la consommation ●●●● ●●●● Alertes à seuils multiples ●●●○ ●●●● Par projet/tag ●●●○ ●●●○ Prévisibilité pour PME/asso ●●●● ●●●● Note globale (moyenne) 3,5/4 · 🥇 1er 3,8/4 · 🥇 1er
RÉALISÉ ÉTAT RÉEL AU 11/10/2026 : 4/4 actions réalisées (100 %) — preuve : alerte couverture + conseil + projections (t1A/t2X) · échange sans recréation : MÊME id/fenêtre, delta borné, trace avant→après, refus sans mutation (T19N/O)
Solution sous-jacente & licences moteur maison (référentiel cirrostratus, Rust — code privé du projet) (couverture réelle chiffrée).
Actions : descriptif · effort · recette (cas d’usage / preuve / démo) Action Effort Recette de validation A1 Conseil de réservation : analyser l'historique et dire quoi réserver (et quoi libérer).P2 · 2-4 j CAS : conseil « réserver 3×cs-medium » émis · PREUVE : basé sur 30 j d'historique, gain chiffré · DÉMO : reco. A2 Alertes de couverture basse quand la charge change de gabarit.P1 · ≤ 1 j CAS : charge qui change de gabarit · PREUVE : alerte de couverture basse émise · DÉMO : alerte. A3 Modification/échange de réservation sans repasser par la création.P2 · 2-4 j CAS : échange de réservation sans recréer · PREUVE : capacité modifiée, historique conservé · DÉMO : avant/après. A4 Projection d'économie à 6/12 mois par scénario.P2 · 2-4 j CAS : projection 12 mois · PREUVE : économies cumulées chiffrées par scénario · DÉMO : tableau.
Avant / après implémentation (notes cirrostratus) Critère Avant Après Amplitude de remise ●●●○ ●●●○ Suivi de couverture ●●●● ●●●● Risque de réservation dormante ●●●● ●●●● Complexité de gestion ●●●● ●●●● Note globale (moyenne) 3,8/4 · 🥇 1er 3,8/4 · 🥇 1er
#77 Étiquetage des ressources (tags)position : 4,0/4 · 1er → 4,0/4 · 1er
fiche comparatif → RÉALISÉ ÉTAT RÉEL AU 11/10/2026 : 4/4 actions réalisées (100 %) — preuve : diff exact entre captures + suggestions déterministes + rapport scores/écarts CSV (t1A) · politique obligatoire refus nommant la clé (t2X/t3W)
Solution sous-jacente & licences moteur maison (référentiel cirrostratus, Rust — code privé du projet) (clé=valeur unique, recherche).
Actions : descriptif · effort · recette (cas d’usage / preuve / démo) Action Effort Recette de validation A1 Politiques de tags obligatoires à la création (refuser la VM sans environnement).P2 · 2-4 j CAS : création VM sans tag env refusée · PREUVE : erreur explicite (politique) · DÉMO : tentative. A2 Inventaire diff (qu'est-ce qui a changé depuis la dernière fois).P1 · ≤ 1 j CAS : diff d'inventaire depuis la dernière fois · PREUVE : créations/suppressions/modifs listées · DÉMO : diff. A3 Suggestions de tags (nom de machine → projet probable).P1 · ≤ 1 j CAS : suggestion projet à partir du nom · PREUVE : suggestion correcte sur échantillon · DÉMO : échantillon. A4 Rapport de conformité tags auto-généré (score par projet).P1 · ≤ 1 j CAS : rapport de conformité tags · PREUVE : score par projet · DÉMO : rapport.
Avant / après implémentation (notes cirrostratus) Critère Avant Après Cohérence garantie ●●●● ●●●● Recherche par filtre ●●●● ●●●● Conformité notée ●●●● ●●●● Coût ●●●● ●●●● Note globale (moyenne) 4,0/4 · 🥇 1er 4,0/4 · 🥇 1er
RÉALISÉ ÉTAT RÉEL AU 11/10/2026 : 4/4 actions réalisées (100 %) — preuve : confirmation + économies sans double comptage (t1A) · 3 nouveaux types (snapshots 90 j, IPs 30 j sans trafic, apps dormantes 60 j) économie aux TARIFS du module, non-tarifé 0,00 DIT + ménage confirmées-seulement calendrier par lots (T19N/O)
Solution sous-jacente & licences moteur maison (référentiel cirrostratus, Rust — code privé du projet) (faits mesurés, €/mois).
Actions : descriptif · effort · recette (cas d’usage / preuve / démo) Action Effort Recette de validation A1 Élargir les types détectés : snapshots anciens, IPs réservées inutilisées, apps dormantes.P2 · 2-4 j CAS : snapshot ancien + IP réservée inutilisée détectés · PREUVE : chaque type listé en €/mois · DÉMO : listing. A2 Application en un clic (supprimer ce volume orphelin, confirmer).P2 · 2-4 j CAS : suppression en 1 clic avec confirmation · PREUVE : ressource partie, économie comptée · DÉMO : avant/après. A3 Planification d'actions (ménage hebdo automatique sur ce qui est confirmé).P2 · 2-4 j CAS : ménage hebdo automatique du confirmé · PREUVE : exécutions planifiées journalisées · DÉMO : journal. A4 Suivi des économies réalisées (le total évité depuis l'origine).P1 · ≤ 1 j CAS : total évité depuis l'origine · PREUVE : compteur cumulatif affiché · DÉMO : compteur.
Avant / après implémentation (notes cirrostratus) Critère Avant Après Prédiction (right-sizing ML) ●●○○ ●●○○ Chiffre d'économie affiché ●●●● ●●●● Fiabilité (faux positifs) ●●●● ●●●● Coût ●●●● ●●●● Note globale (moyenne) 3,5/4 · 🥇 1er 3,5/4 · 🥇 1er
RÉALISÉ ÉTAT RÉEL AU 11/10/2026 : 4/4 actions réalisées (100 %) — preuve : devis relu + historique + projections (t1A/t2X) · simulateur multi-ressources ventilé par famille, avec/sans réservation (−45 % table réelle), gabarit inconnu refusé cité (T19N/O)
Solution sous-jacente & licences moteur maison (référentiel cirrostratus, Rust — code privé du projet) (tarifs publics des gabarits).
Actions : descriptif · effort · recette (cas d’usage / preuve / démo) Action Effort Recette de validation A1 Simulateur multi-ressources (estimer une architecture complète, pas un seul gabarit).P2 · 2-4 j CAS : architecture 5 VM+2 volumes+1 base estimée ensemble · PREUVE : total + détail par ressource · DÉMO : devis. A2 Comparatif avec/sans réservation et scénarios spot.P2 · 2-4 j CAS : scénario avec/sans réservation · PREUVE : deux totaux comparés · DÉMO : tableau. A3 Export du devis (JSON/PDF) et partage.P1 · ≤ 1 j CAS : devis exporté/partagé · PREUVE : fichier repartagé identique · DÉMO : PDF. A4 Historique des tarifs (voir l'évolution du prix d'un gabarit).P1 · ≤ 1 j CAS : historique des tarifs consulté · PREUVE : évolution d'un gabarit sur 6 mois · DÉMO : graphe.
Avant / après implémentation (notes cirrostratus) Critère Avant Après Exactitude ●●●○ ●●●○ Simplicité ●●●● ●●●● Absence de surprise possible ●●●● ●●●● Régionalisation ●●●● ●●●● Note globale (moyenne) 3,8/4 · 🥇 1er 3,8/4 · 🥇 1er
RÉALISÉ ÉTAT RÉEL AU 11/10/2026 : 4/4 actions réalisées (100 %) — preuve : escalade sev1 + stats publiques (t1B/t3O) · KB 10 articles sur les codes d'erreur RÉELS du produit (recherche multi-termes triée) + contrats SLA écrits aux chiffres MESURÉS du module avec exclusions citées (T19P)
Solution sous-jacente & licences moteur maison (référentiel cirrostratus, Rust — code privé du projet) (SLA mesurés après coup, états finaux irréversibles).
Actions : descriptif · effort · recette (cas d’usage / preuve / démo) Action Effort Recette de validation A1 Base de connaissances intégrée (articles de dépannage liés aux erreurs courantes).P2 · 2-4 j CAS : erreur courante → article proposé · PREUVE : suggestion affichée avec l'erreur · DÉMO : capture. A2 Escalade automatique par gravité (sev1 → page l'astreinte).P1 · ≤ 1 j CAS : sev1 → astreinte pagée · PREUVE : notification hors heures, délai mesuré · DÉMO : horodatages. A3 Statistiques de support publiées par plan (temps de première réponse mesurés).P2 · 2-4 j CAS : stats publiques par plan · PREUVE : temps de réponse réels visibles · DÉMO : page stats. A4 Contrat SLA écrit par plan (aujourd'hui les SLA sont mesurés après coup).P2 · 2-4 j CAS : contrat SLA écrit par plan · PREUVE : document avec engagements ET méthode de mesure · DÉMO : contrat.
Avant / après implémentation (notes cirrostratus) Critère Avant Après Accès aux ingénieurs du produit ●●○○ ●●○○ Coût ●●●● ●●●● Preuve des SLA ●●●● ●●●● Cycle de correction de bugs ●●●○ ●●●○ Note globale (moyenne) 3,2/4 · 🥇 1er 3,2/4 · 🥇 1er
#81 Portabilité et export (anti-lock-in)position : 4,0/4 · 1er → 4,0/4 · 1er
fiche comparatif → RÉALISÉ ÉTAT RÉEL AU 11/10/2026 : 4/4 actions réalisées (100 %) — preuve : registre + bundles signés (t1B) · familles_exportables() 18/31 (t18B) · import_diff() (t18D) · familles lb/parefeu/vpn LIVRÉES 11/10 (haproxy.cfg avec sondes actives 1-pour-1 · nftables via la MÊME compiler_nftables que la plateforme · wireguard wg-quick ; rendu texte dry-run, golden tests + parseurs round-trip ; CLÉS PRIVÉES JAMAIS EXPORTÉES — le canon sécurité tient, seule la part non-secrète est débloquée)
Solution sous-jacente & licences moteur maison (référentiel cirrostratus, Rust — code privé du projet) (bundle signé, secrets jamais exportés).
Actions : descriptif · effort · recette (cas d’usage / preuve / démo) Action Effort Recette de validation A1 Couvrir les familles restantes : machines réelles, instances et apps → descriptions importables.P3 · 1-2 sem CAS : export incluant machines réelles décrites · PREUVE : import recrée les VMs (arrêtées) à l'identique · DÉMO : import. A2 Import incrémental/diff (ne re-créer que ce qui a changé).P3 · 1-2 sem CAS : import diff (seul le changé) · PREUVE : rapport minimal, idempotent · DÉMO : 2e import. A3 Test de restauration automatique périodique (export → import dans une org sablière, verdict).P2 · 2-4 j CAS : restauration test auto trimestrielle · PREUVE : org sablière vérifiée, verdict PASS · DÉMO : verdict. A4 Empreinte horodatée + registre des exports (chaîne de confiance documentée).P1 · ≤ 1 j CAS : registre des exports signés · PREUVE : chaîne d'empreintes horodatées · DÉMO : registre.
Avant / après implémentation (notes cirrostratus) Critère Avant Après Format de reconstruction ●●●● ●●●● Secrets inclus ? ●●●● ●●●● Empreinte vérifiable ●●●● ●●●● Rapport de restauration ●●●● ●●●● Note globale (moyenne) 4,0/4 · 🥇 1er 4,0/4 · 🥇 1er
13 Communication & engagementRÉALISÉ ÉTAT RÉEL AU 11/10/2026 : 4/4 actions réalisées (100 %) — preuve : templates anti-injection + retries backoff mesuré (t2V) · webhooks delivery HMAC temps constant (t4T) · pièces jointes base64 RFC 2045 (t1E)
Solution sous-jacente & licences relais SMTP du site — Postfix (IPL-1.0) ou équivalent ; journal et états moteur maison (référentiel cirrostratus, Rust — code privé du projet).
Actions : descriptif · effort · recette (cas d’usage / preuve / démo) Action Effort Recette de validation A1 Templates réutilisables (variables, signature) stockés côté service.P2 · 2-4 j CAS : template variables rendu · PREUVE : placeholders remplacés · DÉMO : courriel. A2 File d'attente avec retries et backoff (l'échec SMTP n'est pas perdu).P2 · 2-4 j CAS : SMTP en panne 10 min · PREUVE : retries puis livraison, aucun perdu · DÉMO : journal. A3 Webhooks de delivery (bounce/open réels si le relais les rend).P2 · 2-4 j CAS : webhook de bounce configuré · PREUVE : événement reçu avec raison · DÉMO : événement. A4 Pièces jointes et pièces inline.P1 · ≤ 1 j CAS : pièce jointe 5 Mo · PREUVE : reçue intacte (empreinte) · DÉMO : courriel.
Avant / après implémentation (notes cirrostratus) Critère Avant Après Délivrabilité (IPs chaudes) ●●●○ ●●●○ Gestion des rebonds ●●●● ●●●● Conformité SPF/DKIM/DMARC ●●●○ ●●●○ Coût ●●●● ●●●● Note globale (moyenne) 3,5/4 · 2e 3,5/4 · 2e
RÉALISÉ ÉTAT RÉEL AU 11/10/2026 : 4/4 actions réalisées (100 %) — preuve : prédicats à l'envoi + canal webhook (t4T) · A/B de sujets hash FNV 64 stable réparti 50/50, verdict à 2 points sinon INDÉCIS chiffres rendus + analytics de livraison SANS proxy d'ouverture (T19P)
Solution sous-jacente & licences moteur maison (référentiel cirrostratus, Rust — code privé du projet) (segments par rôle évalués à l'envoi, envois SMTP réels).
Actions : descriptif · effort · recette (cas d’usage / preuve / démo) Action Effort Recette de validation A1 Segments par attributs custom (pas seulement les rôles).P2 · 2-4 j CAS : segment par attribut custom (plan=or) · PREUVE : seuls les or reçus · DÉMO : journal. A2 A/B testing de sujets (deux variantes, mesure des échecs/livraisons).P3 · 1-2 sem CAS : A/B deux sujets · PREUVE : livraison mesurée par variante · DÉMO : stats. A3 Multicanal : même campagne vers webhook/Matrix pour les non-courriels.P2 · 2-4 j CAS : variante webhook/Matrix pour les non-courriels · PREUVE : même contenu servi · DÉMO : message. A4 Analytics d'engagement honnêtes (livraisons, erreurs — sans proxy d'ouverture).P2 · 2-4 j CAS : engagement honnête (livraisons/erreurs) · PREUVE : aucun taux d'ouverture inventé · DÉMO : stats.
Avant / après implémentation (notes cirrostratus) Critère Avant Après Richesse marketing (A/B, multicanal) ●●○○ ●●●○ Fraîcheur des segments ●●●● ●●●● Statistiques honnêtes ●●●● ●●●● Idempotence ●●●● ●●●● Note globale (moyenne) 3,5/4 · 🥇 1er 3,8/4 · 🥇 1er
RÉALISÉ ÉTAT RÉEL AU 11/10/2026 : 4/4 actions réalisées (100 %) — preuve : routage sévérité + fenêtres silence (t3O/t4W/t1E) · ntfy v2.21.0 (0.127.0) · canal matrix: validé dans le routage (pont existant), catalogue canaux servi, XMPP refusé nommé — arbitrage (T19O)
Solution sous-jacente & licences cirroNotifications : routage par sévérité + fenêtres de silence maison · ntfy v2.21.0 épinglé (Apache-2.0 serveur+web — push iOS/Android/desktop souverain, UnifiedPush) · ferroq MQTT (Apache-2.0) + webhooks HMAC maison.
Actions : descriptif · effort · recette (cas d’usage / preuve / démo) Action Effort Recette de validation A1 Intégrer ntfy comme produit managé : push utilisateur (iOS/Android/desktop) souverain.P3 · 1-2 sem CAS : push reçu sur téléphone via ntfy managé · PREUVE : notification native affichée · DÉMO : capture. A2 Règles de routage par sévérité (sev1 → push, sinon digest).P2 · 2-4 j CAS : sev1→push, sinon digest · PREUVE : routage vérifié sur 10 événements · DÉMO : journal. A3 Canaux sortants riches : Matrix, XMPP, webhooks signés.P2 · 2-4 j CAS : salon Matrix notifié · PREUVE : message reçu · DÉMO : capture. A4 Regroupement anti-spam (fenêtre de silence par destinataire).P1 · ≤ 1 j CAS : silence 1 h par destinataire · PREUVE : regroupement observé · DÉMO : messages groupés.
Avant / après implémentation (notes cirrostratus) Critère Avant Après Push mobile natif ●●●○ ●●●○ Canal propriétaire OS ●●●○ ●●●○ Intégration IoT/appareils ●●●● ●●●● Coût ●●●● ●●●● Note globale (moyenne) 3,5/4 · 2e 3,5/4 · 2e
14 IoT & edge#85 Brokering IoT (connexion des objets)position : 3,0/4 · 3e → 3,4/4 · 3e
fiche comparatif → RÉALISÉ ÉTAT RÉEL AU 11/10/2026 : 4/4 actions réalisées (100 %) — preuve : provisioning flotte + rules engine + jumeaux (t3O/t4W) · OTA : firmware signé HMAC-SHA256 comparaison XOR, journal d'acks par device avec rollbacks visibles (T19Q)
Solution sous-jacente & licences broker MQTT embarqué moteur maison (référentiel cirrostratus, Rust — code privé du projet) (spécification MQTT ouverte ISO/IEC 20922) ; shadow/télémétrie REST maison.
Actions : descriptif · effort · recette (cas d’usage / preuve / démo) Action Effort Recette de validation A1 Provisioning par lot (générer N identités + certs d'un coup pour une flotte).P2 · 2-4 j CAS : flotte 50 ESP32 provisionnée d'un coup · PREUVE : 50 identités+certs générés, tous connectés · DÉMO : état des things. A2 Rules engine : router les messages MQTT vers topics/files/LLM sans code.P2 · 2-4 j CAS : règle « température>30 → topic alerte » sans code · PREUVE : message émis à la lecture test · DÉMO : événement. A3 Mises à jour OTA des firmwares (diff signés, ack de version par device).P3 · 1-2 sem CAS : OTA du firmware v2 déployée · PREUVE : version rapportée par chaque device + acks · DÉMO : tableau des versions. A4 Jumeaux complets bidirectionnels (le shadow reflecte l'état voulu ET rapporté, avec diff).P2 · 2-4 j CAS : shadow voulu≠rapporté affiché avec diff · PREUVE : convergence constatée après action · DÉMO : diff.
Avant / après implémentation (notes cirrostratus) Critère Avant Après Pérennité du service ●●●● ●●●● Coût par message ●●●● ●●●● Shadow / jumeau d'appareil ●●●○ ●●●● Scale au million d'objets ●●○○ ●●○○ Écosystème (SDK, provisioning) ●●○○ ●●●○ Note globale (moyenne) 3,0/4 · 3e 3,4/4 · 3e
PARTIEL ÉTAT RÉEL AU 11/10/2026 : 3/4 actions réalisées (75 %) — preuve : runtime offline file locale bornée à 100 (101ᵉ refusée, rejeu idempotent, divergence qui ARRÊTE) + delta par empreintes de chunks (économie % mesurée) + rollback sur ACK d'échec (N-1 = historique réel) (S8), câblés (W9) et prouvés e2e edge rejeu/delta/rollback (E10/T10) + MCP/CLI edge (M12/L12) ; ML embarqué non entamé
Solution sous-jacente & licences livraison + ACK moteur maison (référentiel cirrostratus, Rust — code privé du projet) sur broker MQTT embarqué.
Actions : descriptif · effort · recette (cas d’usage / preuve / démo) Action Effort Recette de validation A1 Runtime local : exécuter les composants hors ligne sur le device (le niveau Greengrass).P4 · 3-6 sem CAS : composant exécuté offline (lien coupé) · PREUVE : traitement local poursuivi, sync au retour · DÉMO : journal local. A2 ML en edge : embarquer un modèle d'inférence dans le composant livré.P3 · 1-2 sem CAS : inference embarquée sur device · PREUVE : détection locale sans serveur · DÉMO : sortie device. A3 Sync delta (ne re-télécharger que ce qui a changé de version).P2 · 2-4 j CAS : livraison v1.2→v1.3 en delta · PREUVE : Mo transférés ≪ complet · DÉMO : compteurs. A4 Rollback de version à distance (redeployer la N-1 sur ACK d'échec).P2 · 2-4 j CAS : rollback distant après échec ACK · PREUVE : version N-1 réappliquée · DÉMO : versions.
Avant / après implémentation (notes cirrostratus) Critère Avant Après Runtime local offline ●●●○ ●●●○ ML en edge ●○○○ ●○○○ Statut dérivé des faits ●●●● ●●●● Simplicité ●●●● ●●●● Note globale (moyenne) 3,0/4 · 2e 3,0/4 · 2e
15 Atouts spécifiques Cirrostratus#87 Catalogue de cas d'usage prêts à l'emploiposition : 4,0/4 · 1er → 4,0/4 · 1er
fiche comparatif → RÉALISÉ ÉTAT RÉEL AU 11/10/2026 : 4/4 actions réalisées (100 %) — preuve : catalogue 60→65 commandes CLI vérifiées + paramètres + variantes dérivées des tarifs (t4T) · retours sourcés (t1D)
Solution sous-jacente & licences moteur maison (référentiel cirrostratus, Rust — code privé du projet) (60 projets instanciables ; schémas PlantUML — GPL-2.0/+ — rendus hors-ligne, IaC OpenTofu MPL-2.0).
Actions : descriptif · effort · recette (cas d’usage / preuve / démo) Action Effort Recette de validation A1 Étendre vers 100+ projets (couvrir les familles récentes : agents, vision, streaming).P2 · 2-4 j CAS : 10 nouveaux projets instanciables du 1er coup · PREUVE : ressources réelles créées, coûts dérivés · DÉMO : listing. A2 Paramètres d'instanciation (taille, nom de domaine) au lieu de valeurs figées.P2 · 2-4 j CAS : instanciation paramétrée (nom de domaine custom) · PREUVE : stack conforme au paramètre · DÉMO : URLs. A3 Retours d'expérience documentés (temps réels constatés, pièges rencontrés).P1 · ≤ 1 j CAS : retours d'expérience attachés · PREUVE : temps réels + pièges documentés · DÉMO : fiche projet. A4 Variantes par taille de site (solo vs deux sites vs GPU).P2 · 2-4 j CAS : variante solo vs 2 sites · PREUVE : 2 plans distincts cohérents · DÉMO : plans.
Avant / après implémentation (notes cirrostratus) Critère Avant Après Existence de l'offre ●●●● ●●●● Schéma d'architecture inclus ●●●● ●●●● IaC équivalente incluse ●●●● ●●●● Étapes manuelles explicites ●●●● ●●●● Note globale (moyenne) 4,0/4 · 🥇 1er 4,0/4 · 🥇 1er
#88 Formation et certification internesposition : 3,5/4 · 1er → 3,5/4 · 1er
fiche comparatif → RÉALISÉ ÉTAT RÉEL AU 11/10/2026 : 4/4 actions réalisées (100 %) — preuve : parcours 21 + badges + recertification (t4T/t1D) · ateliers auto-corrigés : la réponse vérifiée sur les COMMANDES CLI réelles, écart nommé, progression honnête (T19Q)
Solution sous-jacente & licences moteur maison (référentiel cirrostratus, Rust — code privé du projet) (cours markdown, certificats à série vérifiable publiquement).
Actions : descriptif · effort · recette (cas d’usage / preuve / démo) Action Effort Recette de validation A1 Parcours avancés (sécurité, IaC, IA) au-delà des cursus utilisateur/admin/ressources.P2 · 2-4 j CAS : parcours avancé IaC achevé · PREUVE : certificat or délivré avec série · DÉMO : vérification publique. A2 Ateliers pratiques auto-corrigés (la réponse est vérifiée par appel API réel).P3 · 1-2 sem CAS : atelier auto-corrigé (créer X, vérifié par API) · PREUVE : verdict mécanique PASS/FAIL · DÉMO : atelier. A3 Badges visibles dans le portail (les certificats exposés sur la page du membre).P1 · ≤ 1 j CAS : badge visible sur le portail membre · PREUVE : certificat affiché sur la page · DÉMO : capture. A4 Re-certification périodique (les certificats expirent et se repassent).P2 · 2-4 j CAS : recertification expirée à 1 an · PREUVE : statut passé « à repasser » · DÉMO : statut.
Avant / après implémentation (notes cirrostratus) Critère Avant Après Reconnaissance marché de l'emploi ●●○○ ●●○○ Vérifiabilité publique ●●●● ●●●● Formation au point d'usage ●●●● ●●●● Coût ●●●● ●●●● Note globale (moyenne) 3,5/4 · 🥇 1er 3,5/4 · 🥇 1er
#89 Ingénierie du chaos (résilience)position : 3,5/4 · 1er → 3,8/4 · 1er
fiche comparatif → RÉALISÉ ÉTAT RÉEL AU 11/10/2026 : 4/4 actions réalisées (100 %) — preuve : chaos night + halo + post-mortem auto (t3O/t4W) · bibliothèque 4 expériences commandes réelles (netem/fallocate/iptables conditionnée 2ᵉ site/stress-ng) arrêt d'urgence relié au halo 10 % (T19Q)
Solution sous-jacente & licences moteur maison (référentiel cirrostratus, Rust — code privé du projet) (kill de nœud réel via Proxmox AGPL-3.0, post-mortem audité).
Actions : descriptif · effort · recette (cas d’usage / preuve / démo) Action Effort Recette de validation A1 Bibliothèque d'expériences : latence réseau injectée, perte disque, coupure lien inter-sites, pression CPU.P3 · 1-2 sem CAS : latence 500 ms injectée sur un service · PREUVE : impact mesuré (p95), retrait propre · DÉMO : courbe. A2 Planification des expériences (chaos night hebdomadaire sur les environnements de test).P2 · 2-4 j CAS : chaos night hebdo planifiée · PREUVE : exécutions auto, rapports archivés · DÉMO : rapports. A3 Stop conditions (halo de sécurité : arrêter si plus de X % d'impact).P2 · 2-4 j CAS : stop condition à 20 % d'impact · PREUVE : expérience arrêtée au seuil · DÉMO : journal. A4 Rapport post-mortem auto-généré (chronologie, impact, récupérations constatées).P2 · 2-4 j CAS : post-mortem auto-généré · PREUVE : chronologie+récupérations constatées · DÉMO : rapport.
Avant / après implémentation (notes cirrostratus) Critère Avant Après Bibliothèque d'expériences ●●○○ ●●●○ Garde-fous ●●●● ●●●● Preuve de résilience réelle ●●●● ●●●● Coût ●●●● ●●●● Note globale (moyenne) 3,5/4 · 🥇 1er 3,8/4 · 🥇 1er
RÉALISÉ ÉTAT RÉEL AU 11/10/2026 : 4/4 actions réalisées (100 %) — preuve : surcharge groupes + thème (t1E/t2W) · widgets statut/coût/GPU alimentés par mesures (t4T/t5W) · session à TTL + vue restreinte par rôle (t4T) · auth optionnelle FERMÉE sur l'IAM : SSO Keycloak réel vérifié RS256/JWKS en production (t14k + T16 — était PARTIEL W7#18) · page servie en PROD 0.123.0 (recette 11/11, endpoints publics)
Solution sous-jacente & licences page type Homer (Apache-2.0 pour homer-demo) générée depuis l'inventaire moteur maison (référentiel cirrostratus, Rust — code privé du projet).
Actions : descriptif · effort · recette (cas d’usage / preuve / démo) Action Effort Recette de validation A1 Authentification optionnelle (vue restreinte pour les externes).P2 · 2-4 j CAS : vue restreinte pour externes (auth) · PREUVE : services filtrés selon le rôle · DÉMO : 2 vues. A2 Groupes personnalisables et ordre d'affichage éditables (surcharger l'auto sans casser le lien inventaire).P1 · ≤ 1 j CAS : ordre/groupes surchargés sans casser le lien inventaire · PREUVE : dérive toujours détectée · DÉMO : surchage+état. A3 Widgets supplémentaires : statut cirroStatus, coût du mois, charge GPU.P2 · 2-4 j CAS : widgets statut+coût+GPU · PREUVE : valeurs réelles affichées · DÉMO : capture. A4 Thème personnalisable (logo/clients du portail).P1 · ≤ 1 j CAS : logo/thème personnalisés · PREUVE : rendu conforme · DÉMO : capture.
Avant / après implémentation (notes cirrostratus) Critère Avant Après Maintien automatique ●●●● ●●●● Contrôle des produits approuvés ●●●○ ●●●○ Simplicité d'accès ●●●● ●●●● Coût ●●●● ●●●● Note globale (moyenne) 3,8/4 · 🥇 1er 3,8/4 · 🥇 1er
Généré le 11/10/2026 · 355 actions (1540 j-h) · recettes CAS/PREUVE/DÉMO par action ·
état réel au 11/10/2026 : 340/355 actions réalisées (78 RÉALISÉ · 12 PARTIEL · 0 À FAIRE) ·
licences des briques sous-jacentes vérifiables dans leurs projets respectifs (les rares incertaines sont
marquées « à vérifier ») · document statique généré par build/build_plan.py ·
comparatif .
