Cadrer¶

Du besoin métier aux décisions structurantes.

Un système mal cadre produit une architecture qui résout le mauvais problème. Cadrer, c'est investir le temps nécessaire pour comprendre les exigences réelles, identifier les contraintes dures et documenter les décisions avant de dessiner le moindre composant.

Cette phase n'est pas un exercice de documentation. C'est le travail de fond qui evite les refactorings coûteux. On y identifie les parties prenantes et leurs attentes contradictoires. On distingue les exigences fonctionnelles des exigences non-fonctionnelles — et on rend ces dernières mesurables. On inventorie les contraintes (budget, équipe, reglementation, existant) qui eliminent d'office certaines options. On documente les décisions dans des ADR (Architecture Décision Records) pour que chaque choix reste tracable.

Le modèle C4 fournit un langage visuel pragmatique pour communiquer l'architecture a différents niveaux de détail — du contexte système au code. Le cadre TOGAF, malgre sa lourdeur, offre une grille d'analyse utile pour les grandes organisations. Mais l'outil le plus important reste le trade-off analysis : chaque décision architecturale est un compromis, et le cadrage consiste à rendre ces compromis explicites.

UE couverte : complement NFE108 — Méthodologies des systèmes d'information

Parcours¶