Vos traitements de données sont lents et coûtent cher. Ce n'est pas une fatalité.

Un job de nuit qui déborde sur la matinée. Un notebook qui sature la mémoire sur un volume pourtant raisonnable. Une facture cloud qui grimpe à chaque nouveau cas d'usage. Face à ces symptômes, la réponse habituelle est d'ajouter : une instance plus grosse, un cluster, une plateforme distribuée. C'est presque toujours la réponse la plus chère, et rarement la bonne.

Cet audit répond à deux questions. Où vos traitements perdent-ils réellement du temps, et quels leviers permettent de le récupérer ? Où perdez-vous de l'argent, et quelle infrastructure correspond vraiment à votre charge de travail ?

Je ne vends ni plateforme, ni licence, ni projet de migration. Mes recommandations n'ont pas d'autre intérêt que le vôtre.

Le mauvais réflexe : les outils de Google pour des données qui ne sont pas celles de Google

Spark, Hadoop, et les plateformes construites dessus ont été conçus pour des entreprises qui traitent des données que leurs machines ne peuvent pas contenir. C'est un problème réel, et rare. La plupart des équipes qui adoptent ces outils ont des volumes de plusieurs ordres de grandeur inférieurs, mais raisonnent ainsi : si c'est assez bon pour Google ou Amazon, c'est ce qu'il y a de mieux. Elles héritent alors d'une couche d'exploitation, de compétences et de coût qu'elles n'amortissent jamais, et de traitements souvent plus lents que sur une seule machine bien utilisée.

La recherche décrit ce décalage. Baziotis, Kang et Mendis constatent qu'une grande part du travail réel en data science tourne sur une seule machine, avec du code ad hoc, et que les frameworks distribués n'ont pas été conçus pour ces cas ; ils obtiennent des accélérations importantes en réécrivant du code pandas existant, sans toucher à l'infrastructure. Petersohn et ses coauteurs montrent que les problèmes de performance des dataframes apparaissent dès des volumes modérés et tiennent à la façon dont les opérations sont exprimées, pas à la machine.

Mon expérience le confirme à une échelle que peu d'équipes atteignent. J'ai analysé l'intégralité du graphe social de Twitter, plus de cinq cents millions de comptes et vingt-trois milliards de liens ; l'intégralité de la chaîne de transactions Bitcoin, plus de seize milliards de liens ; des années d'échanges BitTorrent portant sur des centaines de millions d'adresses. Tout cela sur une seule machine, en Python. Vos données sont presque certainement plus petites.

Ce que j'apporte. Le regard de quelqu'un qui a déjà rencontré ces problèmes, les a résolus, et ne vend ni infrastructure ni licences. Je sais reconnaître, en lisant votre code et en examinant votre architecture, la part de la lenteur qui vient de l'outillage, celle qui vient du code, et celle, rare, qui vient réellement du volume.

Où va le temps, où va l'argent

Les gains de performance en data science viennent rarement de la puissance de calcul. Ils viennent de la façon dont le code est écrit : boucles là où une opération vectorisée suffirait, jointures qui recalculent ce qui pourrait être conservé, types de données qui multiplient l'empreinte mémoire par dix, lecture intégrale de fichiers dont trois colonnes servent. Le passage de pandas à Polars, la compilation d'un noyau avec Numba, ou la réécriture de dix lignes critiques apportent des ordres de grandeur d'amélioration de la performance — à condition de savoir où les appliquer, et d'utiliser ces outils comme ils sont conçus : du code pandas traduit ligne à ligne vers Polars ne gagne rien.

Côté infrastructure, les enquêtes convergent : Flexera rapporte en 2026 que 85 % des organisations considèrent la gestion des coûts cloud comme un défi majeur et estiment gaspiller 29 % de leurs dépenses d'infrastructure. Le cloud à la demande est rentable pour une charge irrégulière et ruineux pour une charge continue. Pour beaucoup d'équipes, une machine dédiée, achetée et amortie sur plusieurs années, coûte moins que six mois d'abonnement, tient dans un placard, et ne dépend d'aucun fournisseur. Pour d'autres, c'est l'inverse. L'arbitrage se fait sur votre profil de charge réel, pas sur des principes.

Ce que j'apporte. Je forme des équipes à la performance Python depuis 2011, et ma formation « Python haute performance » est née de mes propres traitements à grande échelle. Je lis un profil d'exécution, je reconnais les motifs qui coûtent, et je sais décider entre optimiser l'existant, migrer une section, compiler, réécrire, ou changer d'infrastructure. Je sais aussi dire quand il ne faut rien faire.

Comment je procède

L'audit dure trois à cinq jours selon le périmètre. Je ne réécris pas votre code et je ne dimensionne pas votre infrastructure à votre place : j'établis un diagnostic et je donne à votre équipe les moyens d'agir.

• Cadrage avec le responsable : les traitements qui posent problème, leur fréquence, leur coût actuel, ce qu'un gain changerait pour l'activité.
• Revue du code des traitements critiques : structures de données, types, ordre des opérations, formats de fichiers, usage des bibliothèques.
• Revue de l'architecture : ce qui tourne où, pourquoi, et ce que ça coûte.
• Sessions avec l'équipe sur les traitements identifiés, pour localiser ensemble où le temps et la mémoire partent et vérifier les hypothèses sur vos données.
• Analyse du profil de charge avec vous : volumes actuels et prévisibles, régularité, contraintes réelles.

Ce que vous recevez

Un rapport de constats et de recommandations : les causes de lenteur identifiées, classées par rapport entre effort et gain attendu ; les endroits où une migration vers Polars, une compilation Numba ou une réécriture est justifiée, et ceux où elle ne l'est pas ; une position argumentée sur l'infrastructure — conserver, réduire, changer, ou acheter — avec les ordres de grandeur de coût sur plusieurs années ; et un plan d'action que l'équipe exécute elle-même. Si le plan demande des compétences que l'équipe n'a pas encore, je le dis, et une formation ciblée peut prendre le relais.

Conseil récurrent

Après un audit, les gains se perdent parfois : nouveaux cas d'usage, nouvelles dépendances, code écrit dans l'urgence, et la facture qui remonte sans qu'on sache pourquoi. Une demi-journée à une journée par mois permet de vérifier que les choix retenus tiennent, d'arbitrer les nouveaux, et de repérer une dérive avant qu'elle ne coûte.

Pour qui

Les équipes data science, data engineering et R&D de PME, d'ETI et de startups en croissance, dont les traitements Python — pandas, NumPy, scikit-learn — sont devenus trop lents ou trop coûteux pour l'activité qu'ils soutiennent, ou qui s'apprêtent à investir dans une plateforme distribuée et veulent un avis indépendant avant de signer.

Pourquoi moi

Directeur de recherche à Inria, je fais de l'analyse de données à grande échelle depuis plus de vingt ans, en Python, sur des problèmes de recherche où la reproductibilité compte autant que la vitesse. J'ai aussi été adjoint du CTO d'une startup, puis fondateur d'une autre : je sais ce que coûte une infrastructure surdimensionnée à une entreprise qui compte chaque euro, et je sais qu'un serveur amorti sur sept ans est parfois le meilleur investissement data qu'elle fera.

Mon parcours et mes recherches →

Diagnostic préalable

Avant toute chose, un appel d'une heure, gratuit et sans engagement, pour comprendre votre situation et vérifier que je peux vous être utile. S'il y a matière, un diagnostic d'une à deux journées : cadrage avec le responsable, revue rapide d'un ou deux traitements représentatifs, restitution orale et recommandations écrites. Il conclut sur ce qui mérite un audit, une formation, ou rien.