Le ratio run/build n’est plus une ligne budgétaire : c’est lui qui décide de votre capacité à transformer. Dans la majorité des DSI, il absorbe 60 à 70 % du budget IT — et reste constaté plutôt que piloté.

L’essentiel en 30 secondes

• Le ratio run/build se situe autour de 64 % / 36 % (CIGREF, 2023), avec une zone d’équilibre entre 60/40 et 70/30 selon la taille et la maturité de l’organisation.
• En 2026, le run est un poste incompressible : quand le budget se resserre, ce n’est pas l’exploitation qui absorbe le choc, c’est la transformation.
• Un ratio ne veut rien dire tant que le périmètre du run n’est pas défini : comparer sans comparer les périmètres produit une fausse réassurance ou une alerte injustifiée.
• Trois dettes invisibles gonflent le run sans déclencher aucune alerte : dette de connaissance, dette de dépendance, dette de procédure.
• L’ordre compte : mesurer, puis se référencer, puis refacturer aux équipes, puis verrouiller les nouvelles mises en production. Réduire avant d’avoir mesuré coupe au mauvais endroit.

Le marché du numérique français repart, mais lentement. Les DSI investissent, mais sur un nombre restreint de priorités. Dans cet équilibre tendu, une variable reste largement absente des discussions stratégiques : la part du budget consacrée à faire tourner l’existant. Elle est pourtant devenue le premier facteur limitant de la transformation.

Budget DSI 2026 : un marché qui repart sans élan

L’Observatoire de conjoncture Numeum-Xerfi publié le 8 juillet 2026 décrit un marché qui repart sans élan : 3 % de croissance en 2026 contre 1,8 % en 2025. La reprise est réelle mais contrainte, freinée par ce que le syndicat appelle l’attentisme des donneurs d’ordres. Cet attentisme n’est pas un climat, c’est un comportement documenté : quatre DSI sur dix reconnaissent que les incertitudes géopolitiques ont pesé sur leurs décisions, et cela se traduit très concrètement par des reports de projets pour plus d’un sur deux.

Mais réduire la situation à un marché frileux serait passer à côté de l’essentiel. Les investissements ne disparaissent pas, ils se resserrent sur quatre priorités : cybersécurité (92 %), conformité réglementaire (84 %), optimisation des dépenses contraintes (72 %) et IA productive (71 %). Ce classement dit quelque chose de précis sur l’époque. Deux de ces priorités sont subies, imposées par la menace ou la réglementation. Une troisième, l’optimisation des dépenses contraintes, est le seul levier réellement offensif de la liste, et il concerne directement le coût de l’existant. Autrement dit, quand les DSI ne peuvent plus investir librement, la première chose qu’elles cherchent à reprendre en main, c’est leur propre run. Sept sur dix en font une priorité déclarée. Le sujet est donc partout dans les arbitrages, et nulle part dans les discours.

Qu’est-ce que le ratio run/build et pourquoi il n’est pas piloté

La répartition entre le run, ce qui maintient le système d’information en condition opérationnelle, et le build, ce qui le fait évoluer, n’a rien d’une nouveauté. Le CIGREF l’a intégrée dès 2006 à son modèle de benchmarking des coûts informatiques, mis à jour en 2018 pour tenir compte du cloud, de l’agilité et de la sécurité. Si l’indicateur existe depuis vingt ans, ce n’est pas par tradition comptable, c’est parce qu’il conditionne tout le reste.

Quel est le bon ratio run/build ?

Les ordres de grandeur disponibles situent ce ratio autour de 64 % de run pour 36 % de build (CIGREF, 2023), une étude 2026 plaçant la zone d’équilibre entre 60/40 et 70/30 selon la taille et la maturité de l’organisation. Ces chiffres appellent une lecture prudente, et c’est là que se joue une bonne partie de l’expertise : un ratio ne veut rien dire tant qu’on n’a pas défini le périmètre du run. Dans la logique CIGREF, celui-ci englobe l’exploitation, les licences, l’infrastructure, mais aussi le cloud, le support et l’hébergement. Comparer son ratio à celui d’un pair sans comparer les périmètres produit une conclusion fausse rassurante ou une alerte injustifiée, jamais une décision utile.

Un ratio run/build constaté, jamais piloté

Le vrai enseignement n’est donc pas le niveau du ratio, c’est le rapport que la DSI entretient avec lui. Dans la majorité des organisations, il est constaté, pas piloté. On le découvre au moment de l’arbitrage budgétaire, quand il ne reste plus de marge pour agir. Une DSI qui apprend sa répartition run/build en septembre n’a plus un indicateur entre les mains, elle a une contrainte qu’elle n’a pas choisie.

Pourquoi le coût du run devient urgent en 2026

Trois mouvements se combinent cette année pour rendre l’inaction coûteuse.

1. Le run est devenu structurellement intouchable. Le baromètre Abraxio sur les budgets 2026 le classe, avec les ressources humaines, parmi les postes incompressibles, pendant que le build et l’innovation encaissent le resserrement. La conséquence est mécanique et rarement énoncée aussi clairement : quand le budget se tend, ce n’est pas l’exploitation qui absorbe le choc, c’est la transformation. Chaque euro de run mal maîtrisé n’est pas un euro de trop sur une ligne, c’est un euro retiré à la capacité de l’entreprise à évoluer.
2. La conversation budgétaire s’est durcie. Deux tiers des DSI anticipaient pour 2026 des négociations complexes avec leur direction financière, en hausse de dix-huit points en un an. Ce bond n’est pas anecdotique, il signale un changement de rapport de force : la DSI ne présente plus un budget, elle le défend. Et l’on ne défend bien que ce qu’on sait expliquer. La pédagogie budgétaire, longtemps considérée comme un supplément d’âme, devient une compétence de survie.
3. La structure de coût se déplace vers le poste le plus difficile à contenir. Selon Forrester, la masse salariale et les prestations externes pèsent en moyenne 35 % et 25 % du budget d’une DSI, le logiciel 23 %. Or c’est précisément le logiciel qui subit le plus l’inflation des éditeurs, et il alimente très largement le run. La pression sur les coûts ne vient donc pas d’où l’on regarde habituellement, elle vient d’un poste que beaucoup de DSI ne décomposent pas finement.

Un signal faible à surveiller : l’IA agentique

À ces trois mouvements s’ajoute un signal faible qui mérite qu’on s’y arrête. Un peu plus d’une DSI sur cinq estime déjà que l’IA agentique pourrait réduire certaines dépenses logicielles. Si l’anticipation se confirme, une part du run deviendrait, pour la première fois depuis longtemps, réductible par la technologie plutôt que seulement par la négociation. Mais cette opportunité a une condition d’entrée : on ne peut automatiser que ce que l’on a d’abord cartographié. Les DSI qui capteront ce gain sont celles qui connaissent déjà le détail de leur exploitation. Les autres regarderont passer une économie qu’elles ne sauront pas où appliquer.

Run structurel ou run de dette : ce que le ratio ne dit pas

Un ratio run/build donne un niveau, jamais une composition. Et c’est dans la composition que tout se joue, car il faut distinguer le run structurel, prix normal du fonctionnement, du run de dette, prix différé de décisions passées. Cette distinction est le cœur du métier, parce qu’aucun tableau de bord financier ne la fait spontanément. Les deux se ressemblent sur une ligne budgétaire. Ils n’appellent pas du tout les mêmes décisions.

La dette de connaissance

Des systèmes que deux ou trois personnes seulement savent faire fonctionner. Sa dangerosité tient à son invisibilité totale. Rien ne casse, aucun indicateur ne se dégrade, tout va bien tant que ces personnes sont là. Le coût n’apparaît qu’au moment du départ, sous forme de plusieurs mois de rétro-ingénierie, c’est-à-dire au pire moment et sans budget prévu.

La dette de dépendance

Des composants maintenus par contrainte plutôt que par choix, une version d’OS gelée parce qu’une application métier ne suit pas, un service propriétaire dont sortir imposerait une réécriture. Son coût n’est pas une facture, c’est une liberté perdue : chaque dépendance transforme une décision future en négociation. Le sujet est d’ailleurs devenu réglementaire, le Data Act et la loi SREN qui le transpose imposant désormais aux hébergeurs une obligation de transfert des données et interdisant des frais de réversibilité prohibitifs. Ce que le régulateur reconnaît ainsi, c’est que la dépendance a une valeur, et donc un coût.

La dette de procédure

Des opérations manuelles répétées faute d’avoir été automatisées. Prise isolément, chacune est négligeable, ce qui explique que personne ne la remonte. Cumulée sur un exercice, elle représente pourtant souvent l’équivalent de plusieurs postes, dispersés en fragments dans les plannings d’astreinte.

Ces trois dettes partagent le trait qui les rend si difficiles à traiter : elles ne provoquent pas d’incident, elles consomment. Or un incident se défend en comité de direction, une consommation silencieuse non. C’est exactement pourquoi elles survivent aux plans de réduction : on coupe ce qui fait du bruit, on laisse ce qui coûte en silence.

Comment réduire le coût du run : 5 leviers, dans l’ordre

Réduire le coût du run ne se pilote pas en coupant une ligne : cela suppose d’agir sur le ratio run/build à travers cinq leviers, dans l’ordre.

1. Mesurer avant de réduire. L’erreur la plus commune est de vouloir réduire avant d’avoir mesuré. Le suivi des temps, dans une DSI, reste un sujet sensible, souvent vécu comme un excès de contrôle. Il demeure la seule façon d’objectiver un arbitrage, et un inventaire honnête vaut toujours mieux qu’un plan de réduction prématuré qui coupera au mauvais endroit.
2. S’appuyer sur un référentiel commun. L’intérêt du modèle CIGREF n’est pas normatif, il est pratique : il permet de se comparer à d’autres DSI, de renforcer le pilotage économique et surtout de dialoguer avec les métiers et la direction générale sur une base partagée. Sans périmètre commun, le benchmark externe ne compare rien.
3. Attribuer les coûts aux équipes qui les génèrent. Tant que le run est une enveloppe centrale, il n’appartient à personne et personne ne l’optimise. Dès qu’une équipe voit sa propre consommation, les arbitrages se font d’eux-mêmes, sans qu’il soit besoin de les imposer.
4. Verrouiller les nouvelles mises en production. Une règle simple évite de creuser la dette du prochain exercice : aucun nouveau système ne passe en production sans procédure d’exploitation écrite et testée par quelqu’un qui ne l’a pas conçu. Cela ralentit les mises en production, et c’est précisément l’objectif, car chaque système livré sans cette étape est une dette de connaissance créée sciemment.
5. Ne jamais externaliser la compréhension du run. Externaliser l’exécution du run est un choix légitime, externaliser sa compréhension ne l’est jamais. Une DSI qui ne sait plus ce qui tourne chez elle a délégué bien plus qu’une charge, elle a délégué sa capacité d’arbitrage, y compris sur les projets de transformation qu’elle croit maîtriser.

Notre retour terrain sur les environnements Ops et Cloud

Chez Rædy, nous intervenons sur des environnements Ops et Cloud où ce déséquilibre du ratio run/build saute aux yeux dès les premiers échanges. Le constat récurrent n’est pas que le run coûte cher, c’est qu’il coûte sans être expliqué. Les équipes savent que le système fonctionne. Elles savent rarement dire pourquoi il coûte ce qu’il coûte, ni ce qui se passerait si telle personne partait. Cette zone d’ombre est confortable tant que rien ne bouge, et intenable dès qu’il faut négocier.

Or c’est exactement ce que la conjoncture 2026 ne pardonne plus. Quand la pression sur les prix et l’attentisme des donneurs d’ordres se conjuguent, la DSI qui sait décomposer son run ne négocie pas mieux, elle négocie autrement : elle ne défend pas une enveloppe, elle défend des choix documentés. Face à une direction financière, la différence entre les deux postures est décisive.

Numeum referme son observatoire sur un avertissement qui vaut à l’échelle d’un pays comme à celle d’une DSI : différer l’investissement revient le plus souvent à accumuler du retard. Nous y ajoutons une précision qui résume notre métier. On n’investit que ce qu’on a d’abord libéré, et on ne libère que ce qu’on a d’abord mesuré. Le run n’est pas l’adversaire de la transformation. Il en est la condition de départ.

FAQ — ratio run/build et coût de l’existant

Quelle différence entre run structurel et run de dette ?

Le run structurel est le prix normal du fonctionnement, assumé et identifiable. Le run de dette est le prix différé de décisions passées : il se répartit entre dette de connaissance, dette de dépendance et dette de procédure. Aucun tableau de bord financier ne fait spontanément cette distinction, ce qui explique que le run de dette survive aux plans de réduction.

Comment réduire le coût du run ?

Dans l’ordre : mesurer avant de réduire, s’appuyer sur un référentiel commun de type CIGREF, attribuer les coûts aux équipes qui les génèrent, puis interdire toute mise en production sans procédure d’exploitation écrite et testée. Réduire avant d’avoir mesuré conduit à couper au mauvais endroit.

Faut-il externaliser son run ?

Externaliser l’exécution du run est un choix légitime. Externaliser sa compréhension ne l’est jamais. Une DSI qui ne sait plus ce qui tourne chez elle a délégué sa capacité d’arbitrage, y compris sur les projets de transformation qu’elle croit maîtriser.