Votre patrimoine de bases de données sera-t-il prêt si la vitesse de développement augmente d’un ordre de grandeur ?

Les outils assistés par l’IA ont augmenté la vitesse et réduit le coût de production de code. Cependant, les dirigeants d’entreprise se demandent pourquoi cette efficacité ne se traduit pas par une innovation supérieure et un temps de mise sur le marché plus rapide. Au lieu d’accélérer l’ensemble du cycle de livraison, cette augmentation de vitesse a simplement exposé la fragilité des processus de modification de base de données existants.

Au cours de la dernière décennie, la réponse à “comment pouvons-nous aller plus vite ?” a été de construire de meilleures pipelines, d’investir dans la CI/CD et de déplacer les tests vers la gauche. Ces investissements ont porté leurs fruits – le code d’application se déplace à une vitesse remarquable dans les organisations d’ingénierie matures. Cependant, ces gains n’ont pas été ressentis de manière uniforme dans l’ensemble de la pile technologique. La base de données a souvent été traitée comme un cas spécial ; un actif protégé nécessitant un niveau de soins différent, des processus plus lents et une surveillance manuelle. Il y avait de bonnes raisons pour que ce modèle se développe, car les bases de données contiennent les données sur lesquelles repose l’entreprise et les erreurs peuvent être catastrophiques. Alors que la prudence était autrefois raisonnable, le coût de cette prudence a changé. En augmentant la pression sur les administrateurs de base de données et les équipes d’exploitation pour apporter des modifications à la base de données au même rythme que les développeurs peuvent maintenant écrire du code, la disparité dans la pile est devenue une contrainte. Ces équipes ne peuvent pas suivre, et les modifications de base de données tuent maintenant l’avantage de vitesse fourni par les outils assistés par l’IA. Résoudre une contrainte – le temps nécessaire pour écrire du code – a simplement mis en évidence le prochain goulet d’étranglement dans le processus. C’est la pensée systémique qui prend vie, et la friction résultante devient de plus en plus douloureuse pour l’entreprise.

La vitesse et le contrôle ne sont pas des opposés. Mais la façon dont la plupart des organisations gèrent les modifications de base de données les traite comme s’ils l’étaient.

Le modèle traditionnel de gouvernance de base de données a été conçu pour un monde de versions trimestrielles. Demandes de modification, comités d’approbation, cycles de révision manuelle, plans de restauration rédigés à l’avance des déploiements qui ont lieu quatre fois par an. Rien de tout cela n’est intrinsèquement faux. Il s’agissait d’une gestion des risques qui a grandi pour s’adapter au temps disponible entre les déploiements. Le problème est que la cadence de déploiement a changé, et pour la plupart des organisations, l’approche de gouvernance n’a pas suivi. Les équipes sont censées expédier en continu, mais elles acheminent toujours les modifications de base de données via des processus conçus pour une autre époque. Le résultat n’est pas la sécurité. Le résultat est la friction, les contournements et une classe croissante de “petites” modifications de base de données qui contournent la gouvernance entièrement parce que le processus formel est trop lent pour être pratique.

C’est là que vit le véritable risque.

Lorsque la gouvernance est trop lente pour être utilisée, les gens arrêtent de l’utiliser. Les modifications de schéma sont appliquées directement en production. Les correctifs sont expédiés sans contrôle de version, et avec la bonne intention de les faire passer correctement avec la prochaine version formelle, mais cela n’arrive pas parce que les gens sont occupés. Les étapes manuelles qui devaient être le filet de sécurité deviennent la chose que les gens contournent lorsqu’ils sont sous pression. Et la pression, dans la livraison de logiciels, est l’état par défaut.

La réponse n’est pas de ralentir la pipeline. C’est de déplacer la gouvernance à l’intérieur.

Les organisations qui ont résolu ce problème n’ont pas fait cela en relâchant leurs normes. Ils ont fait le travail plus difficile pour rendre la gouvernance suffisamment rapide pour être le chemin le plus court. Les modifications de schéma contrôlées par version, la détection de dérive automatisée, les vérifications de stratégie déterministes intégrées dans la pipeline CI/CD plutôt que d’être appliquées comme une porte à la fin. Alors que les outils alimentés par l’IA sont probabilistes – offrant des suggestions basées sur des modèles – la gouvernance doit rester déterministe pour être efficace. En utilisant des vérifications prévisibles et répétitives, vous vous assurez que chaque modification est auditable et répond aux normes de sécurité avant même d’atteindre la production. L’approbation a toujours lieu. La trace d’audit existe toujours. Mais cela se produit dans le même flux que tout le reste, plutôt que comme un processus séparé et plus lent qui se situe en dehors.

Cela compte pour une raison qui va au-delà de la productivité des développeurs. Les exigences de conformité ne sont pas en train de s’alléger. La combinaison du RGPD, de la DORA (règlement UE sur la résilience opérationnelle numérique) et d’un éventail croissant de réglementations spécifiques au secteur signifie que la gouvernance de la base de données est de plus en plus une question juridique et réglementaire, et non seulement opérationnelle. Les organisations qui ne peuvent pas démontrer une histoire traçable et auditable de modification de base de données sont exposées de manière qui devient matérielle. L’argument pour intégrer la gouvernance dans la pipeline n’est pas seulement qu’elle rend la livraison plus rapide. C’est ce qui rend la conformité traçable à grande échelle.

L’IA est en train d’accroître l’urgence.

La vague actuelle de développement assisté par l’IA rend ce problème plus aigu, et non moins aigu. Lorsque les développeurs peuvent générer et itérer sur le code d’application d’un ordre de grandeur plus rapide qu’avant, la base de données devient un goulet d’étranglement plus évident par rapport à tout ce qui l’entoure. Mais il y a un effet secondaire qui est moins largement discuté. Les outils alimentés par l’IA sont très bons pour générer une logique d’application. Ils sont moins bons pour comprendre les conséquences à long terme des modifications de schéma dans une base de données de production complexe et en direct. La combinaison d’une vitesse de développement d’application plus rapide et de suggestions de modification de schéma générées par l’IA sans gouvernance mature est exactement le type de pression qui produit des incidents. La vitesse sans garde-fous structurels crée les conditions pour que des erreurs se produisent plus rapidement.

Les organisations qui vont naviguer cela avec succès sont celles qui traitent la gouvernance de la base de données comme une préoccupation d’ingénierie de premier plan, et non comme une afterthought de conformité. Cela signifie que le contrôle de version du schéma de base de données est un paramètre par défaut non négociable, et que les tests automatisés gèrent les vérifications de routine afin que la surveillance manuelle puisse se concentrer sur les modifications à haut risque et à haute appréciation, plutôt que de devenir un goulet d’étranglement en fin de parcours. Enfin, cela signifie une détection de dérive qui identifie la divergence avant qu’elle ne provoque un incident.

La plupart des patrimoines d’entreprise rendent cela plus difficile qu’il ne devrait l’être.

Il y a une réalité cumulative qui accompagne la plupart de ces observations. La majorité des patrimoines de bases de données d’entreprise ne sont pas des cas neufs. Ils représentent des décennies de modifications de schéma accumulées, exécutées sur plusieurs plates-formes de gestion de bases de données, certaines sur site et d’autres dans le cloud, avec des degrés variables de documentation et de connaissances tribales répartis entre les équipes qui ont changé de nombreuses fois. La conversation de modernisation suppose souvent un point de départ propre que la plupart des organisations n’ont pas. C’est là que le défi est en réalité le plus aigu et souvent entrave la progression. Que l’objectif soit de soutenir l’innovation, de nettoyer et de migrer des données pour l’IA ou d’améliorer la résilience opérationnelle ; cela revient aux mêmes choses. La question n’est pas de savoir comment construire une pratique de DevOps de base de données parfaite sur un nouveau système. La question est de savoir comment introduire une gouvernance significative sur un patrimoine hérité complexe sans arrêter l’entreprise pendant que vous le faites.

La gouvernance incrémentale, intégrée dans la pipeline, est la seule réponse pratique à cette question. Vous n’avez pas besoin de replateformer l’ensemble du patrimoine avant d’améliorer vos pratiques de gestion des modifications. Des outils modernes comme Redgate Flyway existent pour alléger la base de données en tant que goulet d’étranglement et commencer par les modifications apportées aujourd’hui, dans les pipelines qui existent déjà, et construire à partir de là.

Les organisations qui gagneront sur la croissance au cours des cinq prochaines années ne seront pas celles qui ont les patrimoines les plus propres. Ce seront celles qui ont découvert comment rendre la modification fiable, au rythme que l’entreprise exige, sur le patrimoine qu’elles possèdent réellement.

C’est le problème qui vaut la peine d’être résolu. Et il est solvable.