Le Cours du Leader Cloud

De zéro connaissance à la direction fluide d’une équipe d’ingénieurs cloud.

Comment fonctionne ce cours

Vous ne vous formez pas pour devenir ingénieur cloud. Vous vous formez pour diriger des ingénieurs cloud : suivre chaque conversation dans la salle, poser les questions qui comptent, prendre de bonnes décisions concernant l’argent, les risques et les personnes, et gagner le respect des experts sans prétendre en être un. C’est une compétence différente, entièrement apprenable — et c’est la compétence que ce cours enseigne.

Le cours comporte trois étapes. Étape 1 (Semaines 1–8) : Parler la langue. Vous apprenez ce qu’est réellement le cloud (l’informatique en nuage) et le vocabulaire de chaque brique de base, pour que les réunions cessent de ressembler à du bruit. Étape 2 (Semaines 9–16) : Penser comme la salle. Architecture, sécurité et argent — les trois conversations que toute équipe cloud a chaque semaine, et les trois où un leader apporte de la valeur ou se fait ignorer. Étape 3 (Mois 5–24) : Diriger. Certifications, recrutement, animation des réunions de décision, et le chemin honnête de deux ans pour tenir tête aux ingénieurs seniors.

Règles pour l’ensemble du cours : étudiez une heure par jour, six jours par semaine — la régularité l’emporte sur l’intensité. Chaque module se termine par un Exercice de fluidité (Fluency Drill) (des phrases à dire à voix haute jusqu’à ce qu’elles deviennent naturelles) et un Jalon (Milestone) (la preuve que vous êtes prêt à passer à la suite). Faites-les ; la lecture seule construit la reconnaissance, pas la fluidité. Et dès la Semaine 1, tenez un Journal de décisions : chaque fois que vous apprenez un concept, écrivez une phrase sur la façon dont il affecte l’argent, les risques ou les personnes — car cette traduction est tout votre métier.

ÉTAPE 1 — PARLER LA LANGUE (Semaines 1–8)

Module 1 (Semaines 1–2) : Ce qu’est réellement le cloud

La grande idée : le cloud, ce sont les ordinateurs de quelqu’un d’autre, loués à l’heure, gérés par du logiciel. Avant le cloud, une entreprise achetait des serveurs physiques, les installait dans une salle et payait des gens pour les maintenir — lent, coûteux, rigide. AWS, Microsoft Azure et Google Cloud ont construit des entrepôts contenant des millions d’ordinateurs (des data centers, ou centres de données) et permettent à quiconque d’en louer des tranches à la seconde, depuis n’importe où, via une page web ou une ligne de code. C’est tout. Tout le reste de ce cours n’est que du détail au-dessus de cette idée unique.

Les trois grands fournisseurs, définis :

Votre compte AWS gratuit — créez-le dès la Semaine 1. Rendez-vous sur https://aws.amazon.com/free et cliquez sur « Create a Free Account » (la page d’inscription directe est https://signin.aws.amazon.com/signup?request_type=register). Il vous faudra une adresse e-mail, un numéro de téléphone et une carte de crédit/débit pour la vérification d’identité — le Free Tier (offre gratuite) vous donne une allocation mensuelle gratuite des services de base (dont 750 heures/mois d’un petit serveur EC2 la première année), et les exercices de ce cours restent dans ces limites. Deux habitudes de sécurité dès le premier jour : activez la MFA (authentification multifacteur — le Module 6 l’explique) et configurez une alerte de facturation à 5 $ (le Module 7 explique comment), afin de ne jamais être pris par surprise. Après l’inscription, vous vous connectez sur https://console.aws.amazon.com — la « console » est simplement la page web de contrôle d’AWS.

Pourquoi les entreprises utilisent le cloud : la vitesse (un nouveau serveur en 60 secondes au lieu de 6 semaines), l’élasticité (louer 100 serveurs pour le grand jour de soldes, en rendre 90 le lendemain), l’absence de coût initial (dépense d’exploitation au lieu de dépense d’investissement) et la portée mondiale (placer votre application près de vos clients à Bangkok, Tokyo et Francfort sans rien construire).

Les trois couches de services — le modèle mental le plus utile du cloud :

Régions et zones de disponibilité : une Région est un groupe géographique de centres de données (la Thaïlande possède sa propre Région AWS depuis janvier 2025, à Bangkok et dans ses environs). Une zone de disponibilité (Availability Zone, AZ) est un ou plusieurs centres de données isolés au sein d’une région. Les applications qui comptent tournent dans au moins deux AZ, pour que la défaillance d’un bâtiment ne les fasse pas tomber. Quand les ingénieurs disent « nous sommes multi-AZ », ils veulent dire « un centre de données peut brûler et nous restons en ligne ».

Vocabulaire :

Vidéos pour ce module (toutes gratuites, liens vérifiés) :

Exercice de fluidité — répétez ces phrases jusqu’à ce qu’elles soient naturelles : “Is that workload on-prem or in the cloud?” (« Ce workload est-il sur site ou dans le cloud ? ») · “Which region are we in — and are we multi-AZ?” (« Dans quelle région sommes-nous — et sommes-nous multi-AZ ? ») · “Is this an IaaS approach or is there a managed service that removes the maintenance?” (« Est-ce une approche IaaS ou existe-t-il un service managé qui supprime la maintenance ? »)

Exercices : (1) Créez votre compte AWS gratuit sur https://aws.amazon.com/free — le parcours d’inscription lui-même vous apprend plus de vocabulaire qu’un chapitre de lecture. (2) Regardez les quatre vidéos du tableau ci-dessus (moins de 20 minutes au total). (3) Dans votre journal : rédigez l’explication « ascenseur » du cloud que vous donneriez à un directeur d’école thaïlandais en une seule respiration.

Jalon : vous savez expliquer IaaS vs PaaS vs SaaS avec votre propre analogie, et expliquer pourquoi l’ouverture d’une région AWS à Bangkok a compté pour les banques thaïlandaises (réponse : latence + résidence des données — voir Module 6).

Module 2 (Semaines 3–4) : Les briques de base — calcul, stockage et bases de données

Le calcul (compute) — les moteurs qui exécutent le code. Une machine virtuelle (VM/instance) est une tranche d’un serveur physique qui se comporte comme un ordinateur complet ; vous choisissez une taille (CPU/RAM) et payez à la seconde d’exécution. Un container (conteneur) est une façon plus légère et plus rapide d’empaqueter une application pour qu’elle tourne à l’identique partout ; Docker les empaquette et Kubernetes (K8s) en orchestre des flottes entières — quand vous entendez « K8s », pensez « le système qui fait tourner et répare automatiquement nos centaines de containers ». Le serverless (informatique sans serveur à gérer — AWS Lambda) signifie que vous ne téléversez qu’une fonction de code ; le cloud l’exécute quand elle est déclenchée et vous payez à l’invocation — aucun serveur à gérer. Le schéma à remarquer : VM → container → serverless est un curseur allant de « plus de contrôle, plus de maintenance » vers « moins de contrôle, maintenance quasi nulle ». Les bonnes équipes choisissent par workload, pas par effet de mode.

Le stockage — trois formes. Le stockage objet (Amazon S3) : un seau sans fond pour les fichiers — images, vidéos, sauvegardes, jeux de données ; bon marché, durable à onze neufs, la réponse par défaut à « où met-on les fichiers ? » Le stockage bloc (EBS) : le disque dur virtuel attaché à une VM. Le stockage fichier (EFS) : un lecteur partagé que de nombreuses machines montent en même temps. Puis les tiers (classes de stockage) : chaud (accès fréquent, coûteux) vs froid/archive (Glacier — bon marché, lent) — déplacer les vieilles données vers les tiers froids est l’une des économies les plus faciles à livrer pour n’importe quelle équipe.

Les bases de données — deux familles. Relationnelles/SQL (MySQL, PostgreSQL ; gérées sous forme d’Amazon RDS/Aurora) : des données en tables à structure stricte ; le choix par défaut pour l’argent, les commandes, les utilisateurs — tout ce où l’exactitude est sacrée. NoSQL (DynamoDB, MongoDB) : flexibles, massivement scalables ; le choix par défaut pour des données énormes, rapides et de forme plus simple (sessions, catalogues, fils d’actualité). « Base de données managée » signifie que le fournisseur gère les sauvegardes, les correctifs et le basculement — les équipes devraient avoir une raison solide pour faire tourner la leur elles-mêmes.

Vocabulaire :

Vidéos pour ce module :

Exercice de fluidité : “Should this run on VMs, containers, or serverless — and what’s the operational cost of each choice?” (« Cela doit-il tourner sur des VM, des containers ou en serverless — et quel est le coût opérationnel de chaque choix ? ») · “Is that data hot or can it go to a cheaper tier?” (« Ces données sont-elles chaudes ou peuvent-elles passer à un tier moins cher ? ») · “Why are we self-managing that database instead of using RDS?” (« Pourquoi gérons-nous nous-mêmes cette base de données au lieu d’utiliser RDS ? »)

Exercices : (1) Dans votre compte gratuit : lancez la plus petite instance EC2, puis résiliez-la. Téléversez un fichier dans S3. Vous venez d’utiliser personnellement de l’IaaS. (2) Demandez à un assistant IA de vous interroger : « Donne-moi 10 scénarios ; je répondrai VM, container ou serverless, et tu me noteras. »

Jalon : pour toute application simple décrite en une phrase (« un site web où les élèves commandent leur déjeuner »), vous savez nommer à voix haute ses briques de calcul, de stockage et de base de données en 60 secondes.

Module 3 (Semaines 5–6) : Les réseaux, et comment les briques se parlent

Le VPC — votre quartier privé. Un Virtual Private Cloud (cloud privé virtuel) est votre propre section clôturée du réseau du fournisseur. À l’intérieur se trouvent des subnets (sous-réseaux) — publics (accessibles depuis internet, p. ex. les serveurs web) et privés (inaccessibles, p. ex. les bases de données). La phrase de sécurité la plus courante que vous entendrez : « la base de données se trouve dans un subnet privé. » Si vous comprenez pourquoi — les attaquants ne peuvent pas toucher ce qui n’a aucun chemin depuis internet — vous comprenez la moitié de la sécurité réseau.

La couche trafic : un équilibreur de charge (load balancer) répartit le trafic entrant entre plusieurs serveurs (et retire discrètement ceux qui sont malades) ; le DNS (Route 53) traduit des noms comme votreentreprise.com en adresses ; un CDN (réseau de diffusion de contenu — CloudFront) met votre contenu en cache dans des centaines de villes pour qu’il se charge vite partout ; une API (interface de programmation) est la porte qu’un logiciel offre à un autre — quand les ingénieurs disent « we’ll expose an API », ils veulent dire « nous donnerons à d’autres logiciels un moyen contrôlé d’utiliser le nôtre » ; une API gateway (passerelle API) est l’accueil qui gère ces portes.

Relier les mondes : un VPN (tunnel chiffré via internet) ou Direct Connect (une ligne physique privée) relie les bureaux/systèmes on-prem d’une entreprise à son cloud. Cloud hybride = faire tourner à la fois du on-prem et du cloud (la plupart des grandes entreprises thaïlandaises) ; multi-cloud = utiliser plus d’un fournisseur.

Vocabulaire :

Vidéo pour ce module : AWS Networking Basics — VPC & Subnets for Beginners — KodeKloud — https://www.youtube.com/watch?v=QM63dyA_4Pc (regardez la première moitié maintenant ; revenez pour le reste après le Module 5).

Exercice de fluidité : “Is the database in a private subnet?” (« La base de données est-elle dans un subnet privé ? ») · “What happens when one web server dies — is the load balancer health-checking?” (« Que se passe-t-il quand un serveur web meurt — l’équilibreur de charge fait-il des contrôles de santé ? ») · “Are we exposing that as an API or is it internal only?” (« Exposons-nous cela comme une API ou est-ce interne uniquement ? »)

Exercices : (1) Demandez à une IA de vous guider pour dessiner, sur papier, le réseau d’une application de livraison de repas : utilisateurs → CDN → équilibreur de charge → serveurs web (subnet public) → base de données (subnet privé). Dessinez-le trois fois, jusqu’à pouvoir le faire de mémoire. (2) Trouvez le diagramme d’architecture de votre entreprise (ou n’importe quel exemple) et entourez chaque boîte que vous savez désormais nommer.

Jalon : vous savez esquisser ce diagramme trois-tiers standard sur un tableau blanc et raconter le chemin du clic d’un client à travers lui.

Module 4 (Semaines 7–8) : Comment travaillent les équipes cloud — DevOps, IaC, et lire la salle

DevOps est la culture qui fusionne « les gens qui écrivent le logiciel » (Dev) et « les gens qui le font tourner » (Ops) en une seule équipe qui livre de petits changements fréquemment et en sécurité, l’automatisation faisant le gros du travail. Son battement de cœur est le pipeline CI/CD (chaîne d’intégration et de livraison continues) : chaque changement de code est automatiquement construit, testé et déployé (Continuous Integration / Continuous Delivery). Quand une équipe dit « c’est dans le pipeline », elle veut dire que le robot est en train de le tester et de le livrer.

L’Infrastructure as Code (IaC, l’infrastructure en tant que code) — l’idée qui a tout changé : au lieu de cliquer dans une console pour créer des serveurs, les ingénieurs écrivent des fichiers texte qui déclarent l’infrastructure (« deux serveurs, un équilibreur de charge, une base de données, ces règles de pare-feu »), et un outil (Terraform, CloudFormation) fait correspondre la réalité au fichier. Pourquoi les leaders s’en soucient : les fichiers vivent dans Git (le système de gestion de versions), donc chaque changement d’infrastructure est relu, réversible et auditable — la différence entre un atelier et une usine.

Les rituels auxquels vous assisterez : le stand-up (réunion debout quotidienne de 15 minutes : ce qui est fait, ce qui vient, ce qui bloque — écoutez les blocages ; les lever est votre travail), le sprint (une unité de travail planifié de 1–2 semaines), la rétro (ce qu’il faut améliorer), le post-mortem/revue d’incident (après une panne : analyse sans blâme de ce qui a échoué et de ce qui empêchera la répétition — la santé d’une équipe se voit à l’honnêteté de ces revues), l’astreinte (on-call) (la rotation de qui est réveillé à 3 h du matin ; si l’astreinte est pénible, vos meilleurs éléments partiront — posez la question chaque mois).

Les métriques de santé qui comptent : l’uptime/la disponibilité (« trois neufs » = 99,9 % ≈ 8,8 heures d’arrêt/an ; chaque neuf supplémentaire multiplie le coût), le SLA (l’engagement contractuel, avec pénalités), le SLO (l’objectif interne), le MTTR (la vitesse de rétablissement — les équipes matures optimisent le rétablissement, pas le fantasme du zéro panne), la fréquence de déploiement (les équipes saines livrent souvent de petits changements ; la peur de déployer est un mauvais signe).

Vocabulaire :

Vidéos pour ce module :

Exercice de fluidité : “Is that change through the pipeline or was it manual?” (« Ce changement est-il passé par le pipeline ou a-t-il été manuel ? ») · “What did the post-mortem conclude, and what’s the prevention item?” (« Qu’a conclu le post-mortem, et quelle est l’action de prévention ? ») · “What’s our MTTR trending like?” (« Quelle est la tendance de notre MTTR ? ») · “Is this in Terraform, or did someone click it into existence?” (« Est-ce dans Terraform, ou quelqu’un l’a-t-il créé à coups de clics ? ») — ce dernier cas s’appelle le « ClickOps », prononcé avec une moue désapprobatrice.

Exercices : (1) Regardez la discussion d’un vrai compte rendu de post-mortem d’incident (beaucoup sont publics — les rapports de pannes de Cloudflare et d’AWS sont célèbres) et résumez-le dans votre journal en cinq phrases. (2) Assistez à (ou regardez l’enregistrement de) n’importe quel stand-up et notez les trois blocages que vous avez entendus.

Jalon — fin de l’Étape 1 : vous savez assister à une réunion de planification technique de 30 minutes et en suivre ≥ 80 %, et votre journal le prouve : des notes d’une réunion réelle ou simulée avec chaque acronyme correctement développé. C’est aussi le moment de planifier l’examen AWS Cloud Practitioner (CLF-C02) — 2 à 4 semaines de préparation concentrée en plus de ces modules est la norme publiée, et le réussir est votre première preuve externe.

ÉTAPE 2 — PENSER COMME LA SALLE (Semaines 9–16)

Module 5 (Semaines 9–10) : L’architecture — juger des conceptions sans les dessiner

Votre rôle dans une revue de conception n’est pas de concevoir — c’est d’interroger. Le cadre qu’utilise toute l’industrie est le Well-Architected Framework d’AWS (cadre de bonne architecture), six piliers auxquels toute conception doit répondre : excellence opérationnelle, sécurité, fiabilité, efficacité des performances, optimisation des coûts, durabilité. Apprenez en profondeur les trois en gras ; c’est là que vivent l’argent et le risque.

La fiabilité, en termes simples : tout finit par tomber en panne, donc les bons systèmes le présupposent. La redondance (aucun point de défaillance unique — deux exemplaires de tout ce qui est important), le multi-AZ (survivre à la perte d’un centre de données), l’auto-scaling (mise à l’échelle automatique — des machines ajoutées/retirées automatiquement selon la demande), des sauvegardes testées (une sauvegarde non testée est un espoir, pas un plan), le RTO/RPO (Recovery Time Objective : combien de temps pouvons-nous être à l’arrêt ; Recovery Point Objective : combien de données pouvons-nous perdre — ces deux chiffres sont la conversation sur la reprise après sinistre, et ce sont des décisions business, c’est-à-dire les vôtres).

Le triangle des compromis : rapide, pas cher, résilient — choisissez-en deux. Chaque débat d’architecture que vous arbitrerez se réduit à savoir où, sur ce triangle, le business doit se situer pour ce workload. Un système de paiement et un site marketing ne méritent pas la même réponse.

Les sept questions du leader — mémorisez-les ; elles vous rendent redoutable dans toute revue de conception :

1. “What happens when this component fails?” (« Que se passe-t-il quand ce composant tombe en panne ? ») — il y a toujours un « quand »
2. “What are the RTO and RPO, and who signed off on them?” (« Quels sont le RTO et le RPO, et qui les a validés ? »)
3. “Where does this run — single AZ, multi-AZ, multi-region — and why?” (« Où cela tourne-t-il — AZ unique, multi-AZ, multi-région — et pourquoi ? »)
4. “What will this cost per month at 10× today’s load?” (« Combien cela coûtera-t-il par mois à 10× la charge actuelle ? »)
5. “What’s the simplest version that meets the requirement?” (« Quelle est la version la plus simple qui satisfait le besoin ? ») — la sur-ingénierie est la maladie du junior ; la simplicité est la vertu du senior
6. “What are we locked into, and what would leaving cost?” (« À quoi sommes-nous liés, et combien coûterait un départ ? ») — le vendor lock-in (l’enfermement chez un fournisseur) est un prix, parfois digne d’être payé — en connaissance de cause
7. “Who else has built this before — are we inventing or assembling?” (« Qui d’autre a déjà construit cela — inventons-nous ou assemblons-nous ? ») — préférez les patterns ennuyeux et éprouvés

Exercice de fluidité : entraînez-vous à poser les questions 1, 4 et 5 sur un ton chaleureux — elles passent pour de la sagesse ou pour une attaque selon la seule façon de les livrer. “Help me understand what happens if the cache goes down” (« Aidez-moi à comprendre ce qui se passe si le cache tombe ») vaut mieux que “did you think about failure?” (« avez-vous pensé aux pannes ? »).

Exercices : (1) Prenez trois architectures d’exemple (demandez à une IA d’en générer : un site e-commerce, un backend d’application mobile, une plateforme d’analyse de données) et passez les sept questions sur chacune, en écrivant les réponses que vous attendriez. (2) Lisez le résumé d’une page des piliers Well-Architected sur https://aws.amazon.com/architecture/well-architected/.

Vidéos pour ce module :

Jalon : lors d’une revue de conception simulée (faites-la avec une IA jouant l’ingénieur), vous posez cinq questions de fond et résumez correctement le point le plus faible de la conception à la fin.

Module 6 (Semaines 11–12) : Sécurité et conformité — la conversation qui peut tuer des entreprises

Le modèle de responsabilité partagée — la première chose à comprendre : le fournisseur sécurise le cloud lui-même (bâtiments, matériel, hyperviseurs) ; vous sécurisez ce que vous mettez dedans (vos données, vos règles d’accès, vos configurations). La plupart des fuites sont des erreurs de configuration côté client — un bucket S3 laissé public, une clé d’accès divulguée — pas des défaillances du fournisseur. Donc « AWS est sécurisé » et « nous sommes sécurisés sur AWS » sont deux phrases différentes.

Le vocabulaire de la défense : IAM (Identity and Access Management — la gestion des identités et des accès : qui a le droit de faire quoi ; la chose la plus auditée du cloud), le moindre privilège (chacun reçoit le minimum d’accès nécessaire — la règle d’or), la MFA (deuxième facteur sur chaque connexion humaine — non négociable), le chiffrement au repos et en transit (données brouillées sur disque et sur le réseau — le minimum vital, toujours activé), le compte root (la clé maîtresse — mise sous clé, jamais utilisée au quotidien), la gestion des secrets (mots de passe/clés dans un coffre-fort, jamais dans le code), le zero trust (confiance zéro — tout vérifier, ne faire confiance à aucun emplacement réseau par défaut), le test d’intrusion (penetration test) (des attaquants engagés qui éprouvent vos défenses), le ransomware (rançongiciel — la raison pour laquelle des sauvegardes testées et hors ligne sont un contrôle de sécurité, pas seulement un contrôle d’exploitation).

Le PDPA — la loi thaïlandaise sur les données, et votre avantage sur le marché. Le Personal Data Protection Act est le RGPD de la Thaïlande : consentement requis pour la collecte de données personnelles, une obligation de notification de violation sous 72 heures, des délégués à la protection des données pour les grands traitants, et des règles sur l’envoi de données à l’étranger. L’application est devenue réelle en 2025 — plus de 21,5 millions de THB de premières amendes, dont un hôpital sanctionné pour avoir mal supervisé un prestataire. Deux conséquences pour vous : (1) chaque grande entreprise thaïlandaise a désormais un problème de conformité que votre société peut être payée pour gérer ; (2) la résidence des données — garder les données thaïlandaises sur le sol thaïlandais — est un vrai moteur qui pousse les workloads vers les régions de Bangkok. Ce paragraphe est la moitié de votre argumentaire commercial en Thaïlande ; connaissez-le par cœur.

Les questions de sécurité du leader : “Who has access to production, and when did we last review the list?” (« Qui a accès à la production, et quand avons-nous revu la liste pour la dernière fois ? ») · “Are we alerted on unusual access, or would we find out from the news?” (« Sommes-nous alertés en cas d’accès inhabituel, ou l’apprendrions-nous par la presse ? ») · “When did we last restore a backup?” (« Quand avons-nous restauré une sauvegarde pour la dernière fois ? ») — pas « avons-nous des sauvegardes » · “If we lost this dataset, is it a PDPA-notifiable breach — and could we notify within 72 hours?” (« Si nous perdions ce jeu de données, serait-ce une violation à notifier au titre du PDPA — et pourrions-nous notifier sous 72 heures ? ») · “What did the last pen test find, and what’s still open?” (« Qu’a trouvé le dernier test d’intrusion, et qu’est-ce qui reste ouvert ? »)

Vocabulaire :

Vidéo pour ce module : The AWS Shared Responsibility Model — Digital Cloud Training — 4 min — https://www.youtube.com/watch?v=ESPBBEK-cvo

Exercice de fluidité : “Is that bucket public? Why?” (« Ce bucket est-il public ? Pourquoi ? ») · “Least privilege — does the intern really need prod access?” (« Moindre privilège — le stagiaire a-t-il vraiment besoin d’un accès à la prod ? ») · “Where does the PDPA line sit in this design — what’s personal data here and where does it physically live?” (« Où passe la ligne du PDPA dans cette conception — qu’est-ce qui relève des données personnelles ici et où vivent-elles physiquement ? »)

Exercices : (1) Lisez l’histoire d’une célèbre fuite due à une mauvaise configuration cloud (Capital One 2019 est le classique) et écrivez-en la version en trois phrases pour votre journal. (2) Faites simuler par une IA un client demandant « pourquoi devrais-je vous confier mes données ? » et entraînez-vous à répondre avec le langage de la responsabilité partagée et du PDPA.

Jalon : vous savez expliquer le modèle de responsabilité partagée et la signification pratique du PDPA à un chef d’entreprise thaïlandais non technique en moins de trois minutes — car cette explication est le rendez-vous commercial d’un MSP (fournisseur de services managés).

Module 7 (Semaines 13–14) : L’argent — l’économie du cloud et le FinOps

C’est ici qu’un leader non-ingénieur apporte de la valeur le plus vite, car la plupart des ingénieurs ne l’ont jamais appris et le gaspillage est énorme — les enquêtes montrent invariablement qu’environ un tiers des dépenses cloud est gaspillé.

Comment tourne le compteur : le calcul est facturé à la seconde où il est allumé (pas à l’usage — un serveur inactif facture plein pot ; « on l’a laissé tourner » est le gaspillage classique), le stockage au Go-mois, et — le piège célèbre — l’egress : les données qui sortent du cloud coûtent de l’argent, tandis que les données entrantes sont gratuites. Les grosses factures d’egress surprennent tout le monde une fois ; après ce module, pas vous.

Le menu tarifaire : on-demand (à la demande : plein tarif, flexibilité totale) · reserved instances / savings plans (instances réservées / plans d’épargne : s’engager 1 à 3 ans pour 30–70 % de réduction — le plus grand levier sur un workload stable) · spot instances (instances spot : jusqu’à 90 % de réduction pour le travail interruptible comme les traitements par lots) · rightsizing (redimensionnement : la plupart des serveurs sont surdimensionnés ; les réduire est de l’argent gratuit) · le tiering du stockage (Module 2) · l’auto-scaling comme outil de coût (pourquoi payer la capacité de minuit au prix de midi ?).

Le FinOps (la gestion financière du cloud) est la pratique consistant à rendre la dépense cloud visible, allouée et optimisée en continu : le tagging (étiquetage) de chaque ressource avec son propriétaire et son projet (une dépense non taguée est une dépense sans responsable), le showback/chargeback (montrer sa facture à chaque équipe — le comportement change instantanément), des budgets avec alertes (ne jamais découvrir un dépassement sur la facture), et les unit economics (économie unitaire) — la métrique du leader : non pas « notre facture est de 800 k฿/mois » mais « notre coût par transaction client baisse ». La certification FinOps Certified Practitioner demande environ deux semaines et est, pour un leader côté business, le certificat au meilleur ratio crédibilité/heure de tout l’univers cloud. Obtenez-la.

Les questions d’argent du leader : “What’s our cost per [customer/transaction/tenant], and which direction is it moving?” (« Quel est notre coût par [client/transaction/locataire], et dans quel sens évolue-t-il ? ») · “What percentage of our steady workload is on reservations?” (« Quel pourcentage de notre workload stable est sous réservation ? ») · “What’s untagged?” (« Qu’est-ce qui n’est pas tagué ? ») · “What died but is still billing?” (« Qu’est-ce qui est mort mais facture encore ? ») — disques orphelins et IP inutilisées : chaque compte en a · “What would this bill look like at 10× growth — does our architecture get cheaper or more expensive per unit?” (« À quoi ressemblerait cette facture à une croissance de 10× — notre architecture devient-elle moins chère ou plus chère à l’unité ? »)

Vocabulaire :

Vidéo pour ce module : What is FinOps? — FinOps Foundation (official) — 2 min — https://www.youtube.com/watch?v=Y-c_xw9bHFw · puis le cours gratuit « Introduction to FinOps » sur https://learn.finops.org.

Exercices : (1) Ouvrez le calculateur de prix AWS et chiffrez un petit système réel (deux serveurs, une base de données, 500 Go de stockage, 1 To d’egress) — le faire une fois démystifie toutes les futures conversations sur les coûts. (2) Demandez à une IA de jouer un ingénieur défendant un serveur surdimensionné ; entraînez-vous à négocier le rightsizing avec bienveillance.

Jalon : passez (ou planifiez) l’examen FinOps Practitioner et, dans une revue simulée, trouvez quatre problèmes de coûts dans un exemple de facture qu’une IA génère pour vous.

Module 8 (Semaines 15–16) : Bootcamp de fluidité — assembler la langue

Cette quinzaine est de l’intégration pure — la différence entre connaître les mots et être fluide en réunion.

Exercice quotidien (30 min) : faites générer par une IA une transcription de réunion réaliste (revue de conception, rétro d’incident ou revue de coûts), avec deux erreurs techniques délibérément enfouies dedans. Votre travail : résumer la réunion en cinq phrases, repérer les erreurs et écrire les trois questions que vous auriez posées. Alternez les types de réunion chaque jour.

Le muscle de la traduction (15 min) : prenez une affirmation technique par jour et traduisez-la pour trois publics — le directeur financier (l’argent), un client (risque/bénéfice) et un jeune ingénieur junior (l’enseignement). Exemple : « Nous déplaçons le stockage des sessions de la base de données vers Redis » → directeur financier : « cela réduit la charge de la base de données, donc nous reportons une mise à niveau de 2 M฿ » → client : « les pages se chargent plus vite en heure de pointe » → junior : « Redis garde les données chaudes en mémoire, donc nous arrêtons de marteler la base de données à chaque clic. »

Pratique de lecture (15 min) : un vrai article de blog d’ingénierie par jour (AWS Architecture Blog, ou les blogs d’ingénierie de Netflix/Grab — Grab est particulièrement pertinent : échelle sud-est-asiatique, marché proche de la Thaïlande). Vous en comprendrez désormais 70–80 %. Cherchez le reste.

Votre compagnon de préparation à l’examen pour cette étape : le célèbre cours complet gratuit — AWS Certified Cloud Practitioner (CLF-C02) 2026 d’Andrew Brown sur freeCodeCamp — https://www.youtube.com/watch?v=7HKot-brXFE (l’édition antérieure de 14 heures, valable pour le même code d’examen, est sur https://www.youtube.com/watch?v=NhDYbskXRgc). Regardez-le à 1,25× au fil des Semaines 13–16 ; après les Modules 1–7, l’essentiel vous fera l’effet d’une révision, ce qui est exactement le signe que vous êtes prêt.

Jalon — fin de l’Étape 2, votre examen de fin d’études : (1) Réussissez l’AWS Cloud Practitioner si ce n’est pas déjà fait. (2) L’épreuve simulée : une IA joue un ingénieur senior qui vous présente une architecture défectueuse pour un client e-commerce thaïlandais ; vous devez trouver la base de données en AZ unique, le bucket S3 public, l’estimation d’egress manquante et la considération PDPA absente — et livrer le retour sur un ton qui donne à « l’ingénieur » le sentiment d’être aidé, pas pris en faute. Quand vous savez faire cela, vous êtes redoutable en conversation, seize semaines après le début.

ÉTAPE 3 — DIRIGER (Mois 5–24)

Module 9 (Mois 5–8) : La certification approfondie et le plancher technique

Travaillez le matériel de l’AWS Solutions Architect Associate (SAA-C03) — 2 à 3 mois à votre rythme d’une heure par jour. Vous passerez ou non l’examen (en tant que leader, c’est le matériel qui a de la valeur ; le badge est du théâtre optionnel), mais c’est ici que les régions, les VPC, l’IAM et la tarification cessent d’être du vocabulaire pour devenir un système connecté dans votre tête. En parallèle, maintenez les exercices quotidiens du Module 8 à demi-dose. C’est aussi la fenêtre pour ajouter les fondamentaux Azure (niveau AZ-900) — la Thaïlande est un marché d’entreprises très orienté Microsoft, et une littératie bilingue (AWS+Azure) élargit vos conversations clients.

Module 10 (Mois 5–12, en continu) : Recruter et manager des ingénieurs

Recruter quand on ne peut pas pleinement juger la compétence : la structure bat l’instinct. Utilisez une boucle cohérente : un entretien de présélection que vous menez (motivation, communication, la façon dont la personne explique un projet passé à un non-ingénieur — si elle n’y arrive pas, elle échouera aussi avec vos clients) + un entretien technique conduit par votre bar-raiser (le garant du niveau : votre n°2 technique ou un contractuel senior rémunéré) + un appel de référence où vous posez exactement la seule question qui compte : “would you hire this person again for this role?” (« réembaucheriez-vous cette personne pour ce poste ? »). Guettez les deux archétypes d’échec : le beau parleur sans profondeur (votre bar-raiser le repère) et l’expert profond mais silencieux (souvent de l’or dans les équipes thaïlandaises, où la modestie est culturelle — ne laissez pas le vernis d’entretien peser plus lourd que les preuves de travail réel).

Le n°2 technique — la décision la plus importante de l’aventure : recrutez-le en premier, payez-le avec une part de capital significative (10–20 % s’il s’agit d’un vrai cofondateur), et définissez l’accord explicitement : il tient le niveau technique et possède les décisions d’architecture ; vous possédez les clients, l’argent, les priorités et les personnes ; vos désaccords se règlent en privé et se résolvent avant que l’équipe ne les voie.

Les rituels qui font rester les ingénieurs : des 1:1 (entretiens individuels) hebdomadaires ou bimensuels qui parlent d’eux (carrière, frictions, énergie — pas de points d’avancement) ; un plan de progression écrit par personne (dans le marché thaïlandais en pénurie de 70 000 talents/an, la progression et les budgets de certification retiennent mieux que le salaire seul — payez chaque certification, avec une prime acquise sur 12 mois à l’obtention) ; le crédit en public, la correction en privé ; et une protection impitoyable de leur temps de concentration — un leader qui annule une réunion en plein sprint est un héros.

Les forums de décision — comment prendre des décisions techniques que vous ne pouvez pas pleinement évaluer : pour toute grande décision, exigez de l’ingénieur qui propose un document de décision d’une page : le problème, 2–3 options, coûts, risques, recommandation. Puis animez la réunion avec vos sept questions du Module 5. Vous n’êtes pas le meilleur architecte de la salle et n’avez jamais besoin de l’être — vous êtes la personne qui fait gagner l’option la mieux argumentée, dans les délais, avec les compromis d’argent et de risque rendus explicites. Les ingénieurs respectent profondément cela quand c’est fait honnêtement ; notez qui a prédit quoi (votre Journal de décisions, encore) et revoyez les prédictions chaque trimestre — cela vous calibre, eux comme vous.

Module 11 (Mois 6–24) : La courbe de crédibilité, honnêtement

L’expérience publiée dans la littérature du leadership d’ingénierie converge vers cette chronologie, et prétendre le contraire est la façon dont les fondateurs non techniques échouent : ~90 jours pour mener avec compétence le rythme business · ~6 mois pour une efficacité de base (réunions fluides, décisions structurées, équipe stable) · 12–18 mois avant que vos intuitions techniques ne valent quelque chose par elles-mêmes · ~2 ans avant de tenir véritablement tête aux ingénieurs seniors sur les compromis d’architecture. Les parades pendant que la courbe grimpe : empruntez de la crédibilité (votre n°2 présente la moitié technique des rendez-vous commerciaux — les clients ont de toute façon besoin de voir le banc), ne bluffez jamais (le tueur de crédibilité le plus rapide ; “I don’t know — walk me through it” (« Je ne sais pas — expliquez-moi ») est une phrase de leader), et laissez vos questions parler pour vous : un leader qui demande “what’s our RPO and who signed off on it?” (« quel est notre RPO et qui l’a validé ? ») sonne comme trente ans de cicatrices, et après ce cours, vous le penserez vraiment.

Module 12 (En continu) : La couche marché thaïlandais

Intégrez les spécificités de la Partie 5 du TSI comme savoir opérationnel : le PDPA à la fois comme obligation de conformité et comme produit (§Module 6) ; les échelons de partenariat (AWS Select exige une poignée de collaborateurs certifiés + 3 projets lancés ; Microsoft Solutions Partner exige un score de capacité de 70/100 — les certifications de votre équipe sont littéralement des actifs commerciaux, une raison de plus de les financer) ; la promotion BOI pour une détention étrangère à 100 % de la société ; les fourchettes salariales de Bangkok (junior ฿50–75k → architecte ฿180–280k/mois) pour tarifer correctement offres et propositions ; et les chiffres de vente du moment — plus de 27 milliards de dollars d’investissements approuvés en centres de données, un mandat gouvernemental « cloud-first » et un déficit de compétences de 70 000 personnes/an que votre banc certifié existe pour combler.

Le programme en une page

Un mot de conclusion de votre professeur. Dans seize semaines, vous suivrez chaque conversation dans la salle. Ce n’est pas la ligne d’arrivée — c’est le permis de commencer. La courbe de deux ans vers un vrai jugement technique n’est pas un mur ; c’est un fossé défensif : chaque semaine que vous en accomplissez est une semaine que les fondateurs non techniques de vos concurrents n’ont pas faite. Étudiez chaque jour, consignez chaque décision, ne bluffez jamais, et embauchez des gens meilleurs que vous en faisant en sorte qu’ils soient heureux d’être venus. C’est tout le métier.

Compagnon de « The Thailand Strategic Investment (TSI) », Partie 5. Les estimations de temps de préparation aux certifications et les chronologies de leadership sont tirées des sources qui y sont citées (CBT Nuggets, StudyTech, FinOps Foundation, First Round Review, The Pragmatic Engineer).