Pandas, Excel et l'IA : pourquoi le code de données est un casse-tête pour ton cerveau

Imaginons que tu dois calculer le chiffre d'affaires total par région, mais seulement pour les ventes positives. Avec pandas, ça donne un truc comme ça :

summary = (
    sales.loc[sales["revenue"] > 0]
    .assign(margin=lambda df: df["revenue"] - df["cost"])
    .groupby("region", as_index=False)
    .agg(
        total_revenue=("revenue", "sum"),
        average_margin=("margin", "mean"),
    )
    .sortvalues("totalrevenue", ascending=False)
)

Ce code n'est pas mauvais. Un analyste expérimenté le comprend sans problème. Pourtant, chaque parenthèse, chaque virgule, chaque lambda (une fonction anonyme en Python) est une distraction. Ton cerveau doit constamment négocier avec l'API plutôt que de se concentrer sur la logique métier.

group by region, then sum revenue

C'est une version simplifiée de la même opération, écrite dans un langage plus direct. Pas de crochets, pas de points, juste l'idée : grouper par région, puis sommer le chiffre d'affaires. Pourtant, avec pandas, il faut passer par un enchaînement de méthodes qui s'éloignent de cette simplicité.

sales.loc[sales["revenue"] > 0, "margin"] = (
    sales["revenue"] - sales["cost"]
)

Ici, on filtre les ventes positives et on calcule une marge. Mais pour faire ça, il faut répéter le nom de la dataframe sales trois fois. C'est comme si tu devais écrire « voiture » à chaque fois que tu veux parler de ta voiture. Fatigant, non ?

with sales as summary
    filter revenue > 0
    margin = revenue - cost
    group by region
        agg sum revenue as totalrevenue, mean margin as averagemargin
    sort total_revenue desc

Cette version ressemble à une recette de cuisine. Chaque ligne correspond à une étape logique : filtrer, calculer, grouper, agréger, trier. Pas de répétitions, pas de syntaxe tordue. Juste la séquence des opérations que tu as en tête.

df.groupby("year").reset_index()

Cette ligne est un parfait exemple du problème. Après un groupby (qui regroupe les données), pandas ajoute par défaut un index. Pour retrouver tes données sous forme de colonnes, il faut écrire reset_index(). Ce n'est pas une simple touche de clavier : c'est une distraction qui casse le fil de ta réflexion.

LA PERFORMANCE N'EST PAS LE VRAI PROBLÈME

Pendant des années, tout le monde a parlé de la lenteur de pandas. Pourtant, pour la plupart des tâches quotidiennes, la performance n'est pas le vrai souci. Si ton jeu de données tient en mémoire et que le calcul s'exécute en une seconde, le problème n'est pas là.

Le vrai problème, c'est ce qu'on appelle la charge cognitive. Chaque fois que tu dois te rappeler une syntaxe, réarranger des parenthèses ou vérifier si un paramètre a changé ton index, tu perds un peu de ton énergie mentale. Et cette énergie, tu devrais la consacrer à analyser les données, pas à te battre avec l'outil.

Prenons un exemple simple : garder les ventes positives, calculer une marge, regrouper par région et trier le résultat. Avec pandas, ça donne un enchaînement de méthodes qui, même si elles sont correctes, demandent une gymnastique mentale. Chaque détail consomme une petite partie de ta mémoire de travail, celle qui te sert à réfléchir.

Les index de pandas illustrent bien ce problème. Après un groupby, il faut souvent écrire reset_index() pour retrouver tes données sous forme de colonnes. Ce n'est pas juste quelques touches de plus : c'est une interruption qui casse le flux de ta pensée.

Et puis, il y a la compatibilité ascendante. pandas est une bibliothèque mature, utilisée par des millions de personnes. Changer radicalement sa syntaxe serait un casse-tête pour toute la communauté. Résultat : on reste coincé avec des choix de design qui datent des années 2010.

L'IA PEUT ÉCRIRE LE CODE À TA PLACE, MAIS PAS PENSER À TA PLACE

Les grands modèles de langage peuvent générer du code pandas en quelques secondes. Oui, c'est pratique. Mais générer du code n'est qu'une partie du travail d'analyse de données.

L'analyse de données, c'est un processus exploratoire. Tu commences par une question, tu filtres les données, tu découvres quelque chose d'inattendu, tu ajoutes une étape, tu réalises que tu as oublié des valeurs manquantes, tu fais un graphique. et puis tu te rends compte que ta question initiale était mal posée.

Ce cycle, c'est de la créativité, de l'interaction, de l'exploration. Dans ce contexte, la vitesse à laquelle tu peux transformer les données manuellement compte. Beaucoup d'analystes continuent de taper du code pandas dans leurs notebooks, même s'ils font confiance à l'IA pour écrire des fonctions plus complexes.

Et puis, il y a la documentation. Un pipeline de données en Python, c'est aussi un document. Il explique à un collègue — ou à ton futur toi — ce que tu as filtré, quelles variables tu as créées, d'où vient le chiffre final. Plus ce chemin est facile à suivre, plus il est simple de vérifier tes hypothèses et de repérer les erreurs.

Le problème, c'est que le code boilerplate (les parties répétitives et inutiles) noie la logique métier sous une montagne de détails techniques. Les noms de dataframes, les sélecteurs de colonnes, les guillemets, les lambdas, les alias, les options spécifiques à l'API. Tout ça réduit le rapport signal/bruit. La logique est là, mais elle est noyée dans un flot de syntaxe.

POURQUOI EXCEL ET LES Outils VISUELS ONT ENCORE LA COTE

Si tu n'es pas convaincu que ce problème existe, pense à la popularité des outils de données visuels. Excel reste ancré dans presque tous les secteurs. Tableau, Power BI, KNIME, Alteryx, Metabase, Orange, RapidMiner. Tous ces outils promettent la même chose : toucher les données plus directement, voir les résultats rapidement et éviter de devoir traduire chaque pensée en une API de programmation générale.

Je utilise beaucoup Excel. Il y a des tas de situations où glisser un petit jeu de données dans un tableau croisé dynamique est plus rapide que d'écrire un pipeline pandas. Les outils visuels peuvent être plus intuitifs et réduire la latence entre la pensée et le résultat.

Bien sûr, le code a son utilité. Un script fournit une piste d'audit depuis les données brutes jusqu'au résultat. Il peut être revu, testé, versionné, réexécuté et partagé. C'est pour ça que les équipes déplacent les travaux critiques hors des tableurs. Beaucoup d'outils visuels modernes génèrent même du code pandas pour cette raison précise, comme Data Wrangler ou Mito.

Mais si le code doit servir de documentation, pourquoi utiliser une syntaxe aussi chargée que celle de pandas ? Pourquoi ne pas choisir quelque chose de plus lisible pour les humains ?

POLYMORPHISME DES SYNTAXES : LE MÊME CONCEPT, DIFFÉRENTES CLÉS

Passe à Polars, et les idées analytiques de base restent les mêmes : sélectionner, filtrer, dériver, grouper, agréger, joindre, trier. Mais la syntaxe change. Passe de Python à R, Julia ou MATLAB, et elle change encore.

Il peut y avoir de bonnes raisons à ces différences, mais d'un point de vue d'analyste, c'est étrange que la même opération logique doive être réapprise dans chaque environnement. Si tu fais de la statistique, tu iras peut-être vers R. Si tu fais de la simulation ou de l'optimisation, tu iras vers Julia ou MATLAB. Si tu as un jeu de données trop gros pour tenir en mémoire, tu iras vers DuckDB. Pourquoi faut-il aussi changer la grammaire dans laquelle tu exprimes « grouper par région, puis sommer le chiffre d'affaires » ?

La plupart des awkwardness (les aspects maladroits) de pandas viennent du fait d'embarquer une grammaire de transformation de données à l'intérieur d'un langage de programmation généraliste.

Python doit distinguer les variables, les attributs, les chaînes de caractères, l'indexation des listes, les appels de fonctions et les affectations. Une bibliothèque de dataframes doit construire son langage à partir des mêmes pièces. C'est pour ça que les noms de colonnes deviennent des chaînes de caractères, que la dataframe active est répétée sans cesse et qu'une expression simple peut s'encombrer de ponctuation :

sales.loc[sales["revenue"] > 0, "margin"] = (
    sales["revenue"] - sales["cost"]
)

Un langage spécifique au domaine (DSL) peut faire des choix différents, car il a un travail plus étroit à accomplir. SQL en est la preuve la plus forte. Il a donné au travail sur les données un vocabulaire partagé qui a survécu aux changements de matériel, de fournisseurs et de langages hôtes. Sa durabilité n'est pas un hasard.

SQL N'EST PAS LA SOLUTION PARFAITE POUR TOUT

Pourtant, SQL n'est peut-être pas la réponse ultime pour tous les flux de travail analytiques. SQL a été conçu pour interroger des bases de données relationnelles, pas pour le cycle interactif complet de chargement de données locales, de transformation, de traçage, d'appel d'un modèle et de sauvegarde d'un ensemble de résultats. Son ordre traditionnel des clauses ne se lit pas comme un pipeline de haut en bas, et les travaux complexes s'étendent souvent en requêtes imbriquées ou en chaînes d'expressions de table communes.

Des projets comme PRQL et la syntaxe pipée dans SQL améliorent considérablement la lisibilité de haut en bas de SQL, tandis que DuckDB a rendu SQL plus à l'aise dans les flux de travail Python locaux.

La popularité de DuckDB est elle-même un cas d'étude intéressant. Une enquête récente auprès de ses utilisateurs a montré que beaucoup n'ont pas en réalité des jeux de données plus gros que la mémoire. Au-delà de la performance, ils apprécient DuckDB pour sa facilité d'utilisation et son support de SQL.

Mais DuckDB, PRQL et SQL pipé sont finalement encore des extensions de SQL classique. DuckDB peut transformer des tables rapidement, mais les opérations analytiques courantes comme le traçage doivent encore être faites en Python. Cela signifie revenir à une API de dataframe, ce qui va interrompre ton flux de travail. Et même si DuckDB exécute la transformation assez vite, le changement de contexte va casser ta concentration.

Ce sont ces préoccupations qui m'ont conduit à créer Pivotal, un DSL open source pour l'analyse de données en Python.

PIVOTAL : UNE SYNTAXE PLUS PROCHE DE LA PENSÉE ANALYTIQUE

Pivotal n'est pas un remplacement de l'écosystème Python. C'est une façon compacte d'exprimer les opérations analytiques courantes, qui peut ensuite compiler en code Python utilisant pandas, Polars ou DuckDB. L'objectif est de séparer la logique que l'analyste écrit de l'engin qui l'exécute.

with sales as summary
    filter revenue > 0
    margin = revenue - cost
    group by region
        agg sum revenue as totalrevenue, mean margin as averagemargin
    sort total_revenue desc

La différence ne se limite pas au nombre de caractères. Chaque ligne correspond à une idée analytique. La table active est déclarée une seule fois. Les colonnes sont des colonnes, pas des chaînes de caractères. Le groupement et ses agrégations forment un bloc visible. La lecture de haut en bas suit l'ordre dans lequel l'analyste pense.

Comme Pivotal compile en Python ordinaire, ses résultats restent disponibles pour le reste de l'écosystème Python. Pivotal inclut aussi des commandes pour les graphiques, les tableaux et la sauvegarde des résultats, tandis que le Python régulier reste disponible comme échappatoire quand le DSL n'est pas l'outil adapté.

Bien sûr, Pivotal n'est peut-être pas la syntaxe ultime. C'est un projet jeune avec ses propres compromis. Les utilisateurs doivent l'apprendre. Les outils sont limités (seulement VS Code et JupyterLab pour l'instant) et le support communautaire n'existe pas encore. pandas a une énorme inertie, et pour les équipes avec des bases de code établies — y compris la mienne — un nouveau langage est difficile à vendre.

Mais Pivotal est une expérience dans un espace de conception qui a été peu exploré. On mesure soigneusement le temps d'exécution. On devrait aussi se soucier du temps de compréhension, de la visibilité des erreurs et du nombre de concepts qu'un analyste doit garder en tête pour exprimer une transformation simple.

L'ÈRE DE L'IA : VERS DE NOUVEAUX LANGAGES OU DE NOUVELLES INTERFACES ?

On vit une époque intéressante. Quand j'ai commencé ma carrière au début des années 2000, on utilisait Excel et Visual Basic pour le nettoyage de données, et des logiciels payants comme SAS et Stata pour l'analyse. Python était encore une niche, et pandas ou scikit-learn n'existaient pas encore. Depuis, l'écosystème Python est devenu la norme dans l'académie, l'industrie et les environnements IT gouvernementaux.

Mais tout cela semble modeste comparé à la disruption que l'IA est sur le point de déclencher.

L'essor des agents de codage IA ces douze derniers mois fait réfléchir beaucoup de gens sur l'avenir de la programmation. Verra-t-on émerger de nouveaux langages et DSL pour interagir avec ces agents ? Ou ces agents devraient-ils produire des représentations plus abstraites ou visuelles de la logique, plutôt que du code — comme un diagramme de pipeline de données (par exemple, un DAG à la Airflow ou KNIME) ?

Et qu'en est-il des outils de données visuels ? À une époque où les ordinateurs comprennent le langage humain, les interfaces cliquer-glisser commencent à paraître un peu désuètes. En même temps, on pourrait voir une convergence de ces produits, avec des outils qui mélangent langage naturel, interaction visuelle et génération de code de manière transparente.

Je ne sais pas à quoi ressemblera l'interface gagnante. Mais je sais qu'on peut faire mieux. Parce que df.groupby("year").reset_index() ne peut pas être le sommet de l'accomplissement humain.

EXEMPLES CONCRETS : TRANSFORMER DES DONNÉES SANS PERDRE LA TÊTE

Prenons un exemple concret. Tu as un jeu de données de ventes avec trois colonnes : revenue (chiffre d'affaires), cost (coût) et region (région). Tu veux calculer la marge par vente, puis faire la somme du chiffre d'affaires et la moyenne de la marge par région, en ne gardant que les ventes positives. Voici comment tu pourrais faire ça dans trois styles différents.

Avec pandas :

summary = (
    sales.loc[sales["revenue"] > 0]
    .assign(margin=lambda df: df["revenue"] - df["cost"])
    .groupby("region", as_index=False)
    .agg(
        total_revenue=("revenue", "sum"),
        average_margin=("margin", "mean"),
    )
    .sortvalues("totalrevenue", ascending=False)
)

Analysons cette syntaxe :

• sales.loc[sales["revenue"] > 0] : On filtre les ventes positives. Mais pourquoi faut-il répéter sales deux fois ?
• .assign(margin=lambda df: df["revenue"] - df["cost"]) : On crée une nouvelle colonne margin en soustrayant le coût du chiffre d'affaires. Le lambda est une fonction anonyme qui prend la dataframe en entrée et retourne la marge.
• .groupby("region", as_index=False) : On regroupe par région. Le paramètre as_index=False empêche pandas de transformer la colonne region en index, ce qui simplifierait la suite.
• .agg(.) : On agrège les données. On calcule la somme du chiffre d'affaires et la moyenne de la marge pour chaque région.
• .sortvalues("totalrevenue", ascending=False) : On trie les résultats par chiffre d'affaires décroissant.

Chaque étape est correcte, mais l'ensemble est lourd. Ton cerveau doit constamment faire le lien entre la logique métier et la syntaxe de pandas.

Avec une syntaxe plus directe :

with sales as summary
    filter revenue > 0
    margin = revenue - cost
    group by region
        agg sum revenue as totalrevenue, mean margin as averagemargin
    sort total_revenue desc

Ici, chaque ligne correspond à une étape logique :

• with sales as summary : On déclare la table active comme summary.
• filter revenue > 0 : On filtre les ventes positives.
• margin = revenue - cost : On calcule la marge.
• group by region : On regroupe par région.
• agg sum revenue as totalrevenue, mean margin as averagemargin : On agrège les données.
• sort total_revenue desc : On trie les résultats.

Pas de répétitions, pas de syntaxe tordue. Juste la séquence des opérations que tu as en tête.

Avec SQL (version DuckDB) :

SELECT
    region,
    SUM(revenue) AS total_revenue,
    AVG(revenue - cost) AS average_margin
FROM sales
WHERE revenue > 0
GROUP BY region
ORDER BY total_revenue DESC;

SQL est plus lisible, mais il a ses limites. Par exemple, si tu veux faire un graphique ou sauvegarder le résultat dans un fichier, il faudra quitter SQL et revenir à Python. Ce changement de contexte casse le flux de travail.

POURQUOI CELA COMPTE POUR TOI, MÊME SI TU N'ES PAS DATA ANALYST

Tu n'es peut-être pas data analyst, mais tu utilises probablement des données dans ton travail ou tes études. Que ce soit pour suivre tes notes, analyser des résultats d'enquêtes, ou même gérer un budget, tu as déjà dû transformer des données.

Le problème de la charge cognitive ne concerne pas seulement les professionnels. Si tu utilises pandas, Excel ou un autre outil pour analyser des données, tu as probablement déjà ressenti cette frustration : tu passes plus de temps à te battre avec la syntaxe qu'à réfléchir à ce que signifient les données.

Les outils visuels comme Excel ou Tableau sont plus intuitifs, mais ils ont leurs limites. Ils ne sont pas toujours adaptés aux jeux de données complexes ou aux analyses répétitives. Le code, lui, permet de tout automatiser, mais à quel prix ?

L'idéal, c'est un outil qui combine la puissance du code avec la simplicité des interfaces visuelles. Un outil où tu peux exprimer ta logique de manière concise et lisible, sans avoir à te soucier de la syntaxe.

C'est exactement ce que cherche à faire Pivotal. Et c'est aussi ce que pourraient offrir les futurs agents IA, s'ils sont conçus pour produire des représentations visuelles ou des pipelines plutôt que du code brut.

LE FUTUR : VERS UNE NOUVELLE GÉNÉRATION D'OUTILS

L'avenir des outils de données est probablement hybride. On pourrait voir émerger des interfaces qui mélangent :

• Langage naturel : Tu décris ce que tu veux faire en français ou en anglais, et l'outil génère le code ou le pipeline correspondant.
• Interaction visuelle : Tu dessines ton pipeline de données comme un schéma, et l'outil exécute les transformations.
• Génération de code : L'outil écrit le code pour toi, mais dans une syntaxe plus lisible et plus proche de ta pensée.

Des outils comme Airflow ou KNIME montrent déjà la voie avec leurs diagrammes de pipelines (DAG). Mais ces outils restent complexes et nécessitent une courbe d'apprentissage. L'idéal serait une interface qui combine la simplicité d'Excel avec la puissance de Python.

Pivotal est une première étape dans cette direction. D'autres projets, comme PRQL ou les extensions de SQL, montrent aussi qu'il existe un besoin pour des syntaxes plus simples et plus lisibles.

Et avec l'essor de l'IA, on pourrait voir des agents capables de générer non pas du code, mais des pipelines visuels ou des diagrammes que tu pourrais modifier à la souris ou par la voix.

CE QUE TU PEUX FAIRE AUJOURD'HUI

Si tu es frustré par la syntaxe de pandas ou d'autres outils de données, voici quelques pistes pour améliorer ta productivité :

• Essaie des outils visuels : Si ton jeu de données est petit, un tableau croisé dynamique dans Excel ou un dashboard dans Tableau peut être plus rapide qu'un script Python.
• Explore des alternatives à pandas : Polars, DuckDB ou même SQL peuvent être plus simples pour certaines tâches.
• Automatise ce que tu peux : Si tu répètes souvent les mêmes transformations, écris des fonctions réutilisables en Python.
• Documente ton code : Même si c'est pénible, ajoute des commentaires pour expliquer ta logique. Ça t'aidera, toi et tes collègues, à comprendre ce que tu as fait.
• Teste Pivotal : Si tu es prêt à apprendre un nouveau langage, Pivotal pourrait être une alternative intéressante à pandas.

Et surtout, n'oublie pas que le but n'est pas d'écrire du code parfait, mais de comprendre tes données. Si un outil te fait perdre plus de temps qu'il ne t'en fait gagner, change d'outil.

EN CONCLUSION : LES DONNÉES NE SONT PAS UN CASSE-TÊTE

Le problème avec pandas n'est pas sa performance. C'est la charge cognitive qu'il impose. Chaque parenthèse, chaque virgule, chaque méthode à retenir est une distraction qui t'éloigne de l'essentiel : comprendre ce que signifient tes données.

L'IA peut t'aider à écrire du code, mais elle ne peut pas penser à ta place. Les outils visuels sont plus intuitifs, mais ils ont leurs limites. SQL est plus lisible, mais il n'est pas adapté à toutes les tâches.

Il existe probablement une meilleure façon de transformer des données. Une façon qui te permet de te concentrer sur la logique métier, pas sur la syntaxe. Une façon qui réduit la charge cognitive et te laisse plus de place pour réfléchir.

Pivotal, PRQL, SQL pipé. Ces projets montrent qu'il existe des alternatives. Et avec l'essor de l'IA, on pourrait voir émerger des interfaces encore plus intuitives et puissantes.

Alors, la prochaine fois que tu écris un pipeline de données, demande-toi : est-ce que je passe plus de temps à coder ou à réfléchir ? Si la réponse est « coder », il est peut-être temps de chercher une autre solution.

Parce que df.groupby("year").reset_index() n'est pas une fatalité. C'est juste un symptôme d'un problème plus large : l'outillage de données n'a pas encore rattrapé l'évolution des besoins des analystes.