Penser comme un architecte logiciel au quotidien

Penser comme un architecte logiciel (software architect) ne veut pas dire dessiner plus de diagrammes ou parler plus haut niveau. Cela veut dire prendre de meilleures décisions sous contraintes.

Un architecte utile n'est pas celui qui produit le plus de concepts. C'est celui qui clarifie les compromis, rend les risques visibles et aide l'équipe à construire un système cohérent dans le temps.

Un architecte pense en contraintes

Les développeurs se concentrent souvent sur la justesse locale d'une implémentation. L'architecte ajoute une autre perspective :

quel est le coût de cette décision à six mois ?
que se passe-t-il si le trafic double ?
comment équipe et produit évoluent-ils autour de ce choix ?
quelle dette accepte-t-on consciemment ?

Penser comme un architecte, c'est regarder plus large sans perdre le contact avec le code.

Un architecte ne cherche pas la solution parfaite

Il n'existe presque jamais de solution parfaite. Il existe des arbitrages.

Par exemple :

simplicité aujourd'hui vs flexibilité demain
couplage plus fort vs meilleure performance
duplication locale vs abstraction prématurée
monolithe modulaire vs système distribué

Le travail de l'architecte consiste à choisir le compromis le plus défendable pour le contexte réel.

Le contexte avant les patterns

Les patterns sont utiles, mais seulement si le problème est bien compris. Beaucoup de mauvaises architectures viennent d'une application mécanique de solutions apprises ailleurs.

Avant de choisir un pattern, il faut clarifier :

les objectifs du système
les flux critiques
les contraintes de latence
les enjeux de sécurité
les compétences de l'équipe
le rythme de changement attendu

Le même pattern peut être excellent dans un contexte et catastrophique dans un autre.

Un architecte pense en frontières

L'une des compétences centrales est de savoir où poser les frontières :

entre modules
entre domaines métier
entre responsabilités techniques
entre code applicatif et détails d'infrastructure

Des frontières claires réduisent le couplage, clarifient qui est responsable de quoi et limitent l'effet de bord des évolutions. En .NET, ces frontières prennent souvent la forme d'un monolithe modulaire avant d'éventuels services séparés.

Un architecte sait identifier le bon niveau d'abstraction

Trop peu d'abstraction produit de la duplication et du chaos. Trop d'abstraction produit de l'opacité et des couches inutiles.

La bonne abstraction apparaît quand plusieurs cas réels partagent une intention stable, pas quand on anticipe un futur hypothétique.

C'est pour cela qu'un architecte solide aime les abstractions tardives et les preuves concrètes.

Un architecte pense aussi en opérabilité

Une décision d'architecture n'est pas terminée quand le code compile. Elle doit aussi être exploitable.

Il faut donc se demander :

comment observer le système ?
comment comprendre un incident ?
comment déployer sans risque excessif ?
comment mesurer la qualité du comportement ?

Un design élégant mais inexploitable est un mauvais design.

Savoir dire non à la complexité

L'une des vraies marques de maturité architecturale est la capacité à dire non :

non à une décomposition prématurée (voir pourquoi les architectures microservices échouent)
non à une abstraction non justifiée
non à une technologie adoptée sans besoin clair
non à un niveau de complexité que l'équipe ne peut pas porter

Penser comme un architecte, c'est protéger la simplicité quand elle est encore possible.

Les questions que pose un architecte

Face à une décision importante, un architecte utile pose souvent ce type de questions :

quel problème exact résolvons-nous ?
quelle hypothèse rend cette décision raisonnable ?
que se passe-t-il si cette hypothèse devient fausse ?
quel sera le coût de retour arrière ?
qui exploitera cette décision au quotidien ?
comment la tester et l'observer ?

Ces questions paraissent simples. Elles évitent pourtant un grand nombre d'erreurs de conception.

Documenter une décision : l'ADR

Les réponses à ces questions se perdent vite si elles restent orales. Un Architecture Decision Record (ADR) est un court fichier Markdown, versionné avec le code, qui fige une décision et son contexte. Il ne décrit pas tout le système : il explique pourquoi une option a été retenue à une date donnée.

# ADR 0007 : publier les événements de commande via une table Outbox

- Statut : acceptée
- Date : 2026-10-14
- Décideurs : équipe Commandes, référent architecture

## Contexte
Les commandes sont enregistrées dans PostgreSQL puis publiées sur RabbitMQ.
Une panne entre les deux écritures a déjà produit des commandes sans événement.

## Décision
Écrire l'événement dans une table Outbox dans la même transaction que la commande,
puis le publier par un relais asynchrone.

## Options écartées
- Transaction distribuée : non supportée par le broker, couplage fort.
- Publication directe après commit : perte possible en cas de crash.

## Conséquences
- Les consommateurs doivent être idempotents (livraison au moins une fois).
- Un relais de plus à superviser ; délai de publication de quelques secondes.
- À revoir si le volume dépasse 2 000 commandes par seconde.

La section « Conséquences » est la plus importante : elle rend visibles les coûts acceptés et la condition qui justifierait de revenir sur la décision. Un ADR n'est jamais modifié après acceptation ; une nouvelle décision le remplace et y fait référence. L'exemple ci-dessus correspond au pattern détaillé dans Inbox et Outbox en .NET.

Le rapport au code

Un bon architecte ne se coupe pas du code. Même s'il n'écrit pas tous les endpoints ou toutes les classes, il reste assez proche pour juger :

si les abstractions sont réelles ou artificielles
si la structure de code porte bien les intentions
si les conventions sont tenables
si la dette s'accumule dangereusement

Une architecture qui n'existe que dans des diapositives n'existe pas vraiment. Les règles de dépendance peuvent d'ailleurs être vérifiées par des tests, comme dans la Clean Architecture en .NET sans dogmatisme.

Penser en système, pas seulement en application

Penser comme un architecte, c'est aussi comprendre l'écosystème autour du code :

l'organisation des équipes
les flux de release
les contraintes de sécurité
les dépendances externes
les données et leur cycle de vie

Le système logiciel n'est jamais isolé. Les décisions d'architecture doivent donc tenir compte de ce contexte élargi.

Conclusion

Penser comme un architecte logiciel, c'est apprendre à raisonner en compromis, en frontières et en conséquences. C'est une posture de clarté plus qu'une posture de prestige. Pour s'exercer sur du code réel, les dépôts GitHub de référence en architecture .NET montrent ces compromis appliqués.

Le meilleur architecte n'est pas celui qui complique la discussion. C'est celui qui rend les décisions plus nettes, plus explicites et plus durables.