27.3 Non-régression & montées de version — le sujet expliqué

🆕 Section prospective — mise en contexte de la fiche A6

Cette page explique le sujet (le quoi, le pourquoi, les pièges connus du marché). La fiche A6 porte la décision concrète pour notre outil (champs, assistant, écran comparatif). Lire A6 pour « ce qu'on propose de construire » ; lire cette page-ci pour « pourquoi, et ce que les autres ont appris à leurs dépens ».

1. De quoi on parle, en clair

Une montée de version ERP, c'est l'éditeur (SAP, Sage, Cegid…) qui livre une nouvelle version du logiciel : correctifs, nouvelles fonctions, parfois refonte d'un module. Pour le client, c'est un moment à risque : du code qui marchait avant peut casser après, sans que personne l'ait touché volontairement.

La non-régression, c'est l'activité qui répond à une seule question :

« On vient de monter de version. Est-ce que ce qui marchait avant marche toujours ? »

Concrètement, on rejoue un sous-ensemble de tests déjà passés sur l'ancienne version, sur la nouvelle version, et on regarde ce qui a changé de résultat. Un test qui passait (OK) et qui échoue maintenant (KO) = une régression : quelque chose a cassé.

Mentalement, c'est un diff entre deux exécutions du même jeu de tests, à deux versions du système sous test. La régression = la ligne qui passe de pass à fail. Rien de plus. Toute la difficulté n'est pas dans le diff — elle est dans choisir quelles lignes rejouer (§3) et avoir gardé l'exécution N-1 pour comparer (§4).

2. Exemple concret (pour fixer les idées)

Un client tourne sur son ERP en version 2025.1. L'éditeur livre 2025.2. L'équipe recette doit valider la montée avant de la passer en production.

1. Elle ne rejoue pas tout le référentiel (2 000 flux, plusieurs semaines) — elle rejoue le cœur métier + ce que la nouvelle version est susceptible d'avoir touché.
2. Elle exécute cette sélection sur 2025.2.
3. Le flux « Facturation → génération d'avoir », qui était OK en 2025.1, ressort KO : l'avoir se génère avec un arrondi faux au centime.
4. C'est ça, une régression détectée. Un patch de l'éditeur sur le calcul de TVA a eu un effet de bord sur un module voisin. Sans campagne de non-régression, le bug part en production et c'est la compta du client qui le trouve.

Ce scénario (facturation qui casse, paie décalée de quelques centimes, commande d'achat impossible après un patch) est le cas d'école du domaine ERP : un petit changement dans un module déclenche un effet domino sur finance / RH / achats (CI Global, testgrid.io).

3. Problème n°1 : quoi rejouer ? (la sélection du périmètre)

On ne peut pas tout rejouer à chaque version — trop long, trop cher. Mais rejouer trop peu = laisser passer une régression. Choisir le bon sous-ensemble est le vrai problème, pas l'exécution.

Ce que fait le marché : la sélection par le risque

La pratique de référence 2026 est la sélection basée sur le risque (risk-based regression) : on note chaque zone fonctionnelle sur deux axes et on rejoue en priorité les plus exposées.

Axe	Ce qui fait monter la note
Impact si ça casse	Enjeu financier, réglementaire, opérationnel (la facturation > un écran de confort)
Probabilité que ça casse	Code récemment modifié, complexe, avec un historique d'anomalies élevé

Règle simple retenue par le marché : « plus de couverture là où un défaut coûte cher, plus légère là où il ne coûte rien ». Le cœur métier se rejoue à chaque version ; le périphérique stable, une fois de temps en temps (Virtuoso QA).

Traduction dans notre outil (fiche A6)

La fiche A6 transforme ces principes en quatre présélections automatiques, toutes calculables depuis nos données existantes — l'assistant propose, le testeur ajuste :

1. flux KO à la campagne de référence (déjà fragiles) ;
2. flux portant un CRIM impacté par la montée de version (changement connu) ;
3. flux marqués noyau de non-régression (regressionCore — le cœur métier, à rejouer toujours) ;
4. flux modifiés au référentiel depuis la dernière campagne (updatedAt récent).

Les axes du marché mappent 1-pour-1 sur nos présélections : probabilité → (1) historique KO + (4) modifié récemment ; changement connu → (2) CRIM impacté ; impact métier → (3) regressionCore. Aucun modèle de scoring à écrire : ce sont quatre filtres sur des champs qu'on a déjà. Le seul champ vraiment nouveau côté référentiel est tests.regressionCore (booléen).

Les gros acteurs ERP vont plus loin avec de l'analyse d'impact automatique : des outils comme Tricentis LiveCompare lisent les notes de version / transports de l'éditeur SAP et calculent les objets impactés à tester (Tricentis, docs LiveCompare). C'est exactement la logique de notre présélection n°2 (CRIM impacté), en version outillée — d'où la question ouverte Q19 : d'où vient l'info « ce CRIM est impacté par la version » ? (note de version éditeur ? saisie manuelle ?). Sans source pour cette info, la présélection 2 n'est pas alimentable.

4. Problème n°2 : comparer avec la fois d'avant (l'écran N vs N-1)

Détecter une régression suppose de garder le résultat de l'exécution précédente pour le mettre en face du nouveau. C'est trivial à dire, pénible à vivre :

Aujourd'hui en v1, comparer deux campagnes = exporter deux classeurs Excel et les rapprocher ligne à ligne, à la main. C'est lent, faux, et personne ne le fait vraiment.

Le marché résout ça en rattachant chaque campagne à une version (TestRail : milestones ; Xray : un Test Plan par version ; Zephyr : un test cycle par release) puis en offrant une vue comparative entre deux exécutions du même périmètre. La valeur métier d'une campagne de montée de version est entièrement dans cet écran : la liste des flux passés OK → KO.

Côté modèle (voir A6) : trois champs sur campaigns (isRegression, targetVersion, previousCampaignId) suffisent à relier N à N-1. Le comparatif ne stocke rien : c'est une query qui rapproche les etapeResults de deux campaignId (modèle A3bis) et sort les transitions OK → KO. Pas de collection dédiée, pas de dénormalisation. Le prérequis réel est A3 : l'assistant de sélection alimente la même mutation campaigns.addTestsFromReferentiel — d'où l'ordre imposé A3 avant A6.

5. Problème n°3 : le noyau qui gonfle (suite bloat)

Piège classique, à connaître avant de figer le modèle : le noyau de non-régression grossit tout seul et ne maigrit jamais. On ajoute un test à chaque incident, on n'en retire jamais. Au bout de quelques versions :

• la campagne de non-régression dure de plus en plus longtemps, l'équipe finit par sauter des exécutions pour tenir les délais ;
• le taux de couverture ne veut plus rien dire : la moitié des tests sont redondants ou obsolètes, ce qui donne une fausse confiance ;
• les résultats se polluent de faux positifs (tests cassés parce que périmés, pas parce que l'ERP a régressé) (Radview, ThinkSys).

Solution du marché : traiter le noyau comme du code — le tailler régulièrement (retirer l'obsolète, dédoublonner), cycles d'hygiène périodiques, et prioriser plutôt qu'accumuler.

Conséquence de design pour A6 : regressionCore doit rester révisable (un booléen qu'on peut remettre à false), et Q19 doit trancher qui possède ce noyau et sur quel critère on y entre/sort. Sinon on reconstruit le bloat qu'on cherche à éviter. La présentation par version (§4) aide : un flux systématiquement OK depuis 5 versions est un candidat à la sortie du noyau.

6. La stack Convex est-elle un obstacle ?

Non pour le cœur du besoin. Rejouer une sélection, relier deux campagnes, sortir un diff OK → KO : ce sont des lectures/écritures transactionnelles classiques — le terrain naturel de Convex. Le comparatif est une simple query temps réel, pas un traitement lourd.

Attention en revanche sur les analyses de tendance multi-versions (courbes sur 10 montées, tableaux croisés) : c'est de la business intelligence, et Convex est OLTP, pas OLAP. Ce volet-là ne se traite pas dans l'app mais par extraction périodique vers un outil dédié — voir la limite structurelle documentée en 27.4 et les exigences non-fonctionnelles §14.1.

7. À retenir

Question	Réponse courte
C'est quoi ?	Rejouer un sous-ensemble de tests après une montée de version pour repérer ce qui a cassé (transitions OK → KO).
Le vrai problème ?	Choisir quoi rejouer (§3), pas exécuter. Sélection par le risque.
Ce qui manque en v1 ?	Aucun lien entre campagnes, aucun « flux à rejouer », comparatif fait à la main sous Excel.
Ce qu'on propose (A6)	3 champs sur campaigns + 1 booléen regressionCore, un assistant à 4 présélections, un écran N vs N-1 sans stockage.
Le piège à éviter	Le noyau qui gonfle (suite bloat) → regressionCore doit rester taillable.
Bloquant à trancher	Q19 : propriétaire du noyau + source de « CRIM impacté ».

Sources

Non-régression & sélection par le risqueVirtuoso — Risk-Based Regression Testing · Katalon — Regression Test Strategy 2026 · ThinkSys — Enterprise Regression Testing Best Practices 2026 · Radview — Regression Testing: Strategies, Automation & Scaling 2026 · TestRail — Regression Testing: A Guide for QA Teams

Spécifique ERP & montées de versionCI Global — ERP Regression Testing across versions · testgrid.io — ERP Testing: Types, Process, Challenges · Tricentis LiveCompare — Test Impact Analysis · Tricentis — S/4HANA Upgrade (docs)

Rattachement à une version / comparatif (outils du marché)TestRail — Milestones · TestRail — Comparison for References report

Suite bloat / maintenance du noyauSmartesting — Fixing Regression Test Suite Bloat · Medium — QA Lead's Guide to Cleanup Test Suite Bloat