A presentation at Asynconf in in La Défense, France by Horacio Gonzalez
Votre architecture cloud est en réalité un organigramme Horacio Gonzalez 2026-06-27
Qui sommes-nous ? Je me présente, et je présente Clever Cloud
Horacio Gonzalez @LostInBrittany Un Espagnol perdu en Bretagne
Clever Cloud From Code to Product
Le choix semblait rationnel La meilleure architecture technique…
Comment choisit-on l’architecture technique ? On compare les fonctionnalités et les contraintes ● Autoscaling, services managés, flexibilité de déploiement… ● Portabilité, coût, sécurité, performance…
Une comparaison technique sérieuse Le choix est rationnel, tout le monde est d’accord
Six mois plus tard, l’app est en production Tout va bien
Six mois plus tard, tout va bien ? Les recrues ont besoin de semaines avant de déployer en confiance
Six mois plus tard, tout va bien ? Incident : appli, plateforme, réseau ou base de données ?
Six mois plus tard, tout va bien ? Une personne est devenue la documentation humaine
Six mois plus tard, tout va bien ? Astreinte plus lourde que ce à quoi qui que ce soit s’était engagé
Six mois plus tard, tout va bien ? Plus de temps à comprendre les déploiements qu’à livrer
Ils viennent de découvrir la facture invisible La facture cloud n’était pas la seule Il y en avait une invisible : charge cognitive • responsabilité onboarding • • astreinte recrutement
Votre architecture cloud est en réalité un organigramme Chaque choix d’infrastructure est aussi un choix d’organisation
C’est quoi, ce talk ? ● Une appli, quatre modèles d’infrastructure ● Quatre organigrammes très différents ● Une matrice utilisable dès lundi ● Pas du Kubernetes-bashing, pas un pitch PaaS
La matrice qu’on fait d’habitude …et ce qui manque
Ce qu’on compare d’habitude Criterion VMs K8s PaaS Serverless Autoscaling 🤨 ✅ ✅ ✅ Pas d’hôte / OS à gérer ❌ 🤨 ✅ ✅ Base de données managée ❌ ❌ ✅ ✅ Flexibilité de déploiement ✅ ✅ 🤨 🤨 Portabilité 🤨 ✅ 🤨 ❌ Observabilité intégrée ❌ 🤨 ✅ 🤨 Écosystème ❌ ✅ ✅ ✅ Scale à zéro / paiement à l’usage ❌ ❌ 🤨 ❌ … … … … …
Incomplète Cette matrice n’est pas fausse, juste incomplète Elle vous dit ce que la plateforme sait faire… pas qui est réveillé à 3h du matin
Ce qu’elle ne vous dit pas Qui possède la production
Ce qu’elle ne vous dit pas Qui est réveillé à 3h du matin
Ce qu’elle ne vous dit pas Ce qu’une nouvelle recrue doit savoir pour livrer
Ce qu’elle ne vous dit pas Quelles compétences vous devez désormais recruter
Ce qu’elle ne vous dit pas Où les incidents rebondissent entre les équipes
Le prisme du modèle opérationnel Quatre dimensions que la matrice de fonctionnalités ignore
Les quatre dimensions Charge cognitive Frontières de responsabilité Ce qu’un dev doit savoir pour livrer en sécurité Où l’appli s’arrête, où la plateforme commence Modèle d’astreinte Personnes et résilience Qui est réveillé, et pour quoi Recruter, onboarder, et bus factor
Une seule application Délibérément banale, la seule chose qui ne changera pas
L’application ennuyeuse 6 développeurs · 1 tech lead · pas de SRE dédié · livre régulièrement
La constante L’application ne change pas, l’organigramme, si
Une appli, quatre organigrammes Même appli, même besoin métier, quatre équipes
VMs auto-gérées L’Historien·ne de la prod : le savoir concentré dans une seule personne
VMs auto-gérées Ce qui devient plus facile ● ● ● ● Contrôle direct Des primitives compréhensibles Facile à démarrer, petits systèmes Convient au legacy ou aux contraintes spécifiques Ce qui devient un boulot à faire ● Patching, provisioning, pare-feu ● Sauvegardes et monitoring ● Scripts de déploiement, réponse aux incidents ● Docs en retard sur la réalité
VMs auto-gérées Vous n’avez peut-être pas d’équipe plateforme… mais vous avez une personne plateforme
Kubernetes managé L’équipe plateforme accidentelle : née sans mandat
Managed Kubernetes Ce qui devient plus facile ● ● ● ● Orchestration standard Écosystème riche, portabilité Des primitives puissantes Une base pour construire une plateforme Ce qui devient un boulot à faire ● Upgrades du cluster, RBAC, réseau ● Capacity planning, observabilité ● Golden paths, expérience développeur ● Documentation de la plateforme
Managed Kubernetes Vous avez acheté un kit de construction, pas un produit… quelqu’un doit assumer la construction
PaaS Pas de héros caché : le fournisseur est la personne plateforme que vous n’avez pas eu à recruter
PaaS Ce qui devient plus facile Ce qui devient un boulot à faire ● Onboarding et déploiements rapides ● Autonomie des développeurs ● Responsabilité de la prod par une petite équipe ● Se concentrer sur le produit ● Comprendre les contraintes de la plateforme ● Le modèle de scaling et de sauvegarde ● Là où l’abstraction fuit ● Mais bien moins de gens ont à le faire
PaaS Un bon PaaS permet à une équipe produit d’opérer la production sans devoir d’abord devenir une équipe plateforme
Serverless Le Détective des systèmes distribués : la responsabilité se déplace vers l’architecture, l’IAM, le tracing
Serverless Ce qui devient plus facile ● ● ● ● Scaling en pic, pas de serveurs Charges event-driven Moins de capacité au repos Expérimentation rapide Ce qui devient un boulot à faire ● ● ● ● Limites du fournisseur et IAM Retries et idempotence Tracing à travers les services Prédictibilité des coûts
Serverless Le serverless retire les serveurs de l’organigramme, mais pas les opérations : Il transforme les problèmes opérationnels en problèmes d’architecture
Où va la complexité ? Le motif commun aux quatre
Chaque plateforme déplace la complexité quelque part Model Where the complexity goes VMs auto-gérées dans les gens et les scripts Kubernetes dans la couche plateforme PaaS dans le contrat du fournisseur Serverless dans l’architecture distribuée
Où elle vit La question n’a jamais été quel modèle a de la complexité, ils en ont tous… C’est où vous voulez que cette complexité vive
Et l’IA dans tout ça ? L’IA change qui fait le travail, pas qui en est responsable
La matrice que vous devriez vraiment faire Évaluez le modèle opérationnel, pas les fonctionnalités
La matrice du modèle opérationnel Question Measures Qui est réveillé à 3h du matin ? Astreinte / responsabilité Que doit savoir chaque dev pour déployer ? Charge cognitive Combien de temps avant qu’une recrue livre ? Personnes et résilience Quelle expertise devons-nous recruter ? Personnes et résilience Et si l’expert plateforme part ? Personnes et résilience Produit ou plateforme ? Orientation stratégique Posséder la complexité ou la louer ? Le vrai arbitrage
La vraie question Ne demandez pas si la plateforme peut faire tourner votre application, demandez quelle équipe vous devriez devenir pour bien l’opérer
À choisir quand VMs auto-gérées ● ● ● Contrôle, système petit ou stable Ops solides Pas de goulot unique PaaS ● ● ● ● Le produit avant le contrôle de la plateforme Petite équipe Onboarding rapide Les contraintes conviennent Kubernetes ● ● ● Vous avez besoin d’une plateforme Plusieurs équipes Capacité à investir dans le platform engineering Serverless ● ● ● Event-driven ou en pics L’équipe maîtrise les systèmes distribués Investir dans l’IAM et le tracing
Trois choses à faire la semaine prochaine ● Auditez les réveils à 3h du matin du mois dernier : structurels ou au niveau appli ? ● Mesurez le temps jusqu’au premier commit de votre dernière recrue ● Exigez un organigramme à côté de chaque diagramme d’architecture
Rendez-le visible Chaque diagramme d’architecture cache un organigramme Rendez-le visible avant que la production ne s’en charge
C’est tout, les amis ! Merci à toutes et à tous !
Chaque choix d’infrastructure est aussi un choix organisationnel. Quand votre équipe choisit Kubernetes, un PaaS, du serverless ou des VMs auto-gérées, elle ne choisit pas seulement une cible de déploiement. Elle choisit aussi qui sera réveillé à 3h du matin, combien de temps il faudra à une nouvelle recrue pour livrer en production, où se situent les frontières de responsabilité, et quels profils il faudra recruter.
Pourtant, on continue à évaluer l’infrastructure avec des matrices de fonctionnalités plutôt qu’avec des matrices de modèle opérationnel. On compare l’autoscaling, les services managés et la flexibilité de déploiement, en ignorant la charge cognitive, la structure de l’équipe et les astreintes que chaque choix implique.
Dans ce talk, je prendrai une application réaliste et je montrerai comment son déploiement sur quatre modèles d’infrastructure différents produit quatre organigrammes radicalement différents : des rôles différents, des modes de défaillance différents, des parcours d’intégration différents, et des coûts qui n’apparaissent jamais sur la facture cloud. Je proposerai ensuite un cadre pratique pour prendre des décisions d’infrastructure fondées sur l’équipe et le modèle opérationnel que vous voulez réellement, et pas seulement sur les fonctionnalités de la plateforme.
