1. Construire le business case

Mode de lecture

IngénieurDécideur

Journal de Laurent Moreau, chapitre 1 (fiction)

Valenciennes, 12 mars 2025. Le DAF attend la fin du tour de table pour lâcher son chiffre : deux cent mille euros de réduction des coûts IT sur l’exercice. Laurent le note sans répondre.

Le soir même, Jean-Paul, le directeur de production, l’appelle : l’ERP est à l’arrêt depuis 16 h 30, panne de réplication, six heures d’interruption à Valenciennes. Le lendemain, la même chose à Liège, pour une autre cause.

Le lundi, Laurent fait un calcul qu’il n’avait jamais fait. Combien coûte une heure d’arrêt ? Il ne le sait pas. Jean-Paul, lui, le sait : environ quatre-vingt mille euros de marge perdue par heure à Valenciennes, à cadence nominale. Laurent additionne les incidents des douze derniers mois : dix-huit heures d’indisponibilité cumulées, tous sites confondus. Valorisées au coût de Valenciennes, cela fait une estimation haute d’environ 1,4 M€ que personne n’avait jamais consolidés.

Sa décision : ne pas répondre tout de suite à la demande de coupe. Construire d’abord un business case qui change la conversation. Le problème n’est pas de retirer 200 000 € du budget IT. Il s’agit de démontrer ce que rapporte l’argent investi. Or le gain se lit dans le compte d’exploitation de la production, pas dans le budget de la DSI.

Sans chiffrage, l’observabilité reste un projet IT de plus et c’est le premier budget coupé en période de tension. Cette leçon donne une méthode pour construire un dossier qu’une direction financière reconnaît comme sérieux.

Le coût réel des incidents

Tout business case commence par le coût des incidents des douze derniers mois. Ce chiffre manque presque toujours dans les tableaux de bord existants et son absence est déjà un argument : on ne pilote pas ce qu’on ne mesure pas.

Quatre indicateurs structurent le calcul :

• MTTD (mean time to detect) : temps entre le début d’une anomalie et sa détection ;
• MTTA (mean time to acknowledge) : temps entre l’alerte et sa prise en charge ;
• MTTR (mean time to recovery) : temps entre la détection et le rétablissement ;
• impact financier : marge perdue pendant l’indisponibilité, pénalités contractuelles, compensations client.

Le coût par minute : votre chiffre, pas celui d’une étude

Le chiffre le plus cité est celui de Gartner : 5 600 dollars par minute d’indisponibilité réseau en moyenne, soit environ 300 000 dollars par heure. Il vient d’une estimation publiée en 2014 par Andrew Lerner, analyste chez Gartner. C’est une moyenne, en dollars, ancienne, qui mélange des entreprises de toutes tailles. Elle peut servir à montrer qu’un ordre de grandeur existe, jamais à chiffrer votre cas.

Votre chiffre se calcule avec le contrôle de gestion, en marge perdue, pas en coût IT :

coût horaire d'un arrêt  =  marge horaire perdue
                          + pénalités contractuelles par heure
                          + coûts de rattrapage (heures supplémentaires, rebuts, relances)
coût direct annuel       =  somme des heures d'arrêt  x  coût horaire du système concerné

Ajoutez à part les coûts indirects (perte de confiance d’un client, heures d’équipe mobilisées) en les présentant comme une estimation, avec leur hypothèse. Mélanger un coût direct validé et un coût indirect supposé affaiblit tout le chiffre.

Recommandation : le chiffre qu’on ne veut jamais produire

À mon avis, le chiffre le plus difficile à obtenir dans un business case est rarement le prix de la plateforme : c’est le coût horaire d’un arrêt de production. Il peut n’avoir jamais été calculé, ou l’avoir été au plus bas pour ne pas inquiéter la direction. Je recommande de ne pas le calculer seul : faites-le avec le contrôleur de gestion du site, en lui faisant valider chaque hypothèse au fur et à mesure. Le chiffre qui sort de cette séance est défendable en comité, pas celui qu’on a construit dans son coin.

Calculer le retour sur investissement

ROI (%)            = (gains - coûts) / coûts x 100
délai de récupération (mois) = investissement initial / gain mensuel

Les gains se construisent à partir de quatre sources, à chiffrer séparément :

1. la réduction du coût des incidents : moins d’heures d’arrêt, détectées plus tôt, rétablies plus vite ;
2. la rationalisation de l’outillage : licences redondantes supprimées ;
3. le temps d’équipe récupéré : moins de bruit d’alerte, diagnostics plus courts ;
4. les économies sur la télémétrie elle-même : voir la leçon 4.

Les coûts comprennent les licences ou l’infrastructure, le stockage, les personnes (exploitation de la plateforme, instrumentation), la formation, la conduite du changement et la migration.

Ce qui ne compte pas comme un gain

Le plafond d’une amende NIS2 ou DORA n’est pas un gain : c’est une exposition au risque. Présentez-la sur une ligne séparée, avec sa probabilité qualitative, plutôt que de l’additionner aux gains. Un DAF qui voit 10 M€ de « sanctions évitées » dans un tableau de ROI cesse de lire le reste.

Un comité de direction est souvent plus sensible au délai de récupération qu’au ROI : « en combien de mois récupère-t-on la mise ? » parle davantage qu’un pourcentage à cinq ans. Pour l’estimer sur vos propres hypothèses, le business case du MTTR calcule le retour, le délai de récupération et la sensibilité aux hypothèses.

Recommandation : au-delà de douze mois, changez de comité

À mon avis, un projet dont le délai de récupération dépasse douze mois a peu de chances d’être accepté par un comité de direction d’ETI. Au-delà, la direction le perçoit comme un pari stratégique. Et un pari se décide ailleurs, souvent en comité d’investissement. Je recommande l’une de deux options : réduire le périmètre de la première phase pour accélérer les gains, ou requalifier explicitement le projet comme stratégique. Un projet présenté entre les deux, avec un délai flou, a peu de chances de passer.

La méthode en six étapes

L’ordre compte. Sauter une étape ou l’inverser produit des dossiers qui ne convainquent pas.

flowchart LR
  E1["1. Coût des<br/>incidents"] --> E2["2. Gains<br/>attendus"] --> E3["3. Coût<br/>complet"] --> E4["4. ROI et<br/>récupération"] --> E5["5. Trois ans,<br/>trois scénarios"] --> E6["6. Pitch au<br/>comité"]

1. Chiffrer le coût des incidents des douze derniers mois : nombre, durée, coût horaire par système, pénalités.
2. Identifier les gains attendus, source par source. Posez une hypothèse de réduction du temps d’arrêt que vous justifiez (par exemple les incidents que vous auriez détectés plus tôt avec une alerte sur le symptôme utilisateur).
3. Totaliser le coût complet sur trois ans, pas seulement les licences.
4. Calculer le ROI et le délai de récupération et la valeur actuelle nette si votre direction financière l’utilise.
5. Projeter sur trois ans avec trois scénarios (prudent, central, favorable) et au moins deux architectures comparées avec les mêmes critères (voir la leçon 3).
6. Pitcher au comité : cinq diapositives, dix minutes, une décision demandée (voir la leçon 7).

Le coût complet, poste par poste

Un business case qui n’affiche que les licences est disqualifié au premier arbitrage sérieux. Six postes sont régulièrement sous-estimés :

Poste	Ce qu’il faut compter	Levier principal
Stockage des métriques	volume de séries actives, rétention, réplication	maîtrise de la cardinalité
Stockage des logs	volume ingéré et indexé, rétention par catégorie	niveaux chaud, tiède, froid
Traces	spans ingérés, rétention	échantillonnage en queue
Personnes	exploitation de la plateforme, astreinte, instrumentation	automatisation, configuration versionnée
Abonnements SaaS	unités facturées (hôtes, volume, utilisateurs, modules)	négociation, plafonds, revue d’usage
Conduite du changement	formation, accompagnement, documentation	référents internes, procédures écrites

Je ne donne pas ici de prix au gigaoctet ni de fourchette de coût total par taille d’entreprise. Ils varient trop selon l’architecture et le contrat pour être utiles hors contexte. Le simulateur de coût au Collector permet de chiffrer votre propre volume, avec des prix unitaires que vous saisissez.

Six leviers d’économie à prévoir dès le départ

Ces leviers se décident à la conception. Activés tôt, ils pèsent sur les trois années du business case.

1. Échantillonnage intelligent des traces : garder toutes les traces en erreur ou lentes et seulement une fraction du trafic nominal.
2. Rétention différenciée : toutes les données n’ont pas la même valeur dans le temps ; un log de débogage n’a pas la durée de vie d’un journal d’authentification.
3. Cardinalité contrôlée : pas d’identifiant unique (utilisateur, requête) comme label de métrique.
4. Un tableau de bord du coût de l’observabilité : coût par gigaoctet ingéré, par service, par équipe, avec alerte sur les dérives.
5. Négociation contractuelle : engagement, plafonds, clause de sortie, toujours avec des offres comparables en main.
6. Architecture choisie sur critères : open source autogéré, SaaS ou mixte, comparés avec la même grille (voir la grille d’évaluation des solutions).

L’effet de chaque levier dépend de votre volume et de votre contrat. Plutôt qu’un pourcentage générique, mesurez-le : le simulateur de coût au Collector montre la facture avant et après chaque levier.

Le modèle de business case

Un modèle à remplir, dont la colonne « méthode » compte autant que la valeur : c’est elle qu’un DAF interroge.

Coût des incidents (douze derniers mois)

Poste	Méthode de calcul	Valeur
Incidents majeurs	tickets de priorité 1 et 2
Durée d’indisponibilité	somme des durées d’arrêt, par système	heures
Coût horaire d’un arrêt	marge horaire perdue, validée par le contrôle de gestion	€/h
Coût direct	durée x coût horaire, par système	€
Coût indirect estimé	hypothèse explicite, validée ou non	€
Exposition réglementaire	ligne séparée, non additionnée aux gains	qualitatif

Gains projetés sur trois ans

Année	Hypothèse de réduction du temps d’arrêt (à justifier)	Gain annuel	Cumul
1
2
3

Synthèse

Indicateur	Formule	Valeur
ROI à trois ans	(gains - coûts) / coûts x 100	%
Délai de récupération	investissement initial / gain mensuel	mois
Ratio gains sur coûts	gains totaux / coûts totaux	pour 1

Atelier : votre business case

Durée : 45 minutes, seul ou à deux.

1. Chiffrez les incidents des douze derniers mois : nombre, durée totale, coût cumulé.
2. Obtenez ou estimez le coût horaire d’un arrêt pour votre système le plus critique, avec son hypothèse.
3. Formulez une hypothèse de réduction du temps d’arrêt et justifiez-la incident par incident.
4. Calculez les gains annuels, le ROI à trois ans et le délai de récupération dans le business case du MTTR.
5. Notez vos deux plus grandes incertitudes : ce sont les premières questions du comité.

Si vous n’avez pas de données d’incident

C’est votre premier argument. L’absence de mesure est le premier symptôme d’un manque d’observabilité et le premier livrable du projet sera justement de la produire.

Ma prochaine action : quelle action, pour quelle date, avec qui ?

Pour aller plus loin

• Le business case du MTTR, pour tester vos hypothèses.
• Pour un service d’IA : l’impact chiffré de la méthode GenAI et son calculateur d’exposition.
• Le plan business.

Marquer comme lue

PasserellesCe que cette page change au-delà de l'équipe technique.

BusinessValeur, coût, risque

Le chiffre central n'est pas le prix de la plateforme mais le coût horaire d'un arrêt, calculé en marge perdue avec le contrôle de gestion : c'est lui qui change la conversation.

OrganisationQui décide, qui possède

Un business case défendable se construit à plusieurs : DSI, contrôle de gestion, responsables de production. Les hypothèses validées en séance tiennent en comité.

HumainÉquipes, astreinte, compétences

Les gains sur l'astreinte et la rétention des équipes sont réels mais difficiles à chiffrer ; les présenter à part évite de fragiliser le reste du dossier.

MétiersProduit, finance, risque, relation client

Pour la direction financière : ROI à trois ans, délai de récupération en mois, trois scénarios, hypothèses en annexe. Le format qu'elle utilise déjà pour les autres investissements.

Pourquoi des passerelles →