directives-darchitecture-logicielle

SKILL.md

---
name: directives-darchitecture-logicielle
description: Appliquez des conseils contextuels d'architecture logicielle lors de l'analyse des limites du système, des exigences de qualité, de la communication, des styles, des décisions, des risques ou de l'évolution.
---

# Directives d'Architecture Logicielle

Utilisez ce brouillon portable pour soutenir le travail d'architecture à travers les domaines logiciels. Il n'est pas installé globalement. Le livre fournit des concepts et des compromis ; ce guide les opérationnalise sous forme de vérifications conditionnelles. Ce ne sont pas des commandes de projet ni des substituts à l'intention de l'utilisateur, à la gouvernance locale ou aux preuves système connues.

## Flux de travail

1. **Établir le contexte et l'autorité.** Identifier le domaine, la frontière du système, les résultats métier, les contraintes de déploiement et de données, les capacités de l'équipe, les preuves connues, les inconnues, et l'autorité décisionnelle. Respecter l'autorité déjà déléguée. Demander uniquement les faits manquants qui peuvent changer le résultat ; sinon, donner une recommandation conditionnelle.
2. **Classer les moteurs.** Traduire les résultats des parties prenantes en caractéristiques architecturales. Tester chaque candidat selon la définition en trois parties, décomposer les qualités composites, et prioriser un petit ensemble.
3. **Cartographier les frontières et les données.** Identifier les responsabilités fonctionnelles, les dépendances, les transactions, la propriété des données, le couplage statique, les appels à l'exécution, et les caractéristiques à chaque frontière pertinente.
4. **Comparer proportionnellement.** Pour un choix conséquent, comparer au moins deux options viables selon les priorités, coûts, risques et preuves énoncés. Ne pas forcer une comparaison formelle pour un changement mineur et réversible.
5. **Décider avec justification.** Énoncer la recommandation ou le statut, pourquoi elle convient, les coûts acceptés, les hypothèses, et quelles preuves entraîneraient une réévaluation. Suivre l'autorité déléguée ; ne pas inventer de portes d'approbation.
6. **Spécifier les vérifications.** Choisir des mesures ou fonctions d'aptitude proportionnelles au risque. Nommer leur portée, signal, limites et réponse.

## Règles principales

- Fonder les recommandations sur le contexte ([règles de contexte et priorité](references/rulebook.md#context-priorities) : F01) et respecter l'autorité déléguée ([règles de décision, risque et évolution](references/rulebook.md#decisions-risk-evolution) : D03).
- Dériver et classer les caractéristiques à partir des résultats mesurables des parties prenantes ([règles de contexte et priorité](references/rulebook.md#context-priorities) : F05, F06, F07, F08, F18).
- Garder les responsabilités cohésives et les frontières honnêtes quant aux dépendances et au couplage ([règles de frontière](references/rulebook.md#boundaries-coupling-data) : F11–F17, S03, S08 ; [glossaire](references/glossary.md)).
- Choisir la communication adaptée au travail ; distinguer requête, commande et événement, et concevoir pour la défaillance ([règles de communication](references/rulebook.md#communication-reliability) : S06, S09–S13, S15, D08).
- Traiter les styles d'architecture comme des options conditionnelles et comparer leurs coûts ([règles de style](references/rulebook.md#style-choice) : S01, S16, D06 ; [guide de style](references/style-selection.md)).
- Enregistrer pourquoi les décisions conséquentes existent et ce qui les modifierait ([compromis](references/rulebook.md#context-priorities) : F02 ; [enregistrements de décision](references/rulebook.md#decisions-risk-evolution) : F03).
- Rendre visibles les risques, incertitudes et alignements d'implémentation ([règles de risque et évolution](references/rulebook.md#decisions-risk-evolution) : D10, D11, D12, D13).
- Gouverner les contraintes importantes avec des vérifications compréhensibles ([règles de gouvernance](references/rulebook.md#decisions-risk-evolution) : F09, F10).
- Préserver le choix de l'équipe dans l'autorité et les contraintes réelles ([règles d'équipe et communication](references/rulebook.md#communication-teams) : S04, D16, D17, D18).
- Appliquer les directives spécifiques au fournisseur uniquement lorsque le projet inclut un fournisseur de modèle ([D15 dans rules.json](references/rules.json)).

## Contrat de sortie

Retourner : contexte et inconnues ; recommandation et statut ; alternatives et coûts ; implications sur les frontières, données et communication ; preuves et vérifications ; et un déclencheur de réexamen. Adapter le détail à la conséquence du choix.

## Références

Pour une tâche, charger uniquement la catégorie pertinente dans [rules.json](references/rules.json) ou lire sa section dans [rulebook.md](references/rulebook.md), pas les deux ni tout le pack. Charger [style-selection.md](references/style-selection.md) pour les neuf styles, [glossary.md](references/glossary.md) pour les termes basés sur la source, et [source-map.json](references/source-map.json) pour localiser les chapitres cités. Les prompts d'évaluation synthétique sont dans [evaluation-cases.json](references/evaluation-cases.json) ; ils n'ont pas été exécutés. La méthode et les limites sont dans [method-and-validation.md](references/method-and-validation.md).