Analyse de l'effet d'entraînement : suivi d'une modification d'une seule ligne dans une base de code

Le message de commit indiquait « étendre la précision du champ de solde client ». La modification consistait en une seule ligne dans un copybook COBOL : PIC S9(9)V99 COMP-3 est devenu PIC S9(11)V99 COMP-3L'ajout de deux chiffres significatifs à un champ décimal compacté a été effectué. Le développeur a soumis le JCL de compilation, a été promu en test et a clôturé le ticket. Six heures plus tard, le traitement par lots nocturne avait échoué à trois endroits, un microservice Java renvoyait du JSON malformé pour les requêtes de solde client et un pipeline d'analyse Python avait silencieusement produit une semaine de caractéristiques de modèle incorrectes. Cette modification d'une seule ligne s'était propagée à travers quatre systèmes dans trois langages, via des chemins de dépendances que personne n'avait entièrement tracés avant l'approbation du commit.

L'analyse des effets d'entraînement consiste à retracer les voies de propagation des modifications avant même qu'elles ne soient apportées, et non après que l'incident les ait révélées. Ce terme a été introduit par Yau et Collofello en 1980 pour décrire comment une modification apportée à un module d'un système logiciel peut engendrer des effets indésirables dans d'autres modules. Ces effets d'entraînement se propagent à partir du point de modification à travers chaque composant dépendant, franchissant chaque frontière de langage et chaque contrat de données implicite, jusqu'à se dissiper ou atteindre une limite du système. Dans un code source monolangage, l'analyse des effets d'entraînement est un problème résolu : parcours du graphe d'appels, inversion du graphe d'importations, analyse statique des dépendances. Dans un code source d'entreprise couvrant COBOL, JCL, Java, Python et SQL, où les dépendances franchissent les frontières des langages via des formats de fichiers plats, des schémas de bases de données et des contrats de données implicites absents du code de chaque système, l'analyse des effets d'entraînement représente l'un des problèmes d'analyse statique les plus complexes auxquels sont confrontées les équipes de développement logiciel d'entreprise.

Les quatre types de propagation

Tous les effets d'entraînement ne sont pas équivalents. Une modification se propage dans un code source via quatre mécanismes distincts, chacun ayant des exigences de détection, un calendrier et une gravité différents :

Type 1 : Impact direct

L'artefact modifié et ses dépendants immédiats et explicites. Dans le cas d'une modification du copybook COBOL, il s'agit du copybook lui-même et de tous les programmes qui l'incluent directement via une instruction COPY. Dans le cas d'une modification de la signature d'une fonction, il s'agit de la fonction et de tous les appelants directs. L'impact direct est la couche d'effet la plus visible ; c'est ce que la plupart des développeurs considèrent intuitivement lorsqu'ils se demandent « qui utilise ceci ? »

Méthode de découverte : analyse des relations COPY/INCLUDE, analyse directe du graphe d’appels, analyse directe des importations. Génère une liste définitive sans faux négatifs pour les langages compilés.

Type 2 : Impact au moment de la compilation

Les composants qui doivent être recompilés suite à une modification, même si leur comportement à l'exécution reste inchangé, doivent l'être. En COBOL, tout programme incluant un copybook modifié doit être recompilé, même ceux qui n'utilisent que des champs inchangés du copybook. En Java, les classes étendant ou implémentant une interface modifiée doivent être recompilées, même si elles n'utilisent pas la méthode modifiée. L'impact à la compilation détermine la portée minimale de la modification lors de la compilation.

Méthode de découverte : analyse transitive des dépendances de compilation, suivant les chaînes COPY, les hiérarchies d’héritage et les graphes d’importation de modules jusqu’à leur fermeture transitive complète. Plus coûteuse qu’une analyse d’impact directe, elle est cependant indispensable pour une définition précise du périmètre de compilation.

Type 3 : Impact en cours d'exécution

Les composants dont le comportement à l'exécution sera différent suite à une modification, qu'ils nécessitent ou non une recompilation, sont concernés. Par exemple, une sous-routine COBOL dont l'interface d'appel est modifiée affecte tous les appelants à l'exécution : l'appel peut échouer, produire des résultats incorrects ou déclencher des exceptions non gérées. De même, une colonne de base de données dont le type est modifié affecte toutes les requêtes qui lisent cette colonne à l'exécution, même celles exécutées sur des systèmes non recompilés. L'impact à l'exécution est plus difficile à détecter que l'impact à la compilation, car il nécessite de comprendre non seulement les dépendances structurelles, mais aussi les dépendances comportementales.

Méthode de découverte : analyse des flux de données, parcours du graphe d’appels avec détection des modifications d’interface, analyse des dépendances de schéma. Nécessite de comprendre le rôle de chaque dépendance vis-à-vis de l’artefact modifié, et pas seulement qu’elle y fait référence.

Type 4 : Impact au niveau des données

Les systèmes qui consomment les données produites par le composant modifié, via n'importe quelle interface (fichiers plats, tables de base de données, réponses d'API, flux d'événements), subissent une dépendance au niveau des données. Cette dépendance est la plus difficile à détecter et la plus dangereuse à négliger. Un programme COBOL générant un fichier plat utilisé par un service ETL Java présente une dépendance au niveau des données : si le format de sortie du programme COBOL change, l'ETL Java cesse de fonctionner. Cette dépendance n'apparaît ni dans le graphe d'appels du programme COBOL, ni dans le graphe d'importations du programme Java, ni dans le schéma de base de données de l'un ou l'autre système. Elle réside dans le contrat de format de fichier plat, un accord implicite présent simultanément dans l'entrée FD COBOL et dans la logique d'analyse syntaxique des positions de champs Java.

Méthode de découverte : analyse du format de sortie (définitions de format de fichier, analyse du schéma d’API, analyse du schéma d’événements), traçage des flux de données inter-systèmes. Nécessite l’analyse du producteur et du consommateur pour établir le contrat et détecter toute modification susceptible de le rompre.

La trace concrète : une ligne, six systèmes

Le manuel COBOL a changé depuis l'introduction, PIC S9(9)V99 COMP-3 à PIC S9(11)V99 COMP-3, se propage à travers la trace suivante. Suivez-la couche par couche.

Couche 0 : Le changement lui-même.

Cobol

* File: CUSTMSTR.cpy -- Before
05  CUST-BALANCE    PIC S9(9)V99 COMP-3.   * 6 bytes packed decimal

* File: CUSTMSTR.cpy -- After (one line changed)
05  CUST-BALANCE    PIC S9(11)V99 COMP-3.  * 7 bytes packed decimal

Le champ s'étend d'un octet. Chaque octet qui suit CUST-BALANCE La disposition des disques se décale d'une position vers la droite.

Couche 1 (temps de compilation) : 47 programmes COBOL incluant CUSTMSTR.

Chaque programme qui comprend CUSTMSTR Le programme utilisant une instruction COPY doit être recompilé, non pas parce qu'il utilise CUST-BALANCE, mais parce que le membre du copybook utilisé pour la compilation a une structure différente. Les programmes qui ne référencent pas directement CUST-BALANCE sont également concernés : tout champ suivant CUST-BALANCE dans l'enregistrement se trouve désormais à un décalage d'octet différent.

Cobol

* TRANPROC.cbl -- includes CUSTMSTR but only reads CUST-NAME and CUST-ID
* Does not use CUST-BALANCE directly
* Still affected: CUST-NAME starts at byte 18 in the old layout
*                 CUST-NAME starts at byte 19 in the new layout
*                 Reading CUST-NAME without recompiling returns wrong bytes
       COPY CUSTMSTR.
       ...
       MOVE CUST-NAME TO WS-DISPLAY-NAME   *> Wrong bytes after the change

La découverte de ces 47 programmes nécessite une analyse des dépendances COPY de l'ensemble du portefeuille COBOL.

Couche 2 (Exécution) : 12 programmes qui écrivent des enregistrements en utilisant la disposition modifiée.

Parmi les 47 programmes, 12 enregistrent les données clients pour générer des ensembles de données, des calculs de solde, des récapitulatifs de compte et des rapports réglementaires. Le format des données de sortie de ces programmes change à l'exécution, car l'enregistrement qu'ils écrivent est désormais plus long d'un octet.

Couche 3 (Niveau de données) : 3 fichiers plats consommés par les services Java.

Trois des douze programmes génèrent des fichiers plats que les services ETL Java lisent en utilisant un système d'analyse syntaxique basé sur la position des octets. Les positions des octets utilisées par le code Java étaient correctes pour l'ancien champ CUST-BALANCE de 6 octets.

Java

// CustomerBalanceParser.java -- hardcoded positions based on old COBOL layout
// These positions are now wrong after the copybook change
public CustomerRecord parse(byte[] record) {
    String custId      = new String(record, 0,  10);  // bytes 1-10: correct
    String custName    = new String(record, 10, 40);  // bytes 11-50: correct
    // CUST-BALANCE was at bytes 51-56 (6 bytes COMP-3)
    // After the change, CUST-BALANCE is at bytes 51-57 (7 bytes COMP-3)
    byte[] balanceBytes = Arrays.copyOfRange(record, 50, 56); // now reads wrong bytes
    BigDecimal balance  = PackedDecimalConverter.decode(balanceBytes);
    // Returns incorrect balance values -- no exception, silent corruption
    String custStatus  = new String(record, 56, 2);  // was bytes 57-58
    // Now reads bytes 57-58 which is the last byte of balance + first of status
    return new CustomerRecord(custId, custName, balance, custStatus);
}

Le service Java ne génère pas d'exception. Il lit les octets 51 à 56, les interprète comme un champ COMP-3 de 6 octets (ce qui n'est pas le cas) et renvoie un nombre. Ce nombre est incorrect. La réponse semble pourtant valide.

Couche 4 (Niveau des données) : 1 pipeline ML Python consommant le service Java.

Le pipeline Python qui alimente le modèle de prédiction du taux de désabonnement client lit les soldes clients depuis le service Java et les utilise comme caractéristiques du modèle. Depuis que l'analyseur Java a commencé à renvoyer des nombres erronés, il produit des valeurs de caractéristiques incorrectes. Ces erreurs ne sont pas suffisamment importantes pour invalider le modèle, mais elles suffisent à dégrader sa précision de prédiction au fil du temps.

python

# feature_engineering.py -- consumes Java service output
def extract_balance_features(customer_id: str) -> dict:
    # Calls Java service -- which is now returning wrong balance values
    response = customer_api.get_balance(customer_id)
    balance = response['current_balance']  # silently wrong since the COBOL change

    return {
        'balance_log': np.log1p(max(0, balance)),
        'is_high_value': balance > 10000,  # wrong classification
        'balance_tier': assign_tier(balance)  # wrong tier assignment
    }

Couche 5 (Niveau des données) : Rapports réglementaires en aval de la couche 2.

Le rapport de solde réglementaire généré par l'un des 12 programmes de couche 2 contient des valeurs CUST-BALANCE incorrectes pour chaque enregistrement client traité après la modification. Il s'agit d'un incident de conformité.

Cinq niveaux d'impact suite à la modification d'une clause PIC. Portée complète :

Layer 0: 1  artifact changed   (CUSTMSTR.cpy)
Layer 1: 47 programs to recompile
Layer 2: 12 programs with changed output format
Layer 3: 3  Java services reading wrong byte positions
Layer 4: 1  Python pipeline with degraded model accuracy
Layer 5: 1  regulatory report with incorrect values
           + potential compliance notification requirement

Le problème des conditions d'arrêt

La définition classique de l'analyse des effets d'entraînement consiste à calculer l'ensemble des dépendances transitives fermées, c'est-à-dire tout artefact dépendant de l'artefact modifié, directement ou indirectement, sans limite. On obtient ainsi une définition complète et théoriquement rigoureuse du périmètre d'impact.

En pratique, pour les grands projets d'entreprise, l'ensemble des dépendances transitives est souvent trop vaste pour permettre une intervention. Une modification apportée à un schéma de base de données largement partagé peut avoir un impact transitif sur l'ensemble des applications de l'entreprise. Considérer l'entreprise entière comme la zone d'impact d'une modification de schéma est techniquement correct, mais opérationnellement inutile.

La solution pratique consiste en une analyse de propagation limitée à la profondeur : suivre l’impact jusqu’à une profondeur définie (généralement 3 à 5 sauts) et classer tout ce qui se trouve au-delà de cette profondeur comme « à surveiller en temps réel » plutôt que comme « à valider avant le déploiement ».

Les limites de profondeur correspondent aux quatre types d'impact :

• Profondeur 1 (Directe + Temps de compilation) : Doit être validé avant le déploiement. Ces dépendances entraîneront des erreurs de compilation ou un comportement manifestement incorrect si elles ne sont pas mises à jour.
• Profondeur 2-3 (Durée d'exécution) : Il convient de procéder à des tests de régression avant le déploiement. Ces dépendances, si elles ne sont pas validées, entraîneront un comportement incorrect à l'exécution.
• Profondeur 4+ (Niveau des données, transitif) : Surveillez en temps réel. Validez le contrat de données au niveau du consommateur immédiat ; appuyez-vous sur la surveillance et les alertes pour les effets transitifs plus profonds.

Pour l'exemple de modification du copybook :

• Les couches 1 et 2 correspondent à la profondeur 1 : recompilation et test obligatoires
• Couche 3 : Profondeur 2-3 : Test de régression du service Java requis
• Les couches 4 et 5 correspondent à une profondeur de 4+ : surveillance et alerte concernant la validation du format de sortie

Le critère d'arrêt ne garantit pas l'absence d'impacts plus profonds. Il s'agit d'une décision pratique de limitation du périmètre d'étude qui met en balance le coût d'une validation exhaustive et le risque résiduel d'effets plus profonds non détectés.

Ripple multilingue vs outils monolingues

Les outils existants pour l'analyse des effets d'entraînement sont majoritairement mono-langage. RippleEffect cartographie l'impact des modifications, callbacks, associations, routes, tâches et préoccupations de Ruby on Rails. L'outil alimaandev/ripple effectue une analyse d'impact des dépendances pour TypeScript et JavaScript. Des outils académiques comme CHID fonctionnent sur Java et Python. Tous ces outils sont excellents pour leur langage cible, mais tous s'arrêtent aux limites de ce langage.

L'analyse des répercussions en entreprise ne peut s'arrêter aux limites du langage, car les bases de code d'entreprise ne les respectent pas :

Dimension d'analyse	Outil monolingue	Analyse multilingue d'entreprise
COPIER/INCLURE le suivi	Au sein de la langue uniquement	En COBOL, JCL, PL/I, C
dépendance d'appel	Au sein de la langue uniquement	Appel COBOL, appel de méthode Java, importation Python, exécution JCL
Analyse des contrats de données	Schémas d'API (REST, GraphQL)	Fichiers plats, VSAM, DB2, flux d'événements, API
contrats au format de fichier plat	Non adressé	Positions d'octets de l'entrée FD COBOL dans l'analyseur Java
périmètre opérationnel du JCL	N'est pas applicable	Quels travaux appellent quels programmes, et dans quel ordre ?
impact du schéma de base de données	Tables et vues SQL	DB2 + COBOL SQL embarqué + ORM d'application
franchissement des frontières linguistiques	Arrêtons-nous à la langue.	Tracer au-delà de toutes les frontières linguistiques
Héritage et modernité combinés	Pile moderne uniquement	Chaîne complète COBOL-Java-Python-API

L'écart entre la colonne centrale « Contrats de format de fichier plat » et « Interconnexion des langages » est source des conséquences les plus dangereuses en environnement d'entreprise. Le service Java qui analyse un fichier plat COBOL avec des positions d'octets codées en dur dépend de la structure des enregistrements COBOL, laquelle n'apparaît ni dans le graphe d'importation Java ni dans le graphe d'appels COBOL. Cette dépendance réside dans le contrat de données implicite entre les deux systèmes. La détecter nécessite une analyse simultanée des deux systèmes, ce qui requiert un outil capable de comprendre à la fois les entrées de format de fichier COBOL et l'analyse des tableaux d'octets Java.

Intégrer l'analyse des répercussions dans le flux de travail de développement

L'analyse des répercussions qui survient après une modification est une enquête sur les incidents. L'analyse des répercussions qui survient avant une modification est une gestion des changements. L'intégration des flux de travail qui produit ce second type :

yaml

# GitHub Actions: pre-merge ripple scope gate
name: Ripple Effect Analysis

on:
  pull_request:
    paths:
      - '**/*.cbl'
      - '**/*.cpy'
      - '**/*.jcl'
      - '**/*.java'
      - '**/*.py'
      - '**/*.sql'

jobs:
  ripple-scope:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Identify changed files
        id: changes
        run: |
          git diff --name-only origin/main...HEAD > changed_files.txt
          echo "Changed files:"
          cat changed_files.txt

      - name: Compute ripple scope (Depth 1-3)
        id: ripple
        run: |
          # Static dependency analysis to find direct and transitive dependents
          # This step calls SMART TS XL or equivalent analysis
          # Output: ripple_scope.json with depth-annotated dependent list
          analyze-ripple \
            --changed-files changed_files.txt \
            --max-depth 3 \
            --output ripple_scope.json

      - name: Check scope threshold
        run: |
          SCOPE_SIZE=$(jq '.total_affected' ripple_scope.json)
          CRITICAL=$(jq '.depth_1_count' ripple_scope.json)

          echo "Total ripple scope: $SCOPE_SIZE components"
          echo "Critical (Depth 1): $CRITICAL components"

          # Block if Depth 1 scope exceeds threshold without impact review
          if [ "$CRITICAL" -gt 50 ]; then
            echo "High-impact change: $CRITICAL Depth-1 dependents require impact review"
            echo "Label this PR with 'impact-review-required' before merging"
            exit 1
          fi

      - name: Post ripple report to PR
        run: |
          # Post the ripple scope as a PR comment for reviewer visibility
          REPORT=$(jq -r '.summary' ripple_scope.json)
          gh pr comment ${{ github.event.pull_request.number }} \
            --body "### Ripple Effect Report\n\n$REPORT"
        env:
          GH_TOKEN: ${{ github.token }}

Ce contrôle d'impact remplit deux fonctions : il permet au relecteur de connaître la portée des modifications avant la fusion de la demande de tirage, et il empêche la fusion de modifications à fort impact sans approbation explicite lors de l'analyse d'impact. Le relecteur prend connaissance de la portée et détermine si le plan de validation la couvre.

Liste de vérification préalable à toute modification d'une portée de niveau 1 supérieure à un seuil défini :

• Tous les dépendants de niveau 1 identifiés et répertoriés
• Plan de recompilation pour les dépendances de compilation confirmé
• Couverture des tests d'exécution confirmée pour les interfaces modifiées
• Les consommateurs de contrats de données chez Depth-3 ont été identifiés et informés.
• Examen du périmètre réglementaire ou de conformité (le cas échéant)
• Un plan de retour en arrière a été défini pour chaque niveau du périmètre d'impact.
• Alerte de surveillance post-déploiement configurée pour les effets au niveau des données

Comment SMART TS XL Effectue une analyse en cascade multilingue

SMART TS XL's analyse d’impact Cette fonctionnalité permet d'effectuer une analyse multilingue des répercussions que les outils monolingues ne peuvent pas réaliser. Dans l'exemple de la modification du copybook, un SMART TS XL analyse d'impact sur CUSTMSTR.cpy produit le périmètre d'impact annoté en profondeur : les 47 programmes COBOL à la profondeur 1, les 12 programmes de production de sortie à la profondeur 2, les 3 services Java avec dépendances de fichiers plats à la profondeur 3 et le pipeline Python et le rapport réglementaire à la profondeur 4. Chaque couche, à travers chaque frontière de langage, en une seule passe d'analyse.

La cartographie des dépendances applicatives est essentielle à l'analyse de propagation inter-langages : chaque relation COPY, chaque relation CALL, chaque référence à un jeu de données JCL, chaque contrat de format de fichier plat et chaque dépendance à une table de base de données, dans l'ensemble de l'environnement, figure dans le graphe de dépendances. Lorsqu'une modification est proposée, l'analyse de propagation parcourt ce graphe, en partant de l'élément modifié et en suivant chaque arête jusqu'à atteindre la limite de profondeur.

L' analyse statique du code permet d'identifier la nature précise de chaque dépendance dans la portée de l'analyse : s'agit-il d'une dépendance de compilation (nécessitant une recompilation) ou d'une dépendance d'exécution (entraînant une modification du comportement) ? Ou encore d'une dépendance de contrat de données (une modification du format perturbe le consommateur) ? La classification des types de dépendances permet une limitation de la portée en fonction de la profondeur, distinguant ainsi la recompilation obligatoire (niveau 1) de la surveillance (niveau 4) et gérant chaque cas de manière appropriée.

La fonctionnalité de recherche d'entreprise permet d'interroger l'analyse d'impact en temps réel : trouvez tous les programmes qui incluent un copybook spécifique, tous les programmes qui appellent un sous-programme spécifique, tous les programmes qui lisent un ensemble de données spécifique. Pour les développeurs qui examinent une modification proposée, cette recherche constitue une analyse d'impact en libre-service : interrogez avant de valider, et connaissez la portée avant la clôture du ticket.

Pour les organisations menant des programmes de modernisation de systèmes existants , l'analyse des répercussions est une discipline incontournable. Chaque décision de modernisation implique une modification du système existant : migration, réécriture, mise hors service. Chacune de ces modifications a un impact qui détermine les tests à effectuer, la coordination nécessaire et la validation des systèmes en aval avant tout déploiement en toute sécurité.

Le rayon de l'explosion est toujours plus grand que la variation

Le développeur qui a modifié une clause PIC dans un copybook COBOL n'a pas agi par négligence. La modification était correcte, le champ nécessitait plus de précision, la justification métier était valable et le programme COBOL ayant effectué la modification a été compilé et testé avec succès. Ce qui lui manquait, c'était la conscience que cette modification avait des répercussions jusqu'à six niveaux de systèmes dont il n'était pas responsable et dont il ignorait peut-être l'existence.

L'analyse des répercussions vise à anticiper les effets d'un changement, non pas pour l'empêcher, mais pour le faciliter en toute sécurité. Une organisation qui connaît l'étendue complète d'un changement avant sa mise en œuvre peut la valider, séquencer le déploiement pour minimiser les risques et configurer la surveillance afin de détecter tout impact dépassant le périmètre validé. Une organisation qui découvre l'étendue du changement après l'arrêt anormal d'un traitement par lots nocturne se contente de réagir aux incidents, et non de gérer le changement.

Le rayon de l'explosion est toujours supérieur à la variation. La seule question est de savoir s'il est mesuré avant ou après le déploiement.