Sphera
Développeur de données
Réduction de 30 % du temps de build de production en réécrivant le SQL qu'un ORM générait silencieusement
Spécifications de mappage C# et Entity Framework, réécrites pour que le SQL généré ressemble à ce qu'un DBA recommanderait vraiment. Intégrité des données vérifiée avant et après pour que le gain ne change pas silencieusement le comportement.
Le problème
Les builds de production étaient assez lents pour nuire à la productivité de toute l'équipe de développement. La couche d'accès aux données existante faisait plus d'allers-retours que les requêtes ne l'exigeaient, et la forme de requête par défaut générée par Entity Framework n'était pas celle qu'un DBA aurait écrite à la main.
Pourquoi c'était difficile
L'ORM avait accumulé des années de conventions. Changer un mappage cascadait dans des endroits que personne ne se souvenait avoir écrits. Chaque réécriture devait être remontée jusqu'aux appelants pour prouver que rien d'autre n'avait bougé.
« Plus rapide » et « toujours correct » ne sont pas le même test. Une requête qui retourne le même nombre de lignes avec un tri légèrement différent peut casser silencieusement un rapport en aval. L'équivalence comportementale, pas la vitesse, était la vraie barre.
L'équipe était en cadence de livraison. Le travail d'optimisation devait atterrir en petits morceaux sans mettre en pause le développement des fonctionnalités. Ça voulait dire aucune réécriture d'un seul coup, seulement des changements chirurgicaux mappage par mappage avec un plan de retour arrière à chaque fois.
L'approche
Développement de spécifications de mappage en C# avec Entity Framework pour optimiser le motif d'accès aux données.
Lecture du SQL réellement généré par Entity Framework en coulisses, réécriture des mappages pour que la sortie ressemble à ce qu'un DBA approuverait, et utilisation de requêtes SQL efficaces pour maintenir et vérifier les données.
Vérification de l'intégrité des données avant et après chaque changement pour que l'optimisation ne change pas silencieusement le comportement.
Le résultat
Temps de build de production réduit de 30 %.
Efficacité globale du développement logiciel améliorée.
Équivalence comportementale maintenue sur la surface d'accès aux données modifiée.
Vous avez ce problème si
- Votre suite de build ou de tests s'est lentement ralentie sur des années et personne ne sait ce qui a régressé quand
- La couche d'accès aux données est en pilote automatique : le framework génère les requêtes et personne ne les lit
- Une optimisation de performance a déjà cassé un rapport parce que l'équivalence a été supposée plutôt que vérifiée
- Vous avez besoin de gains de vitesse dans un codebase qui livre, sans « sprint de refactoring » planifié que le métier n'approuvera jamais
Ce que j'en retiens
Les ORM génèrent silencieusement la requête qu'ils vont générer, que la forme soit bonne ou pas. Le 30 % venait de la lecture du SQL réel, pas du C# qui l'avait produit. La même leçon s'applique au code généré par un LLM aujourd'hui : lisez la sortie, pas juste l'invite.
Comment ça se voit dans mon travail aujourd'hui
Lisez le diff, pas l'invite. Cette seule phrase généralise la leçon Sphera à chaque projet intégrant un LLM que je prends. L'IA a écrit du code qui passe le type-check ; le SQL qu'Entity Framework émettait compilait aussi. Dans les deux cas, la bonne étape suivante était d'ouvrir la sortie réelle et de la lire. Le chemin de démo en 48 h est bâti autour exactement de cette discipline de lecture : je vous remets ce que le modèle a produit, et je l'ai déjà lu.