Réduction des coûts IT : au-delà du temps et des lignes de code

Ce qu’il faut retenir en 5 points essentiels :

Pause café, un étage élevé d’une tour à La Défense.
Autour de la machine à café, une question revient souvent : “Combien de temps et d’argent faudra t-il pour développer telle solution ? Et ne vaut-il pas mieux opter pour une solution clé-en-main ?”

Derrière cette interrogation se cache un enjeu bien plus vaste : comment mesurer le coût réel d’une solution informatique ? Et comment situer la réduction des coûts IT dans un monde où les outils no-code, l’intelligence artificielle et les exigences RSE redéfinissent les règles du jeu ?

Au-delà du simple calcul en heures ou en lignes de code, l’enjeu est désormais de repenser la valeur réelle d’une solution : sa performance, sa capacité à s’adapter aux besoins métiers, mais également et de plus en plus son impact environnemental et sa contribution à une stratégie RSE cohérente.
Dans un contexte où les directions financières exigent des résultats mesurables et où les DSI doivent justifier chaque euro investi, la réduction des coûts devient un impératif stratégique. Mais comment faire pour estimer de manière fiable le coût global d’une solution numérique sans perdre de vue la consommation réelle qu’elle implique ?

Les méthodes traditionnelles d’estimation sont-elles suffisantes ?
Avons-nous les bons outils pour intégrer les dimensions humaines, matérielles et écologiques ?
Et surtout, comment rester compétitif tout en respectant les engagements RSE de l’entreprise ?

Cet article - le premier d’une trilogie - propose une réflexion sur les limites des modèles traditionnels d’estimation, les biais qui les accompagnent, et les pistes pour une approche plus responsable et holistique. Mais surtout, c’est un rappel des raisons derrière.

Le développement logiciel a déjà fêté ses soixante ans (merci Margaret Hamilton!), et pourtant la question de ses coûts réels reste toujours ouverte.

Pendant longtemps, le débat se résumait à une opposition un peu simpliste : “temps passé à coder” versus “tout le reste”. Ces propos rappellent les modèles d’estimation du coût d’un développement logiciel des années 80, tels que le COCOMO, qui se basent sur la quantification des lignes de code (LOC) comme mesure de l’effort fourni. Ces approches, utiles à leur époque, ne prenaient pas encore en compte des notions devenues centrales aujourd’hui, comme les coûts IT ou la consommation des ressources par les solutions numériques.

Jusqu’en 2019 encore, on déplorait le fait que les développeurs ne puissent passer plus “que 4 à 5 heures par jour” à coder, qualifiant de “perte de productivité” les “interruptions continuelles, ainsi que des heures passées à résoudre des problèmes et à faire du reporting”. L’on allait même jusqu'à poser la question “comment rendre les développeurs plus efficaces“ de sorte à augmenter le temps qu’ils peuvent passer à coder.

Mais depuis, le paysage a bien changé.

Le COVID a imposé de nouvelles façons de travailler, l'IA a bouleversé les pratiques et fait évoluer les outils (cf. le dernier rapport de JetBrains):

De plus, un acteur inattendu est venu peser dans la balance : la loi !

En France, l’Assemblée nationale et le Sénat ont voté le 15 Novembre 2021 la loi n°2021-1485, dite loi REEN, qui vise à réduire l’empreinte environnementale du numérique, tout le long de sa chaîne de valeur. L’article L. 229-25 du Code de l’environnement oblige désormais les entreprises à rendre des comptes sur leur impact carbone.

Dans un monde où chaque pan de nos vies se numérise, la question n’est plus seulement “combien ça coûte de développer un logiciel”, mais aussi “quel est son prix environnemental ?” et comment intégrer cette dimension dans une stratégie globale de réduction des coûts et de la consommation des ressources. Réduire l’empreinte environnementale des solutions logicielles n’est désormais plus un choix : c’est une nécessité, voire une obligation.

Dans un tel contexte, pas étonnant que les DSI, eux, aient l’impression de marcher sur une ligne de crête : d’un côté, livrer des solutions performantes, robustes et rapides ; de l’autre, intégrer des objectifs RSE, réduire l’impact environnemental et rendre des comptes sur des coûts qui ne rentrent dans aucune grille standard.

Résultat : concilier l’inconciliable.

Alors comment mesurer le coût réel d’une solution informatique à l’ère du no-code, de l’IA et des exigences RSE ? Comment maîtriser des coûts calculés uniquement en temps-passé-à-coder ? Et pour quoi faire ?

Dans cette équation, le développement logiciel n’est pas un objectif isolé : il se retrouve en balance avec l'optimisation de la performance et la réduction de l'empreinte environnementale.

L’estimation des coûts réels d’un projet informatique est une tâche ardue. Les modèles classiques basés sur l’approche Waterfall (ou cycle en V), efficaces pour structurer un projet, présentent des limites importantes en soi. En particulier, ils se concentrent sur les moyens (combien de lignes tapées, de temps passé) plutôt que sur les résultats (résolution du bon problème, durabilité).

Ces limites sont exacerbées aujourd’hui.

En effet, il est difficile de refléter par le nombre de LOC (Lines of Code) les coûts cachés du cycle de développement (tel que l’usage du Cloud/serveur, le coût de la sécurité, de la maintenance, etc.) - autant d’éléments rarement pris en compte dans les approches classiques d’estimation des coûts de développement logiciel. On comptabilise mal l’incertitude liée aux environnements d’intégration qui évoluent, et encore moins les biais humains (oublis, sous-évaluations, méconnaissance des coûts indirects, évènements imprévus).

Cerise sur le gâteau, le paradigme du cône d’incertitude: il est le plus ardu de proposer une estimation réelle du coût d’un projet à ses prémices!

Pourtant, la pression des parties prenantes pour obtenir des chiffres précoces conduit tantôt à de la surestimation (gâchis), tantôt à de la sous-estimation (frustrations, risques).

Dans les deux cas, les promesses initiales de réduction des coûts deviennent rapidement intenables.

Pourtant, ces éléments sont rarement intégrés dans les modèles d’estimation mathématique, même si les modèles COCOMO ont beaucoup évolué dans ce sens (COCOMO-II). Ces derniers ont plutôt tendance à peindre une image figée de l’incertitude, facilement quantifiable.

Le propos n’est pas (que) de la nécessité de changer d’outils. Les approches classiques restent pertinentes dans certains cas :

Mais au-delà des modèles de calcul, figer trop tôt des estimations revient à produire des chiffres qui rassurent jusqu’à leur premier contact avec la réalité. Les illusions de précision génèrent frustrations, dépassements et tensions croissantes entre directions métiers, DSI et finance - sans parler de l'épuisement moral des équipes.

Ces chiffres figés occultent les vrais leviers de réduction des coûts IT : la flexibilité et l’adaptation.

Admettons à ce stade qu’on ne peut vraisemblablement pas optimiser ce que l’on n’a pas bien quantifié .. mais pour quoi faire ?

Au-delà des ressources humaines et financières mobilisées, le coût d’une solution informatique aujourd’hui doit refléter d’autres facteurs dont l’impact/la disponibilité est critique, tels que :

Dans un monde hyper connecté, où chaque ligne de code peut avoir un impact environnemental, ignorer ces coûts revient à fausser l’analyse globale.

Mais comment faire alors pour intégrer des coûts qu’aucun modèle classique ne comptabilise ?

Le coût d’une solution n’est pas une variable isolée : il s’inscrit dans une triangulation entre le périmètre du projet (scope), le budget et les délais impartis.

Si cette dynamique est ignorée, l’estimation des coûts de développement logiciel se fausse, et la maîtrise des coûts devient illusoire.

Si votre méthode d’estimation ignore les variables clés du contexte (incertitude sur les délais, interdépendances des fonctionnalités, coûts opérationnels), vous ne prédisez pas l’avenir : vous pariez sur un modèle figé dans un environnement mouvant. Dans un marché où les marges se compressent et les ressources se tendent, ce pari compromet la réduction des coûts attendue et draine les équipes.

Les cadres agiles apportent une réponse pragmatique, car l’agilité intègre l’incertitude au lieu de l'éliminer. En cela, elle épouse mieux cette merveilleuse faculté des Homo Sapiens: l’adaptabilité.
Et elle le fait intrinsèquement, puisqu’elle se base sur les mêmes piliers du Manifeste Agile qui ont provoqué sa genèse.

En effet, l’agilité repose sur une approche intégrée où estimation, collaboration, gestion des risques et durabilité se renforcent mutuellement pour optimiser la valeur et la maîtrise des coûts. La visibilité transversale permet d’intégrer conception, tests et déploiement dans une même dynamique. L’estimation par itérations et la réévaluation continue des risques soutiennent un rythme durable et une meilleure maîtrise des coûts.

De ce fait, les équipes de développeurs Agiles sont en mesure de faire évaluer les estimations, à mesure que progresse leur compréhension de la solution et de sa complexité!

Par exemple, une fonctionnalité peut être dépriorisée, pour se concentrer sur l’essentiel.

L’agilité élargit le périmètre de l’estimation : design, tests, déploiement, exploitation mais aussi maintenance et décommissionnement. Cette approche offre une vision plus complète du coût total de développement Ainsi, elle prépare l’intégration de nouvelles dimensions d’évaluation - en vue d’implémenter des pratiques utiles, pour l’homme et pour son environnement.

Car estimer, ce n’est pas que chiffrer des heures : c’est mesurer l’impact global d’un choix!

Pour ce faire, il faudra même aller au-delà des cadres Agiles.

En France, l’agence de la transition écologique (ADEME) a fixé l’horizon de la neutralité carbone à 2050, en identifiant quatre trajectoires possibles : la frugalité, la réparation, la coopération territoriale et les technologies vertes. Transposé aux systèmes d’information, aujourd’hui en lien avec quasiment tous les domaines de nos vies urbanisées, cela signifie que chaque décision — choix de matériel, d’architecture, de logiciel — peut contribuer ou non à cet objectif.

Dans cette perspective, il devient essentiel de lier les KPIs de la performance à la valeur ajoutée réelle d’une solution. Autrement dit, les décisions budgétaires -et opérationnelles- ne doivent plus uniquement servir une logique de rentabilité immédiate (combien je gagne ?); mais être pondérées par les effets à long terme de la solution développée - sur le client, la communauté et l’environnement.

Une approche complexe, certes, mais devenue incontournable dans les débats contemporains sur la gestion responsable des ressources.

Et là encore, des outils existent déjà : solutions open-source pour estimer l’empreinte carbone d’une application (Green Algorithms ), le recours à des GPU plus sobres en énergie, ou l'adoption de nouveaux cadres d’analyse (Home )redéfinissent la manière dont nous évaluons les solutions informatiques.

Ces outils permettent actuellement une approche plus globale, en intégrant à la fois les coûts directs liés aux infrastructures et aux logiciels, et les externalités liées à la consommation énergétique, aux émissions de gaz à effet de serre, à l’obsolescence matérielle - souvent occultées dans la gouvernance des SI.

En d’autres termes, elles enrichissent le tableau de bord qui guide les arbitrages, au même titre que le budget ou le planning.

Mais comment ces principes prennent-ils forme concrètement, au plus près des outils que les DSI utilisent chaque jour ? Dans un prochain article, Stéphane Génin, Président de BleuLemon, vous propose une démonstration directe sur Jira Software, en montrant l’impact réel d’une simple fonctionnalité sur la consommation de ressources… et donc sur les coûts. Inscrivez-vous pour ne pas le manquer.

Dans cet article, nous avons présenté l’intérêt d’une approche holistique quand il s’agit d’estimer le coût réel d’un développement informatique. Au-delà des cadres classiques, il y a urgence de penser les solutions aujourd’hui de façon durable.

Estimer le coût d’une solution n’a jamais été aussi complexe… ni aussi nécessaire.
Derrière les chiffres, il y a la question de la valeur réelle : ce que la solution apporte, ce qu’elle consomme, et l’impact qu’elle laisse sur le monde environnant.

L’agilité nous aide à avancer autrement : accepter l’incertitude, réévaluer régulièrement, rapprocher performance, durabilité et maîtrise des coûts.
La réduction des coûts IT n’est pas une fin : c’est une boussole parmi d’autres, qui dialogue avec les enjeux métiers et l’empreinte environnementale. Estimer aujourd’hui, ce n’est pas seulement compter des heures ; c’est prendre position dans un monde qui change.

Dans ce contexte, l’Agilité amène les outils mais la démarche doit rester holistique.

En effet, loin de la ségrégation entre “coûts matériels” d’une part et “bonnes pratiques pour un numérique vert” de l’autre, BleuLemon a pris le parti d’une stratégie globale pour réduire aussi bien vos coûts que l’empreinte carbone de vos solutions.

Rendez-vous dans le deuxième article de cette série, où nous vous proposons une plongée dans ce monde encore mal connu des “outils et initiatives“ qui contribuent à cet écosystème.