DebtOps : automatiser le désendettement technique en continu

La dette technique n'est pas un concept nouveau. Elle existe depuis les premiers jours du développement logiciel. Dès qu'on écrit du code, il faut arbitrer : jusqu'où investir en qualité, en structure et en maintenabilité avant que l'effort dépasse le bénéfice? Passé un certain point, chaque heure supplémentaire investie dans la « propreté » d'un système rapporte moins qu'elle ne coûte. C'est cet équilibre, longtemps délicat à tenir, que l'intelligence artificielle vient aujourd'hui transformer.

Un arbitrage vieux comme le logiciel

Historiquement, l'industrie s'est donné des règles du pouce pour cadrer cet arbitrage. On visait généralement qu'environ 80 % du code soit maintenable à long terme, tout en tolérant une part de dette technique — souvent située entre 5 et 20 % — qu'on acceptait de ne pas rembourser immédiatement. En deçà de ce seuil, corriger coûtait plus cher que de vivre avec le problème.

Cette tolérance n'était pas de la négligence : c'était un calcul économique rationnel. Rembourser chaque parcelle de dette technique exigeait du temps humain, une ressource rare et coûteuse. À un certain moment, l'investissement en maintenance cessait d'être rentable.

L'IA change l'équation

Ce calcul reposait entièrement sur une hypothèse : que le remboursement de la dette technique demande un effort humain important. Cette hypothèse ne tient plus.

Les modèles récents sont aujourd'hui excellents pour trouver des bugs et les corriger automatiquement. Dans la grande majorité des cas, ils produisent un correctif juste du premier coup, et la révision passe sans qu'on ait à ajuster quoi que ce soit. Ce qui exigeait auparavant une intervention humaine coûteuse devient une opération que l'on peut automatiser, exécuter en continu et répéter chaque nuit.

Autrement dit : il est désormais possible d'augmenter la qualité d'une application à très peu de frais, et de la maintenir sur le long terme sans un investissement qui, hier, n'aurait peut-être jamais été rentable. Le seuil de tolérance de 5 à 20 % de dette technique, qui était une contrainte économique, devient un choix.

Qu'est-ce que le DebtOps?

Le DevOps a automatisé la livraison. Le DevSecOps y a ajouté la sécurité. Le DebtOps applique la même logique au désendettement technique : automatiser la maintenance, la revue de code, la revue d'architecture et la revue de sécurité au moyen d'agents spécialisés.

Une précision s'impose : « DebtOps » n'est pas un terme établi ni reconnu dans l'industrie. C'est un nom que nous dérivons ici, en reprenant le schéma de nommage devenu familier — le suffixe « Ops » accolé à une nouvelle préoccupation, comme dans DevOps ou DevSecOps. Ce n'est pas une catégorie officielle; c'est une façon commode de nommer une pratique qui, elle, est bien réelle chez nous.

Chaque agent a un mandat précis : couvrir une facette de l'application et s'assurer que son évolution respecte les bonnes pratiques associées à cette facette. Ces agents tournent en continu — chez nous, chaque nuit — sur l'ensemble de nos produits.

Chez Byrnu, nous avons retenu trois facettes principales. Nous les présentons ici de la plus routinière à la plus critique.

1. La maintenance

La maintenance est par nature infinie. Chaque jour, on peut trouver quelque chose à refaire d'une meilleure façon pour améliorer la maintenabilité à long terme. C'est justement pourquoi nous l'abordons par des quick wins : de petites améliorations que l'on peut traiter en grand nombre, chaque jour.

Nous ne voulons pas de gros refactorings quotidiens. Ces chantiers doivent rester sous la responsabilité d'un humain, qui les cadre et les décide. L'agent de maintenance nourrit un flux constant de petites victoires; il ne se substitue pas au jugement humain sur les décisions structurantes.

2. L'architecture

L'architecture est traitée avec un niveau d'exigence élevé : les dérapages doivent être corrigés au fur et à mesure, et nous attendons des agents un feu vert à chaque nuit, pour chaque produit.

C'est là qu'une fondation technologique prend tout son sens. Quand on gère un portefeuille de produits, on pourrait croire qu'il faut un spécialiste par technologie et par architecture. Mais une fondation technologique — une collection d'outils réutilisables, mais aussi de patterns architecturaux et de concepts à implémenter uniformément d'un produit à l'autre — nous permet d'avoir un seul type d'agent capable de parcourir chacun de nos produits et d'en évaluer l'évolution de la même manière.

L'uniformité de la fondation rend l'automatisation de la revue d'architecture non seulement possible, mais fiable à l'échelle du portefeuille.

3. La sécurité

C'est notre première priorité. Nous la présentons en dernier parce qu'elle est le point culminant de l'exigence : les agents de sécurité ont le mandat de valider la sécurité applicative, et nous avons le devoir de régler tout problème qu'ils rapportent. Un robot qui nous signale une faille de sécurité crée une priorité, point. Nous traitons ces enjeux au fur et à mesure jusqu'à obtenir le feu vert des agents — et nous gardons une trace de ce feu vert pour garantir, dans le temps, qu'aucun produit ne dérive.

Le désendettement devient continu

La dette technique a longtemps été une fatalité économique : on la tolérait faute de mieux. Le DebtOps renverse cette logique. En confiant la revue et le remboursement à des agents spécialisés qui travaillent en continu, on maintient la qualité, la sécurité et la cohérence architecturale de nos produits sans l'investissement humain qui rendait autrefois l'opération non rentable.

Une nuance, cependant : le DebtOps ne remplace pas l'humain. Ce n'est que de l'automatisation, destinée à pallier l'effort qu'un humain devait auparavant investir sur ces trois fronts — la maintenance, l'architecture et la sécurité. Il reste des choses à prendre en charge manuellement : cadrer un refactoring d'envergure, trancher un choix d'architecture, arbitrer une exception de sécurité. Mais grâce à l'automatisation, le temps que l'humain doit y consacrer est de loin réduit.

La question n'est plus « combien de dette technique pouvons-nous nous permettre? », mais « pourquoi en garder? ». Et, à mesure que l'automatisation absorbe l'effort : l'humain reste-t-il indispensable?