On ne commence pas un chantier par les murs
Un terrain, un maître d'ouvrage pressé, une équipe de maçons libre dès lundi. Tu peux faire livrer les parpaings le premier matin. Les murs vont monter, vite, et tout le monde sera content pendant six semaines.
Puis le géotechnicien passe. Le sol ne reprend pas les charges prévues à l'angle nord, l'accès livraison est trop étroit pour un semi-remorque, et le local technique se retrouve derrière un mur porteur. Aucune de ces trois choses ne se corrige à la truelle. On démolit.
Le logiciel se comporte pareil, à ceci près que son béton est invisible. Un projet qui démarre par du code démarre par des murs. Six mois plus tard, la reprise s'appelle refonte, et elle coûte le prix du bâtiment entier.
Cette série suit trois mouvements, dans cet ordre : lire le terrain, dresser les plans, conduire le chantier. C'est l'ordre dans lequel on s'occuperait vraiment d'un bâtiment, et c'est celui dans lequel un système se conçoit.
Cette page est le plan de lecture. Elle n'enseigne aucune notion en détail : elle montre le chemin, les trois paliers, les huit domaines et l'ordre des treize billets. Garde-la dans un onglet, tu y reviendras entre deux étapes.
Chaque billet ouvre sur Le Chantier, le bâtiment commun à toute la série, puis transpose la notion côté informatique et s'appuie sur un cas réel documenté. Une métaphore ne prouve rien, elle aide seulement à comprendre.
Ce que fait vraiment un architecte logiciel
Un développeur sait ce qui peut être construit. Un architecte décide de ce qui devrait l'être. La différence tient dans un petit ensemble de décisions : quels composants existent, quelle est leur responsabilité, comment ils se parlent, où vivent les données, sur quelle pile technique tout cela repose. Ces décisions ont une propriété commune, elles sont douloureuses à défaire une fois le projet lancé.
L'autre moitié du métier ne se passe pas devant un écran. Elle consiste à interroger le client jusqu'à transformer « il faut que ce soit rapide » en un chiffre défendable, à expliquer un arbitrage à une direction qui ne lira que le résumé, et à obtenir l'accord d'équipes sur lesquelles l'architecte n'a aucune autorité hiérarchique. Le document d'architecture est le livrable visible ; le travail réel se fait avant, dans les questions posées pendant que personne n'a encore ouvert un éditeur.
Un architecte ne se juge pas au nombre de schémas qu'il produit, mais au nombre de décisions coûteuses qu'il a rendues explicites avant qu'on coule le béton.
Le fil rouge : Le Chantier
Un même bâtiment sert de décor à toute la série. Un terrain, une étude de sol, un permis, des fondations, un gros œuvre, des lots confiés à des entreprises différentes, une remise des clés. Le choix n'est pas décoratif : le chantier rend visibles des contraintes que le logiciel dissimule. Personne ne discute le fait qu'une dalle coulée ne se déplace pas.
Voici la table de correspondance, en version courte. Chaque billet en reprend une ou deux lignes, celles qui le concernent.
| Le Chantier | Architecture logicielle |
|---|---|
| Le maître d'ouvrage, celui qui commande et qui paie | Le client, la direction |
| Le maître d'œuvre, l'architecte | L'architecte logiciel |
| Le programme, ce que le bâtiment doit permettre de faire | Les exigences fonctionnelles |
| L'étude de sol, les charges admissibles, la fréquentation attendue | Les exigences non-fonctionnelles |
| Les normes de construction : incendie, sismique, accessibilité | Les qualités de service (*-ilities) |
| Le type d'ouvrage : immeuble, entrepôt, pont | Le type d'application |
| Le choix des matériaux : béton, acier, bois, préfabriqué | La stack technique |
| Le terrain et les fondations | Le magasin de données |
| Le gros œuvre : murs porteurs, planchers, trémies | Les couches et les composants |
| Les lots séparés confiés à des entreprises différentes | Les microservices |
| Le local technique et la gestion technique du bâtiment | La journalisation et la supervision centralisée |
| Le permis de construire, puis le dossier des ouvrages exécutés | Le document d'architecture |
Le logiciel garde un avantage que le bâtiment n'a pas : il se modifie après la livraison. Le piège consiste à croire que tout s'y modifie au même prix. Le magasin de données, le découpage en services et la pile technique se comportent comme du béton.
La métaphore ouvre chaque section, elle ne la remplit pas. Dès que la transposition devient acrobatique, on repasse à l'informatique.
Le parcours en un schéma
Les huit domaines de la série, regroupés en trois paliers, dans l'ordre de lecture. On avance de gauche à droite et on ne passe au palier suivant qu'une fois le précédent digéré.
Les paliers ne classent pas les sujets par difficulté, mais par dépendance. Choisir une base de données suppose de connaître la volumétrie. Chiffrer la volumétrie suppose d'avoir interrogé le métier. Chaque étape rend la suivante possible.
Sauter le palier 1 revient à choisir une technologie pour un besoin qu'on n'a pas encore écrit. C'est la façon la plus courante de se tromper très tôt, et de le découvrir très tard.
Palier 1 : Lire le terrain
Avant le premier trait de crayon, l'architecte se rend sur place. Il commande une étude de sol, relève les règles d'urbanisme, mesure l'accès des camions, et surtout il écoute le maître d'ouvrage assez longtemps pour comprendre ce qu'il compte faire du bâtiment. Un entrepôt logistique et une clinique tiennent parfois sur le même terrain, ce ne sont pas les mêmes plans.
Ce palier ne contient aucune technologie. Il pose le rôle, la méthode et le vocabulaire que tous les billets suivants réutilisent. Deux domaines, page du palier : Lire le terrain.
Business
Qui commande, qui paie, qui décide, et quelle est la place exacte de l'architecte au milieu. Ce domaine traite du rôle lui-même : ce qui sépare un architecte d'un développeur expérimenté, pourquoi comprendre le métier du client passe avant la technique, et comment emporter l'adhésion de gens sur qui on n'a aucun pouvoir hiérarchique.
On y apprend aussi à distinguer un objectif métier (« vendre plus ») d'une exigence (« afficher le catalogue en moins d'une seconde pour dix mille visiteurs simultanés »). Un client formule presque toujours le premier en croyant énoncer la seconde.
Lis dans cet ordre :
- Cette page, le plan de lecture de la série.
- Le métier d'architecte : rôle, mindset et influence sans autorité
Page du domaine : Business.
Process
La méthode de travail, de la première réunion au support de l'équipe pendant la réalisation. Six étapes, dont une que presque personne ne traite sérieusement : les exigences non-fonctionnelles. Elles ne sont jamais demandées spontanément, et elles décident pourtant du magasin de données, du découpage en composants et de la facture d'hébergement.
Le premier billet chiffre les cinq grandeurs qui comptent : performance, charge, volumétrie, utilisateurs simultanés, SLA. Le second fait le pont entre ces chiffres et les capacités techniques qu'ils imposent, les fameuses qualités de service.
Lis dans cet ordre :
- Le processus d'architecture : six étapes, des exigences au support
- Les *-ilities : traduire les exigences en capacités techniques
Page du domaine : Process.
À la fin du palier 1, tu n'as choisi aucune technologie, et c'est exactement le but. Tu sais ce que le système doit faire, et ce à quoi il doit faire face.
Palier 2 : Dresser les plans
Le terrain est connu, le programme est écrit. L'architecte s'assoit et dessine. Il choisit d'abord le type d'ouvrage, puis les matériaux, puis il descend jusqu'aux murs porteurs et aux trémies qui laisseront passer les gaines.
Trois domaines, page du palier : Dresser les plans. L'ordre de lecture ne suit pas ce découpage, parce qu'on choisit la forme et les matériaux avant de descendre dans le mur.
Applications
D'abord la forme. Application web, API, service en tâche de fond, mobile, application de bureau, ligne de commande : chaque type a un profil d'usage qui le rend évident ou absurde, et un système réel en combine presque toujours plusieurs. Se tromper de forme coûte plus cher que se tromper de bibliothèque.
Ensuite l'intérieur du composant. Les couches et ce qu'elles interdisent autant que ce qu'elles permettent, les interfaces, l'injection de dépendances, les cinq principes SOLID sans récitation d'acronyme, et deux sujets systématiquement bâclés : la gestion des exceptions et la journalisation.
- Types d'applications : web, API, mobile, service, desktop
- Architecture des composants : couches, interfaces, injection, SOLID, à lire après les deux domaines suivants.
Page du domaine : Applications.
Technology
Le choix des matériaux, celui qu'on ne reprend pas une fois coulé. Deux moitiés : les critères rationnels d'abord (le langage sait-il faire ce travail, quelle maturité, quel écosystème, quelle communauté), puis les contraintes extérieures qui tranchent souvent à la place de l'architecte. Délais, compétences déjà présentes dans l'équipe, capacité de l'exploitation à tenir le produit une fois livré, coût, et l'arbitrage entre acheter et construire.
Page du domaine : Technology.
Data
Les fondations. Le magasin de données est la décision la moins réversible du projet : la reprendre après la mise en production ressemble à une reprise en sous-œuvre sous un bâtiment habité. Relationnel ou non, et sur quels critères réels : structure des données, volumétrie, besoin de cohérence, nature des requêtes, fréquence des changements de schéma.
Page du domaine : Data.
Ordre de lecture du palier 2 : types d'applications, stack technique, magasin de données, puis architecture des composants. Les trois premiers engagent des sommes ; le quatrième engage la vie quotidienne de l'équipe.
Palier 3 : Conduire le chantier
Les plans sont signés, le chantier ouvre. Les lots partent chez des entreprises différentes, les réseaux et les fluides traversent le bâtiment, le local technique centralise ce qui remonte des étages, et le chef de chantier passe ses journées à coordonner des gens qui ne se parleraient pas spontanément. À la livraison, un dossier décrit ce qui a réellement été construit, pas ce qui avait été imaginé.
Ce palier passe du composant au système entier. Trois domaines, page du palier : Conduire le chantier.
Solutions
Les techniques éprouvées du métier, puis les décisions d'échelle. On commence par quatre design patterns qui suffisent largement à démarrer, avec la question qu'on pose rarement : à quel signe reconnaît-on qu'on en abuse.
On enchaîne sur ce qui fait tenir la charge. Ne pas coupler les services entre eux, ne rien garder en mémoire entre deux requêtes, rapprocher la donnée de son consommateur. Puis les trois patterns qu'on cite en réunion pour avoir l'air à jour, microservices, event sourcing et CQRS, avec leur prix annoncé franchement.
Lis dans cet ordre :
- Design patterns 101 : Factory, Repository, Façade, Command
- Couplage lâche, stateless et cache : tenir la charge
- Microservices, Event Sourcing et CQRS : quand et pourquoi, à lire après le domaine Integrations.
Page du domaine : Solutions.
Integrations
Les réseaux et les fluides, puis le local technique. Comment les services se parlent, avec quatre modes possibles (API REST, notifications push HTTP, file de messages, échange par fichiers ou par base) jugés sur cinq critères plutôt que sur une préférence personnelle. Puis la journalisation centralisée et l'identifiant de corrélation, qui décide de la durée d'une nuit d'incident.
Page du domaine : Integrations.
Information
Le livrable de l'architecte. Cinq sections, chacune avec sa longueur cible et son lectorat, du résumé exécutif écrit en dernier au détail par composant. Le billet se termine par une étude de cas qui rejoue toute la série sur un système unique, des premières questions posées au client jusqu'à la table des routes de l'API.
Page du domaine : Information.
Le dernier billet sert de contrôle final : si son étude de cas se lit sans effort, la série a fait son travail.
Les huit domaines en un coup d'œil
Pour repérer rapidement où aller, ce tableau résume le parcours complet.
| Palier | Domaine | Ce qu'on y apprend | Billets |
|---|---|---|---|
| 1. Lire le terrain | Business | Le rôle, le mindset, l'influence sans autorité, objectif contre exigence | Cette page · Le métier d'architecte |
| 1. Lire le terrain | Process | Les six étapes et les exigences non-fonctionnelles chiffrées | Le processus d'architecture · Les *-ilities |
| 2. Dresser les plans | Applications | La forme de l'application, puis l'intérieur du composant | Types d'applications · Composants et SOLID |
| 2. Dresser les plans | Technology | Les critères de choix d'une stack et les contraintes qui tranchent | Choisir sa stack technique |
| 2. Dresser les plans | Data | Relationnel ou non, et sur quels critères réels | SQL ou NoSQL |
| 3. Conduire le chantier | Solutions | Patterns, couplage lâche, stateless, cache, microservices | Design patterns 101 · Couplage lâche · Microservices et CQRS |
| 3. Conduire le chantier | Integrations | Comment les services se parlent, comment on sait ce qui s'est passé | Messagerie et supervision |
| 3. Conduire le chantier | Information | La structure du document et une étude de cas complète | Le document d'architecture |
Comment lire la série
Quelques repères pour en tirer le maximum.
Commence au palier 1, même si tu conçois des systèmes depuis dix ans. Beaucoup de praticiens savent comparer deux bases de données et bloquent sur « combien d'écritures par seconde, au juste ? ». Les deux premiers domaines donnent le vocabulaire que tous les autres réutilisent.
Suis la numérotation, pas le classement. Les domaines rangent les billets par sujet, l'ordre de lecture les enchaîne par dépendance. Les deux ne coïncident pas toujours, et c'est indiqué à chaque fois que le parcours change de domaine en cours de palier.
Repère l'ancre du Chantier avant la technique. Chaque billet commence par une situation de bâtiment, puis transpose. Quand une notion résiste, retourne à son coin du chantier : c'est souvent là que le déclic se produit, parce que la contrainte physique y est évidente.
Reviens à cette page entre deux paliers. En fin de palier, relis le schéma du parcours. Tu verras ce que tu viens d'acquérir et pourquoi la suite arrive maintenant plutôt qu'avant. Une carte ne sert que si on la consulte en chemin.
La série vise la compréhension d'un système entier, pas la maîtrise d'un outil. Aucun billet ne remplace la documentation d'un produit ; tous cherchent à te faire poser la bonne question avant de l'ouvrir.
Points clés
- La série suit un fil rouge unique, lire le terrain, dresser les plans, conduire le chantier, l'ordre dans lequel on mènerait vraiment Le Chantier.
- Trois paliers regroupent huit domaines : Business et Process ; Applications, Technology et Data ; Solutions, Integrations et Information.
- Le palier 1 ne contient aucune technologie, et c'est volontaire : on écrit ce que le système doit encaisser avant de choisir avec quoi le construire.
- Chaque billet ancre sa notion dans Le Chantier, puis la transpose et l'illustre par un cas réel documenté.
- Le dernier billet rejoue la série entière sur une étude de cas unique, du premier entretien client au document d'architecture.
Dans la série
Palier 1 : Lire le terrain. Domaine : Business.
Pour aller plus loin
- Le métier d'architecte : rôle, mindset et influence sans autorité, la suite immédiate de cette page.
- Le processus d'architecture : six étapes, des exigences au support, pour la méthode et les exigences non-fonctionnelles.
- Les trois pages de palier regroupent leurs billets au fil des publications : Lire le terrain, Dresser les plans, Conduire le chantier.
- TOGAF, le cadre d'architecture d'entreprise de The Open Group, si tu veux voir ce qui se joue un cran au-dessus de l'architecture logicielle traitée ici.
