Une mise à jour de sécurité, un correctif sur la facturation, une nouvelle règle de calcul : chaque modification d'une application métier peut casser quelque chose qui marchait la veille. Les tests de non-régression servent précisément à le détecter avant vos utilisateurs. Voici comment les concevoir, quoi automatiser en premier et comment les intégrer à la maintenance sans alourdir le budget.

Régression : le risque invisible de la maintenance

Une régression, c'est une fonctionnalité qui fonctionnait et qui ne fonctionne plus après une modification, souvent sans lien apparent avec ce qui a été changé. On corrige l'export comptable, et c'est l'envoi des bons de commande qui tombe en panne. On met à jour une bibliothèque, et un calcul d'arrondi change discrètement de résultat.

Ce risque grandit avec l'âge de l'application. Plus le code est ancien, plus les dépendances entre modules sont nombreuses et moins elles sont connues de l'équipe en place. C'est la raison pour laquelle beaucoup d'entreprises finissent par repousser les mises à jour : non par négligence, mais par peur de casser. Or une application qu'on n'ose plus faire évoluer accumule des failles et de la dette technique.

Le test de non-régression inverse cette logique : au lieu de craindre chaque livraison, on vérifie systématiquement, et de la même façon à chaque fois, que l'essentiel fonctionne toujours.

Ce que l'on vérifie vraiment

Un test de non-régression n'a pas vocation à tout contrôler. Il protège ce qui ferait le plus de dégâts en cas de panne. Dans une application métier, on retrouve presque toujours les mêmes familles :

  • Les parcours qui rapportent : création d'un devis, validation d'une commande, émission d'une facture.
  • Les calculs : tarifs, remises, TVA, plannings, stocks. Une erreur silencieuse y coûte souvent plus cher qu'un écran qui plante.
  • Les échanges avec d'autres logiciels : import depuis l'ERP, synchronisation CRM, export comptable, appels d'API.
  • Les droits d'accès : un utilisateur ne doit pas voir ce qu'il ne voyait pas hier.
  • Les bugs déjà corrigés : chaque anomalie réparée mérite son test, pour qu'elle ne revienne jamais.

Cette dernière règle est la plus rentable. Un bug qui réapparaît après une mise à jour entame fortement la confiance des utilisateurs, alors qu'un test écrit au moment de la correction coûte peu.

Les trois niveaux de tests automatisés

On représente souvent les tests automatisés sous la forme d'une pyramide, une image popularisée par Mike Cohn dans son livre Succeeding with Agile (2009). Elle reste un bon guide pour répartir l'effort.

Les tests unitaires, à la base

Ils vérifient une petite portion de code isolée, typiquement une fonction de calcul. Ils sont nombreux, rapides (quelques secondes pour des centaines de tests) et peu coûteux à maintenir. Ce sont eux qui protègent les règles de gestion : une remise par palier, un calcul de délai, un arrondi.

Les tests d'intégration, au milieu

Ils vérifient que plusieurs briques fonctionnent ensemble : l'application et sa base de données, ou l'application et l'API d'un partenaire. Ils détectent par exemple un champ renommé dans un flux d'import ou une requête devenue invalide après une mise à jour du moteur de base de données.

Les tests de bout en bout, au sommet

Ils pilotent l'application comme un utilisateur, dans un vrai navigateur : se connecter, remplir un formulaire, valider, vérifier le résultat. Des outils open source comme Playwright, Cypress ou Selenium le permettent. Ces tests sont les plus parlants pour un responsable métier, mais aussi les plus lents et les plus fragiles : on les réserve à une poignée de parcours critiques.

Un bon socle de non-régression contient beaucoup de tests unitaires, un nombre raisonnable de tests d'intégration et peu de tests de bout en bout, bien choisis.

Démarrer sur une application existante

La situation la plus fréquente n'est pas l'application neuve, mais l'outil en production depuis des années, sans aucun test automatisé. Inutile de viser la couverture complète d'emblée. Une démarche progressive fonctionne mieux :

  1. Lister les cinq à dix parcours vitaux avec les utilisateurs clés : ceux dont la panne bloquerait l'activité dans la journée.
  2. Les automatiser en tests de bout en bout, avec un jeu de données de test stable et anonymisé, jamais les données réelles des clients.
  3. Ajouter un test à chaque correction de bug, au niveau le plus bas possible (unitaire si le défaut est dans un calcul).
  4. Couvrir les calculs sensibles en tests unitaires lors des évolutions qui les touchent.
  5. Brancher l'exécution automatique sur la chaîne de livraison, pour que les tests tournent sans que personne n'ait à y penser.

En quelques mois, sans chantier dédié, l'application dispose d'un filet de sécurité qui couvre l'essentiel. C'est aussi un prérequis pour moderniser une application existante par étapes sans craindre l'effet domino.

Intégrer les tests à la chaîne de livraison

Un test qu'il faut penser à lancer finit par être oublié. La valeur vient de l'automatisation de l'exécution, grâce à l'intégration continue (CI/CD) : à chaque modification déposée par un développeur, les tests rapides tournent automatiquement et bloquent la livraison s'ils échouent.

Une organisation simple et efficace :

  • À chaque modification : tests unitaires et d'intégration, résultat en quelques minutes.
  • Chaque nuit ou avant chaque mise en production : la campagne complète, tests de bout en bout compris, sur l'environnement de préproduction.
  • Après une mise à jour de dépendance ou de serveur : la même campagne, rejouée à l'identique, même si aucune ligne de code métier n'a changé.

Le compte rendu doit être lisible par tous : quels tests ont échoué, sur quel parcours, avec une capture d'écran pour les tests de bout en bout. C'est ce qui permet de décider sereinement de livrer ou non.

Quatre erreurs à éviter

  • Tout miser sur les tests de bout en bout : la campagne devient lente, instable, et l'équipe finit par ignorer les échecs.
  • Accepter les tests instables : un test qui échoue une fois sur dix sans raison doit être réparé ou retiré, sinon il décrédibilise tout le socle.
  • Tester sur des données de production : risque RGPD et résultats imprévisibles. Un jeu de données dédié, maîtrisé et réinitialisable est indispensable.
  • Considérer les tests comme un livrable figé : ils évoluent avec l'application. Une évolution fonctionnelle inclut la mise à jour des tests concernés, et cela doit figurer dans le chiffrage de la maintenance évolutive.

Questions fréquentes

Quelle différence entre test de non-régression et test fonctionnel ?

Un test fonctionnel vérifie qu'une nouvelle fonctionnalité fait ce qui est attendu. Un test de non-régression vérifie que ce qui fonctionnait déjà fonctionne toujours après une modification. Le même scénario peut servir aux deux : écrit pour une nouveauté, il rejoint ensuite le socle de non-régression.

Faut-il automatiser tous les tests de non-régression ?

Non. On automatise en priorité les parcours critiques et répétitifs, ceux qu'on rejoue à chaque livraison. Les vérifications rares, très visuelles ou qui changent souvent restent manuelles, sur une check-list courte.

Peut-on ajouter des tests automatisés à une application existante sans tests ?

Oui, c'est même le cas le plus courant. On commence par quelques tests de bout en bout sur les parcours qui rapportent ou qui coûtent cher en cas de panne, puis on complète par des tests ciblés à chaque correction de bug.

Combien de temps doit durer une campagne de non-régression ?

Le bon repère est qu'elle puisse tourner à chaque livraison sans freiner l'équipe : quelques minutes pour les tests rapides lancés à chaque modification, et une campagne complète plus longue, par exemple la nuit ou avant chaque mise en production.

Les tests de non-régression remplacent-ils la préproduction ?

Non, ils se complètent. La préproduction offre un environnement proche du réel pour valider une version ; les tests automatisés sont les contrôles qu'on y exécute, de façon identique et reproductible, avant de passer en production.

Faites évoluer votre application sans appréhension.

Pulsar Forge accompagne depuis 2005 des PME, associations et collectivités dans la maintenance et l'évolution de leurs applications métier. Nous pouvons identifier avec vous les parcours à protéger en priorité et mettre en place un premier socle de tests de non-régression adapté à votre outil. Parlons de votre projet.