Il y a quelques semaines, je suis parti marcher avec une amie. Une sortie assez simple, sans objectif particulier, juste prendre l’air et discuter un peu.
Comme souvent, on a fini par parler de travail.
Elle bosse dans une entreprise où l’IT est important, avec des outils internes qui ont été développés au fil des années — des applications métier devenues essentielles, mais aussi de plus en plus difficiles à maintenir.
Elle m’explique que globalement, ça fonctionne toujours. Le business tourne, les équipes arrivent à faire leur travail. Mais dès qu’il faut faire évoluer quelque chose, c’est une autre histoire.
Un système qui fonctionne… mais devient difficile à faire évoluer
Les développements prennent du temps. Les bugs sont parfois difficiles à comprendre. Et surtout, personne n’a vraiment une vision complète de l’ensemble.
Je lui demande si c’est un sujet identifié en interne.
Elle me dit que oui, évidemment. Tout le monde sait que ce n’est pas idéal. Mais dans les faits, ils n’ont jamais vraiment le temps de s’en occuper.
Il y a toujours autre chose de plus urgent. Une demande métier à traiter rapidement, un incident à corriger, un projet à livrer.
Du coup, ils font comme ils peuvent. Ils corrigent, ils adaptent, ils avancent.
Le moment où la dette technique commence à peser
On a continué à marcher, et elle me donne quelques exemples concrets. Une modification qui a pris plusieurs jours alors qu’elle semblait simple au départ. Un bug qui revient régulièrement sans qu’ils aient vraiment le temps d’en comprendre la cause. Des zones du code que personne ne veut trop toucher.
Rien de dramatique pris individuellement.
Mais mis bout à bout, ça pèse.
Ils corrigent, ils adaptent, ils avancent, mais sans vraiment traiter le fond. La dette technique s’installe progressivement, sans qu’il y ait de moment précis où tout bascule.
Je lui demande s’ils ont envisagé une refonte de leur application ou une modernisation progressive de leurs outils.
Elle me répond que oui, plusieurs fois. Mais à chaque fois, ça bloque au même endroit. Difficile de dégager du temps, difficile de mobiliser une équipe sur plusieurs mois, difficile aussi de prioriser ça face aux besoins immédiats.
Reprendre le sujet sans tout arrêter
On est resté là-dessus un moment.
Je lui ai expliqué comment on intervenait parfois dans ce type de contexte. Pas sur des projets massifs, mais plutôt en venant s’intégrer à l’existant, quelques jours par mois, pour traiter ces sujets sans tout remettre en question d’un coup.
Pas sur un projet de refonte complet, mais plutôt sur une approche de maintenance évolutive et progressive.
L’idée n’est pas de tout refaire, mais de remettre un peu de structure là où ça en manque, de sécuriser certaines parties, et d’avancer progressivement.
La discussion s’est arrêtée là, on est passé à autre chose.
Une mise en place progressive
Quelques semaines plus tard, elle m’a recontacté. On a commencé à travailler ensemble sur cette base, avec un rythme d’environ dix jours par mois.
On ne parle pas de transformation radicale. Le reste de l’activité continue normalement. Mais ça leur permet de reprendre certains sujets qu’ils repoussaient depuis longtemps, sans devoir tout arrêter à côté.
Avec le recul, ce qui m’a marqué dans cette histoire, ce n’est pas tellement la situation en elle-même. Je la vois souvent.
C’est plutôt à quel point elle est acceptée comme une forme de normalité.
Les outils fonctionnent, donc on fait avec. Tant que ça tient, on avance.
Et puis un jour, ça devient plus compliqué que prévu, sans qu’il y ait vraiment eu de rupture nette.
Conclusion
Je n’ai pas l’impression qu’il y ait une bonne ou une mauvaise façon de gérer ça. Chaque boîte fait avec ses contraintes, ses priorités, ses moyens.
Mais cette discussion m’est restée en tête.
Parce qu’elle ressemblait beaucoup à d’autres que j’ai eues ces dernières années, souvent dans des contextes différents, mais avec des points communs assez frappants.
