# data[].attributes.title
Votre architecture cloud est en réalité un organigramme

# data[].attributes.blurb.html
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.

# data[].attributes.slidedeck.data[].slides[].desc.html
Votre architecture cloud est en réalité un organigramme Horacio Gonzalez 2026-06-27

# data[].attributes.slidedeck.data[].slides[].desc.html
Qui sommes-nous ? Je me présente, et je présente Clever Cloud

# data[].attributes.slidedeck.data[].slides[].desc.html
Horacio Gonzalez @LostInBrittany Un Espagnol perdu en Bretagne

# data[].attributes.slidedeck.data[].slides[].desc.html
Clever Cloud From Code to Product

# data[].attributes.slidedeck.data[].slides[].desc.html
Le choix semblait rationnel La meilleure architecture technique…

# data[].attributes.slidedeck.data[].slides[].desc.html
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…

# data[].attributes.slidedeck.data[].slides[].desc.html
Une comparaison technique sérieuse Le choix est rationnel, tout le monde est d’accord

# data[].attributes.slidedeck.data[].slides[].desc.html
Six mois plus tard, l’app est en production Tout va bien

# data[].attributes.slidedeck.data[].slides[].desc.html
Six mois plus tard, tout va bien ? Les recrues ont besoin de semaines avant de déployer en confiance

# data[].attributes.slidedeck.data[].slides[].desc.html
Six mois plus tard, tout va bien ? Incident : appli, plateforme, réseau ou base de données ?

# data[].attributes.slidedeck.data[].slides[].desc.html
Six mois plus tard, tout va bien ? Une personne est devenue la documentation humaine

# data[].attributes.slidedeck.data[].slides[].desc.html
Six mois plus tard, tout va bien ? Astreinte plus lourde que ce à quoi qui que ce soit s’était engagé

# data[].attributes.slidedeck.data[].slides[].desc.html
Six mois plus tard, tout va bien ? Plus de temps à comprendre les déploiements qu’à livrer

# data[].attributes.slidedeck.data[].slides[].desc.html
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

# data[].attributes.slidedeck.data[].slides[].desc.html
Votre architecture cloud est en réalité un organigramme Chaque choix d’infrastructure est aussi un choix d’organisation

# data[].attributes.slidedeck.data[].slides[].desc.html
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

# data[].attributes.slidedeck.data[].slides[].desc.html
La matrice qu’on fait d’habitude …et ce qui manque

# data[].attributes.slidedeck.data[].slides[].desc.html
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 ❌ ❌ 🤨 ❌ … … … … …

# data[].attributes.slidedeck.data[].slides[].desc.html
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

# data[].attributes.slidedeck.data[].slides[].desc.html
Ce qu’elle ne vous dit pas Qui possède la production

# data[].attributes.slidedeck.data[].slides[].desc.html
Ce qu’elle ne vous dit pas Qui est réveillé à 3h du matin

# data[].attributes.slidedeck.data[].slides[].desc.html
Ce qu’elle ne vous dit pas Ce qu’une nouvelle recrue doit savoir pour livrer

# data[].attributes.slidedeck.data[].slides[].desc.html
Ce qu’elle ne vous dit pas Quelles compétences vous devez désormais recruter

# data[].attributes.slidedeck.data[].slides[].desc.html
Ce qu’elle ne vous dit pas Où les incidents rebondissent entre les équipes

# data[].attributes.slidedeck.data[].slides[].desc.html
Le prisme du modèle opérationnel Quatre dimensions que la matrice de fonctionnalités ignore

# data[].attributes.slidedeck.data[].slides[].desc.html
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

# data[].attributes.slidedeck.data[].slides[].desc.html
Une seule application Délibérément banale, la seule chose qui ne changera pas

# data[].attributes.slidedeck.data[].slides[].desc.html
L’application ennuyeuse 6 développeurs · 1 tech lead · pas de SRE dédié · livre régulièrement

# data[].attributes.slidedeck.data[].slides[].desc.html
La constante L’application ne change pas, l’organigramme, si

# data[].attributes.slidedeck.data[].slides[].desc.html
Une appli, quatre organigrammes Même appli, même besoin métier, quatre équipes

# data[].attributes.slidedeck.data[].slides[].desc.html
VMs auto-gérées L’Historien·ne de la prod : le savoir concentré dans une seule personne

# data[].attributes.slidedeck.data[].slides[].desc.html
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é

# data[].attributes.slidedeck.data[].slides[].desc.html
VMs auto-gérées Vous n’avez peut-être pas d’équipe plateforme… mais vous avez une personne plateforme

# data[].attributes.slidedeck.data[].slides[].desc.html
Kubernetes managé L’équipe plateforme accidentelle : née sans mandat

# data[].attributes.slidedeck.data[].slides[].desc.html
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

# data[].attributes.slidedeck.data[].slides[].desc.html
Managed Kubernetes Vous avez acheté un kit de construction, pas un produit… quelqu’un doit assumer la construction

# data[].attributes.slidedeck.data[].slides[].desc.html
PaaS Pas de héros caché : le fournisseur est la personne plateforme que vous n’avez pas eu à recruter

# data[].attributes.slidedeck.data[].slides[].desc.html
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

# data[].attributes.slidedeck.data[].slides[].desc.html
PaaS Un bon PaaS permet à une équipe produit d’opérer la production sans devoir d’abord devenir une équipe plateforme

# data[].attributes.slidedeck.data[].slides[].desc.html
Serverless Le Détective des systèmes distribués : la responsabilité se déplace vers l’architecture, l’IAM, le tracing

# data[].attributes.slidedeck.data[].slides[].desc.html
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

# data[].attributes.slidedeck.data[].slides[].desc.html
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

# data[].attributes.slidedeck.data[].slides[].desc.html
Où va la complexité ? Le motif commun aux quatre

# data[].attributes.slidedeck.data[].slides[].desc.html
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

# data[].attributes.slidedeck.data[].slides[].desc.html
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

# data[].attributes.slidedeck.data[].slides[].desc.html
Et l’IA dans tout ça ? L’IA change qui fait le travail, pas qui en est responsable

# data[].attributes.slidedeck.data[].slides[].desc.html
La matrice que vous devriez vraiment faire Évaluez le modèle opérationnel, pas les fonctionnalités

# data[].attributes.slidedeck.data[].slides[].desc.html
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

# data[].attributes.slidedeck.data[].slides[].desc.html
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

# data[].attributes.slidedeck.data[].slides[].desc.html
À 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

# data[].attributes.slidedeck.data[].slides[].desc.html
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

# data[].attributes.slidedeck.data[].slides[].desc.html
Rendez-le visible Chaque diagramme d’architecture cache un organigramme Rendez-le visible avant que la production ne s’en charge

# data[].attributes.slidedeck.data[].slides[].desc.html
C’est tout, les amis ! Merci à toutes et à tous !