Une architecture, c'est un assemblage de familles de services : un reverse proxy qui reçoit le trafic, une base de données qui garde l'état, un cache qui accélère, une file qui découple, un annuaire qui authentifie. Cette formation apprend à reconnaître ces familles, pas à administrer chaque produit : devant un schéma, vous saurez dire à quoi sert chaque brique, qui l'appelle, si elle porte de l'état, ce qu'il faut sauvegarder et ce qui se passe quand elle tombe.
Elle s'adresse aux ops, administrateurs, SRE et ingénieurs cloud débutants à intermédiaires qui croisent PostgreSQL, Redis, Kafka, Nginx ou Keycloak sans avoir de vue d'ensemble. Elle se place après les bases Linux et réseau, et avant les formations spécialisées vers lesquelles chaque leçon renvoie.
Cette formation se concentre sur le rôle architectural des grandes familles de services. Elle ne remplace pas les formations spécialisées : les produits correspondants sont ou seront installés, configurés, sécurisés, administrés et dépannés dans leurs parcours dédiés. Ici, l'objectif est d'abord de comprendre pourquoi ces briques existent, comment elles interagissent et quelles contraintes elles introduisent dans une architecture.
Ce que vous allez apprendre
Section intitulée « Ce que vous allez apprendre »- Reconnaître la famille d'un composant sans connaître le produit
- Décrire pour chaque brique son rôle, son interface et l'état qu'elle porte
- Identifier ce qu'il faut sauvegarder et l'impact de la perte d'une brique
- Distinguer les familles qu'on confond : proxy, répartiteur et passerelle, file, broker et flux, stockage objet, fichier et bloc
- Repérer un point unique de défaillance sur un schéma
Pourquoi raisonner par familles, et pas par produits ?
Section intitulée « Pourquoi raisonner par familles, et pas par produits ? »Les produits changent, les familles restent. Nginx peut être un serveur web, un reverse proxy ou un répartiteur de charge ; Redis peut être un cache, une base clé-valeur ou un système de messages. Apprendre les produits un par un donne une liste de noms ; apprendre les familles donne une méthode : devant un outil inconnu, on cherche son rôle, puis on en déduit ses contraintes.
C'est aussi la façon dont raisonnent les équipes qui exploitent ces systèmes. Lors d'un incident, la question n'est pas « que fait PostgreSQL ? » mais « quelle brique porte l'état que nous risquons de perdre ? » ; lors d'une revue d'architecture, « où est le point unique de défaillance ? ».
La grille de lecture
Section intitulée « La grille de lecture »Chaque famille est lue avec la même grille de quinze questions, regroupées en cinq axes : rôle et flux, données et état, disponibilité, confiance et sécurité, exploitation. La première leçon la détaille. Toutes les questions n'ont pas de réponse pour toutes les familles : « sans objet » est une réponse juste, à condition de savoir dire pourquoi.
Un seul système, enrichi module après module
Section intitulée « Un seul système, enrichi module après module »Toute la formation suit la même application : une boutique en ligne, qui démarre avec trois briques et grandit à chaque module. Le premier module la lit telle quelle : un utilisateur, une application, une base de données. Chaque module suivant y ajoute ses familles, et chaque leçon répond à la même question : qu'est-ce que cette brique change dans la boutique, qu'est-ce qu'elle apporte et qu'est-ce qu'elle coûte ?
Dans tous les schémas de la formation, un cylindre signale une brique qui garde des données, le trait rouge suit le chemin d'une requête, et un trait pointillé marque une dépendance transverse, comme le DNS ou l'identité, que les schémas courants oublient souvent. Chaque module se termine par un checkpoint : un diagramme inédit à analyser, qui prépare le capstone.
Le programme de la formation
Section intitulée « Le programme de la formation »La formation suit le trajet d'une requête puis s'élargit aux services dont dépend toute la plateforme. Le programme détaillé, avec votre progression, est sur la page Mon parcours.
Lire une architecture
Section intitulée « Lire une architecture »Le premier module pose le vocabulaire commun : service et middleware, client et serveur, protocole, port et API, plan de données et plan de contrôle, dépendance et SPOF. Il traite ensuite les deux notions qui décident de presque tout : l'état, et la différence entre synchrone et asynchrone. Il se termine par la lecture des pannes, domaines de panne et rayon d'impact, et par les mesures qui fondent tout engagement : disponibilité, durabilité, RPO et RTO.
Exposer et acheminer
Section intitulée « Exposer et acheminer »Ce module distingue les briques qui reçoivent et orientent le trafic : serveur web, reverse proxy et forward proxy, répartiteur de charge, passerelle d'API et ingress, puis les services de bordure, CDN et pare-feu applicatif.
Bases relationnelles et NoSQL, moteurs de recherche, bases de séries temporelles et vectorielles, cache, puis stockage objet, fichier et bloc : ce que chaque famille garantit et ce qu'elle ne garantit pas.
Échanger et coordonner
Section intitulée « Échanger et coordonner »Comment découpler des briques qui ne partagent plus le même temps, le même rythme ni la même disponibilité ? File et broker, publication et abonnement, flux d'événements : des familles proches qu'il faut savoir départager. Puis les workers, les ordonnanceurs et les moteurs de workflow, avec ce qu'ils coûtent : doublons, file des échecs, tâches manquées.
Faire fonctionner la plateforme
Section intitulée « Faire fonctionner la plateforme »Quelles dépendances invisibles rendent une application exploitable ? DNS, DHCP et temps, découverte de services et configuration distribuée, annuaire et fournisseur d'identité, secrets, PKI et gestion des clés, forges et registres, plateformes d'exécution et observabilité : pour chacune, ce qui casse tout de suite et ce qui casse au redémarrage.
Services d'exploitation et d'administration
Section intitulée « Services d'exploitation et d'administration »Les briques qui servent à opérer le système plutôt qu'à le faire fonctionner, rangées par responsabilité : accéder par bastion, VPN ou réseau overlay, conserver par la sauvegarde et le plan de reprise, détecter avec un SIEM, connaître et piloter avec la CMDB, l'IPAM et l'outil de gestion des services.
Capstone
Section intitulée « Capstone »Un exercice de lecture d'architecture complète, sur un système inédit présenté en deux vues, les flux puis la plateforme : identifier chaque famille, suivre les flux, marquer l'état, prédire les pannes, dire quoi sauvegarder et où observer.
Ce que la formation ne fait pas
Section intitulée « Ce que la formation ne fait pas »Elle n'enseigne pas l'administration des produits, ce qui ne veut pas dire que le site l'ignore : installer PostgreSQL, régler Kafka ou configurer Keycloak relève des formations et guides spécialisés, qui prennent le relais et sont cités dans chaque leçon. Elle n'apprend pas non plus à concevoir une architecture, choisir et assembler des services pour un besoin donné, une capacité plus haute qui suppose celle-ci acquise.
À retenir
Section intitulée « À retenir »- Une architecture se lit par familles de services, pas par produits.
- Pour chaque brique : rôle, interface, état, sauvegarde, impact de sa perte.
- La même grille de quinze questions s'applique à toutes les familles.
- La formation apprend à reconnaître, les formations spécialisées à administrer.