Comparatif des services cloud — une ligne par service

EC2 est la référence absolue : catalogue d'instances le plus large du marché (généralistes, mémoire, calcul, GPU, Graviton ARM propriétaire offrant un meilleur rapport prix/performance), facturation à la seconde et écosystème d'images AMI mature. Compute Engine mise sur la simplicité : remises automatiques à l'usage soutenu, machines personnalisées (vCPU/RAM ajustés au pixel), Spot et intégration native des TPU pour l'IA. Azure mise sur l'hétérogénéité d'entreprise : Hybrid Benefit pour réutiliser les licences Windows/SQL, availability sets/zones et intégration Active Directory — décisif en contexte corporate. Cirrostratus fait tourner des VM réelles sur Proxmox avec six gabarits honnêtes (1 à 16 vCPU + un gabarit GPU) : pas de catalogue infini, mais zéro coût de sortie (egress), contrôle physique total et un showback dérivé de l'usage réel (usage × tarif × 730 h). Le compromis est clair : les hyperscalers gagnent sur l'élasticité brute et la profondeur du catalogue, Cirrostratus sur la souveraineté, le coût marginal nul et la prévisibilité — une VM dormante y est un coût connu et taggable, pas une ligne de facture opaque.

AWS Auto Scaling est le plus granulaire : politiques cibles, pas, prédictives (ML), scaling par planification et métriques arbitraires via CloudWatch. Les MIG de GCP ajoutent l'autoscaler et la reconstruction automatique (autohealing) avec des politiques simples à raisonner. Azure scale sets s'appuient sur Azure Monitor et l'intégration aux zones. Cirrostratus fournit l'essentiel opérationnel — bornes min/max par groupe, seuils CPU, décision tick par tick — avec une singularité assumée : la pression budget coupe d'abord les VMs spot, ce qui aligne le scaling sur l'enveloppe financière réelle plutôt que sur une carte bancaire. Ce qu'il manque (prédiction ML, métriques custom) est exactement ce qu'un lab ou une PME souveraine échange contre la maîtrise du coût. Honnêteté du modèle : chaque tick applique UNE décision mesurée sur la charge réelle, pas une simulation.

Les trois hyperscalers proposent un batch managé avec orchestration de files priorisées, conteneurs et reprise sur échec ; AWS Batch est le plus intégré (Fargate/Spot, politiques de tentatives fines), Azure Batch est historiquement fort en HPC (rendering, simulation, MPI), GCP Cloud Batch est le plus récent et le plus sobre. Cirrostratus couvre le cœur du besoin : file d'attente, exécution, code de retour, sortie capturée et tentatives restantes — comptés pour de vrai, échecs enregistrés honnêtement. L'argument fort est le coût : un batch nocturne sur des machines déjà possédées a un coût marginal proche de zéro, là où les hyperscalers facturent chaque vCPU-heure (même à prix Spot). La limite est l'absence de planification de dépendances DAG complexe — pour ça, voir la ligne orchestration.

L'hébergement dédié est le rebutique des clouds publics : nécessaire pour la conformité (licences par socket, données réglementées, isolation physique), mais facturé très cher et rarement transparent. AWS et Azure facturent l'hôte entier quelle que soit sa consommation réelle ; GCP propose des nœuds sole-tenant avec une facturation similaire. Cirrostratus inverse la logique : les vCPU achetés (1 à 64 par hôte) fixent un prix dérivé et public (0,012 €/vCPU/h), la capacité réelle de l'inventaire Proxmox prime sur les valeurs déclarées, et chaque placement est vérifié AVANT inscription — au moindre refus, l'hôte reste intact, jamais d'affinité fantôme. C'est le seul des quatre où le dossier capacité est auditable à la commande, et où une VM orpheline est signalée explicitement.

AWS WorkSpaces et Azure Virtual Desktop (désormais Windows App côté client) industrialisent le VDI : pools, profils itinérants, bureaux Windows multisessions — lourds à opérer mais complets. GCP n'a pas de VDI généraliste et mise sur Cloud Shell (terminal temporaire) et les IDE web. Cirrostratus choisit le segment développeur : une VM dédiée + code-server (VS Code dans le navigateur) + jeton de tunnel, provisionnée en une commande. C'est exactement le flux d'un poste de dev à distance, sans la complexité VDI ni les licences Windows. La limite est assumée : pas de bureau complet ni de GPU partagé pour la 3D — pour du développement, le ratio valeur/complexité est imbattable, surtout depuis un bastion ou un VPN WireGuard managé.

Le PaaS historique promet « poussez votre code, on gère le reste » : Beanstalk reste orienté applications web classiques avec contrôle de l'infrastructure sous-jacente, App Engine offre les versions et le traffic splitting les plus élégants, App Service est le plus riche pour l'entreprise (slots de déploiement, connexions hybrides, plans dédiés). Le revers : l'abstraction fuit tôt ou tard (limites de runtime, prix des plans premium, comportements spécifiques). Cirrostratus ne cherche pas à reproduire ce contrat : sa brique équivalente est le déploiement d'applications conteneurisées (voir ligne suivante), plus honnête sur la nature réelle d'un déploiement moderne. Sur ce créneau PaaS pur, l'avantage reste clairement aux hyperscalers — c'est le prix de la maturité de dix ans d'abstraction web.

C'est le segment le plus disputé : Fargate a normalisé le « conteneur sans serveur » mais reste verbeux à configurer ; Cloud Run est universellement considéré comme la meilleure expérience développeur (déploiement en une commande, scale-to-zero, concurrency par instance, facturation à la requête) ; Container Apps propose un équivalent avec des microservices à la KEDA d'office. Cirrostratus reprend exactement le contrat de Cloud Run, en plus simple encore : une image étiquetée (jamais :latest, refusée), un port, et l'app dort au bout de 10 minutes sans accès — réveillée à la demande, de façon idempotente. Les contraintes (étiquette obligatoire, pas de révision canari natif) sont les compromis d'une plateforme qui tient toutes ses promesses mesurées ; le gain : aucun cold-start facturé, aucun egress, aucun vendor lock-in sur le format d'image OCI standard.

GKE est la référence (upgrades automatiques, autopilot mode où les nœuds disparaissent complètement, intégration Anthos), AKS est le plus compétitif en licence (control plane gratuit) et EKS le plus adopté en entreprise mais le plus cher à l'entrée. Tous trois déportent la complexité sans la supprimer : la facture combine control plane, nœuds, egress et l'opérationnel des upgrades. Cirrostratus provisionne de vrais clusters k3s sur nœuds LXC : création réelle, node pools avec bornes autoscaler, scale réellement exécuté (LXC créés + join en montée, drain + destruction en descente), et upgrades de mineure épinglées nœud par nœud avec version MESURÉE après coup — pas déclarée. Et depuis la 0.130.0, l'option `cilium: true` à la création pose le dataplane **eBPF Cilium 1.20.2 épinglé** (Apache-2.0) : flannel coupé, kube-proxy REMPLACÉ, NetworkPolicies k8s gérées par Cilium et micro-segmentation L7 par org via CiliumNetworkPolicy — la recette complète (commandes réelles, prérequis LXC privilégiés) est servie par l'offre GET /k8s/cilium/offre. Le choix k3s (vs k8s complet) est un choix de sobriété assumé ; en contrepartie, un cluster tourne sur du matériel possédé, avec un coût de control plane nul et une latence de provisioning en minutes.

Lambda a inventé le segment (et le modèle mental « événement → fonction ») avec un écosystème de déclencheurs inégalé ; Cloud Functions s'appuie désormais sur le runtime Cloud Run ; Azure Functions excelle dans l'intégration d'entreprise (durable functions, bindings .NET). Cirrostratus répond en deux étages : cirroFonctions d'abord — quatre genres de déclencheurs natifs (http, règles, topics, cron), pool de warm-starts, métriques p50/p90 et limites honnêtes (30 s par défaut, 5 min max, dites) ; et depuis la 0.125.0 l'offre managée Knative 1.22.0 ÉPINGLÉE (serving + eventing + Kourier, Apache-2.0) : scale-to-zero automatique, révisions immuables avec partage de trafic (canari v1 90 %/v2 10 %), déclencheurs cron devenus PingSource — plan d'installation exact rendu jamais exécuté, manifests générés par fonction (limites et code réels), état du cluster lu pour de vrai. Sur les coûts, l'exécution locale a un coût marginal nul là où l'hyperscaler facture la milliseconde — le fameux crossover conteneur-dédié n'existe tout simplement pas ; pour du spike massif imprévisible, l'hyperscaler garde l'avantage de l'élasticité infinie.

Les registres managés sont commodité pure : ECR et ACR intègrent IAM, réplication géographique et scan d'images (payant en options), Artifact Registry unifie les artefacts (packages, images, langages). La valeur ajoutée réelle par rapport à un registre auto-hébergé est la réplication mondiale et le scan continu — deux besoins rares à l'échelle d'un lab ou d'une PME. Cirrostratus embarque l'offre cirroRegistre : Harbor v2.12.2 ÉPINGLÉ (création en commande, config générée, santé vérifiée — pattern cirroGit), avec divergence d'images détectée par digest, garde 409 sur le tag protégé, et l'analyse Trivy en pipeline réel (spawn → stdout → parse prouvé à frontière processus réelle ; exécution Trivy conditionnée au binaire via CIRRO_TRIVY_BIN, refus honnête si absent). Le pipeline CI/CD cirroPipelines vérifie la source par HTTP (manifeste de registre ou dépôt git) avant de déployer : la confiance se construit à la promotion, pas seulement au push.

S3 est devenu le standard de fait du stockage objet — au point que « compatible S3 » est une catégorie de produit entière. Cloud Storage et Blob Storage en sont des équivalents directs avec des classes de stockage comparables et une intégration IAM propre à chacun. Les points de divergence réels : le pricing à l'opération (lectures/écritures/listings facturées différemment), les frais de sortie (le coût caché n°1 du cloud), et le lock-in des API propriétaires au-dessus du socle S3. cirroS3 expose une API compatible S3 sur SeaweedFS avec un modèle IAM propre : clés d'accès nommées, droits par bucket — et JAMAIS de secrets rendus par l'API (les listes ne montrent que les noms). C'est la compatibilité S3 qui rend la migration triviale dans les deux sens : c'est précisément l'anti-lock-in par conception. La limite : pas de réplication multi-région mondiale — remplacée par des sauvegardes et archives locales maîtrisées.

L'archivage chez les hyperscalers est un produit d'ingénierie financière : stockage à très bas coût, mais délais de restauration gradués (heures) et surtout pénalités de suppression anticipée. Bien conçu (durées d'archivage longues), c'est une économie ; mal dimensionné, la facture de récupération surprend. cirroGlacier fait le pari inverse : des archives froides où tout est mesuré et vérifiable — taille originale et compressée MESURÉES (pas déclarées), ratio, empreinte sha256, rétention, historique des restaurations. La restauration est un dossier auditable, pas une loterie de délais. Pour des volumes de lab/PME (dizaines de Go à quelques To), le stockage sur disque possédé coûte moins cher que Glacier sans aucun de ses pièges contractuels ; à l'échelle du pétabyte froid, l'hyperscaler reste imbattable.

EBS, Persistent Disk et Managed Disks se valent structurellement : SSD généraliste/premium, snapshots incrémentaux, chiffrement au repos, et le même piège de facturation à la capacité provisionnée (et non utilisée). Les différences sont d'intégration (EBS gp3 découpé IOPS/débit/capacité, Ultra disks Azure pour le très haute perf, PD Extreme côté GCP). Cirrostratus expose des volumes blocs avec attachement à la VM et coût horaire affiché, et sa valeur est dans l'écosystème : les recommandations cirroRecos listent les volumes orphelins avec leur €/mois gaspillé — la chasse au gaspillage est intégrée au produit, pas vendue en option Cost Optimization. Là où EBS facture chaque snapshot conservé « au cas où », le modèle local rend le coût du stockage réellement proportionnel au matériel possédé.

EFS est élastique et cher (facturé à l'usage réel, parfait pour le partage multi-AZ imprévisible) ; Filestore et Azure Files sont plus lisibles en capacité provisionnée, Azure Files ajoutant le protocole SMB pour les postes Windows. Le cas d'usage entreprise (partage de fichiers entre VMs, contenu web commun) est bien couvert partout — à prix d'hyperscaler. Cirrostratus fournit des exports NFSv4 managés avec point de montage et CIDR autorisé : sobre, suffisant pour partager des données entre conteneurs et VMs du réseau privé, et inclus dans le coût du matériel. Manque : le SMB et l'élasticité transparente d'EFS ; gain : la bande passante locale est celle du LAN (multi-Gb/s), là où les débits des services managés sont graduellement payants.

AWS Backup a unifié la sauvegarde multi-services (EBS, RDS, EFS, DynamoDB…) avec des politiques cross-région ; Azure Backup est l'outil d'entreprise complet (vaults, rétention GRS, sauvegarde d'agents) ; GCP Backup and DR est le plus récent. La maturité est au rendez-vous partout — le sujet réel est le coût de la réplication multi-région et la testabilité des restaurations. cirroBackup assume la portée locale : fréquence, fenêtre UTC, rétention, et surtout des compteurs de succès/échecs honnêtes par plan, avec l'échéance suivante affichée. La philosophie de la maison — « jamais déduit, toujours lu » — s'applique : un plan de sauvegarde qui échoue est visible comme tel. Complété par les snapshots PVE réels par machine (création/restauration à la demande), le lab dispose d'une chaîne de restauration testable de bout en bout, là où l'industry constate régulièrement que les sauvegardes cloud n'ont jamais été restaurées à blanc. La discipline est vérifiée contre la réalité : le 05/10, la sauvegarde par tar à chaud du plan de contrôle FerroDB affichait quatre échecs consécutifs (02→05/10 — audit.log de 1,1 Go modifié pendant la lecture) ; le correctif (backup natif --compact, troncature du journal au-delà de 100 Mo derrière arrêt propre, purge des .sst.tmp orphelins, alertes ntfy, rétention NAS 90 j) a été déployé le 06/10 et prouvé au premier run (8,9 Go, 244 s, journal 1050→0 Mo) — l'échec a été affiché, jamais déduit, puis corrigé.

Aurora est l'argument technique AWS (stockage répliqué à travers 3 AZ, performances PostgreSQL/MySQL sans en payer l'opérationnel) ; AlloyDB joue ce rôle côté GCP avec un accent analytique colonne ; Azure SQL bénéficie de l'héritage SQL Server et du Hybrid Benefit pour les licenciés. Le modèle économique commun : paie l'instance + le stockage + l'IOPS + le backup + l'egress. FerroDB est le différentiateur le plus profond de Cirrostratus : un moteur SQL original (Rust, moteur A « Data Centric ») déployé en instances 1/3/5 nœuds Raft réelles, accessibles en PostgreSQL-wire (pgwire) — donc compatible avec les clients et ORMs Postgres standard. Il apporte ABAC/RLS/CLS (contrôle d'accès par attributs au niveau moteur), le time travel de requête et l'authentification TOTP. Un moteur jeune ne rivalise pas avec 30 ans de PostgreSQL sur la profondeur SQL, mais le pgwire + le Raft réel le rendent immédiatement utile, et son architecture data-centric propose un modèle de sécurité que même les hyperscalers n'offrent pas nativement à ce niveau.

BigQuery est la référence de l'expérience (serverless total, facturation au Go scanné, séparateur compute/storage réussi) ; Redshift a construit le segment mais exige plus d'opérationnel (clusters, distribution) même si RA3 a corrigé le tir ; Synapse/Fabric DW s'appuie sur l'écosystème Microsoft et les pools dédiés. Le point aveugle commun : le coût au Go scanné devient ingérable sans discipline de partitionnement, et les données DOIVENT vivre dans le cloud pour être interrogées. FerroQuery propose le contrat analytique — entrepôts nommés, SQL en lecture/écriture, vues matérialisées, export Parquet prouvé — sur pods réels à coût marginal nul, avec des durées honnêtes (~10 s par requête lourde, erreur honnête si injoignable). Ce n'est pas la latence de BigQuery, mais aucune requête n'y sera jamais facturée au téraoctette scanné : le coût de l'analytique devient celui du fer local.

DynamoDB est une merveille d'ingénierie (latences à la milliseconde à n'importe quelle échelle, on-demand ou provisionné) et le piège financier symétrique si le modèle d'accès n'est pas pensé ; Bigtable domine l'analytique time-series à très gros débit ; Cosmos DB vend la multi-modélité (clé-valeur, document, graphe) avec une SLA de latence contractuelle — unique au marché. La réponse cirrostratus est à deux étages, comme le FaaS et les workflows : **cirroKV**, le magasin maison — tables et entrées CRUD, TTL délégué, chaque mutation journalisée sur cirroFlux (curseur/dédup/lacune nommés), perf par-entrée MESURÉE en production (×65 HTTP réel à 2,23 ms/req indépendant de la taille de famille) ; et depuis la 0.129.0 l'offre **TiKV v8.5.0 LTS épinglé** (Apache-2.0, CNCF gradué, écrit en Rust) quand l'échelle arrive : réplication Raft 3 répliques, scale-out horizontal (ajouter un nœud rebalance les régions), transactions ACID ou API raw, et géo-réplication — la réponse long terme aux tables globales multi-sites. Le mapping est honnête : table = préfixe de clé raw, le TTL reste cirroKV (TiKV n'a pas de TTL natif, dit), le journal part avant la réplication. Le CR TiKVCluster est rendu en entier, l'état du cluster lu pour de vrai.

Le cache managé est un produit de confort : Redis ou Memcached opérés, avec failover, patchs et monitoring inclus — ElastiCache et Azure Cache facturent l'instance mémoire au prix premium, Memorystore également avec l'argument de l'intégration GCP. La valeur réelle est la disponibilité managée du processus, pas la technologie. cirroCache est livré comme offre managée depuis la 0.126.0 sur **Valkey 9.1.0 épinglé** — le fork Linux Foundation de Redis 7.2.4, resté BSD-3-Clause quand Redis est passé en tri-licence RSALv2/SSPL/AGPL : même protocole, mêmes commandes, mêmes ACL, redis-cli fonctionne tel quel (compatibilité Redis OSS 7.2 annoncée et dite). L'offre tient en une commande, les plans sont chiffrés (nano/small/medium, mémoire et €/h), les modes d'éviction et le TTL par défaut se choisissent, le docker run EXACT est rendu (maxmemory du plan, AOF, port éphémère localhost) jamais exécuté par l'API, la supervision redémarre le moteur tombé (restarts comptés sur PING mesuré, pas supposé) et les ACL restent par utilisateur distinct (action D2, syntaxe identique). Pour un cache de session ou d'API, la différence opérationnelle avec ElastiCache est marginale, la différence de coût un facteur 10 à 50 ; à l'échelle multi-Tb avec réplication cluster, l'hyperscaler reprend l'avantage.

Athena a ouvert la voie « interrogez vos données S3 sans cluster » au Go scanné ; BigQuery fait au moins aussi bien avec les tables externes ; Synapse serverless propose l'équivalent Azure avec la syntaxe T-SQL. L'argument de vente — pas d'infrastructure — masque la facturation au volume scanné : une requête mal filtrée sur du Parquet volumineux coûte cher. cirroAthena offre le même geste sur les données réelles du plan de contrôle (machines, VMs, coûts, événements) : SQL lecture seule stricte (SELECT/WITH uniquement), plafond 1 000 lignes, dialecte détecté. La portée est plus étroite (données du plan de contrôle, pas du bucket arbitraire), mais le prix est nul et le plafond de lignes impose de facto la discipline que les hyperscalers facturent. Pour l'exploration ad-hoc de l'infrastructure, c'est le bon niveau d'abstraction.

Data Factory est le plus complet en connecteurs entreprise et en orchestration visuelle ; Dataflow (Apache Beam) est le plus puissant techniquement (streaming + batch unifiés) mais exige de maîtriser Beam ; Glue s'appuie sur Spark avec un catalogue intégré. Tous facturent au DPU-heure ou à l'exécution, avec la complexité de provisioning qui va avec. cirroDataflow fait le choix radical de la simplicité : un pipeline = une source SQL + une table etl_ matérialisée + une planification, et la dernière exécution affiche les LIGNES COMPTÉES réellement chargées (pas un statut approximatif). Pour 90 % des besoins ETL d'un lab (synchroniser des données opérationnelles vers l'analytique), c'est exactement le bon contrat ; les transformations complexes multi-sources restent le terrain des hyperscalers.

Power BI domine l'entreprise (intégration Microsoft 365, DAX, écosystème de visuels) ; Looker apporte LookML (la sémantique versionnée en code, adorée des data teams) et Looker Studio la gratuité grand public ; QuickSight est le plus récent avec l'embedded analytics et un pricing par session intéressant. Ce sont des plateformes de visualisation complètes — et leur complexité avec. cirroRapports assume la sobriété : des rapports BI définis sur des sources réelles (machines, VMs, coûts, événements), planifiés, exécutables via l'API en CSV, avec l'historique des exécutions. C'est le niveau « rapport opérationnel automatisé », pas le dashboard interactif multi-utilisateurs. Combiné au portail Grafana du monitoring (déployé et mesuré en réel), le besoin visuel courant est couvert sans licence par utilisateur.

Kinesis a défini le segment (shards, replay, KCL) et le facture au shard-heure + PUT ; Event Hubs est l'équivalent Azure avec l'intégration Kafka protocol en option ; GCP répond par le duo Pub/Sub (transport, facturé au Go) + Dataflow (traitement). Le point commun : un excellent replay et une scalabilité sans limite, au prix d'une opérationnalité spécialisée. cirroFlux est un Kinesis maison : partitions avec ordre garanti par clé, rétention configurable, curseurs de lecture (reprise exacte), et compteurs écritures/lectures/évictions mesurés — le modèle mental est identique, à l'échelle d'un LAN. La reprise par curseur est le contrat essentiel du streaming et il est tenu ; le débit d'un shard Kinesis en revanche n'est pas la promesse ici, mais pour l'ingestion d'un lab, la bande passante locale surpasse de loin ce dont on a besoin. La chaîne d'audit qui solidarise ces flux a été accélérée et DÉPLOYÉE en prod (0.134.0, 2 141 tests verts) : cache mémoire du dernier maillon — l'append d'audit n'relit plus la base en régime établi (0 SELECT lent depuis le déploiement) ; la lecture à froid reste coûteuse (6,6 s sur ~4 M de maillons : le moteur FerroDB n'a pas encore le fast-path ORDER BY DESC, dette dite), d'où un budget de requête porté à 15 s pour que le cache se repeuple après un arrêt de nœud au lieu de boucler en dégradation.

Kinesis Video Streams est le seul vrai équivalent hyperscaler : ingestion RTSP/WebRTC, stockage fragmenté, replay et intégration Rekognition — avec une facturation à la data ingérée qui dissuade vite les webcams 24/7. GCP et Azure n'ont pas d'offre dédiée équivalente (il faut composer Media Services + stockage). cirroVideo assume une position unique : le processus ffmpeg lit la source RTSP en TCP et écrit les segments .ts un par un — moteur annoncé, compteurs segment par segment, et 503 honnête si le binaire est absent, jamais de flux simulé. La playlist HLS n'est construite QUE des segments réellement présents sur le disque : l'infrastructure ne peut pas mentir sur ce qu'elle sert. Pour la vidéosurveillance ou le monitoring de lab, c'est la solution la plus honnête et la moins chère des quatre.

Step Functions est la référence du genre : machine à états visuelle, patrons d'erreur (retry/catch) sophistiqués, et le pricing à la transition qui devient significatif à grande échelle ; Logic Apps domine l'intégration SaaS d'entreprise avec ses centaines de connecteurs ; GCP propose Workflows (léger) et Composer (Airflow managé pour la data). La réponse cirrostratus est à deux étages, comme pour le FaaS : **cirroWorkflows**, la Step Functions maison — étapes (webhook, fonction, publication, attendre, condition), retry/catch PAR étape avec backoff propre, worker continu, vue graphique et rejeu depuis une étape avec contexte ; et depuis la 0.128.0 l'offre managée **Argo Workflows 4.0.0 épinglé** (Apache-2.0, CNCF gradué, k8s-natif — monte sur cirroK8s comme Knative) pour les DAG conteneurisés qui grossissent : parallélisme et fan-out/fan-in natifs, chaque étape est un conteneur, artefacts S3, suspend/resume, UI avec graphe et journaux. Le pont est honnête : chaque workflow existant se convertit en manifeste Argo (GET /workflows/{wid}/argo — URL réelles, tentatives/backoff portés en retryStrategy, conditions en when, catchs dits exit handlers). L'orchestration ne coûte rien par transition ; le tick-30 s maison reste plus grossier qu'AWS pour l'immédiat — Argo lève cette limite pour les pipelines conteneurisés.

Le VPC/VNet est la fondation identique des trois clouds : sous-réseaux, tables de routage, security groups — GCP se distingue par son modèle global (règles partagées entre projets via Shared VPC, subnet régional), AWS par la maturité des constructions (Transit Gateway, peering), Azure par l'intégration hybride (VPN/ExpressRoute vers l'on-prem). Le coût y est structurel : NAT gateway, IP publiques, egress inter-AZ. Le réseau Cirrostratus reprend le modèle (CIDR, plage DHCP, passerelle, VLAN) et y INTÈGRE l'IPAM : baux, réservations et adresses libres du pool sont exposés par réseau, avec la réservation prioritaire sur le bail dans la résolution d'IP réelle. Ce qui se configure en 5 services AWS (VPC + DHCP + IPAM + DNS interne + carte réseau) tient en une seule ressource lisible. La contrepartie : pas de multi-région natif — le réseau est celui de votre site, ce qui est aussi sa force en latence.

Route 53 est le plus complet (routing géo/latence/poids, health checks, failover — le nom vient du port 53 et l'ambition est totale) ; Cloud DNS et Azure DNS font le travail avec des zones publiques/privées et l'intégration IAM respective. La différenciation Cirrostratus est originale : ses records A sont PILOTÉS par le surveillant de bascule multi-site — chaque mapping FQDN → IP (primaire/secondaire, TTL) suit le site actif automatiquement en cas de bascule (3 tics muets + repli sain), avec verrou sticky et retour TOUJOURS manuel. C'est du DNS-through-DR : la fonctionnalité pour laquelle on paie Route 53 health checks + ARC chez AWS est native et auditable ici. La limite : pas d'anymore le routing géographique mondial ni la latence anycast — le DNS résout localement.

CloudFront est le CDN le plus intégré (points de présence massifs, Lambda@Edge, Shield natif) ; Cloud CDN bénéficie du réseau mondial de Google (le meilleur backbone du secteur) ; Front Door unifie CDN + L7 load balancing + WAF avec un modèle de règles propre. Ces services valent leur prix pour une audience mondiale — c'est leur raison d'être. cirroCDN est un CDN de périmètre local : origine + TTL + statistiques réellement mesurées (hits/misses, ratio, octets économisés, latence origine). Devant un service consommé depuis un LAN ou un VPN, « économiser des octets » et « réduire la latence origine » restent des objectifs réels — la mise en cache fonctionne pareil. Pour diffuser vers Internet mondial, l'hyperscaler est sans discussion supérieur ; pour servir les utilisateurs de son réseau, cirroCDN fait le travail gratuitement.

Le LB managé est un produit mature partout : ALB/NLB côté AWS (L7/L4 avec target groups), le Global External HTTPS LB de GCP (un seul anycast mondial, le plus élégant), Azure avec son duo LB (L4) / Application Gateway (L7). La facturation combine l'heure du LB + les LCU au traitement — modérée jusqu'à un certain débit. Cirrostratus n'embarque pas de LB dans le catalogue : le banc d'écosystème a prouvé Traefik devant les stacks (avec TLS terminé, routes et middlewares), qui couvre le L7 local très correctement. À l'échelle d'un lab ou d'une PME, un Traefik possédé équilibre la charge réelle qu'on a ; l'anycast mondial, lui, ne s'auto-héberge pas — c'est une frontière assumée.

Les trois clouds vendent du VPN IPsec/IKEv2 managé (tunnels site-to-site, redondance, BGP en option) au tunnel-heure + au Go transféré — le pont vers l'on-prem est un marché en soi. Cirrostratus a choisi WireGuard : code moderne auditable (quelques milliers de lignes vs des centaines de milliers pour IPsec), performance excellente, configuration lisible. L'état exposé montre l'interface, la clé publique et les peers AVEC leurs handshakes réels — on voit d'un coup d'œil qui est vivant. La recette « WireGuard sur Proxmox depuis un fichier .conf » a été écrite et piégée (hyperviseur : Table=off, DNS=, ifupdown2) — la connaissance opérationnelle est documentée. Ce que ça n'a pas : le BGP dynamique multi-tunnels des hyperscalers. Ce que ça a : un protocole qu'on comprend de bout en bout, à coût nul.

AWS VPC IPAM répond à un vrai problème d'entreprise (gérer des dizaines de VPC sans collision CIDR, monitorer les allocations) ; GCP gère cela en interne via l'organisation des projets ; Azure l'aborde via Virtual Network Manager. À l'échelle où ces outils comptent — des milliers de réseaux — ils sont pertinents. L'IPAM cirrostratus est de grain plus fin et plus honnête : par réseau, chaque prise est listée avec la machine attachée, son bail DHCP ou sa réservation, la passerelle, et les adresses libres du pool. La résolution d'IP réelle suit un ordre explicite (réservation > bail > agent) et est LUE après application, jamais déduite. Pour l'opération quotidienne d'un réseau — trouver une IP libre, comprendre qui occupe .23 — c'est plus utile qu'une console IPAM mondiale.

Cloud Map est le service le plus méconnu d'AWS et pourtant central dans les architectures microservices (enregistrement DNS privé automatique, health checking, découverte par attributs) ; GCP et Azure laissent cela à Kubernetes DNS ou aux conventions. cirroCarte généralise le principe à TOUTE ressource adressable de l'organisation : chaque service obtient un nom <nom>.<org>.cirro, et la carte signale les conflits de nom et la dérive (enregistrements à régénérer quand la réalité a bougé). La détection de dérive est précisément ce qui manque aux conventions informelles — c'est la différence entre « on a des noms » et « les noms sont garantis conformes à la réalité ». Segment de niche chez les hyperscalers, mais une vraie hygiène d'infrastructure ici.

Le DR automatisé est le summum de la maturité cloud : Route 53 failover + ARC orchestrent les bascules régionales Azure/GCP ont leurs équivalents (Traffic Manager, Front Door) — au prix d'une architecture active/passive coûteuse (on paie deux fois l'infrastructure pour l'utiliser une). La bascule cirrostratus est un surveillant armé qui sonde la santé réelle des sites (API Proxmox mesurée), maintient les mappings FQDN → IP par site, et bascule après 3 tics muets + repli sain — avec compteur d'échecs, cohérence des records A vérifiée (dérives signalées), verrou sticky anti-oscillation et retour TOUJOURS manuel (leDR ne doit jamais rebasculer seul vers un site non diagnostiqué). Ce design conservateur est une leçon d'ingénierie : la bascule automatique dans UN sens, l'humain décide du retour. Le trio hyperscaler vend plus d'automatisme ; la maison vend de la prévisibilité. Et le second site n'est plus théorique depuis le 04/10 : tunnel WireGuard lab1↔OVH actif (persisté, 90 ms) et cirrod site 2 tournant sur l'hôte OVH (SQLite embarqué) ; ce qui reste à déployer — le nœud FerroDB site 2 et la réplication Raft inter-sites — armera réellement la bascule et débloquera d'un coup les 6 actions « matériel » restantes du plan.

API Management d'Azure est le plus riche du point de vue entreprise (portail développeur, produits, politiques XML, VNet) ; AWS API Gateway est le plus utilisé avec ses étapes de déploiement et l'intégration Lambda native, mais son pricing à la requête + au cache devient significatif ; GCP API Gateway est le plus sobre (config YAML, destiné aux backends serverless), Apigee étant l'offre premium. La fonction cœur commune : throttling, clés d'API, quotas, transformation. cirroPasserelle assume cette fonction cœur uniquement : consommateurs nommés, quota horaire, usage de la fenêtre courante affiché, préfixe de clé visible (jamais la clé complète), activation/désactivation. Simple, lisible, et impossible de se faire facturer 10 k$/mois pour un oubli de cache (cas d'école bien documenté côté AWS). Ce qui manque — portail développeur, transformation de payloads — est le prix de la sobriété.

AppSync est le seul hyperscaler à proposer un service GraphQL managé complet : schéma, résolveurs vers DynamoDB/Lambda, abonnements temps réel, auth fine. GCP et Azure n'ont pas d'équivalent direct (il faut un backend Cloud Run/Functions ou du .NET custom). Cirrostratus est donc le SEUL des quatre avec GCP/Azure à… en proposer un, en lecture seule : un endpoint GraphQL qui interroge les ressources réelles de l'org (machines, VMs, apps, instances, réseaux, buckets, budgets, événements) avec alias et arguments. La lecture seule est un choix de sécurité — on ne peut pas muter l'infrastructure par erreur via le graphe. Pour construire des tableaux de bord et des outils d'exploitation au-dessus du plan de contrôle, c'est une surface d'intégration que ni GCP ni Azure n'offrent nativement, et qu'AWS facture à la requête.

Le trio est légendaire : SNS pour le fan-out simple, GCP Pub/Sub comme probablement le meilleur produit du segment (push/pull, ordering par clé, dead-letter intégrées, facturation au Go), Service Bus pour l'entreprise (sessions, duplicata detection, AMQP). Tous excellent — et tous facturés à l'opération/octet, ce qui devient une ligne sérieuse à volume. cirroTopics fait le fan-out avec deux types d'abonnés : webhooks signés HMAC (l'outil de test envoie un événement et on vérifie X-Cirrostratus-Signature côté destinataire — la vérification d'intégrité est prévue, pas sous-traitée) et les files ferroq. Compteurs livrés/échecs par abonnement : la livraison est un fait mesuré. L'ordering garanti par clé appartient à ferroq/cirroFlux ; le push serverless multi-région, lui, reste l'affaire des hyperscalers.

SQS est le service le plus fiable d'AWS, quasiment indestructible, facturé à la requête ; Storage Queues est l'équivalent Azure simple, Service Bus la version entreprise. GCP n'a pas de file « pure » : Pub/Sub pull sert de file. Le contrat essentiel — au moins une livraison, ordre best-effort, visibilité timeout — est identique partout. ferroq est la file maison, intégrée au courtier multi-protocoles : une file ferroq est consommable en MQTT, STOMP, AMQP 1.0, HTTP, gRPC ou QUIC — le même objet de messagerie exposé sous six dialectes, ce qui est unique aux quatre (chez AWS, il faut choisir SQS OU MQ OU EventBridge). Pour les applications du lab, la file est incluse dans le courtier possédé ; à l'échelle du million de messages/seconde, SQS reste une merveille d'ingénierie.

EventBridge a transformé le bus d'événements en produit (schémas, règles par motif, ingestion d'événements SaaS partenaires) ; Event Grid est l'équivalent Azure (routage par type, intégration Azure Functions profonde) ; Eventarc gère les événements GCP avec les filtres par attributs. La puissance est le routage déclaratif : quand X arrive, déclenche Y. cirroRegles reprend exactement ce contrat — filtres, destinations, déclenchements — et y ajoute l'outil qui manque à tous : le TEST À BLANC, qui montre quelles règles actives attraperaient un événement donné (genre + titre) AVANT de l'émettre. Debuguer un pattern EventBridge est notoirement pénible ; ici, la simulation est un appel d'API. C'est un petit plus fonctionnel qui matérialise une philosophie : la plateforme doit pouvoir répondre « qu'est-ce qui se passerait si… ».

Amazon MQ est l'aveu qu'aucun protocole unifié n'existe : il opère ActiveMQ/RabbitMQ pour les applications qui parlent JMS/AMQP legacy, à côté de SQS/SNS/EventBridge/MSK — quatre produits pour quatre mondes. GCP et Azure n'ont pas d'équivalent généraliste (Azure a le Service Bus support AMQP, c'est tout). ferroq attaque le problème à la racine : UN courtier, SIX protocoles natifs (MQTT, STOMP, AMQP 1.0, HTTP, gRPC, QUIC), avec TLS et le clustering. C'est un choix d'architecture radical — la messagerie comme socle unique polyglotte plutôt que comme constellation de produits — qui a un coût de validation (maturité d'un projet jeune, 134 tests au compteur) mais un avantage opérationnel net : un seul objet à opérer, monitorer, sauvegarder. Les hyperscalers ne peuvent pas se permettre cette unification, elle cannibaliserait leur catalogue.

Le cron managé semble trivial et ne l'est pas : il faut la haute dispo, les retries, le suivi d'exécution et le PIT (planifier dans le futur avec précision). EventBridge Scheduler est le plus abouti (cibles multiples, schedules ponctuelles à la minute), Cloud Scheduler est sobre et fiable, Azure a retiré son Scheduler au profit des timers Logic Apps/Functions — fragmentation assumée. cirroCron fait le travail avec un accent opérationnel : le déclenchement manuel (audité, il nourrit les webhooks) permet de rejouer une exécution ratée sans attendre le prochain passage, et l'audit fait foi. La planification fine à la minute et les cron expressions complexes appartiennent aux hyperscalers ; le besoin réel d'un lab — « tourne-moi ça toutes les nuits et dis-moi quand ça casse » — est couvert avec rejouabilité.

Bedrock agrège les modèles tiers (Anthropic, Meta, Mistral…) derrière une API unique avec garde-fous ; Vertex AI couple Gemini à un Model Garden et les TPU ; Azure OpenAI est le canal historique des modèles OpenAI en entreprise avec les réservations de capacité. Le contrat : le meilleur modèle du moment, managé, facturé au token. Cirrostratus retourne la logique : des endpoints vLLM auto-hébergés (modèles ouverts quantifiés GGUF/FP8), avec le catalogue de la maison et surtout les ALIAS à fallback — la première cible disponible route, les suspendues sont sautées. Le contrôle est total (modèle, quantification, contexte), le coût par token marginal, les latences mesurées (p50/p95/p99 à chaque chat). Ce qu'on perd en pointe de performance (les frontier models à 700 Md de paramètres exigent du matériel dédié — 5×RTX 3090 ne remplacent pas un cluster), on le gagne en confidentialité absolue : aucun prompt ne quitte le site. Pour des données sensibles, ce n'est pas un compromis, c'est une exigence.

Le segment agents est le plus jeune et le plus mouvant : Bedrock Agents orchestre des LLM avec des outils AWS (Lambda, Knowledge Bases), Agent Builder fait l'équivalent GCP avec la recherche entreprise intégrée, Azure pousse AI Foundry. Tous vendent l'abstraction « décrivez l'agent, on gère la boucle ». cirroAgents assume la boucle ReAct à l'ancienne : instructions métier par agent, OUTILS RÉELS (les mêmes que la console — vms_ls, coûts, recommandations), mémoire en notes, politique de lecture seule activable (bloque TOUT outil d'action), et l'historique complet des runs auditable. La gouvernance est le vrai sujet des agents — un agent qui peut agir doit pouvoir être bridé — et la politique lecture seule est plus tranchante que les garde-fous declaratifs des hyperscalers. S'y ajoutent les SUITES D'ÉVALUATION mécaniques (cas notés contains/exact/regex/outil utilisé, un run réel par cas, score %) : l'évaluation d'agent est un produit, pas une après-pensée. La maturité des LLM sous-jacents reste celle des modèles ouverts — l'écart se referme, il n'est pas fermé.

Les registres hyperscaler gèrent le cycle versionné des modèles avec approbations et déploiement intégré — SageMaker Model Registry est le plus abouti, les autres suivent le même modèle. La promesse cirroModeles est plus stricte sur un point essentiel : l'IMMUTABILITÉ des versions (gguf/onnx/pytorch/safetensors) et l'unicité de la production — une seule version en prod à la fois, la promotion d'une autre version EST le rollback, archive en fin de vie. Ce design élimine toute une classe d'incidents (deux « prod » coexistant, artefacts mutés en place). Le chemin de promotion (staging → prod → archive) est le même partout ; la différence est que la garantie d'intégrité est structurelle, pas procédurale. L'écosystème d'entraînement distribué et de pipelines MLOps complet reste l'avantage hyperscaler.

Chez les hyperscalers, le fine-tuning est un job managé : on paie le cluster GPU-heure, avec la profondeur d'écosystème qui va avec (distributed training, hyperparameter tuning, tracking d'expériences). Vertex propose le tuning d'adaptateurs efficace, SageMaker l'entraînement complet. cirroModeles affiner est volontairement plus humble et plus honnête : un entraîneur LOCAL consomme la version gguf de base + les exemples (JSON instruction/réponse, 4 à 200), enregistre une nouvelle version avec les pertes MESURÉES epoch par epoch (le journal d'affinage est consultable), bornes explicites (epochs 1-20, lr 1e-6 à 1e-2) — et si aucun moteur n'est installé, 503 honnête plutôt qu'un simulacre. Le transfer réel en jeu d'un fine-tune reste l'épine du secteur (l'expérience laya-ft l'a prouvé : 0,884 en validation, transfert incomplet en partie) — la maison documente cet écart au lieu de le cacher. Pour les modèles ouverts à taille lab, c'est le seul fine-tuning dont on voit TOUTE la mécanique.

Le feature store répond au problème de la cohérence entraînement/inférence (les mêmes transformations au même moment) — SageMaker et Vertex l'ont managé, Azure n'a pas d'offre dédiée stable. C'est un produit de data science mature dont le ROI n'existe qu'avec une équipe DS établie et des modèles en production réguliers. cirroFeatures couvre le cœur : groupes de features à schéma figé, entités, versions ingérées. Le schéma figé est la vraie garantie (pas de dérive de type silencieuse entre deux entraînements). L'écosystème (streaming ingestion, online/offline stores synchronisés en millisecondes) reste le terrain hyperscaler — à l'échelle d'un lab, l'offline store versionné suffit.

La surveillance de modèles est le parent pauvre du MLOps : dérive de données, dérive de qualité, alerting — Model Monitor et Vertex le font sur des tabulaires, Azure ML sur ses endpoints. La spécificité des LLM (latence, jetons, taux d'erreur, coût par conversation) a rebattu les cartes. Le monitoring cirrostratus est calibré LLM : appels, erreurs, latences p50/p95/p99 MESURÉES à chaque chat, jetons consommés, coût estimé — l'équivalent d'un SageMaker Model Monitor spécialisé endpoints vLLM, branché d'office. La détection de dérive sémantique (le modèle dérive dans ses réponses) est le front de recherche de tous ; personne ne la maîtrise vraiment, et la maison ne prétend pas l'avoir. Sur le mesurable, tout y est.

Rekognition, Vision AI et Azure AI Vision sont d'une redoutable efficacité (détection d'objets, visages, célébrités, modération) — la facturation à l'image rend l'usage trivial à démarrer et coûteux à l'échelle. cirroVision fait un choix de radicalisme honnête : les octets base64 sont réellement décodés, l'en-tête PARSÉ (png/jpeg/gif/webp/bmp), les dimensions MESURÉES, l'empreinte SHA-256 calculée — l'identité cryptographique de chaque image est un fait. L'OCR passe par tesseract SI le moteur est présent ; sans moteur, « aucun » est dit honnêtement, AUCUN mot n'est inventé. C'est l'anti-hallucination par architecture : le service ne peut pas décrire ce qu'il n'a pas réellement analysé. Pour l'analyse d'images de lab (vérifier des captures, extraire du texte), c'est fiable à 100 % sur ce qu'il affirme ; pour la reconnaissance d'objets general-purpose, les hyperscalers sont sans équivalent local.

Textract et Document AI extraient structure (formulaires, tables, factures) avec des modèles entraînés massivement — la qualité sur documents complexes est imbattable en managé. Document Intelligence suit sur la même logique Microsoft. L'OCR de cirrostratus est tesseract : excellent sur le texte imprimé net (99 %+), faible sur la mise en forme complexe et l'écriture manuscrite. Mais il est LOCAL : un document juridique ou médical n'est pas envoyé chez un tiers pour être lu — argument décisif pour le RGPD et les données classifiées. La stratégie honnête est hybride : OCR local pour le courant, API hyperscaler pour l'exceptionnel — la plateforme cirro ne verrouille rien qui empêche ce choix.

Comprehend, Natural Language API et AI Language couvrent sentiment, entités, classification, avec la qualité des grands modèles entraînés. Le différenciateur cirroComprehend est double : les ENTITÉS sont françaises et européennes (IBAN, cartes vérifiées Luhn, SIREN-friendly, courriels, dates, montants) — pas les entités américaines des API génériques — et le texte n'est JAMAIS stocké (analyse en mémoire, résultat rendu, oubli). Ce « rien n'est conservé » est un contrat de privacy structurel, pas une politique de confidentialité : le service n'a tout simplement pas de stockage du contenu. Combiné aux LLM locaux pour l'extraction complexe, le besoin NLP courant (trier, classifier, détecter des données sensibles dans du texte) est couvert sans fuite. La qualité brute des très grands modèles reste supérieure chez les hyperscalers sur les textes ambigus.

Transcribe et Azure Speech excellent (temps réel, diarisation, vocabulaires custom, accents) ; GCP est historiquement le plus fort sur la longue durée et les variantes régionales. Tous facturent à la minute audio et reçoivent l'audio intégral. cirroTranscription s'appuie sur whisper.cpp : un vrai moteur local transcrit le WAV en texte et détecte la langue — la même base technique que les offres « Whisper managé » d'AWS/GCP (AWS Transcribe a d'ailleurs intégré Whisper comme option). L'audio vient soit d'une synthèse cirroVoix, soit d'un fichier local ; échec honnête si aucun moteur installé. La diarisation 393 épisodes du lab Thinkerview a prouvé la chaîne à l'échelle réelle. Pour le français à voix claire, la qualité est proche des hyperscalers ; le streaming temps réel multi-locuteurs, lui, reste leur terrain.

Polly (voix neuronales, SSML riche), Google TTS (WaveNet, très naturelles) et Azure Speech sont les références de naturalité — facturées au million de caractères. cirroVoix utilise piper : synthèse 100 % locale, WAV 22,05 kHz rendu par l'API avec URL d'écoute, plafond 1 000 caractères par appel, échec honnête sans moteur. La naturalité est un cran en dessous des meilleures voix neuronales cloud (l'écart se ressent sur l'intonation expressive), mais la voix est gratuite, illimitée en volume, et AUCUN TEXTE n'est envoyé au-dehors — pour des annonces, de l'accessibilité ou des prototypes, le compromis est excellent. L'audio repartant vers cirroTranscription boucle un pipeline vocal complet local (TTS → fichier → STT), utile pour tester des chaînes de dialogue sans dépendance externe.