Dans le cadre de la 13ème édition de Devoxx France, qui s’est tenue du 16 au 18 avril 2025 au Palais des Congrès de Paris, Cyril Martraire et Christian Sperandio ont animé une présentation attirante intitulée: Les clés de l’architecture pour les devs. La présentation a eu le but de mettre l’humain au cœur de l’architecture, tout en proposant aux devs des outils pratiques pour aborder l’architecture d’une manière pragmatique, évolutive et surtout humaine.

Première clé : Accepter de vivre dans l’incertitude

Certes la première grande idée des deux speakers semble simple, mais elle est libératrice:

“En architecture, personne ne sait tout, ni les architectes, ni les devs, ni même les clients.

Au lieu de chercher à tout contrôler au départ, il faut apprendre à vivre avec le doute, et surtout être capable de prendre des décisions malgré l’incertitude .

Voilà une posture à adopter : savoir se mouvoir entre ce qu’on sait (le connu), ce qui nous reste à apprendre (l’inconnu), et ce qu’il nous est possible d’apprendre (le possible).

“Problème bien posé = moitié de la solution trouvée.”

Les orateurs ont illustré par un exemple concret issu de leur pratique: la création d’un agrégateur de données issues de capteurs dans des antennes télécoms.

Le besoin exprimé était simple:

Recevoir toutes les minutes des fichiers et les agréger toutes les 15 minutes pour alimenter un système de monitoring qui permet de détecter des pannes avant qu’elles ne surviennent.

Mais derrière cette apparente simplicité va émerger une véritable complexité architecturale..

Mesurer les qualités d’architecture

Pour chaque problème, aussi trivial soit-il, on doit considérer bien plus que la seule logique métier . C’est là où interviennent les qualités non fonctionnelles, aussi appelées Quality Attributes, qui représentent des critères souvent sous-estimés mais pourtant déterminants dans la conception architecturale.

Ci-dessous un tableau qui illustre les possibles questions que nous pouvons poser afin de construire l’architecture de notre exemple.

Ces attributs de qualité peuvent servir à négocier avec le client en confrontant leur idéal à la réalité technique et économique. Cela permet de transformer un besoin exprimé d’une manière abstraite et vague en une solution équilibrée et réaliste (c’est souvent en parlant d’argent ou effort requis qu’on redescend vite sur terre.. pas pour limiter l’ambition, mais pour la rendre durable)

Penser modulaire, même dans un monolithe

Une des parties centrales que la session a traité est la modularité, avec une approche originale : commencer avec un monolithe modulaire au lieu de partir directement vers une architecture distribuée.

“Parfois, un seul service est bien suffisant. Moins de coordination, moins de complexité.”

Mais il ne s’agit pas d’un monolithe classique : c’est un ‘’modular monolith’’, organisé autour de modules bien séparés, avec de véritables connecteurs, cela permet d’avoir une grande souplesse tout en limitant la dette technique dès le départ.

Préparer des options peu coûteuses

L’avenir est incertain donc l’architecture consiste à préparer des options facilement modifiables sans prévoir tous les cas possibles.

Exemple : faire une interface simple pour communiquer entre deux modules permettra de remplacer plus tard facilement un appel local par un appel HTTP, sans avoir à tout restructurer.

“Pas besoin de trop prévoir. Juste quelques points d’entrée souples.”

Itérer, tester, apprendre vite

Pour reprendre notre cas pratique, imaginons maintenant qu'après avoir déployé une première version, l’équipe découvre que le traitement prend trop de temps (plus que le temps demandé par le client), dans ce cas, c’est inutile d’attendre pour savoir  combien de temps le traitement nécessite.

Ceci est loin d’être un échec mais plutôt est une victoire: ils ont découvert très vite qu’une évolution était nécessaire, sans avoir investi trop de ressources.

Documenter les décisions architecturales (ADR)

Chaque décision prise doit être documentée via des Architectural Decision

Records (ADR), pour garder une trace claire sur le problème rencontré, les options envisagées, la solution choisie et les raisons du choix.

“Si vous ne savez pas justifier votre ADR, vous avez honte. C’est de la bonne honte.”

L’architecture, c’est avant tout une posture

Ce qui est marquant dans cette session, c’est à quel point l’architecture est humaine. Ce n’est pas juste un diagramme UML ou un schéma technique, c’est une manière de penser, de communiquer, de collaborer et de faire des compromis.

“L’architecture, c’est autant du code que des personnes. Et parfois, c’est même plus de personnes.”

Conclusion

Les clés de l’architecture pour les devs est une session qui sort du cadre technique traditionnel pour replacer l’humain au centre de l’architecture. Elle propose une approche pragmatique, itérative et résolument moderne de la conception architecturale.  Au-delà des diagrammes et des technologies, elle met en avant l’importance de savoir vivre avec l’incertitude, de poser les problèmes avant les solutions, de mesurer les qualités d’architecture, de penser modulaire même dans un monolithe, de préparer des options peu coûteuses, de tester et apprendre vite, et surtout, de documenter ses décisions.

Finalement, comme le rappellent les speakers: l’architecture, c’est autant du code que des personnes et parfois, c’est même plus des personnes.