Python open file - Évitez les pièges et codez proprement

Derrière l’expression python open file, il y a surtout une question très concrète : comment ouvrir un fichier sans perdre de données, lire son contenu proprement, puis écrire exactement ce qu’il faut au bon endroit. En Python, la réponse tient souvent en quelques lignes, mais le détail du mode, de l’encodage et du chemin change tout. Je vais aller à l’essentiel, avec des exemples simples et les pièges que je vois revenir le plus souvent en backend.

L’essentiel à retenir sur l’ouverture d’un fichier

En Python, open() retourne un objet fichier. C’est lui qui donne accès à la lecture, à l’écriture et aux autres opérations de base. La forme la plus courante ressemble à open(fichier, mode, encoding=None), et en pratique je recommande presque toujours de rendre le mode explicite plutôt que de le laisser implicite.

Le réflexe le plus sain reste d’utiliser un gestionnaire de contexte avec with. Concrètement, cela garantit que le fichier sera fermé automatiquement à la fin du bloc, même si une exception est levée. C’est plus court qu’un couple try/finally, et surtout plus sûr pour éviter les descripteurs laissés ouverts ou les écritures incomplètes.

with open("notes.txt", "r", encoding="utf-8") as fichier:
    contenu = fichier.read()
    print(contenu)

Je garde aussi un autre réflexe simple : si le fichier est petit et textuel, pathlib.Path rend souvent le code plus lisible. On peut lire directement avec Path("notes.txt").read_text(encoding="utf-8") ou écrire avec write_text(). Ce n’est pas une nouvelle logique, juste une syntaxe plus compacte. Une fois ce socle clair, le vrai sujet devient le mode d’ouverture.

Choisir le bon mode selon ce que l’on veut faire

Si je dois simplifier au maximum, j’utilise r pour lire, w pour produire un fichier neuf, a pour un journal ou un historique, et rb/wb dès que le contenu n’est plus du texte. Cette discipline évite déjà une bonne partie des bugs. Le reste se joue surtout dans la façon de lire les données.

Lire du texte sans erreurs d’encodage

Pour lire un petit fichier, read() reste la solution la plus directe. Le piège, c’est de l’utiliser par réflexe sur des fichiers volumineux. Si le contenu dépasse quelques dizaines de mégaoctets, je préfère presque toujours lire ligne par ligne ou par blocs. La raison est simple : un appel à read() sans taille charge tout en mémoire.

with open("rapport.txt", "r", encoding="utf-8") as fichier:
    contenu = fichier.read()
    print(contenu)

Pour un fichier de log, un CSV ou un export texte long, je préfère l’itération directe sur le fichier. C’est plus économe, souvent plus rapide à raisonner, et bien mieux adapté aux traitements backend.

with open("journal.log", "r", encoding="utf-8") as fichier:
    for ligne in fichier:
        print(ligne.rstrip())

Quand je veux garder le contrôle sur la mémoire, je lis aussi par blocs de 8192 octets, ce qui est un bon point de départ dans beaucoup de cas. C’est moins élégant qu’un simple read(), mais beaucoup plus raisonnable pour les fichiers larges ou les flux continus.

with open("gros_fichier.txt", "r", encoding="utf-8") as fichier:
    bloc = fichier.read(8192)
    while bloc:
        traiter(bloc)
        bloc = fichier.read(8192)

Sur l’encodage, je reste prudent : UTF-8 est le bon choix par défaut, mais il ne corrige pas un fichier qui a réellement été encodé autrement. Si je sais qu’un fichier vient d’un système ancien ou d’un export bureautique, je préfère déclarer l’encodage explicitement plutôt que de laisser Python deviner. Une lecture propre prépare la suite : écrire sans casser l’existant.

Écrire sans écraser ce qui compte

En écriture, le choix du mode est encore plus sensible. Avec w, Python crée le fichier s’il n’existe pas, mais il le tronque s’il existe déjà. Ce comportement est utile pour générer un export, un rapport ou un fichier de sortie totalement neuf. Il est catastrophique si l’on voulait seulement ajouter une ligne de plus.

with open("export.txt", "w", encoding="utf-8") as fichier:
    fichier.write("ligne 1\n")
    fichier.write("ligne 2\n")

Pour un journal applicatif ou des événements à empiler, a est plus adapté. Le fichier reste intact, et tout ce qui est écrit vient se placer à la fin. C’est simple, mais il faut rester attentif au risque de doublons si le même bloc est écrit plusieurs fois par erreur.

with open("app.log", "a", encoding="utf-8") as fichier:
    fichier.write("Nouvel événement\n")

Je me méfie aussi d’un détail souvent oublié : writelines() n’ajoute pas automatiquement de saut de ligne. Si l’on lui passe trois chaînes sans \n, elles seront collées. Dans un fichier texte, je préfère donc soit boucler avec write(), soit préparer mes lignes avec les séparateurs déjà inclus.

lignes = ["alpha\n", "beta\n", "gamma\n"]

with open("sortie.txt", "w", encoding="utf-8") as fichier:
    fichier.writelines(lignes)

Quand il faut vraiment modifier un fichier existant au milieu, je déconseille de bricoler directement en r+ sauf cas très maîtrisé. En pratique, il est souvent plus fiable de lire, de réécrire dans un fichier temporaire, puis de remplacer l’original. C’est plus propre, et beaucoup moins fragile dès que les données deviennent critiques. Les erreurs de production commencent souvent là où le code veut être trop malin.

Gérer les cas qui cassent en production

La plupart des incidents de manipulation de fichiers ne viennent pas de open() lui-même, mais du contexte autour : chemin relatif, droits insuffisants, encodage incorrect ou mauvais type de fichier. Un script qui fonctionne depuis le terminal peut échouer dans un service, un conteneur ou une tâche planifiée simplement parce que le répertoire courant a changé.

from pathlib import Path

chemin = Path("data") / "config.txt"

try:
    contenu = chemin.read_text(encoding="utf-8")
except FileNotFoundError:
    print("Fichier introuvable")
except PermissionError:
    print("Accès refusé")
except UnicodeDecodeError:
    print("Encodage invalide pour ce fichier")

Pour limiter les surprises, j’aime construire les chemins avec pathlib plutôt qu’avec des chaînes bricolées à la main. C’est plus lisible, plus portable entre Windows, Linux et macOS, et plus simple à maintenir quand l’arborescence du projet évolue. Si le script dépend de son propre emplacement, je pars souvent du dossier du fichier Python lui-même plutôt que du répertoire de lancement.

Je garde aussi une frontière nette entre texte et binaire. Une image, un PDF, une archive ZIP ou un exécutable ne se traite pas en mode texte. Dans ce cas, j’ouvre en rb ou wb, et je manipule des bytes. C’est moins confortable à lire qu’un fichier texte, mais c’est exactement ce qu’il faut pour ne pas corrompre les données. Cette distinction vaut vraiment la peine d’être respectée.

Les réflexes que je garde pour un code de fichiers propre

Quand je relis du code qui touche aux fichiers, je cherche toujours les mêmes signes de maturité : un mode explicite, un encodage déclaré, un chemin clair et un bloc with. Si ces quatre points sont présents, le reste du code devient plus facile à faire évoluer, à tester et à relire six mois plus tard.

• Utiliser with pour fermer le fichier sans dépendre d’un appel manuel à close().
• Déclarer l’encodage, surtout dès qu’il s’agit de texte partagé entre plusieurs environnements.
• Choisir le mode avec intention, plutôt que de laisser w ou a s’installer par habitude.
• Éviter read() par défaut sur les gros fichiers et préférer l’itération ou les blocs.
• Tester les cas d’échec : fichier manquant, permission refusée, mauvaise encodage, chemin erroné.

Si je devais garder une seule règle, ce serait celle-ci : choisir explicitement le mode, l’encodage et le chemin, puis laisser with gérer la fermeture. Avec ces réflexes, lire ou écrire un fichier en Python reste simple, lisible et suffisamment robuste pour un script comme pour un service backend.