Gestion du budget IT : comment le construire, le suivre et le défendre

À retenir

• La gestion du budget IT couvre trois temps : la construction annuelle, le suivi en cours d’exercice et l’arbitrage des nouvelles demandes.
• Un budget IT se structure généralement entre Run (fonctionnement du SI existant) et Build (projets et évolutions).
• La principale difficulté n’est pas de construire le budget, c’est de le rattacher à la réalité : quelles dépenses correspondent à quelles applications, quels usages, quelle valeur.
• Un budget IT présenté par nature de dépense est difficile à défendre. Un budget rattaché aux applications et aux services rendus est beaucoup plus convaincant.
• La gestion budgétaire n’est pas un exercice isolé : elle fait partie intégrante de la gestion du SI, et sans référentiel applicatif fiable, elle reste une compilation plutôt qu’un outil de pilotage. 

 

Ce que recouvre la gestion du budget IT

La gestion du budget IT ne se résume pas à l’exercice annuel de construction budgétaire. Elle couvre trois temps distincts, souvent traités séparément alors qu’ils sont liés.

La construction : estimer les dépenses de l’exercice à venir, arbitrer entre les demandes, aligner le budget sur les priorités de l’entreprise et le négocier avec la direction générale et la DAF.

Le suivi : piloter l’exécution en cours d’année, rapprocher les engagements des prévisions, détecter les dérives avant qu’elles ne deviennent des dépassements, ajuster.

L’arbitrage continu : traiter les demandes qui arrivent en cours d’exercice, décider ce qu’on finance, ce qu’on reporte et ce qu’on refuse, avec des critères objectivés.

Ces trois temps s’appuient sur la même chose : la qualité des données disponibles.

 

La structure d’un budget IT : Run et Build

La distinction la plus répandue oppose deux grandes masses.

Le Run couvre tout ce qui fait fonctionner le SI existant : licences et abonnements, infrastructure, hébergement, contrats de maintenance, support, infogérance, salaires des équipes d’exploitation. C’est la part contrainte du budget, celle qu’on ne peut pas supprimer sans conséquence immédiate.

Le Build couvre les projets et les évolutions : nouveaux déploiements, migrations, développements, refontes applicatives. C’est la part arbitrable, celle qui porte la transformation.

Le ratio entre les deux est un indicateur en soi. Un Run qui représente 80% du budget laisse peu de marge de manœuvre pour transformer. Réduire le Run, c’est souvent la condition pour financer le Build sans augmenter l’enveloppe globale, ce qui rejoint directement les enjeux d’optimisation des coûts IT.

 

Le vrai problème : un budget déconnecté du SI

Voici comment le budget IT est structuré dans la plupart des organisations : par nature de dépense. Une ligne « licences logicielles ». Une ligne « prestations externes ». Une ligne « infrastructure ». Une ligne « maintenance ».

Cette structure convient à la comptabilité, mais elle est presque inutilisable pour piloter, car elle ne répond à aucune des questions qui comptent vraiment :

• Combien nous coûte l’ERP, tout compris ?
• Quelle direction métier consomme le plus de ressources IT ?
• Cette application vaut-elle ce qu’elle coûte ?
• Quelles sont les dépenses qu’on pourrait arrêter demain sans impact ?

Pour y répondre, il faut pouvoir rattacher chaque dépense à une application, un service ou un projet identifié. Et c’est là que le bât blesse : les licences sont recensées dans un tableur aux achats, les coûts d’infrastructure sont globalisés, les prestations sont dans l’ERP comptable, et personne ne dispose d’un inventaire fiable des applications du SI.

En conclusion, la DSI passe des jours à compiler des données pour produire un budget qu’elle ne peut pas défendre en détail.

 

Construire un budget IT rattaché à la réalité

Partir du patrimoine applicatif

Un budget IT fiable commence par un inventaire fiable. Quelles applications tournent réellement ? Qui en est propriétaire ? Quels contrats sont associés ? Quelle infrastructure les supporte ?

Cette base, c’est ce que fournit la cartographie applicative. Sans elle, le budget se construit sur des estimations et des reconductions à l’identique, sans jamais interroger la pertinence des lignes existantes.

Ventiler selon plusieurs axes

Un même budget doit pouvoir se lire différemment selon l’interlocuteur.

• Par nature de dépense pour la DAF et la comptabilité
• Par application pour analyser le coût réel de chaque brique du SI
• Par direction métier pour objectiver la consommation de chacun
• Par projet pour suivre l’avancement du Build
• Par domaine fonctionnel pour raisonner en termes d’urbanisation du SI

Cette capacité à croiser les axes transforme un tableau de chiffres en véritable outil d’analyse.

Intégrer le coût complet, pas seulement la facture

Une application ne coûte pas ce que dit sa licence. Elle coûte aussi son infrastructure, son support, sa maintenance, le temps des équipes qui l’administrent et les développements d’interfaces qu’elle nécessite. Raisonner en TCO applicatif plutôt qu’en montant facturé change complètement la lecture du budget.

 

Piloter le budget en cours d’exercice

Le pilotage en continu repose sur quelques mécanismes simples.

• Le rapprochement engagements / prévisions. Devis, bons de commande, factures : suivre les engagements réels au fil de l’eau permet de savoir où on en est, pas où on pensait être.
• Les alertes sur les écarts. Détecter une dérive à 40% de consommation d’une ligne budgétaire au premier trimestre laisse le temps de réagir, alors que la découvrir en fin d’exercice ne laisse que le constat.
• La délégation maîtrisée. Attribuer des périmètres budgétaires à des responsables identifiés répartit la charge de pilotage et responsabilise les équipes, tant que la vision consolidée reste accessible.
• Le reporting automatisé. Si produire le point budgétaire mensuel demande une journée de compilation manuelle, le format est le problème, pas la fréquence.

 

Défendre son budget IT en CODIR

C’est l’exercice redouté. Quelques principes changent la donne.

• Parler valeur, pas coût. Une ligne « licences : 340 K€ » invite à la discussion sur le montant. Une présentation qui montre quelles applications ce montant finance, pour quels métiers et quels usages, déplace la conversation vers l’utilité.
• Maîtriser la lecture CAPEX / OPEX. La bascule des infrastructures vers le cloud et des licences perpétuelles vers l’abonnement transforme des investissements amortissables en charges de fonctionnement récurrentes. Cette évolution a un impact direct sur le compte de résultat, et la DAF y est très attentive. Une DSI capable de présenter son budget sous les deux angles, avec la trajectoire CAPEX/OPEX sur plusieurs exercices, parle le même langage que ses interlocuteurs financiers. 
• Documenter le contraint et l’arbitrable. Distinguer clairement ce qui ne peut pas être réduit sans conséquence de ce qui relève d’un choix permet des arbitrages éclairés plutôt que des coupes uniformes.
• Anticiper la question de l’optimisation. Arriver en CODIR avec les gisements d’économies déjà identifiés, licences sous-utilisées, applications en doublon, contrats à renégocier inverse la dynamique. La DSI n’est plus sur la défensive.
• S’appuyer sur des données, pas des estimations. C’est le point qui fait toute la différence, et c’est celui qui nécessite un référentiel applicatif tenu à jour.

C’est précisément ce que permet le module Budget d’Optim-SI en association avec les modules APM d’Optim-SI et PPM: rattacher le budget aux applications, aux contrats et aux projets, et disposer à tout moment d’une vision consolidée pour arbitrer, suivre et présenter.

 

FAQ

Quelle différence entre budget IT et budget DSI ?

Les deux termes sont souvent employés indifféremment, mais il existe une nuance. Le budget DSI désigne l’enveloppe gérée directement par la direction des systèmes d’information. Le budget IT au sens large inclut aussi les dépenses informatiques portées par les directions métiers, souvent invisibles pour la DSI.

Comment répartir le budget entre Run et Build ?

Il n’existe pas de ratio universel. La répartition dépend du secteur, de la maturité numérique de l’entreprise et de l’état du SI. Ce qui compte davantage que le ratio absolu, c’est sa trajectoire : un Run qui grossit d’année en année sans justification indique une accumulation de dettes techniques et applicatives.

Peut-on gérer son budget IT dans Excel ?

Beaucoup de DSI le font encore. Le problème n’est pas Excel en soi, c’est la déconnexion : les chiffres du tableur ne sont reliés ni aux applications, ni aux contrats, ni aux engagements réels. Chaque mise à jour est manuelle, chaque analyse croisée demande un retraitement. Un référentiel centralisé change la nature de l’exercice : le budget devient une donnée vivante plutôt qu’une photo à retoucher en permanence.

Comment gérer la bascule CAPEX / OPEX dans son budget IT ?

La migration vers le cloud et le passage aux licences par abonnement transforment des investissements amortissables sur plusieurs années en charges de fonctionnement immédiates. L’effet est double : le budget d’investissement diminue, mais les charges récurrentes augmentent, ce qui alourdit le compte de résultat à court terme.