Finance et budgets IT¶

Savoir parler finance est la compétence la plus sous-estimée d'un responsable technique — sans elle, les meilleurs arguments techniques perdent face aux chiffres.

Pourquoi les DSI doivent comprendre la finance¶

Les décisions IT se prennent dans des contextes ou l'argent est la langue commune. Un DSI qui ne maîtrise pas les concepts financiers de base est systematiquement en position de faiblesse dans trois situations critiques :

La negociation budgetaire : le DSI demande 2M€ pour moderniser une plateforme. Le CFO demande le ROI. Si le DSI ne peut pas calculer et defendre un retour sur investissement crédible, le budget sera coupe ou alloue ailleurs.

L'arbitrage build vs buy : choisir entre développer en interne ou souscrire un SaaS est un calcul financier autant que technique. TCO, CapEx/OpEx, coût d'opportunité — ces notions déterminent la bonne décision.

La justification de la dette technique : la dette technique est un concept intuitif pour les ingénieurs, abstrait pour les financiers. La traduire en risque financier quantifie (coût de correction croissant, risque de panne, ralentissement de livraison) est la seule manière de la faire entendre au-delà de la DSI.

TCO : coût total de possession¶

Le TCO (Total Cost of Ownership) est la somme de tous les coûts engages sur la durée de vie d'un système ou d'une solution. C'est la métrique fondamentale pour toute décision d'investissement IT.

Les composantes du TCO¶

Acquisition : coûts initiaux pour obtenir la solution.

• Licences logicielles (perpetuelles ou subscription initiale)
• Matériel (serveurs, réseau, stockage)
• Coûts de développement ou d'intégration
• Coûts de migration des données
• Formation initiale

Exploitation : coûts recurrents pour faire fonctionner la solution.

• Infrastructure (cloud, datacenter, énergie)
• Licences recurrentes (SaaS, maintenance éditeur)
• Équipe opérationnelle (ops, support, astreintes)
• Monitoring, sécurité, sauvegardes

Maintenance : coûts lies à l'évolution et au maintien en condition opérationnelle.

• Mises à jour et patches
• Corrections de bugs et d'incidents
• Évolution fonctionnelle
• Gestion des dépendances (librairies, frameworks)

Decommissionnement : coûts souvent oublies en fin de vie.

• Migration vers la solution suivante
• Archivage des données (contraintes legales parfois longues : 10 ans pour certaines données financieres)
• Résiliation des contrats (pénalités eventuelles)
• Coûts humains de la transition

TCO en pratique : l'exemple cloud vs on-premise¶

Un calcul TCO incomplet est l'erreur la plus fréquente dans les décisions d'infrastructure.

Ce tableau simplifie masque des variables importantes : l'élasticité du cloud (on paye selon l'usage, pas la capacité maximale), les coûts de sortie (egress fees), la charge de migration initiale, et les coûts de formation aux outils cloud.

ROI, VAN, TRI : les outils de décision financiere¶

ROI : retour sur investissement¶

Le ROI est le ratio entre le gain net généré par un investissement et le coût de cet investissement.

ROI = (Benefices - Couts) / Couts × 100

Exemple : un projet de migration CI/CD coute 150 k€ (développement, formation, outillage). Il réduit les incidents de production de 40% (économie estimée : 80 k€/an en temps équipe) et accéléré la livraison de 30% (valeur estimée : 100 k€/an en time-to-market). Benefice annuel : 180 k€.

• ROI année 1 : (180 000 - 150 000) / 150 000 = 20%
• Payback period : 150 000 / 180 000 = 10 mois

Le ROI est simple mais ignore la valeur temporelle de l'argent (1€ aujourd'hui vaut plus qu'1€ dans 3 ans) et ne permet pas de comparer des investissements sur des durées différentes.

Payback period : délai de récupération¶

Le payback period est la durée nécessaire pour récupérer l'investissement initial. C'est la métrique la plus intuitive pour les decideurs non-financiers.

Calcul : diviser l'investissement initial par le flux de tresorerie annuel généré.

Interpretation : un payback inférieur à 2 ans est généralement acceptable pour des projets IT. Au-delà de 3 ans, l'incertitude sur les benefices futurs augmente considérablement — il faut justifier davantage.

Limite : ne prend pas en compte ce qui se passe après le payback. Deux projets avec le même payback peuvent avoir des profils de benefices très différents sur 5 ans.

VAN : valeur actuelle nette¶

La VAN actualise les flux de tresorerie futurs pour tenir compte de la valeur temporelle de l'argent. Elle répond à la question : combien vaut aujourd'hui la somme des flux futurs de cet investissement ?

VAN = -Investissement + Σ (Flux annee n / (1 + taux actualisation)^n)

Le taux d'actualisation représenté le coût du capital (généralement entre 5% et 15% selon le secteur et le risque de l'entreprise). Si la VAN est positive, l'investissement créé de la valeur. Si elle est negative, il en détruit.

Exemple : projet de 200 k€ avec des flux annuels de 80 k€ sur 4 ans, taux d'actualisation 8%.

VAN = 264 971 - 200 000 = +64 971€ — l'investissement crée de la valeur.

TRI : taux de rendement interne¶

Le TRI est le taux d'actualisation qui annule la VAN — autrement dit, le rendement effectif de l'investissement. Si le TRI est supérieur au taux de rendement exige par l'entreprise (hurdle rate), l'investissement est acceptable.

Le TRI est utile pour comparer des projets de durées différentes ou pour arbitrer entre plusieurs options d'investissement.

CapEx vs OpEx¶

La distinction CapEx/OpEx est fondamentale pour comprendre les implications comptables et fiscales des investissements IT.

Définitions¶

CapEx (Capital Expenditure) : depenses en capital, investissements en actifs durables qui sont inscrits au bilan et amortis sur leur durée de vie utile. Le coût est étalé dans le temps en comptabilité, même si le decaissement est immédiat.

OpEx (Operational Expenditure) : depenses opérationnelles, charges courantes qui sont integralement deduites du résultat de l'exercice ou elles sont engagees.

Impact comptable et fiscal¶

Pourquoi le cloud est de l'OpEx¶

Le passage du datacenter on-premise (CapEx dominant) au cloud (OpEx dominant) a des implications strategiques importantes :

Avantages de l'OpEx cloud :

• Pas d'immobilisation de capital — le cash reste disponible pour d'autres investissements
• Flexibilite : on peut réduire ou arrêter les depenses selon les besoins
• Aligne le coût sur l'usage réel — on ne paye pas de la capacité inutilisee
• Facilite les approbations — les OpEx passent souvent sous des seuils d'approbation plus bas que les CapEx

Inconvénients :

• Coût recurrent non plafonnable si la gouvernance est absente
• Peut être plus cher sur le long terme pour des charges stables et prévisibles
• Dépendance contractuelle au fournisseur

Implication budgetaire : un DSI qui passe de l'on-premise au cloud doit gérer une transition comptable : les CapEx disparaissent progressivement (plus d'amortissement), mais les OpEx augmentent immédiatement. Le coût total peut sembler augmenter pendant la periode de transition, même si le TCO est favorable. Anticiper cette communication avec le CFO.

Le business case IT¶

Le business case est le document qui formalise la justification d'un investissement. C'est l'outil de décision et de communication entre la DSI et les decideurs.

Structure d'un business case solide¶

1. Problème ou opportunité Description factuelle de la situation actuelle. Quels problèmes sont observes ? Quelles opportunités sont manquees ? Quel est le coût de ne rien faire (status quo cost) ?

2. Solution proposee Description de la solution retenue et des alternatives evaluees. Pourquoi cette solution plutôt qu'une autre ? Quelles hypothèses sous-jacentes ?

3. Coûts Tous les coûts sur la durée de vie, par phase (étude, implémentation, exploitation, maintenance). Distinguer les coûts certains des estimations. Inclure les coûts indirects (charge des équipes métier impliquees dans le projet).

4. Benefices Benefices quantifies (économies, revenus supplémentaires, réduction de risque en euros) et benefices qualitatifs (satisfaction client, conformité, agilité). Être explicite sur les hypothèses de quantification.

5. Risques Risques d'exécution (retards, dépassements budgetaires), risques techniques (intégration, performance), risques métier (adoption, résistance au changement). Chaque risque avec sa probabilite, son impact, et les mesures d'attenuation.

6. Timeline et jalons Phasage du projet, jalons clés, points de décision (go/no-go), date de première valeur livree (time-to-value).

7. Recommandation Synthèse en une demi-page : pourquoi investir, quel montant, quel benefice attendu.

Erreurs courantes¶

Quantifier uniquement les benefices optimistes : tout modèle financier peut être rendu attractif en choisissant les hypothèses les plus favorables. Les decideurs experimentees le savent. Un business case crédible présente des scenarios (pessimiste, nominal, optimiste) et justifie ses hypothèses.

Ignorer les coûts caches : la formation des utilisateurs, le temps des équipes métier pendant le projet, les coûts de transition, le risque de parallélisme pendant la migration sont systematiquement sous-estimés.

Oublier le coût de ne rien faire : le status quo a un coût — dette technique croissante, risque de défaillance, perte de competitivite. Ne pas le quantifier affaiblit l'argument en faveur de l'investissement.

Présenter une solution sans alternative : un business case qui ne considéré qu'une seule option ne donne pas de choix aux decideurs. Présenter au moins deux options (y compris "ne rien faire") renforce la crédibilité.

Modèles de refacturation IT : showback, chargeback, FinOps¶

Showback¶

Le showback est la présentation des coûts IT par centre de coût consommateur, sans refacturation réelle. La DSI présente aux BU "vous avez consomme X euros d'IT ce mois" — pour information, sans mouvement financier.

Avantages : crée une visibilité sur les coûts sans friction administrative. Première étape vers la responsabilisation des métiers.

Inconvénients : sans conséquence financiere réelle, l'information est souvent ignoree. Les comportements de consommation ne changent pas.

Chargeback¶

Le chargeback est la refacturation réelle des coûts IT aux entités consommatrices. Chaque BU paye les services IT qu'elle consomme via des refacturations internes.

Avantages : crée une vraie incitation à la maîtrise des coûts. Les métiers font des choix conscients de consommation quand ils en supportent le coût.

Inconvénients : complexité administrative (modèles de tarification internes, contestations), risque que les BU contournent la DSI en achetant des services cloud directement (shadow IT).

Modèles de tarification interne : par utilisateur, par service consomme, par ressource (CPU, stockage, réseau), ou tarification par "catalogue de services" avec des prix unitaires fixes.

FinOps¶

Le FinOps (Financial Opérations) est une pratique qui vise à optimiser les depenses cloud en combinant ingénierie, finance et métier. Les trois piliers :

Visibilité : tagging systematique des ressources cloud, dashboards de consommation en temps réel, alertes sur les dérivés.

Optimisation : rightsizing (adapter les instances à l'usage réel), reserved instances / savings plans pour les charges stables, spot instances pour les charges tolerantes aux interruptions, élimination des ressources inutilisees.

Gouvernance : budgets par équipe, processus d'approbation pour les deployments coûteux, revues mensuelles de coûts, accountability claire.

Construire et defendre le budget IT¶

Le processus budgetaire annuel¶

Septembre-octobre : construction Les équipes remontent leurs besoins. Le DSI consolide et priorise selon les axes strategiques. Chaque poste budgetaire est justifie par un besoin identifié, pas par recduction du budget précédent.

Novembre : arbitrage interne Le budget IT est présenté à la direction financiere. Des iterations sont attendues — prévoir des "paquets" de coupes possibles (que peut-on sacrifier si le budget est réduit de 10%, 20%, 30%) avec les conséquences clairement explicitees.

Decembre-janvier : validation Validation par le COMEX, engagement sur le budget annuel.

En continu : suivi Reporting mensuel budget vs réalisé. Anticipation des dérivés. Demandes de budget complementaire en cas de besoin non prévu (avec business case).

Structure d'un budget IT type¶

Negocier le budget¶

Lier chaque demande a un objectif business : "nous avons besoin de 200k€ pour la plateforme de monitoring" est faible. "Nous avons besoin de 200k€ pour la plateforme de monitoring, ce qui nous permettra de réduire notre MTTR de 4h a 30min, evitant en moyenne 3 incidents majeurs par an qui coutent chacun 150k€ en perte de CA et remediations" est fort.

Présenter les risques du non-investissement : les décisions de ne pas investir ont aussi des conséquences financieres. Les rendre explicites et chiffrees.

Proposer des options : budget plein (tout le programme), budget contraint (priorités 1 et 2 seulement, avec les risques associes), budget minimal (maintien du niveau actuel, avec détérioration des capacités sur X mois).

Séparer les runs des builds : le run (exploitation courante) doit être clairement distingue du build (investissements nouveaux). Comprimer le run met en danger la stabilité opérationnelle — les decideurs doivent en être conscients.

Indicateurs de pilotage budgetaire¶

La dette technique : comment en parler aux financiers¶

La dette technique est souvent le sujet le plus difficile à faire financer — parce que sa valeur est negative (éviter des problèmes futurs) et son impact est diffus.

Traduction en risque financier :

• Ralentissement de livraison : une base de code avec 20% de dette active ralentit les nouvelles fonctionnalités de X%. Coût : Y jours-ingénieur par sprint, soit Z k€/mois
• Risque de panne : systèmes non maintenus, dépendances obsolètes, vulnérabilités non patchees. Coût actuariel : probabilite × impact financier d'une panne
• Coût d'opportunité : les ingieneurs qui maintiennent la dette ne travaillent pas sur de nouvelles fonctionnalités. Coût = temps × taux journalier × valorisation des fonctionnalités

Stratégie de communication : ne pas demander un budget "pour corriger la dette". Intégrer la remediaiton de la dette dans chaque projet sous forme de pourcentage explicite (20% du temps de chaque sprint, ou une iteration "tech debt" par trimestre). Le coût est réel, visible, et lie a des livraisons concrètes.