Le créateur de Pandas parle de l’avenir de l’IA, d’Apache Arrow et du génie logiciel [YouTube]

• Fort de son expérience dans la création de Pandas et d’Apache Arrow, il estime qu’à l’ère de l’IA, l’expertise, le jugement et le goût restent au cœur de la conception de systèmes de données et de logiciels haute performance
• Apache Arrow est une couche en mémoire universelle pour les données tabulaires, qui standardise leur transfert et leur traitement entre systèmes ; plus il est adopté, plus la valeur de l’interopérabilité augmente
• Des systèmes sophistiqués comme DuckDB ou DataFusion sont difficiles à remplacer par la seule génération de code moyenne d’un LLM, et la compétitivité de l’open source repose aussi, au-delà du code, sur un historique de confiance et de qualité accumulé sur le long terme
• Les outils d’IA peuvent fortement accroître la productivité des développeurs les plus proactifs, mais si l’on ne sait pas clairement quoi construire, on risque d’accumuler des solutions et du code moyens, créant un bourbier agentique (agentic tarpit) dont même les agents ont du mal à sortir
• À l’avenir, l’architecture, la définition du problème, la communication et la capacité à évaluer les résultats compteront davantage que la syntaxe d’un langage ou le code écrit à la main, et les organisations devront aussi gérer une charge décisionnelle accrue et le coût des tokens

---

D’une carrière autour de Pandas aux outils de développement IA

• Wes McKinney a créé Python Pandas il y a environ 18 ans et l’a publié comme projet open source en 2010
• Son livre Python for Data Analysis a été largement utilisé dans l’écosystème Python de la data science, puis il s’est impliqué dans la création d’entreprises et de modèles économiques permettant de poursuivre le développement open source
• Chez Cloudera, il a lancé Apache Arrow avec plusieurs développeurs open source, et a aussi contribué à l’écosystème Arrow et au développement de Parquet
• Ursa Computing est ensuite devenu Voltron Data, et même après la réorganisation de Voltron Data, il a conservé ses liens avec Posit
• Aujourd’hui, il a fondé une nouvelle entreprise centrée non plus sur les bibliothèques de data science, mais sur les outils et l’infrastructure pour développeurs IA, afin d’explorer comment l’IA peut améliorer la productivité en génie logiciel

Comment Apache Arrow s’est diffusé

• Arrow est une couche de base en mémoire pour les données tabulaires qui accélère le traitement en mémoire et le transfert de données entre systèmes, tout en améliorant l’interopérabilité
• Au départ, le faible nombre d’utilisateurs et de systèmes consommateurs réduisait l’incitation à l’adopter, et certains doutaient que plusieurs communautés open source puissent s’accorder sur un format unique
  • Créer un nouveau standard unifié conduit facilement au problème façon XKCD où 13 standards existants deviennent 14
  • Arrow a grandi en proposant une implémentation stable dans un contexte où il existait peu d’alternatives crédibles pour résoudre le même problème, puis en attendant l’adoption
• La technologie elle-même n’a pas beaucoup changé ces 5 à 6 dernières années, mais à mesure que davantage de systèmes l’adoptent, sa valeur augmente d’une manière proche d’un effet de réseau
• DataFusion permet d’étendre un moteur de requêtes pour l’adapter à un produit sans devoir le créer de zéro ; on estime qu’environ 30 à 40 entreprises l’utilisent comme composant interne
  • Arroyo, qui construisait un moteur de données en streaming, a été racheté par Cloudflare, et Arrow comme DataFusion sont ensuite devenus une partie de l’infrastructure de données en streaming de Cloudflare
  • DataFusion Comet sert à accélérer Spark

Des logiciels systèmes que l’IA remplace difficilement

• DataFusion et DuckDB sont des projets qu’il est difficile de remplacer rapidement par du vibe coding
• Les LLM ont tendance à moyenner le code et les approches existantes, ce qui rend difficile, à court terme, la production de systèmes finement conçus par des experts comme des moteurs de requêtes de pointe
• Ces projets ressemblent davantage à une montre suisse de précision assemblée par un artisan qu’à un jouet en plastique moulé par injection
  • Cela ne veut pas dire que l’IA ne pourra jamais les produire, mais qu’à ce stade, leur remplacement paraît peu probable
• La valeur d’un projet open source ne vient pas seulement de son implémentation, mais aussi de la confiance accumulée au fil du temps par sa communauté
  • la conviction que les mainteneurs agissent dans l’intérêt de la communauté
  • l’attente qu’ils sauront défendre le projet contre les attaques de la chaîne d’approvisionnement et corriger les bugs graves
  • l’historique de livraison d’un logiciel cohérent, bien conçu et fiable
• McKinney n’est plus profondément impliqué dans le développement de Pandas depuis 2013, et le projet est aujourd’hui maintenu par un large groupe de développeurs
  • selon lui, la reconnaissance et le soutien doivent donc aller aux véritables mainteneurs
• Même si l’IA permet de générer 10 000 lignes de code par jour, on ne peut pas publier un résultat qui n’atteint pas les standards de qualité accumulés dans le passé ; le défi principal devient donc davantage la revue et le maintien de la qualité que le volume généré

Du jeu et des mathématiques à la programmation

• À la fin des années 1990, il était passionné par GoldenEye 007 sur Nintendo 64 et a rejoint une communauté de speedrun en créant un site de fans sur GeoCities fin 1997 ou début 1998
• À l’époque, il gérait le site manuellement, mais en voyant Kisman, très doué en programmation compétitive, automatiser les mises à jour avec un programme C++, il a découvert l’effet de levier de l’automatisation produite par un excellent programmeur
• Au lycée, il s’intéressait aux concours de mathématiques et à l’informatique ; au MIT, il a ressenti l’écart de niveau face à des camarades qui programmaient depuis l’enfance
• En préparant un diplôme de mathématiques pures, il a étudié un peu d’informatique théorique, notamment la complexité et les algorithmes, mais une mauvaise expérience avec Java l’a longtemps détourné de la programmation elle-même
• Il ne s’y est vraiment investi qu’en comprenant la programmation comme un outil de résolution de problèmes et d’amplification de la productivité individuelle

Pandas, né de la recherche en finance

• En 2007, à 22 ans, il a rejoint un hedge fund quantitatif et a découvert que, contrairement à ses attentes d’une recherche centrée sur les formules, beaucoup d’analyses reposaient sur des feuilles Excel et du travail manuel
• MATLAB et R étaient aussi utilisés, mais plutôt comme outils d’appoint, et déployer du code MATLAB sur des serveurs nécessitait des licences coûteuses pour chaque machine
• Il a jugé nécessaire d’utiliser un langage open source adapté à la construction de systèmes couvrant tout le cycle, de la recherche à la production
• Sur les conseils d’un collègue, il a commencé début 2008 à utiliser Python et ses bibliothèques de calcul scientifique ; en recréant les outils de recherche existants en Python, une première forme de Pandas a émergé
• Concevoir des outils qui augmentent la productivité et voir d’autres personnes travailler plus efficacement grâce à eux lui procurait une immersion comparable à celle du speedrun

Simplicité de l’expérience utilisateur et dette technique interne

• McKinney privilégie des outils simples et cohérents que d’autres peuvent comprendre et utiliser, plutôt que des outils d’IA complexes adaptés à une seule personne
• Un ensemble d’outils trop personnalisé peut devenir si complexe qu’il ressemble à la Winchester Mystery House, impossible à explorer pour quiconque autre que son créateur
• Les premières implémentations de Pandas privilégiaient l’API et l’utilisabilité, plus faciles à comprendre et à écrire pour les humains, plutôt que l’architecture interne
• Cette confusion interne a laissé un lourd fardeau de maintenance pendant longtemps, mais le succès de Pandas montre qu’un logiciel peut connaître un grand succès sans architecture parfaite

Le rôle et les limites de NumPy

• NumPy est né de la fusion, vers 2005-2006 par Travis Oliphant, de Numeric, une bibliothèque de tableaux multidimensionnels lancée par Jim Hugunin au milieu des années 1990, et de la lignée Numarray, qui ajoutait des fonctions pour les grands tableaux comme le memory mapping
• À l’époque, Matplotlib, SciPy ainsi que des outils de statistiques et de régression linéaire fonctionnaient autour des tableaux NumPy ; pour qu’un nouvel outil de données rejoigne l’écosystème, la compatibilité NumPy était indispensable
• NumPy était centré sur les grands tableaux multidimensionnels de nombres et d’entiers, et n’avait pas été conçu comme base pour des bases de données ou des données non numériques
• Les premières versions de Pandas se sont appuyées sur NumPy tout en contournant ses limites pour les données non numériques
  • les valeurs autres que numériques ou booléennes étaient stockées comme objets Python dans des tableaux NumPy
  • pour les chaînes de caractères, cela entraînait du surcoût d’objet et des références indirectes, donc une faible efficacité
• Ces limites ont ensuite motivé la création d’Arrow, comme base en mémoire alternative destinée à des systèmes tels que Pandas

La croissance de l’écosystème Python pour la data science

• Plusieurs entreprises financées par le capital-risque affirmaient que chaque entreprise devait construire une infrastructure de données comparable à celle de Google, ce qui a attiré des investissements massifs vers les projets open source du big data
• Toutes les entreprises n’avaient pas besoin d’une infrastructure de cette ampleur, mais sans cet argent, il aurait sans doute été beaucoup plus difficile de réunir les développeurs nécessaires à Arrow
• À l’époque, le secteur se disputait autour du sens même de la data science et du data scientist, ainsi que de la manière de trouver des profils combinant compétences métier, statistiques et logicielles
• Python a permis à des personnes ayant peu d’expérience en programmation mais des bases en statistique d’accéder à la data science
  • en apprenant Python for Data Analysis et des outils comme scikit-learn, on pouvait commencer à produire des analyses utiles au travail en 2 à 3 semaines
  • s’il avait d’abord fallu apprendre un langage comme Scala, la barrière à l’entrée et la durée d’apprentissage auraient été bien plus élevées

Publication de Pandas et structuration autour d’Arrow

• La décision de publier Pandas a été prise la veille du Nouvel An 2009, et sa première présentation à PyCon en février 2010 l’a véritablement connecté à la communauté Python
• McKinney a commencé un doctorat de statistique à Duke en 2010, mais a mis ses études en pause en voyant l’intérêt des sociétés financières pour les outils de données Python et le potentiel de croissance de Pandas
• À l’époque, Pandas 0.1 avait encore des fonctionnalités limitées, au point de ne pas prendre en charge tous les types de jointures ; il a quitté l’université pour se concentrer sur la croissance du projet
• Après avoir étudié une activité de technologie financière, il a écrit Python for Data Analysis puis fondé une startup BI, avant de juger en 2013 qu’il serait difficile de rivaliser avec Looker sur le marché de la BI et de rejoindre Cloudera
• Chez Cloudera, il a travaillé avec les développeurs d’Impala et rencontré de nombreux ingénieurs qui évolueront ensuite vers Iceberg, Databricks et d’autres projets ; cette expérience a servi de tremplin pour la suite de sa carrière
• Le projet Arrow a démarré chez Cloudera au début de 2016, mais dans le logiciel d’entreprise, il était alors difficile d’obtenir le budget d’une équipe dédiée à une technologie expérimentale
• Entre 2016 et 2018, il a appliqué Arrow à des systèmes réels dans des sociétés financières afin d’accélérer les charges de traitement de données et d’améliorer Parquet
• En 2018, plusieurs entreprises voulaient financer le développement d’Arrow, mais les règles internes de la société financière rendaient la gestion de fonds externes compliquée ; il a donc créé en avril une structure indépendante capable de recevoir un sponsoring d’entreprise
  • environ 6 sponsors y ont participé, dont des entreprises de matériel comme Nvidia et des sociétés financières
  • une équipe d’environ 8 développeurs a été constituée
• Après avoir confirmé l’opportunité commerciale, il a fait évoluer le projet en Ursa Computing pendant la période du Covid-19 en 2020

Des problèmes de data engineering toujours présents

• Aujourd’hui encore, le domaine de la donnée résout en boucle les mêmes problèmes : déplacer des données de A vers B, convertir des formats, charger en mémoire, puis exécuter efficacement requêtes et transformations
• Pandas est devenu une base qui soutient bien plus de flux de données d’entreprise que prévu, et il est possible qu’aujourd’hui les LLM génèrent davantage de code Pandas que les humains n’en ont écrit par le passé
• DuckDB est un outil d’une puissance qu’un développeur d’il y a 20 ans aurait eu du mal à imaginer
  • il peut être installé gratuitement et exécuté dans des environnements variés
  • il peut fonctionner sur téléphone et dans un navigateur web
  • il fournit de l’analytique haute performance sur une seule machine, sans installation complexe
• Après de longues années de difficultés et d’essais-erreurs, la nécessité de technologies comme DuckDB et Arrow est devenue claire ; Parquet et d’autres solutions ont aussi été influencés par des techniques créées par de grandes entreprises internet comme Google pour réduire coûts et temps
• Parquet n’est pas le format idéal, mais il représente un grand progrès par rapport au passé et est pris en charge par presque tous les systèmes
  • même s’il existe des alternatives spécialisées comme Vortex ou Lance, il continue d’être utilisé grâce à une compatibilité suffisamment bonne
• Avec l’IA qui capte l’attention du secteur, le data engineering est moins sous les projecteurs ; même quand Databricks annonce un nouveau moteur de données, l’intérêt est moindre qu’auparavant
• En contrepartie, cela laisse aux développeurs d’outils de données davantage de marge pour se concentrer sur la qualité technique plutôt que sur les effets de mode, tout en utilisant l’IA pour des tâches répétitives et pénibles comme l’écriture de tests

Une convergence vers les technologies de base de données

• La grande leçon de l’ère du big data est qu’il aurait fallu exploiter plus tôt les articles et résultats de conférence des chercheurs en bases de données
• Il est important de lire, implémenter et faire évoluer en collaboration les travaux de recherche en bases de données issus d’institutions comme TU Munich, CWI, MIT, CMU ou Berkeley
• À l’époque dominée par NoSQL et les stockages non relationnels, les systèmes extensibles ajoutaient parfois une telle surcharge qu’ils devenaient plus lents que des implémentations bien conçues sur une seule machine et un seul thread
• L’étude Scalability! But at what COST?, à laquelle ont notamment participé Frank McSherry et Michael Isard, traite du coût à payer pour obtenir cette extensibilité
• La stack data moderne converge de nouveau vers les technologies de base de données et le traitement en colonnes
  • Polars, Daft et DataFusion utilisent Arrow
  • le nouveau moteur de dbt exploite ADBC
  • Databricks Photon adopte une structure en colonnes, qu’il utilise ou non Arrow
• À mesure que les grands systèmes convergent vers des architectures et approches similaires, l’enjeu devient moins le mode de traitement lui-même que la facilité réelle d’utilisation du logiciel

De Hadoop à DuckDB : des progrès d’utilisabilité

• À l’époque de Hadoop, il fallait parfois passer près de deux jours à configurer Java, des fichiers XML et une multitude de paramètres avant de pouvoir commencer le vrai travail
• Spark a été une grande amélioration en permettant d’écrire un comptage de mots en une ligne, mais il fallait encore préparer l’infrastructure et les fichiers de configuration
• Le mode d’installation et d’exécution de DuckDB constitue un modèle d’utilisabilité montrant jusqu’où la simplification des systèmes de données peut aller
• Même les systèmes distribués devraient offrir des valeurs par défaut raisonnables et une configuration fonctionnelle immédiatement afin de réduire la complexité opérationnelle
• DuckDB s’étend aussi vers le domaine client-serveur et collabore étroitement avec MotherDuck

Une couche de données multimodale pour l’IA générative

• Les lakehouses existants restent centrés sur les formats tabulaires et Parquet, alors que l’IA générative et l’entraînement ou le fine-tuning de grands modèles nécessitent conjointement images, vidéos, texte, documents et logs
• Le lakehouse de données multimodales abordé par LanceDB correspond à un véritable problème d’entreprise
• Générer des embeddings à partir de grands volumes de données non structurées consomme de l’électricité et du temps GPU ; les embeddings produits acquièrent donc eux-mêmes une valeur économique liée à ce coût de calcul
• En production, il faut un stockage de données capable de conserver, gérer et traiter de façon fiable les données sources et les résultats générés
• Si chaque entreprise construit son propre stockage multimodal, elle risque de répéter les mêmes bugs, pertes de données et problèmes de performance ; il est donc plus efficace qu’un éditeur spécialisé fournisse une solution commune
• Même si l’on peut exploiter directement des tables Iceberg, déléguer leur gestion à des fournisseurs comme Databricks, Snowflake ou AWS réduit la complexité opérationnelle ; la même logique s’applique aux données multimodales pour l’IA générative
• Sur le marché des données pour l’IA générative, il reste de la place pour résoudre des couches distinctes, de la recherche vectorielle documentaire et du traitement à haut QPS jusqu’à la gestion du cycle de vie des données

La compétitivité des développeurs à l’ère de l’IA

• McKinney dit s’être lui-même demandé un temps s’il avait encore un avenir comme ingénieur logiciel, mais il estime que l’IA différencie désormais plus nettement les personnes selon leur niveau de proactivité
• Les personnes très proactives, capables de réfléchir à ce qu’il faut construire et d’évaluer un bon résultat grâce à leur goût et à leur jugement, peuvent tirer de l’IA un fort effet de levier de productivité
• Les LLM proposent pour la plupart des problèmes une approche de niveau B+, moyenne et correcte, mais ils ne créent pas à la place de l’utilisateur l’expérience, le goût ou le jugement
• Sans bon jugement, continuer à empiler du code généré finit par former un bourbier complexe où même les agents peinent à poursuivre le travail sous le poids du contexte et de la structure
• Autrefois, on développait en implémentant soi-même et en forgeant simultanément sa technique et son jugement ; à l’avenir, à mesure que le temps de code manuel diminue, il faudra développer séparément la compréhension des systèmes et les capacités de conception

Ce qu’il faut étudier à l’ère de l’IA

• Les nouveaux développeurs ont intérêt à étudier la conception et l’architecture logicielles ainsi que la structure des systèmes de données, plutôt que de se limiter à la syntaxe de Python ou Java
• En data engineering, il faut comprendre comment fonctionnent différents systèmes comme les architectures Lambda et Kappa, et à quels problèmes ils conviennent
• Il faut être capable de transmettre précisément à un agent le résultat souhaité, et de reconnaître quand il part dans la mauvaise direction
• Si l’utilisateur est incapable de juger ce qui est meilleur entre A et B, l’agent ne peut pas non plus garantir le bon choix à sa place
• Ingénieurs logiciels, data engineers et data scientists pourraient tous passer davantage de temps à définir les problèmes et communiquer qu’à écrire du code
• Si l’on est incapable d’expliquer ce que l’on veut, on n’obtiendra pas non plus de l’IA le résultat souhaité ; ajouter simplement de l’IA dans une organisation n’augmente pas automatiquement la productivité ni les performances économiques
• Donner l’IA à des personnes manquant d’expérience et de jugement peut en faire un canon à slop (slop cannon) produisant massivement une dette que d’autres devront traiter, plutôt que des livrables utiles

Une hausse des décisions à prendre et l’investissement IA des organisations

• Dans les 2 à 5 prochaines années, le recrutement de développeurs, les entretiens techniques et la répartition des rôles pourraient devenir confus et évoluer rapidement
• Par le passé, l’équipe construisait une confiance commune dans le travail à travers les réunions, le sprint planning et le planning poker, puis répartissait l’implémentation
• Désormais, le processus classique de planification agile peut se retrouver compressé dans le mode planification de Claude, et un seul développeur peut se retrouver à devoir prendre seul un très grand nombre de décisions
• Un développeur amené à prendre 10 fois plus de décisions qu’avant dans une journée peut se retrouver paralysé par la fatigue décisionnelle et l’ambiguïté
• Les personnes capables de juger rapidement et de choisir une trajectoire efficace peuvent exploiter la productivité de l’IA, mais pour celles qui ne savent pas clairement quoi faire, l’IA ne résout pas ce problème
• Les entreprises peuvent payer cher Anthropic et OpenAI sans pour autant réussir à démontrer un retour sur investissement clair de leurs dépenses IA
  • on observe à la fois quelques résultats positifs, du gaspillage, des livrables de faible qualité et le coût nécessaire pour remettre de l’ordre dans ces productions
  • les fournisseurs de modèles d’IA profitent tant que la vente de tokens continue, mais les entreprises clientes sont susceptibles d’imposer des budgets tokens plus stricts

Modèles open weight et économie des tokens

• McKinney a exécuté le modèle chinois open weight GLM 5.2 sur une infrastructure physique et juge les résultats bons
• GLM 5.2 n’est pas un petit modèle, et l’exécuter correctement nécessite environ 8 GPU B200
  • le prix d’un seul B200 est estimé entre 30 000 et 50 000 dollars
  • le coût matériel total peut donc atteindre environ 250 000 à 400 000 dollars
• À long terme, il espère qu’avec l’amélioration de la qualité des modèles open weight et la baisse du coût du matériel, il deviendra possible d’éviter de payer en continu des entreprises d’IA externes et de ne supporter que le coût électrique d’un serveur personnel
• Si l’on calcule au tarif public API les tokens utilisés au cours des 30 derniers jours, cela représente environ 37 000 dollars, mais le montant réellement payé au fournisseur de modèles est bien inférieur
• Les prix actuels des tokens pourraient intégrer des subventions massives, et on ne sait pas encore quelle structure de coûts sera durable à long terme
• L’adoption de l’IA n’est pas non plus aussi uniforme que le laisserait penser l’attention du secteur : certaines entreprises en sont encore au stade des discussions au niveau du conseil d’administration et du CTO, sans avoir réellement commencé la mise en œuvre