Comment tu justifies 20 M£ de dépenses d'ingénierie ?

Je connais la galère qu’est la justification des coûts d’ingénierie logicielle. Que ce soit pour expliquer des dépassements de projet à des directeurs financiers en grande entreprise ou pour projeter le burn rate à des investisseurs en startup, la conversation est toujours la même.

Le DAF ou l’investisseur demande : « On dépense 15 millions de £ en ingénierie. Qu’est-ce qu’on en tire ? »

Tu ouvres ton tableur. Tu as les effectifs. Tu as les grilles de salaires. Tu as la liste des projets en cours. Mais quand on te demande « Combien a vraiment coûté la refonte du checkout ? » ou « Quel est le ROI de cette migration de plateforme de six mois ? », tu improvises.

J’ai dirigé des équipes d’ingénieurs dans des startups et dans des organisations plus grandes, avec 30 ingénieurs au maximum à la fois. L’échelle change, mais le problème est le même partout : personne ne sait te dire ce que les choses coûtent vraiment.

Ni les fonctionnalités. Ni les projets. Ni les « initiatives stratégiques » qui avalent des trimestres entiers. L’argent disparaît dans un trou noir étiqueté « Ingénierie » et tout le monde espère qu’il ressortira de l’autre côté sous forme de chiffre d’affaires.

Et il n’y a pas que les salaires. Ces 15 millions de £ comprennent les gens, oui, mais aussi les dépenses d’IA, les licences logicielles, l’infrastructure cloud et le matériel. La facture complète de l’ingénierie. Pourtant, la plupart des organisations n’arrivent à ventiler aucun de ces postes.

J’ai connu les deux mondes. En startup, j’ai dû projeter des coûts à des investisseurs qui voulaient comprendre l’unit economics avant la série A. En entreprise, j’ai dû expliquer à des directeurs financiers pourquoi un projet de six mois en visait désormais douze. Les excuses changent, le problème de fond reste : il nous manque l’infrastructure de base pour mesurer ce que coûte réellement le travail d’ingénierie.

Le problème n’est pas nouveau, mais il empire

Voilà ce que j’entends de presque tous les responsables tech à qui je parle :

« On finit par ranger les coûts dans un pot commun parce qu’on n’arrive pas à boucler le mois. »

Traduction : on ne sait pas ce qu’on dépense pour quoi, alors on balance tout dans un seau générique et on l’appelle « Équipe Plateforme T3 ». La finance déteste ça. Le conseil d’administration pose des questions. Mais que faire d’autre ?

« Si on coupe 20 % des effectifs ou qu’on déplace des équipes, je veux voir l’impact tout de suite. »

Impossible. Ton « outil de planification » est un tableur de 47 onglets qui casse si tu supprimes une ligne. Le temps que tu aies modélisé le scénario, le conseil a déjà tranché au feeling.

« On dépense 20 millions de £ en salaires, et je dois montrer qu’on les dépense bien. »

Celle-là empêche les CTO de dormir. Tu sais que tu dépenses bien. Tu sais que tes équipes sont talentueuses. Mais tu ne peux pas le prouver avec des données, parce que les données n’existent pas.

« On doit replanifier tous les quelques mois, quand les priorités ou les équipes bougent. »

Et chaque replanification te coûte trois jours de réunions, une nouvelle salve de tableurs, et le même calvaire que le trimestre dernier.

Pourquoi la planification meurt dès qu’on la livre

La plupart des organisations d’ingénierie planifient par trimestre. Tu passes 4 à 6 semaines à construire le plan du trimestre suivant. À la semaine sept, quelqu’un démissionne. À la semaine neuf, une « priorité stratégique » surgit de nulle part. À la semaine douze, ton plan d’origine est un roman historique.

Voici comment le temps des responsables d’ingénierie se répartit vraiment :

Réunions (planification, allocation, revues) : 17,9 heures par semaine, soit 7 heures de plus que les contributeurs individuels
Temps fragmenté : 7,1 heures par semaine, avec une pénalité de productivité de 40 %
Temps de concentration : 10,4 heures par semaine, dont 2,6 heures seulement sans interruption

Ces 17,9 heures de réunions par semaine ? Une bonne part touche à la planification : lancements de planification trimestrielle qui s’étirent sur 4 à 6 semaines, revues de mi-trimestre, discussions d’allocation des ressources, justifications budgétaires. Quand tu fais le calcul, les responsables d’ingénierie passent à peu près un tiers de chaque trimestre à planifier le suivant. Tu as perpétuellement six semaines de retard sur la réalité, parce que le temps que tu finisses de planifier, le monde a changé.

Et que planifies-tu ? Selon les recherches de McKinsey, les équipes d’ingénierie passent 40 à 60 % de leur temps en maintenance et en exploitation plutôt que sur de nouvelles capacités¹. Mais peux-tu me dire quels 40 à 60 % ? Peux-tu me montrer quels ingénieurs travaillent sur quels projets, et si ces projets relèvent du CapEx ou de l’OpEx ?

Évidemment que non. Parce que suivre ça demande de mettre à jour un tableur chaque semaine, et on sait tous que ça n’arrive jamais.

L’angle mort CapEx contre OpEx

C’est là que ça devient douloureux. Ton DAF doit savoir si le travail d’ingénierie construit de nouvelles capacités (CapEx) ou entretient les existantes (OpEx). Ce n’est pas de la pinaillerie comptable : ça change fondamentalement la façon dont le travail est financé et mesuré.

McKinsey a constaté que dans certaines organisations, les développeurs passent plus de 50 pour cent de leur temps à gérer la dette technique ². C’est la différence entre une organisation d’ingénierie stratégique et une équipe qui éteint des incendies en permanence.

À l’inverse, les entreprises du quartile supérieur (selon le Developer Velocity Index) passent 33 pour cent de temps en moins sur du travail manuel sans valeur ajoutée, ce qui leur libère du temps pour innover ³.

Le plus fou, c’est que le problème est quasi universel. Une enquête de 2023 a montré que 91 % des responsables IT considèrent la dette technique comme leur principal obstacle à l’innovation ⁴. Pourtant, beaucoup d’entreprises ne « consacrent que 15 à 20 pour cent du budget IT à résorber la dette technique », une enveloppe que McKinsey juge souvent insuffisante ².

Peux-tu montrer à ton conseil dans quelle case tombe chaque ingénieur ? Peux-tu démontrer que tu passes de 50 % de frein lié à la dette technique à 30 % ? Ou tu espères juste que personne ne posera la question ?

La cocotte-minute du private equity

Voilà pourquoi c’est plus important que jamais : les rachats par des fonds de private equity ont rebondi à 602 milliards de $ en 2024, une hausse de 37 % sur un an ⁵. Le secteur de la tech en a été le principal moteur, avec 33 % de toutes les opérations de rachat en valeur dans le monde ⁵.

Mais la donne a changé. Regarde comment les fonds créent de la valeur au fil du temps :

L’excellence opérationnelle est passée de 18 % à 47 % de la création de valeur. L’ingénierie financière, c’est-à-dire l’effet de levier et l’expansion des multiples, est tombée de 51 % à 25 %.

Qu’est-ce que ça change pour toi ? Si tu diriges l’ingénierie d’une entreprise détenue par un fonds, tu as 90 jours pour montrer comment tu dépenses l’argent et 12 à 24 mois pour montrer des gains d’efficacité significatifs.

« On recrute plus d’ingénieurs », ce n’est pas un plan. « On alloue 8,5 ETP à ces trois projets avec ces retours attendus », c’est un plan.

Et devine ce que demandent les operating partners des fonds :

Le vrai coût par projet (pas des estimations, pas des devinettes)
La répartition OpEx et CapEx dans toute l’organisation d’ingénierie
Les taux d’utilisation des ressources
Les coûts de développement des fonctionnalités, avec des chiffres réels
Une feuille de route d’expansion des marges, avec les leviers d’efficacité de l’ingénierie

La plupart des responsables tech ne savent répondre à rien de tout ça.

La taxe d’erreur du tableur

Voilà de quoi te faire peur : des revues académiques, dont une analyse récente sur 35 ans, trouvent systématiquement que 88 à 94 % des tableurs utilisés dans des décisions d’affaires critiques contiennent des erreurs ⁶. Ce n’est pas une coquille. Presque tous les tableurs qui pilotent la planification de tes coûts d’ingénierie contiennent des fautes.

Et pourtant, PwC indique que 80 % des organisations s’appuient encore sur des tableurs pour leur planification et analyse financières (FP&A) ⁷.

Ce n’est pas un problème technique. C’est une crise d’organisation. Quand ton DAF ne fait pas confiance à tes chiffres parce qu’ils sont construits dans Excel, tu perds en crédibilité. Quand il demande une analyse de scénarios et qu’il te faut trois jours pour copier des onglets, tu perds en influence.

Ce décalage est endémique. Workday a constaté que seuls 30 % des DAF se disent en phase avec leurs DSI sur la feuille de route digitale et technologique de leur entreprise ⁸. Comment s’aligner quand on ne parle pas la même langue ? La finance parle centres de coûts et prévisions trimestrielles. L’ingénierie parle story points et vélocité de sprint.

Ce qui nous manque : une unité minimale viable

Le problème n’est pas qu’il nous faut de meilleurs diagrammes de Gantt. C’est qu’on n’a pas d’unité minimale viable pour mesurer le travail d’ingénierie.

La finance a une hiérarchie claire :

Lignes comptables → Centres de coûts → Départements → Dépenses totales

L’industrie a :

Composants → Produits → Lignes de production → Volume produit

Et le logiciel ?

Des story points (sans signification hors de ton équipe)
Des fonctionnalités (trop granulaires)
Des produits (trop larges)
De l’« investissement plateforme » (ça peut vouloir dire n’importe quoi)

Les startups sont particulièrement aveugles. Demande à n’importe quel fondateur combien a coûté son nouveau tunnel de paiement, pas en story points, mais en argent dépensé en salaires, en frais généraux et en coût d’opportunité, et tu auras un haussement d’épaules.

C’est ce qu’on répare chez flowstate. J’ai commencé à appeler cette discipline le Workforce Engineering : concevoir délibérément la façon dont une organisation déploie son travail pour produire des résultats. Je t’en dis plus bientôt.

La méthode flowstate : le Workforce Engineering en pratique

On ne construit pas un énième outil de gestion de projet. On construit un cadre pour la façon dont les organisations d’ingénierie devraient planifier, suivre et mesurer le travail.

Vois ça comme :

Agile, c’était la méthodologie de développement logiciel
The Linear Method, c’est le suivi des tickets et le flux produit
La méthode flowstate, c’est l’économie de l’ingénierie et la visibilité sur les coûts

Le principe de base : l’investissement en ingénierie doit s’organiser autour de paris, pas de backlogs.

Les projets comme paris minimums viables

Là, on a des opinions tranchées. Dans la méthode flowstate, un projet, c’est :

Au minimum 1,0 ETP de la capacité mensuelle d’une équipe
Au maximum 4 projets simultanés par équipe et par trimestre
Porté par une seule équipe autant que possible
Aligné sur un centre de coûts pour que la finance puisse le suivre
Adapté aux compétences, pour que les équipes aient les bonnes capacités

Pourquoi 1,0 ETP minimum ? Parce que tout ce qui est plus petit n’est pas un pari, c’est une tâche qui se fait passer pour de la stratégie. Si tu n’es pas prêt à y consacrer au moins un mois-personne, tu n’es pas sérieux.

Pourquoi 4 au maximum par trimestre ? Parce que l’attention est une ressource rare. Une équipe qui tente de mener plus de quatre choses importantes en même temps n’en fait bien aucune.

Cette structure te donne :

Une vraie visibilité sur les coûts : tu sais ce qu’a coûté « refaire le checkout », parce que tu vois les projets qui le composent et leur allocation d’ETP
Une planification de scénarios qui marche : tu déplaces une équipe ? Tu vois tout de suite quels projets perdent de la capacité
Un vrai suivi du ROI : tu peux mesurer si le pari a payé, parce que tu sais ce que tu as parié
Un équilibrage des compétences : tu fais correspondre les besoins du projet aux capacités des équipes, pas seulement aux effectifs, mais aux compétences réelles

Les gens, ce n’est pas que des ETP

C’est là que la plupart des outils de planification d’ingénierie échouent : ils traitent tout le monde comme des ressources interchangeables. flowstate non.

On suit :

Le rôle (Frontend Engineer, Backend Engineer, DevOps, etc.)
Le niveau (Junior, Mid, Senior, Staff, Principal)
Les compétences (React, Python, AWS, PostgreSQL, etc.)

Ça veut dire que, quand tu prévois un nouveau projet, tu peux te demander : « Est-ce qu’on a les bonnes compétences de disponibles ? » Pas seulement : « Est-ce qu’on a de la capacité ? »

Tu peux voir que ton équipe a 4,0 ETP de disponibles, mais seulement 1,5 ETP avec les compétences React nécessaires au travail frontend. Ça change ta planification. Peut-être qu’il faut recruter autrement. Peut-être qu’il faut ajuster le périmètre du projet. Peut-être qu’il faut former quelqu’un.

Mais au moins, tu le sais. Et c’est mieux que de découvrir le manque de compétences six semaines après le début du projet.

Les initiatives se découpent vers le bas, pas vers le haut

Le travail stratégique de grande taille, les initiatives, n’existe pas comme un bloc monolithique dans flowstate. Il se découpe en projets, chacun porté par une seule équipe avec une allocation d’ETP claire.

Du coup, quand le DAF demande « Combien a coûté la refonte du checkout ? », tu peux répondre :

« Trois projets, 12,5 ETP au total sur les T2 et T3. Environ 340 k£ de coûts chargés. Livré dans les temps. On observe 15 % de conversion en plus, ce qui représente 2,1 M£ de chiffre d’affaires annuel supplémentaire. »

Ce n’est pas une estimation au doigt mouillé. Ce sont des données.

Le cadre des paris

Chaque projet dans flowstate correspond à :

Une valeur métier : impact sur le chiffre d’affaires, économies de coûts ou positionnement stratégique
Un centre de coûts : où la dépense est comptabilisée
Un flux de valeur : quelle partie de l’entreprise en profite
Une allocation d’ETP : l’engagement exact de ressources dans le temps
Les compétences requises : les capacités dont le projet a besoin

Quand tu structures le travail comme ça, la discussion CapEx et OpEx devient simple :

Type de projet	Allocation typique	Impact business	Traitement comptable
Nouvelles capacités	20-30 % de la capacité	Croissance du CA	CapEx
Modernisation de la plateforme	15-20 %	Efficacité et passage à l’échelle	Mixte
Réduction de la dette technique	15-20 %	Vélocité à long terme	OpEx
Maintenance et support	20-30 %	KTLO	OpEx
Expérimentations d’innovation	10-15 %	Valeur d’option	CapEx

Allocation recommandée par la méthode flowstate pour une organisation d’ingénierie équilibrée

Tu ne suis pas seulement du temps. Tu suis l’investissement et son retour.

À quoi ça ressemble en pratique

On travaille avec des entreprises comme RAC sur la planification de leurs coûts d’ingénierie. Voilà comment ça change la conversation :

Avant flowstate :

« Il nous faut cinq ingénieurs de plus pour l’équipe plateforme. »

Après flowstate :

« On alloue 8,5 ETP à trois projets ce trimestre :

Migration vers l’API v3 (4,0 ETP, 110 k£, devrait débloquer 2 M£ d’économies opérationnelles)

Infrastructure d’observabilité (3,0 ETP, 82 k£, réduit le MTTR des incidents de 40 %)

Renforcement de la sécurité (1,5 ETP, 41 k£, le minimum pour l’offre entreprise)

Coût total ce trimestre : 233 k£. Capacité actuelle : entièrement allouée.

Si on ajoute cinq ingénieurs (150 k£ par trimestre, charges comprises), on peut prendre le projet de modernisation des paiements au T4. On projette 5 M£ de chiffre d’affaires annuel grâce à moins d’abandons de panier et à de nouveaux moyens de paiement.

Cela dit, il nous faut 2,0 ETP avec de l’expérience en traitement des paiements et 1,5 ETP qui connaissent la conformité PCI. Notre pipeline de recrutement actuel ne couvre pas encore ces compétences. »

Tu vois la différence ? Tu ne te disputes pas sur les effectifs. Tu discutes d’investissement, de retour et de lacunes de capacités.

L’interface de planification que tu aurais envie d’utiliser

Les outils de planification classiques ont été conçus pour des chefs de projet en 2005. Il te faut un diplôme en MS Project pour les comprendre.

flowstate est différent :

Glisser-déposer des membres d’équipe entre les projets
Calcul instantané des coûts pendant que tu alloues les gens
Vues de capacité en temps réel qui montrent ce qui est vraiment possible
Correspondance des compétences pour voir si tu as les bonnes capacités
Planification de scénarios sans copier de tableurs
Piste d’audit automatique de chaque changement et de sa raison

Tu peux modéliser « et si on recrutait trois ingénieurs seniors le trimestre prochain ? » en 30 secondes environ. Compare les scénarios côte à côte. Vois l’impact sur les dates de livraison, les coûts et la capacité.

Dans six mois, quand quelqu’un demandera « Pourquoi a-t-on retiré ces ingénieurs de l’équipe paiements ? », tu pourras lui montrer :

L’allocation d’origine et le plan du projet
Qui l’a changée et quand
Le commentaire qui explique la raison business
L’impact sur les projets en aval
Si le pari a payé

Une planification collaborative qui marche vraiment

Là, ça devient intéressant. La planification de scénarios dans flowstate est collaborative et en direct.

Pense à Git pour ton plan d’ingénierie.

Tu peux :

Créer autant de brouillons de scénarios que tu veux
Partager des scénarios avec les parties prenantes pour relecture
Recueillir des retours et itérer
Approuver un scénario, qui devient le nouveau plan
Voir tous les brouillons se mettre à jour automatiquement avec les changements approuvés

C’est collaboratif. Ça se met à jour en direct pour tous ceux qui regardent. Tu peux jeter autant de brouillons que tu veux. Mais il y a une seule source de vérité à jour, et elle met à jour comme par magie les brouillons de chacun avec les changements approuvés, de sorte que tu travailles toujours sur la dernière version.

Fini le « on regarde quelle version du plan ? ». Fini les tableurs envoyés par e-mail. Fini la découverte que la finance travaillait avec les chiffres de la semaine dernière.

Commit. Merge. Rebase. Mais en plus magique.

Replanifier en continu sans souffrir

Le marché du logiciel bouge vite. Les virages stratégiques arrivent. Des personnes clés partent. Les priorités changent.

Dans la méthode flowstate, replanifier ne veut pas dire repartir de zéro. Ça veut dire :

Glisser les projets pour ajuster le calendrier
Voir l’impact immédiat sur les coûts et les livraisons
Comparer les scénarios avant de s’engager
Documenter le pourquoi pour plus tard
Publier automatiquement le nouveau plan auprès des parties prenantes

Ce qui prenait trois jours prend maintenant trente minutes.

Et comme tout est correctement tracé, tu peux répondre à « Pourquoi ce projet a-t-il dérapé ? » avec de vraies données :

« On a réalloué 2,0 ETP à l’incident de sécurité en semaine 3 »
« La migration de l’API a pris 6 semaines de plus à cause de problèmes de qualité des données qu’on a découverts »
« On a ajouté du périmètre en semaine 7 suite aux retours clients, voici le changement approuvé »

Pas des suppositions. Des faits.

La méthode pilote le produit (et pas l’inverse)

On ne fait pas que construire un logiciel. On codifie les bonnes pratiques de responsables tech de tous les secteurs.

La méthode flowstate est notre réponse à ces questions :

Comment structurer le travail d’ingénierie pour qu’il soit visible ?
Quelle est l’unité minimale viable de planification, celle qui équilibre granularité et surcoût ?
Comment équilibrer la concentration (peu de projets) et la souplesse (des priorités qui changent) ?
Comment relier les paris d’ingénierie aux résultats financiers qui comptent vraiment pour la finance ?
Comment rendre la planification de scénarios assez rapide pour être utile ?
Comment suivre les compétences et les capacités, pas seulement les effectifs ?

On parle avec :

Des CTO d’entreprises détenues par des fonds, sous surveillance opérationnelle
Des scale-ups en croissance rapide, avec plusieurs cycles de planification par an
Des entreprises de taille intermédiaire qui essaient de maîtriser leurs dépenses d’ingénierie pour la première fois
Des responsables d’ingénierie qui en ont marre de l’enfer des tableurs

Les problèmes sont les mêmes partout. Les solutions ne devraient pas être faites sur mesure.

Où on va

La pression sur les dépenses d’ingénierie n’a jamais été aussi forte. Les fonds exigent l’excellence opérationnelle. Les conseils réclament de l’expansion de marge. Les DAF veulent voir en temps réel où va l’argent.

En même temps, la nature du travail d’ingénierie change. Les références de productivité bougent. Les modèles de coûts d’ingénierie historiques seront obsolètes d’ici quelques mois.

Les organisations qui y arriveront, celles qui savent planifier dynamiquement, mesurer avec précision et s’adapter vite, auront un énorme avantage. Celles qui copient encore des onglets de tableur resteront sur le bord de la route.

On a construit flowstate parce que j’en avais assez de ne pas avoir de réponses. Assez des tableurs qui cassent. Assez d’une planification de scénarios qui prend trois jours. Assez d’expliquer aux conseils pourquoi on ne peut pas leur dire ce que les choses coûtent.

La méthode flowstate est notre tentative de régler ça proprement. Pas avec un autre outil de tâches. Pas avec un autre remplaçant de tableur. Mais avec un vrai cadre pour la façon dont les organisations d’ingénierie devraient planifier et mesurer le travail en 2025 et après.

Aide-nous à l’affiner

On est encore au début. Le logiciel marche, RAC et d’autres l’utilisent aujourd’hui, mais on affine la méthode au fil des conversations avec des responsables tech.

Si tu te reconnais dans un de ces problèmes, je veux te parler :

Comment fais-tu de la planification de scénarios aujourd’hui ? Quand ton DAF demande « et si on coupait 20 % ? », c’est quoi ton processus ? Des tableurs ? Au feeling ? Trois jours de réunions ?

Comment suis-tu le coût des fonctionnalités ? Peux-tu me dire tout de suite ce qu’ont coûté tes trois dernières grosses fonctionnalités ? Pas des estimations. Des coûts réels.

Comment justifies-tu les demandes de recrutement ? C’est quoi ton discours ? « Il nous faut plus de monde » ou « Il nous faut 3,0 ETP pendant six mois pour construire [truc], qui générera [valeur] » ?

Comment gères-tu les replanifications fréquentes ? Quand les priorités changent tous les mois, comment tiens-tu les plans à jour sans brûler des semaines en administration ?

Comment fais-tu correspondre les compétences aux projets ? Peux-tu voir d’un coup d’œil si ta capacité disponible a les bonnes compétences pour le travail à venir ?

Les meilleurs cadres naissent de la sagesse collective, pas de l’expérience d’une seule personne. On construit flowstate pour résoudre des problèmes que j’ai vécus, mais je veux m’assurer qu’on résout aussi ceux que tu vis.

Si ça te parle, contacte-nous : flowstate.inc

References

McKinsey & Company, How high performers optimize IT productivity for revenue growth: A leader’s guide ↩
McKinsey & Company, Breaking technical debt’s vicious cycle to modernize your business ↩ ↩²
McKinsey & Company, Developer Velocity: How software excellence fuels business performance ↩
OutSystems, Driving IT innovation forward: 3 imperatives for success ↩
Bain & Company, Global Private Equity Report 2025 ↩ ↩²
Panko, R. R. (2008). “What We Know About Spreadsheet Errors” & Poon, J., et al. (2024). “A review of spreadsheet errors: 35 years of research.” (The foundational academic papers.) The original link for Panko’s publication is dead, but I’ll leave it here for reference: panko.shidler.hawaii.edu/SSR/Mypapers/whatknow.htm ↩
PwC (2023). “FP&A Survey Results” ↩
Bruno J. Navarro, Workday (2022). “CFO-CIO Alignment Can Help Drive Digital Finance Transformation Goals, Global Research Finds.” ↩