Comprenez ce que Werner Vogels entendait par « Vous le construisez, vous l'exploitez » et comment l’appliquer : propriété, on‑call, SLO, gestion des incidents et livraisons plus sûres.
« Vous le construisez, vous l'exploitez » reste une phrase marquante parce qu'elle est directe. Il ne s'agit pas de posters de motivation ou de « devenir plus DevOps ». C’est une déclaration claire sur la responsabilité : l’équipe qui met un service en production reste responsable de son comportement en production.
Concrètement, cela signifie que la même équipe produit qui conçoit les fonctionnalités et écrit le code :
Cela ne veut pas dire que tout le monde devient expert en infrastructure du jour au lendemain. Cela veut dire que la boucle de rétroaction est réelle : si vous publiez quelque chose qui augmente les pannes, le bruit des pages ou la souffrance client, votre équipe le ressent directement — et apprend vite.
Cette philosophie est facile à répéter et difficile à mettre en œuvre à moins d’en faire un modèle opérationnel avec des attentes explicites. « Exploiter » inclut généralement d'être on‑call (sous une forme ou une autre), d'assumer la réponse aux incidents, d'écrire des runbooks, de maintenir des tableaux de bord et d’améliorer continuellement le service.
Cela implique aussi des contraintes : vous ne pouvez pas demander aux équipes d’« exploiter » sans leur fournir les outils, les accès et l’autorité pour corriger les problèmes — et le temps dans leur feuille de route pour faire le travail.
Avant « Vous le construisez, vous l'exploitez », beaucoup d’entreprises organisaient le travail comme une course de relais : les devs écrivent le code puis le « jettent par‑dessus la clôture » à une équipe opérations pour le déployer et le maintenir.
Ce transfert résolvait un problème à court terme — quelqu’un d’expérimenté surveillait la production — mais il en créait de plus grands.
Quand une équipe ops distincte possède la production, les développeurs apprennent souvent les problèmes tard (ou pas du tout). Un bug peut apparaître sous forme d’un ticket vague quelques jours plus tard : « le service est lent » ou « CPU élevé ». À ce moment-là, le contexte manque, les logs ont été tournés et les auteurs du changement sont passés à autre chose.
Les transferts embrouillent aussi la propriété. Si une panne survient, le dev peut supposer « ops va s’en occuper », tandis que ops pense « dev a déployé quelque chose de risqué ». Le résultat : délai de résolution plus long, modes de défaillance répétés et une culture où les équipes optimisent localement plutôt que pour l’expérience client.
« Vous le construisez, vous l'exploitez » resserre la boucle. La même équipe qui publie une modification est responsable de son comportement en production. Cela pousse des améliorations pratiques en amont : alertes plus claires, déploiements plus sûrs, meilleurs tableaux de bord et code plus facile à exploiter.
Paradoxalement, cela conduit souvent à une livraison plus rapide. Quand les équipes font confiance à leur processus de release et comprennent le comportement en production, elles peuvent livrer des changements plus petits et plus fréquents — réduisant le rayon d’impact des erreurs et facilitant le diagnostic des problèmes.
Toutes les organisations n’ont pas les mêmes effectifs, contraintes de conformité ou systèmes hérités. La philosophie est une direction, pas un interrupteur. Beaucoup d’équipes l’adoptent progressivement — en commençant par un on‑call partagé, une meilleure observabilité et des frontières de service plus claires — avant de prendre une propriété complète de bout en bout.
Werner Vogels, CTO d’Amazon, a popularisé l’expression « You build it, you run it » en décrivant comment Amazon (et plus tard AWS) voulait que les équipes pensent le logiciel : pas comme un projet à transférer, mais comme un service à exploiter.
Le changement clé était autant psychologique que technique. Quand une équipe sait qu’elle sera pagée en cas de défaillance, les décisions de conception changent. On prête attention aux choix par défaut sensés, à des alertes claires, à une dégradation élégante et à des voies de déploiement réversibles. En d’autres termes, construire inclut la planification des parties désordonnées de la vie réelle.
La pensée « service » de l’ère AWS a rendu la fiabilité et la vitesse non négociables. Les clients cloud attendent des API disponibles 24/7 et des améliorations continues — pas des vagues de « grosses releases » trimestrielles.
Cette pression a favorisé :
Cette philosophie recoupe le mouvement DevOps : rapprocher dev et ops, réduire les transferts et faire de la disponibilité, latence et charge de support des critères du développement. Elle s’accorde aussi avec l’idée d’équipes autonomes capables de livrer indépendamment.
Il est tentant de traiter l’approche d’Amazon comme un modèle exact à reproduire. Mais « Vous le construisez, vous l'exploitez » est plutôt une direction que d’un organigramme strict. La taille de votre équipe, les contraintes réglementaires, la maturité du produit et les exigences de disponibilité peuvent nécessiter des adaptations — rotations on‑call partagées, support plateforme ou adoption progressive.
Si vous voulez une méthode pratique pour traduire l’état d’esprit en actions, passez à /blog/how-to-adopt-you-build-it-you-run-it-step-by-step.
« Vous le construisez, vous l'exploitez » est surtout une affirmation de propriété. Si votre équipe met un service en production, elle est responsable de son comportement dans le monde réel — pas seulement qu’il passe les tests le jour de la release.
Exploiter un service signifie se soucier des résultats de bout en bout :
En semaine normale, « exploiter » relève moins de l’héroïsme que des opérations de routine :
Ce modèle fonctionne uniquement si responsabilité signifie « nous prenons en charge la correction », pas « on cherche une personne à punir ». Quand quelque chose casse, l’objectif est de comprendre ce qui dans le système a permis à l’erreur d’atteindre la production — alertes manquantes, limites floues, déploiements risqués — et d’améliorer ces conditions.
La propriété devient confuse quand les services sont flous. Définissez les frontières du service (ce qu’il fait, dont il dépend, ce qu’il promet) et assignez une équipe propriétaire nommée. Cette clarté réduit les transferts, accélère la réponse aux incidents et rend les priorités évidentes quand fiabilité et fonctionnalités entrent en concurrence.
Le on‑call est central à « Vous le construisez, vous l'exploitez » car il ferme la boucle de rétroaction. Quand la même équipe qui déploie ressent aussi l’impact opérationnel (pics de latence, déploiements échoués, plaintes clients), les priorités se clarifient : la fiabilité cesse d’être « le problème de quelqu’un d’autre » et le moyen le plus rapide de livrer plus est souvent de calmer le système.
Un on‑call sain tient surtout de la prévisibilité et du soutien.
Définissez des niveaux de sévérité pour ne pas pager pour chaque imperfection.
Règle simple : si réveiller quelqu’un ne changera pas l’issue, c’est un ticket, pas une page.
Le on‑call n’est pas une punition ; c’est un signal. Chaque alerte bruyante, défaillance répétée ou correction manuelle doit revenir sous forme de travail d’ingénierie : meilleures alertes, automatisation, déploiements plus sûrs et changements de système qui suppriment le besoin de pager.
Si « vous l’exploitez » est réel, les équipes ont besoin d’un langage partagé pour parler de fiabilité sans transformer chaque discussion en opinion. C’est le rôle des SLIs, SLOs et budgets d’erreur : cibles claires et compromis justes entre vitesse et stabilité.
Mémo utile : SLI = métrique, SLO = objectif, SLA = engagement externe.
Des SLIs utiles sont spécifiques et liés à l’expérience utilisateur, par exemple :
Un budget d’erreur est la quantité de « mauvais » admissible tout en respectant le SLO (par ex. SLO 99,9 % → budget d’erreur mensuel 0,1 % de temps d’indisponibilité).
Quand le service est sain et vous êtes dans le budget, vous pouvez prendre plus de risques (features, expériences). Quand vous brûlez le budget trop vite, le travail de fiabilité devient prioritaire.
Les SLO font de la fiabilité une entrée de planification. Si votre budget est bas, le sprint suivant peut mettre l’accent sur le rate limiting, des déploiements plus sûrs ou la correction de dépendances instables — car manquer le SLO a un coût clair. Si le budget est confortable, vous pouvez prioriser le travail produit sans craindre que « ops s’en sorte ».
« Vous le construisez, vous l'exploitez » ne fonctionne que si déployer en production devient routinier — pas un événement à forts enjeux. L’objectif est de réduire l’incertitude avant le lancement et de limiter le rayon d’impact après.
Avant qu’un service soit considéré « prêt », les équipes ont typiquement besoin de quelques bases opérationnelles :
Plutôt que de livrer tout le monde en même temps, la livraison progressive limite l’impact :
Si vous standardisez le rollback, traitez‑le comme une capacité de premier ordre : plus vite vous pouvez revenir en arrière en toute sûreté, plus « vous l’exploitez » devient réaliste.
Deux tests réduisent les « inconnues inconnues » :
Gardez‑la légère : une page dans le repo ou le template de ticket (par ex. « Observabilité », « Prêt on‑call », « Protection des données », « Plan de rollback », « Capacité testée », « Runbooks liés »). Faire du statut « pas prêt » une normalité vaut mieux que l’apprendre en production.
Les incidents sont l’endroit où « vous l’exploitez » devient concret : un service se dégrade, les clients le remarquent et l’équipe doit répondre vite et clairement. L’objectif n’est pas l’héroïsme, mais un workflow reproductible qui réduit l’impact et produit des améliorations.
La plupart des équipes convergent vers les mêmes phases :
Si vous voulez un template pratique pour ce flux, gardez une checklist légère à portée de main (voir /blog/incident-response-checklist).
Un postmortem sans blâme ne signifie pas « personne n’a fait d’erreur ». Cela signifie qu’on se concentre sur comment le système et les processus ont laissé l’erreur atteindre la production, pas sur l’humiliation d’individus. C’est ce qui encourage le partage rapide des informations, essentiel à l’apprentissage.
Documentez :
Les bons postmortems se terminent par des suivis concrets, souvent dans quatre catégories : améliorations d’outillage (meilleures alerts/dashboards), tests (régressions et cas limites), automatisation (déploiement/rollback plus sûr, garde‑fous) et documentation (runbooks, étapes opérationnelles plus claires). Assignez un propriétaire et une date — sinon l’apprentissage reste théorique.
L’outillage est le levier qui rend « Vous le construisez, vous l'exploitez » durable — mais il ne remplace pas la vraie propriété. Si une équipe traite l’opération comme « le problème de quelqu’un d’autre », le plus beau tableau de bord ne fera que documenter le chaos. Les bons outils réduisent les frictions : ils rendent la bonne chose (observer, répondre, apprendre) plus facile que la mauvaise (deviner, blâmer, ignorer).
Au minimum, les propriétaires de services ont besoin d’un moyen cohérent pour voir ce que leur logiciel fait en production et agir vite :
Si votre story de monitoring est fragmentée, les équipes passent plus de temps à chercher qu’à réparer. Une approche unifiée d’observabilité aide ; voir /product/observability.
À mesure que l’organisation grandit, « qui possède ceci ? » devient un risque de fiabilité. Un catalogue de services (ou portail développeur interne) résout cela en centralisant la propriété et le contexte opérationnel : nom de l’équipe, rotation on‑call, chemin d’escalade, runbooks, dépendances et liens vers dashboards.
La clé est des métadonnées de propriété à jour. Faites‑en partie du workflow : les nouveaux services ne vont pas en prod sans propriétaire, et les changements de propriétaire sont traités comme des changements de code (revus, tracés).
Les meilleurs dispositifs incitent aux bons comportements : templates de runbook, alerts automatisées liées aux SLO, dashboards répondant en quelques secondes à « les utilisateurs sont‑ils impactés ? ». Mais le système humain compte toujours — les équipes ont besoin de temps pour maintenir ces outils, nettoyer les alertes et améliorer continuellement leur façon d’exploiter le service.
Les équipes plateforme rendent la vie de « Vous le construisez, vous l'exploitez » plus supportable. Leur job n’est pas d’exploiter la production pour tout le monde — c’est de fournir un chemin bien éclairé (les « paved roads ») pour que les équipes produit puissent posséder leurs services sans réinventer l’exploitation à chaque sprint.
Une bonne plateforme offre des défauts sûrs et faciles à adopter :
Les garde‑fous doivent empêcher les comportements risqués sans bloquer la livraison. Pensez « sécurisé par défaut » plutôt que « ouvrez un ticket et attendez ».
Les équipes plateforme peuvent exploiter des services partagés — sans pour autant prendre la propriété des services produit.
La frontière est simple : l’équipe plateforme possède la disponibilité et le support de la plateforme ; les équipes produit possèdent l’usage et le comportement de leurs services.
Quand les équipes n’ont pas à devenir expertes en CI/CD, auth ou secrets dès le jour 1, elles peuvent se concentrer sur le comportement du service et l’impact utilisateur.
Exemples qui éliminent les tâches fastidieuses :
Le résultat : livraison plus rapide avec moins de « snowflakes » opératoires custom, tout en maintenant la promesse centrale : l’équipe qui construit le service l’exploite toujours.
« Vous le construisez, vous l'exploitez » peut améliorer la fiabilité et la vitesse — mais seulement si l’organisation change les conditions autour de l’équipe. Beaucoup d’échecs ressemblent à une adoption du slogan sans les habitudes de soutien.
Quelques schémas reviennent souvent :
Certains environnements exigent une approche sur mesure :
Cette philosophie échoue rapidement quand le travail de fiabilité est traité comme du « supplément ». La direction doit explicitement réserver de la capacité pour :
Sans cette protection, le on‑call devient une taxe — plutôt qu’une boucle de rétroaction qui améliore le système.
La mise en œuvre marche mieux en phases, pas en annonce générale. Commencez petit, rendez la propriété visible, puis étendez.
Choisissez un service unique, bien délimité (idéalement avec des utilisateurs clairs et un risque gérable).
Définissez :
L’important : l’équipe qui publie les changements possède aussi les résultats opérationnels du service.
Avant d’étendre à d’autres services, assurez‑vous que l’équipe pilote peut opérer sans héroïsme :
Utilisez un petit ensemble d’indicateurs montrant si la propriété améliore livraison et stabilité :
Si vous adoptez « vous le construisez, vous l'exploitez » tout en cherchant à accélérer la livraison, le goulot d’étranglement est souvent le même : passer d’idée → service prêt pour la production avec propriété claire et story de rollback sûre.
Koder.ai est une plateforme vibe‑coding qui aide les équipes à construire des apps web, backend et mobiles via une interface chat (React web, Go + PostgreSQL backend, Flutter mobile). Pour les équipes qui renforcent la propriété de service, quelques fonctionnalités s’alignent naturellement sur le modèle opérationnel :
Choisissez votre service pilote cette semaine et planifiez un kickoff de 60 minutes pour définir le premier SLO, la rotation on‑call et les propriétaires de runbook. Si vous évaluez des outils pour supporter ce modèle (shipping, rollback et workflows autour de la propriété), voyez /pricing pour les offres Koder.ai (free, pro, business, enterprise) et options d’hébergement, déploiement et domaines personnalisés.
Cela signifie que l’équipe qui conçoit, construit et déploie un service s’occupe aussi de ce qui se passe après la mise en production : surveillance, réponse on‑call, actions après incident et améliorations de la fiabilité.
C’est un modèle de responsabilité (propriété claire), pas un choix d’outil ni un simple changement de titre.
Cela ne veut pas dire que chaque ingénieur doit devenir un spécialiste infrastructure à temps plein.
Cela signifie :
Avec une équipe ops séparée, le retour d’information est retardé et la responsabilité se dilue : les développeurs peuvent ne pas ressentir la douleur en production, et l’ops manquer du contexte des changements récents.
La propriété de bout en bout améliore généralement :
« L’exploiter » inclut généralement :
Commencez par des choix humains par défaut :
Un bon système on‑call vise à réduire le volume d’alertes le mois suivant, pas à normaliser le mode héroïque.
Règle simple : si réveiller quelqu’un ne changera pas le résultat, c’est un ticket, pas une page.
Pratiquement :
Ils fournissent des cibles mesurables pour parler de fiabilité sans se perdre en opinions :
Si le budget s’épuise rapidement, priorisez le travail de fiabilité ; s’il reste confortable, prenez plus de risques de livraison.
Pratiques de sortie en production qui réduisent l’incertitude et la portée d’impact :
Gérez les incidents avec un flux répétable :
Rédigez ensuite un postmortem sans blâme axé sur les lacunes du système et des processus, avec des actions concrètes :
Un checklist léger comme /blog/incident-response-checklist aide à standardiser le travail.
L’équipe plateforme doit fournir des « paved roads » (modèles, CI/CD, garde‑fous, services partagés) tout en laissant la responsabilité produit :
La frontière pratique : plateforme = services partagés et outils ; produit = comportement et cible de fiabilité du service.
