Architecture IT : monolith et microservices

Architecture IT : Des monolithes aux microservices et la pensée systémique

Le passage à l'architecture n'est souvent pas planifié — il surgit avec la croissance d'un projet. Quand une équipe ne peut plus gérer la charge, et que les décisions doivent tenir sur plusieurs années, un développeur évolue naturellement vers le rôle d'architecte. Philippe Delgado, architecte fintech, a commencé dans les années 90 par la maintenance système ; six mois après son premier poste, il avait pris en main l'intégralité du projet. Cela l’a poussé à penser au-delà des demandes immédiates et à se concentrer sur l’évolution à long terme.

L’enseignement supérieur fournit une base pour maîtriser la complexité : les mathématiques enseignent l’abstraction — passer des idées à la mise en œuvre. Bien que les universités ne transmettent pas directement l’architecture, elles cultivent la pensée systémique. Les ouvrages de McConnell, les patterns de conception GoF, ainsi que les travaux de Fowler posent les fondations grâce au refactorisation et à la structure du code.

Des conférences comme Highload++ depuis 2007 combinent théorie et pratique — les échanges avec des développeurs utilisant des piles technologiques différentes révèlent l’écart entre les idéaux et la réalité.

Le rôle de l'architecte dans l'équipe

Un architecte est un rôle de coordination, pas seulement un titre. Dans les années 90, les chefs architectes assuraient l’alignement global. Aujourd’hui, il s’agit davantage de ingénieurs principaux ou staff — responsables du système entier, pas seulement d’un module.

Dans des projets complexes comme le traitement de cartes ou les premières versions de Yandex.Money, les architectes anticipent les scénarios, équilibrant performance et contraintes métier. La fierté vient de voir des systèmes en production résister à des pressions réelles. Les startups enseignent l’adaptabilité, mais beaucoup n’arrivent jamais à livrer.

Défis majeurs :

• Écart entre architecture théorique et besoins concrets.
• S’adapter au changement sans tout reconstruire.
• Équilibrer vitesse et évolutivité.

Les architectes sont confrontés à des tâches répétitives, pas toujours déléguées. La concentration est essentielle : 2 heures pour saisir le contexte, 3 heures pour réfléchir, parfois plusieurs jours pour résoudre.

Monolithe vs Microservices : le contexte dicte le choix

Le choix entre monolithe et microservices dépend du stade du projet et de la dynamique d’équipe. Les monolithes conviennent aux phases initiales, quand une équipe étroite travaille ensemble. Les microservices ont leur place quand les exigences entrent en conflit et qu’un déploiement indépendant est nécessaire. Il n’y a pas de réponse universelle — les choix évoluent avec la complexité.

Les architectes doivent comprendre l’implémentation : un schéma « élégant » échoue sans connaissance de la pile technique. Un architecte solution peut ignorer le code, mais un architecte logiciel doit avoir une expérience pratique des frameworks — pour anticiper les coûts et risques d’implémentation.

Compétences et outils de l'architecte

La pensée systémique s’aiguise par la pratique — voir le système d’en haut et sous plusieurs angles. Profitez de la responsabilité et de l’autonomie : prendre des décisions qui influencent la qualité pendant des années.

Détestez le turnover : moins de code, plus de routine. Changer de projet est difficile — cela dépend fortement de la familiarité avec le domaine.

Compétences clés pour les rôles intermédiaires et seniors :

• Passer entre niveaux d’abstraction.
• Prévoir l’évolution du système.
• Tenir compte des coûts d’implémentation.
• Gérer les exigences contradictoires.
• Se concentrer sur les problèmes complexes.

Les livres sont préférés aux vidéos : le texte permet de revenir en arrière et de construire une logique linéaire. Les vidéos sont excellentes pour les démos de code, mais pas pour une compréhension profonde.

Lecture recommandée pour penser comme un architecte

Pour développer une vision architecturale :

• Harry Potter et les méthodes de la rationalité (Yudkowsky) — rationalité et probabilités.
• Les ouvrages TRIZ, par exemple Un mois sous les étoiles de la fantasy.
• Le paradoxe de Prométhée (Mesterházi) — analyse critique.
• Les œuvres de Lotman sur la sémiotique.
• Sun Tzu avec les commentaires de Conrad.

Ces textes entraînent la pensée analytique, libérée des contraintes technologiques.

Ce qui compte vraiment

• L’architecture, c’est gérer la complexité, pas dessiner des diagrammes.
• Le passage du codage à l’architecture survient avec une responsabilité accrue.
• Une expérience de pile technique est obligatoire pour l’architecture logicielle.
• La pensée systémique s’améliore par la pratique et la lecture.
• Monolithe ou microservices ? Choisissez selon le contexte du projet.

— Editorial Team