Aller au contenu principal

Mettre des tests automatisés sur un logiciel métier de 20 ans : ce n'est plus réservé au neuf

Par François-Guillaume Ribreau, cofondateur de NoBullshit Conseil. Publié le 5 octobre 2026.

Dans une PME qui tourne sur un logiciel métier ancien, une croyance revient toujours : les tests automatisés seraient réservés aux projets neufs, hors de portée pour l'outil qui fait déjà vivre la maison.

Cette croyance était justifiée il y a encore peu. Elle ne l'est plus, et c'est une bonne nouvelle pour tous ceux qui vivent dans la peur de modifier leur logiciel.

« On croyait que les tests automatisés, c'était réservé aux projets neufs. Chez nous, tout est si imbriqué qu'une modif en casse une autre ailleurs. »
Propos types entendus en PME industrielle, reformulés et anonymisés, sans valeur de témoignage client.

La peur de modifier, vécue tous les jours

Sur un logiciel métier qui a vingt ans, toucher une ligne devient un pari. Les règles se sont empilées au fil des années, les dépendances se sont nouées, et l'équipe finit par toucher le moins possible pour ne rien casser.

Cette peur n'a rien d'une frilosité. Elle repose sur un constat répété : une correction ici fait apparaître un problème là-bas, souvent dans une partie de l'outil qu'on pensait sans rapport. À force, l'entreprise se résigne à geler son logiciel au moment précis où elle aurait besoin de le faire évoluer.

Pourquoi on croyait les tests réservés au neuf

L'idée venait d'une réalité économique. Instrumenter un logiciel existant, comprendre chacun de ses comportements puis écrire à la main les contrôles correspondants, demandait un effort tel que peu d'entreprises s'y lançaient. On gardait donc les tests pour les développements partant d'une feuille blanche, où ils s'écrivent au fur et à mesure.

Depuis, les outils ont changé. Il est devenu possible de mettre en place une boucle automatisée qui parcourt l'application, observe ses réponses et génère les tests qui vérifient qu'on n'a pas introduit de régression. Le travail qui demandait des mois d'écriture manuelle se ramène à une mécanique qui tourne dans le cloud.

Tests manuels et tests automatisés ne jouent pas le même rôle

Beaucoup d'équipes testent déjà, mais à la main. Quelqu'un ouvre l'application, refait les manipulations d'un dossier type et vérifie que tout se passe bien. Ce contrôle a sa valeur, et il a aussi ses limites.

Test manuelUne personne à chaque passageUn seul chemin vérifiéRejoué rarement, car coûteuxPèse sur la masse salarialeRassure une foisTest automatiséAucune intervention humaineDes centaines de cas couvertsRejoué à chaque modificationQuelques secondes par exécutionProtège en continu
Le test manuel vérifie un passage à un instant donné. Le test automatisé, unitaire ou d'intégration, replace un filet sous chaque modification.

Le test manuel ne couvre qu'un chemin, celui que la personne a pris ce jour-là, et il mobilise cette personne à chaque fois. Le test automatisé, qu'il soit unitaire ou d'intégration, rejoue des centaines de contrôles en quelques secondes, à chaque modification, sans qu'on ait à y penser. Les autocontrôles intégrés par un éditeur apportent un premier niveau, mais ils ne remplacent pas ces vrais tests, comme le montrent les effets de bord que vivent les équipes.

La boucle qui pose un filet sur l'existant

Le principe tient en trois temps. Une mécanique automatisée explore l'application telle qu'elle est, enregistre comment elle se comporte sur des cas réels, puis transforme ces observations en tests qui échouent si le comportement change sans raison.

Une fois ce filet en place, chaque correction se vérifie avant d'arriver chez les utilisateurs. La modification qui aurait cassé une autre partie de l'outil est repérée tout de suite, pendant qu'elle est encore facile à corriger. La peur de modifier recule, parce qu'un garde-fou a pris le relais de la prudence humaine.

Par où commencer

On ne couvre pas tout d'un coup, et ce n'est pas nécessaire. Les briques les plus fragiles passent en premier, celles qu'une modification casse régulièrement, que la cartographie de l'existant a fait apparaître.

Chaque zone sécurisée redevient modifiable sans crainte, et les évolutions restées en attente repartent une à une. Ce filet est aussi ce qui rend possible un remplacement progressif, lorsqu'il s'agit de sortir d'un logiciel propriétaire sans Big Bang.

Vous vivez dans la peur de modifier votre logiciel métier ?

Sécuriser l'existant avant d'y toucher

Questions fréquentes sur les tests automatisés d'un logiciel ancien

Ce qui revient quand une PME veut sécuriser son logiciel métier sans régression.

Peut-on vraiment ajouter des tests automatisés sur un vieux logiciel métier ?

Oui. Longtemps, instrumenter un logiciel ancien coûtait trop cher pour en valoir la peine, ce qui a nourri l'idée que les tests étaient réservés aux projets neufs. Aujourd'hui, une boucle automatisée dans le cloud observe le comportement de l'outil sur des cas réels et en déduit des tests de non-régression. On pose ainsi un filet sur l'existant sans le réécrire d'abord.

Quelle différence entre tests manuels et tests automatisés ?

Un test manuel consiste à cliquer soi-même dans l'application pour vérifier qu'elle réagit bien. Il ne couvre qu'un passage, demande une personne à chaque fois et pèse sur la masse salariale. Un test automatisé, unitaire ou d'intégration, rejoue le même contrôle en quelques secondes, autant de fois qu'il le faut, à chaque modification. Le premier rassure une fois, le second protège en continu.

Par où commencer pour sécuriser un logiciel métier sans régression ?

Commencez par les briques les plus fragiles, celles qu'une modification casse régulièrement, repérées grâce à la cartographie de l'existant. On y pose d'abord les tests de non-régression, puis on élargit brique par brique. Chaque zone couverte redevient modifiable sans crainte, ce qui débloque les évolutions restées en attente.