Demandez à un DSI combien lui coûte son Run. Il vous citera quatre lignes : sa facture cloud, son contrat d’infogérance, peut-être ses licences supervision et l’équipe d’opérations. Quatre lignes lisibles, qui passent en comité budgétaire.
Et quatre lignes qui représentent à peine la moitié du coût réel.
Le vrai coût du Run se cache dans des postes que personne ne consolide : le temps de vos équipes absorbé par l’opérationnel, les astreintes, le turnover des SRE, les pertes liées aux incidents, la dette technique et — surtout — l’innovation qui n’a jamais lieu.
Cet article propose une grille à 9 postes pour faire ce calcul. Et montre, poste par poste, comment le Run as Code agit sur chacun. Pas pour faire peur — pour donner aux DSI la conversation qu’ils n’ont jamais eue avec leur direction financière.
Ce qui se mesure facilement — et ce qui ne se mesure pas
Les quatre premiers postes du Run sont connus de tout DSI : ils figurent dans le budget IT, sont suivis chaque mois, et donnent l’impression qu’on maîtrise. C’est précisément ce qui pose problème : ils créent une illusion de visibilité. Tout ce qui pèse réellement sur l’organisation se trouve dans les cinq postes suivants, et reste invisible.
Le temps technique absorbé par le Run non planifié. Vos développeurs, vos architectes, vos chefs de projet passent une part significative de leur temps à débugger des déploiements, comprendre pourquoi un service a redémarré, animer des post-mortems. Ce travail s’appelle toil dans le vocabulaire SRE de Google : le travail lié à la production qui est manuel, répétitif, automatisable, tactique, sans valeur durable, et qui croît linéairement avec la taille du service. Google s’impose une limite stricte : les équipes SRE doivent maintenir leur toil sous les 50 % de leur temps. Au-delà, l’organisation paie deux fois — en heures consommées et en projets qui n’avancent pas.
Les astreintes. Leur coût direct est dans la paie. Leur coût indirect — fatigue, baisse de productivité du lendemain, usure des équipes — n’est nulle part. Mais il est bien réel.
Le turnover des profils SRE/DevOps. Quand le quotidien est dominé par le toil, les meilleurs profils partent. Chaque départ déclenche un coût complet de remplacement : recrutement, transition, perte de savoir non documenté, dégradation des SLA pendant plusieurs mois.
Les pertes liées aux indisponibilités. C’est devenu un sujet de direction générale.
Le coût agrégé de l’indisponibilité non planifiée pour les Global 2000 a atteint 600 milliards de dollars par an — une augmentation de 50 % en deux ans. Le coût moyen du downtime atteint 15 000 dollars par minute, avec une chute de cours moyenne de 3,4 % après un événement majeur. — Hidden Costs of Downtime, Splunk / Cisco, mai 2026
Vos chiffres ne sont pas ceux du Global 2000 — mais l’écart entre le coût réel et ce que vous mesurez aujourd’hui est probablement du même ordre de grandeur.
La dette technique et l’innovation perdue. Le poste le plus lourd, et le plus difficile à chiffrer. Chaque heure consacrée à entretenir l’existant est une heure qui ne construit pas votre différence. Les projets qui n’avancent pas, les expérimentations qui n’ont jamais lieu, les compétences qu’on ne développe pas. Aucune facture n’enregistre ce coût. Il est pourtant celui qui décide de votre trajectoire.
La grille de calcul du TCO Run
Voici la grille des neuf postes qui composent le coût complet du Run. Quatre sont visibles dans votre budget, cinq ne le sont nulle part — et c’est cette deuxième moitié qui rend la conversation budgétaire intéressante.
L’exercice prend une heure : posez chaque ligne, collectez la donnée, additionnez. Vous obtiendrez un TCO Run que ni votre contrôle de gestion ni votre direction financière n’ont jamais consolidé. C’est le point de départ de toute discussion sérieuse sur l’industrialisation de votre exploitation.
| Catégorie | Poste | Donnée à collecter | Type |
|---|---|---|---|
| Coûts visibles | Cloud & hébergement | Facture annuelle moyenne | Direct |
| Coûts visibles | Infogérance & prestations | Contrats + jours-homme + avenants | Direct |
| Coûts visibles | Licences (supervision, ITSM, sauvegarde, sécurité) | Renouvellements annuels | Direct |
| Coûts visibles | Salaires équipes RUN dédiées | ETP × coût chargé annuel | Direct |
| Coûts humains cachés | Temps technique absorbé par le Run non planifié | % temps × coût chargé des profils concernés | Estimation |
| Coûts humains cachés | Astreintes directes et indirectes | Primes + rappels + impact post-astreinte | Estimation |
| Coûts humains cachés | Turnover SRE / DevOps | Départs × coût complet de remplacement | Estimation |
| Coûts incidents | Pertes liées aux indisponibilités | Heures d’indispo × coût horaire business | Estimation |
| Coût d’opportunité | Dette technique et innovation perdue | Projets retardés, risques accumulés, valeur non créée | Estimation |
Comment le Run as Code agit, poste par poste
Sur les coûts cloud. Le rapport State of FinOps 2025 est clair : l’optimisation des workloads et la réduction du gaspillage figurent en tête des priorités, avec 50 % des praticiens FinOps qui la citent comme leur priorité principale. Le Run as Code intègre nativement cette discipline : rightsizing automatisé, alertes sur dérive, suppression des ressources oubliées. La baisse de facture est mesurable dès les premiers mois.
Sur l’infogérance et les prestations. Le Run as Code ne supprime pas le partenaire — il change ce qu’on attend de lui. La prestation se déplace de l’entretien manuel quotidien vers l’installation et l’amélioration continue du dispositif. Le budget se réoriente vers de la valeur.
Sur les licences. Une stack open source unifiée (Prometheus, Grafana, Loki, GitLab, Ansible, Terraform) remplace souvent plusieurs abonnements empilés. L’économie dépend du contexte mais est réelle.
Sur les salaires Run. L’objectif n’est pas la réduction d’effectifs, mais la réorientation. Les équipes Run montent en compétence sur l’automatisation, l’IA et l’architecture — des compétences à plus forte valeur, qui font aussi mieux rester les profils.
Sur le temps technique absorbé. C’est là que les gains sont les plus visibles. Sur les alertes courantes, la remédiation se déclenche sans intervention humaine. L’IA accélère le diagnostic des incidents restants : là où une investigation prenait des heures, elle prend des minutes. Le temps rendu aux équipes est massif.
Sur les astreintes. L’auto-remédiation traite la majorité des incidents nocturnes sans réveil. Les astreintes redeviennent ce qu’elles sont censées être — une couverture, pas une charge permanente.
Sur le turnover. Effet structurel, plus lent à mesurer mais décisif. Quand le métier redevient intéressant — concevoir, automatiser, innover — les profils rares restent.
Sur les incidents business. Détection prédictive, MTTR divisé, PRA testé régulièrement. La disponibilité réelle monte. C’est aussi la métrique la plus reconnue par la finance : elle se mesure directement en chiffre d’affaires préservé.
Sur l’innovation perdue. Effet long, mais le plus stratégique. Le cadre des DORA Metrics — devenu la référence du secteur — le formalise bien : fréquence de déploiement, délai de mise en production, taux d’échec de changement, temps de récupération. Un Run automatisé améliore les quatre simultanément. Les heures rendues aux équipes deviennent des projets qui avancent.
L’impact, en ordres de grandeur
Pour passer du calcul théorique au business case, voici les gains observés une fois le Run as Code en place — poste caché par poste caché. L’ampleur réelle dépend de votre maturité Run de départ : un Run très manuel verra des effets plus marqués et plus rapides qu’un Run déjà partiellement industrialisé.
Ces chiffres sont des repères pour calibrer votre business case, pas un engagement contractuel.
| Poste | Impact Run as Code |
|---|---|
| Temps ingénieur absorbé par le Run | −60 % — automatisation des tâches répétitives |
| Astreintes | −70 % — détection proactive, runbooks automatisés |
| Turnover SRE | −40 % — travail plus stimulant, moins de “pompier” |
| Pertes incidents | −75 % — MTTR divisé par 4 en moyenne |
| Dette technique | −50 % — la codification force le traitement |
| Audits de conformité | −80 % — conformité continue, rapport automatisé |
Le retour sur investissement est mesurable — et défendable devant un CFO avec ces chiffres.
La conversation qui débloque
L’industrialisation du Run se présente toujours, en comité budgétaire, comme un coût supplémentaire face à une ligne existante. La direction financière voit “encore une dépense IT” — alors que c’est un changement de modèle qui se propose.
Argumenter sur la ligne cloud ou la ligne infogérance ne suffit pas : on défend la moitié visible du problème. La conversation qui débloque ressemble plutôt à :
“Voici ce que coûte vraiment notre Run aujourd’hui — pas la ligne cloud, le coût complet. Voici comment le Run as Code agit sur chacun des postes. Voici le delta sur 24 mois.”
Avec la grille des 9 postes en main, le cadre du débat change. On ne demande pas un investissement supplémentaire — on propose une réallocation d’un coût existant, mal mesuré jusqu’ici, vers un modèle plus efficace et plus stratégique.
Pour aller plus loin
L’audit Run gratuit que nous proposons commence par ce calcul : nous reconstruisons avec vous le TCO réel de votre exploitation sur les 9 postes. Vous repartez avec un chiffre que vous n’aviez probablement jamais vu — et une feuille de route pour le faire baisser, poste par poste, sur 3, 6 et 12 mois.
Réserver votre audit Run gratuit →
Sources
- Google SRE — Eliminating Toil
- DORA / Google Cloud — DORA Metrics Guide
- FinOps Foundation — State of FinOps 2025
- Splunk / Cisco — The Hidden Costs of Downtime 2026
Cloud Inspire — Le Build est devenu facile. Le Run reste un métier. Exploitation opérée depuis la France et la Côte d’Ivoire. Stack open source, souveraine, maîtrisée bout-en-bout.