3.0 Introduction à la partie 3 : les systèmes
L’architecture est l’ensemble des décisions coûteuses à inverser. Comment divisez-vous un système en parties ? Comment ces parties se parlent-elles entre elles ? Comment les données sont-elles modélisées ? Et comment le tout se comporte-t-il sous charge et sous panne ? La partie 3 porte sur le fait de prendre ces décisions délibérément. Dans une petite équipe, l’architecture peut vivre dans quelques têtes et évoluer au fil de l’eau. Dans une grande organisation (des centaines d’ingénieurs, des dizaines d’équipes, des systèmes qui survivront aux carrières des personnes qui les construisent), l’architecture devient ce qui garde tout le monde coordonné. Quand elle est claire, les équipes avancent indépendamment sans se heurter. Quand elle est vague, chaque dépendance inter-équipes se transforme en négociation, et chaque incident en projet d’archéologie.
Les enjeux sont les plus élevés dans l’entreprise et l’administration publique. Un moteur fiscal, une plateforme de prestations, un dossier de santé national, ou le grand livre central d’une banque est de longue durée, fortement réglementé, partagé entre départements, et redevable devant le public. Les décisions que vous prenez aujourd’hui sur le couplage, la propriété des données, et les attributs de qualité contraindront ce qui est possible pendant une décennie ou plus. Les régulateurs et les auditeurs attendent de plus en plus une architecture documentée et défendable, avec une preuve réelle que la fiabilité, la sécurité, la confidentialité, et la durabilité ont été conçues dès le départ, pas ajoutées après coup. Les échecs qui font la une sont des échecs architecturaux : des portails qui plient le jour du lancement, des systèmes de dépôt qui expirent à l’échéance, des migrations qui perdent ou comptent en double des enregistrements.
Cette partie commence par les fondamentaux durables, traverse des choix structurels concrets, puis entre dans les réalités de la distribution, des données, et de l’échelle, et finit par le problème le plus difficile que la plupart des grandes organisations affrontent réellement : moderniser les systèmes qu’elles exploitent déjà. Le fil qui relie le tout : une bonne architecture est une série de compromis conscients, pas une valeur par défaut à la mode.
Chapitres de cette partie
3.1 Fondamentaux de l’architecture. Les outils durables qui survivent aux modes technologiques : les attributs de qualité (les « -ilités »), les exigences architecturalement significatives, les fonctions d’aptitude (des tests automatisés qui gardent une qualité architecturale choisie) et l’architecture évolutive, la documentation légère avec le modèle C4 (des diagrammes d’architecture imbriqués à quatre niveaux de zoom) et arc42 (un gabarit de documentation d’architecture), et l’analyse structurée de compromis.
3.2 Styles et motifs architecturaux. Un tour d’horizon des principales formes de système, du monolithe aux microservices, les architectures pilotées par les événements avec CQRS (Command Query Responsibility Segregation, qui sépare les modèles de lecture des modèles d’écriture) et le sourcing d’événements (stocker l’état comme un journal d’événements en ajout seul), le maillage de services (une couche d’infrastructure dédiée pour la communication de service à service) et les passerelles, le sans serveur, et l’architecture hexagonale et propre, avec des indications sur quand chacun convient, encadré par la loi de Conway (les systèmes tendent à refléter la structure de communication de l’organisation qui les construit).
3.3 Systèmes distribués. Les vérités dures qui apparaissent au moment où vous traversez une frontière réseau (réseaux non fiables, panne partielle, aucune horloge partagée), et les défenses standard : le raisonnement de cohérence, l’idempotence (rendre une opération sûre à répéter), les nouvelles tentatives avec recul, les disjoncteurs (qui arrêtent d’appeler une dépendance défaillante), les sagas (des séquences de transactions locales avec des étapes d’annulation compensatoires), et l’observabilité distribuée.
3.4 Architecture et stockage des données. Comment les données sont modélisées, stockées, gardées cohérentes, et servies rapidement à l’échelle : les principaux paradigmes de stockage et quand utiliser chacun, la persistance polyglotte (utiliser plusieurs magasins de données spécialisés dans un seul système), l’évolution et la migration de schéma, la mise en cache et les CDN (réseaux de diffusion de contenu), et les transactions et la concurrence sous charge.
3.5 Évolutivité, performance, et résilience. Trois qualités distinctes conçues dès le départ plutôt que rétro-adaptées : la montée en charge horizontale et verticale, l’absence d’état et le sharding (diviser les données à travers les machines par une clé), l’équilibrage de charge et la mise à l’échelle automatique, les budgets de performance, les motifs de résilience et l’ingénierie du chaos, et la reprise après sinistre multi-région encadrée par le RTO (objectif de temps de reprise) et le RPO (objectif de point de reprise).
3.6 Modernisation des systèmes hérités. Les motifs incrémentaux qui fonctionnent réellement, le figuier étrangleur (faire grandir un nouveau système autour de l’ancien jusqu’à ce que l’ancien puisse être retiré) et la branche par abstraction (remplacer un composant derrière une interface sur la ligne principale de développement), plus l’évaluation du risque hérité, la gestion des mainframes et du COBOL (Common Business-Oriented Language), la migration de données et l’exploitation en parallèle, et comment résister à la tentation de la grande réécriture qui produit les échecs les plus coûteux du domaine.
3.7 Maintenance logicielle. La phase dominante de la vie du logiciel : maintenance corrective, adaptative, perfective, et préventive, la compréhension de programme et la réingénierie, et la conception pour la maintenabilité afin que les systèmes de longue durée restent abordables à changer.
3.8 Interopérabilité et normes ouvertes. Concevoir des systèmes pour interopérer à travers des normes ouvertes plutôt que des intégrations sur mesure : interopérabilité technique, syntaxique, et sémantique, les normes de domaine telles que FHIR en santé, et le coût de l’enfermement propriétaire.
3.9 Ingénierie des systèmes. Concevoir des systèmes complexes de bout en bout, combinant souvent logiciel, matériel, personnes, et processus : cycle de vie, allocation et traçabilité des exigences, interfaces, intégration, et vérification et validation.
3.10 Systèmes embarqués et temps réel. Le logiciel pour des dispositifs sous contraintes serrées : comportement en temps réel et déterminisme, un RTOS ou un micrologiciel bare-metal, une mémoire et une puissance limitées, l’interaction matérielle, et les normes critiques pour la sécurité.
3.11 Architecture cloud. Concevoir pour le cloud plutôt que de transposer un centre de données : modèles de service et sans serveur, régions et zones de disponibilité comme domaines de panne, le modèle de responsabilité partagée, les compromis de service géré et d’enfermement, le multi-cloud et l’hybride quand ils méritent leur complexité, et une conception consciente des coûts et bien architecturée.
3.12 Architecture pilotée par les événements et messagerie. Construire des systèmes qui communiquent en produisant et en réagissant à des événements : files contre flux durables, chorégraphie contre orchestration, sourcing d’événements et CQRS là où ils méritent leur place, sagas pour les transactions distribuées, garanties de livraison et idempotence, et les motifs qui gardent les flux asynchrones fiables.
3.13 Réseaux et connectivité. Le réseau auquel un ingénieur d’application fait réellement face : DNS, TCP et l’évolution de HTTP, la terminaison TLS, l’équilibrage de charge et les proxys inverses, la diffusion de contenu et la périphérie, la découverte de service et le maillage de services, et les délais d’expiration, nouvelles tentatives, et disjoncteurs qui rendent la non-fiabilité du réseau supportable.
3.14 Multi-locataire et architecture SaaS. Servir de nombreux clients depuis une instance logicielle unique sans les laisser se voir ou s’affamer mutuellement : le spectre isolation-contre-efficacité, le partitionnement des données, les quotas par locataire contre les voisins bruyants, le cycle de vie des locataires, et l’attribution des coûts.
3.15 Mise en cache et diffusion de contenu. Échanger un peu de péremption contre de grands gains de latence, charge, et coût à travers la hiérarchie de cache (client, périphérie et CDN, proxy inverse, application, et magasin de données), tout en traitant l’invalidation de cache et la protection contre les ruées comme une conception de premier ordre.
3.16 Passerelles API et maillage de services. Gérer le trafic nord-sud à une passerelle API (routage, authentification, limitation de débit, composition) et le trafic est-ouest à travers un maillage de services (TLS mutuel, déplacement de trafic, nouvelles tentatives, observabilité), et décider quand un maillage mérite sa complexité.
3.17 Recherche et recherche d’information. Traiter la recherche comme un système de premier ordre, de l’index inversé et du classement par pertinence à la compréhension de requête, au facettage, et à la récupération vectorielle et hybride, avec une vraie évaluation de pertinence plutôt que de la devinette.
Comment ces chapitres s’articulent
Les chapitres s’appuient les uns sur les autres dans l’ordre. Le chapitre 3.1 vous donne le vocabulaire (attributs de qualité et analyse de compromis) que chaque chapitre ultérieur utilise ; les « -ilités » qu’il nomme sont exactement ce que les chapitres 3.4 et 3.5 rendent concret. Le chapitre 3.2 transforme ces fondamentaux en choix structurels, et les styles plus distribués qu’il approuve (microservices, piloté par les événements, maillage de services) apportent les coûts que le chapitre 3.3 vous apprend à gérer. Les chapitres 3.3, 3.4, et 3.5 s’appuient fortement les uns sur les autres : la distribution force les décisions de cohérence et de durabilité de l’architecture des données, et ensemble la distribution et les données façonnent l’évolutivité et la résilience que vous pouvez réellement atteindre. Le chapitre 3.6 referme la boucle, parce que la plupart des grandes organisations ne construisent pas sur une page blanche : elles font évoluer des systèmes de référence qui contraignent chaque choix que les chapitres précédents décrivent.
La partie 3 s’étend aussi vers l’extérieur. Le chapitre 3.2 s’appuie sur les principes de conception et la conception pilotée par le domaine du chapitre 2.2 pour trouver de bonnes frontières de service. Les disciplines opérationnelles qui gardent ces systèmes en fonctionnement vivent dans la partie 9 : l’ingénierie de fiabilité des sites (chapitre 9.1) et l’observabilité (chapitre 9.2) sont où la résilience architecturale est prouvée en production. Les propriétés de sécurité et de confidentialité que les régulateurs exigent sont conçues ici mais détaillées dans la partie 4, et les pratiques de plateforme et de livraison de la partie 8 décident si une architecture peut réellement être livrée et exploitée par de nombreuses équipes à la fois.