Partie 2: communiquer à partir de données

1 Introduction

Une partie essentielle du travail du data scientist consiste à synthétiser l’information que contient ses jeux de données afin de distinguer ce qui relève du signal, sur lequel il pourra se concentrer, et ce qui relève du bruit inhérent à tout jeu de données. Dans le travail du data scientist, lors d’une phase exploratoire, il y a donc un aller-retour constant entre information synthétique et jeu de données désagrégé. Il est ainsi essentiel de savoir synthétiser l’information dans un jeu de données avant d’en saisir la structure, cette dernière pouvant ensuite guider les exploitations ultérieures, pour une phase de modélisation ou de correction de données (détection d’anomalies ou de mauvaises remontées de données).

Nous avons déjà exploré une partie essentielle de ce travail, à savoir la construction de statistiques descriptives pertinentes et fiables. Néanmoins, si on se contentait de présenter l’information en utilisant des sorties brutes issues du combo groupby et agg sur un DataFrame Pandas, notre connaissance des données serait assez limitée. La mise en oeuvre de tableaux stylisés à partir de great tables constituait déjà un progrès dans cette démarche mais, en vérité, notre cerveau se représente l’information de manière beaucoup plus intuitive par le biais de visualisations graphiques simples que dans un tableau.

1.1 La visualisation des données, une part essentiel du travail de communication

En tant qu’humains, nos capacités cognitives étant limitées, nous ne pouvons appréhender qu’une information limitée là où l’ordinateur est capable de traiter de grands volumes d’information. En tant que data scientist, cela signifie qu’utiliser nos compétences informatiques et statistiques pour obtenir des représentations synthétiques de nos nombreux jeux de données est essentiel pour être en mesure de répondre à nos besoins opérationnels ou scientifiques. L’ensemble des méthodes et des outils qui constituent la boîte à outil des data scientists vise à simplifier l’appréhension puis l’exploitation de jeux de données dont le volume dépasse nos capacités cognitives.

Ceci nous entraîne vers la question de la visualisation des données, un ensemble d’outils et de principes pour représenter de manière synthétique des faits stylisés ou contextualiser une donnée individuelle. La visualisation de données est l’art et la science de représenter visuellement des informations complexes et abstraites à l’aide d’éléments visuels. Son objectif principal est de synthétiser l’information présente dans un ensemble de données afin de faciliter la compréhension des enjeux de celle-ci pour une analyse ultérieure. La visualisation de données permet, entre autres, de mettre en évidence des tendances, des corrélations ou des anomalies qui pourraient être difficiles voire impossibles à saisir simplement en examinant des données brutes, ces dernières nécessitant une certaine mise en contexte pour porter du sens.

La visualisation de données joue un rôle crucial dans le processus d’analyse de données en fournissant des moyens visuels pour explorer, interpréter et communiquer des informations. Elle facilite la communication entre experts de la données, décideurs et grand public, en permettant aux derniers de bénéficier du travail rigoureux des premiers pour donner sens aux données sans la connaissance des subtilités conceptuelles qui ont permis de synthétiser l’information contenue dans celle-ci.

1.2 La place de la visualisation dans le processus de valorisation de la donnée

La visualisation des données n’est pas restreinte à la phase finale d’un projet, c’est à dire à la phase de communication de résultats à une audience qui n’a pas accès à la donnée ou n’a pas les moyens de la valoriser. La visualisation intervient à toutes les étapes du processus de valorisation de la donnée. Il s’agit d’ailleurs d’un travail essentiel pour trouver comment basculer de l’enregistrement, un instantané d’un phénomène, à une donnée, un enregistrement qui a une valeur parce qu’il porte une information en tant que telle ou lorsqu’il est combiné avec d’autres enregistrements.

Le travail quotidien du data scientist consiste à regarder un jeu de données sous toutes ses coutures pour identifier les axes prioritaires d’extraction de valeur. Savoir rapidement quelles statistiques représenter, et comment, est essentiel pour gagner du temps sur cette partie exploratoire. Il s’agit principalement d’un travail de communication envers soi-même qui peut se permettre d’être brouillon car il s’agit de dégrossir le travail avant de polir certains angles. L’enjeu à ce niveau du processus est de ne pas manquer une dimension qui pourrait être porteuse de valeur.

Le travail de communication réellement chronophage intervient plutôt lorsqu’on communique à une audience ayant un accès limité à des données, ne connaissant pas bien les sources, ayant un temps d’attention limité ou n’ayant pas des compétences quantitatives. Ces publics ne peuvent se satisfaire d’une sortie brute comme un DataFrame dans un notebook ou un graphique produit en quelques secondes avec la méthode plot de Pandas. Il convient de s’adapter à leurs attentes, qui évoluent, et aux outils qu’ils connaissent, d’où la place de plus en plus importante prise par les sites web de data visualisations.

2 Communiquer, une ouverture au data storytelling

La visualisation de données a ainsi une place à part dans l’ensemble des techniques de la data science. Elle intervient à tous les stades du processus de production de la donnée, de l’amont (analyse exploratoire) à l’aval (restitution à des publics multiples) et peut, si elle est bien construite, permettre de saisir de manière intuitive la structure des données ou les enjeux de son analyse.

Art de la synthèse, la visualisation de données est également l’art de raconter une histoire et peut même, lorsqu’elle est bien construite, prétendre au rang de production artistique. La dataviz est un métier en soi dont on trouve de plus en plus de praticiens dans les titres de presse ou dans des entreprises spécialisées (Datawrapper par exemple).

Sans prétendre construire des visualisations aussi riches que celles des spécialistes, tout data scientist se doit d’être en mesure de pouvoir produire rapidement quelques visualisations permettant de synthétiser l’information présente dans les jeux de données à sa disposition. Une visualisation claire et lisible tout en restant simple peut être meilleure qu’un discours pour faire passer un message.

De même qu’un discours, une visualisation est une communication pour laquelle un locuteur - la personne construisant la visualisation - cherche à transmettre une information à un récepteur - éventuellement la même personne que le locuteur puisqu’une visualisation peut être construite pour soi-même dans une analyse exploratoire. Il n’est donc pas surprenant qu’à l’époque où la sémiologie occupait une part importante dans les débats intellectuels, notamment autour de la figure de Roland Barthes, le concept de sémiologie graphique ait émergé autour de la personne de Jacques Bertin (Bertin 1967; Palsky 2017). Cette approche permet de réfléchir sur la pertinence des techniques mises en oeuvre pour transmettre un message graphique et de nombreuses visualisations, si elles suivaient quelques-unes de ces règles, pourraient être améliorées à peu de frais.

Eric Mauvière, statisticien français héritier de l’école de la sémiologie graphique de Bertin, propose d’excellents contenus sur le sujet. Certaines des présentations qu’il a pu faire, notamment celle pour le SSPHub présentées dans la Note 2.1 devraient être visionnées dans toutes les formations de data science tant elles évoquent les nombreux écueils rencontrés par les data scientists.

Un exemple de deux visualisations faites sur le même jeu de données par Eric Mauvière, voir Note 2.1

Note 2.1: Une conférence d’Eric Mauvière sur le sujet

html`${slides_button}`

slides = "https://minio.lab.sspcloud.fr/lgaliana/ssphub/replay/20240229-dataviz-mauviere/conf_ssphub_icem7.pdf"

slides_button = html`<p class="text-center">
  <a class="btn btn-primary btn-lg cv-download" href="${slides}" target="_blank">
    <i class="fa-solid fa-file-arrow-down"></i>&ensp;Télécharger les slides
  </a>
</p>`

3 Communiquer, une ouverture à la mise à disposition d’applications

L’objectif de ce cours est d’introduire aux principaux outils et à la démarche que doivent adopter les data scientists face à divers jeux de données. Il devient néanmoins de plus en plus commun pour les data scientists de développer et mettre à disposition des applications interactives proposant un certain nombre d’explorations et de visualisations automatisées de données. Il s’agit d’enjeux plus avancés que ce cours mais qui constituent souvent un point d’entrée vers la data science pour des publics proches des data scientists, notamment les data engineers, les data analysts ou les statisticiens.

Nous évoquerons certains des outils privilégiés pour faire cela, notamment les écosystèmes liés aux applications web et aux outils Javascript. Ce besoin, devenu assez standard pour les data scientists, fait la passerelle avec la mise en production, l’enjeu principal d’un cours de 3e année de l’ENSAE construit par Romain Avouac et moi-même (site web du cours ensae-reproductibilite.github.io/). Le présent site web, par exemple, est construit selon ce principe grâce à des outils permettant d’exécuter de manière reproductible du Python sur des serveurs standardisés et ensuite mettre à disposition ce code par le biais d’un site web.

4 L’écosystème Python

Pour revenir à notre cours, nous présenterons dans cette partie quelques librairies et visualisations basiques en Python permettant de partir sur de bonnes bases. Les ressources pour approfondir et progresser dans l’art de la visualisation ne manquent pas, comme cet ouvrage (Wilke 2019).

4.1 Les packages de visualisations de données

L’écosystème Python pour la visualisation de données est très riche et très éclaté. Il est possible de consacrer des livres entiers à celui-ci (Dale 2022). Python propose de nombreuses librairies pour produire de manière rapide et relativement simple des visualisations de données¹.

Les librairies graphiques se distinguent principalement en deux familles:

• Les librairies de représentations figées. Celles-ci ont plutôt vocation à être intégrées dans des publications figées type PDF ou documents texte. Nous présenterons principalement Matplotlib et Seaborn mais il en existe d’autres, en pleine émergence, comme Plotnine, l’adaptation de ggplot2 à l’écosystème Python.
• Les librairies de représentations réactives. Celles-ci sont adaptées à des représentations web et offrent la possibilité aux lecteurs d’agir sur la représentation graphique affichée. Les librairies qui proposent ces fonctionnalités reposent généralement sur JavaScript, l’écosystème du développement web, pour lequel elles offrent un point d’entrée via Python. Nous évoquerons principalement Plotly et Folium dans cette famille mais il existe de nombreux autres frameworks dans ce domaine².

Il est tout à fait possible de faire des visualisations sophistiquées avec une chaine de bout en bout Python puisqu’il s’agit d’un langage couteau-suisse dont l’écosystème est très riche. Néanmoins, Python n’est pas la panacée et il peut parfois être utile, pour obtenir un produit fini parfaitement poli, de finaliser le travail avec d’autres langages, comme Javascript pour les visualisations réactives ou QGIS pour le travail cartographique. Ce cours donnera les outils minimums pour faire un travail rapide et plaisant mais le diable étant dans les détails, il ne faut pas s’arcbouter à vouloir utiliser Python pour tout et n’importe quoi.

Dans le domaine de la visualisation, ce cours adopte le parti pris d’explorer quelques librairies centrales à partir d’un nombre restreint d’exemples en répliquant des graphiques qu’on peut trouver sur le site d’open data de la mairie de Paris. La meilleure école pour la visualisation restant la pratique sur des jeux de données, il est recommandé d’explorer la richesse de l’écosystème de l’open data pour expérimenter des visualisations.

4.2 Les applications de visualisation

Cette partie du cours se focalise sur des représentations synthétiques simples. Elle n’évoque pas (encore ?) la construction d’applications de visualisation de données où un ensemble de graphiques se mettent à jour de manière synchrone en fonction d’actions d’utilisateurs.

Ceci dépasse en effet le cadre d’un cours d’introduction car construire ces applications impliquent de maîtriser des concepts plus complexes comme l’interaction entre une page web et un serveur, d’avoir des rudiments de connaissance en Linux, etc. Les concepts nécessaires à la compréhension de ces outils sont au coeur du cours de 3e année “Mise en production de projets de data science” que Romain Avouac donnons en 3e année d’ENSAE.

Néanmoins, comme la valorisation de données sous une forme applicative est très commune, il il est utile a minima d’évoquer la dualité entre sites statiques et applications dynamiques afin de donner les bons gestes et pointer vers les outils adéquat. Dans le monde de l’applicatif, il est important de distinguer le front (la page visible par les utilisateurs de l’application) du back office (le moteur qui effectue des actions en fonction des paramètres choisis par l’utilisateur de la page).

Il existe principalement deux paradigmes pour faire interagir ces deux éléments. La distinction principale entre ces deux approches est qu’elles s’appuient sur des serveurs différents. Un site statique repose sur un serveur web là où Streamlit s’appuie sur serveur classique en backend. La différence principale entre ces deux types de serveurs réside principalement dans leur fonction et leur utilisation:

• Un serveur web est spécifiquement conçu pour stocker, traiter et livrer des pages web (le front) aux clients. Cela inclut des fichiers HTML, CSS, JavaScript, images, etc. Les serveurs web écoutent les requêtes HTTP/HTTPS provenant des navigateurs des utilisateurs et y répondent en envoyant les données demandées. Cela n’empêche pas d’avoir des étapes complexes de valorisation de données, ni de la réactivité en embarquant du Javascript dans l’application mais les étapes de traitement en Python sont faites en amont de la mise à disposition de l’application. Pour les utilisateurs de Python, il existe plusieurs constructeurs de sites statiques avant une mise à disposition par le biais d’un hébergement sur Github Pages. Les deux écosystèmes les plus communs sont Quarto Markdown et Django, le premier étant plus simple d’usage et de maintenance que le second. Ce site, par exemple, est construit grâce à Quarto ce qui assure la reproductibilité des exemples présentés et une mise en forme ergonomique et paramétrable des résultats.
  
• Un serveur backend classique est conçu pour effectuer des opérations en réponse à un front, en l’occurrence une page web. Dans le contexte d’une application construite avec Python, il s’agit d’un serveur avec l’environnement Python ad hoc pour exécuter le code nécessaire à répondre à toute action d’un utilisateur de l’application. Le code est exécuté à la volée et non une fois pour toute comme dans l’approche précédente. Il s’agit donc d’un paradigme pouvant permettre plus de complexité applicative mais représentant un défi supplémentaire lors de la phase de mise en production. Dans l’écosystème Python, les deux principaux outils permettant de construire de telles applications sont Streamlit et Dash, le premier étant plus rapide à mettre en oeuvre que le second. Plus récemment, l’écosystème équivalent dominant en R, Shiny a été adapté en Python par Posit.

Fait-on toujours du tkinter ?

Les écosystèmes présentés ci-dessus pour les applications réactives sont des frameworks web. Ils se distinguent des clients lourds comme tkinter, l’outil historique pour faire des interfaces graphiques. Outre l’aspect plus rudimentaire des interfaces tkinter par rapport à celles de Streamlit, Dash ou Shiny, il existe des raisons fortes pour privilégier ces derniers à tkinter.

Ce dernier est un client lourd. Autrement dit, il est adhérent à un système d’exploitation et à des installations de packages en amont du fonctionnement de l’interface. Il est bien sûr possible de rendre portable celle-ci mais, comme cela est développé dans le cours de mise en production, il y a de nombreuses raisons pour lesquelles cette approche peut provoquer des erreurs ou des bugs inattendus. Les frameworks web présentent l’intérêt de simplifier cette mise à disposition en dissociant le front (des pages HTML et du CSS) du back (du code Python). Ils se sont donc imposés naturellement même si on retrouve encore beaucoup de ressources en ligne datées sur le développement d’applications avec tkinter.

En ce qui concerne la construction d’applications, le premier réflexe à avoir est: “ai-je besoin de faire une application réactive ou un site statique ne suffit-il pas ?”. Ce dernier étant beaucoup plus facile à mettre en oeuvre et ayant une charge de maintenance minimale, c’est souvent un choix rationnel. S’il devient complexe de faire un site statique, par exemple parce qu’ils impliquent des calculs sophistiqués qu’il serait complexe de mettre en oeuvre sans compétences JavaScript, on peut alors se poser la question de la séparation entre front et back en reportant les calculs vers une API, construite par exemple par le biais de FastAPI. Il s’agit, par exemple, d’une méthode pratique pour mettre à disposition un modèle de machine learning comme le dernier chapitre de la partie modélisation l’évoquera. Si la mise en oeuvre d’une API est compliquée ou bien est un bazooka pour tuer une mouche, alors on pourra aller vers une application réactive du type de Streamlit.

Encore une fois, la construction d’une application fait appel à des concepts qui dépassent un niveau introductif en Python. Avoir conscience des bons réflexes peut néanmoins faire économiser un temps non négligeable en évitant de patauger dans la semoule à cause d’un mauvais choix initial.

4.3 Résumé de cette partie

Pour en revenir au contenu de cette partie après cet aparté, celle-ci est divisée en deux et chaque chapitre est lui-même dual, selon qu’on s’intéresse aux représentations figées ou dynamiques :

• Dans un premier temps, nous évoquerons des représentations graphiques standards (histogrammes, diagrammes en barre…) pour synthétiser certaines informations quantitatives ;
  • Les représentations fixes reposeront sur Pandas, Matplotlib et Seaborn
  • Les graphiques réactifs s’appuieront sur Plotly
• Dans un deuxième temps, nous présenterons les représentations cartographiques:
  • Les cartes figées à partir de Geopandas ou de plotnine
  • Les cartes réactives avec Folium (adaptation Python de la librairie Leaflet.js)

4.4 Références utiles

La visualisation de données est un art qui s’apprend, au début, principalement par la pratique. Néanmoins, il n’est pas évident de produire des visualisations lisibles et ergonomiques et il est utile de s’inspirer d’exemples de spécialistes (les grands titres de presse disposent d’excellentes visualisations).

Voici quelques ressources utiles sur ces sujets :

• Datawrapper propose un excellent blog sur les bonnes pratiques de visualisation, notamment avec les articles de Lisa Charlotte Muth. Je recommande notamment cet article sur les couleurs ou celui-ci sur les textes ;
• Le blog d’Eric Mauvière ;
• “La Sémiologie graphique de Jacques Bertin a cinquante ans” ;
• Les visualisations trending sur Observable ;
• Le New York Times (les rois de la dataviz) revient tous les ans sur les meilleures visualisations de l’année dans la veine du data scrollytelling. Voir par exemple la rétrospective de l’année 2022.

Quelques ressources sur Streamlit ou Dash

Outre le cours de 3e année de l’ENSAE, le lab de data science de l’Insee a construit de nombreux tutoriels pour s’appropier les écosystèmes d’applications réactives en Python qui sont l’un des produits les plus attractifs de l’écosystème Python.

Voici par exemple un tutoriel 101 très détaillé sur Streamlit permettant de créer une application type Yuka sur les données de l’openfoodfacts. Un autre tutoriel pas à pas construit par l’Insee est consacré à streamlit et vise à proposer la construction d’un tableau de bord du trafic aérien.

Et quelques références supplémentaires, citées dans cette introduction :

Bertin, Jacques. 1967. Sémiologie graphique. Paris: Mouton/Gauthier-Villars.

Dale, Kyran. 2022. Data Visualization with Python and JavaScript. " O’Reilly Media, Inc.".

Palsky, Gilles. 2017. « La Sémiologie graphique de Jacques Bertin a cinquante ans ». Visions carto (en ligne).

Wilke, Claus O. 2019. Fundamentals of data visualization: a primer on making informative and compelling figures. O’Reilly Media.

Informations additionnelles

environment files have been tested on.

Latest built version: 2025-05-26

Python version used:

'3.12.6 | packaged by conda-forge | (main, Sep 30 2024, 18:08:52) [GCC 13.3.0]'

Package	Version
affine	2.4.0
aiobotocore	2.15.1
aiohappyeyeballs	2.4.3
aiohttp	3.10.8
aioitertools	0.12.0
aiosignal	1.3.1
alembic	1.13.3
altair	5.4.1
aniso8601	9.0.1
annotated-types	0.7.0
anyio	4.9.0
appdirs	1.4.4
archspec	0.2.3
asttokens	2.4.1
attrs	24.2.0
babel	2.17.0
bcrypt	4.2.0
beautifulsoup4	4.12.3
black	24.8.0
blinker	1.8.2
blis	1.3.0
bokeh	3.5.2
boltons	24.0.0
boto3	1.35.23
botocore	1.35.23
branca	0.7.2
Brotli	1.1.0
cachetools	5.5.0
cartiflette	0.1.9
Cartopy	0.24.1
catalogue	2.0.10
cattrs	24.1.3
certifi	2024.8.30
cffi	1.17.1
charset-normalizer	3.3.2
click	8.1.7
click-plugins	1.1.1
cligj	0.7.2
cloudpathlib	0.21.1
cloudpickle	3.0.0
colorama	0.4.6
comm	0.2.2
commonmark	0.9.1
conda	24.9.1
conda-libmamba-solver	24.7.0
conda-package-handling	2.3.0
conda_package_streaming	0.10.0
confection	0.1.5
contextily	1.6.2
contourpy	1.3.0
cryptography	43.0.1
cycler	0.12.1
cymem	2.0.11
cytoolz	1.0.0
dask	2024.9.1
dask-expr	1.1.15
databricks-sdk	0.33.0
dataclasses-json	0.6.7
debugpy	1.8.6
decorator	5.1.1
Deprecated	1.2.14
diskcache	5.6.3
distributed	2024.9.1
distro	1.9.0
docker	7.1.0
duckdb	1.1.1
en_core_web_sm	3.8.0
entrypoints	0.4
et_xmlfile	2.0.0
exceptiongroup	1.2.2
executing	2.1.0
fastexcel	0.14.0
fastjsonschema	2.21.1
fiona	1.10.1
Flask	3.0.3
folium	0.19.6
fontawesomefree	6.6.0
fonttools	4.54.1
frozendict	2.4.4
frozenlist	1.4.1
fsspec	2024.9.0
geographiclib	2.0
geopandas	1.0.1
geoplot	0.5.1
geopy	2.4.1
gitdb	4.0.11
GitPython	3.1.43
google-auth	2.35.0
graphene	3.3
graphql-core	3.2.4
graphql-relay	3.2.0
graphviz	0.20.3
great-tables	0.12.0
greenlet	3.1.1
gunicorn	22.0.0
h11	0.16.0
h2	4.1.0
hpack	4.0.0
htmltools	0.6.0
httpcore	1.0.9
httpx	0.28.1
httpx-sse	0.4.0
hyperframe	6.0.1
idna	3.10
imageio	2.37.0
importlib_metadata	8.5.0
importlib_resources	6.4.5
inflate64	1.0.1
ipykernel	6.29.5
ipython	8.28.0
itsdangerous	2.2.0
jedi	0.19.1
Jinja2	3.1.4
jmespath	1.0.1
joblib	1.4.2
jsonpatch	1.33
jsonpointer	3.0.0
jsonschema	4.23.0
jsonschema-specifications	2025.4.1
jupyter-cache	1.0.0
jupyter_client	8.6.3
jupyter_core	5.7.2
kaleido	0.2.1
kiwisolver	1.4.7
langchain	0.3.25
langchain-community	0.3.9
langchain-core	0.3.61
langchain-text-splitters	0.3.8
langcodes	3.5.0
langsmith	0.1.147
language_data	1.3.0
lazy_loader	0.4
libmambapy	1.5.9
locket	1.0.0
loguru	0.7.3
lxml	5.4.0
lz4	4.3.3
Mako	1.3.5
mamba	1.5.9
mapclassify	2.8.1
marisa-trie	1.2.1
Markdown	3.6
markdown-it-py	3.0.0
MarkupSafe	2.1.5
marshmallow	3.26.1
matplotlib	3.9.2
matplotlib-inline	0.1.7
mdurl	0.1.2
menuinst	2.1.2
mercantile	1.2.1
mizani	0.11.4
mlflow	2.16.2
mlflow-skinny	2.16.2
msgpack	1.1.0
multidict	6.1.0
multivolumefile	0.2.3
munkres	1.1.4
murmurhash	1.0.13
mypy_extensions	1.1.0
narwhals	1.41.0
nbclient	0.10.0
nbformat	5.10.4
nest_asyncio	1.6.0
networkx	3.3
nltk	3.9.1
numpy	2.1.2
opencv-python-headless	4.10.0.84
openpyxl	3.1.5
opentelemetry-api	1.16.0
opentelemetry-sdk	1.16.0
opentelemetry-semantic-conventions	0.37b0
orjson	3.10.18
OWSLib	0.33.0
packaging	24.1
pandas	2.2.3
paramiko	3.5.0
parso	0.8.4
partd	1.4.2
pathspec	0.12.1
patsy	0.5.6
Pebble	5.1.1
pexpect	4.9.0
pickleshare	0.7.5
pillow	10.4.0
pip	24.2
platformdirs	4.3.6
plotly	5.24.1
plotnine	0.13.6
pluggy	1.5.0
polars	1.8.2
preshed	3.0.10
prometheus_client	0.21.0
prometheus_flask_exporter	0.23.1
prompt_toolkit	3.0.48
protobuf	4.25.3
psutil	6.0.0
ptyprocess	0.7.0
pure_eval	0.2.3
py7zr	0.22.0
pyarrow	17.0.0
pyarrow-hotfix	0.6
pyasn1	0.6.1
pyasn1_modules	0.4.1
pybcj	1.0.6
pycosat	0.6.6
pycparser	2.22
pycryptodomex	3.23.0
pydantic	2.11.5
pydantic_core	2.33.2
pydantic-settings	2.9.1
Pygments	2.18.0
PyNaCl	1.5.0
pynsee	0.1.8
pyogrio	0.10.0
pyOpenSSL	24.2.1
pyparsing	3.1.4
pyppmd	1.1.1
pyproj	3.7.0
pyshp	2.3.1
PySocks	1.7.1
python-dateutil	2.9.0
python-dotenv	1.0.1
python-magic	0.4.27
pytz	2024.1
pyu2f	0.1.5
pywaffle	1.1.1
PyYAML	6.0.2
pyzmq	26.2.0
pyzstd	0.16.2
querystring_parser	1.2.4
rasterio	1.4.3
referencing	0.36.2
regex	2024.9.11
requests	2.32.3
requests-cache	1.2.1
requests-toolbelt	1.0.0
retrying	1.3.4
rich	14.0.0
rpds-py	0.25.1
rsa	4.9
ruamel.yaml	0.18.6
ruamel.yaml.clib	0.2.8
s3fs	2024.9.0
s3transfer	0.10.2
scikit-image	0.24.0
scikit-learn	1.5.2
scipy	1.13.0
seaborn	0.13.2
setuptools	74.1.2
shapely	2.0.6
shellingham	1.5.4
six	1.16.0
smart-open	7.1.0
smmap	5.0.0
sniffio	1.3.1
sortedcontainers	2.4.0
soupsieve	2.5
spacy	3.8.4
spacy-legacy	3.0.12
spacy-loggers	1.0.5
SQLAlchemy	2.0.35
sqlparse	0.5.1
srsly	2.5.1
stack-data	0.6.2
statsmodels	0.14.4
tabulate	0.9.0
tblib	3.0.0
tenacity	9.0.0
texttable	1.7.0
thinc	8.3.6
threadpoolctl	3.5.0
tifffile	2025.5.24
toolz	1.0.0
topojson	1.9
tornado	6.4.1
tqdm	4.67.1
traitlets	5.14.3
truststore	0.9.2
typer	0.16.0
typing_extensions	4.12.2
typing-inspect	0.9.0
typing-inspection	0.4.1
tzdata	2024.2
Unidecode	1.4.0
url-normalize	2.2.1
urllib3	2.2.3
uv	0.7.8
wasabi	1.1.3
wcwidth	0.2.13
weasel	0.4.1
webdriver-manager	4.0.2
websocket-client	1.8.0
Werkzeug	3.0.4
wheel	0.44.0
wordcloud	1.9.3
wrapt	1.16.0
xgboost	2.1.1
xlrd	2.0.1
xyzservices	2024.9.0
yarl	1.13.1
yellowbrick	1.5
zict	3.0.0
zipp	3.20.2
zstandard	0.23.0

View file history

md`Ce fichier a été modifié __${table_commit.length}__ fois depuis sa création le ${creation_string} (dernière modification le ${last_modification_string})`

creation = d3.min(
  table_commit.map(d => new Date(d.Date))
)

last_modification = d3.max(
  table_commit.map(d => new Date(d.Date))
)

creation_string = creation.toLocaleString("fr", {
  "day": "numeric",
  "month": "long",
  "year": "numeric"
})

last_modification_string = last_modification.toLocaleString("fr", {
  "day": "numeric",
  "month": "long",
  "year": "numeric"
})

html`<div>${git_history_table}</div>`

html`<div>${git_history_plot}</div>`

SHA	Date	Author	Description
cbe6459f	2024-11-12 07:24:15	lgaliana	Revoir quelques abstracts
593106f1	2024-09-21 14:39:32	lgaliana	Abstract également
1ebb5eed	2024-09-21 14:23:43	lgaliana	Translate the introduction to visualisation
72d44dd6	2024-09-21 12:50:38	lgaliana	Force build for pandas chapters
d02515b4	2024-04-27 21:32:25	Lino Galiana	Eléments sur les applis & évaluation (#495)
005d89b8	2023-12-20 17:23:04	Lino Galiana	Finalise l’affichage des statistiques Git (#478)
1f23de28	2023-12-01 17:25:36	Lino Galiana	Stockage des images sur S3 (#466)
09654c71	2023-11-14 15:16:44	Antoine Palazzolo	Suggestions Git & Visualisation (#449)
80823022	2023-08-25 17:48:36	Lino Galiana	Mise à jour des scripts de construction des notebooks (#395)
3bdf3b06	2023-08-25 11:23:02	Lino Galiana	Simplification de la structure 🤓 (#393)
5d4874a8	2023-08-11 15:09:33	Lino Galiana	Pimp les introductions des trois premières parties (#387)
2dc82e7b	2022-10-18 22:46:47	Lino Galiana	Relec Kim (visualisation + API) (#302)
8e5edba6	2022-09-02 11:59:57	Lino Galiana	Ajoute un chapitre dask (#264)
a4e24263	2022-06-16 19:34:18	Lino Galiana	Improve style (#238)
12965bac	2022-05-25 15:53:27	Lino Galiana	:launch: Bascule vers quarto (#226)
66a52761	2021-11-23 16:13:20	Lino Galiana	Relecture partie visualisation (#181)
4cdb759c	2021-05-12 10:37:23	Lino Galiana	:sparkles: :star2: Nouveau thème hugo :snake: :fire: (#105)
0a0d0348	2021-03-26 20:16:22	Lino Galiana	Ajout d’une section sur S3 (#97)
5ac3cbee	2020-09-28 18:59:24	Lino Galiana	Continue la partie graphiques (#54)
8ed01f45	2020-09-24 21:27:29	Lino Galiana	Ajout d’une partie visualisation

git_history_table = Inputs.table(
  table_commit,
  {
    format: {
      SHA: x => md`[${x}](${github_repo}/commit/${x})`,
      Description: x => md`${replacePullRequestPattern(x, github_repo)}`,
      /*Date: x => x.toLocaleString("fr", {
        "month": "numeric",
        "day": "numeric",
        "year": "numeric"
        })
      */
    }
  }
)

git_history_plot = Plot.plot({
  marks: [
    Plot.ruleY([0], {stroke: "royalblue"}),
    Plot.dot(
          table_commit,
          Plot.pointerX({x: (d) => new Date(d.date), y: 0, stroke: "red"})),
    Plot.dot(table_commit, {x: (d) => new Date(d.Date), y: 0, fill: "royalblue"})
  ]
})

function replacePullRequestPattern(inputString, githubRepo) {
    // Use a regular expression to match the pattern #digit
    var pattern = /#(\d+)/g;

    // Replace the pattern with ${github_repo}/pull/#digit
    var replacedString = inputString.replace(pattern, '[#$1](' + githubRepo + '/pull/$1)');

    return replacedString;
}

github_repo = "https://github.com/linogaliana/python-datascientist"

table_commit = {

// Get the HTML table by its class name
var table = document.querySelector('.commit-table');

// Check if the table exists
if (table) {
    // Initialize an array to store the table data
    var dataArray = [];

    // Extract headers from the first row
    var headers = [];
    for (var i = 0; i < table.rows[0].cells.length; i++) {
        headers.push(table.rows[0].cells[i].textContent.trim());
    }

    // Iterate through the rows, starting from the second row
    for (var i = 1; i < table.rows.length; i++) {
        var row = table.rows[i];
        var rowData = {};

        // Iterate through the cells in the row
        for (var j = 0; j < row.cells.length; j++) {
            // Use headers as keys and cell content as values
            rowData[headers[j]] = row.cells[j].textContent.trim();
        }

        // Push the rowData object to the dataArray
        dataArray.push(rowData);
    }
  }

  return dataArray

}

// Get the element with class 'git-details'
{
  var gitDetails = document.querySelector('.commit-table');

  // Check if the element exists
  if (gitDetails) {
      // Hide the element
      gitDetails.style.display = 'none';
  }
}

Plot = require('@observablehq/plot@0.6.12/dist/plot.umd.min.js')

Notes de bas de page

1. To be honest, for a long time, Python was a bit less enjoyable in this regard compared to R, which benefits from the indispensable library ggplot2.

   Not built on the grammar of graphics, the main graphical library in Python, Matplotlib, is more cumbersome to use than ggplot2.

   seaborn, which we will present, simplifies graphical representation somewhat, but again, it is difficult to find something more flexible and universal than ggplot2.

   The library plotnine aims to provide a similar implementation to ggplot for Python users. Its development is worth following.

2. In this regard, I highly recommend keeping up with data visualization news on the platform Observable, which tends to bring together the communities of dataviz specialists and data analysts. The library Plot could become a new standard in the coming years, a sort of intermediate between ggplot and d3.