Outils d'analyse d'impact : comment ils fonctionnent et quelles sont les meilleures options pour les équipes d'entreprise

Chaque modification apportée à un système de production entraîne des conséquences qui dépassent le cadre du composant modifié. La modification d'une fonction partagée perturbe les appels qui dépendaient de son comportement antérieur. Une modification du schéma d'une base de données invalide silencieusement toutes les requêtes référençant la colonne modifiée. La mise à jour d'un copybook COBOL exige la recompilation de tous les programmes qui l'intègrent, ce qui peut concerner des centaines de programmes répartis sur des dizaines de flux de travaux. Tous ces programmes doivent être testés avant toute mise en production. L'analyse d'impact ne vise pas à déterminer si une modification a des conséquences, mais à identifier précisément les composants affectés, leurs liens avec l'élément modifié et l'étendue complète des validations nécessaires avant le déploiement en toute sécurité de la modification.

Sans analyse d'impact, cette question se résout par conjecture, en interrogeant le développeur ayant effectué la modification, en exécutant l'ensemble des tests en espérant que les échecs se concentrent autour des éléments pertinents, ou encore en déployant la solution et en identifiant les composants affectés lorsque les utilisateurs signalent des erreurs. Les outils d'analyse d'impact remplacent ces conjectures par des preuves structurelles : ils analysent le code source, cartographient les dépendances et génèrent une liste exhaustive de tous les composants impactés par la modification proposée. Les outils présentés dans ce guide vont des plateformes d'analyse statique aux moteurs de sélection de tests, en passant par les outils de cartographie des dépendances d'entreprise, chacun couvrant une dimension différente du problème de l'analyse d'impact.

Qu’est-ce que l’analyse d’impact en génie logiciel ?

L'analyse d'impact en génie logiciel consiste à identifier tous les composants d'un système qui sont affectés, directement ou indirectement, par une modification proposée. Elle répond à la question : si je modifie ceci, qu'est-ce qui change d'autre ? Elle intervient avant la mise en œuvre, lors de la planification, de la conception et de l'approbation des modifications, et non après coup, pendant les tests ou la gestion des incidents.

Ce terme englobe plusieurs activités connexes mais distinctes qui diffèrent par ce qu'elles analysent et par le moment où elles le font :

L'analyse d'impact des modifications permet de déterminer la portée d'une modification de code proposée avant sa mise en œuvre. Elle identifie les modules, fonctions, tables de base de données et systèmes dépendants qui devront être modifiés ou testés à nouveau suite à la modification proposée.

L'analyse d'impact des tests (AIT) est une application spécifique de l'analyse d'impact des modifications qui identifie les tests existants pertinents pour une modification de code donnée. Au lieu d'exécuter l'ensemble des tests, l'AIT sélectionne le sous-ensemble minimal de tests couvrant le code modifié et ses dépendances, réduisant ainsi le temps d'exécution tout en maintenant la couverture du périmètre affecté.

L'analyse d'impact des exigences permet d'identifier les exigences, les éléments de conception et les livrables en aval affectés par une modification d'exigence. Dans les secteurs réglementés, elle garantit la mise à jour et la revérification de tous les éléments en aval dépendant d'une exigence modifiée.

Tous trois partagent une base commune : un modèle de dépendance qui représente la façon dont les composants sont liés les uns aux autres, et un mécanisme permettant de parcourir ce modèle à partir d’un point de départ (le composant modifié) afin d’énumérer tout ce qui est accessible à partir de celui-ci.

Les trois types d'analyse d'impact

Les techniques d'analyse d'impact sont classées selon la manière dont elles recueillent les informations sur les dépendances :

Type	Méthode	Ce qu'il trouve	Quand utiliser
Analyse d'impact statique	Analyse le code source sans l'exécuter.	Toutes les références syntaxiques : appels de fonctions, importations, accès aux champs, références de schéma	Avant la mise en œuvre, lors de la planification des changements ; fonctionne sur n'importe quelle base de code
Analyse d'impact dynamique	Instruments exécutant du code pour observer les chemins d'exécution réels	Seuls les composants réellement sollicités lors d'un test d'exécution	Dépendances spécifiques à l'exécution ; identifie les chemins que l'analyse statique pourrait ne pas détecter.
Basé sur les exigences (sémantique)	Les traces assurent la traçabilité des liens entre les exigences, les conceptions et le code.	Les artefacts en amont et en aval sont affectés par une modification des exigences.	Industries réglementées ; ingénierie des systèmes ; logiciels critiques pour la sécurité

L'analyse d'impact statique est la plus répandue car elle opère uniquement sur le code source, sans nécessiter de système en fonctionnement ni d'infrastructure de test. C'est la technique utilisée par les outils présentés dans ce guide et par SMART TS XL Pour l'analyse du code source en entreprise, l'analyse dynamique complète l'analyse statique en capturant les comportements d'exécution, tels que les requêtes construites dynamiquement ou les appels de fonctions à liaison tardive, que l'analyse statique ne peut identifier à partir du seul code source. En pratique, la plupart des programmes d'analyse d'impact en production combinent les deux approches : l'analyse statique fournit la cartographie des dépendances de référence, et le profilage dynamique la valide en la comparant au comportement d'exécution observé.

Analyse d'impact statique vs dynamique : principales différences

L'analyse d'impact statique est prudente : elle peut surestimer l'étendue des dégâts en incluant des dépendances présentes dans le code mais jamais utilisées en pratique. L'analyse d'impact dynamique est précise quant aux observations effectuées, mais incomplète ; elle ne capture que les opérations réellement exécutées lors de la session instrumentée, omettant les chemins d'exécution testés avec des entrées ou des configurations différentes. Pour les systèmes de production, où l'exhaustivité prime sur la précision, l'analyse statique constitue la méthode par défaut la plus sûre.

Le processus d'analyse d'impact : étape par étape

Un processus structuré d'analyse d'impact suit une séquence cohérente quel que soit l'outil utilisé :

Étape 1 : Définir la modification. Identifiez précisément ce qui change : la fonction, le champ, la classe, le module, le copybook ou la colonne de base de données concernée. La précision à cette étape détermine l’exactitude des résultats suivants. Des définitions de modification vagues (« nous modifions le module de paiement ») produisent des résultats d’impact vagues.

Étape 2 : Construire ou interroger le modèle de dépendances. Ce modèle représente les relations entre tous les composants du système. Pour les outils automatisés, il est construit par analyse du code source. Pour l’analyse manuelle de petits systèmes, il peut être conservé sous forme de documentation. Le modèle doit être à jour : une documentation de dépendances obsolète produit des évaluations d’impact inexactes.

Étape 3 : Parcourez le graphe de dépendances à partir du point de modification. En partant du composant modifié, suivez toutes les arêtes de dépendance entrantes (composants qui dépendent du composant modifié) et sortantes (composants dont dépend le composant modifié, et dont le comportement peut être différent après la modification). Continuez transitivement jusqu’à ce que tous les composants dépendants accessibles soient énumérés.

Étape 4 : Classer les composants affectés par niveau de risque. Tous les composants affectés ne présentent pas le même niveau de risque. Un composant qui appelle directement une fonction modifiée présente un risque plus élevé qu’un composant situé à cinq niveaux de dépendance. Classer les anomalies par proximité, criticité et couverture des tests afin de cibler les efforts de correction.

Étape 5 : Définir le périmètre des tests. L’ensemble d’impact, c’est-à-dire la liste complète des composants concernés, définit le périmètre minimal des tests. Tout composant de l’ensemble d’impact non couvert par des tests automatisés représente un risque qui doit être traité soit par l’ajout de tests, soit par une validation manuelle.

Étape 6 : Documenter et examiner. Présenter l’évaluation d’impact au comité consultatif sur les changements (CCC) ou aux parties prenantes concernées afin de servir de base à l’approbation du changement. Le périmètre d’impact détaillé, assorti d’une classification des risques, remplace les estimations du promoteur par des preuves structurelles.

Analyse d'impact des tests : son fonctionnement dans l'intégration continue et le déploiement continu (CI/CD)

L'analyse d'impact des tests (AIT) applique l'analyse d'impact spécifiquement au problème des tests : suite à une modification du code, quels tests doivent être exécutés ? Sans AIT, les pipelines d'intégration continue exécutent l'intégralité de la suite de tests à chaque commit. Dans un code source comportant 50 000 tests et une suite de tests dont l'exécution prend 45 minutes, cela signifie que chaque requête d'extraction bloque le code pendant 45 minutes. C'est pourquoi les développeurs contournent ce blocage, effectuent plusieurs commits sans attendre les résultats et perdent ainsi le retour d'information que les tests sont censés fournir.

TIA résout ce problème en assurant le suivi de la correspondance entre le code et les tests : quelles lignes de code sont couvertes par quels tests. Lorsqu'un commit modifie des lignes spécifiques, TIA sélectionne uniquement les tests qui couvrent ces lignes et leurs dépendances. Une modification affectant trois fichiers sur 50 000 peut nécessiter 200 tests au lieu de 50 000. Le pipeline s'exécute en quelques secondes au lieu de plusieurs minutes.

Le mappage est construit en instrumentant l'exécution des tests pour enregistrer les données de couverture, puis en stockant ces données indexées par le code couvert. À chaque nouveau commit, TIA :

1. Identifie les fichiers et fonctions modifiés (par rapport à la différence Git).
2. Recherche les tests qui couvrent ces fichiers et fonctions.
3. Ajoute des tests qui couvrent tous les composants du graphe de dépendances statiques du code modifié.
4. Exécute le sous-ensemble sélectionné ; réussit tous les tests restants, car présumés non affectés.

Parmi les outils implémentant l'analyse d'impact des tests (TIA), on trouve l'outil d'analyse d'impact des tests de Microsoft dans Visual Studio, le moteur TIA de Parasoft, la sélection de tests de Gradle et plusieurs plugins intégrés à l'intégration continue pour Jest, pytest et d'autres outils d'exécution de tests. La précision de la TIA dépend de la précision du modèle de dépendances ; un outil qui ne suit que la couverture de code directe sans parcourir les dépendances manquera des tests couvrant des composants situés à trois niveaux de la modification.

L'AIT en pratique : avant et après

Dans un service backend d'entreprise classique, l'activation de TIA réduit le temps d'exécution des tests de 60 à 80 % en moyenne pour chaque requête d'extraction. En contrepartie, les modifications importantes, notamment celles qui touchent les utilitaires partagés, les classes de base ou la configuration largement utilisée, peuvent toujours déclencher des sous-ensembles de tests conséquents. TIA est particulièrement utile pour le développement de nouvelles fonctionnalités et la correction de bogues, lorsque les modifications sont localisées. Pour les modifications transversales telles que les mises à jour de frameworks ou les modifications de schémas partagés, une exécution complète des tests reste la solution la plus sûre.

Analyse d'impact dans la gestion des exigences et des changements

En ingénierie des systèmes et en développement logiciel réglementé, l'analyse d'impact s'étend au-delà du code pour englober l'ensemble de la chaîne d'artefacts : exigences, spécifications de conception, cas de test, évaluations des risques et preuves de vérification. Une exigence modifiée n'affecte pas seulement le code, mais aussi chaque élément de conception qui l'a mise en œuvre, chaque cas de test qui l'a vérifié, chaque évaluation des risques qui l'a prise en compte et chaque document de conformité qui y fait référence.

L'analyse d'impact basée sur les exigences utilise les liens de traçabilité pour recenser le périmètre en aval. Une matrice de traçabilité reliant chaque exigence à ses éléments de conception, cas de test et preuves de vérification permet d'identifier l'ensemble des revérifications nécessaires suite à toute modification d'exigence. Dans les secteurs réglementés (dispositifs médicaux soumis à la norme FDA 21 CFR Part 11, logiciels aéronautiques soumis à la norme DO-178C, logiciels automobiles soumis à la norme ISO 26262), cette revérification est une obligation réglementaire et non une pratique qualité facultative.

Le lien entre l'analyse d'impact des exigences et l'analyse d'impact du code réside dans la traçabilité : lorsqu'une exigence est liée à un composant logiciel spécifique et que ce composant est identifié lors d'une analyse d'impact au niveau du code, les résultats de cette analyse permettent de concentrer les efforts de revérification sur les cas de test spécifiques qui vérifient ce composant. Les plateformes modernes de gestion des exigences, telles que Jama Connect et IBM DOORS, prennent en charge cette traçabilité et offrent des fonctionnalités intégrées d'analyse d'impact au niveau des exigences.

Analyse d'impact pour les bases de code volumineuses et existantes

L'analyse d'impact des grands ensembles de code, notamment des systèmes d'entreprise développés sur plusieurs décennies, diffère qualitativement de celle d'un service de 10 000 lignes. Les différences d'échelle ne sont pas seulement quantitatives. Les grands ensembles de code existants présentent des structures de dépendances qu'aucun membre de l'équipe actuelle ne maîtrise pleinement : des milliers de programmes avec un couplage implicite via des ensembles de données partagés, des copybooks inclus simultanément par des centaines de programmes, des flux de tâches JCL avec une logique d'exécution conditionnelle complexe créant des dépendances d'exécution uniquement.

Plusieurs caractéristiques des grands ensembles de code rendent l'analyse d'impact manuelle peu fiable :

Dépendances implicites. Dans les systèmes COBOL, un copybook inclus par 300 programmes crée une dépendance invisible pour tout développeur qui ignore son existence. Une modification d'un membre du copybook, même si elle ressemble à un simple renommage de champ, peut nécessiter la recompilation et le test de l'ensemble des 300 programmes. Sans analyse automatisée, cette dépendance est découverte progressivement, chaque nouvel échec révélant une dépendance manquante.

Dépendances interlangages. Un programme COBOL écrit dans une table DB2. Un service Java lit cette même table. Un pipeline Python traite la sortie du service Java. Toute modification du schéma DB2 affecte ces trois couches. Aucun outil d'analyse statique monolangage ne peut retracer cette chaîne interlangage ; il est nécessaire de disposer d'un outil capable de comprendre et de connecter les trois langages au sein d'un modèle de dépendance unifié.

Dépendances indirectes via les données. Deux programmes qui ne s'appellent jamais peuvent néanmoins être liés par un fichier partagé. Le programme A écrit dans le jeu de données X ; le programme B lit depuis le jeu de données X. Une modification de la structure du jeu de données X affecte les deux programmes, mais la dépendance n'est pas un appel de fonction ; il s'agit d'un contrat de données exprimé par des instructions DD JCL et des définitions FD COBOL. Une analyse structurelle qui se limite aux appels de fonction ne détecte pas ce type de dépendance.

Code mort et accessibilité. Les bases de code volumineuses accumulent du code défini mais jamais appelé, des fonctions résiduelles issues de fonctionnalités supprimées, des procédures remplacées mais non effacées. Une analyse d'impact incluant le code mort dans le périmètre concerné surestime la portée des modifications et concentre les efforts de test sur des composants qui ne seront jamais utilisés en production.

La solution d'analyse de modernisation héritée pour ces environnements doit gérer tous ces cas : elle doit analyser les langages réellement utilisés (y compris COBOL, JCL, PL/I, RPG, Assembleur et DB2), résoudre les dépendances implicites via des structures de données partagées, retracer les chaînes inter-langages et distinguer le code accessible du code inaccessible.

Outils d'analyse d'impact : comparaison

Les outils ci-dessous couvrent les principales catégories d'analyse d'impact dans le développement logiciel. Chacun est évalué selon ce qu'il analyse, les langages qu'il prend en charge et le type de problème d'analyse d'impact qu'il traite le mieux.

Outil	Approche primaire	Langues	Idéal pour
SMART TS XL	Cartographie statique et inter-langages	COBOL, JCL, Java, Python, .NET, RPG, SQL	Analyse d'impact multilingue pour les entreprises et les systèmes centraux
Comprendre par SciTools	Analyse statique, graphes d'appels, visualisation des dépendances	Plus de 70 langues	Ensembles de compréhension et d'impact du code multilingue
Structure101	Analyse architecturale, graphes de dépendance	Java, C#, JVM/.NET	Impact structurel sur les applications d'entreprise Java/C#
CAST AIP	Intelligence applicative, dette technique, impact	Java, .NET, COBOL, SQL	Analyse d'impact commercial et technique au niveau du portefeuille
Suite Axivion	Graphes de dépendance sémantique pour C/C++	C, C ++	Systèmes critiques pour la sécurité, conformité MISRA, embarqués
Parasoft	Analyse d'impact des tests, intégration CI/CD	Java, C/C++, .NET	TIA dans les industries réglementées, essais critiques pour la sécurité
Connexion Jama	Traçabilité des exigences, impact des artefacts	Indépendant de la langue (niveau d'exigences)	Ingénierie des systèmes, industries réglementées, DO-178C/ISO 26262
SonarQube	Qualité du code, analyse des dépendances au sein d'un langage	Plus de 30 langues	Contrôles de qualité du code ; analyse d’impact inter-systèmes limitée
IntelliJ IDEA / Eclipse	hiérarchie des appels IDE, analyse de référence	Java, Kotlin, Python	Analyse d'impact local au niveau du développeur au sein d'un projet

Understand de SciTools est l'outil d'analyse d'impact le plus complet pour les équipes de développement logiciel utilisant des langages modernes. Sa fonctionnalité « Ensembles d'impact » calcule la fermeture transitive de toutes les entités de code affectées par une modification spécifique : chaque fonction, classe et variable accessible via le graphe de dépendances depuis le point de départ. Il prend en charge plus de 70 langages et génère des graphes d'appels détaillés, des diagrammes de flux de données et des cartes entité-relation.

Structure101 est l'outil le plus performant pour l'analyse d'impact au niveau de l'architecture Java et C#. Il visualise la structure des dépendances des packages et des classes sous forme de cartes interactives et identifie les modifications proposées qui enfreignent les limites architecturales ou créent de nouveaux cycles dans le graphe de dépendances.

CAST AIP opère au niveau du portefeuille, analysant l'ensemble du paysage applicatif, notamment COBOL, Java, .NET, SQL et d'autres langages, afin de produire des scores d'impact métier ainsi qu'une analyse d'impact technique. Il est couramment utilisé dans le cadre des audits préalables aux fusions-acquisitions et des programmes de rationalisation de portefeuille.

La suite Axivion cible le développement C et C++ critique pour la sécurité, où l'analyse d'impact doit satisfaire aux exigences réglementaires (ISO 26262, DO-178C, MISRA) et produire une preuve formelle de l'exhaustivité de l'analyse.

Parasoft est la solution TIA la plus performante pour les industries réglementées, avec un moteur de sélection de tests intégré CI/CD qui suit la couverture jusqu'au niveau de l'instruction et sélectionne des sous-ensembles de tests en fonction d'une analyse précise des dépendances.

SonarQube propose une analyse des dépendances au sein d'un projet et une détection des anomalies de code, mais n'est pas conçu pour l'analyse d'impact inter-systèmes ou inter-langages. Son intérêt dans la suite d'analyse d'impact réside dans sa fonction de contrôle qualité, permettant d'identifier les composants modifiés qui introduisent de nouveaux problèmes de qualité ou de sécurité, plutôt que dans sa fonction de cartographie des dépendances.

Les outils intégrés aux environnements de développement intégrés (hiérarchie des appels IntelliJ, analyse des références Visual Studio, graphe d'appels Eclipse) offrent aux développeurs une analyse d'impact locale au sein d'un projet. Ils permettent de comprendre l'effet d'une modification sur un module, mais ne peuvent pas retracer les dépendances entre projets, langages ou systèmes centraux.

Comment SMART TS XL Effectue une analyse d'impact

SMART TS XL L'analyse d'impact est réalisée en examinant chaque fichier source de l'environnement (programmes COBOL, flux de travaux JCL, copybooks, schémas SQL, classes Java, modules Python, programmes RPG, etc.) afin de construire un modèle de dépendance unifié représentant toutes les relations structurelles entre les langages. Ce modèle constitue la base de l'analyse : celle-ci consiste à interroger le graphe de dépendances à partir de n'importe quel composant pour en recenser tous les éléments affectés.

Lorsqu'une équipe propose de modifier un membre du copybook COBOL, SMART TS XL's analyse d’impact Réponses : Quels programmes utilisent ce copybook ? Parmi ces programmes, lesquels sont appelés par quelles étapes de tâche JCL ? Quelles tables DB2 ces programmes lisent-ils ou écrivent-ils ? Quels services Java utilisent ces tables ? Quels cas de test couvrent ces programmes ? La réponse n’est pas une estimation, mais une liste complète et numérotée, établie à partir de la structure réelle du code, avec les noms de fichiers, de programmes, de tâches et les numéros de ligne.

La fonctionnalité de cartographie des dépendances applicatives génère des diagrammes visuels du graphe de dépendances centrés sur le composant modifié, utilisant un code couleur pour distinguer les dépendances directes des dépendances indirectes et mettre en évidence les connexions les plus critiques. Ces diagrammes servent de base factuelle à l'examen du comité consultatif sur les modifications (CAB) et de feuille de route pour la planification des tests.

La fonctionnalité d'expansion JCL résout la substitution des paramètres symboliques dans les procédures avant l'analyse, garantissant ainsi que le modèle de dépendances reflète l'exécution réelle et non des références de modèles non résolues. Une procédure qui appelle différents programmes selon des paramètres symboliques est résolue en tous les programmes qu'elle appelle effectivement, assurant une couverture complète que les outils ne prenant pas en charge les paramètres symboliques ne peuvent pas garantir.

Pour les équipes d'entreprise effectuant des audits techniques préalables, planifiant la modernisation des systèmes existants ou gérant le changement dans des systèmes couvrant plusieurs langues et plateformes, SMART TS XL's recherche d'entreprise Cette fonctionnalité permet d'interroger le modèle de dépendances : trouvez en quelques secondes chaque utilisation d'un champ spécifique, chaque programme qui appelle une fonction spécifique, chaque tâche JCL qui produit un ensemble de données spécifique, dans une base de code de n'importe quelle taille.

Meilleures pratiques en matière d'analyse d'impact

Il est essentiel de commencer l'analyse d'impact avant d'écrire le code, et non après. Son objectif est d'éclairer la décision de procéder à une modification et de définir le périmètre des travaux qui en découlent, et non d'expliquer les dysfonctionnements survenus après le déploiement. Une analyse d'impact réalisée une fois la modification déjà en cours constitue une justification a posteriori, et non un outil de planification.

Définissez explicitement les limites de l'analyse d'impact. Dans les grands systèmes, les graphes d'impact peuvent s'étendre et englober la quasi-totalité des éléments. Avant d'exécuter l'analyse, définissez les limites de l'analyse, la profondeur de dépendance maximale, le code mort exclu et les systèmes hors périmètre. Un parcours non contraint produit des résultats techniquement corrects, mais inutilisables en pratique.

Il convient de distinguer les tests obligatoires de la simple surveillance. Tous les composants de l'ensemble d'impact n'exigent pas la même réponse en matière de tests. Un composant appelant directement la fonction modifiée dans un chemin critique doit être testé à nouveau. Un composant atteignant la fonction modifiée via cinq niveaux de code rarement exécuté peut être surveillé en production. La classification des risques transforme une liste d'impacts en un plan de test.

Maintenez le modèle de dépendances à jour. Une analyse d'impact réalisée sur un modèle de dépendances obsolète ou incomplet est pire qu'une absence d'analyse, car elle induit une confiance erronée dans un périmètre incorrect. Les modèles de dépendances doivent être régénérés à chaque modification importante du code source ou mis à jour de manière incrémentale via une intégration CI/CD qui réanalyse automatiquement les fichiers modifiés.

Associez l'analyse d'impact au contrôle des changements. L'analyse d'impact prend tout son sens lorsque ses résultats alimentent un processus formel de contrôle des changements. Un rapport d'impact documentant le périmètre, la classification des risques et les exigences de test fournit aux comités consultatifs de changement les éléments structurels nécessaires pour prendre des décisions d'autorisation fondées sur le système réel plutôt que sur les estimations des développeurs.

Pour les systèmes existants, il est essentiel de tenir compte du couplage implicite des données. Toute analyse de dépendances se limitant à l'étude des appels de fonctions est incomplète. Dans les environnements mainframe, les programmes couplés via des fichiers partagés, des ensembles de données, des bases de données et des files d'attente de messages sont fréquents et échappent à une analyse se limitant aux seuls appels de fonctions. Le modèle de dépendances doit impérativement prendre en compte le couplage au niveau des données pour offrir une vision complète de l'impact.

L'investissement dans l'infrastructure d'analyse d'impact, que ce soit par le biais d'un outil dédié comme SMART TS XLLe coût d'un outil d'analyse d'impact des tests comme Parasoft, ou d'une plateforme de traçabilité des exigences comme Jama, est compensé par le coût des modifications qui n'ont pas engendré de dysfonctionnements inattendus, des tests qui n'ont pas nécessité l'exécution de la suite complète et des déploiements qui n'ont pas provoqué d'incidents. Cette compensation n'est pas hypothétique. Chaque incident de production causé par une dépendance non détectée représente un coût direct de l'analyse qui n'a pas été effectuée avant la modification.