Dette technique, obsolescence, modernisation : bienvenue dans la partie immergée de l'iceberg

Il y a un moment dans la vie de toute organisation qui fait du logiciel où quelqu'un dit, l'air grave : "On va être obligés de tout refondre." Ce moment arrive rarement par surprise. Il est précédé de mois, parfois d'années, de signaux ignorés, de dette accumulée, de chantiers techniques repoussés au prochain sprint, au prochain PI, à l'année prochaine. Jusqu'au jour où cela fait trop mal pour continuer à les ignorer.

Le problème des sujets IT - dette technique, obsolescence, modernisation du socle - c'est qu'ils constituent la partie immergée de l'iceberg. Invisibles de prime abord, indolores tant qu'ils ne débordent pas, ils ne remontent à la surface que quand les symptômes deviennent suffisamment douloureux. Et à ce stade, le coût est bien plus élevé que ce qu'il aurait été si le sujet avait été traité au fil de l'eau.

C'est un peu comme ne pas se brosser les dents. Ca permet de gagner un peu de temps à court terme, sans voir tout de suite les conséquences. Et au bout d’un moment, l'intervention est autrement plus coûteuse que l'hygiène quotidienne qui avait été négligée. Nous connaissons tous cette application qu'il faut obligatoirement refondre tous les deux à trois ans, faute d'avoir traité la dette technique au fur et à mesure.

Ces sujets ne sont pas “jamais” traités, il serait caricatural de dire le contraire. Non, ils finissent par l'être, mais le plus souvent tardivement, dans la douleur, après avoir dépensé une énergie considérable à convaincre que ce gros chantier coûteux vaut le coup. Et cette friction n'est pas le fruit du hasard. Elle est le produit d'une organisation qui n'est pas structurée pour considérer ces sujets au bon moment, de silos qui rendent la valeur technique difficile à comprendre et à rendre visible, et parfois tout simplement de contraintes budgétaires qui poussent à reporter.

La question est donc : pourquoi ces sujets arrivent-ils souvent trop tard, et comment changer cela ?

Chez OCTO, nous observons ce pattern depuis des années, et ce n’est pas lié à un contexte particulier, car tous les secteurs sont touchés : banque, retail, énergie, assurance.

Quelle est la racine du problème ?

La tension entre sujets IT et features métier se joue à tous les niveaux de l'organisation.

Au niveau de l'équipe, c'est la bataille du sprint : avancer sur les fonctionnalités attendues, ou investir dans la qualité technique ? La feature se voit, notamment en démo, et se célèbre. La dette remboursée, elle, est invisible. Dans ce contexte, le PO - qui a naturellement plus la main sur la priorisation - se retrouve à devoir être "convaincu" par les développeurs ou le tech lead que tel refactoring est nécessaire.

Au niveau du portefeuille, c'est la même tension amplifiée : un chantier de décommissionnement d'un middleware vieillissant sera toujours moins sexy qu’un projet CRM avec un business case de dix pages. La valeur du premier est indirecte et différée : c'est du risque à ne pas faire, pas du gain à faire. Et le risque est vraiment ressenti qu'une fois qu'il s'est matérialisé en véritable problème.

Mais attention : l'erreur serait de n'y voir qu'un problème du côté métier. Le silotage peut créer une dérive symétrique côté IT. Isolés dans leur couloir, les équipes techniques peuvent avoir tendance à proposer des chantiers "par défaut" - pour être à l'état de l'art, pour refactorer parce que c'est le bon moment, pour adopter la dernière technologie - sans toujours s'assurer que ces investissements sont ancrés dans les enjeux réels de l'entreprise. Le risque de “s'acheter une Rolls-Royce pour faire ses courses” est toujours possible.

Les deux dérives existent, et elles se nourrissent mutuellement, et prennent leur source dans le fossé de responsabilités entre IT et métier.

La “tier list” des solutions

Chez OCTO, nous avons eu la chance d’expérimenter des pratiques chez la plupart de nos clients - certaines transformantes, d'autres moins. Et pour vous remercier, chers lecteurs, de votre fidélité au blog OCTO, plutôt qu'un énième tableau de bonnes pratiques, nous vous avons concocté une Tier List (inspirée du monde du gaming). Le principe : classer les solutions du niveau F au niveau S, de la moins impactante à la plus game-changing.

Solution 1 : La capacité réservée, sanctuariser du temps pour l'investissement long terme

Ce que c'est

Sanctuariser un pourcentage fixe de la capacité pour les sujets IT, indépendamment des demandes métier.

Certaines frameworks comme SAFe préconisent d'allouer une part explicite de la capacité aux enablers, et sans fixer de chiffre universel, car cela dépend du contexte. En pratique, il est fréquent d’entendre parler de 10 à 20% comme point de départ raisonnable, à ajuster selon le niveau de dette existante :

• Peu de legacy : 10-15% suffisent pour entretenir au fil de l'eau
• Legacy significatif : 20-30% le temps de rembourser la dette accumulée, redescendre ensuite
• Legacy critique : au-delà, c'est souvent le signe qu'un chantier dédié s'impose plutôt qu'un simple quota

Ce n'est pas un objectif vague : c'est une règle du jeu non négociable, appliquée en permanence, à tous les niveaux : un quota de vélocité réservé à chaque sprint pour la dette technique au niveau équipe, une enveloppe budgétaire dédiée aux chantiers IT au niveau portefeuille.

L'idée est simple : comme pour le brossage de dents, c'est l'effort régulier qui évite l'intervention coûteuse. Pas besoin de perdre du temps à débattre à chaque sprint à propos du brossage de dents ce soir; c’est une routine, point.

Ce qui a l’air de fonctionner chez certains clients : 10% de la capacité réservée, entièrement à la main de l'équipe IT. C’est simple et dans un respect de l’autonomie : ni le management, ni le métier n’en contrôlent le contenu, juste que la capacité est utilisée.

C'est un premier step important de maturité. Il permet de garantir un investissement technique minimal sans avoir à convaincre à chaque itération. Mais il a une limite importante : les sujets IT restent gérés séparément des sujets métier. Du temps est alloué - mais rien ne garantit que ce temps est utilisé sur ce qui compte le plus pour l'entreprise.

Les avantages

• Simple à comprendre et à mettre en place
• Force une discipline régulière sans changer le modèle organisationnel
• S'applique immédiatement, à tous les niveaux

Les inconvénients

• Fragile si elle n'est pas sanctuarisée dans les règles du jeu - à la première urgence il peut être tentant de taper dans cette réserve
• Ne garantit pas l'alignement des chantiers IT avec les enjeux de l'entreprise
• Le pourcentage est arbitraire, et le bon ratio peut être difficile à calibrer selon les contextes

Verdict

⭐ A-Tier : Accessible et efficace comme point de départ. Mais c'est un premier niveau, pas une destination. Elle crée de l'espace pour les sujets IT, c’est déjà cela! Ce qui a été fait de cet espace est une autre question.

Solution 2 : Prioriser IT et métier ensemble, la valeur comme terrain commun

Ce que c'est

La capacité réservée sanctuarise du temps pour les sujets IT. Mais elle ne répond pas à une question plus fondamentale : sur quoi investit-on ce temps, et pourquoi ? Tant que les chantiers techniques sont priorisés dans leur coin - par les équipes IT, selon des critères IT - ils restent déconnectés des enjeux de l'entreprise. Et tant qu'ils sont déconnectés, ils restent difficilement défendables.

Cette solution s’attaque justement à cela : mettre features métier et chantiers techniques en compétition sur les mêmes bases, avec un outil de priorisation commun comme le WSJF par exemple.

Le WSJF (Weighted Shortest Job First - voir la définition officielle) est un score de priorisation basé sur le “coût du délai”, ou “coût à ne pas faire tout de suite”. Il est calculé sur une base sur la valeur, le risque et la temporalité par exemple.

Ce que cela implique concrètement, c'est de forcer une question que personne ne pose vraiment : quelle est la valeur concrète de ce chantier technique pour l'entreprise ? Pas pour les développeurs, mais pour l'entreprise.

Prenons un chantier de mise en place d’une CI/CD, par exemple. Il ne s’agit pas ici de "faire plaisir aux devs", mais déployer plus souvent et plus fiablement : ce qui réduit les coûts de run / maintenance, limite les incidents, améliore la satisfaction client, et en fin de compte protège du chiffre d'affaires. Dit comme cela, c'est un sujet métier. Et cela mérite donc d'être mis en face d'une feature dans un backlog commun.

Ce changement de posture - traiter les chantiers IT comme des sujets métier à part entière - est inconfortable au premier abord. Mais c'est précisément cet inconfort qui est sain : il oblige les équipes IT à construire un argumentaire business, et les équipes métier à évaluer le risque à ne pas faire. Pas seulement la valeur à faire.

Une nuance importante sur le WSJF appliqué aux enablers (ou chantiers techniques) : leur valeur est souvent indirecte et différée. Le critère RR/OE (Risk Reduction / Opportunity Enablement) permet de l'exprimer - en demandant explicitement : “si cela n’est pas fait maintenant, qu'est-ce que nous risquons, et quand ?” C'est là que la discussion devient vraiment intéressante.

L’avantage de cette solution est qu’elle implique que la roadmap technique soit construite en lien avec la roadmap produit, et non en parallèle. Un enabler technique n'existe pas pour pousser la solution à l'état de l'art, il existe parce qu'il supporte une ambition business identifiée. Et c'est la responsabilité des équipes IT de rendre ce lien explicite.

Les avantages

• Force les équipes IT à exprimer la valeur de leurs chantiers en langage business
• Introduit le risque à ne pas faire dans les arbitrages, ce que les outils classiques ignorent
• Crée un dialogue réel entre métier et IT autour de priorités communes
• Réduit la dérive "état de l'art pour l'état de l'art"

Les inconvénients

• Demande un effort de traduction important côté IT, savoir exprimer la valeur business d'un chantier technique n'est pas inné
• Peut être perçu comme complexe ou une contrainte supplémentaire sans réel accompagnement
• Fonctionne mieux pour les enablers bloquants directs, la dette diffuse reste plus difficile à valoriser ainsi

Verdict

⭐ A-Tier : Complémentaire à la capacité réservée et plus mature. Là où la capacité réservée dit "on consacre du temps au technique", cette approche dit "on consacre du temps au technique parce que cela vaut autant que telle feature, et voilà pourquoi". C'est un saut qualitatif important.

Attention cependant : appliquer le WSJF sans précaution sur un backlog mixte, features et enablers en compétition directe sans contextualisation ni prise de hauteur sur les critères de priorisation serait la version 😬 C-Tier de cette solution. Les enablers y perdront presque systématiquement. NB : L'outil WSJF n'est pas en cause, c'est son application sans nuance qui l'est.

Solution 3 : Les OKR IT et indicateurs de santé technique

Ce que c'est

Rendre visible la "santé IT" dans la durée avec des indicateurs partagés jusqu'au niveau direction. Les métriques DORA (fréquence de déploiement, lead time, taux d'échec des changements, temps de récupération), le ratio de dette technique, le taux d'obsolescence des composants critiques.

L'objectif : créer un langage commun entre IT et direction, pour que les discussions de budget ne se fassent plus uniquement dans l'urgence. "Réduire le temps moyen de résolution d'un incident de 4h à 1h" est plus parlant que "améliorer l'observabilité du système". Et rendre visible la dette, ou le coût de ne pas faire, est souvent ce qui manque pour que les décideurs fassent les bons arbitrages.

Les avantages

• Donne de la légitimité dans la durée aux sujets IT
• Rend visible le risque à ne pas faire, pas seulement la valeur à faire
• Crée un langage commun avec la finance et le management

Les inconvénients

• Effet lent : il faut du temps pour que ces indicateurs s'imposent comme légitimes
• Risque de devenir un exercice cosmétique si les indicateurs ne sont pas pris en compte dans les vraies décisions budgétaires

Verdict

👍 B-Tier : Indispensable sur le long terme, insuffisant seul. À mettre en place en complément des approches précédentes.

Solution 4 : Le domaine "IT for IT"

Ce que c'est

Face à la complexité croissante des systèmes et à la multiplication des équipes autonomes, une réponse organisationnelle naturelle émerge : créer un domaine dédié aux sujets IT transverses : modernisation du socle, sécurité, observabilité, CI/CD, gestion des accès, avec budget propre, roadmap visible et équipe dédiée.

Cette idée n'est pas nouvelle, mais elle connaît un regain d'intérêt. Après une décennie à pousser la décentralisation - des équipes autonomes, chacune propriétaire de son bout de SI. Or, il s’avère que cette autonomie a souvent un coût caché : des standards qui divergent, des briques transverses qui sont réinventées dix fois, une dette qui s'accumule à un échelon local sans que personne n'en ait la vision globale. Donc centraliser ce qui est vraiment transverse est clairement pertinent.

A un fort niveau de maturité, il peut être judicieux d’appliquer Team Topologies, qui a formalisé cette idée sous le nom de Platform Team, dont la règle d'or est : la plateforme est un produit interne dont les autres équipes sont les clients.

Les avantages

• Donne une existence officielle et un budget aux sujets IT transverses
• Évite la réinvention en silo de briques communes : sécurité, observabilité, CI/CD
• Crée une expertise concentrée sur les sujets de fond, visible et défendable

Les inconvénients

• Risque structurel de renforcer le silo IT/métier : isoler les sujets techniques dans un domaine dédié peut cristalliser exactement le problème de départ
• Sans sponsor métier naturel, ce domaine est vulnérable aux arbitrages budgétaires, il n'a personne pour le défendre côté business
• Dès que la Platform Team grossit ou se bureaucratise, elle peut sortir de son intention de départ "équipe qui sert les autres"

Verdict

👍 B-Tier — Pertinent pour les sujets vraiment transverses, à condition de ne jamais perdre de vue pour qui elle existe. Le jour où la Platform Team commence à se mesurer à ses propres critères plutôt qu'à la satisfaction de ceux qu'elle sert, elle devient le problème qu'elle était censée résoudre.

Solution 5 : Le binôme métier-IT, la co-responsabilité comme principe

Ce que c'est

Toutes les solutions précédentes ont un point commun : elles compensent un problème de fond sans le résoudre. Créer des mécanismes pour forcer la prise en compte des sujets IT, parce que sans ces mécanismes, ils seraient traités trop tard ou pas du bon angle. Mais pourquoi ce problème existe-t-il ? Parce que la responsabilité de ces décisions n'est pas partagée.

L'idée du binôme est d’installer une co-responsabilité entre acteurs métier et IT à chaque échelon de l'organisation. Une façon directe de définir ce qu’est la responsabilité est de poser cette question : à qui cela fait mal si cela ne marche pas ? La co-responsabilité est donc : “gagner ensemble et perdre ensemble”

Par exemple, si la plateforme tombe ou devient lente, cela doit déranger le métier, pas seulement les équipes de delivery. Donc il a un intérêt à ce que nous investissions dans la stabilité. Si le business n'avance pas (rentabilité, chiffre d’affaires, satisfaction client), cela doit embêter l'IT également.

SAFe a formalisé cette co-responsabilité à chaque échelon organisationnel :

• Au niveau portefeuille : Business Owner et Enterprise Architect
• Au niveau train (ART) : Product Management et System Architect
• Au niveau équipe : Product Owner et équipe de développement

À chaque niveau, le binôme priorise ensemble en évaluant valeur et risque, et assume collectivement les conséquences. Un chantier technique non fait qui dégrade la capacité de Delivery, devient aussi la responsabilité du Business Owner. Et une roadmap technique déconnectée des enjeux business est clairement la responsabilité de l'architecte.

Et pour que cette co-responsabilité ne reste pas une intention culturelle vague, elle doit être actée formellement : objectifs annuels partagés, OKR communs, évaluation sur les deux dimensions. Sans cela, chacun retombe naturellement dans son couloir dès que la pression monte.

Ce que nous avons pu observer chez plusieurs clients confirme que dès que cette co-responsabilité est installée dans les faits, la nature des décisions change. Les solutions proposées (capacité réservée, backlog aligné, indicateurs partagés) deviennent des évidences plutôt que des contraintes de plus.

Les avantages

• S'attaque à la cause réelle, pas aux symptômes
• Une fois installé, les autres mécanismes viennent naturellement, parce que les acteurs ont intérêt à ce qu'ils fonctionnent
• Répond aux deux dérives symétriques : le métier qui ignore l'IT, et l'IT qui se déconnecte du business
• Fonctionne à tous les échelons, de l'équipe opérationnelle à la direction

Les inconvénients

• Long à installer : cela demande un vrai changement culturel et un sponsorship fort
• Nécessite que la co-responsabilité soit actée formellement, une bonne volonté ne suffit pas
• Exige que les deux parties aient une légitimité perçue équivalente, ce qui n'est pas toujours le cas

Verdict

🏆 S-Tier — C'est la seule réponse qui s'attaque aux causes profondes. Une fois la co-responsabilité installée dans les faits, les autres solutions deviennent des évidences partagées plutôt que des contraintes imposées. Le S-Tier que tout le monde comprend intuitivement, mais que presque personne ne formalise vraiment.

La Tier List complète

Les points clés à retenir

Ignorer la partie immergée de l'iceberg ne la fait pas disparaître. Elle grossit, silencieusement, jusqu'au jour où elle devient impossible à contourner.

Mais le problème n'est pas unilatéral. Ce n'est pas le métier contre l'IT. C'est une organisation qui n'a pas encore trouvé comment faire porter à tout le monde la responsabilité de ce qui compte vraiment, la valeur livrée maintenant et la capacité à continuer à en livrer dans le futur.

Les solutions que nous proposons sont utiles et nécessaires, mais restent des rustines tant que la question de la coresponsabilité métier / IT n'est pas résolue.

En revanche, ce changement-là ne se décrète pas. Il se construit avec les bonnes personnes, les bons objectifs communs, et un sponsor suffisamment haut placé pour que cela tienne dans la durée.