Python

Python n’est pas un produit que l’on achète et que l’on installe. C’est un langage, et les questions qu’il pose ne ressemblent à aucune de celles que l’on se pose devant un outil : il n’y a ni licence à arbitrer, ni facture à surveiller, ni éditeur à interroger.

La bonne question n’est donc pas de savoir s’il faut faire du Python. C’est de savoir où il a sa place dans une chaîne de données, et surtout où il n’en a pas, parce que le mettre au mauvais endroit crée une dépendance dont on se libère difficilement.

La première est le connecteur que personne ne vend. Une interface obscure, un fournisseur qui ne publie qu’un espace de dépôt de fichiers, un format d’échange propre à votre secteur, un portail public sans accès programmatique. Aucun outil du marché ne couvrira cela, et quelques dizaines de lignes suffisent souvent.

La deuxième est la transformation que SQL exprime mal. Analyser du texte libre, rapprocher des noms d’entreprises écrits différemment, appliquer un algorithme itératif, découper des documents. Le SQL peut parfois y parvenir au prix d’une requête que personne ne relira ; ici, quinze lignes lisibles font le travail.

La troisième est l’apprentissage automatique et tout ce qui touche aux modèles de langage. Prévision, classification, détection d’anomalies, extraction d’informations depuis des documents : c’est le terrain historique de Python, avec un écosystème que rien n’égale.

Ces trois cas ont un point commun : il n’existe pas d’alternative raisonnable. C’est le critère que nous appliquons.

Remplacer des transformations SQL. C’est le cas le plus fréquent, parce que l’équipe qui sait faire du Python trouve naturel de charger les données, de les manipuler et de les réécrire. Cela fonctionne, et cela produit une chaîne que personne d’autre ne peut lire, sans tests, sans documentation, sans dépendances explicites entre les étapes. La même logique écrite avec dbt est lisible par tout analyste sachant écrire du SQL, testée, documentée et ordonnée automatiquement. Le calcul se fait en outre dans l’entrepôt, prévu pour cela.

Remplacer un ordonnanceur. On commence par une tâche planifiée qui appelle un script, puis on ajoute une reprise sur erreur, un journal, un envoi d’alerte, une gestion des dépendances entre traitements. Au bout d’un an, on a écrit un mauvais Airflow, sans interface, sans historique et sans possibilité de rejouer une seule journée.

Remplacer un outil de restitution. Un graphique produit par un script est une image figée. Le besoin métier, lui, consiste presque toujours à filtrer, comparer, remonter à la ligne. Un outil décisionnel fait cela nativement, et l’utilisateur ne dépend plus de quelqu’un pour relancer le script.

Écrire le script représente une petite part du travail. Ce qui coûte, c’est tout ce qui vient après, et que l’on découvre au premier incident.

L’environnement d’abord. Un script dépend de bibliothèques dont les versions évoluent. Sans versions figées ni environnement reproductible, il fonctionne sur le poste de celui qui l’a écrit et nulle part ailleurs. C’est la cause numéro un des traitements qui tombent après un changement de poste ou de serveur.

Les secrets ensuite. Les mots de passe et clés d’accès écrits en clair dans le fichier sont d’une banalité affligeante, et ils finissent dans un dépôt de code, parfois public.

Le comportement en cas d’échec enfin. Que se passe-t-il si l’interface distante ne répond pas, si le script est relancé deux fois, s’il s’interrompt au milieu ? Un traitement de production doit pouvoir être relancé sans dupliquer les données et signaler son échec à quelqu’un.

S’ajoute à cela la question du carnet de notes, qui n’est pas un format d’exécution : l’ordre des cellules ne garantit rien et l’état dépend de ce qui a été lancé avant. Il sert à explorer, pas à produire.

Le point de bascule est simple à énoncer : à partir du moment où quelqu’un d’autre que l’auteur dépend du résultat, ce n’est plus un script, c’est un logiciel, et cela demande le soin correspondant.

Nous écrivons les connecteurs que personne ne vend, pour aller chercher la donnée là où aucun outil ne va, et nous les livrons versionnés, testés et orchestrés plutôt que déposés sur un serveur.

Nous industrialisons des scripts existants devenus critiques : environnement reproductible, secrets sortis du code, reprise sur erreur, alertes, et documentation suffisante pour que le départ de leur auteur ne soit pas un événement.

Nous construisons enfin les traitements d’intelligence artificielle et d’extraction documentaire, en gardant à l’esprit ce que nous vous dirons dès le premier échange : la moitié des besoins exprimés comme des projets Python se traitent mieux avec un outil existant, et nous préférons vous le dire avant que vous ne payiez le développement.

Quand Python est-il vraiment nécessaire dans une chaîne de données ?

Dans trois situations, et le critère commun est l’absence d’alternative raisonnable. Le connecteur que personne ne vend, pour une interface obscure ou un format propre à un secteur. La transformation que SQL exprime mal : analyse de texte libre, rapprochement de noms écrits différemment, algorithme itératif, découpage de documents. Et l’apprentissage automatique avec tout ce qui touche aux modèles de langage, terrain historique du langage.

Faut-il faire ses transformations de données en Python ou en SQL ?

En SQL dans la grande majorité des cas. Charger les données en Python, les manipuler puis les réécrire fonctionne, mais produit une chaîne que personne d’autre ne peut lire, sans tests, sans documentation et sans dépendances explicites entre les étapes. La même logique écrite avec dbt est lisible par tout analyste sachant écrire du SQL, testée, documentée et ordonnée automatiquement, et le calcul se fait dans l’entrepôt, prévu pour cela.

Qu’est-ce qui sépare un script Python d’un traitement de production ?

L’environnement reproductible avec des versions de bibliothèques figées, sans quoi le script fonctionne sur le poste de son auteur et nulle part ailleurs. Les secrets sortis du code, car les mots de passe écrits en clair finissent dans un dépôt. Et le comportement en cas d’échec : un traitement doit pouvoir être relancé sans dupliquer les données et signaler son échec à quelqu’un. Le point de bascule est simple : dès que quelqu’un d’autre que l’auteur dépend du résultat, ce n’est plus un script mais un logiciel.

Peut-on mettre un carnet de notes Python en production ?

Ce n’est pas un format d’exécution. L’ordre des cellules ne garantit rien et l’état dépend de ce qui a été lancé avant, ce qui rend le résultat non reproductible. Le carnet sert à explorer et à mettre au point ; ce qui compte doit ensuite être versionné, testé et déclenché par un ordonnanceur.

Faut-il écrire son propre ordonnanceur en Python ?

Non. On commence par une tâche planifiée qui appelle un script, puis on ajoute une reprise sur erreur, un journal, une alerte, une gestion des dépendances. Au bout d’un an, on a écrit un mauvais Airflow, sans interface, sans historique et sans possibilité de rejouer une seule journée. Mieux vaut orchestrer les scripts avec un outil prévu pour cela.

• dbt, pour les transformations qui n’ont pas besoin de Python.
• Airflow, pour orchestrer les scripts au lieu de réécrire un ordonnanceur.
• n8n, quand l’automatisation peut se faire sans écrire de code.
• MCP, pour brancher un assistant sur vos outils métier.

Sources — documentation officielle de l’éditeur, consultée le 22 août 2026 : environnements virtuels, gestion des dépendances.