La saison des budgets s'ouvre. Votre DAF va bientôt réclamer des chiffres pour l'année prochaine - et si votre entreprise est susceptible de changer d'actionnariat, ces chiffres ne resteront pas entre vous. Ils seront lus, retraités et challengés par des analystes dont c'est le métier. Un budget IT bricolé se repère en quelques minutes. Un budget construit avec méthode aussi.
Cet article décrit la méthode que j'emploie pour construire le budget IT d'une ETI. Elle ne demande aucun outillage sophistiqué : un ordre de construction, des hypothèses partagées avec la DAF (et un peu de discipline..!).
Pourquoi cette saison compte double
Un changement d'actionnariat - LBO, cession, ouverture du capital - change la nature de l'exercice budgétaire. Le budget IT devient une pièce d'analyse : il raconte à un acquéreur si le SI est piloté ou subi.
Pour l’avoir vécu de l’intérieur, ce que les analystes regardent en premier : le montant des OPEX, et le nombre de lignes d’OPEX - autrement dit, le nombre d'outils différents qui composent le SI. Puis vient la question de fond : où va l'argent ? Vers le maintien de l'existant, ou vers le financement de l'avenir du SI ?
Derrière ces questions, une grille de lecture constante : l'EBITDA et le cash. Ce qui est OPEX pèse sur l'EBITDA, ce qui s'immobilise n'y pèse pas - et la frontière entre les deux sera retraitée si elle paraît arrangeante. Présenter son budget en sachant ce qu'il fait à ces deux agrégats, c'est parler la langue de l'acquéreur.
Et ce qui les a rassurés tient en une phrase : la capacité à fournir en 48 heures le budget, le forecast, le réalisé, la ventilation par nature de dépense et la roadmap à 18 mois. Ce que cherche un fonds n'est pas un budget bas : c'est un budget dont chaque composante est disponible, à jour et racontable.
La bonne nouvelle : cette capacité ne s'improvise pas au moment de la due diligence. Elle s'obtient en construisant le budget correctement dès le départ.
Ce qu'un budget bricolé coûte vraiment
Les budgets que je trouve à mon arrivée en mission souffrent souvent des mêmes maux : un état des lieux non exhaustif des dépenses, du shadow IT qui échappe au périmètre, des lignes de projets sans date de fin - et qui deviennent in-fine du Run sans le nommer. Parfois, c'est une méconnaissance totale des coûts réels de l'IT dans l'entreprise : le budget se résume à un chiffre calculé à la va-vite il y a un an ou deux, sans contexte ni périmètre borné. C’est généralement le cas pour les entreprises dont la trésorerie n’est pas un problème, et donc pour qui le manque de maîtrise de ses dépenses n’est pas un problème non plus.
Ce bricolage se paie deux fois.
- Au moment de défendre le budget : sans justification ligne à ligne, l'arbitrage se fait au rapport de force, et l'IT le perd souvent. Le symptôme le plus courant : “bon, vous me faites le petit cut de 10% sur le budget global et on va se prendre une petite coupette”.
- Puis tout au long de l'année : si le contrôle de gestion est permissif, rapprocher ses budgets de ses dépenses est un enfer - et les comités budgétaires se passent à reconstituer, au lieu d'arbitrer.
Étape 1 - cartographier l'existant, service par service
Tout commence par la cartographie de l'ensemble des applications - en interrogeant chaque service, pas seulement depuis la vision de la DSI : c'est en passant par les métiers que le shadow IT sort du bois et que le périmètre réel de l'IT se borne.
En parallèle, récupérer l'ensemble des contrats : licences, abonnements, maintenance, prestations. Chaque contrat porte sa date d'échéance et sa clause d'indexation - ce sont elles qui feront le budget de l'année suivante. Un contrat ferré avec un partenaire sur 3 ans est une dépense indéboulonnable sur la période du contrat - en gestion courante du moins. En contexte de cession, d'autres clauses prennent le relais et se repèrent dès la collecte : changement de contrôle, conditions de sortie, engagements hors bilan, dépendance à un fournisseur unique.
Étape 2 - constituer la database
La matière collectée se structure immédiatement en base : chaque application avec ses contrats, ses coûts triés par nature de dépense, son responsable, sa criticité. Ce référentiel n'est pas un livrable de l'exercice budgétaire : c'est lui qui portera le budget, puis son suivi tout au long de l'année.
Une exigence dès la conception : chaque nature de dépense de la base doit se mapper sur le plan comptable de l'entreprise. C'est cette correspondance qui permet de réconcilier le budget IT avec le grand livre - et des chiffres qui ne se réconcilient pas avec la comptabilité ne valent rien en due diligence, quelle que soit la vitesse à laquelle on les produit.
Étape 3 - poser les hypothèses de l'année à venir
Rien ne se chiffre sans hypothèses écrites :
- revalorisation Syntec des prestations
- maintien ou abandon de licences, adossé à des stratégies de sortie de produit IT
- produits et besoins supplémentaires
- chantiers impératifs - en isolant la sécurité et la conformité (cyber, RGPD, NIS2) comme lignes identifiables : une sécurité noyée dans le reste du budget est un signal faible pour un auditeur,
- staffing minimal par application pour tenir le Run,
- masse salariale et hypothèses de recrutement ou de départ - avec un œil sur la structure : ratio interne / externe, dépendance à des personnes clés, réversibilité des prestations. C'est cette structure, plus que la masse, qu'un acquéreur analyse,
- production immobilisée : la capitalisation des développements internes améliore l'EBITDA - c'est précisément pour cela qu'elle est l'un des retraitements les plus scrutés en due diligence. Les critères d'activation se documentent et se défendent.
Étape 4 - définir les besoins projets : top-down et bottom-up
Les besoins en projets se collectent dans les deux sens :
- top-down - ce que la stratégie de l'entreprise impose au SI
- bottom-up - ce que les services font remonter du terrain.
Chaque besoin est ensuite macro-chiffré avec le CTO : stratégie make-or-buy, charge, coût externe, jalon de démarrage - et le Run qu'il générera une fois livré : licences, maintenance, hébergement. Un projet chiffré sans son run-rate futur est un chiffrage tronqué : c'est lui qui alourdira les OPEX des exercices suivants. Un chiffrage grossier mais construit vaut mieux qu'un chiffre précis sorti de nulle part : en phase de cadrage, la fourchette assumée est une pratique saine, pas un aveu de faiblesse.
Étape 5 - le tableau global, puis les scénarios
Vient ensuite le tableau global de l'ensemble des budgets : chaque ligne avec sa nature, son type de dépense, son montant, l'hypothèse prise - et son apport pour le business : pourquoi cette ligne a de la valeur et mérite d'être intégrée au budget. Une ligne qu'on ne sait pas justifier à ce stade ne survivra pas aux arbitrages.
Sur cette base se construisent deux ou trois scénarios budgétaires. Chacun tient en quatre éléments :
- La baseline - le narratif de l'intention du budget, résumé en trois phrases.
- L'année en cours - le budget CAPEX / OPEX, avec réalisé, budget et forecast par nature de dépense
- L'année à venir - le budget CAPEX / OPEX proposé, avec les marqueurs principaux, accompagnée des marqueurs roadmap / projet
- Le bridge financier - l'écart entre les deux exercices, expliqué par les macro-écarts par nature de dépense - y compris ce qui a été reporté : obsolescence repoussée, dette technique, montées de version différées. Un budget « propre » qui sous-investit chroniquement est un passif aux yeux d'un acquéreur ; mieux vaut le nommer que le laisser découvrir.
En contexte actionnarial, prolongez l'exercice : un fonds raisonne sur sa durée de détention, trois à cinq ans. Une trajectoire pluriannuelle des coûts, même en ordres de grandeur, vaut mieux qu'un budget mono-exercice sec.
Deux ou trois scénarios assumés valent mieux qu'un chiffre unique indéfendable : chaque scénario dit ce qu'il contient et ce qu'il sacrifie, et c'est la direction qui choisit - en connaissance de cause. Les marges de manœuvre s'affichent, elles ne se cachent pas : une provision pour aléas nommée et bornée est parfaitement défendable ; la même somme diluée dans les lignes ne l'est pas.
Étape 6 - défendre : la DAF d'abord, le COMEX ensuite
La première présentation se fait à la DAF, et son objet est précis : challenger les hypothèses. Mieux vaut un contrôle de gestion exigeant à ce stade qu'un COMEX qui découvre les failles en séance. Une fois les hypothèses alignées, la présentation au COMEX et à l’actionnariat raconte une vraie histoire - l'intention du budget, les scénarios, les arbitrages à prendre -, pas des lignes de budget qui s'empilent. Le découpage Run/Build et le modèle de restitution COMEX font l'objet d'un article dédié.
Étape 7 - un budget ne vaut que suivi
Le budget voté n'est pas une prédiction : c'est un instantané pris avec les hypothèses connues au moment de sa constitution. C’est celui qu'on oppose au réalisé chaque mois. Sans suivi de la consommation au fil de l'eau - commandes, factures, jours consommés, reliés à leurs lignes budgétaires -, le plus beau budget du monde meurt en quelques semaines.
C'est cette mécanique de suivi qui fait l'atterrissage : la dérive se voit le mois où elle commence, pas à la clôture. Sur les portefeuilles que je pilote - 8 à 20 M€ -, c'est elle qui tient l'écart entre budget initial et clôture sous les 5 %. Et c'est elle, bien plus que le document budgétaire lui-même, qu'un acquéreur attentif remarquera.
L'outillage de ce suivi est décrit pas à pas dans un autre article : Un cockpit de pilotage DSI dans Notion.
Et maintenant ?
Si votre cycle budgétaire s'ouvre dans les prochaines semaines, prenez les étapes dans l'ordre : la cartographie des applications et la collecte des contrats se lancent dès maintenant, les hypothèses et les chiffrages suivront. Et si votre contexte actionnarial rend l'exercice plus sensible que d'habitude - ou si vous voulez simplement un budget que vous pourrez défendre, puis tenir -, c'est mon métier.
Réservez 30 minutes pour diagnostiquer votre pilotage →
Pour aller plus loin : le CIO-Office externalisé pour DSI · Un budget IT lisible en Run/Build · Un cockpit de pilotage DSI dans Notion
