Le Piège des Patterns

Soyons honnêtes : si tu bosses dans le développement depuis quelques années, tu as forcément vécu ça. Tu es dans une review d'architecture et quelqu'un sort un catalogue de patterns comme un serveur qui te présente la carte. « On pourrait utiliser une Factory ici. Un Strategy là. Tu connais CQRS ? »

Non. C'est pas de l'architecture ça. C'est du pattern-matching déguisé en ingénierie.

Il y a une réflexion qui circule beaucoup dans les communautés de devs et qui décrit bien le problème : une bonne architecture logicielle émerge de la modélisation du problème lui-même, pas de l'inverse. Les meilleurs développeurs apprennent à utiliser leurs outils, à comprendre leurs matériaux, puis à suivre leur vision. Pas à attraper des emporte-pièces qui cachent la solution évidente juste devant eux.

Pourquoi il y a des ressources partout pour le web, mais presque rien pour la prog' systèmes ?

Tu veux apprendre les microservices, l'orchestration de conteneurs, les systèmes distribués dans un contexte web ? Bravo, tu es submergé. Des tonnes de ressources, des podcasts, des cours, des conférences.

Mais si tu construis un compilateur, un système embarqué, un moteur de jeu, ou une base de données ?

Là, le décor change complètement.

La plupart du contenu « software architecture » d'aujourd'hui se concentre sur les problématiques du web à grande échelle : scaling horizontal, discovery de services, cohérenceEventually, et les défis organisationnels des grandes équipes. Des vrais problèmes, certes. Mais pas des problèmes universels.

Pour les programmeurs systèmes et les devs hors web, le vocabulaire change. On pense à :

• La disposition mémoire et les patterns d'accès
• Les garanties de latence et les contraintes temps réel
• Les environnements contraints en ressources
• La vérification formelle quand la correction est critique
• Construire pour des décennies de maintenance, pas juste le prochain sprint

Le problème, c'est que les bonnes ressources pour ce monde sont dispersées, souvent académiques, et rarement présentées comme de « l'architecture » — alors qu'elles en sont.

Ce qui aide vraiment : les modèles mentaux, pas les patterns

Plutôt qu'un nouveau catalogue de patterns, voici les cadres mentaux qui ont fait leurs preuves pour construire des systèmes robustes, que tu codes en C embarqué ou en Java enterprise :

1. Les contraintes d'abord

Chaque système existe dans un cadre de contraintes : budget, délais, taille de l'équipe, besoins de perf, environnement réglementaire. L'architecture qui émerge d'une compréhension profonde de tes contraintes battra toujours l'architecture « correcte » qui les ignore.

2. Le flux de données comme fondation

Avant de penser aux classes, modules ou services, comprends comment les données entrent dans ton système, se transforment, et sortent. L'architecture devient souvent évidente une fois ça cartographié. Les abstractions tordues disparaissent ; celles qui sont nécessaires deviennent claires.

3. La propriété des dépendances

Qui possède cette donnée ? Qui peut modifier cet état ? Des réponses claires à ces questions évitent la plupart des catastrophes architecturales. La confusion autour de la propriété — surtout la propriété des données — c'est là où la plupart des systèmes commencent à pourrir.

4. Le coût de l'indirection

Chaque abstraction a un prix. Chaque couche d'indirection rend le debugging plus difficile et les performances plus dures à comprendre. La question c'est pas « dois-je abstraire ça ? » mais « qu'est-ce que j'achète avec cette abstraction, et est-ce que ça vaut le prix ? »

5. La locality du comportement

Du code facile à comprendre isolément, qui te demande pas de garder trois fichiers en tête en même temps, c'est du code qui survivra aux cinq prochaines années de maintenance. Une architecture qui crée de la charge cognitive sera simplifiée tôt ou tard — souvent par quelqu'un qui comprend pas pourquoi c'était construit comme ça.

Ressources recommandées (le genre non-web)

Si tu veux approfondir ta réflexion architecturale sans tomber dans le terrier du pattern web-scale, considère :

• « A Philosophy of Software Design » de John Ousterhout — C'est toujours un des textes les plus clairs sur la gestion de la complexité dans les systèmes logiciels. Indépendant du langage et profondément pragmatique.

• Les articles académiques sur les systèmes d'exploitation et les systèmes distribués — surtout ceux d'avant l'ère microservices. Un papier sur la conception de systèmes de fichiers contient une sagesse architecturale applicable bien au-delà des systèmes de fichiers.

• Lire le code source de systèmes bien conçus — Ça a l'air évident, mais la plupart des développeurs le font pas systématiquement. Comprendre comment les bases de données, les compilateurs et les projets open source bien engineerés résolvent leurs problèmes te teach plus que n'importe quel livre de patterns.

L'art derrière la science

Voici la vérité inconfortable : l'architecture logicielle, c'est plus de l'art que de la science, et ça va pas changer.

On peut parler de principes et d'heuristiques. Mesurer le couplage et la cohésion. Créer des modèles et des diagrammes. Mais en bout de ligne, l'architecture reflète le jugement des gens qui construisent le système — leur capacité à voir clairement le problème, leur expérience de ce qui foire habituellement, leur skill à faire des compromis qui servent les besoins réels plutôt que les idéaux théoriques.

Les devs qui construisent les meilleurs systèmes partagent un trait commun : ils sont profondément curieux du domaine du problème, pas juste de la technologie. Ils demandent « pourquoi c'est difficile ? » avant de demander « quel pattern je devrais utiliser ? »

Commence par là. Comprends profondément ton problème. Laisse la solution émerger. Et quand quelqu'un essaie de te vendre un pattern comme de l'architecture, demande-lui quel problème ça résout — et si ce problème existe vraiment dans ton système.