10 K€ pour en économiser 500 : le vrai ROI de la modularisation
La non-modularisation coûte cher. Investir dans une architecture modulaire protège votre logiciel et évite des pertes financières massives.
Publié le 10 septembre 2025
Pourquoi la modularisation devrait être l'obsession du CEO
Je le dis souvent, s'il est un sujet sur lequel les CEO doivent avoir l'œil, c'est bien la modularisation du logiciel ou du système d'information que leur entreprise développe. En premier lieu parce que c'est un sujet purement fonctionnel, lié à votre métier, qui ne requiert donc pas de compétence technique, au moins dans un premier temps.
Mais aussi parce que, parmi tous les sujets ayant trait à la qualité, celui-ci est de loin le plus important . Bien sûr que le test est important, mais l'ordre de grandeur des dégâts causés par l'absence de tests est moindre. Autrement dit, mieux vaut une codebase bien modularisée et mal testée, ou pas testée du tout, qu'une codebase bien testée mais mal modularisée (1).
Travailler la modularité d'un système d'information requiert de passer un peu de temps : identification puis interview des acteurs métiers clés, élaboration d'une carte des modules fonctionnels (le terme consacré étant "contextes" au sens du Domain-driven design ), et généralement quelques itérations. Une telle étude vous coûtera entre 10 et 20 K€, disons 10 K€ en ordre de grandeur.
Parlons justement de cela, le prix de la modularisation, et donc de votre propension à payer, vous, CEO. Ceux qui ont déjà vécu le refactoring d'une codebase à grande échelle, quand la modularisation n'a pas été anticipée, en connaissent le coût (comptable ou d'opportunité) et ne veulent généralement pas le revivre.
Procédons ensemble à l'estimation du coût comptable.
L'absence de modularisation, une bombe à retardement
Considérons une application type, comme on en voit pléthore dans tous types de structures : une application construite par 3 développeurs pendant 2 ans. Le résultat est un bon plat de spaghettis, non pas ceux, réconfortants, que vous vous apprêtez à déguster ce midi, mais bien l'antipattern auquel mènent le manque de savoir-faire, l'urgence permanente et le turnover.
3 développeurs, 2 ans, 1 plat de spaghettis.
À présent, le problème est criant : des bugs comme s'il en pleuvait et des délais de développement qui explosent, autrement dit une application instable. Vous décidez de procéder au refactoring qui s'impose et faites appel à d'autres personnes que celles qui ont créé le produit (2).
Combien cela vous coûtera-t-il ?
- Hypothèse basse : 1 personne à temps plein pendant 1 an. Soyons conservateur et prenons un indépendant à 450 €HT/j pendant 200 jours (~5 ans d'expérience professionnelle, je doute que vous trouviez à ce prix-là quelqu'un qui ait les reins assez solides pour mener un tel sujet, mais enfin c'est notre hypothèse). Vous êtes à 90 K€. Un profil salarié équivalent se paie au bas mot 50 K€ brut, soit pour vous un coût de 70 K€ (x1.4). L'ordre de grandeur est donc le même : 100 K€, en étant conservateur.
- Hypothèse haute : il n'y a pas vraiment de limite, le coût du refactoring pouvant en réalité dépasser celui du premier développement (3). Partons sur 2 personnes pendant 2 ans, un profil senior accompagné d'un autre moins expérimenté. En freelance, disons 700 €HT/j pour le premier et 450 €HT/j pour le second, soit 460 K€ au total. Salariés, ces mêmes profils vous coûteraient 80 K€ et 50 K€ brut, soit 360 K€ au total. L'ordre de grandeur n'a pas changé, mais c'est tout de même le quadruple de l'hypothèse basse.
- Et le scénario du pire, qu'il faut tout de même envisager – on l'a vu plus d'une fois : votre logiciel et votre entreprise ne s'en remettent pas, parce que vous n'êtes pas seuls sur le marché.
Le moment idéal pour modulariser : au premier jour
Dans la réalité, beaucoup de développeurs témoigneront avec moi qu'entre un code qui marche "vite fait" et un code robuste à l'exécution et capable d'évoluer dans le temps, le rapport est bien plus que 1 à 4. Et encore, en partant de la page blanche ; sur base d'un existant, le refactoring peut vous coûter un bon 10 fois plus cher que le développement initial.
Tandis qu'une simple étude de modularisation faite à
t0Ce sujet est la parfaite illustration de l'effet Dunning-Kruger : il faut en savoir assez pour savoir qu'on ne sait rien. Les créateurs d'entreprise les plus jeunes n'ont généralement jamais entendu parler de modularisation et partent bille en tête pour des années de création de dette technique.
Ceux qui, au contraire, se sont déjà frottés au problème et ont été contraints de mettre de telles sommes d'argent sur la table savent la nécessité d'anticiper. Puisse cet article vous convaincre de prendre les devants pour ne jamais vivre un tel refactoring 😊
(1) Cela pose d'ailleurs une question troublante : comment bien tester une codebase mal modularisée ? Si elle est mal modularisée, il y a des chances que l'essentiel des tests se situe à haut niveau, par exemple des tests end-to-end, ce qui est contraire aux bonnes pratiques (on recommande généralement d'établir une pyramide de tests ).
(2) Nécessairement d'autres personnes que celles qui ont produit l'existant, car si elles avaient la compétence pour mener à bien ce refactoring, la codebase ne serait pas dans cet état.
(3) Vous me direz alors : "pourquoi ne pas repartir de la page blanche ?", et vous aurez raison. Sauf que vous voulez à tout prix éviter de vous lancer dans un projet de refonte parallèle à la production, car tout code qui n'est pas en production est un code en surcis. La tâche s'apparente donc bien à du refactoring.