Prioriser la dette technique selon la valeur métier
La dette technique ne se résume ni à du code ancien ni à une liste d’anomalies à corriger dès qu’un créneau se libère. Elle représente les compromis techniques qui ralentissent l’évolution d’un produit, renchérissent son exploitation, fragilisent l’expérience client ou mobilisent excessivement les équipes. Pour un responsable de projet web ou IT, la vraie question n’est donc pas seulement « quelle dette est la plus grave ? », mais « quelle dette faut-il traiter maintenant pour protéger ou créer le plus de valeur métier ? ».
Cette distinction est déterminante lorsque les capacités d’une équipe sont limitées et que fonctionnalités, conformité, incidents, modernisation et optimisation des coûts se disputent le même backlog. Les recommandations récentes d’AWS vont clairement dans ce sens : la remédiation doit être priorisée selon l’impact métier, et non selon la seule sévérité technique. Une démarche crédible consiste alors à rendre la dette visible, à relier chaque sujet à une conséquence observable, puis à arbitrer avec les équipes produit, techniques et opérationnelles sur une base partagée.
Comprendre la dette technique comme un enjeu de valeur
Une dette technique apparaît lorsqu’une décision de conception, d’architecture, de tests, de documentation ou d’exploitation permet d’avancer rapidement, mais crée un coût futur. Ce coût peut être volontaire et raisonnable : lancer un premier parcours client avec une solution temporaire peut être le bon choix si l’hypothèse produit doit encore être validée. Il devient problématique lorsque le compromis n’est plus assumé, n’est plus mesuré ou empêche l’entreprise d’atteindre ses objectifs.
Le risque classique consiste à parler de dette avec un vocabulaire réservé aux développeurs : dépendance obsolète, couplage, absence de tests automatisés, pipeline fragile ou dette de données. Ces éléments sont réels, mais ils ne suffisent pas à décider de leur ordre de traitement. Une même faiblesse technique peut être négligeable dans un outil interne peu utilisé et prioritaire dans un tunnel de conversion, une API partenaire critique ou un service qui bloque plusieurs équipes.
« Après l’analyse, examinez les constats de dette technique en équipe et priorisez la remédiation selon l’impact métier, et non selon la seule sévérité technique. » Cette formulation d’AWS, ici traduite en français, résume un principe utile : la gravité technique informe la décision, mais ne la remplace pas.
AWS rappelle également que la dette technique dépasse la technologie : elle affecte les finances, l’expérience client, la productivité interne et d’autres dimensions de l’activité. Cette vision aide à sortir d’un faux débat entre « travail technique » et « travail métier ». Réduire la dette est du travail métier lorsqu’il diminue un coût récurrent, sécurise un revenu, accélère une livraison attendue ou réduit une exposition opérationnelle.
Les formes de valeur à rechercher
Revenu et conversion :
une lenteur, une indisponibilité ou une limitation d’intégration peut dégrader un parcours d’achat, de souscription ou de renouvellement.
Expérience client :
un défaut de fiabilité, des données incohérentes ou un délai de traitement élevé peuvent augmenter la frustration et les sollicitations du support.
Vitesse de mise sur le marché :
une architecture trop couplée peut transformer chaque évolution commerciale en chantier risqué et long.
Coût d’exploitation :
une plateforme surdimensionnée, des tâches manuelles ou des doublons de solutions pèsent sur les dépenses et le temps des équipes.
Risque et continuité :
la dette peut exposer l’organisation à des incidents, à une perte de données, à une dépendance excessive ou à des difficultés de conformité.
Capacité d’innovation :
le temps libéré par la réduction de frictions peut être réinvesti dans des fonctionnalités à valeur ajoutée.
Ce cadre ne dit pas qu’il faut attendre qu’un problème devienne visible par les clients. Il impose plutôt de formuler un mécanisme de valeur explicite : quel résultat sera amélioré, pour quel public, dans quel horizon, et comment le vérifier ? C’est cette chaîne de raisonnement qui transforme une demande de nettoyage technique en décision d’investissement.
Pourquoi la sévérité technique seule conduit à de mauvais arbitrages
Une équipe d’ingénierie peut légitimement considérer qu’une dette est très grave : code difficile à faire évoluer, vulnérabilité potentielle, dépendance en fin de vie, schéma de données confus ou absence de supervision. Pourtant, classer systématiquement ces sujets par difficulté, ancienneté ou élégance architecturale peut détourner de problèmes moins spectaculaires mais plus coûteux pour l’entreprise.
Imaginons deux chantiers. Le premier concerne un composant ancien, complexe, mais isolé dans une fonction rarement modifiée. Le second concerne une intégration de paiement fragile qui oblige les équipes à intervenir manuellement et retarde régulièrement des évolutions commerciales. Le premier peut avoir une sévérité technique supérieure ; le second a souvent une contribution métier plus immédiate. Sans analyse de contexte, l’ordre de traitement serait arbitraire.
Les biais à éviter
Le biais de visibilité technique :
corriger ce qui est le plus irritant pour l’équipe, sans vérifier l’impact sur les utilisateurs, les coûts ou les délais.
Le biais de l’incident récent :
placer durablement en tête du backlog le dernier sujet douloureux, alors qu’une analyse de fréquence, d’exposition et de coût pourrait nuancer l’urgence.
Le biais du grand refactoring :
lancer une réécriture large parce qu’elle semble plus propre, sans découpage, sans résultat intermédiaire et sans hypothèse de valeur testable.
Le biais de la fonctionnalité visible :
écarter toute dette au motif qu’elle n’est pas directement vendable, alors qu’elle peut conditionner la rapidité, la fiabilité ou le coût des futures fonctionnalités.
La bonne réponse n’est pas d’opposer produit et ingénierie. Elle consiste à faire porter la discussion sur les conséquences. Si une dette réduit la vélocité de livraison, l’équipe doit pouvoir montrer quelles initiatives sont ralenties, quels délais sont allongés ou quelles opérations manuelles sont imposées. Si son traitement demande un investissement, le produit doit pouvoir préciser quelle promesse client, quel objectif commercial ou quel risque cela soutient.
Les travaux AWS sur la modernisation insistent précisément sur cette logique : l’impact métier doit primer sur la sévérité technique seule. Dans les arbitrages de portefeuille, cela signifie qu’un sujet techniquement imparfait peut rester planifié plus tard si son impact est faible et maîtrisé, tandis qu’une dette modérée mais située sur un flux stratégique peut passer devant.
Rendre la dette technique visible dans le backlog produit
Une dette qui n’apparaît que dans les conversations entre développeurs ne peut pas être arbitrée correctement. Atlassian recommande d’identifier les sujets à fort impact et d’utiliser des représentations visuelles pour montrer aux responsables la valeur du travail. Le but n’est pas de produire un reporting décoratif : il s’agit de donner aux décideurs les éléments nécessaires pour comparer une remédiation à une fonctionnalité, à une demande de conformité ou à une optimisation opérationnelle.
Le backlog doit donc accueillir explicitement les travaux de dette technique. Atlassian inclut d’ailleurs le remboursement récurrent de dette parmi les catégories de travail à prendre en compte dans la priorisation. Cette intégration évite deux écueils : la dette cachée dans des tâches techniques non planifiées, et la « file de nettoyage » séparée, toujours reportée parce qu’elle n’est jamais comparée aux demandes métier.
Une fiche de dette utile à la décision
Chaque élément n’a pas besoin d’un dossier lourd. En revanche, une formulation uniforme réduit les malentendus. Une fiche peut contenir les informations suivantes :
le périmètre concerné : service, parcours, composant, données ou chaîne de déploiement ;
le constat factuel et ses preuves : incidents, interventions manuelles, lenteurs de livraison, coûts observés ou limitations connues ;
la conséquence métier probable ou actuelle ;
les utilisateurs, clients, équipes ou partenaires touchés ;
le risque de ne rien faire pendant la période considérée ;
l’option de remédiation la plus petite qui apporte un résultat significatif ;
l’effort, les dépendances et l’incertitude ;
la mesure qui permettra de vérifier le bénéfice après livraison.
Un libellé tel que « refactoriser le module X » est trop faible pour une discussion de priorisation. Une formulation plus actionnable serait : « découpler le module X du processus de commande afin de réduire le délai et le risque des évolutions de promotion, actuellement contraintes par cette dépendance ». Elle ne promet pas un gain chiffré sans preuve ; elle explicite néanmoins le résultat attendu et crée une base de validation.
La transparence est aussi une question de confiance. Les responsables métier doivent voir qu’une estimation comporte des inconnues. Les équipes techniques doivent pouvoir expliquer qu’un faible nombre de tickets ne signifie pas toujours un faible risque : certains sujets sont peu fréquents, mais ont une forte exposition lorsqu’ils surviennent. Documenter les hypothèses vaut mieux que masquer cette incertitude derrière une note prétendument précise.
Construire une matrice impact métier, coût et risque
Une matrice ne remplace ni l’expertise ni le jugement collectif. Elle crée un langage commun et rend les arbitrages auditables. Le cadre Tech Roadmap Prioritization (TRP) d’AWS formalise une approche où le coût et l’impact métier constituent les deux axes d’une matrice partagée entre parties prenantes métier et techniques. L’intérêt est simple : expliquer pourquoi une initiative arrive avant une autre, sans réduire la décision à la personne qui parle le plus fort.
La guidance AWS sur la décomposition de bases de données recommande également d’évaluer des problèmes de couplage selon des facteurs métier et techniques dans une matrice de priorisation, afin de maximiser la valeur métier. Le même principe s’applique à la dette au sens large : on doit mesurer l’impact, estimer l’investissement et considérer les facteurs techniques qui modifient le risque ou la faisabilité.
Les dimensions d’un score pragmatique
Un modèle simple peut noter chaque dimension sur une échelle définie par l’organisation, par exemple de faible à fort. L’essentiel est d’écrire ce que chaque niveau signifie et de garder la même interprétation au fil des revues.
Impact client ou utilisateur :
ampleur de la gêne, importance du parcours et nombre de personnes exposées.
Contribution aux objectifs métier :
influence sur une priorité de croissance, de fidélisation, de qualité de service, de réduction de coûts ou de conformité.
Effet sur la capacité de livraison :
temps perdu, rework, blocages, durée des tests, complexité des déploiements ou dépendances entre équipes.
Risque de continuité :
probabilité et conséquence d’une indisponibilité, d’une erreur de données, d’une défaillance d’intégration ou d’un problème de sécurité.
Coût de remédiation :
capacité nécessaire, coût d’opportunité, dépendances externes et niveau d’incertitude.
Urgence temporelle :
échéance contractuelle, évolution d’un partenaire, période commerciale, fin de support ou fenêtre de migration.
Il est souvent préférable de ne pas fusionner aveuglément toutes les notes dans une formule unique. Un score global est pratique pour préparer une revue, mais il peut cacher un risque inacceptable ou une dépendance bloquante. Une approche saine consiste à utiliser le score pour classer les sujets, puis à appliquer des règles explicites : certains risques de sécurité, de conformité ou de continuité peuvent imposer un traitement prioritaire, même si leur valeur directe est difficile à comparer à celle d’une fonctionnalité.
Lire la matrice sans la transformer en vérité mécanique
Les dettes à fort impact et à coût modéré constituent souvent les meilleurs premiers investissements. Elles peuvent améliorer rapidement un parcours, réduire une opération manuelle ou lever un frein de livraison. Les sujets à fort impact et à coût élevé exigent généralement un découpage : une phase de découverte, une sécurisation, un pilote ou une migration progressive permettent de réduire l’incertitude avant d’engager l’ensemble du budget.
Les travaux à faible impact ne doivent pas forcément disparaître. Ils peuvent être regroupés dans des fenêtres de maintenance, traités opportunément lors d’une évolution voisine ou acceptés explicitement avec une date de réexamen. La différence est importante : reporter une dette en connaissance de cause n’est pas l’ignorer.
Dans l’approche TRP d’AWS, les équipes cherchent à s’aligner autour d’un « plan partagé avant d’écrire une seule ligne de code ». La priorisation devient ainsi un travail d’alignement, et non une simple opération de nettoyage technique.
Relier chaque chantier à une hypothèse de valeur mesurable
La valeur métier ne se limite pas au chiffre d’affaires. Dans un produit numérique, elle peut prendre la forme d’un délai de traitement réduit, d’une meilleure disponibilité, d’une baisse des interventions manuelles, d’un temps de développement récupéré ou d’une diminution de la duplication technologique. AWS Prescriptive Guidance propose de suivre des métriques de valeur pour la réduction de dette, notamment le temps développeur récupéré et l’amélioration des scores de dette technique, avec des cadences de revue mensuelles ou trimestrielles.
Ces exemples sont utiles parce qu’ils lient un chantier à un résultat observable. Ils ne dispensent pas de choisir des indicateurs adaptés au contexte. Un score de dette peut signaler une amélioration de qualité, mais il ne démontre pas seul un bénéfice commercial. Inversement, une amélioration de délai de livraison ne prouve pas automatiquement que les clients reçoivent plus de valeur : il faut relier la capacité gagnée aux initiatives effectivement réalisées.
Formuler une hypothèse testable
Décrire le problème actuel.
Par exemple : les déploiements d’un service exigent des vérifications manuelles et retardent les mises en production.
Identifier le mécanisme de valeur.
L’automatisation doit réduire le temps et le risque nécessaires pour livrer les évolutions attendues.
Choisir une mesure avant/après.
Il peut s’agir du temps de cycle, du nombre d’interventions manuelles, du taux d’échec de déploiement ou du délai de traitement.
Définir un horizon de revue.
Une évaluation mensuelle ou trimestrielle est cohérente avec la cadence recommandée par AWS pour suivre les métriques de valeur.
Décider du réinvestissement de la capacité.
Le temps dégagé doit être rendu visible : dette supplémentaire, innovation, amélioration d’un parcours ou fonctionnalités prioritaires.
Cette méthode protège contre les promesses excessives. Une équipe ne doit pas annoncer que la modernisation « améliorera la satisfaction client » sans expliquer comment. Elle peut en revanche dire : « nous pensons que la suppression de cette étape manuelle réduira le délai de réponse ; nous suivrons ce délai, les retours du support et la stabilité du flux pendant la période définie ». C’est une posture plus crédible, fondée sur une hypothèse vérifiable.
Thoughtworks défend l’intégration des décisions de dette technique dans une gestion de portefeuille orientée valeur, en les reliant à des objectifs et à des hypothèses. Cette approche est particulièrement pertinente pour les organisations qui gèrent plusieurs produits ou programmes. La dette ne devient pas un budget opaque réservé à l’IT : elle rejoint les autres investissements avec un objectif, une hypothèse, un coût et un apprentissage attendu.
Arbitrer avec les parties prenantes sans opposer produit et ingénierie
Une priorisation robuste repose sur une conversation structurée. Les équipes techniques connaissent les mécanismes de défaillance et les dépendances ; les équipes produit comprennent les utilisateurs, le calendrier et les résultats recherchés ; les opérations, la sécurité, la finance ou le support voient des coûts et des risques parfois invisibles dans le code. Exclure l’un de ces regards appauvrit la décision.
La guidance AWS récente sur les matrices partagées souligne l’intérêt d’un scoring explicite pour éviter les conflits entre parties prenantes. Le conflit n’est pas forcément un signe d’échec : il révèle souvent que les critères, les horizons ou les responsabilités ne sont pas alignés. Une matrice et une revue régulière rendent ces désaccords discutables sur des faits et des hypothèses plutôt que sur des préférences.
Un rituel de revue efficace
Préparer les éléments :
le responsable du sujet renseigne la fiche, les preuves disponibles, les dépendances et les mesures proposées.
Qualifier collectivement :
produit, ingénierie et opérations évaluent l’impact, l’urgence, l’effort et les inconnues selon les définitions convenues.
Comparer dans le même espace :
les éléments de dette sont examinés avec les fonctionnalités, les demandes réglementaires et les optimisations de coûts.
Décider et consigner :
prioriser, découper, reporter avec une date de réexamen, ou accepter le risque de manière explicite.
Revoir les résultats :
vérifier si le bénéfice attendu se matérialise et ajuster les critères si nécessaire.
Le rôle du chef de projet ou du delivery manager est moins de produire lui-même toutes les évaluations que de garantir la qualité du processus. Il veille à ce que les décisions soient traçables, que les termes soient compris par tous, que les dépendances soient visibles et que l’équipe ne confonde pas urgence perçue et priorité démontrée.
Il est également utile de distinguer les décisions réversibles des décisions difficiles à annuler. Un petit chantier qui apporte de l’observabilité peut être lancé rapidement pour éclairer une dette incertaine. Une réécriture complète ou une migration de plateforme engage davantage l’organisation ; elle mérite des jalons, une validation de la valeur et un plan de réduction des risques. Cette gradation évite de bloquer l’action tout en protégeant l’entreprise contre les paris trop grands.
Découper la remédiation pour livrer de la valeur plus tôt
Prioriser selon la valeur métier ne signifie pas attendre la fin d’une modernisation pour constater un résultat. Les programmes de dette les plus difficiles échouent souvent parce qu’ils sont présentés comme un vaste chantier technique, avec une valeur lointaine et un périmètre mouvant. Un découpage orienté résultats rend le financement et le suivi plus réalistes.
Un projet de désengagement d’un système ancien, par exemple, peut commencer par cartographier les usages, sécuriser les flux les plus critiques, isoler une interface, migrer un segment à forte valeur, puis retirer progressivement les dépendances. Chaque étape doit répondre à une question métier : réduit-elle un risque réel, accélère-t-elle une évolution attendue, diminue-t-elle un coût d’exploitation ou améliore-t-elle une expérience ?
Choisir le plus petit incrément utile
Le bon incrément n’est pas forcément le plus petit ticket technique. C’est la plus petite unité qui produit une information ou un bénéfice exploitable. Ajouter de la télémétrie sur un flux critique peut révéler où se concentre réellement la perte de temps. Automatiser un contrôle répétitif peut libérer de la capacité immédiatement. Extraire une interface stable peut permettre à plusieurs équipes de travailler sans attendre la réécriture complète du système sous-jacent.
AWS Well-Architected relie les gains de temps à la capacité de se concentrer sur le remboursement de dette, l’innovation et les fonctionnalités qui créent de la valeur. Cette idée doit guider le séquencement. Lorsque du temps est gagné, le pilotage doit rendre visible ce qui en est fait ; sinon, l’organisation risque de voir la dette réapparaître sous une autre forme, sans progression nette de sa capacité.
Le découpage aide aussi à éviter le piège de la perfection. Une équipe peut améliorer la résilience d’un service critique sans résoudre immédiatement toutes les imperfections de son architecture. Elle peut réduire la duplication la plus coûteuse avant de rationaliser l’ensemble du paysage applicatif. L’objectif est de faire reculer les contraintes qui pèsent sur la stratégie, pas de poursuivre un idéal technique abstrait.
Intégrer dette, modernisation et maîtrise des coûts dans une même feuille de route
La dette technique ne devrait plus vivre dans une file séparée, déconnectée des programmes de modernisation, des objectifs de coûts ou de la roadmap produit. Les publications AWS de 2025 et 2026 la relient aux vagues de modernisation, aux backlogs d’architecture, aux décisions d’optimisation et à la planification technologique. Cette évolution traduit une réalité de terrain : les mêmes choix d’architecture influencent simultanément les dépenses, la capacité de livraison, la fiabilité et l’expérience client.
La guidance AWS « Money Matters » recommande notamment d’évaluer la contribution métier et les dépenses opérationnelles de chaque élément technologique afin d’aligner les investissements sur les priorités de l’entreprise, de réduire la dette et d’éliminer les doublons. Pour une direction de projet, cela ouvre une question utile : ce composant, cet outil ou cette plateforme apporte-t-il une contribution proportionnée à son coût et à sa complexité ?
Des décisions de portefeuille, pas seulement des tickets
Au niveau d’un portefeuille, certaines dettes révèlent des causes systémiques : multiplication des outils pour la même fonction, plateformes non standardisées, dépendances entre domaines, absence de gouvernance des interfaces ou cycles de livraison trop manuels. Les traiter un ticket à la fois peut soulager les symptômes sans réduire le coût global. Une feuille de route doit donc combiner des remédiations locales à retour rapide et des investissements structurants justifiés par leur contribution métier.
Le cadre AWS consacré à la dette technique « purposeful » met l’accent sur l’équilibre entre dynamiques métier, technologiques et de marché. Cette notion est importante : une priorité pertinente aujourd’hui peut changer si une fenêtre commerciale, une obligation de partenaire ou une évolution du marché modifie l’impact. La revue de dette doit être régulière, non parce que les équipes manquent de constance, mais parce que la valeur est contextuelle.
Relier les chantiers de dette aux objectifs de roadmap et aux résultats attendus.
Repérer les doublons technologiques qui ajoutent des coûts et compliquent l’exploitation.
Planifier les dépendances de modernisation avant qu’elles ne bloquent une initiative produit critique.
Réserver une capacité explicite, tout en laissant la priorisation décider des sujets réellement à traiter.
Réexaminer les choix reportés lorsque les coûts, risques ou opportunités évoluent.
Une capacité réservée ne doit toutefois pas devenir une excuse pour financer indistinctement tout travail technique. Elle donne un cadre de prévisibilité ; la matrice de valeur et la revue de portefeuille conservent leur rôle pour choisir les meilleurs investissements dans cette capacité.
Mettre en place une gouvernance simple et fiable
La qualité d’une priorisation se mesure dans la durée. Une organisation peut adopter une excellente matrice, puis perdre ses bénéfices si les décisions ne sont pas suivies, si les métriques ne sont jamais relues ou si les sujets techniques sont à nouveau retirés du backlog visible. Une gouvernance légère, répétable et fondée sur les preuves est plus utile qu’un processus lourd qui décourage les équipes.
Un cycle opérationnel en cinq temps
Détecter :
recueillir les signaux provenant du delivery, du monitoring, du support, des coûts, des incidents et des retours des équipes.
Qualifier :
formuler le problème, le périmètre, le mécanisme de valeur, les risques et l’incertitude.
Prioriser :
utiliser une matrice partagée impact métier/coût, complétée par les contraintes non négociables.
Exécuter :
découper le chantier, livrer des incréments et maintenir la traçabilité avec les objectifs de roadmap.
Apprendre :
revoir les indicateurs à la cadence choisie, documenter l’écart entre hypothèse et résultat, puis adapter les décisions futures.
La confiance se construit aussi par la qualité des données. Il faut distinguer un fait observé, une estimation et une hypothèse. « Trois équipes réalisent une étape manuelle » est un constat si cela est documenté. « L’automatisation pourrait réduire le délai » est une hypothèse. « Le chantier apportera un gain déterminé » ne doit être affirmé qu’après mesure, ou présenté explicitement comme une prévision. Cette rigueur est essentielle pour dialoguer avec une direction comme avec une équipe technique expérimentée.
Enfin, aucun cadre ne dispense de l’expertise. Une équipe senior peut identifier qu’une dépendance apparemment secondaire porte un risque systémique. Un responsable produit peut savoir qu’un parcours peu utilisé aujourd’hui deviendra stratégique dans quelques mois. La matrice doit faire émerger ces connaissances, pas les effacer. Son rôle est de rendre les arbitrages comparables, compréhensibles et révisables.
Les erreurs qui font échouer une démarche orientée valeur
La première erreur est de traduire « valeur métier » par « uniquement revenu immédiat ». La continuité de service, la sécurité, la conformité, la fiabilité des données, l’efficacité des équipes et la préservation d’options stratégiques font partie de la valeur. Une dette sans effet commercial immédiat peut être prioritaire si elle met en danger la capacité de l’entreprise à opérer ou à évoluer.
La deuxième erreur est de surpromettre. Les gains de productivité ou les effets sur l’expérience client doivent être reliés à des indicateurs et vérifiés. Une estimation honnête, accompagnée d’une marge d’incertitude et d’un plan de mesure, inspire davantage confiance qu’un business case artificiellement certain.
La troisième erreur est de faire du score un substitut à la discussion. Les notes restent des appréciations. Elles doivent être challengées, contextualisées et mises à jour. Un sujet de faible priorité peut monter rapidement si son exposition change ; un chantier jugé urgent peut être découpé différemment après une phase de découverte.
La dernière erreur est d’oublier le suivi après livraison. Sans mesure, l’organisation ne sait pas si elle a réellement réduit une contrainte ou simplement déplacé la complexité. Le suivi mensuel ou trimestriel des métriques de valeur, comme le recommande AWS pour ses indicateurs de réduction de dette, transforme le backlog en boucle d’apprentissage plutôt qu’en liste d’intentions.
Prioriser la dette technique selon la valeur métier revient à faire de la qualité technique un levier stratégique concret. En rendant les sujets visibles, en reliant chaque dette à une conséquence, en comparant impact et coût dans une matrice partagée, puis en mesurant les résultats, les équipes peuvent investir là où leur effort protège le mieux l’expérience client, les finances, la continuité et la capacité d’innovation.
Cette méthode ne promet pas des décisions sans débat. Elle rend les débats plus utiles, parce qu’ils s’appuient sur des objectifs, des preuves, des hypothèses explicites et des compromis assumés. Pour un projet web ou IT, le bon objectif n’est pas d’éliminer toute dette : c’est de maîtriser celle qui freine la valeur, d’accepter consciemment celle qui reste, et de préserver la capacité de livrer durablement ce qui compte pour l’entreprise et ses utilisateurs.
