Préparer son projet

Un projet maintenable permet de retrouver le code, de recréer son environnement et de comprendre où chaque responsabilité se trouve. Une structure légère dès le départ évite qu’un carnet unique devienne le seul endroit où les règles financières sont cachées.

Gérer son projet

Créez un dossier nommé d’après le problème à résoudre, ouvrez-le dans votre éditeur et initialisez Git. Un dépôt distant peut servir de sauvegarde et permettre une revue des changements, même si le projet reste privé.

Quelques fichiers utiles rendent le dépôt explicite :

• README.md décrit l’objectif, les données d’entrée et les commandes usuelles.
• .gitignore exclut les environnements locaux, fichiers temporaires et données privées.
• pyproject.toml déclare Python, les dépendances et la configuration d’outils.
• .pre-commit-config.yaml indique les contrôles automatiques à lancer avant une validation Git.
• uv.lock (si vous utilisez uv) consigne les versions exactes résolues pour l’environnement.

Ces fichiers ne sont pas de la paperasse : ils décrivent comment recréer, vérifier et faire évoluer le modèle. Ils aident aussi un collègue ou un assistant à travailler dans le projet sans deviner ses conventions.

Structure des dossiers

Une structure de départ peut distinguer les calculs réutilisables, les tests et les explorations temporaires :

analyse-rentabilite/
├── README.md
├── pyproject.toml
├── uv.lock
├── .gitignore
├── .pre-commit-config.yaml
├── src/
│   └── rentabilite/
│       ├── __init__.py
│       ├── donnees.py
│       ├── calculs/
│       │   ├── __init__.py
│       │   └── marges.py
│       └── rapports.py
├── tests/
│   ├── test_donnees.py
│   └── calculs/
│       └── test_marges.py
├── examples/
└── notebooks/
    └── exploration.ipynbCopier

Le dossier de tests reprend l’organisation du code afin qu’on sache rapidement où placer le test d’un module. Des projets plus vastes peuvent ajouter un dossier pour les visualisations ou séparer les contrôleurs. Pour un petit modèle, quelques modules suffisent.

Gérer les dépendances

Les bibliothèques externes évoluent : une mise à jour peut apporter des correctifs, mais aussi modifier une interface. Déclarez les dépendances directes et la version de Python prises en charge, puis enregistrez les versions résolues lorsque la reproductibilité est importante.

Un exemple de configuration avec uv :

[project]
name = "analyse-rentabilite"
version = "0.1.0"
requires-python = ">=3.11"
dependencies = ["pandas>=2.2"]

[dependency-groups]
dev = ["pytest>=8", "ruff>=0.6"]Copier

Les versions sont des exemples : choisissez-les selon les versions de Python et les bibliothèques réellement prises en charge par votre projet. Consultez la documentation de uv pour la syntaxe à jour.

Pourquoi choisir un gestionnaire de dépendances ?

pip installe des paquets dans un environnement Python ; il reste parfaitement adapté aux installations simples. Un gestionnaire tel que uv ajoute la résolution des versions, la gestion de l’environnement et un fichier de verrouillage. Un fichier requirements.txt peut aussi figer des versions s’il est préparé à cette fin, mais une simple liste de noms n’explique pas toujours comment résoudre un environnement reproductible.

Avec uv, les commandes de base ressemblent à ceci :

uv sync
uv add pandas
uv add --dev pytest ruff
uv run pytestCopier

Le groupe de développement contient des outils utiles pour modifier le projet, mais qui ne sont pas nécessaires à chaque personne qui exécute le modèle. Si votre équipe choisit un autre gestionnaire, documentez la même chose : comment créer l’environnement, ajouter une dépendance et lancer les vérifications.

Ajouter une dépendance sans alourdir le projet

N’installez une bibliothèque que lorsqu’elle répond à un besoin réel. Les extras permettent parfois d’activer des fonctions optionnelles d’une bibliothèque, par exemple les outils de calcul ou de tracé d’un paquet de données. Après l’ajout, vérifiez le fichier de configuration et le verrouillage des versions, puis relancez les commandes documentées.

Configurer les outils d’analyse statique

Les vérificateurs statiques examinent le code sans exécuter toute l’analyse. Un formateur comme Black rend la mise en page uniforme ; Ruff réunit plusieurs contrôles de style et de pièges courants ; un vérificateur de types comme ty ou mypy contrôle certaines incohérences d’annotations ; Bandit peut repérer des motifs à risque ; Codespell cherche des fautes dans les textes et commentaires.

Commencez par un petit ensemble utile et gardez la configuration dans pyproject.toml. Un avertissement doit être compris : corrigez le code, ou ajoutez une exception locale avec une raison précise plutôt que de désactiver une famille entière de contrôles.

Automatiser les vérifications avant une validation

Le fichier .pre-commit-config.yaml associe des outils aux validations Git. Après l’installation des crochets, les contrôles choisis s’exécutent avant l’enregistrement des changements. Ils peuvent reformater un fichier ou signaler une valeur codée en dur, une faute ou une annotation incohérente.

Un échec n’est pas forcément une erreur du modèle : un formateur peut simplement réindenter le code. Mais l’analyse financière ne doit pas être validée sans examen. Lisez les changements produits par les outils, puis lancez également les tests du modèle.

uv add --dev pre-commit
uv run pre-commit install
uv run pre-commit run --all-filesCopier

Utiliser Git pour suivre les changements

Git conserve l’historique, permet d’examiner les changements et facilite le retour à un état précédent. Chaque enregistrement devrait regrouper des changements liés et avoir un message qui décrit leur intention.

Créer un flux de travail Git

Pour un projet individuel, on peut travailler dans une branche de fonctionnalité puis fusionner après revue. Une équipe peut garder main pour la version stable, develop pour l’intégration et des branches courtes pour les fonctionnalités ou corrections urgentes. Le degré de cérémonial doit rester proportionné à la taille de l’équipe.

Les assistants de programmation peuvent travailler sur une branche séparée. Examinez les changements et les contrôles avant de les intégrer dans la branche que vous utilisez au quotidien.

Ajouter des exceptions Git

Le fichier .gitignore exclut les artefacts générés, les préférences locales et les fichiers temporaires. Il ne remplace pas la prudence : n’ajoutez jamais de secret, de clé d’API ou de données personnelles au dépôt. Pour les fichiers financiers confidentiels, utilisez un stockage autorisé et fournissez des données synthétiques aux tests.

.venv/
__pycache__/
.pytest_cache/
.ipynb_checkpoints/
.DS_Store
.env
*.xlsxCopier

La dernière règle est un choix propre à cet exemple : si le projet doit contenir des classeurs d’exercice non confidentiels, remplacez-la par une règle plus ciblée.

Instructions pour les assistants IA

Un fichier AGENTS.md, CLAUDE.md ou des consignes propres à un éditeur peuvent expliquer l’objectif, les dossiers, les commandes et les conventions du projet. Gardez ces instructions courtes et concrètes. Pour un modèle financier, précisez notamment la définition des ratios, les unités, l’emplacement des calculs et la méthode de vérification.

Si vous n’arrivez pas à décrire la structure en quelques lignes, le projet a peut-être besoin d’une organisation plus claire. Le chapitre Travailler avec un assistant IA détaille ces fichiers et les autres mécanismes d’assistance.

Étape suivante

Une fois le dépôt et l’environnement établis, décidez comment les données vont traverser le modèle. Le chapitre suivant présente les responsabilités de chaque partie : Structurer un modèle.