Un incident qui revient, une mise en production devenue anxiogène, une fonctionnalité simple qui nécessite de toucher cinq services : c’est généralement là que le sujet devient visible. Corriger la dette d’architecture logicielle ne consiste pas à réécrire une application pour satisfaire un idéal technique. Il s’agit de réduire les risques et le coût de changement qui empêchent l’entreprise d’avancer.
Pour une PME, le problème n’est presque jamais l’absence d’une architecture parfaite. Le problème est une architecture dont personne ne maîtrise plus les dépendances, les limites ou les conditions d’exploitation. Elle continue de fonctionner, jusqu’au jour où une demande commerciale, un incident de sécurité ou le départ d’un développeur révèle sa fragilité.
La dette d’architecture est un problème de capacité
La dette de code est locale : une fonction difficile à lire, des tests absents, un nommage confus. La dette d’architecture est systémique. Elle concerne la façon dont les composants échangent des données, dont les responsabilités sont réparties, dont les déploiements sont organisés et dont l’équipe peut diagnostiquer un problème en production.
Elle se traduit rarement par une ligne comptable. Elle apparaît dans les délais : deux semaines pour estimer une évolution mineure, une journée perdue à retrouver la source d’une donnée, un déploiement reporté parce qu’une migration de base de données paraît trop risquée. Elle apparaît aussi dans l’exploitation : alertes inutiles, sauvegardes jamais restaurées, accès de production trop larges, jobs planifiés dont personne ne connaît réellement l’utilité.
Le mauvais réflexe consiste à déclarer que le système est « trop vieux » et à proposer une reconstruction complète. Une réécriture suspend les livraisons, recrée des défauts déjà résolus et consomme l’attention des personnes qui connaissent encore le métier. Elle peut être justifiée lorsque la plateforme est condamnée par ses contraintes fondamentales. C’est plus rare qu’on ne le prétend.
La bonne question est plus sobre : quelle dette limite aujourd’hui le revenu, la fiabilité, la sécurité ou la vitesse de livraison ?
Diagnostiquer avant de corriger
On ne corrige pas une dette d’architecture à partir d’un diagramme ancien ou d’un ticket Jira. Il faut lire le code, suivre un flux réel de bout en bout et vérifier ce qui se passe réellement en production. La documentation déclarée et le système exécuté ne racontent souvent pas la même histoire.
Un diagnostic sérieux commence par les parcours qui comptent : création d’un compte, paiement, commande, synchronisation avec un outil métier, génération d’un document, import de données. Pour chacun, il faut identifier les services impliqués, les bases de données, les appels externes, les files de messages, les tâches asynchrones et les points de reprise en cas d’échec.
L’architecture doit ensuite être confrontée à l’exploitation. Les logs permettent-ils d’associer un incident à une requête ou à un client ? Les erreurs sont-elles visibles avant que les utilisateurs les signalent ? Un déploiement est-il reproductible ? Peut-on restaurer les données dans un délai compatible avec l’activité ? Si la réponse est non, le sujet n’est pas seulement applicatif.
Les signaux qui justifient une intervention prioritaire
Certains symptômes méritent une décision rapide, car ils augmentent directement le risque opérationnel :
- plusieurs applications écrivent dans les mêmes tables sans contrat clair ;
- une modification impose des déploiements coordonnés sur des services supposés indépendants ;
- les traitements asynchrones ne sont ni idempotents ni traçables ;
- les secrets, sauvegardes ou droits d’accès sont gérés de façon manuelle et non vérifiée ;
- l’équipe ne peut pas expliquer ce qui se passe après un échec de paiement, une panne d’API ou une donnée corrompue.
Ces signaux ne demandent pas une refonte académique. Ils demandent une réduction ciblée des zones où l’entreprise perd le contrôle.
Prioriser par le risque, pas par l’élégance
Toutes les imperfections techniques ne se valent pas. Un module mal structuré mais stable, peu modifié et isolé peut attendre. À l’inverse, un service banal situé entre le paiement, le CRM et l’ERP peut devenir une priorité absolue s’il concentre les erreurs et bloque les opérations.
Une priorisation utile croise trois critères : la probabilité d’un incident, l’impact métier s’il survient et la fréquence de changement. Une faiblesse très impactante mais rarement touchée mérite souvent des protections opérationnelles : sauvegarde testée, procédure de reprise, monitoring, droits réduits. Une faiblesse fréquemment modifiée mérite plutôt une correction structurelle, car son coût se répète à chaque livraison.
Il faut aussi distinguer la dette qui ralentit l’équipe de celle qui met l’entreprise en danger. Les deux coûtent cher, mais elles ne se traitent pas avec le même calendrier. Une vulnérabilité d’accès, une absence de restauration testée ou une dépendance externe non maîtrisée passent avant le nettoyage d’un modèle de domaine imparfait.
Le résultat attendu n’est pas une liste vague de recommandations. C’est un registre de décisions : risque observé, preuve, impact, option de correction, coût indicatif, dépendances et ordre d’exécution. Sans cela, la dette devient un sujet récurrent de réunion plutôt qu’un plan de travail.
Corriger la dette d’architecture logicielle par tranches
Les corrections les plus fiables sont progressives et vérifiables. Elles améliorent une propriété du système sans exiger que tout le système change en même temps. Par exemple, on peut placer une couche d’API stable devant un module ancien, extraire un traitement lourd vers un worker, ou introduire une file de messages pour éviter qu’un appel externe bloque une transaction critique.
Le principe est simple : isoler avant de remplacer. Si une logique métier est enfouie dans un contrôleur, un script planifié et des requêtes SQL directes, la première étape n’est pas forcément d’extraire un microservice. Il peut être plus prudent de créer un point d’entrée unique, de couvrir les comportements existants, puis de déplacer la logique derrière une interface contrôlée.
Les microservices ne sont pas une réponse automatique. Ils peuvent réduire le couplage du code tout en ajoutant du couplage opérationnel : réseau, observabilité distribuée, déploiements multiples, gestion des versions et diagnostic plus difficile. Pour beaucoup de petites équipes, un monolithe modulaire bien testé, déployé proprement et correctement supervisé est plus rentable qu’un ensemble de services à moitié exploités.
Sécuriser chaque chantier
Chaque tranche doit produire un gain observable. Avant de toucher à un flux de facturation, définissez les métriques qui comptent : taux d’échec, durée de traitement, nombre de reprises manuelles, délai de détection. Ajoutez ensuite des logs structurés, des identifiants de corrélation et des alertes actionnables. Une alerte qui ne conduit à aucune action est du bruit.
Préparez également le retour arrière. Une migration de données doit être répétable et, quand c’est possible, réversible. Une nouvelle intégration doit pouvoir coexister temporairement avec l’ancienne. Un changement de routage doit être activable progressivement. Cela paraît plus lent au départ, mais c’est ce qui évite de transformer une correction de dette en incident majeur.
Les tests ont leur place, sans dogmatisme. Les tests unitaires protègent les règles métier isolées. Les tests d’intégration protègent les contrats de base de données et d’API. Les tests de parcours critiques protègent la livraison réelle. Le bon niveau dépend de la zone modifiée et du coût d’une régression, pas d’un objectif arbitraire de couverture.
Ne pas séparer architecture et exploitation
Une architecture exploitable est une architecture dont les erreurs sont visibles, dont les données sont récupérables et dont le déploiement ne dépend pas d’une mémoire individuelle. C’est particulièrement vrai pour les systèmes hérités ou repris après l’arrêt d’un prestataire.
La dette peut être réduite fortement sans modifier le métier : automatiser les déploiements, centraliser les secrets, documenter les procédures de reprise, tester les restaurations, mettre en place une supervision minimale et supprimer les accès permanents inutiles. Ces travaux ne sont pas spectaculaires. Ils rendent pourtant les changements futurs possibles.
L’ajout de composants IA mérite la même discipline. Un modèle peut accélérer un traitement ou améliorer une interface, mais il introduit des dépendances de coût, de confidentialité, de disponibilité et de traçabilité. Il doit être placé derrière des contrôles clairs, avec des limites de temps, des journaux adaptés et une solution de repli quand le fournisseur ou le modèle ne répond pas.
Chez Rocket Services, l’intervention commence par le système réel : code, infrastructure, déploiements, données et incidents passés. C’est la seule base sérieuse pour décider ce qu’il faut conserver, protéger, extraire ou supprimer.
Le bon chantier de dette n’est pas celui qui produit le plus beau schéma d’architecture. C’est celui qui permet à votre équipe de livrer une évolution utile vendredi, de diagnostiquer un incident lundi et de dormir entre les deux.