Un budget informatique se construit en quelques semaines et se défend toute l'année. La difficulté n'est pas de le bâtir : elle est de tenir ensemble la part contrainte, qui ne se discute pas, et la part projets, qui se discute tout le temps.
Un budget informatique mélange deux natures de dépense qui n'obéissent pas aux mêmes règles.
Le run — infrastructure, licences, support, maintenance, renouvellement du parc — est largement contraint. Il se prévoit à partir du réalisé des exercices précédents, augmenté des hausses connues. On ne l'arbitre qu'à la marge, et le réduire brutalement se paie l'année suivante.
Le build — les projets — est la seule part réellement discutable. C'est là que se joue l'alignement avec la stratégie, et c'est là que la direction générale attend des arbitrages argumentés.
Présenter les deux dans un tableau unique conduit invariablement au même dialogue : une demande de réduction uniforme de quelques pour cent, appliquée à des lignes dont la moitié n'est pas compressible. Les séparer change la conversation.
La part projets se pilote comme un portefeuille : chaque projet porte un budget, une charge interne, un calendrier et une priorité. Trois écueils reviennent systématiquement.
Les jours internes ne sont pas valorisés. Un projet réalisé par l'équipe interne apparaît alors gratuit face à un projet confié à un prestataire. L'arbitrage se fait sur une comparaison fausse — et l'équipe interne se retrouve engagée sur trois fois sa capacité.
La capacité n'est pas confrontée au plan. Un portefeuille validé sans plan de charge est une liste de vœux. La question n'est pas « peut-on financer ces projets ? » mais « a-t-on les gens pour les faire, aux mois où ils sont prévus ? ».
La conduite du changement est oubliée. Faire évoluer un système d'information est un projet de transformation ; le budget de formation, d'accompagnement et de reprise de données n'est pas une variable d'ajustement.
Un budget se tient par la fréquence de sa confrontation au réalisé. Le format minimal, par poste :
| Poste | Prévu | Engagé | Réalisé | Ce qu'on en fait |
|---|---|---|---|---|
| Infrastructure & cloud | oui | oui | oui | Suivre les renouvellements et les hausses de tarif |
| Licences | oui | oui | oui | Auditer le nombre de postes réellement utilisés |
| Prestations externes | oui | oui | oui | Poste le plus volatil : suivre l'engagé, pas le facturé |
| Projets | oui | oui | oui | Coût final prévisionnel par projet, pas dépense cumulée |
| Réserve | oui | — | oui | Tracée à part, sinon elle se consomme sans décision |
La colonne engagé est celle qui manque le plus souvent, et c'est celle qui prévient les mauvaises surprises : sur les prestations externes, l'engagement contractuel précède la facture de plusieurs mois.
Voir la page Solution DSI.
Ce que cet article décrit se pilote dans ces modules de CESAR.TEAM.
Dites-nous comment vous pilotez aujourd'hui : structure, rythme de clôture, systèmes en place. Nous préparons une démonstration sur un contexte comparable.