Par Stephanie Nicholls-Dempsey, directrice Analytique des données
Contribution de l’analyste de données au remboursement de la dette technique
Bien que la dette technique soit souvent perçue comme une responsabilité relevant principalement des équipes de développement lors d’un projet de transformation numérique, la littérature souligne l’importance de sa gestion au niveau des bases de données. Ce type de dette peut s’accumuler dès la phase de conception de la base de données, d’où la nécessité d’élargir la responsabilité de sa gestion aux concepteurs de bases de données ainsi qu’aux analystes de données.
La dette technique liée aux bases de données est définie comme des « décisions de conception immatures ou sous‑optimales qui s’écartent des décisions optimales ou souhaitables et qui se traduisent par des problèmes structurels ou comportementaux futurs, rendant les changements inévitables et plus coûteux à mettre en œuvre » (Al‑Barak et al., 2016, p. 18, traduction libre). Des impacts importants, notamment sur la viabilité économique, peuvent également affecter les systèmes ou applications alimentés par des bases de données conçues de manière inadéquate.
Parmi les exemples courants de dette technique sur une base de données, on retrouve notamment :
· Des tables comportant trop de colonnes (tables « fourre‑tout »);
· La répétition des mêmes données dans plusieurs tables;
· L’absence de clés étrangères ou de règles d’intégrité référentielle (Al‑Barak et al., 2016).
L’IA au service des analystes de données pour accélérer le remboursement de la dette technique
L’intelligence artificielle peut jouer un rôle clé dans l’accélération du remboursement de la dette technique, en particulier pour les bases de données, en outillant directement les analystes de données.
1. Le refactoring des bases de données n’est plus une activité intimidante
Avec l’intégration d’outils basés sur l’IA dans la majorité des environnements technologiques, l’analyse des structures de données peut désormais être réalisée en quelques secondes. Le refactoring devient plus accessible, sans exiger une expertise approfondie technique.
Exemples concrets d’IA en action :
- Des assistants IA intégrés aux environnements SQL ou aux notebooks analytiques peuvent analyser un schéma de base de données et signaler automatiquement :
- Des colonnes redondantes;
- Des tables peu ou jamais utilisées;
- Des relations implicites qui devraient être formalisées par des clés étrangères.
- Les analystes peuvent demander à l’IA de proposer une version normalisée d’une table, incluant la décomposition en plusieurs entités logiques (ex. séparation entre données clients et des bénéficiaires).
- Certains outils d’IA, comme Google Gemini, sont capables de générer des scripts de refactoring SQL (création de nouvelles tables, migration de données, ajout de contraintes).
Exemples d’outils: GitHub Copilot, Azure Copilot, DBT
- Analyse des schémas existants directement dans l’éditeur;
- Suggestions de normalisation (décomposition de tables, renommage cohérent).
La normalisation repose sur des règles visant à structurer les relations entre les tables afin de minimiser la redondance, améliorer l’intégrité des données et prévenir la création de dette technique (Al‑Barak et al., 2022). L’IA permet aujourd’hui d’appliquer ces principes de façon beaucoup plus systématique.
2. La création de cas de tests facilitée par l’IA
La conception et l’exécution des cas de tests sont souvent négligées ou précipitées dans un contexte agile, ce qui favorise l’accumulation de dette technique.
Exemples concrets d’IA en action :
- À partir des requis d’affaires (ex. : « le montant d’une transaction ne peut pas être négatif »), l’IA peut générer automatiquement des règles de validation de données.
- L’IA peut proposer des cas de tests de qualité des données, tels que :
- détection de valeurs nulles inattendues,
- vérification de plages de valeurs,
- contrôle des duplications ou des incohérences de formats.
- Dans les environnements de type CI/CD data, l’IA peut suggérer des tests à exécuter après une modification de schéma, réduisant ainsi les régressions silencieuses.
Exemples d’outils: Copilot IA dans les plateformes cloud (Azure Synapse, Databricks, BigQuery)
- Transformation de règles d’affaires en tests SQL;
- Génération automatique de requêtes de contrôle post‑déploiement
Bien qu’une revue humaine demeure essentielle, l’IA agit ici comme un multiplicateur de productivité, permettant aux analystes de données d’intégrer plus facilement des pratiques de tests robustes dans un contexte de livraison rapide.
3. Une documentation enfin durable grâce à l’IA
Le manque de documentation est un problème récurrent dans les projets agiles et constitue une source majeure de dette technique, particulièrement dans les écosystèmes de données complexes.
Exemples concrets d’IA en action :
- L’IA peut analyser un schéma de base de données existant et générer automatiquement une documentation descriptive pour chaque table et colonne (rôle, type de données, relations).
- À partir des requêtes SQL et des pipelines de transformation, l’IA peut produire :
- un document de mapping source‑cible,
- un glossaire d’affaires aligné sur les données techniques.
- Lors d’une modification de la base de données, l’IA peut détecter les écarts et proposer une mise à jour de la documentation, réduisant ainsi l’obsolescence documentaire.
Exemples d’outils: Data catalogs augmentés par l’IA (Microsoft Purview, Collibra, DBT)
- Génération automatique de descriptions de tables et colonnes:
- Suggestions de définitions métiers basées sur les métadonnées, l’usage réel des données et les requêtes SQL existantes.
Cette documentation ‘dynamique’ améliore la compréhension des données, facilite l’intégration des nouveaux membres et renforce la collaboration entre les équipes techniques et d’affaires.
Pour finir, bien que l’IA constitue un levier puissant pour accélérer le remboursement de la dette technique, elle doit être utilisée avec discernement. La validation humaine demeure indispensable pour assurer la qualité et la pertinence des décisions prises.
L’IA ne remplacera pas le rôle des analystes de données. En revanche, les analystes qui n’adopteront pas ces outils risquent de perdre en compétitivité. Les gains en temps, en qualité et — par conséquent — en coûts deviendront un facteur décisionnel clé pour les organisations dans les années à venir.
