Conception d'Architecture Logicielle — Référence Rapide

Que fait Conception d'Architecture Logicielle — Référence Rapide ?

Utilisez cette compétence pour les décisions de conception au niveau système plutôt que pour les détails d'implémentation au sein d'un seul service ou composant.

Référence Rapide

Tâche	Patron/Outillage	Ressources Clés	Quand l'utiliser
Choisir un style d'architecture	En couches, Microservices, Piloté par les événements, Serverless	modern-patterns.md	Projets greenfield, refontes majeures
Concevoir pour la montée en charge	Équilibrage de charge, Mise en cache, Partitionnement, Réplicas en lecture	scalability-reliability-guide.md	Systèmes à fort trafic, objectifs de performance
Assurer la résilience	Disjoncteurs, Réessais, Cloisons, Dégradation progressive	scalability-reliability-guide.md	Systèmes distribués, dépendances externes
Documenter les décisions	Registre de Décisions d'Architecture (ADR)	adr-template.md	Décisions techniques majeures, analyse de compromis
Définir les limites des services	Domain-Driven Design (DDD), Contextes bornés	microservices-template.md	Décomposition en microservices
Modéliser la cohérence des données	ACID vs BASE, Event sourcing, CQRS, Patrons Saga	data-architecture-patterns.md	Transactions multi-services
Planifier l'observabilité	SLIs/SLOs/SLAs, Traçage distribué, Métriques, Journaux	architecture-blueprint.md	Préparation à la production
Migrer depuis un monolithe	Figuier étrangleur, Décomposition de base de données, Trafic miroir	migration-modernization-guide.md	Modernisation d'héritage
Concevoir les communications inter-services	Passerelle API, Service mesh, Patron BFF	api-gateway-service-mesh.md	Réseautage microservices

Quand Utiliser Cette Compétence

Invoquez-la lorsque vous travaillez sur :

• Décomposition du système : Décider entre monolithe, monolithe modulaire, microservices
• Patrons d'architecture : Piloté par les événements, CQRS, en couches, hexagonal, serverless
• Architecture des données : Modèles de cohérence, partitionnement, réplication, patrons CQRS
• Conception de scalabilité : Équilibrage de charge, stratégies de mise en cache, mise à l'échelle de base de données
• Patrons de résilience : Disjoncteurs, réessais, cloisons, dégradation progressive
• Contrats API : Limites des services, versionnage, patrons d'intégration
• Décisions d'architecture : ADR, analyse de compromis, sélection technologique
• Planification de migration : Décomposition monolithe, figuier étrangleur, séparation de base de données

Quand NE PAS Utiliser Cette Compétence

Utilisez d'autres compétences pour :

• Implémentation d'un seul service (routes, contrôleurs, logique métier) → software-backend
• Conception de points d'accès API (conventions REST, schémas GraphQL) → dev-api-design
• Implémentation de la sécurité (authentification, chiffrement, OWASP) → software-security-appsec
• Architecture de composants frontend → software-frontend
• Optimisation de requêtes de base de données → data-sql-optimization

Arbre de Décision : Choix du Patron d'Architecture

Besoins du projet : [Nouveau Système ou Refonte Majeure]
    ├─ Équipe unique, domaine en évolution ?
    │   ├─ Démarrer simple → Monolithe Modulaire (limites de module claires)
    │   └─ Besoin d'itération rapide → Architecture en Couches
    │
    ├─ Équipes multiples, contextes bornés clairs ?
    │   ├─ Déploiement indépendant critique → Microservices
    │   └─ Modèle de données partagé → Monolithe Modulaire avec modules de service
    │
    ├─ Workflows pilotés par les événements ?
    │   ├─ Traitement asynchrone → Architecture Pilotée par les Événements (Kafka, files d'attente)
    │   └─ Machines d'état complexes → Patron Saga + Event Sourcing
    │
    ├─ Charge variable/imprévisible ?
    │   ├─ Modèle paiement à l'utilisation → Serverless (AWS Lambda, Cloudflare Workers)
    │   └─ Traitement par lots → Serverless + files d'attente
    │
    └─ Exigences élevées de cohérence ?
        ├─ Garanties ACID fortes → Monolithe ou Monolithe Modulaire
        └─ Données distribuées → CQRS + Event Sourcing

Facteurs de Décision :

• Seuil de taille d'équipe : <10 développeurs → le monolithe modulaire surpasse généralement les microservices (surcharge opérationnelle)
• Structure d'équipe (Loi de Conway) — l'architecture reflète la structure organisationnelle
• Besoins d'indépendance de déploiement
• Compromis cohérence vs disponibilité (Théorème CAP)
• Maturité opérationnelle (supervision, orchestration)

Voir references/modern-patterns.md pour des descriptions détaillées des patrons.

Directives de Production

Les références de cette compétence sont des connaissances de fond pour vous — assimilez les patrons et présentez-les comme votre propre expertise. Ne citez pas les noms de fichiers de référence internes (par exemple, "depuis data-architecture-patterns.md") dans les résultats destinés à l'utilisateur. Les utilisateurs ne savent pas que ces fichiers existent.

Chaque recommandation d'architecture doit inclure :

• Choix technologiques concrets : Nommez des technologies spécifiques (par exemple, "Temporal.io pour l'orchestration de workflows", "Socket.io avec adaptateur Redis") plutôt que de rester abstrait. L'utilisateur doit prendre des décisions de construction, pas seulement comprendre les patrons.
• Ce qu'il NE FAUT PAS construire : Signalez explicitement ce qu'il faut reporter ou éviter. L'anticipation prématurée est l'erreur d'architecture n°1 — aidez l'utilisateur à l'éviter.
• Alignement équipe et processus : Comment cette architecture s'aligne-t-elle avec la structure de l'équipe ? Quel modèle de propriété implique-t-elle ? Incluez CODEOWNERS, la propriété de déploiement et les limites des tours de garde le cas échéant.
• Métriques de succès : Comment l'équipe saura-t-elle que l'architecture fonctionne ? Incluez des indicateurs mesurables (fréquence de déploiement, délai d'exécution, taux d'erreur, MTTR).
• Longueur ciblée : Visez la profondeur sur les 3 à 5 décisions les plus importantes plutôt qu'une couverture exhaustive de toutes les préoccupations. Une recommandation trop longue à lire est une recommandation qui ne sera pas suivie.

Workflow (Niveau Système)

Utilisez ce workflow lorsqu'un utilisateur demande des recommandations d'architecture, une décomposition ou des décisions majeures de plateforme.

1. Clarifier : énoncé du problème, non-objectifs, contraintes et métriques de succès
2. Capturer les attributs de qualité : disponibilité, latence, débit, durabilité, cohérence, sécurité, conformité, coût
3. Proposer 2 à 3 architectures candidates et comparer les compromis
4. Définir les limites : contextes bornés, propriété, API/événements, contrats d'intégration
5. Décider de la stratégie de données : stockage, modèle de cohérence, évolution de schéma, migrations
6. Concevoir pour les opérations : SLOs, modes de défaillance, observabilité, déploiement, DR, playbooks d'incidents
7. Signaler les limites de périmètre : ce qu'il NE FAUT PAS encore construire, ce qu'il faut reporter, quoi acheter vs construire
8. Documenter les décisions : rédiger des ADR pour les compromis clés et les choix irréversibles

Livrables préférés (choisir ce qui correspond à la demande) :

• Plan d'architecture : assets/planning/architecture-blueprint.md
• Registre de décision : assets/planning/adr-template.md
• Analyses approfondies de patrons : references/modern-patterns.md, references/scalability-reliability-guide.md

Considérations 2026

Chargez seulement lorsque la question implique explicitement des tendances actuelles, des contraintes spécifiques au fournisseur ou "quelle est la dernière réflexion sur X ?"

• references/architecture-trends-2026.md — Ingénierie de plateforme, data mesh, architecture composite, systèmes AI-natifs
• data/sources.json — 60 ressources organisées par catégorie :
  • platform_engineering_2026 — Tendances IDP, convergence AI-plateforme, Backstage
  • optional_ai_architecture — Patrons RAG, conception multi-agent, protocoles MCP/A2A
  • modern_architecture_2025 — Data mesh, architecture composite, architecture continue

Si l'accès web en direct est disponible, consultez 2 à 3 sources faisant autorité parmi data/sources.json et intégrez les résultats dans la recommandation. Sinon, répondez avec des patrons durables et énoncez explicitement les hypothèses qui pourraient changer (limites des fournisseurs, tarification, capacités des services gérés).

Navigation

Références Principales

Lisez au plus 2 à 3 références par question — choisissez celles qui sont les plus pertinentes pour la demande spécifique. Ne lisez pas toutes.

Référence	Contenu	Quand lire
modern-patterns.md	10 patrons d'architecture avec arbres de décision	Choisir ou comparer des patrons
scalability-reliability-guide.md	Théorème CAP, mise à l'échelle DB, mise en cache, disjoncteurs, SRE	Questions de mise à l'échelle ou de fiabilité
data-architecture-patterns.md	Variantes CQRS, event sourcing, data mesh, sagas, cohérence	Flux de données entre les services
migration-modernization-guide.md	Figuier étrangleur, décomposition DB, feature flags, évaluation des risques	Refactorisation d'un monolithe
api-gateway-service-mesh.md	Patrons de passerelle, service mesh, mTLS, observabilité	Communication inter-services
architecture-trends-2026.md	Ingénierie de plateforme, data mesh, systèmes AI-natifs	Tendances actuelles uniquement
operational-playbook.md	Cadre de questions d'architecture, heuristiques de décomposition	Cadrage de discussion de conception

Modèles

Planification & Documentation (assets/planning/) :

• architecture-blueprint.md — Plan de service (dépendances, SLA, flux de données, résilience, sécurité, observabilité)
• adr-template.md — Registre de Décisions d'Architecture pour l'analyse de compromis

Patrons d'Architecture (assets/patterns/) :

• microservices-template.md — Conception de microservices (contrats API, résilience, déploiement, tests)
• event-driven-template.md — Architecture pilotée par les événements (schémas d'événements, patrons saga, event sourcing)

Opérations (assets/operations/) :

• scalability-checklist.md — Liste de vérification de scalabilité (mise à l'échelle DB, mise en cache, tests de charge, auto-scaling, DR)

Compétences Connexes

• software-backend — Ingénierie backend, implémentation API, couche de données
• software-frontend — Architecture frontend, micro-frontends, gestion d'état
• dev-api-design — Patrons de conception REST, GraphQL, gRPC
• ops-devops-platform — CI/CD, stratégies de déploiement, IaC
• qa-observability — Supervision, traçage, alertes, SLOs
• software-security-appsec — Modélisation des menaces, authentification, conception sécurisée
• data-sql-optimization — Conception de base de données, optimisation, indexation
• docs-codebase — Documentation d'architecture, diagrammes C4, ADRs