Il est notoire qu’il est difficile de convaincre le directeur financier d’allouer des fonds pour la modernisation de l’ITSM. Contrairement à une nouvelle application, à une solution d’analyse de données ou à un outil destiné à garantir certaines normes de sécurité, un investissement dans l’écosystème de gestion des services informatiques n’a qu’un lien indirect avec les revenus ou un avantage concurrentiel, même lorsque les raisons opérationnelles sont évidentes. Il en résulte que l’IT dans son ensemble est perçu avant tout comme un poste de coût, dont les frais sont à reporter ou à réduire pour donner la priorité à une autre dépense qu’il est plus facile d’associer à de nouvelles recettes.
Afin de lutter contre cette perception, décrire en détail les fonctionnalités d’une nouvelle plateforme ITSM ne suffit pas. Il faut un business case structuré, conçu dans un langage que la direction financière comprend, en insistant sur le coût de la situation actuelle, la réduction des risques et le retour sur investissement. Cet article propose aux DSI et aux directeurs informatiques un plan en quatre étapes pour construire un business case capable d’obtenir l’approbation de la direction financière, surtout lorsque le budget est sous pression.
Étape 1 : combien coûte le statu quo ?
La première des quatre étapes consiste à rendre visible un coût que personne ne mesure pour l’instant. Le maintien du statu quo n’est pas gratuit, il s’accompagne d’un coût qui n’apparaît tout simplement pas dans les bilans. Pour le rendre apparent, il est nécessaire de quantifier quatre voire cinq postes.
Le premier est la perte de productivité des opérateurs du service desk, absorbés par des activités manuelles et répétitives qu’un processus bien structuré pourrait automatiser. La quantifier est assez simple : il suffit de multiplier le coût horaire du personnel concerné par les heures consacrées à ces tâches à faible valeur ajoutée. On obtient ainsi un chiffre souvent surprenant (dans le sens négatif du terme), même pour la direction informatique.
Le deuxième est la surcharge générée par les escalades : plus une demande est transférée vers les niveaux de support spécialisés, plus son coût de traitement augmente. Une bonne façon d’évaluer ce poste de coût consiste à comprendre comment calculer le coût réel par ticket, réouvertures comprises.
Le troisième est constitué par les interruptions de service non planifiées, liées à une gestion des changements inadéquate. Selon une enquête de l’ITIC sur le coût des interruptions, pour plus de 90 % des moyennes et grandes entreprises, une heure d’arrêt coûte plus de 300 000 dollars, hors pénalités éventuelles.
Le quatrième est l’exposition à la conformité : des processus non standardisés et une traçabilité incomplète se traduisent par des échecs d’audits et des amendes potentielles.
À ces postes de coût s’en ajoute un dernier, moins évident, mais tout aussi concret : celui de la rotation du personnel. D’après un récent rapport de TeamViewer sur la friction numérique, 69 % des travailleurs interrogés estiment que les frustrations liées à la technologie ont contribué à la rotation du personnel au sein de leur organisation. De plus, le remplacement d’un seul salarié nécessite en moyenne huit semaines d’intégration. Considérés dans leur ensemble, ces chiffres décrivent une situation que la direction financière ne peut ignorer : le statu quo entraîne une érosion constante des marges.
Enfin, il existe un argument sur lequel repose une grande partie du business case : éviter ne serait-ce qu’un seul incident grave par an est souvent suffisant pour rentabiliser l’intégralité de l’investissement sur l’ITSM. Pour utiliser cet argument de façon efficace, il faut cependant disposer d’une base de référence fiable des coûts actuels ; sans cela, toute estimation des bénéfices financiers attendus reste facilement contestable lors d’une évaluation financière. La collecte de ces données doit donc être abordée avant l’élaboration du business case.
Étape 2 : changer le cadre de référence
La deuxième étape concerne la manière dont l’investissement est présenté. Un directeur financier répond mieux à la réduction des risques qu’à l’ajout de nouvelles fonctionnalités technologiques. Si la modernisation de l’ITSM est présentée comme l’adoption d’une plateforme plus récente avec des workflows améliorés, celle-ci sera classée parmi les dépenses facultatives. Si elle est dépeinte comme un moyen de réduire des risques concrets et mesurables, elle sera alors placée parmi les investissements nécessaires.
Les risques à mettre en avant sont ceux que les dirigeants d’entreprise redoutent déjà : l’interruption des services causée par des changements mal gérés, l’exposition réglementaire due à des processus non documentés, les incidents de sécurité résultant d’un contrôle insuffisant des modifications et le risque lié aux connaissances non partagées, une vulnérabilité qui se concrétise lorsque des compétences essentielles détenues par quelques personnes se perdent au moment où celles-ci quittent l’entreprise.
L’ITSM est une forme d’assurance opérationnelle
Dans un business case efficace, on ne se contente pas de présenter la solution préférée : on définit le problème, on compare les options, y compris celle de ne rien changer, avec son coût associé, et on quantifie les risques liés à chaque option. Une modification déployée sans un processus de contrôle adéquat, par exemple, peut provoquer une interruption quantifiable en heures d’arrêt et en revenus perdus, ce qu’un processus de gestion des changements mature aurait intercepté en amont. Dans ce cadre, l’ITSM est une forme d’assurance opérationnelle ; la demande de financement ne sert plus à acheter un outil, mais à réduire une perte probable.
Étape 3 : utiliser le budget destiné à l’IA comme levier de financement
La troisième étape s’appuie sur une tendance désormais bien établie sur le marché. Alors que les budgets informatiques traditionnels sont constamment surveillés à la loupe, ceux destinés à l’intelligence artificielle continuent de croître : selon Gartner, les dépenses mondiales en IA atteindront 2,59 billions de dollars d’ici fin 2026, constituant une hausse annuelle de 47 %. De cette tendance découle une réelle occasion pour le DSI.
L’adoption de l’IA dépend certes de la disponibilité des ressources financières, mais aussi et surtout de la maturité des processus organisationnels. Il s’agit d’une observation décisive : une IA entraînée sur des données de service fragmentées, sur une base de connaissances désorganisée et sur des processus non structurés produit des résultats peu fiables. La modernisation de l’ITSM peut alors être présentée comme l’infrastructure préparant l’organisation à la mise en œuvre d’initiatives d’IA. Des données propres, des workflows cohérents et une base de connaissances bien organisée et systématiquement mise à jour sont les prérequis pour que toute initiative d’intelligence artificielle dédiée au support IT porte ses fruits.
L’intérêt pour ces solutions est d’ailleurs déjà répandu : toujours selon l’enquête TeamViewer citée plus haut, 48 % des travailleurs estiment que l’IA peut réduire les dysfonctionnements technologiques et la moitié d’entre eux se déclare prête à laisser l’IA gérer des tâches de base comme la résolution de problèmes simples ou la réinitialisation de mots de passe. Présenter la modernisation de l’ITSM comme la base requise pour les initiatives d’IA dans le support IT, plutôt que comme un poste isolé du budget informatique, la rattache à un domaine de dépenses en expansion plutôt qu’en réduction. Pour le DSI, cela signifie déplacer la demande de financement du budget informatique traditionnel, de plus en plus disputé, vers le poste de coût qui connaît la croissance la plus rapide de l’organisation dans son ensemble.
Étape 4 : définir des attentes de ROI qui tiennent face à la première évaluation annuelle
La quatrième étape est la plus délicate, car c’est celle sur laquelle le business case est finalement jugé. La tentation, pour obtenir l’approbation des décideurs, est d’en promettre trop : des réductions de coûts très importantes en très peu de temps et des retours quasi immédiats. C’est pourtant la façon la plus rapide de perdre toute crédibilité lors de la première évaluation de fin d’exercice, quand les chiffres réels ne correspondent pas à ceux promis. Une prévision de ROI solide et durable se construit sur des objectifs mesurables et échelonnés dans le temps, ancrés dans la base de référence définie au départ.
Un objectif réaliste, par exemple, est une réduction progressive des délais de résolution et du coût par ticket au cours de la première année, avec des indicateurs intermédiaires vérifiables dès les premiers mois. Il est préférable de démontrer rapidement un retour partiel mais concret, plutôt que d’attendre un résultat global difficile à prouver.
L’erreur la plus courante à éviter
Il convient de distinguer honnêtement les bénéfices tangibles, tels que la réduction du volume de tickets, du nombre de violations des accords de niveau de service, du coût par ticket ou du nombre d’heures d’interruption de service, de ceux moins concrets comme la satisfaction des utilisateurs et la réduction de la rotation du personnel, en évitant de présenter ces derniers comme s’ils étaient mesurables avec la même précision que les premiers.
Et il est essentiel d’éviter l’erreur la plus courante : sous-dimensionner les ressources dédiées non seulement à la mise en œuvre technique, mais aussi à l’adoption par les opérateurs et les utilisateurs finaux, ce dont dépend le retour réel. Une solution adoptée mais utilisée de manière inadéquate ne produit aucun ROI et compromet la crédibilité de ceux qui ont soutenu l’investissement. Mieux vaut un retour plus prudent mais solide, vérifiable trimestre après trimestre, qu’une promesse ambitieuse destinée à être démentie lors de l’évaluation de fin d’exercice.
D’un centre de coûts à un centre de valeur
Pour le DSI, le business case est l’outil qui traduit la valeur de l’IT dans le langage des affaires. S’il est bien construit, le business case peut changer la façon dont l’ITSM est perçu : son image passe d’un coût inévitable à un investissement qui réduit les risques, dégage de la productivité et prépare l’organisation aux technologies à venir.
Le parcours, lorsque le budget informatique est limité, est celui que nous avons identifié dans cet article : quantifier le coût de la situation actuelle à partir d’une base de référence réelle, présenter la modernisation comme une réduction des risques, la rattacher au budget croissant de l’IA en la positionnant comme infrastructure habilitante et fixer des attentes de retour sur investissement qui résistent à l’épreuve des faits. Il s’agit de démontrer, données à l’appui, que maintenir le statu quo est de loin l’option la plus coûteuse.
FAQ
- Pourquoi est-il difficile de justifier un investissement sur l’ITSM ?
Parce que, contrairement à une application donnée ou à un outil de sécurité spécifique, l’ITSM est difficile à rattacher directement aux revenus. C’est pourquoi il faut un business case qui en traduise la valeur par des coûts évités et des risques réduits. - Comment quantifier le coût du statu quo ?
En mesurant des postes de coût concrets à partir de bases de référence réelles : productivité perdue par le personnel du service desk, surcharge des escalades, interruption de service non planifiée due à une gestion des changements inadéquate, exposition à la conformité et coût de la rotation du personnel. - Que signifie positionner l’ITSM comme « infrastructure de préparation à l’IA » ?
Cela signifie le présenter comme la base habilitante (données propres, processus structurés, connaissances organisées) sans laquelle les initiatives d’IA ne sauraient produire des résultats fiables, rattachant ainsi le projet au budget IA en croissance. - Comment établir des attentes de ROI réalistes ?
Avec des objectifs mesurables et échelonnés, ancrés dans une base de référence et vérifiables dès le premier trimestre. Mieux vaut un ROI prudent mais démontrable qu’une promesse ambitieuse qui ne passe pas l’évaluation de fin d’exercice.
2025 Gartner® Market Guide des Plateformes ITSM
