Dans un précédent article, les ADR étaient présentés comme un moyen de documenter les décisions d’architecture. Ces décisions s’appuient sur des contraintes et des attentes qui façonnent les choix techniques. C’est le rôle des ASR d’identifier les exigences ayant un impact direct sur la conception.

Dans les systèmes d’information, ce sujet permet de structurer les échanges entre équipes projets, architectes et responsables de domaine. Il contribue également à la gouvernance des décisions d’architecture en apportant des repères partagés entre métiers et équipes techniques. Les ASR rendent explicites les éléments réellement déterminants dans la construction ou l’évolution d’une solution. 

Qu’est-ce qu’un ASR (Architecture Significant Requirement) ?

Un Architecture Significant Requirement désigne une exigence qui influence concrètement les décisions d’architecture. Contrairement aux exigences non fonctionnelles classiques, un ASR introduit une contrainte ou un objectif qui oriente les choix de conception.

Les travaux de Bass, Clements et Kazman les structurent autour de trois dimensions : les attributs de qualité, les contraintes et certaines exigences fonctionnelles influentes. Les attributs de qualité couvrent des aspects comme la performance, la disponibilité ou la sécurité, et orientent directement les mécanismes techniques. Les contraintes limitent l’espace de conception, tandis que certaines fonctionnalités peuvent structurer fortement l’architecture.

Ces catégories se traduisent par des impacts concrets. Une exigence de haute disponibilité implique des mécanismes de tolérance aux pannes. Une contrainte réglementaire peut orienter les choix d’hébergement. Une fonctionnalité en temps réel conduit souvent à une architecture événementielle. 

Dans les projets, ces exigences sont identifiées dès les phases de cadrage. Dans un système exposé à des partenaires externes, par exemple, des exigences de sécurité sur l’authentification et la traçabilité influencent directement les choix d’API Management. 

Un ASR se reconnaît au fait qu’il limite les options d’architecture. En son absence, plusieurs solutions resteraient envisageables. 

L'intérêt des ASR pour un SI

Pour un système d'information, les ASR facilitent les arbitrages en réduisant les ambiguïtés. Lorsque les contraintes majeures sont explicites, les équipes savent où concentrer leurs efforts. 

Ils contribuent également à maintenir un alignement entre les projets. Une exigence de sécurité, par exemple, garantit que les solutions retenues restent cohérentes avec les standards de l'organisation. 

Dans les comités d'architecture, ils servent de base d'analyse. Ils permettent de comparer les options sur des critères partagés et d'améliorer la traçabilité des décisions. 

Au-delà des projets, ils s'intègrent directement dans la gouvernance du système d'information. Ils constituent un référentiel commun utilisé dans les processus de validation, les comités d'architecture et les phases de cadrage. Ils permettent de formaliser des exigences transverses, comme la sécurité, la résilience ou la conformité, et de les décliner de manière cohérente à l'échelle du SI. 

Dans ce cadre, ceux-ci jouent un rôle opérationnel. Ils servent de base pour instruire les dossiers d'architecture, comparer les options techniques et justifier les décisions auprès des parties prenantes. Ils contribuent à homogénéiser les pratiques entre équipes et à limiter les écarts entre projets. 

ASR et ADR : deux artefacts complémentaires

Un ASR exprime une contrainte. Un ADR documente la manière dont l'équipe décide d'y répondre. Les ASR constituent la base sur laquelle s'appuient les décisions. 

Si une application doit rester opérationnelle en cas d'indisponibilité d'un datacenter, cet ASR conduit à formaliser un ADR précisant une architecture multizone. 

Dans ce cas, l'ASR exprime un objectif de continuité de service. L'ADR décrit une réponse concrète, par exemple un déploiement sur plusieurs zones avec réplication des données et bascule automatique. Ce lien permet de comprendre pourquoi une solution technique a été retenue et sur quelle contrainte elle repose. 

L'usage des ASR à l'ère des LLM

Les outils d'IA générative produisent rapidement du code, suggèrent des patterns ou proposent différentes options d'architecture. Cet apport accélère les phases d'exploration, mais les modèles ne disposent pas du contexte du système d'information.

Les ASR permettent d'évaluer ces propositions en les confrontant aux contraintes réelles. Ils aident à écarter les options qui introduisent des compromis non acceptables, notamment en matière de sécurité ou de conformité.

Intégrer les ASR dans les prompts oriente directement les réponses. Des exigences de disponibilité, de déploiement multizone ou de localisation des données conduisent à des architectures plus adaptées au contexte.

Cette approche est particulièrement utile lors des phases de cadrage ou de refonte.

Dans une approche plus avancée, ces principes s'intègrent dans une chaîne d'agents. Un agent DocWriter structure les sources de vérité et formalise les ASR et les ADR. Ce travail reste validé par un ingénieur.

Un agent Planner produit les spécifications à partir de ces éléments. Un agent d'implémentation génère ensuite le code en respectant les contraintes et décisions. Cette organisation sépare clairement l'intention de l'exécution. 

Un cas concret permet d'illustrer cette approche. Dans le cadre du décommissionnement d'un service SOAP, une API REST devait être exposée à un partenaire externe. L'enjeu consistait à contrôler strictement les accès et à éviter qu'un prestataire puisse soumettre des données sensibles pour en obtenir d'autres en retour. 

Sans contrainte explicite, une génération via un modèle propose généralement une API standard, avec une authentification limitée et un accès large aux données. 

En intégrant les ASR dans le prompt, le résultat évolue. Les contraintes portent sur la sécurisation de l'API via un fournisseur d'identité, l'accès réservé à des clients identifiés et la restitution de données limitée au périmètre de l'utilisateur authentifié. Cela conduit à une architecture intégrant une authentification centralisée, des jetons d'accès et un filtrage des données en fonction du contexte utilisateur. 

Dans ce type de situation, les propositions du modèle sont analysées au regard des ADR existants, notamment sur le choix des mécanismes d'authentification et d'autorisation. Certaines options peuvent être retenues, mais nécessitent des ajustements pour répondre aux contraintes de sécurité et de gouvernance des données. 

Ce cas montre que la valeur des modèles repose sur leur intégration dans un cadre d'architecture existant. Les ASR orientent les propositions, tandis que les ADR assurent la cohérence des décisions dans le temps. 

La démarche BMAD au service de l'identification des ASR

La méthodologie BMAD (Business, Method, Analysis, Decision) propose un cadre structuré pour identifier et formaliser les ASR. Le besoin permet de qualifier les attentes métier et de mettre en évidence les contraintes à l'origine des exigences architecturales.

La partie Method précise la manière dont ces exigences sont analysées et rend explicite leur qualification. Cette étape permet d'identifier les contraintes susceptibles de devenir des ASR.

L'étape Analysis consiste à déterminer si une exigence influence réellement l'architecture. C'est à ce niveau que les ASR sont explicitement identifiés, en distinguant les exigences structurantes de celles qui n'ont pas d'impact sur les choix de conception. 

La phase Decision formalise la manière dont ces ASR sont pris en compte dans l'architecture. Elle se concrétise par des ADR, assurant un lien direct entre les contraintes identifiées et les décisions techniques. 

Cette approche positionne les ASR comme un point de passage central entre le besoin métier et la mise en œuvre technique. Ils permettent de relier explicitement les contraintes métier aux décisions d'architecture et à leur implémentation. 

Elle permet également de formaliser l'intention avant toute phase d'exécution, notamment dans un contexte de modèles génératifs. Les ASR structurent le cadre dans lequel les modèles opèrent, sans redéfinir les contraintes. 

Les résultats restent ainsi alignés avec les objectifs du système. Les modèles exécutent, mais ils ne décident pas. 

Le format habituel d'un ASR

Un ASR repose sur une structure simple avec un identifiant, un contexte, une description de l'exigence et ses impacts. 

Une section de liens permet de relier l'ASR aux besoins métier et aux décisions associées. 

Par exemple, une exigence de performance peut imposer de supporter cinq mille utilisateurs simultanés avec un temps de réponse inférieur à trois cents millisecondes. Cela implique des mécanismes d'élasticité, de cache et de supervision. 

ASR-PERF-002 indique que la plateforme doit supporter cinq mille utilisateurs simultanés avec un temps moyen de réponse inférieur à trois cents millisecondes. Le contexte mentionne des pics d'activité récurrents. Cette exigence implique une architecture évolutive, des capacités de mise à l'échelle automatique, un cache distribué et une solution de supervision adaptée. Sa vérification repose sur un test de charge. 

Ce format concis facilite la compréhension et la réutilisation de l'ASR par toutes les équipes impliquées. 

En conclusion…

La mise en œuvre des ASR nécessite une attention particulière. Leur nombre, leur granularité et leur priorisation influencent directement leur utilité. 

Une multiplication excessive complique leur exploitation. Des exigences trop générales perdent leur valeur opérationnelle. Certaines peuvent entrer en tension et nécessiter des arbitrages explicites. 

La gestion dans le temps reste essentielle. Le versionnement permet de suivre les évolutions. La définition d’états de cycle de vie clarifie leur statut. Une supervision garantit la cohérence du référentiel. 

Sans cette discipline, les ASR deviennent un stock d’exigences difficilement exploitable plutôt qu’un outil d’aide à la décision. 

Ces enjeux prennent encore plus d’importance avec l’usage des LLM. Les modèles s’appuient sur ces artefacts pour produire des résultats cohérents. Les ASR doivent donc être considérés comme un référentiel vivant, maintenu et contrôlé, au même titre que le code, les configurations ou la documentation technique.