Analyse d'impact des objets SQL

Vous effectuez une trace de dépendance pré-modification pour un objet de base de données (table, colonne, procédure stockée, vue, fonction ou trigger) dans une base de code héritée ou peu familière. L'objectif est une réponse unique et fiable à : « Si je change ceci, qu'est-ce que cela affecte ? »

Quand l'utiliser

Déclenchez cette analyse quand l'utilisateur :

• Nomme une table, colonne, procédure stockée, vue ou trigger spécifique et demande ce qui l'utilise, ce qui en dépend, ou s'il est sûr de le modifier/renommer/supprimer
• S'apprête à modifier un élément de schéma dans une base de code sans ORM, ou avec une pile hétérogène héritée (SQL brut + procs stockées + code d'accès aux données manuscrit)
• Demande un « rayon d'impact », une « analyse d'impact » ou une « trace de dépendance » d'un objet DB spécifique

Ne l'utilisez pas pour :

• L'optimisation générale des performances SQL (utilisez sql-optimization)
• L'examen de la qualité/sécurité du code SQL (utilisez sql-code-review)
• L'analyse d'exposition de données confidentielles/PII (utilisez data-breach-blast-radius)
• La documentation architecturale d'une base de code entière (utilisez doc-and-modernize)

Processus

1. Confirmez l'objet cible et son (ses) nom(s) exact(s). Posez une question si c'est ambigu (p. ex., plusieurs tables avec des noms similaires, ou l'utilisateur dit « la table client » sans préciser le schéma). Obtenez l'identifiant précis avant de chercher.

2. Recherchez d'abord dans la couche SQL :

   • Cherchez dans tous les fichiers .sql, définitions de procédures stockées, vues, fonctions et triggers du dossier de scripts repo/database pour des références directes au nom de l'objet
   • Pour une colonne : vérifiez chaque proc/vue/trigger qui la sélectionne, l'insère, la met à jour ou la filtre
   • Pour une table : vérifiez chaque proc/vue/trigger qui la référence, plus les relations de clé étrangère vers/depuis d'autres tables
   • Pour une procédure stockée : vérifiez chaque autre proc qui l'appelle, et chaque travail planifié/étape d'agent qui l'invoque
   • Notez aussi les références indirectes — SQL dynamique (EXEC(@sql)), synonymes et vues construites sur des vues

3. Cherchez dans la couche application :

   • Cherchez dans tout le code application (C#, Java, JS/TS, Angular, etc.) :
     • Les chaînes SQL directes référençant le nom de l'objet
     • Les noms de méthodes/classes de couche d'accès aux données ou ORM qui le mappent (p. ex., une méthode repository appelant la procédure stockée)
     • Les handlers de points d'accès API qui finissent par toucher au chemin de données affecté
   • Tracez une couche supplémentaire si c'est raisonnable : un composant frontend consomme-t-il un endpoint qui touche cet objet ? Notez-le, mais ne poursuivez pas exhaustivement chaque consommateur UI — signalez « d'autres consommateurs en aval probables existent » si la piste disparaît plutôt que de deviner.

4. Classifiez chaque découverte par confiance :

   • Direct — nom d'objet trouvé littéralement dans le code/SQL
   • Indirect — atteint via une chaîne d'appel de proc, un mapping ORM ou du SQL dynamique qui n'a pas pu être entièrement résolu statiquement
   • Incertain — plausible mais non vérifié (p. ex., construction SQL dynamique qui n'a pas pu être tracée vers un nom d'objet littéral)
   • Ne présentez jamais une découverte Incertaine comme si elle était Direct — signalez-la clairement pour que le lecteur sache vérifier manuellement

5. Produisez le rapport (voir Format de sortie ci-dessous).

Format de sortie

Structurez toujours le rapport comme :

1. Objet cible — nom exact, type (table/colonne/proc/vue/trigger) et schéma
2. Dépendants SQL directs — liste des procs/vues/triggers/fonctions qui le référencent directement, groupés par type d'objet
3. Dépendants du code application — liste des fichiers/classes/méthodes qui le référencent, groupés par couche (accès aux données, API/service, frontend), avec chemins de fichiers
4. Références indirectes / dynamiques — tout ce qui a été trouvé via SQL dynamique, synonymes ou chaînes d'appels qui n'ont pas pu être entièrement résolu — clairement étiqueté comme nécessitant une vérification manuelle
5. Résumé des risques — un paragraphe : cet objet est-il peu utilisé (risque faible) ou largement étendu (risque élevé) ? Soulevez spécifiquement tout ce qui touche un travail planifié, une intégration externe ou une couche de reporting, car ceux-ci sont souvent oubliés
6. Étapes de vérification suggérées — actions concrètes suivantes avant d'effectuer la modification (p. ex., « exécutez ces deux procs contre les données de staging en premier », « vérifiez si le endpoint ReportingService à X dépend de cette colonne »)

Directives

• Ne prétendez jamais qu'une dépendance est complète ou exhaustive — la recherche textuelle statique ne peut pas capturer chaque construction SQL dynamique ou mapping ORM basé sur la réflexion. Énoncez explicitement la méthode de recherche utilisée et ses limites dans le rapport.
• Ne faites jamais l'invention d'un chemin de fichier, d'un nom de proc ou d'une référence de ligne. Si vous avez cherché et trouvé rien, dites « aucune référence trouvée via recherche textuelle » — pas de silence, et pas de résultat inventé.
• Si la base de code est suffisamment grande pour qu'une trace complète ne soit pas faisable en un seul passage, dites-le et proposez un scoping (p. ex., « cherchez d'abord seulement dans le module Orders ») plutôt que de produire silencieusement un rapport partiel comme s'il était complet.
• Gardez le rapport scannable — c'est une vérification de sécurité pré-modification que quelqu'un lira en quelques minutes avant de prendre une décision, pas un document d'architecture complet.