Votre architecture cloud est en réalité un organigramme

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 !