Nouveau Studio d'architecture
Conçois ton cloud. Casse-le ici, pas en production.
Dessine ton architecture avec de vraies régions, de vrais réseaux et sous-réseaux. Chaque modification est vérifiée comme un vrai déploiement, testée face aux pannes et chiffrée sur AWS, Azure et Google Cloud à partir de leurs prix publics.
- 77 services cloud
- 17 tests, de la panne au ransomware
- 3 clouds chiffrés côte à côte
- 6 régions, Afrique comprise
-
Dessine-la comme tu la déploies
Régions, VPC ou VNet, sous-réseaux publics et privés, passerelles, peering, VPN, hubs de transit : les mêmes briques que dans la console cloud.
-
Vérifiée comme un déploiement
Plages d'adresses qui se chevauchent, base de données joignable depuis Internet, serveur privé sans sortie : ce qui échouerait là-bas échoue ici, avec la raison et la correction.
-
Testée comme en production
Pics de trafic, pannes, pertes de zone et de région, bots, exercice de reprise après sinistre et ransomware, face à tes propres objectifs de disponibilité, de latence, de RTO et de RPO.
-
Chiffrée sur trois clouds
Une facture ligne par ligne à partir des prix publics, transfert de données compris, sur AWS, Azure et Google Cloud. Exporte le schéma ou un rapport PDF complet.
Mes designs
Connecte-toi pour garder tes designs dans ton compte. Tu peux essayer le Studio sans compte : ton travail reste dans ce navigateur.
Se connecterModèles
23 architectures qui fonctionnent, prêtes à adapter : chacune se déploie telle que dessinée et passe ses tests.
- Site statique sur un CDN Un bucket versionné contient le site, un CDN le sert depuis une ville proche de chaque visiteur. Aucun serveur à maintenir, et une facture en dollars, pas en centaines.
- Application web sur un serveur Le départ classique : un serveur dans un sous-réseau public, une base managée dans des sous-réseaux privés. Lance le test de panne pour voir pourquoi ça ne dure pas.
- Application web derrière un load balancer Deux serveurs dans deux zones derrière un load balancer, une base Multi-AZ : un serveur ou une zone peut tomber sans que tes utilisateurs le voient.
- API serverless Des fonctions derrière un CDN et une table clé-valeur : aucun serveur, aucun réseau à gérer, et une facture qui suit le trafic.
- Application web avec un cache Redis répond aux lectures fréquentes en une milliseconde et épargne la base : plusieurs fois plus de trafic sur la même base.
- E-commerce trois tiers CDN, load balancer, serveurs auto-scalés, Redis, un pooler de connexions, PostgreSQL Multi-AZ avec réplica, S3 pour les images et Stripe via NAT. Le paiement attend la carte : son p99 dépasse la seconde.
- API gateway et conteneurs Une API gateway managée authentifie et limite, puis atteint des conteneurs privés par un VPC link ; les données dans une table clé-valeur via des endpoints privés.
- Traitement asynchrone des commandes L'API accepte les commandes en quelques millisecondes et les met en file ; des workers débitent la carte et écrivent la commande. Un fournisseur de paiement lent ne ralentit plus ton site.
- Microservices pour démarrer Deux services derrière un load balancer, chacun avec sa base, qui se parlent par un bus d’événements : le plus petit découpage en microservices qui reste raisonnable.
- Envoi et diffusion de médias Les envois arrivent dans un bucket versionné, une file alimente les transcodeurs, et le CDN diffuse les médias partout avec un origin shield devant le bucket.
- Plateforme web hautement disponible Trois zones de bout en bout : CDN et WAF, load balancer, flotte auto-scalée, cluster Redis, PostgreSQL Multi-AZ avec réplicas, sauvegardes chiffrées copiées dans une autre région.
- Plateforme Kubernetes Un cluster Kubernetes managé sur trois zones avec load balancer d’entrée, Redis, Kafka et une base documents. Les pods prennent des adresses du sous-réseau : des /20 laissent de la marge.
- Architecture événementielle avec Kafka Le service de commandes écrit sa base et publie dans Kafka ; un projecteur construit les vues et l’index de recherche à partir des événements. Les consommateurs peuvent s’arrêter une heure sans perdre un message.
- Cloud hybride avec un VPN Les clients passent par un portail public ; les employés atteignent l’intranet par un VPN site à site depuis le réseau du bureau, dont la plage ne doit pas chevaucher celle du cloud.
- Marketplace avec recherche Les annonces dans une base documents, les photos sur un CDN, un cluster de recherche tenu à jour par un indexeur derrière une file : la recherche reste fraîche même quand l’indexeur redémarre.
- Multi-région actif/passif Paris sert, Francfort attend avec un réplica de la base. Quand Paris tombe, le basculement DNS déplace tes utilisateurs en quelques minutes, en perdant quelques secondes de données.
- Actif/actif mondial L’Europe et l’Amérique servent chacune leurs utilisateurs, à partir d’une table mondiale répliquée dans les deux régions. Si une région tombe, le DNS envoie ses utilisateurs vers l’autre.
- Hub and spoke avec transit gateway Un réseau hub avec le point d’entrée, le pare-feu d’inspection et un NAT central ; un réseau par équipe rattaché à une transit gateway ; le bureau sur une liaison dédiée.
- Streaming vidéo Segments vidéo servis par un CDN avec origin shield, une API de lecture pour le catalogue et la progression, des packagers alimentés par une file, des segments répliqués dans une seconde région.
- Architecture cellulaire Les clients sont répartis en cellules indépendantes, chacune avec son service et sa base, derrière un routeur de cellules : un mauvais déploiement ou une base en panne touche une cellule, jamais toutes.
- Fintech régulée Protection DDoS, trafic inspecté, clés de chiffrement, un registre Multi-AZ répliqué vers une région de secours, et des sauvegardes immuables qui survivent au ransomware.
- SaaS mondial sur trois continents L’Europe, l’Amérique et l’Asie font chacune tourner l’application près de leurs utilisateurs ; une base cohérente mondialement valide les écritures dans trois régions : en perdre une ne fait rien perdre.
- Plateforme d’inférence IA Une API gateway devant un orchestrateur qui récupère le contexte dans un index vectoriel, répond depuis un cache quand il peut et appelle sinon des serveurs de modèles GPU ; les documents sont vectorisés en asynchrone.
Questions
Un design qui passe ici fonctionnera-t-il dans le vrai cloud ?
Le Studio applique les règles des fournisseurs eux-mêmes : plages et adresses réservées, tailles de sous-réseaux, zones exigées par les load balancers et les bases de données, sous-réseaux dédiés sur Azure, passerelles Internet et NAT, peering non transitif, quotas par défaut. Un design que le fournisseur refuserait échoue ici avec la raison. Ce qu'il ne peut pas connaître, comme le code de ton application, reste ta part du travail.
Les prix sont-ils réels ?
Ils viennent des prix publics à la demande d'AWS, d'Azure et de Google Cloud pour chaque région, transfert de données compris. Taxes, offres gratuites, remises et engagements ne sont pas inclus : la facture estime ce que tu paierais sans négocier.
Qu'est-ce qui est gratuit ?
Le palier débutant : de petites architectures jusqu'à 10 composants, un design enregistré, les tests de journée normale et de panne, la facture sur trois clouds et l'export PNG. Chaque formule débloque plus de services, des designs plus grands, plus de tests et le rapport PDF.