Ce que les CTE révèle sur notre secteur

Les Common Table Expressions (CTE) ne sont pas qu'une simple syntaxe SQL. Après plusieurs années d'utilisation intensive dans nos projets, j'ai observé que leur adoption massive révèle des vérités inconfortables sur l'état actuel du développement backend français. Les CTE sont devenues un marqueur involontaire de nos pratiques, de nos lacunes et de nos directions futures.

Cet article n'est pas un tutoriel sur WITH...AS. C'est une analyse de ce que l'explosion des CTE dans notre secteur nous dit réellement : comment on code, comment on pense, et pourquoi on a échoué à faire les choses simplement la première fois.

Les CTE comme cache de problèmes architecturaux

Depuis 2020, j'ai vu le nombre de requêtes utilisant les CTE exploser chez nos clients. Ce qui m'a frappé : la plupart n'en avaient pas besoin techniquement. Elles auraient pu utiliser des sous-requêtes, des vues matérialisées, ou simplement restructurer leur modèle de données. Mais non. Les CTE ont fourni une échappatoire facile.

Les CTE permettent d'écrire du code complexe sans résoudre la complexité sous-jacente. Vous pouvez chaîner 7-8 CTE, créer une requête de 150 lignes, et elle fonctionnera. Personne n'osera refactoriser parce que « ça marche ». C'est une forme de dette technique silencieuse.

Cette requête révèle le problème : on ne sait pas modéliser la relation. On construit un « tuyau » de transformations successives. Un bon design aurait des vues ou une table dénormalisée pour ce pattern.

L'illusion de la lisibilité comme excuse

« Les CTE, c'est plus lisible. » C'est l'argument qu'on entend partout. Et oui, étape par étape c'est plus clair. Mais cela cache une vérité : si vous avez besoin de 8 étapes pour une requête, votre logique métier est mal comprise.

Les CTE ne sont pas mauvaises pour la lisibilité. Elles sont mauvaises pour déguiser une compréhension insuffisante du domaine. J'ai revu du code CTE qui aurait dû être une simple jointure avec un GROUP BY. Mais comme personne n'avait documenté pourquoi la relation existait, on a créé 4 CTE « pour la clarté ».

Le vrai problème : les CTE sont venues trop tard dans nos carrières. PostgreSQL les a eu tardivement (9.1 en 2011). Nous avons passé 15 ans à écrire du SQL sans elles. Maintenant on les utilise excessivement en surcompensation.

Ce que les CTE révèlent sur nos équipes

L'adoption des CTE montre une bifurcation claire dans nos équipes : les seniors qui les utilisent avec parcimonie (1-2 par requête) et les juniors qui en font une solution universelle. C'est un signal qu'on n'a pas standardisé nos pratiques SQL.

J'ai examiné 200+ requêtes CTE chez différents clients. Résultat : 70% auraient pu être simplifiées sans perte de performance. 15% etaient justifiées (récursion, fenêtrage complexe). 15% etaient simplement mauvaises. Ces chiffres reflètent l'absence de code reviews SQL rigoureuses dans nos boîtes.

Les CTE sont aussi devenus un marqueur de séniorité inexacte. Un dev écrivant du CTE « compliqué » est perçu comme expérimenté. Non. Un dev écrivant une requête simple qui résout le problème l'est vraiment.

Les CTE et la mort du SQL analytique simple

Voici ce qui me préoccupe vraiment : les CTE ont tué le SQL analytique simple. Avant, on forçait les gens à penser en termes de SET operations. Jointures, agrégations, fenêtres. Maintenant, avec les CTE, on peut écrire du code pseudo-impératif.

Les data analysts qui arrivent, formés aux CTE, ne comprennent pas l'optimisation SQL. Ils ne savent pas que l'ordre des jointures change tout. Ils construisent 6 CTE, chacune produisant 100k lignes, et demandent pourquoi c'est lent. Les CTE ont abaissé la barre d'entrée en feignant de la simplifier.

La première version traite 2M lignes. La deuxième traite directement 100k. Les CTE masquent cette distinction jusqu'à ce que votre base soit en prod et morte.

Conclusion : Les CTE ne sont pas le problème

Les CTE révèlent simplement que nous avons oublié les fondamentaux. Le secteur les utilise en excès parce que nous avons échoué à former à l'algèbre relationnelle, à l'optimisation query, et à la modélisation. Les CTE sont un symptôme, pas la maladie.

Ma recommandation : utilisez les CTE pour la récursion, pour les fenêtres complexes, ou pour décomposer une logique vraiment difficile. Pour tout le reste, ramenez-vous. Documentez pourquoi vous en avez une. Et surtout, stoppez de les utiliser comme excuse pour ne pas refactoriser votre schéma.