Concevoir une architecture microservices
Concevez une architecture microservices complète avec décomposition DDD, patterns de communication, résilience et observabilité.
Coller dans votre IA
Collez ce prompt dans ChatGPT, Claude ou Gemini et personnalisez les variables entre crochets.
Tu es un architecte logiciel spécialisé dans les systèmes distribués et les architectures microservices. Je dois migrer ou concevoir un système selon une architecture microservices.
Système à concevoir :
[DESCRIPTION_DU_SYSTÈME: ex. plateforme e-commerce avec catalogue, commandes, paiements, expédition]
Contexte technique :
- Charge estimée : [EX: 10 000 utilisateurs concurrents, 1M transactions/jour]
- Équipes disponibles : [EX: 3 équipes de 4 développeurs]
- Stack préféré : [EX: Node.js, Python, Go, Java]
- Infrastructure : [EX: Kubernetes sur AWS, GCP, Azure]
- Contraintes : [EX: conformité PCI-DSS, latence < 100ms, haute disponibilité]
Conçois l'architecture microservices complète :
- Décomposition des services : identifie les bounded contexts selon DDD et propose les microservices avec leurs responsabilités. Justifie la granularité choisie.
- Communication entre services : recommande synchrone (REST, gRPC) vs asynchrone (message broker) selon les cas d'usage. Propose la topologie de l'event bus si applicable.
- Gestion des données : stratégie de base de données par service, gestion de la cohérence éventuelle, patterns Saga pour les transactions distribuées.
- Patterns de résilience : Circuit Breaker, Retry, Bulkhead, Timeout avec exemples de configuration.
- Observabilité : stratégie de logging centralisé, tracing distribué et métriques.
- Sécurité : authentification inter-services (mTLS, JWT), gestion des secrets.
- Diagramme : fournis un diagramme d'architecture en ASCII art ou en notation Mermaid.
Personnaliser ce prompt avec Léa
Léa réécrit ce prompt pour ton métier et ton objectif précis — 3 questions suffisent.
Pourquoi ce prompt fonctionne
<p>Ce prompt couvre les sept dimensions critiques d'une architecture microservices en partant des fondamentaux DDD (Domain-Driven Design) pour la décomposition des services. L'ancrage dans les bounded contexts garantit une décomposition alignée sur les réalités métier plutôt que sur des décisions purement techniques.</p><p>La question de la communication entre services est souvent sous-estimée : le choix entre synchrone et asynchrone a des implications profondes sur la résilience et la cohérence des données. Ce prompt force une réflexion explicite sur ces trade-offs pour chaque type d'interaction.</p><p>La demande d'un diagramme en Mermaid est une valeur ajoutée significative : ce format est directement intégrable dans la documentation GitHub/GitLab et permet de communiquer l'architecture visuellement à toutes les parties prenantes, techniques et non techniques.</p>
Cas d'usage
Résultat attendu
Une spécification d'architecture complète avec services identifiés, stratégies de communication, patterns de résilience et diagramme Mermaid.
Améliorez ce prompt
Passez ce prompt dans l'Optimiseur pour renforcer le contexte, les contraintes et le format attendu.
Améliore ce prompt avec l'OptimiseurCommentaires
- LéaIA
Pour maximiser la pertinence, précisez dans `[DESCRIPTION_DU_SYSTÈME]` les dépendances métier entre les bounded contexts, cela orientera les choix synchrone/asynchrone. Ajoutez aussi un critère de succès mesurable (ex. « temps de déploiement < 2h ») pour juger la granularité des services.
Termes du glossaire
📬 Recevez de nouveaux prompts chaque semaine
Rejoignez notre newsletter et ne manquez aucun prompt.
Pour aller plus loin
Prompts similaires
Prompt Sora pour créer des tests E2E
Les tests end-to-end (E2E) sont essentiels pour garantir la fiabilité d'une application, mais leur rédaction reste chronophage et répétitive. Sora, grâce à ses capacités de génération avancées, permet d'automatiser la création de scénarios de tests E2E complets en quelques secondes. En formulant un prompt précis décrivant les parcours utilisateurs, les interactions attendues et les critères de validation, vous obtenez des suites de tests structurées, couvrant les cas nominaux comme les cas limites. L'approche par prompt engineering appliquée à Sora transforme la manière dont les équipes QA et développement abordent la couverture de tests. Au lieu de partir d'une page blanche, vous décrivez le comportement attendu de votre application en langage naturel, et Sora génère le code de test correspondant avec les assertions appropriées. Cette méthode réduit considérablement le temps de mise en place d'une suite E2E tout en maintenant un niveau de qualité professionnel. Que vous utilisiez Playwright, Cypress ou Selenium, les prompts présentés ici s'adaptent à votre stack technique et à la complexité de votre application.
Mettre en place une limitation de débit
Protéger les API contre les abus
Prompt GitHub Copilot pour créer une API REST
GitHub Copilot est devenu un assistant incontournable pour les développeurs souhaitant accélérer la création d'APIs REST. Grâce à son intégration directe dans l'éditeur de code, il comprend le contexte de votre projet et génère du code structuré en temps réel. Que vous travailliez avec Node.js et Express, Python et FastAPI, ou Java et Spring Boot, Copilot s'adapte à votre stack technique pour produire des endpoints conformes aux conventions REST. L'enjeu principal réside dans la formulation du prompt : un prompt bien structuré permet d'obtenir une API complète avec validation des données, gestion des erreurs, authentification et documentation. Un prompt vague, en revanche, produira du code générique nécessitant de nombreuses retouches. Dans ce guide, nous vous proposons un prompt optimisé qui exploite pleinement les capacités de GitHub Copilot pour générer une API REST professionnelle, testable et prête pour la production. Vous découvrirez également des variantes adaptées à votre niveau d'expérience ainsi que des conseils pratiques pour tirer le meilleur parti de cet outil au quotidien.
Mise en œuvre de la CSP avec des nonces
Prévenir les XSS avec une CSP stricte