SQL est un excellent langage, une référence incontournable pour tout profil tech dont le métier est la donnée : data analyst, data engineer, data scientist. Mais pour un profil métier au sens large (contrôle de gestion, business analyst, RH, marketing...), SQL est rarement le bon point de départ, pour une raison très concrète : il suppose d'avoir accès à une base de données, ce qui est rarement le cas au quotidien. Python, lui, répond au besoin quel que soit l'endroit où vivent les données : fichiers Excel, exports CSV, bases de données, API.
Voici pourquoi cette différence est fondamentale, et dans quel cas SQL garde malgré tout un vrai intérêt.
Ce que SQL fait très bien
SQL (Structured Query Language) est le langage standard pour interroger une base de données relationnelle : filtrer, croiser, regrouper des tables avec une syntaxe déclarative, relativement simple à lire (SELECT, WHERE, JOIN, GROUP BY). Ce n'est pas un hasard si c'est la référence absolue pour quiconque travaille directement sur les données d'une entreprise : le moteur de la base est optimisé pour exécuter ces requêtes efficacement, bien plus qu'en récupérant toutes les données brutes pour les traiter ailleurs.
Pourquoi SQL est rarement adapté à un usage métier
Trois raisons expliquent pourquoi ce langage, aussi bon soit-il, ne correspond que rarement aux besoins d'un profil métier :
- SQL suppose d'avoir accès à une base de données. C'est rarement le cas côté métier : les données du quotidien vivent le plus souvent dans des exports Excel, des fichiers partagés, des outils SaaS, pas dans une base de données interne à laquelle on peut se connecter.
- Les besoins métier croisent le plus souvent des fichiers de sources hétérogènes. Un export client, un fichier fournisseur, une extraction d'un autre outil : autant de sources qui ne vivent pas dans la même base, quand elles vivent dans une base tout court.
- SQL, aussi excellent soit-il pour transformer des données, se limite à ça. Impossible d'aller plus loin : automatiser une tâche récurrente, appeler une API, générer un fichier, envoyer un mail. SQL s'arrête à la requête.
Un exemple concret
Si les données vivent déjà dans une base, une requête SQL pour regrouper des montants par centre de coûts est simple et efficace :
SELECT centre_de_cout, SUM(montant) AS montant_total
FROM commandes
GROUP BY centre_de_cout;Le problème n'est pas cette requête : elle est parfaite pour ce qu'elle fait. Le problème, c'est la précondition qu'elle suppose, à savoir que la table commandes existe déjà dans une base à laquelle on a accès. Si les données viennent plutôt de plusieurs exports Excel envoyés par différents interlocuteurs, ce qui est le scénario le plus courant côté métier, SQL ne peut tout simplement rien faire tant que ces données n'ont pas été rassemblées ailleurs. Python couvre les deux étapes dans un seul script :
import pandas as pd
from pathlib import Path
dossier_source = Path("exports_mensuels")
donnees = pd.concat([pd.read_excel(f) for f in dossier_source.glob("*.xlsx")], ignore_index=True)
rapport = donnees.groupby("centre_de_cout", as_index=False).agg({"montant": "sum"})Et si on a accès à une base de données ?
Si votre poste vous donne un accès direct à une base de données, un cas plus fréquent côté data que côté métier, SQL garde un vrai intérêt pour l'étape d'extraction : la base est optimisée pour exécuter ces requêtes efficacement, bien plus qu'en récupérant toutes les données brutes pour les filtrer ensuite dans un script. Mais cette étape reste rarement la seule : une fois les données extraites, il faut le plus souvent les croiser avec d'autres sources, les nettoyer, produire un livrable, ce que SQL seul ne permet pas.
Et Python sait de toute façon envoyer lui-même des requêtes SQL à une base de données, par exemple avec pandas.read_sql(), ce qui permet de couvrir l'extraction et tout ce qui suit dans un seul et même script, sans changer d'outil en cours de route :
import pandas as pd
from sqlalchemy import create_engine
moteur = create_engine("chaine_de_connexion")
commandes = pd.read_sql("SELECT * FROM commandes", moteur)Le comparatif, critère par critère
| Critère | SQL | Python |
|---|---|---|
| Prérequis | Nécessite l'accès à une base de données | Fonctionne avec n'importe quelle source : fichiers, API, bases de données |
| Ce qu'il fait | Interroger et transformer des données déjà structurées en base | Lire, croiser, transformer et produire un résultat, quelle que soit la source |
| Croisement de sources hétérogènes | Limité aux tables d'une même base | Naturel : fichiers, bases de données, API, dans un seul script |
| Au-delà de la transformation | Non : SQL s'arrête à la requête | Oui : automatisation, envoi de rapports, appels API |
| Performance sur une base déjà en place | Optimale, la base fait le travail | Bonne, avec la possibilité d'interroger directement la base via SQL |
| Adapté à un profil métier | Rarement, sauf accès direct à une base d'entreprise | Oui, quel que soit l'endroit où vivent les données |
Faut-il quand même apprendre un peu de SQL ?
Si votre poste vous donne un accès direct et régulier à une base de données d'entreprise, apprendre les bases de SQL (SELECT, WHERE, JOIN, GROUP BY) reste un complément utile et rapide à acquérir. Mais ça ne devrait pas être le premier langage appris pour un profil métier, ni le seul : il ne couvre qu'une partie, souvent minoritaire, des besoins réels du quotidien.
En résumé
- SQL est un excellent langage, une référence pour tout profil dont le métier est la donnée, mais il suppose d'avoir accès à une base, rarement le cas côté métier.
- Les besoins métier croisent le plus souvent des fichiers de sources hétérogènes, pas seulement des données internes en base.
- SQL, aussi bon soit-il pour transformer des données, s'arrête là : impossible d'automatiser une tâche au-delà.
- Python répond au besoin quel que soit l'endroit où vivent les données, et sait lui-même interroger une base via SQL si besoin.
Ce constat rejoint celui de nos comparatifs Python vs VBA et Python vs Power Query : chaque outil a sa place, mais Python reste souvent la seule option capable de couvrir l'ensemble du besoin, quelle que soit la source. Retrouvez aussi l'ensemble de nos articles sur Python pour les métiers.