Un script Python commence souvent comme un petit fichier sans prétention.

On veut renommer des fichiers, appeler une API, traiter un CSV, générer un rapport ou automatiser une tâche pénible. Au début, tout va bien. Puis le script grandit. Il lit de vrais fichiers. Il manipule des données clients. Il utilise une clé API. Il écrit dans un dossier partagé. Il tourne sur un serveur.

Et là, ce n’est plus “juste un petit script”. C’est un outil qui peut casser, fuir une donnée ou faire une action au mauvais endroit.

Cette checklist sert à éviter ça.

Elle ne transforme pas un script en application parfaite. Elle aide simplement à poser les bonnes questions avant de lancer du Python dans un contexte réel.

À qui s’adresse cette checklist ?

Elle est utile si vous :

• apprenez Python avec des projets pratiques ;
• automatisez des fichiers ou rapports ;
• utilisez des API ;
• manipulez des données sensibles ;
• écrivez des scripts internes ;
• préparez une montée en compétence en cybersécurité ;
• voulez éviter les erreurs classiques avant de partager un script.

L’objectif n’est pas de faire peur. L’objectif est de faire mieux que “ça marche chez moi”.

Règle de base : un script qui marche n’est pas forcément un script fiable

Un script peut fonctionner sur votre machine et rester dangereux.

Exemples :

• une clé API écrite en clair dans le fichier ;
• un chemin de dossier mal configuré ;
• une suppression de fichiers sans confirmation ;
• des erreurs masquées ;
• des logs qui exposent des données ;
• une dépendance installée sans version ;
• un fichier de sortie qui écrase des données existantes.

La fiabilité commence quand on anticipe les erreurs, pas quand on espère qu’elles n’arriveront pas.

Checklist rapide avant exécution

1. Le script a-t-il un objectif clair ?

Un bon script doit pouvoir être résumé en une phrase.

Mauvais exemple :

Ce script traite des fichiers.

Meilleur exemple :

Ce script lit les fichiers CSV d’un dossier, supprime les lignes vides et génère un rapport de synthèse sans modifier les fichiers originaux.

Si vous ne pouvez pas expliquer clairement ce que fait le script, vous ne devriez pas encore l’utiliser sur de vraies données.

2. Les fichiers originaux sont-ils protégés ?

Avant de modifier ou déplacer des fichiers, posez-vous une question :

Est-ce que je peux revenir en arrière ?

Bonnes pratiques :

• travailler sur une copie ;
• créer un dossier de sortie séparé ;
• ne jamais modifier l’original au premier passage ;
• ajouter un mode simulation ;
• sauvegarder la liste des actions réalisées.

3. Le script possède-t-il un mode dry-run ?

Un mode dry-run permet d’afficher ce que le script ferait, sans le faire réellement.

Exemple :

python nettoyage.py --dossier exports/ --dry-run

Le script indique alors :

[SIMULATION] 24 fichiers seraient analysés
[SIMULATION] 3 fichiers seraient déplacés
[SIMULATION] Aucun fichier n’a été modifié

C’est l’une des protections les plus simples et les plus utiles.

4. Les chemins sont-ils contrôlés ?

Un chemin mal géré peut faire travailler le script au mauvais endroit.

À vérifier :

• le dossier existe ;
• le script ne pointe pas vers la racine du système ;
• les chemins sont affichés avant action ;
• les chemins relatifs sont compris ;
• l’utilisateur confirme les actions sensibles.

Utilisez des outils comme pathlib pour manipuler les chemins plus proprement.

5. Les secrets sont-ils absents du code ?

Ne mettez jamais directement dans le script :

• clé API ;
• mot de passe ;
• token ;
• identifiant de service ;
• secret de webhook ;
• chaîne de connexion sensible.

Mauvais exemple :

API_KEY = "sk-xxxxxxxxxxxxxxxx"

Meilleur principe :

• utiliser une variable d’environnement ;
• charger un fichier .env non versionné ;
• utiliser un coffre de secrets si le contexte le justifie ;
• vérifier que .env est dans .gitignore.

6. Le fichier .gitignore est-il présent ?

Si le projet est versionné, ajoutez au minimum :

.env
.venv/
__pycache__/
*.log
*.sqlite3
exports/
output/

Le but est d’éviter d’envoyer par erreur des secrets, fichiers générés, logs ou données sensibles dans un dépôt.

7. Les dépendances sont-elles isolées ?

Utilisez un environnement virtuel.

Exemple :

python -m venv .venv

Puis activez-le et installez les packages nécessaires.

Un projet Python sérieux ne doit pas dépendre d’un environnement global bricolé au fil du temps.

8. Les dépendances sont-elles listées ?

Créez un fichier :

requirements.txt

Exemple :

requests==2.32.3
python-dotenv==1.0.1

Versionner les dépendances aide à relancer le projet plus tard et réduit les surprises.

9. Les erreurs sont-elles visibles ?

Ne masquez pas toutes les erreurs avec un except trop large.

Mauvais exemple :

try:
    lancer_traitement()
except:
    pass

Ce code enterre les problèmes.

Meilleur exemple :

try:
    lancer_traitement()
except FileNotFoundError as erreur:
    print(f"Fichier introuvable : {erreur}")
except PermissionError as erreur:
    print(f"Permission refusée : {erreur}")

Un script fiable doit échouer clairement.

10. Les logs exposent-ils des données sensibles ?

Les logs sont utiles, mais dangereux s’ils affichent tout.

À éviter dans les logs :

• mots de passe ;
• tokens ;
• clés API ;
• données personnelles ;
• contenus confidentiels ;
• fichiers sensibles complets.

Préférez des messages comme :

24 lignes traitées, 2 erreurs détectées

plutôt que :

Token utilisé : sk-xxxxxxxx

11. Les entrées utilisateur sont-elles validées ?

Si le script demande une valeur à l’utilisateur, vérifiez-la.

Exemples :

• le dossier existe ;
• le fichier a la bonne extension ;
• la valeur numérique est dans une plage acceptable ;
• l’URL commence bien par https:// si nécessaire.

Ne faites pas confiance à une entrée simplement parce qu’elle vient d’un collègue ou de vous-même.

12. Le script écrase-t-il des fichiers ?

Avant d’écrire un fichier de sortie, vérifiez s’il existe déjà.

Stratégies possibles :

• refuser d’écraser ;
• ajouter un suffixe ;
• demander confirmation ;
• créer un dossier daté ;
• sauvegarder l’ancien fichier.

13. Le script a-t-il un journal d’actions ?

Pour un script qui modifie ou déplace des fichiers, gardez une trace :

• fichier traité ;
• action réalisée ;
• destination ;
• date ;
• erreur éventuelle.

C’est utile pour comprendre ce qui s’est passé si un résultat semble étrange.

14. Le script limite-t-il son périmètre ?

Un script doit agir seulement sur ce qui est nécessaire.

À éviter :

• scanner tout le disque ;
• modifier tous les fichiers d’un dossier sans filtre ;
• envoyer toutes les données à une API ;
• donner trop de droits au script.

Le principe est simple : moins le script peut faire de dégâts, mieux c’est.

15. Les appels API sont-ils contrôlés ?

Si le script appelle une API, vérifiez :

• timeout défini ;
• gestion des erreurs HTTP ;
• limitation du nombre de requêtes ;
• absence de secrets dans l’URL ;
• stockage minimal des réponses ;
• validation du contenu reçu.

Un appel API qui fonctionne une fois peut échouer demain. Prévoyez l’échec.

16. Les données envoyées à un service externe sont-elles nécessaires ?

Avant d’envoyer un texte, un fichier ou une donnée à une API, demandez :

Est-ce que cette donnée doit vraiment sortir de mon environnement ?

Si non, ne l’envoyez pas.

Si oui, minimisez :

• envoyez moins de champs ;
• masquez les identifiants ;
• supprimez les données sensibles ;
• conservez seulement ce qui est nécessaire.

17. Le script est-il documenté ?

Un fichier README.md simple suffit souvent.

Il doit indiquer :

• ce que fait le script ;
• comment l’installer ;
• comment le lancer ;
• les paramètres disponibles ;
• les fichiers modifiés ;
• les limites connues.

Un script non documenté devient vite inutilisable, même par son auteur.

18. Le script est-il testable sur de fausses données ?

Créez un dossier tests_fichiers ou exemples avec de petites données sans risque.

Un bon script doit pouvoir être testé sans toucher aux vrais fichiers.

19. Les actions dangereuses demandent-elles confirmation ?

Pour toute action irréversible ou sensible, demandez confirmation :

• suppression ;
• déplacement massif ;
• écrasement ;
• envoi externe ;
• publication ;
• modification de données.

Une confirmation humaine ne règle pas tout, mais elle évite beaucoup d’accidents.

20. Le script respecte-t-il le principe du moindre privilège ?

N’exécutez pas un script avec plus de droits que nécessaire.

Si un script peut fonctionner sans compte administrateur, ne le lancez pas en administrateur.

Si une clé API peut être limitée en lecture seule, ne lui donnez pas un accès complet.

21. Le script affiche-t-il un résumé final ?

À la fin, affichez :

• nombre d’éléments traités ;
• nombre de succès ;
• nombre d’erreurs ;
• emplacement des fichiers générés ;
• éventuelles actions ignorées.

Un script qui se termine en silence est moins pratique à contrôler.

22. Le code est-il assez lisible pour être relu ?

Si vous ne comprenez plus votre script deux semaines plus tard, il est trop fragile.

À améliorer :

• noms de variables clairs ;
• fonctions courtes ;
• commentaires utiles ;
• suppression du code mort ;
• découpage logique.

23. Le script contient-il des valeurs codées en dur ?

Évitez de disperser partout :

• chemins ;
• URLs ;
• noms de fichiers ;
• seuils ;
• paramètres.

Regroupez-les en haut du fichier ou dans un fichier de configuration.

24. Le script a-t-il été relu avec un scénario d’échec ?

Demandez-vous :

• que se passe-t-il si le dossier est vide ?
• si le fichier n’existe pas ?
• si l’API ne répond pas ?
• si la connexion coupe ?
• si un fichier existe déjà ?
• si une valeur est mal formée ?

Un script fiable n’est pas celui qui marche quand tout va bien. C’est celui qui réagit proprement quand quelque chose se passe mal.

25. Le script est-il prêt à être partagé ?

Avant de l’envoyer à quelqu’un :

• retirez les secrets ;
• ajoutez un README ;
• ajoutez des exemples ;
• précisez les limites ;
• testez sur un environnement propre ;
• vérifiez les dépendances ;
• ajoutez un mode dry-run si besoin.

Mini-lab : ajouter un mode dry-run à un script Python

Voici un exemple simple de script qui affiche ce qu’il ferait avant d’agir.

Objectif

Créer un script qui liste les fichiers .txt d’un dossier. En mode normal, il les déplacerait dans un dossier Textes. En mode dry-run, il affiche seulement l’action prévue.

Code exemple

from pathlib import Path
import argparse
import shutil


def organiser_textes(dossier_source, dry_run=False):
    dossier_source = Path(dossier_source)
    dossier_destination = dossier_source / "Textes"

    if not dossier_source.exists():
        print("Le dossier source n'existe pas.")
        return

    fichiers_txt = list(dossier_source.glob("*.txt"))

    if not fichiers_txt:
        print("Aucun fichier .txt trouvé.")
        return

    if not dry_run:
        dossier_destination.mkdir(exist_ok=True)

    for fichier in fichiers_txt:
        destination = dossier_destination / fichier.name

        if dry_run:
            print(f"[SIMULATION] {fichier} serait déplacé vers {destination}")
        else:
            shutil.move(str(fichier), str(destination))
            print(f"[OK] {fichier} déplacé vers {destination}")

    print(f"Traitement terminé : {len(fichiers_txt)} fichier(s) concerné(s).")


if __name__ == "__main__":
    parser = argparse.ArgumentParser(description="Organise les fichiers texte d'un dossier.")
    parser.add_argument("dossier", help="Dossier à analyser")
    parser.add_argument("--dry-run", action="store_true", help="Affiche les actions sans les exécuter")

    args = parser.parse_args()
    organiser_textes(args.dossier, args.dry_run)

Lancer en simulation

python organiser_textes.py exemples/ --dry-run

Lancer réellement

python organiser_textes.py exemples/

Pourquoi ce mini-lab est important

Le mode dry-run oblige à penser avant d’agir.

C’est une excellente habitude pour tous les scripts qui :

• déplacent des fichiers ;
• suppriment des éléments ;
• écrivent dans un dossier ;
• appellent une API ;
• modifient des données.

Un débutant qui apprend cette habitude tôt évite beaucoup d’erreurs plus tard.

Kit téléchargeable — Checklist sécurité Python

Vous pouvez copier ce bloc dans un fichier :

checklist-securite-script-python.md

# Checklist sécurité pour script Python

## Objectif du script

- [ ] Le script peut être résumé en une phrase claire.
- [ ] Les fichiers ou données modifiés sont identifiés.
- [ ] Les limites du script sont écrites.

## Données et fichiers

- [ ] Le script travaille sur une copie ou un dossier de test.
- [ ] Les fichiers originaux ne sont pas modifiés au premier passage.
- [ ] Un mode dry-run est disponible pour les actions sensibles.
- [ ] Les fichiers de sortie n’écrasent pas silencieusement des fichiers existants.
- [ ] Un journal d’actions est créé si le script modifie des fichiers.

## Secrets et configuration

- [ ] Aucune clé API n’est écrite dans le code.
- [ ] Les secrets sont chargés depuis l’environnement ou un coffre adapté.
- [ ] Le fichier .env est absent du dépôt.
- [ ] Le .gitignore exclut .env, .venv, logs et fichiers générés.

## Dépendances

- [ ] Le projet utilise un environnement virtuel.
- [ ] Les dépendances sont listées dans requirements.txt.
- [ ] Les versions importantes sont fixées.
- [ ] Les packages inutiles sont supprimés.

## Erreurs et logs

- [ ] Les erreurs ne sont pas masquées par un except trop large.
- [ ] Les messages d’erreur sont compréhensibles.
- [ ] Les logs n’affichent pas de secrets ou données sensibles.
- [ ] Le script affiche un résumé final.

## API et services externes

- [ ] Les appels API ont un timeout.
- [ ] Les erreurs HTTP sont gérées.
- [ ] Les données envoyées sont minimisées.
- [ ] Les réponses externes sont validées avant usage.

## Sécurité d’exécution

- [ ] Le script n’est pas lancé avec plus de droits que nécessaire.
- [ ] Les actions dangereuses demandent confirmation.
- [ ] Le périmètre d’action est limité.
- [ ] Le script a été testé sur de fausses données.

## Documentation

- [ ] Un README explique l’installation.
- [ ] Un exemple d’utilisation est fourni.
- [ ] Les paramètres sont documentés.
- [ ] Les limites connues sont indiquées.

Pour aller plus loin

Si vous voulez apprendre Python avec des projets pratiques, de l’automatisation, des fichiers, des API, de la data, de l’IA et une préparation à la certification TOSA Python, Cyberini propose une formation structurée pour progresser étape par étape.

Découvrir la formation Python

FAQ

Pourquoi sécuriser un simple script Python ?

Parce qu’un script peut manipuler de vrais fichiers, des données sensibles, des clés API ou des actions automatisées. Dès qu’il agit sur un environnement réel, il doit être traité avec sérieux.

Qu’est-ce qu’un mode dry-run ?

Un mode dry-run permet d’afficher les actions prévues sans les exécuter. C’est très utile pour vérifier un script avant qu’il modifie, déplace ou supprime des fichiers.

Faut-il utiliser un environnement virtuel Python ?

Oui, dès qu’un projet utilise des dépendances. L’environnement virtuel isole les packages du projet et rend le script plus facile à relancer ou partager.

Où stocker une clé API dans un script Python ?

Pas directement dans le code. Utilisez une variable d’environnement, un fichier .env non versionné ou un gestionnaire de secrets adapté au contexte.

Un script Python doit-il avoir un README ?

Oui, s’il doit être relancé, partagé ou utilisé par quelqu’un d’autre. Un README simple évite beaucoup d’erreurs d’utilisation.