Un budget IT présenté en une seule masse, c'est une soupe de légumes d'hiver : choux, carottes, poireaux, tout est dedans, et plus personne ne sait ce qu'il mange. La répartition entre Run et Build joue le rôle du sel. Elle n'ajoute pas un euro, elle révèle ce qui est déjà là et relie les morceaux entre eux.
Posez ce paquet unique devant votre directeur financier : il cherchera d'abord ce qui n'y est pas. Ce qui maintient l'existant et ce qui le transforme. Ce qui s'inscrit à l'actif et ce qui part en charges. Ce qui est courant et ce qui est exceptionnel. Un DAF qui ne réclame pas ces ventilations ne reste pas très longtemps à son poste. Autant les lui apporter avant qu'il ne les demande : c’est nettement plus courtois, et c’est une excellente opportunité pour reprendre la main sur la lecture de votre propre budget.
Cet article ne traite pas de la construction du budget, décrite pas à pas dans Comment construire son budget IT. Il traite de sa lecture : où passe la frontière entre Run et Build, quelle répartition viser, comment trancher les dépenses ambiguës, et comment présenter le tout pour que votre COMEX arbitre au lieu de deviner.
Run et Build : deux questions, deux décisions
Un COMEX ne sait pas arbitrer « le budget IT ». Un budget IT global n'a qu'un défaut possible : il est toujours trop élevé. Posez la question en deux fois, et la discussion change de nature.
- Combien coûte le maintien du service tel qu'il tourne aujourd'hui, avec le parc, les contrats et les engagements en cours ? C'est le Run.
- Que transformons-nous cette année, pour quel bénéfice et à quelle échéance ? C'est le Build.
La répartition ne retire pas un euro au total. La première question ouvre un travail d'efficacité, qui se mène sur plusieurs exercices. La seconde appelle un choix d'entreprise, qui revient à la direction générale et pas à la DSI. Tant que les deux restent dans le même sac, la séance se termine toujours de la même façon : une coupe forfaitaire appliquée à l'aveugle, qui rogne autant l'avenir que l'existant, et qui fruste les équipes IT.
Run/Build n'est pas CAPEX/OPEX
C'est la confusion la plus fréquente, et celle qui fait dérailler le plus de séances. Les deux découpages ne répondent pas à la même question. Run et Build disent à quoi sert l'argent. CAPEX et OPEX disent comment la dépense est traitée dans les comptes : inscrite à l'actif et étalée sur plusieurs années, ou passée en charges de l'exercice. Les deux lectures se croisent, elles ne se confondent pas.
Les deux erreurs se commettent aussi facilement l'une que l'autre :
- annoncer un Build « investi » alors qu'il partira en charges et pèsera sur le résultat de l'année
- ou faire passer un renouvellement d'infrastructure pour de la transformation, alors qu'il maintient simplement le service en état.
Dans les deux cas, le COMEX décide sur une information fausse, et la direction financière s'en aperçoit à la clôture.
Le SaaS mérite un mot particulier, il porte aujourd'hui la majorité des projets d'ETI. Un abonnement n'achète pas un actif, il achète un droit d'usage. Les coûts de paramétrage et de personnalisation suivent le plus souvent le même chemin, en tant que Charges. Beaucoup de dossiers d'investissement sont bâtis sur l'hypothèse inverse et s'en aperçoivent trop tard. Ce point se tranche avec votre DAF au cadrage du projet, pas à la clôture.
Ce que le contexte financier change, et ce qu'il ne change pas
L'année en cours pèse sur le budget, mais pas là où on le croit.
Elle joue sur le calendrier et sur le contenu. Si l’entreprise réalise un bon exercice : on avance des dépenses, on solde une dette technique, on traite une obsolescence pendant qu'on peut encore la financer. Un exercice où l'EBITDA est scruté, avant une opération ou sous LBO, on décale ce qui peut l'être sans risque, on garde les chantiers qui portent une valeur réelle, et on nomme les renoncements au lieu de les diluer.
Elle ne joue pas sur le classement d'une dépense donnée. Une dépense s'inscrit à l'actif ou part en charges selon sa nature, jamais selon le résultat que l'on souhaite afficher. Et si l'idée d'immobiliser plus largement pour soulager l'EBITDA vous traverse l'esprit, autant savoir ce qui l'attend : quand un acquéreur passe les comptes en revue, la production immobilisée est l'une des premières lignes qu'il réintègre pour ramener l'EBITDA à sa réalité. Le gain espéré n'arrive pas, et la crédibilité du budget s'en va avec lui.
Il reste une marge d'appréciation, sur la conception, l'UX design ou la maintenance évolutive. Elle est plus étroite qu'on ne l'imagine. Ce qui se défend, en séance comme devant un analyste, c'est une règle écrite et appliquée de la même façon d'un exercice à l'autre.
La règle qui tranche, applicable dès demain
Ma frontière tient en deux questions, posées dans cet ordre.
La dépense modifie-t-elle le parc applicatif ou l'infrastructure ? Si la réponse est non, c'est du Run, sans discussion. Si elle est oui, deuxième question : cette dépense apporte-t-elle une capacité ou un niveau de performance que le système n'avait pas à sa mise en service ? Si oui, c'est du Build. Si elle ramène simplement le système au niveau prévu au départ, c'est du Run, même quand le devis parle d'« évolution ».
Cette seconde question vaut mieux qu'un seuil en jours ou qu'une typologie de tickets : c'est celle que se pose votre contrôle de gestion pour décider d'immobiliser la dépense ou de la passer en charges. Une réponse, deux usages, et une ventilation qui se réconcilie avec la comptabilité sans retraitement.
Le réglementaire mérite une nuance. Traité comme une contrainte, il produit une dépense subie que personne ne défend de bon cœur. Traité comme un projet, il apporte souvent des fonctions utiles au métier, et il se raconte alors très bien en Build.
Le détail par nature de dépense, licences, prestations, hébergement, production immobilisée, se trouve dans Comment construire son budget IT.
Quelle répartition Run/Build viser dans un budget IT ?
La question tombe toujours : quel est le bon ratio ? Elle n'a pas de sens tant qu'on n'a pas d’écrit l’assiette que l’on observait.
Sur l'assiette que j'utilise, les dépenses externes sur facture fournisseur plus la production immobilisée, hors masse salariale interne non immobilisée, et sur mes cinq derniers contextes de SI mature, clients et employeurs confondus, le Run représente 30 à 40 % du budget IT. Ce n'est pas un référentiel de marché : c'est un ordre de grandeur observé sur cinq cas, avec cette assiette et cette règle de ventilation, et dans un contexte assimilé au bancaire et au wealth management sur des entreprises installées depuis plusieurs décennies.
Ajoutez la masse salariale interne dans le total, ou versez la maintenance évolutive au Run, et le chiffre bouge de plusieurs points sans que rien n'ait changé dans l'entreprise. Comparer votre pourcentage à celui du voisin ne vous apprendra donc rien. La seule comparaison utile est celle de vos propres exercices, à assiette et à règle constantes. Un Run élevé n'est d'ailleurs pas un mauvais signe en soi : un environnement critique ou fortement régulé, un socle maintenu sous support étendu portent un Run lourd, et cela s'explique très bien en séance.
Ce qui se lit vraiment, c'est la variation dans ces chiffres, d’année en année. Chaque projet livré alourdit le Run des années suivantes, par ses licences, sa maintenance, son hébergement. Un Run qui monte tout seul finit par absorber la capacité de transformation de l’entreprise, sans que personne n'ait jamais décidé de le laisser faire. La bonne question en COMEX n'est donc pas « sommes-nous au bon pourcentage », mais « où sera notre Run dans trois ans si nous ne changeons rien ».
Le Run engagé et le Run discrétionnaire
Un COMEX qui cherche de l'argent ne demande pas un pourcentage. Il demande ce qui est compressible cette année, et à quel prix.
D'où l'intérêt de couper le Run en deux :
- Le socle engagé : contrats pluriannuels en cours, maintenance obligatoire, hébergement, licences dont le préavis de résiliation est passé.
- Le discrétionnaire : ce qui se renégocie, se réduit ou s'arrête dans l'exercice, avec ses conséquences nommées et quantifiées.
Cette maille a trois vertus :
- elle évite les promesses intenables sur un socle qui ne bougera pas avant échéance.
- elle chiffre la marge de manœuvre réelle, souvent bien plus étroite que ce que le montant global laisse imaginer.
- enfin, elle prépare le scénario dégradé qu'un actionnaire finira par demander, sans avoir à refaire le travail dans l'urgence
Elle se construit à partir des contrats et de leurs échéances, c'est-à-dire de la collecte que vous avez déjà faite pour bâtir le budget (étant entendu que vous ayez bien accompli cette étape ..!)
Faire baisser le Run sans casser le service
Deux leviers donnent des résultats mesurables, à condition d'être outillés.
Le décommissionnement d'applications d'abord. Comparer le logiciel A et le logiciel B sur leurs coûts de mise en place ne veut rien dire. Ce qui décide, c'est le coût complet sur la durée, mise en place et exploitation, sur l'horizon de votre plan. Les coûts de sortie comptent aussi, et ils sont presque toujours oubliés : migration et extraction des données, période de double run, préavis et pénalités, valeur résiduelle de l'immobilisation à sortir des comptes, archivage de l'historique pendant la durée légale. Un amortissement accéléré se voit tout de suite au compte de résultat, et l'économie de Run de l'année suivante ne le compense pas toujours. Autant l'avoir chiffré avant d'annoncer une économie.
La revue du parc applicatif ensuite, deux fois par an. La version que je pratique aujourd'hui autant que possible : usage réel mesuré sur douze mois glissants, un propriétaire nommé pour chaque application, puis mise en sommeil réversible de soixante à quatre-vingt-dix jours, annoncée aux métiers, avant un décommissionnement documenté. La mise en sommeil plutôt que la coupure sèche, pour une raison simple : l'outil que personne n'ouvre en août sert à la liasse, au reporting réglementaire ou à l'audit annuel. La fenêtre doit couvrir au moins une clôture. Le principe reste franc, si personne ne réclame l'outil c'est qu'il ne servait à rien, mais le retour arrière est réel et chaque décision laisse une trace.
Le Run se dégrade en effet rarement sur les grandes lignes. Il se dégrade par accumulation, comme un mille-feuilles, de petits outils. J'ai vu un parc de 150 logiciels, dont beaucoup portaient une ou deux licences, dans une entreprise de mille personnes. Le coût des licences n'était pas le sujet. Le sujet, c'était la surface d'attaque, les comptes hors annuaire AD, les contrats et leurs annexes de protection des données à suivre un par un, les factures à traiter. Un acquéreur, lui, compte les lignes d'OPEX : c'est sa façon de mesurer la dispersion de votre SI, et cela lui prend quelques minutes.
Même vigilance sur le cloud et sur l'IA, où la flexibilité se paie au réel et sort vite du budget prévu. Une infrastructure dimensionnée et tenue sous contrôle vaut parfois mieux qu'un service trop élastique dont la facture se découvre à la fin du mois.
Faire tenir la répartition toute l'année
Une ventilation juste en janvier et fausse en septembre n'aide personne. Trois exigences suffisent à la faire tenir.
Écrivez la règle, datez-la, versionnez-la. Une ventilation qui vit dans la tête de son auteur ne survit pas à son départ, et elle ne se défend devant personne.
Faites-la porter par votre référentiel d'applications et de contrats, rattaché au plan comptable, plutôt que refaite à la main chaque trimestre. Gardez la trace des reclassements : qui, quand, pour quel motif. C'est ce qui distingue un budget lisible d'un budget arrangé, et un auditeur fait la différence en une question.
Revoyez-la chaque trimestre, avec un point mensuel avec le contrôle de gestion pour résorber les écarts au fil de l'eau plutôt qu'à la clôture. L'objectif vaut l'effort : le chiffre de la DSI, celui de la comptabilité analytique et celui présenté à l'actionnaire finissent par être le même.
Un détail qui n'en est pas un : le jour où vous basculez en Run/Build, retraitez l'exercice précédent avec la même règle. Sinon votre première restitution affiche un écart de méthode que le COMEX prendra pour une dérive réelle, et vous passerez la séance à expliquer votre tableau au lieu d'arbitrer.
Restituer le budget en une page
Une page, trois messages, dans cet ordre. L'intention du budget en trois phrases, ce que cet exercice cherche à obtenir. Le chiffre. Puis les arbitrages ouverts, deux ou trois au maximum, chacun avec son coût et ce à quoi il fait renoncer.
Le chiffre, en base 100 pour l'exemple, avec l'exercice précédent retraité selon la même règle :
Les valeurs sont illustratives, c'est la structure de lecture qui compte. Trois compléments sont vite réclamés :
- le Run que généreront les projets livrés dans l'année, puisque le Run de l'an prochain se décide maintenant
- le reste à engager
- la vue trésorerie à côté de la vue résultat, parce qu'un actionnaire lit d'abord le cash.
Le COMEX demande très rarement le détail. Il demande de quoi décider, et de quoi vérifier au trimestre suivant que la décision a produit son effet.
Un point compte autant que le format : cette page n'est pas un livrable de consultant. Elle sort de votre propre cockpit budgétaire, elle se régénère chaque mois avec un effort minimal de reconstitution et de contrôle, et elle reste chez vous.
Quand l'actionnariat change
Sous LBO, avant une cession ou une ouverture du capital, le SI cesse d'être un centre de coût pour devenir un actif que l'on regarde de près. Soyons clairs sur ce que la répartition Run/Build apporte dans ce contexte : ce n'est pas le langage d'un investisseur. Lui lit l'EBITDA, la trésorerie générée, l'investissement rapporté à l'activité, et les retraitements qu'il applique à vos chiffres. Le Run/Build est une maille de gestion, et sa valeur tient à sa capacité à se raccrocher proprement à ces agrégats.
En revanche, il répond aux quatre questions qui revenaient à chaque fois : quel est le plancher de dépenses pour maintenir le service en état, qu'est-ce qui est compressible et à quel risque, combien coûtera l'intégration d'une acquisition, que contient le plan des premiers mois. Un budget ventilé, socle engagé isolé et trajectoire visible, répond aux quatre en une page.
Ces réponses ne s'improvisent pas la veille d'un audit. Arriver avec un budget consolidé, ventilé selon une règle documentée, comparable à l'exercice précédent et adossé à des contrats, c'est transformer un exercice subi en démonstration de maîtrise. Compter quelques semaines à 2-3 mois de cartographie, à condition de ne pas les entamer trop tard.
Par où commencer
Trois gestes avant votre prochain comité budgétaire. Écrivez votre règle de répartition Run/Build sur une page, en précisant l'assiette du budget IT retenue. Isolez dans votre Run ce qui est contractuellement engagé et ce qui reste discrétionnaire. Regardez enfin la pente de votre Run sur les trois derniers exercices, à assiette constante. Ce que vous verrez là vaut la plupart des comparaisons de marché.
Réservez 30 minutes pour diagnostiquer votre pilotage →
Pour aller plus loin : le CIO-Office externalisé pour DSI · Comment construire son budget IT · Un cockpit de pilotage DSI dans Notion
