Créer un dossier Python robuste - La méthode pro expliquée

Créer un dossier en Python paraît simple, mais la méthode choisie change vite dès qu’un script doit fonctionner sur plusieurs machines, gérer des chemins imbriqués ou rester stable si le répertoire existe déjà. Je vais te montrer les approches les plus fiables avec pathlib et os, puis les cas concrets qui comptent vraiment quand on automatise un export, un projet de données ou un petit outil interne. L’idée est d’aller droit au code, sans perdre les nuances qui évitent les bugs inutiles.

Les deux méthodes que je privilégie

Pour créer un répertoire, je pars presque toujours sur pathlib. La lecture du code est meilleure, les chemins sont plus faciles à composer, et l’ensemble s’intègre bien avec les autres opérations sur les fichiers. La documentation officielle de Python précise que Path.mkdir() crée un nouveau dossier et que parents=True reproduit le comportement de mkdir -p en créant les dossiers intermédiaires manquants.

En face, os.makedirs() fait très bien le travail, surtout si ton code manipule déjà des chaînes ou s’appuie beaucoup sur le module os. Je le garde volontiers pour les scripts courts ou pour maintenir un vieux projet, mais pour un nouveau code je préfère la version objet de pathlib.

from pathlib import Path

Path("rapports").mkdir()

Cette version crée un dossier simple dans le répertoire courant. Si le chemin doit traverser plusieurs niveaux, j’utilise une forme explicite :

from pathlib import Path

Path("exports/clients/2026").mkdir(parents=True, exist_ok=True)

Avec os, l’équivalent est correct, mais moins fluide à lire quand le script grandit :

import os

os.makedirs("exports/clients/2026", exist_ok=True)

La vraie différence n’est pas la puissance brute. Elle est dans la lisibilité et dans la façon dont ce code va s’enchaîner avec le reste du projet. C’est ce qui permet ensuite de choisir proprement l’outil adapté au contexte.

Choisir entre pathlib et os selon le contexte

Je ne conseille pas le même outil dans tous les cas. Le bon choix dépend surtout de la taille du script, de l’existant et du niveau de clarté que tu veux garder dans six mois. Quand on écrit du code destiné à durer, ce détail compte plus qu’il n’y paraît.

En pratique, je choisis pathlib dès que je contrôle le code source. Je reviens à os surtout quand je dois m’aligner sur un code déjà établi, pas par préférence technique. Une fois ce choix posé, le vrai sujet devient la gestion des chemins déjà présents et des erreurs usuelles.

Gérer les dossiers parents et les erreurs sans improviser

Le point le plus utile, en production, c’est souvent parents=True et exist_ok=True. Sans eux, un simple dossier intermédiaire manquant peut casser tout le script. Avec eux, le code devient plus idempotent, c’est-à-dire capable de s’exécuter plusieurs fois sans provoquer d’échec inutile quand le répertoire cible existe déjà.

Je fais aussi attention au comportement réel de exist_ok=True. La documentation officielle rappelle que l’option évite l’erreur si le dossier est déjà là, mais elle ne transforme pas un fichier en dossier. Si un chemin existant pointe vers autre chose qu’un répertoire, l’exception reste normale, et c’est préférable ainsi.

from pathlib import Path

dossier = Path("logs/app/2026/06")
dossier.mkdir(parents=True, exist_ok=True)

Ce code est robuste pour un pipeline, un export automatique ou un service qui génère des artefacts. Si le dossier existe déjà, il continue sans bruit. Si un élément du chemin manque, il est créé. Si une autorisation bloque l’opération, Python lève une erreur claire qu’il faut gérer au niveau supérieur.

Je garde aussi en tête le paramètre mode, surtout sur Unix. Il est combiné avec le umask du processus, donc la permission effective n’est pas toujours celle que tu imagines en lisant le code. En pratique, je préfère miser sur une politique de droits cohérente au niveau du système plutôt que sur une valeur magique dans chaque script. Le passage suivant montre justement comment j’applique ça sur des cas concrets.

Exemples concrets pour un projet réel

Les exemples les plus utiles ne sont pas les plus spectaculaires. Ce sont ceux qu’on peut reprendre tels quels dans un projet de build, de scraping, de reporting ou d’automatisation interne.

Créer un dossier simple dans le répertoire courant

from pathlib import Path

Path("exports").mkdir(exist_ok=True)

Je pars souvent de ce modèle pour un outil local ou un petit script de préparation. Il est clair, court et facile à maintenir.

Créer une arborescence complète

from pathlib import Path

base = Path("data")
(base / "brut" / "2026" / "06").mkdir(parents=True, exist_ok=True)

Ce format est particulièrement pratique quand le script organise les sorties par lot, par client ou par date. Le chemin se lit comme une intention, pas comme une suite de concaténations fragiles.

Créer un dossier dans le répertoire personnel

from pathlib import Path

dossier = Path.home() / "mes_exports"
dossier.mkdir(exist_ok=True)

Je trouve ce modèle plus propre que d’écrire un chemin absolu en dur. Il s’adapte mieux à la machine de l’utilisateur et évite les surprises liées à l’environnement local.

Lire aussi : π en Python - Le guide complet pour des calculs précis

Travailler avec un chemin relatif au script

from pathlib import Path

racine = Path(__file__).resolve().parent
sortie = racine / "build" / "assets"
sortie.mkdir(parents=True, exist_ok=True)

Ce cas est très utile pour les projets de déploiement ou les scripts appelés depuis différents emplacements. La nuance est importante : le dossier courant n’est pas toujours le dossier du script. Quand on ignore cette différence, on finit vite avec des fichiers créés au mauvais endroit.

Ces exemples couvrent la majorité des usages courants. Le reste, en réalité, concerne surtout les pièges d’exécution et les problèmes d’environnement, qui sont souvent plus coûteux que la ligne de code elle-même.

Les pièges qui cassent un script quand il passe en production

Le premier piège, c’est le répertoire courant. Un script lancé depuis un terminal, un cron, un conteneur ou un IDE ne part pas forcément du même endroit. Si tu écris Path("data") sans réfléchir au contexte, tu peux créer un dossier au mauvais niveau sans même t’en rendre compte.

Le deuxième piège, c’est la vérification préalable avec exists(). Beaucoup de scripts font d’abord un test, puis un mkdir. En pratique, cette logique ouvre une petite fenêtre de course entre les deux opérations. Je préfère souvent laisser mkdir(..., exist_ok=True) faire le travail directement, puis gérer l’exception seulement si elle signifie quelque chose de réel pour le métier.

Le troisième piège concerne les chemins fournis par l’utilisateur. Si tu acceptes un nom de dossier depuis un formulaire, un argument CLI ou une API, il faut contrôler ce qui est autorisé. Un chemin mal validé peut sortir du périmètre prévu, créer une structure inattendue ou provoquer une erreur de permission. Dans les scripts exposés à des entrées externes, je valide toujours la base cible avant d’écrire quoi que ce soit.

Enfin, les contraintes de système restent très concrètes : droits insuffisants, noms réservés sous Windows, dossier déjà verrouillé par un autre processus, ou chemin trop profond. Dans ces cas-là, Python ne fait que signaler le problème. C’est à toi de décider si tu dois réessayer, journaliser l’échec ou arrêter le traitement proprement. C’est ce cadre-là qui rend le code fiable sur la durée.

Ce que je garde en tête pour des scripts vraiment robustes

Quand j’écris un script qui doit durer, je vise d’abord un comportement prévisible. Je crée le dossier au début du traitement, je le fais de manière idempotente, et je garde les chemins sous forme de Path autant que possible. Ce trio simple évite une grande partie des bugs bêtes, surtout dans les scripts d’automatisation et les outils internes.

Je fais aussi un choix de lisibilité assumé : un chemin doit raconter ce que le code va produire. Si je dois relire le script trois mois plus tard, je veux comprendre immédiatement où vont les fichiers, pourquoi le dossier existe, et ce qui se passe s’il est déjà là. C’est exactement pour ça que je privilégie pathlib dans un code neuf.

Si tu veux aller plus loin, la bonne suite logique n’est pas de compliquer la création du dossier, mais d’enchaîner avec la gestion des fichiers, des sous-dossiers et des chemins relatifs au projet. À ce stade, créer un répertoire n’est plus une fin en soi : c’est la première brique d’un flux de fichiers propre et portable.