Que faire lorsqu’une anomalie revient plusieurs fois ?

Une anomalie qui revient révèle souvent un problème de processus. Découvrez comment analyser les causes réelles et réduire les régressions.

QUALITÉ LOGICIELLE & QA

10/2/20253 min read

a man with glasses is looking at a laptop
a man with glasses is looking at a laptop

Une anomalie qui revient après chaque livraison n’est pas uniquement un problème de correction.

Elle peut révéler :

  • une exigence mal comprise ;

  • un scénario de test incomplet ;

  • une donnée de test non représentative ;

  • une correction qui traite le symptôme ;

  • une dépendance mal identifiée ;

  • une absence de test de non-régression ;

  • un environnement différent de celui de production ;

  • une responsabilité mal définie.

Tant que l’organisation se contente de corriger l’anomalie visible, le cycle recommence.

Commencer par caractériser la récurrence

Toutes les anomalies récurrentes ne sont pas identiques.

Il faut préciser :

  • dans quelles versions elles apparaissent ;

  • à quelle fréquence ;

  • sur quels environnements ;

  • avec quelles données ;

  • pour quels profils ;

  • après quelles évolutions ;

  • avec quelles conséquences.

Cette analyse permet de distinguer une anomalie réellement récurrente d’un problème différent qui produit un symptôme similaire.

Ne pas corriger uniquement le résultat visible

Une correction peut faire disparaître un message d’erreur sans traiter la cause.

Prenons l’exemple d’un calcul incorrect. La cause peut venir :

  • d’une règle métier incomplète ;

  • d’un format de données différent ;

  • d’une interface qui transmet une valeur incorrecte ;

  • d’un arrondi appliqué au mauvais endroit ;

  • d’un test qui ne couvre pas certains cas ;

  • d’un changement non répercuté dans un autre composant.

L’analyse doit remonter le plus loin possible dans la chaîne : exigence, conception, développement, intégration, données, test et exploitation.

Organiser une analyse de cause proportionnée

Il n’est pas nécessaire de réunir toute l’organisation pour chaque anomalie.

Pour les problèmes significatifs, une analyse courte peut documenter :

  • le symptôme ;

  • l’impact ;

  • la cause immédiate ;

  • la cause de fond ;

  • la correction réalisée ;

  • le test ajouté ou modifié ;

  • le responsable du suivi ;

  • le risque résiduel.

L’objectif n’est pas de rechercher un responsable individuel. Il s’agit d’améliorer le système qui a permis à l’anomalie de passer.

Renforcer la non-régression

Lorsqu’une anomalie est corrigée, il faut décider si elle doit devenir un test permanent.

Cette décision dépend notamment :

  • de la criticité du parcours ;

  • de la probabilité de réapparition ;

  • du coût d’une nouvelle occurrence ;

  • de la fréquence des évolutions ;

  • de la facilité d’automatisation ;

  • du niveau de risque associé.

La non-régression ne signifie pas que chaque anomalie doit automatiquement devenir un script. Elle consiste à conserver une preuve de contrôle sur les risques importants.

Vérifier l’environnement et les données

Certaines anomalies apparaissent uniquement en production parce que :

  • les volumes sont différents ;

  • les données sont plus anciennes ;

  • les droits ne sont pas identiques ;

  • les dépendances externes ne sont pas simulées ;

  • la configuration diffère ;

  • la charge est plus élevée.

Une analyse sérieuse doit donc comparer les conditions de reproduction avec les conditions réelles d’utilisation.

Mesurer les récidives

Quelques indicateurs peuvent aider à suivre le phénomène :

  • nombre d’anomalies réouvertes ;

  • anomalies réapparaissant après correction ;

  • anomalies détectées en production ;

  • délai entre correction et réapparition ;

  • pourcentage d’anomalies sans test associé ;

  • nombre de versions affectées ;

  • taux de régression sur les parcours critiques.

Ces indicateurs ne doivent pas devenir un classement des équipes. Ils servent à identifier les zones du processus qui nécessitent une amélioration.

Intégrer les contrôles dans la chaîne de livraison

Pour les projets disposant d’une chaîne CI/CD, les contrôles peuvent intégrer :

  • tests de non-régression ;

  • analyses statiques ;

  • analyses dynamiques ;

  • scans de dépendances ;

  • tests de sécurité ;

  • contrôles de conformité.

L’ANSSI recommande notamment d’intégrer des tests de sécurité automatisés et des contrôles dans la chaîne CI/CD.

À retenir

Pour réduire les anomalies récurrentes :

  1. Décrivez précisément le contexte de reproduction.

  2. Recherchez la cause de fond.

  3. Vérifiez les données et l’environnement.

  4. Ajoutez un contrôle adapté au risque.

  5. Suivez les récidives dans le temps.

Nous connectons les talents IT aux besoins des entreprises.

Vous souhaitez être contacté ?

© 2025. pragmaIT S.A.S - Tous droits réservés
Mentions légales

Nos offres