ADR vs NFR : les décisions d'architecture et la qualité du système ne sont pas la même chose

ADR vs NFR expliqués : découvrez comment les exigences de qualité système orientent les décisions d'architecture, comment les ADR consignent les compromis et pourquoi la validation reste distincte.

Publié:8 octobre 2026 à 14:11

Aleksandar Stajić

Mis à jour: 8 octobre 2026 à 19:31

ADR vs NFR : les décisions d'architecture et la qualité du système ne sont pas la même chose

Une exigence non fonctionnelle (ENF) décrit une qualité, une contrainte ou une condition d'exploitation que le système est censé satisfaire. Un enregistrement de décision d'architecture (EDA) consigne un choix architecturalement significatif effectué en réponse à des exigences, des contraintes, des risques et des compromis. Ils sont liés, mais ils ne sont pas interchangeables : une ENF énonce ce qui doit être vrai ; un EDA explique ce qui a été décidé, pourquoi, et avec quelles conséquences.

Quelle est la différence entre une ENF et un EDA ?

La distinction la plus simple est grammaticale. Une exigence décrit une condition que le système doit satisfaire. Un enregistrement de décision décrit un choix effectué par l'équipe.

Par exemple, « L'API doit renvoyer 95 % des requêtes de lecture en moins de 300 ms sous la charge de référence convenue » est une exigence de qualité. « Utiliser un cache read-through pour cette charge de travail car le chemin mesuré en base de données seule ne peut pas atteindre l'objectif de latence sans coût inacceptable » est une décision d'architecture.

La première affirmation reste valide même si l'implémentation change. La seconde peut ensuite être remplacée par une autre décision si la charge de travail, la technologie, le modèle de coût ou les preuves changent.

ENF et EDA répondent à des questions différentes

	ENF / exigence de qualité	EDA / décision d'architecture
Question principale	What quality, constraint, or operating condition must the system satisfy?	What architecturally significant choice did we make, and why?
Contenu typique	Measurable target, scope, condition, constraint, acceptance or validation rule	Context, decision, rationale, alternatives, trade-offs, status and consequences
Rôle dans le cycle de vie	A requirement to design for and validate	A historical record of a significant decision
Qu'est-ce qui le prouve ?	Measurement, test, analysis, inspection, audit or other validation evidence	The record proves what was decided, not that the resulting system meets the requirement
Quand cela change	When stakeholder need, operating conditions, policy or quality target changes	When the decision is replaced, rejected, deprecated, or superseded

Qu'est-ce qu'une ENF en termes architecturaux précis ?

« Exigence non fonctionnelle » est une étiquette pratique du secteur, mais elle peut masquer plusieurs types d'énoncés différents. Dans le travail d'architecture, la distinction utile est entre comportement fonctionnel, exigences de qualité et contraintes.

L'ISO/IEC 25010:2023 fournit un modèle de qualité de produit avec neuf caractéristiques et sous-caractéristiques qui peuvent être utilisées pour spécifier et évaluer la qualité des produits TIC et logiciels. Le travail d'architecture du SEI traite de même les exigences d'attributs de qualité comme des moteurs majeurs de l'architecture logicielle.

Une ENF utile n'est donc pas « le système devrait être rapide » ou « la plateforme doit être sécurisée ». Ces énoncés nomment des aspirations. Une exigence motrice d'architecture devrait rendre la propriété attendue suffisamment testable pour que les alternatives de conception et les preuves ultérieures puissent être évaluées par rapport à elle.

Énoncé faible	Forme d'exigence plus utile	Pourquoi la différence compte
L'API doit être rapide	Pour la charge de travail W, 95 % de l'opération X se termine en T millisecondes	Définit la charge de travail, l'opération, la métrique et le seuil
Le service doit être disponible	Le service S atteint un objectif de disponibilité convenu sur la fenêtre de mesure M, en excluant les conditions de maintenance explicitement définies	Rend la disponibilité mesurable et définit le périmètre
Les données des locataires doivent être sécurisées	Une requête authentifiée pour le locataire A ne doit jamais récupérer ou modifier les données du locataire B via les chemins applicatifs pris en charge	Transforme un objectif de sécurité vague en propriété d'isolation
Le système devrait évoluer	Le système prend en charge la charge de travail W à la concurrence C tout en respectant les seuils de latence et de taux d'erreur	Relie l'échelle à un comportement de service mesurable
Nous avons besoin de PostgreSQL	Pas une ENF en soi ; énoncer d'abord les qualités de persistance requises ou la contrainte externe	Un choix technologique est normalement une solution, pas l'exigence qu'il est censé satisfaire

Qu'est-ce qu'un enregistrement de décision d'architecture ?

Un enregistrement de décision d'architecture est un compte rendu compact d'une décision d'architecture importante. La formulation originale d'ADR de Michael Nygard met l'accent sur le contexte, la décision, son statut et les conséquences qui en résultent.

L'objet important est la décision, pas le modèle. Différentes équipes utilisent différents formats d'ADR. Un enregistrement plus riche peut également conserver les alternatives, les critères de décision, les compromis, les preuves, les liens vers les exigences et la date ou la version à partir de laquelle la décision s'applique.

ISO/IEC/IEEE 42010:2022 est plus large que la pratique des ADR : il spécifie des exigences pour les descriptions d'architecture et leurs concepts, tout en ne prescrivant explicitement aucun processus, notation, outil, format ou support pour consigner une description d'architecture. Un ADR est donc une technique pratique de consignation des décisions, et non un format imposé par l'ISO 42010.

Champ de l'ADR	Ce qu'il préserve	Pourquoi c'est important
Contexte	Le problème, les forces, les exigences, les hypothèses et l'environnement entourant le choix	Les lecteurs futurs peuvent reconstituer pourquoi un choix était nécessaire
Décision	Le choix devenu faisant autorité	Sépare l'option retenue de la discussion
Statut	Proposé, accepté, rejeté, obsolète, remplacé ou un autre état contrôlé	Empêche les anciennes décisions de rester silencieusement actives
Alternatives	Les autres options viables envisagées	Montre que la solution retenue n'était pas la seule imaginable
Justification / compromis	Pourquoi l'option a été retenue et ce à quoi elle renonce	Rend le raisonnement architectural inspectable
Conséquences	Effets positifs et négatifs attendus, travaux de suivi, risques	Relie un choix local à l'impact sur le système
Date / version	Quand la décision est devenue valide	Soutient la traçabilité historique et le remplacement ultérieur

L'exemple le plus simple : exigence de latence → décision d'architecture

Supposons qu'un product owner et une équipe d'ingénierie conviennent qu'un point de terminaison de recherche doit renvoyer la première page de résultats en moins de 400 ms au 95e centile sous une charge de référence définie.

Cette cible n'est pas un ADR. C'est une exigence de qualité. Le travail d'architecture commence en demandant quelle conception peut la satisfaire compte tenu des autres contraintes du système.

De l'exigence à la preuve

1

1. Énoncer l'exigence

Définir la cible de qualité, la charge, la portée, le seuil et la méthode de validation.

2

2. Identifier la signification architecturale

Déterminer si l'exigence influence matériellement la structure, la technologie, le déploiement, le flux de données ou le modèle opérationnel.

3

3. Évaluer les options

Comparer des alternatives telles que l'indexation, la mise en cache, la dénormalisation, le travail asynchrone, le partitionnement ou une architecture de requête différente.

4

4. Consigner la décision

Capturer le choix d'architecture retenu, la justification, les alternatives, les compromis, le statut et les conséquences dans un ADR.

5

5. Mettre en œuvre

Transformer la décision en code, infrastructure, configuration et comportement opérationnel.

6

6. Valider

Mesurer le système réel par rapport à l'exigence initiale. Le résultat du test valide l'ENF ; l'ADR seul ne le fait pas.

Les ENF et les ADR ont généralement une relation plusieurs-à-plusieurs

Une exigence de qualité peut entraîner plusieurs décisions d'architecture. Une exigence d'isolation des locataires, par exemple, peut influencer la propagation de l'identité, le périmètre de la base de données, la conception des tâches en arrière-plan, les clés de cache, la journalisation d'audit et l'outillage administratif.

Une décision d'architecture peut aussi répondre à plusieurs exigences à la fois. Choisir une frontière de traitement asynchrone peut améliorer la réactivité et l'isolation des défaillances tout en introduisant des compromis de cohérence, de complexité, d'observabilité et d'exploitation.

Pourquoi la relation n'est pas biunivoque

	Côté exigence	Côté décision	Côté validation
Une ENF → plusieurs ADR	A broad quality target can constrain several architectural boundaries	Several coordinated decisions may be required	Evidence may need multiple tests or measurements
Plusieurs ENF → un ADR	Several quality and constraint drivers can point at the same design problem	One decision may balance several drivers	Each requirement still needs its own acceptance evidence
ADR sans ENF classique	The driver may be a functional need, policy, ecosystem constraint, cost or delivery condition	The choice can still be architecturally significant	Validate against the actual driver, not an invented NFR
Exigence stable, ADR qui change	The target can remain unchanged	A better or necessary implementation choice can supersede the old decision	The new architecture must still be checked against the same target

Un choix technologique n'est pas automatiquement une exigence

Une erreur d'architecture récurrente consiste à inscrire une technologie préférée dans la couche des exigences, puis à traiter la conception qui en résulte comme inévitable.

« Le système doit utiliser PostgreSQL » peut être une contrainte légitime si un contrat, une politique de plateforme, une exigence de compatibilité, une règle de licence, une norme organisationnelle ou une frontière opérationnelle existante impose réellement PostgreSQL. Mais si le besoin réel est la cohérence transactionnelle, l'interrogation structurée, la familiarité opérationnelle ou un objectif de reprise spécifique, l'exigence devrait énoncer ce besoin et la sélection technologique devrait être consignée comme une décision.

Énoncé	Classification	Raison
Toutes les lectures limitées à un locataire doivent appliquer l'isolation des locataires	Exigence / propriété de sécurité	Décrit une propriété qui doit être respectée
Utiliser la sécurité au niveau des lignes de PostgreSQL pour certaines tables limitées à un locataire	Décision d'architecture	Choisit un mécanisme destiné à aider à satisfaire la propriété d'isolation
La cible de déploiement doit s'exécuter dans un environnement approuvé exploité dans l'UE	Contrainte / condition d'exploitation de type ENF	Restreint le lieu où le système peut fonctionner
Utiliser le fournisseur X dans la région Y	Décision d'architecture / de déploiement, sauf si imposée de l'extérieur	Sélectionne une solution particulière à l'intérieur de la frontière autorisée
Latence de l'API au 95e centile ≤ 300 ms sous la charge W	Exigence de qualité	Définit un comportement de performance mesurable
Introduire un cache pour le point de terminaison X	Décision d'architecture	Sélectionne une tactique destinée à améliorer le comportement mesuré

Un ADR n'est pas la preuve qu'une ENF a été satisfaite

La documentation des décisions et la validation du système répondent à des questions différentes. Un ADR peut montrer que la performance, la sécurité, la résilience ou la maintenabilité ont été prises en compte. Il ne peut pas, à lui seul, démontrer que le système livré atteint réellement ces propriétés.

La preuve doit provenir de la méthode de validation appropriée à l'exigence : benchmark, test de charge, test de défaillance, test de sécurité, analyse d'architecture, audit, inspection, télémétrie opérationnelle, exercice de reprise, étude utilisateur ou une autre forme de preuve.

Quand une exigence non fonctionnelle devient-elle architecturally significant ?

Toutes les exigences non fonctionnelles ne méritent pas une décision d'architecture. Le sous-ensemble important est constitué des exigences qui façonnent matériellement l'architecture ou qui imposent des compromis à l'échelle du système.

La littérature du SEI utilise le concept d'architecturally significant requirements pour les exigences ayant un effet architectural de grande portée. Les attributs de qualité tels que la performance, la fiabilité, la sécurité et la modifiabilité sont des sources fréquentes de tels moteurs, en particulier lorsqu'ils portent une valeur métier ou de mission élevée.

Test de signification architecturale

1

1. Demander si l'exigence modifie la structure

Des valeurs différentes imposeraient-elles des composants, des frontières, des chemins de données ou une topologie de déploiement différents ?

2

2. Demander si elle contraint des choix technologiques majeurs

Élimine-t-elle des options d'implémentation autrement viables ?

3

3. Demander si elle crée un comportement transversal

Affecte-t-elle de nombreux composants, équipes, interfaces ou étapes du cycle de vie ?

4

4. Demander si elle crée un compromis difficile

Améliorer cette propriété affecte-t-il matériellement une autre qualité, le coût, le calendrier, la complexité ou le risque ?

5

5. Demander si l'échec est coûteux

Manquer l'exigence créerait-il un impact opérationnel, de sécurité, réglementaire, financier ou produit matériel ?

6

6. Enregistrer les décisions uniquement là où le raisonnement mérite d'être conservé

Ne créez pas d'ADR pour chaque choix de codage local ; conservez les décisions architecturalement significatives et leur justification.

Un modèle d'architecture plus robuste : exigence → décision → implémentation → validation

Le lien le plus utile entre les NFR et les ADR est la traçabilité. Une exigence devrait pouvoir pointer vers les décisions d'architecture qui la traitent ; un ADR devrait identifier les moteurs auxquels il répond ; le travail d'implémentation devrait réaliser la décision ; la validation devrait revenir à l'exigence d'origine.

Chaîne de traçabilité architecturale

1

Besoin / objectif métier

Pourquoi la qualité ou la contrainte importe.

2

Exigence / NFR

Ce que le système doit atteindre ou respecter.

3

Moteurs d'architecture

Quelles exigences sont suffisamment significatives pour façonner la conception.

4

Options

Façons plausibles de traiter le moteur.

5

ADR

Le choix sélectionné, la justification, les alternatives, les compromis et les conséquences.

6

Implémentation

Code, modèle de données, infrastructure, interfaces et mécanismes opérationnels qui réalisent la décision.

7

Preuve de validation

Tests, mesures, analyses ou audits démontrant si l'exigence d'origine est réellement satisfaite.

8

Changement / remplacement

De nouvelles preuves ou des exigences modifiées peuvent déclencher un nouvel ADR tout en préservant le raisonnement historique.

Preuve d'implémentation : comment je sépare les exigences et les décisions dans SenseFlow

Dans SenseFlow, la Source de Vérité du projet place explicitement les exigences non fonctionnelles à l'intérieur de la structure des exigences, aux côtés des dépendances, des risques, des hypothèses, des critères d'acceptation et d'une méthode de validation. Le modèle de documentation définit séparément l'intégrité des décisions pour les décisions significatives.

Pour les décisions significatives de SenseFlow, les champs enregistrés sont Décision, Raison, Alternatives, Compromis, Statut et Date / Version. Les décisions majeures d'architecture et de produit sont destinées à rester historiquement traçables plutôt que d'être écrasées lorsque le projet évolue.

SenseFlow attribue également des rôles opérationnels différents à Confluence et Jira. Confluence est l'environnement structuré de connaissances et de décisions ; Jira gère le travail de livraison actionnable. Les Épopées Jira majeures devraient renvoyer à la documentation produit ou d'exigences pertinente. Cela préserve la chaîne allant de l'intention produit à travers les exigences et les décisions jusqu'à l'implémentation, plutôt que de transformer le backlog en Source de Vérité de l'architecture.

Couche SenseFlow	Ce qu'elle contient	Rôle dans la séparation ADR/NFR
Structure produit / exigences	Objectif produit, capacité, épopée, récit utilisateur, critères d'acceptation, tâches techniques ; les exigences peuvent inclure des NFR et une méthode de validation	Préserve ce qui doit être atteint et comment le succès sera vérifié
Intégrité des décisions	Décision, raison, alternatives, compromis, statut, date/version	Préserve pourquoi un choix architecturalement significatif est devenu faisant autorité
Confluence	Exigences, architecture, recherche, enregistrements de décisions, risques, feuille de route et sources de support	Maintient la Source de Vérité conceptuelle et historique
Jira	Initiatives/objectifs, épopées, récits, tâches et état de livraison	Exécute le travail approuvé sans devenir la Source de Vérité conceptuelle
Gestion du changement	État actuel → nouvelle preuve → changement proposé → impact → décision	Permet aux décisions d'évoluer sans effacer la trace du raisonnement
Traçabilité de bout en bout	Problème → besoin → valeur → objectif produit → exigence → implémentation → validation	Maintient la documentation des décisions connectée au produit réel et au cycle de vie des preuves

Contexte de projet d'entreprise : les exigences devraient précéder les choix d'architecture

La même séparation est utile dans le travail de projet orienté entreprise. Les décisions d'architecture prises avant que les exigences, les risques, les contraintes et les conditions d'acceptation soient suffisamment compris peuvent transformer des préférences en fausses nécessités.

Pour Enterprise Aaasaasa 0.1, la leçon pertinente est méthodologique plutôt qu'une affirmation sur un ADR particulier : les exigences, l'architecture, la validation, les jalons, la gestion des risques et l'acceptation appartiennent à un système de livraison connecté. Un choix d'architecture devrait rester traçable jusqu'à l'exigence ou la contrainte qu'il est censé traiter.

Modes de défaillance courants lorsque les ADR et les NFR sont mélangés

Mode de défaillance	Ce qui se passe	Conséquence
Technologie déguisée en exigence	Une solution préférée est écrite comme « doit utiliser X » sans établir le besoin sous-jacent	Les alternatives ne sont jamais évaluées et l'architecture est figée prématurément
NFR caché uniquement dans un ADR	La décision mentionne une cible de performance/sécurité absente de la base de référence des exigences	La cible est difficile à valider, prioriser ou gérer indépendamment
ADR traité comme preuve	Un choix documenté est supposé signifier que l'exigence est satisfaite	L'intention architecturale remplace la mesure ou la vérification
NFR vague	Des mots tels que rapide, évolutif, sécurisé ou maintenable n'ont pas de portée mesurable	Différentes parties prenantes peuvent croire que la même exigence signifie des choses différentes
Aucune alternative enregistrée	L'équipe n'enregistre que la technologie sélectionnée	Les futurs mainteneurs ne peuvent pas reconstituer pourquoi une autre option a été rejetée
Aucun modèle de remplacement	Les anciens ADR sont modifiés ou supprimés lorsque l'architecture change	Le raisonnement historique disparaît et les décisions obsolètes peuvent rester ambiguës
Chaque détail d'implémentation devient un ADR	Le référentiel se remplit d'enregistrements de faible valeur	Les choix d'architecture importants deviennent difficiles à trouver
Le backlog devient la source de vérité de l'architecture	Les tâches Jira sont traitées comme la seule explication du système	L'état de livraison survit, mais la justification architecturale et les moteurs de qualité sont perdus

Le cadre de décision ADR–NFR

Lorsqu'une équipe rencontre une nouvelle préoccupation architecturale, la séquence suivante aide à déterminer ce qui appartient aux exigences, ce qui appartient à un ADR et ce qui appartient aux preuves.

Test de classification ADR–NFR

1

1. S'agit-il d'une propriété requise ou d'une contrainte externe ?

Si oui, écrivez ou référencez l'exigence avant de choisir un mécanisme.

2

2. Peut-il être validé ?

Définissez la portée, la condition, la métrique, la règle d'acceptation, la méthode d'analyse ou toute autre preuve nécessaire.

3

3. Est-ce architecturalement significatif ?

Identifiez si l'exigence façonne matériellement la structure, la technologie, les données, le déploiement ou les compromis transversaux.

4

4. Existe-t-il des alternatives significatives ?

Comparez les tactiques ou options d'architecture viables plutôt que de passer directement à une technologie préférée.

5

5. Un choix est-il devenu faisant autorité ?

Créez ou mettez à jour l'ADR avec le contexte, la décision, la justification, les alternatives, les compromis, le statut et les conséquences.

6

6. La décision est-elle mise en œuvre ?

Tracez l'ADR dans la conception, les tâches, le code, la configuration et les opérations.

7

7. L'exigence est-elle satisfaite ?

Recueillez des preuves de validation par rapport à l'exigence elle-même.

8

8. Les conditions ont-elles changé ?

Réévaluez l'exigence et, si nécessaire, remplacez l'ADR sans effacer l'historique.

Ce que l'ADR et la NFR ne sont pas

Erreurs de catégorie courantes

	Concept	Ce n'est pas	Raison
NFR / exigence de qualité	A required quality, constraint or operating condition	A technology shopping list	Requirements should preserve the need independently from one implementation when possible
ADR	A record of an architecturally significant decision	The complete architecture description	Architecture also needs views, interfaces, models, responsibilities and other documentation
Preuve de validation	Evidence that checks whether a requirement is satisfied	The ADR itself	Documented intent is different from measured or analyzed system behavior
Élément de backlog	Actionable delivery work	A durable substitute for architecture rationale	Task state answers what is being delivered, not necessarily why the architecture exists
Contrainte	A condition that restricts the solution space	Always an internally chosen architecture decision	Some constraints come from regulation, contracts, existing platforms or organizational boundaries

Qu'est-ce qui changerait cette réponse ?

La terminologie peut évoluer. L'ISO/IEC/IEEE 29148:2018 reste la norme d'ingénierie des exigences publiée en vigueur au 8 octobre 2026, mais l'ISO répertorie un projet de norme internationale destiné à la remplacer. Si la nouvelle édition modifie la terminologie ou les directives relatives aux exigences, les références spécifiques à la version dans cet article devraient être mises à jour.

Les modèles d'ADR peuvent également évoluer sans changer la distinction centrale. Le modèle minimal de Michael Nygard, MADR, les modèles spécifiques à l'organisation, les outils de connaissance architecturale ou les bases de données de décisions structurées peuvent tous enregistrer des décisions. La question durable est de savoir si l'enregistrement préserve suffisamment de contexte et de justification pour comprendre un choix architecturalement significatif.

La distinction ne s'effondrerait que si une organisation choisissait délibérément un artefact combiné qui stocke à la fois les données d'exigence et de décision dans un seul document. Même dans ce cas, les rôles sémantiques restent différents : un champ énonce le résultat ou la contrainte requis ; un autre enregistre la réponse choisie.

Limites

Cet article utilise NFR comme abréviation pratique. Certaines méthodes d'ingénierie préfèrent des termes tels qu'exigence d'attribut de qualité, exigence de qualité, qualité système, contrainte, objectif de niveau de service ou exigence architecturalement significative. Ces termes ne sont pas parfaitement interchangeables, et la terminologie du projet doit être explicite.

Toutes les exigences ne peuvent pas être réduites à un seul seuil numérique. La sécurité, la sûreté, la maintenabilité, l'interopérabilité, l'utilisabilité, l'explicabilité, la portabilité et la gouvernance peuvent nécessiter des combinaisons de scénarios, de règles structurelles, d'analyses, de contrôles de processus et de preuves qualitatives. « Mesurable » devrait signifier suffisamment vérifiable pour la décision, et non artificiellement numérique.

Toutes les décisions d'architecture n'ont pas besoin d'un ADR formel. Le coût de documentation doit être proportionnel à l'importance architecturale, à la longévité, à l'incertitude, à la complexité des compromis et au coût de la perte de la justification.

Conclusion

L'ADR et la NFR appartiennent à des couches différentes du travail d'architecture. La NFR définit une cible de qualité, une contrainte ou une condition d'exploitation. L'ADR enregistre une réponse architecturale significative à un ou plusieurs moteurs.

Garder ces couches séparées rend l'architecture plus facile à raisonner. Les exigences peuvent être validées indépendamment de la technologie. Les décisions peuvent être remplacées sans réécrire l'historique. Les alternatives et les compromis restent visibles. Le travail de livraison peut être retracé jusqu'à l'intention architecturale. Les preuves peuvent montrer si le système résultant satisfait réellement l'exigence.

La chaîne la plus solide n'est donc pas « NFR → ADR → terminé ». C'est besoin → exigence → moteurs architecturaux → options → décision → mise en œuvre → validation → changement. Cette chaîne transforme la documentation d'architecture d'une paperasse statique en un registre testable des raisons pour lesquelles le système a la forme qu'il a.

FAQ

ADR vs NFR

Un ADR est-il une exigence non fonctionnelle ?

Non. Une NFR énonce une qualité, une contrainte ou une condition d'exploitation requise. Un ADR consigne un choix architecturalement significatif effectué en réponse à des exigences, des contraintes, des risques et des compromis.

Chaque NFR doit-elle avoir un ADR ?

Non. Seules les exigences qui influencent matériellement l'architecture nécessitent des décisions au niveau de l'architecture qui méritent d'être conservées. Une NFR peut aussi motiver plusieurs ADR, et un ADR peut répondre à plusieurs exigences.

« Utiliser PostgreSQL » peut-il être une NFR ?

Uniquement lorsque PostgreSQL est véritablement imposé comme contrainte externe. Sinon, le besoin sous-jacent doit d'abord être exprimé, et le choix de PostgreSQL doit normalement être traité comme une décision d'architecture.

Un ADR prouve-t-il qu'une exigence de performance ou de sécurité est satisfaite ?

Non. Un ADR consigne l'intention et le raisonnement. L'exigence est validée par des preuves appropriées telles que des tests, des mesures, des analyses, des audits ou de la télémétrie opérationnelle.

Que doit contenir un ADR ?

Au minimum, un ADR doit rendre le contexte et la décision clairs. Les structures courantes incluent aussi le statut et les conséquences. Les équipes peuvent ajouter des alternatives, la justification, les compromis, les liens vers les exigences, les preuves, les responsables, les dates et les relations de remplacement.

Qu'est-ce qui rend une NFR architecturalement significative ?

Une exigence est architecturalement significative lorsqu'elle façonne matériellement la structure du système, la technologie, les flux de données, le déploiement, le comportement transversal ou des compromis de qualité difficiles, en particulier lorsque l'échec entraîne un impact métier ou de mission élevé.

Un ancien ADR doit-il être supprimé lorsque l'architecture change ?

Généralement non. Une décision de remplacement doit normalement remplacer l'ancien enregistrement afin que le raisonnement historique reste traçable.

Glossaire

Termes d'architecture fondamentaux

NFR: Exigence non fonctionnelle : abréviation pratique pour une qualité, une contrainte ou une condition d'exploitation requise du système ; la terminologie exacte varie selon la méthode et la norme.
Exigence d'attribut de qualité: Exigence décrivant une propriété de qualité que le système est censé présenter dans des conditions définies, telles que la performance, la disponibilité, la sécurité, la fiabilité ou la modifiabilité.
Architecture Decision Record (ADR): Enregistrement durable d'une décision architecturalement significative et d'un contexte suffisant pour comprendre pourquoi le choix a été fait et quelles conséquences en découlent.
Architecturally Significant Requirement (ASR): Exigence ayant un impact architectural suffisamment étendu pour influencer matériellement la conception du système.
Contrainte: Condition qui restreint l'espace des solutions, y compris les politiques externes, la réglementation, la plateforme, la compatibilité, les limites contractuelles ou organisationnelles.
Compromis: Relation de conception dans laquelle l'amélioration d'un objectif, d'une propriété ou d'une dimension de coût peut en dégrader un autre.
Validation: Travail produisant des preuves utilisé pour déterminer si le système mis en œuvre satisfait l'exigence énoncée dans les conditions pertinentes.
ADR remplacé: Enregistrement de décision historique qui a été remplacé par une décision faisant autorité plus récente tout en restant disponible pour la traçabilité.

Sources primaires et preuves de mise en œuvre

Cet article distingue les normes en vigueur des preuves de mise en œuvre de projet. L'ISO/IEC/IEEE 29148:2018 reste en vigueur au 8 octobre 2026 mais est marquée pour révision ; l'ISO/IEC 25010:2023 et l'ISO/IEC/IEEE 42010:2022 sont les éditions publiées en vigueur. SenseFlow est une preuve de projet originale pour le modèle de traçabilité et d'intégrité décisionnelle décrit ci-dessus.

ISO/IEC/IEEE 29148:2018 — Ingénierie des exigences

Norme d'ingénierie des exigences publiée en vigueur. L'ISO indique que l'édition 2018 a été examinée et confirmée en 2024 et devrait être remplacée par le DIS actuellement en cours d'élaboration.

ISO/IEC/IEEE DIS 29148 — Ingénierie des exigences

Projet de norme internationale actuellement en cours d'élaboration et destiné à remplacer l'ISO/IEC/IEEE 29148:2018.

ISO/IEC 25010:2023 — Modèle de qualité du produit

Modèle de qualité du produit en vigueur avec neuf caractéristiques de qualité utilisées pour spécifier, mesurer et évaluer la qualité des produits TIC et logiciels.

ISO/IEC/IEEE 42010:2022 — Description de l'architecture

Norme de description de l'architecture en vigueur. Elle spécifie les concepts de description de l'architecture et les exigences de conformité sans prescrire un format d'enregistrement, une notation, un processus ou un outil unique.

Michael Nygard — Documenter les décisions d'architecture

Article original influent sur les ADR décrivant des enregistrements légers centrés sur le contexte, la décision, le statut et les conséquences, avec les décisions remplacées conservées pour la compréhension historique.

SEI — Relier les objectifs métier aux exigences architecturalement significatives

Rapport du SEI expliquant comment les exigences d'attributs de qualité et les objectifs métier orientent l'architecture logicielle et pourquoi les exigences architecturalement significatives nécessitent une élicitation explicite.

SEI — Définir les qualités système non fonctionnelles

Aperçu du SEI reliant les attributs non fonctionnels/de qualité à l'architecture, aux scénarios, aux compromis et à l'évaluation objective du système.

SEI — Collection de méthodes Attribute-Driven Design

Méthode de conception d'architecture basée sur les exigences fonctionnelles, les exigences d'attributs de qualité et les contraintes, avec des tactiques et des patrons architecturaux sélectionnés pour satisfaire les scénarios de qualité.

SEI — Collection Views and Beyond

Guide de documentation d'architecture mettant l'accent sur les vues pertinentes et l'enregistrement des décisions de conception nécessaires dans le cadre du travail d'architecture.

Partager sur X Partager sur Xing Partager sur Facebook Partager sur LinkedIn Partager sur Telegram Partager par e-mail