Choisir sa dette technique pendant une migration SI, plutôt que la subir

Le blocage que crée une architecture trop tôt exigée

Un fournisseur d'énergie ETI, filiale d'un groupe suisse, implémente un nouveau système de paiement destiné à remplacer progressivement un applicatif hérité. Le débat de cadrage tourne autour d'une seule question : faut-il laisser le nouveau système écrire directement dans la base de données de l'ancien, ce qui viole le principe d'isolation entre les deux systèmes, ou maintenir une séparation stricte en construisant des API synchrones faites à la main, au prix d'une complexité de développement nettement plus lourde.

L'architecture cible ne fait débat pour personne : à terme, les deux systèmes doivent être parfaitement isolés. Le problème n'est pas la destination, c'est le moment. Exiger cette isolation dès la première ligne de code revient à s'imposer une complexité artificielle pour protéger une donnée qui, de toute façon, n'est pas encore migrée. Le risque n'est plus technique, il devient un risque d'exécution : se bloquer sur un principe au détriment de la livraison.

Le paradoxe qui piège la plupart des migrations

Une architecture cible claire n'est utile que si elle laisse une place à la façon d'y arriver. Le réflexe le plus répandu sur une migration consiste à traiter chaque écart par rapport à l'architecture visée comme un échec à corriger immédiatement. C'est l'inverse qui protège réellement le projet : accepter que certains écarts soient nécessaires pendant la transition, à condition qu'ils soient choisis et non subis.

Ce qui distingue une dette subie d'une dette choisie

Une dette subie s'installe sans arbitrage explicite : personne ne l'a décidée, elle résulte d'un raccourci pris sous pression, jamais nommé, jamais documenté. Elle se découvre des mois plus tard, au moment où elle bloque une évolution que personne n'avait anticipée. Une dette choisie, à l'inverse, part d'une décision assumée : quelqu'un identifié a accepté, en connaissance de cause, de déroger temporairement au principe d'architecture, pour une raison précise et avec une sortie planifiée.

Dette choisie : le principe

Face à une architecture cible claire mais impossible à respecter immédiatement sans ralentir la migration, la meilleure décision n'est pas d'attendre de pouvoir la respecter intégralement, c'est de violer le principe de façon délibérée, bornée et documentée. Le principe qu'on peut nommer dette choisie tient sur trois conditions qui la distinguent d'un simple compromis : un périmètre limité et nommé, une contrainte de cloisonnement qui empêche la dérogation de s'étendre à d'autres fonctionnalités, et une reprise planifiée qui referme la dette à une échéance suivie, pas à un moment hypothétique où l'équipe aura « plus de temps ».

Ce que ça a donné concrètement sur cette migration

Sur ce projet, l'équipe technique a explicitement accepté que le nouveau service de paiement écrive directement dans la base héritée, à une condition stricte : l'ancien système devait cesser d'écrire dans ces mêmes tables, pour éliminer tout risque de collision entre les deux. Le cloisonnement a été posé dès le départ : seule la partie facturation du nouveau service avait le droit d'écrire dans l'ancienne base, pas l'ensemble de ses fonctionnalités. Une reprise de données ultérieure a été planifiée pour nettoyer cette dette une fois la migration suffisamment avancée.

« [...] Là où je ne veux pas qu'à un moment on dise mince, maintenant on garde des choix qu'on a fait ou pas fait parce que finalement on a investi du temps en dev. »

Cette phrase nomme exactement le risque que la dette choisie cherche à éviter : qu'un choix technique devienne définitif non pas parce qu'il est le bon, mais parce que du temps de développement a déjà été investi dessus. Une dette non documentée se fige de cette façon, par sédimentation, sans que personne ne l'ait vraiment décidée. Une dette choisie reste réversible, parce que sa sortie a été prévue avant même qu'elle soit contractée.

Où ce principe s'arrête

Dette choisie ne justifie pas n'importe quelle dérogation. Il exclut une violation dont le périmètre n'est pas contenu : si rien n'empêche techniquement d'autres fonctionnalités de suivre le même raccourci, la dette cesse d'être bornée et redevient subie. Il exclut tout autant d'ériger la pureté architecturale en condition préalable à toute livraison, ce qui bloque l'exécution sans bénéfice proportionné, c'est précisément la position inverse que défend cet article. Cette discipline de cloisonnement rejoint celle qui rend une coexistence temporaire entre ancien et nouveau système tenable sur une refonte progressive plus large, et complète l'approche construire à côté plutôt que par-dessus décrite sur une migration ERP : la dette choisie s'applique à l'intérieur de ce cadre-là, pas à sa place. Elle rejoint aussi le principe qui consiste à stabiliser avant d'étendre sur un projet repris : dans les deux cas, la priorité va à un périmètre borné et observable plutôt qu'à un objectif de pureté immédiat.

Le test à faire avant votre prochaine dérogation d'architecture

La prochaine fois qu'une équipe propose de déroger à l'architecture cible pour tenir un délai, posez trois questions avant de trancher. Le périmètre de la dérogation est-il nommé précisément, ou reste-t-il flou. Existe-t-il une contrainte technique qui empêche cette dérogation de s'étendre ailleurs. Une date de reprise est-elle fixée, avec quelqu'un identifié pour la suivre. Si les trois réponses sont oui, c'est une dette choisie, et elle protège votre exécution. Si une seule réponse manque, documentez-la avant de continuer : c'est le moment le moins coûteux pour le faire, bien avant qu'elle ne devienne une dette subie que personne ne se souvient d'avoir acceptée.