Les mauvaises décisions coûtent cher plus tard.

Traduire les objectifs de qualité en une architecture vérifiable

« Rapide », « sûr » et « évolutif » ne suffisent pas à formuler une exigence. Pour une recherche, nous avons par exemple besoin du volume de données attendu, du nombre d'utilisateurs simultanés et d'un temps de réponse acceptable. Pour la validation d'une commande, les autorisations, la journalisation et le comportement en cas de panne doivent en outre être définis. Nous décrivons ces scénarios de qualité avec un déclencheur, un état d'exploitation et la réaction souhaitée. Ils permettent d'en déduire les décisions techniques et les tests ultérieurs.

Les objectifs peuvent s'opposer : un contrôle approfondi de chaque requête augmente la charge de traitement ; une vue des données particulièrement à jour peut créer un couplage supplémentaire. Nous mettons ces conflits d'objectifs en évidence et les priorisons avec les responsables. L'architecture ne contient donc pas seulement des composants, mais aussi des hypothèses, des limites et des preuves. Un prototype de charge ne répond pas à la même question qu'une maquette cliquable. Chacun reçoit un objectif de vérification concret et une date de fin.

Limites du système, maîtrise des données et responsabilités

Lorsqu'une commande, une facture et une fiche client apparaissent dans plusieurs applications, il doit être clair qui peut modifier quelle information. Nous délimitons les domaines de responsabilité métier et distinguons les notions propres à chacun. « Client » peut désigner des données et des règles différentes pour les ventes, la comptabilité et le support. Un modèle de base de données commun à tous les domaines simplifie certes la mise en œuvre au départ, mais peut rendre les modifications ultérieures fortement interdépendantes.

Nous examinons les limites entre modules, les dépendances et les transferts entre équipes. Un déploiement séparé ne se justifie que lorsque l'indépendance obtenue compense l'effort supplémentaire lié aux interfaces, à la surveillance et à la gestion des erreurs. Le choix entre une application modulaire et des services distribués dépend donc aussi de la taille de l'équipe, de la responsabilité des mises en production et de la capacité d'exploitation. La matrice des responsabilités, le contexte système et les décisions d'architecture documentées précisent qui peut modifier une limite et quelles autres équipes doivent être impliquées.

Investissement, dette technique et feuille de route viable

Un concept d'architecture doit pouvoir être financé et intégré dans l'exploitation courante. Nous examinons ensemble l'effort de développement, les licences, la reprise des données, l'infrastructure et la maintenance à long terme. La dette technique existante est évaluée en fonction des modifications qu'elle entrave ou des pannes qu'elle favorise. Un composant dépassé ne doit pas forcément être remplacé immédiatement ; un petit composant stable peut être moins risqué que son remplacement mal préparé.

La feuille de route relie les étapes métier aux conditions techniques préalables. Avant un nouveau portail partenaire, il peut par exemple falloir clarifier d'abord la gestion des droits. Chaque étape comporte un résultat, des points de décision et des dépendances identifiées. Pour les coûts, nous utilisons des hypothèses explicites et des fourchettes tant que des inconnues importantes subsistent. Vous pouvez ainsi comparer les offres et décider si une analyse supplémentaire est plus judicieuse qu'un lancement précipité de la mise en œuvre.