SQL est mort. Vive SQL !
Je travaille dans l’IT d’entreprise depuis 30 ans. Suffisamment longtemps pour voir défiler de nombreux effets de mode et un cimetière rempli de promesses ratées faites par des commerciaux et des consultants qui promettaient un impact technologique réel et révolutionnaire pour les entreprises.
Voici quelques exemples de choses qui nous ont été vendues comme une sorte de Graal, mais qui se sont révélées éphémères ou ont fini dans des niches après leur minute de gloire.
Mais il existe aussi les cas inverses. Des technologies déclarées mortes il y a des décennies ont traversé l’ère de l’AI et se portent toujours très bien aujourd’hui.
La plupart des prévisions de long terme sur l’adoption technologique ne se réalisent tout simplement pas.
De nombreux facteurs y contribuent, mais l’un d’eux ressort particulièrement. Nous avons une tendance notoire à sous-estimer l’inertie dans l’adoption des technologies, en particulier dans l’IT d’entreprise.
Cela tient peut-être en partie à la nature humaine, mais c’est surtout lié à l’expérience des professionnels évoluant dans des environnements IT d’entreprise. Oui, l’IT doit apporter une innovation à fort impact au business pour améliorer la compétitivité et soutenir la croissance. Mais la fonction centrale du leadership IT consiste à gérer le risque et à optimiser les coûts dans un juste équilibre pour maintenir l’activité. Cela concerne à la fois les personnes et la technologie et va bien au-delà de la disponibilité des systèmes et de la cybersécurité.
Comment les décisions sont prises dans l’IT d’entreprise
Pour donner un exemple simple : en tant que CTO, lorsque je sélectionne un langage de programmation pour un nouveau projet, je dois regarder bien au-delà des capacités du langage lui-même. D’autres facteurs sont encore plus critiques dans ma prise de décision. Je dois regarder à l’intérieur de mon entreprise et sur le marché au sens large pour comprendre le niveau de popularité du langage. Sera-t-il facile de recruter des développeurs pour ce langage ?
Par exemple, si je devais choisir entre JavaScript et Ruby pour un nouveau projet en 2025, je vérifierais rapidement que plus de 66 % des développeurs connaissent JavaScript, contre seulement 6,4 % pour Ruby (une alternative possible côté serveur), selon l’enquête StackOverflow. Dans un tel cas, même si Ruby était une meilleure option, je choisirais probablement JavaScript. Il n’y a pas que le recrutement, potentiellement plus simple ; avec une communauté plus large, on peut aussi compter sur un écosystème plus complet : outils, support, disponibilité d’entreprises de services professionnelles, etc. De la même façon, lorsqu’elles choisissent un outil de recrutement marketing, les entreprises privilégient souvent les plateformes bénéficiant d’une base d’utilisateurs solide et d’un fort soutien de l’écosystème,
ce qui garantit une meilleure stabilité sur le long terme et une intégration plus simple.
Ensuite, je dois examiner les tendances de long terme. Depuis combien de temps le langage existe-t-il ? Son adoption progresse-t-elle encore, stagne-t-elle ou décline-t-elle déjà ? Le langage va-t-il continuer à évoluer pour absorber de nouvelles tendances et innovations ? Y aura-t-il encore du support dans 5 ou 10 ans ?
Et c’est précisément là que commence réellement notre histoire sur SQL et son histoire.
Qu’est-ce que SQL ?
SQL est un langage de programmation largement utilisé, standardisé et principalement déclaratif, doté d’éléments procéduraux, dont le but est de définir des structures de données, de manipuler, interroger et contrôler les données. Il repose sur l’algèbre relationnelle et a considérablement amélioré les techniques précédentes de requête et de manipulation de données comme VSAM. Une instruction se compose de clauses, d’expressions, de prédicats, de requêtes et de sous-requêtes récursives.
Il y a toujours eu des extensions et des dialectes spécifiques aux fournisseurs, mais le cœur du langage est conforme au standard dans toutes les grandes implémentations. Les incompatibilités concernent les types de données et les constructions plus avancées.
SQL n’est pas parfait. Il ne suit pas toujours de façon cohérente ses élégantes bases mathématiques, n’est pas optimal pour les données hiérarchiques ou orientées graphe et n’a jamais très bien épousé le paradigme orienté objet. De manière générale, il ne s’intègre pas parfaitement aux langages orientés objet ni procéduraux (c’est là qu’intervient l’Object-Relational Mapping, ou ORM). Les requêtes plus complexes peuvent devenir pénibles à écrire et à lire, et il n’est pas efficace d’écrire de grosses logiques complexes entièrement en SQL ou en PL/SQL.
C’est pourquoi, au fil du temps, de nombreuses alternatives ont été proposées et plusieurs ont rencontré un réel succès, par exemple les langages de requête pour graphes et le noSQL pour les magasins clé-valeur et les données orientées document.
Cependant, la plupart des alternatives qui ont réussi ont fini par plafonner dans leur niche et, en réalité, nous observons même ces dernières années un recul de certaines d’entre elles au profit de SQL. D’un autre côté, certains de ces concepts comme JSON ou les graphes ont déjà été intégrés à des versions plus récentes de SQL, réduisant ainsi le besoin d’alternatives.
SQL est ancien, mais c’est clairement le gagnant de ce marathon.
Les origines de SQL
Les origines de SQL remontent au début des années 1970. En 1970, Edgar F. Codd a publié A Relational Model of Data for Large Shared Data Banks, introduisant le modèle relationnel des bases de données.
Ce fut la naissance du SGBDR, une toute nouvelle catégorie de systèmes IT à l’époque, qui, 55 ans plus tard, figure toujours parmi les 3 principales catégories mondiales (aux côtés de l’infrastructure IT et des systèmes ERP). L’adoption des SGBDR a été portée par la montée en puissance de l’ERP et l’adoption de SQL a avancé main dans la main avec elle. Comme des jumeaux, l’un ne peut pas exister sans l’autre.
Deux grands prototypes de systèmes de bases de données relationnelles ont été créés entre 1974 et 1977. Il s’agissait d’Ingres, développé à UC Berkeley (UCB), et de System R, créé chez IBM San Jose. Ingres utilisait un langage de requête appelé QUEL, et il a conduit à la création de systèmes tels qu’Ingres Corp., MS SQL Server, Sybase, PostgreSQL, Wang’s PACE et Britton-Lee. De son côté, System R utilisait le langage de requête SEQUEL, et il a contribué au développement de SQL/DS, DB2, Allbase, Oracle et Non-Stop SQL.
C’est aussi au cours de cette décennie que le terme Relational Database Management System, ou RDBMS, s’est imposé.
Standardisation et adoption de SQL
Après près de 10 ans de R&D autour de SQL, les années 1980 ont été la décennie de la commercialisation et de la standardisation des SGBDR. Plusieurs systèmes de bases de données commerciaux ont été lancés dans les années 1980. Cela inclut Oracle V2 (1979), Sybase SQL Server (1984), IBM DB2 pour mainframes (1983, successeur de System R), IBM Informix (1985), Microsoft SQL Server 1.0 (1987) et SAP DB (1988).
Une étape importante a été l’adoption de SQL comme langage standard des bases de données par l’ANSI et l’ISO en 1986 et 1987 respectivement. Ce standard a connu de nombreuses itérations au fil du temps, la plus récente datant de 2023.
Parmi les raisons ayant poussé les fournisseurs à soutenir la standardisation figuraient l’espoir d’une croissance globale plus rapide grâce à un standard dans ce marché en évolution, la crainte de perdre face aux concurrents en ne le supportant pas, la capacité d’influencer le standard et les bénéfices liés à l’écosystème.
Le succès initial de SQL n’est pas sorti de nulle part. Il existait clairement une demande.
Cependant, la croissance massive n’a vraiment commencé qu’au début des années 1990. Elle a été provoquée par la baisse des prix du matériel, l’essor des architectures client-serveur avec UNIX et PC et l’adoption de l’ERP. C’est aussi la décennie de l’émergence des bases relationnelles open source avec MySQL (1995), PostgreSQL (1996) et MariaDB (1999).
La généalogie des bases de données relationnelles est assez complexe – les détails peuvent être consultés ici.
Paysage actuel et perspectives
En résumé, SQL est là pour durer. Et pas seulement cela. Il est plus vivant que jamais et continue de croître. Ce dinosaure a survécu à tous ses concurrents modernes et les a dépassés en popularité.
C’est un exemple parfait du fait que, sur la durée, les concepts de cycle d’adoption des technologies et de Gartner Hype Cycle ne s’appliquent pas toujours. SQL est entré dans sa “phase tardive” selon tous les critères, mais il croît plus vite que jamais. Exemple : le Gartner Hype Cycle de 2018, où SQL n’apparaissait même plus comme catégorie (et ce n’est toujours pas le cas en 2025).
Au cours des cinq dernières années, les bases de données SQL n’ont pas seulement résisté : elles ont prospéré. Dans la Stack Overflow Developer Survey 2020, MySQL et PostgreSQL figuraient déjà parmi les bases de données les plus utilisées au monde. En 2025, leur avance s’est encore creusée. MySQL, PostgreSQL, Microsoft SQL Server et SQLite composent désormais le top 4 des bases de données utilisées par les développeurs professionnels, très loin devant toute alternative noSQL. Malgré des années de prédictions annonçant que “SQL est mort”, les données montrent l’inverse : SQL reste l’épine dorsale des logiciels modernes et des systèmes pilotés par la donnée.
Pourquoi SQL est-il à nouveau bien vivant ?
Voici mes quatre hypothèses sur les raisons du grand retour de SQL. N’hésitez pas à me contredire : je serais très curieux d’avoir votre avis.
Fondation
SQL a été l’un des premiers langages déclaratifs (par opposition aux langages procéduraux dominants à l’époque). Un langage déclaratif permet de décrire ce que l’on veut plutôt que comment le faire. C’est très attractif pour les utilisateurs peu familiers avec d’autres langages de programmation. Il est très facile à apprendre et à appliquer (du moins pour les cas d’usage de base) et offre en même temps un degré énorme de flexibilité, ce qui le rend adapté à un très large éventail de modèles d’accès aux données, des requêtes ad hoc à l’accès transactionnel et à la manipulation des données.
Maturité
Évidemment, une technologie développée et mûrie sur une période aussi longue peut être considérée comme très stable et complète. Aucun décideur ne prend un risque technologique en choisissant SQL.
Adoption
Nous avons déjà abordé ce point dans l’introduction. Les niveaux d’adoption de SQL ont progressé sur une longue période, parfois plus lentement, parfois plus rapidement, mais aujourd’hui SQL est de loin l’acteur dominant comme langage d’accès aux données. Cette position suffit à elle seule à sécuriser sa croissance future.
Si l’on fait un bref détour par la théorie économique de l’avantage concurrentiel, on sait que, dans les marchés fondés sur une plateforme biface, les leaders disposent d’un avantage concurrentiel massif. Les bases de données relationnelles basées sur SQL constituent une telle plateforme biface au sens large :
- La communauté (ou plutôt plusieurs communautés dans le cas de SQL, puisqu’elles s’organisent autour de systèmes de bases de données particuliers) – elle comprend les utilisateurs SQL, les développeurs et d’autres professionnels
- L’industrie – elle comprend les éditeurs de systèmes, les organisations de services professionnels, les fournisseurs cloud et d’autres acteurs.
C’est là que de puissants effets de réseau entrent en jeu. Une communauté plus vaste stimule la croissance de l’écosystème et des capacités des systèmes, car l’industrie veut capitaliser sur la taille du marché. En même temps, la communauté grandit d’elle-même, parce que le choix d’une technologie par les utilisateurs ou les organisations qui les emploient dépend aussi de la taille de la communauté, afin de gérer le risque et de garantir l’accès aux talents.
Cet effet est très puissant, au point de conduire des plateformes à “aspirer” des cas d’usage pour lesquels elles n’avaient pas été conçues, comme les extensions de bases de données graphe et vecteur pour les bases relationnelles.
Évolution
Comme dans l’évolution biologique, nous ne pouvons pas prédire les événements extérieurs dans l’évolution technologique. Nous ne pouvons nous y adapter qu’une fois qu’ils se produisent. Ce n’est ni l’espèce la plus forte, ni la plus rapide, ni la plus grande qui a les meilleures chances de survie sur le long terme. C’est celle qui s’adapte le mieux au changement. Le SQL de 2025 n’est plus le SQL de 1970.
SQL a intégré des changements majeurs au fil du temps, notamment le big data et les systèmes distribués (sharding et partitionnement, bases de données SQL distribuées, stockage colonnaire et analytique), une intégration fluide avec les langages modernes de programmation et d’AI, la prise en charge des données semi-structurées et non structurées (json, types tableau, xml), l’adaptation à l’analytics temps réel, le support de l’analytics avancée et du ML (par exemple BigQuery ML, extensions PostgreSQL), l’intégration aux pipelines d’AI, le traitement en mémoire, l’exécution vectorisée des requêtes et le ML accéléré par GPU.
Quelle est la prochaine étape pour SQL ?
SQL a prouvé qu’il pouvait évoluer plus vite que les prédictions annonçant son déclin. Alors que l’AI, la recherche vectorielle et l’analytics temps réel redéfinissent notre manière de construire des applications, SQL continue de s’adapter au lieu de disparaître. La prochaine vague ne remplacera pas SQL. Elle l’élargira. SQL est la base de données de choix pour l’AI. Nous verrons une intégration plus profonde avec le traitement des données piloté par l’AI, des extensions natives pour les vecteurs et une mise à l’échelle cloud-native qui rendra les bases de données plus dynamiques que jamais.
Pour celles et ceux d’entre nous qui ont vu passer des décennies de hype, l’avenir de SQL semble à la fois familier et nouveau. C’est toujours le langage de la donnée, mais désormais il parle aussi le langage de l’intelligence. Je serais très intéressé par vos retours sur mes hypothèses et sur l’avenir de SQL.
Personnellement, je pense que SQL reste l’avenir, et c’est pour cela que nous construisons Vela. Vela est une plateforme moderne de Backend-as-a-Service construite sur Postgres. Cela nous permet de montrer comment Postgres maintient SQL pertinent pour les workloads cloud et AI d’aujourd’hui.