Développeur base de données vs DBA : deux mondes, un même combat

Le développeur veut livrer. Le DBA veut protéger. C'est la tension la plus ancienne du monde de la donnée, et elle existe pour une bonne raison : les deux ont raison. Le problème, c'est qu'ils ont aussi tort — chacun de leur côté — et que personne n'a trouvé le moyen de leur faire entendre ça.

Le développeur : "Je dois livrer vendredi"

Le développeur voit la base de données comme un outil. Il a une fonctionnalité à livrer, un sprint qui se termine, un Product Owner qui tape du pied. Pour lui, un index est un moyen d'accélérer sa requête. Du SQL dynamique, c'est un moyen de gagner en flexibilité. Un SELECT *, c'est pratique — il n'a pas à lister 40 colonnes. Il ne pense pas mal. Il pense vite. Et la vitesse, dans notre métier, c'est une vertu réelle.

Mais le développeur ne voit pas ce qui se passe après. L'index qu'il a créé en staging pour accélérer sa requête va coûter 15% de CPU supplémentaire sur les INSERT en production. Le SQL dynamique qu'il a écrit avec une concaténation de chaînes est une porte d'entrée pour l'injection SQL. Le SELECT * ramène 80 colonnes dont 60 sont inutiles, et casse le moment où quelqu'un ajoute une colonne BLOB.

Le développeur n'est pas incompétent. Il est incomplet. Il optimise pour la livraison, pas pour l'exploitation. Et c'est normal : on ne lui a jamais demandé de penser à l'exploitation.

Le DBA : "Tu ne touches pas à ma base"

Le DBA, lui, a vu des choses. Des tables sans clé primaire. Des index sur des colonnes BIT. Des procédures stockées de 3000 lignes avec un curseur dedans. Des DELETE sans WHERE. Il a passé des nuits à réparer ce que les développeurs ont cassé en cinq minutes un vendredi après-midi. Alors oui, il est prudent. Trop prudent, parfois.

Le DBA voit chaque changement de schéma comme un risque. Chaque nouvel index comme un coût. Chaque requête dynamique comme une menace. Il demande des revues de code SQL, des tests de charge, des plans de rollback. Et le développeur l'entend comme : "Je ne veux pas que tu livres."

Le DBA n'est pas un bureaucrate. Il est traumatisé. Et la prudence, dans son métier, c'est aussi une vertu réelle. Mais quand la prudence devient de la paralysie, tout le monde perd.

Anecdotes du terrain (anonymisées)

Un développeur ajoute un index sur une table de 200 millions de lignes en production, sans prévisualisation, un jeudi à 16h. L'index met 40 minutes à se créer. Pendant ce temps, la table est verrouillée. L'application est down. Le DBA découvre le incident à 17h en recevant une alerte. Il passe la soirée à comprendre ce qui s'est passé. Le développeur, lui, est déjà parti en week-end.

Un DBA refuse pendant trois mois la création d'un index filtré qui aurait résolu un problème de performance critique. Sa raison : "Je ne veux pas d'index filtré, c'est trop complexe à maintenir." L'équipe de développement contourne le problème avec un cache applicatif qui finit par servir des données périmées. Un client reçoit une facture erronée. Le coût de l'incident : 50 fois le coût de l'index.

Ces deux histoires sont vraies. Et elles montrent la même chose : le problème n'est pas le développeur, ni le DBA. Le problème, c'est le mur entre eux.

La solution : la responsabilité partagée

Le modèle traditionnel — le dev écrit, le DBA valide — ne marche plus. Il est trop lent, trop conflictuel, et il crée une asymétrie : le dev prend les décisions, le DBA porte les conséquences. C'est exactement le genre de structure qui produit des incidents.

La solution, c'est la responsabilité partagée. Concrètement :

• Le DBA intègre le sprint. Pas en validation finale, mais en amont. Il participe au design des requêtes, à la définition des index, à la revue des migrations de schéma. Il est un conseiller, pas un gardien.
• Les changements de schéma sont du code. Flyway, Liquibase, DbUp — peu importe l'outil. L'important, c'est que chaque migration soit versionnée, revue en PR, et exécutée par le pipeline CI/CD. Le DBA ne valide plus à la main. Il review le code de migration comme il reviewerait n'importe quel code.
• Le monitoring est partagé. Le dev voit les métriques de performance en production. Le DBA voit les métriques de déploiement. Quand une régression apparaît, les deux la voient en même temps. Plus de chasse au coupable.
• Le dev porte la production. Pas symboliquement. Réellement. Si sa requête ralentit la prod, c'est son problème, pas celui du DBA. Ça change radicalement la façon dont on écrit du SQL.

-- Exemple de migration Flyway versionnée
-- V1.2.3__add_filtered_index_commandes_en_cours.sql
CREATE NONCLUSTERED INDEX IX_Commandes_EnCours
ON Commandes (ClientId, DateCommande)
INCLUDE (Montant, AdresseLivraison)
WHERE Statut = 'En cours';

Ce fichier est commité dans le repo, revu en PR, testé en CI sur une copie de la base de production, et déployé par le pipeline. Le DBA review la PR. Le dev exécute le déploiement. Personne ne travaille en silo. Personne ne porte le risque seul.

Le SQL dynamique : le terrain d'entente

Le SQL dynamique est le point de friction classique. Le dev l'aime pour sa flexibilité. Le DBA le déteste pour le risque d'injection. La vérité : les deux ont raison. Le SQL dynamique est dangereux mal écrit et indispensable bien écrit.

-- Mauvais : concaténation, injection possible
SET @sql = 'SELECT * FROM Clients WHERE Ville = ''' + @Ville + '''';
EXEC(@sql);

-- Bon : sp_executesql avec paramètres
SET @sql = N'SELECT * FROM Clients WHERE Ville = @Ville';
EXEC sp_executesql @sql, N'@Ville NVARCHAR(100)', @Ville = @Ville;

Le dev obtient sa flexibilité. Le DBA obtient sa sécurité. Et si le dev apprend à écrire du SQL dynamique paramétré, le DBA arrête de le redouter. C'est ça, la responsabilité partagée : pas que chacun cède, mais que chacun apprenne.