Le prix d'un logiciel ne correspond pas à son coût de développement, mais à son coût d'exploitation pendant toute sa durée de vie. Développer un logiciel est devenu bon marché ; l'exploiter, le corriger, l'intégrer et le faire évoluer, en revanche, ne l'est pas. Comparer deux propositions uniquement sur la base de leur budget de réalisation revient à comparer deux bâtiments uniquement sur la base du coût du béton.
Cette distinction est devenue cruciale ces dix-huit derniers mois. Le coût de production de code a chuté de manière réelle et vérifiable – Stanford HAI a démontré que le coût d'inférence pour un système équivalent à GPT-3.5 a été divisé par plus de 280 entre novembre 2022 et octobre 2024 – et, de ce fait, le prix d'entrée de nombreux projets de développement a baissé. En revanche, le coût de maintenance des systèmes développés n'a pas diminué.
Le budget d'un projet couvre généralement l'analyse, la conception, le développement et la mise en œuvre. Cela représente entre 30 % et 40 % des dépenses totales du système sur son cycle de vie. Le reste est alloué ultérieurement, réparti en postes budgétaires qui ne figurent presque jamais dans la proposition initiale.
Départ | Ce qui est inclus | Quand apparaît-il ? |
Construction | Analyse, conception, développement, déploiement | Mois 1 à 9 |
Infrastructure | Cloud, stockage, sauvegardes, environnements | Dès le premier jour, pour toujours |
Correction | Défauts, régressions, incidents de production | Dès la première semaine |
Évolution | Évolutions de l'activité, nouveaux besoins, nouvelles intégrations | Continu |
Sécurité et conformité | Correctifs, audits, adaptation réglementaire | Continu, avec des pics de régulation |
Dépendance | Le coût d'un seul fournisseur sachant comment jouer le jeu | Il apparaît lorsque vous souhaitez modifier |
Les cinq premiers postes peuvent être estimés. Le sixième, absent de tout budget, est celui qui coûte le plus cher lorsqu'il se concrétise, car il n'est pas payé en euros au départ : il est payé en perte de pouvoir de négociation.
La dette technique est généralement présentée comme un concept d'ingénierie, ce qui explique pourquoi les comités de direction l'ignorent souvent jusqu'à ce qu'il soit trop tard. En termes financiers, c'est plus simple : il s'agit du surcoût engendré par chaque modification apportée à un élément, conséquence de décisions prises initialement pour accélérer le processus.
Selon les estimations du secteur, le coût de la maintenance et de la dette technologique représente environ 401 % du budget informatique moyen d'une entreprise. Ce chiffre doit être considéré comme un ordre de grandeur et non comme une donnée vérifiée, car les méthodologies varient considérablement d'une étude à l'autre. Cependant, la tendance se dégage de toutes les sources : la majeure partie des dépenses technologiques d'une entreprise établie ne finance pas de nouvelles fonctionnalités, mais la maintenance de solutions obsolètes.
Un élément supplémentaire change la donne lorsqu'on aborde le sujet avec un directeur financier : IBM estime que la réduction de la dette technique des systèmes existants peut améliorer le retour sur investissement des initiatives d'IA jusqu'à 291 000 milliards de dollars. Autrement dit, la dette technique n'engendre pas seulement des coûts de maintenance ; elle réduit aussi les performances de tout ce qui est construit par-dessus.
Et le problème s'aggrave au lieu de se résorber. GitClear, s'appuyant sur l'analyse de 211 millions de lignes de code, a constaté une explosion de la duplication des blocs de code à partir de 2024 et une chute du travail de refactorisation (l'activité permettant de réduire la dette technique), passant d'environ 25,1 % du total des modifications en 2021 à moins de 10,1 % en 2024. On construit plus vite et on nettoie moins.
Un audit formel n'est pas nécessaire pour détecter les premiers symptômes. Voici les indicateurs qui apparaissent en premier :
Lorsque trois de ces symptômes ou plus apparaissent, l'augmentation des capacités de développement n'accélère rien. Elle ne fait qu'accroître le nombre de personnes en attente d'une décision de conception.
Pour comparer les fournisseurs, ces quatre questions permettent de distinguer celui qui propose une livraison unique de celui qui vend un système. Aucune n'est technique ; elles sont toutes contractuelles.
À qui appartient ce code ? Si la réponse mentionne des nuances, des licences ou un « accès au dépôt », la réponse est non : ce n’est pas à vous. La propriété du code, de la documentation et de la propriété intellectuelle doit être transférée par contrat. Sans cela, tout devis est provisoire, car le fournisseur dispose d’un pouvoir de fixation des prix illimité.
Que se passe-t-il si je veux changer de fournisseur demain ? La réponse utile n'est pas « vous n'y arriverez pas ». C'est plutôt : la documentation architecturale existe, les modules exposent des contrats versionnés, les environnements sont distincts et toute équipe compétente peut prendre le relais dans un délai raisonnable. Si cette transition nécessite qu'un représentant du fournisseur initial « explique comment ça fonctionne », c'est que le système n'est pas documenté ; il est mémorisé.
Qui prend en charge les réparations liées aux défauts ? Un défaut dans le code livré ne constitue pas une modification du périmètre. Il doit être corrigé gratuitement, et cela doit être stipulé par écrit. Chez The Cloud Group, nous l'appelons la Garantie Rain, et elle est inscrite dans le contrat : nous corrigeons les défauts du code livré, à vie. Ce n'est pas de la générosité, mais de la cohérence : si vous prétendez que votre ingénierie est rigoureuse, vous devez assumer les conséquences d'un éventuel manque de rigueur.
Quel est le coût d'exploitation estimé sur trois ans ? Tout fournisseur digne de ce nom peut vous proposer un éventail d'options d'infrastructure, d'assistance et de mise à niveau. Ceux qui ne le peuvent pas n'y ont soit pas pensé, soit préfèrent que vous ne le fassiez pas.
Ce sont précisément les questions que nous contribuons à formuler lorsque nous agissons en tant que partie indépendante dans un processus de Sélection des fournisseurs et rédaction des appels d'offres [lien interne], sans participer en tant que candidats à l'appel d'offres que nous évaluons.
Ce n'est pas une coïncidence, c'est une relation de cause à effet. Les décisions qui réduisent les coûts de construction sont presque toujours celles qui augmentent les coûts d'entretien.
Aucune de ces décisions n'est visible dans la démo. Elles figurent toutes sur le projet de loi de troisième année.
Le cas inverse existe également et est mesurable. Dans les projets de modernisation de systèmes existants (audit, refactoring et modernisation plutôt que réécriture complète), nous avons constaté des réductions des coûts de maintenance pouvant atteindre 601 000 £. Non pas grâce à un code amélioré, mais parce que le coût de la maintenance est principalement lié à l'incertitude : lorsqu'un système est compréhensible et testé, chaque modification cesse d'être un pari risqué.
L'erreur fréquente de l'équipe technique est de demander un budget « pour rembourser la dette technique ». C'est une demande qu'aucun comité n'approuve avec enthousiasme, car elle donne l'impression de vouloir corriger une erreur commise.
La formule qui fonctionne est différente et honnête :
La conversation passe de « le logiciel est mal conçu » à « voici la différence de coût entre les deux options ». Cette deuxième conversation peut être gagnée.
Une proposition bon marché qui n'inclut pas la propriété du code, la documentation, les tests ou les contrats d'intégration n'est pas une proposition bon marché : c'est un prêt dont vous découvrirez plus tard le taux d'intérêt.
Avant de choisir un logiciel, la question à se poser n'est pas son coût de développement, mais son coût d'utilisation, la question de sa propriété et les conséquences d'un changement d'avis.
Il s'agit de la somme de tous les coûts associés à un système tout au long de son cycle de vie : construction, infrastructure, correction des défauts, évolution fonctionnelle, sécurité et conformité, ainsi que le coût lié à la dépendance à un fournisseur unique. Le budget de construction ne représente généralement que 301 % à 401 % du total.
Selon les estimations du secteur, ce chiffre représente environ 401 % du budget informatique, bien qu'il varie selon la méthodologie de l'étude. La tendance est constante : dans les entreprises établies, la majeure partie des dépenses technologiques sert à maintenir les capacités existantes plutôt qu'à développer de nouvelles fonctionnalités.
Elle prévoit une durée de vie d'au moins trois ans et comprend six éléments : construction, infrastructure et environnement, correction des défauts, évolution fonctionnelle, sécurité et conformité réglementaire, et coûts de sortie ou de changement de fournisseur. Un fournisseur réputé peut vous fournir une fourchette de prix justifiée pour les cinq premiers.
Car les décisions qui permettent de réduire les coûts de construction — négliger la conception, ne pas réaliser de tests, ne pas documenter, rafistoler les problèmes — sont les mêmes qui augmentent le coût de chaque modification ultérieure. Les économies sont concentrées au premier trimestre, et les coûts supplémentaires sont répartis sur les années suivantes.
Quatre éléments essentiels : la propriété du code, de la documentation et de la propriété intellectuelle ; des contrats d’intégration versionnés et documentés ; la correction gratuite des défauts ; et un plan de transition permettant à une autre équipe de prendre le relais sans dépendre du fournisseur initial.
Dans la plupart des cas, oui, à condition qu'un diagnostic préalable ait été établi. L'audit, la refactorisation et la modernisation par domaine permettent de réduire considérablement les coûts de maintenance (jusqu'à 601 000 € dans les projets que nous avons menés) tout en assurant la continuité des opérations, ce qu'une réécriture complète ne permet pas.
Savez-vous combien votre logiciel vous coûtera dans trois ans ? Notre audit technique vous fournit un rapport écrit sur l'état de votre architecture, de votre code, de votre dette technique et de votre sécurité, à prix fixe et sous 10 jours ouvrés. C'est la solution la plus rentable pour déceler un problème coûteux. Demandez votre audit → |
Español Español 
English
Français
العربية
Português
Deutsch
Italiano
