Exécuter une vérification statique

Une fonction peut sembler correcte avec quelques exemples et pourtant recevoir, en production, une valeur qui provoque une erreur. Les annotations que vous avez ajoutées aux interfaces du paquet depenses permettent à un analyseur statique de repérer certaines incohérences avant l’exécution. Vous allez configurer mypy, vérifier le paquet et apprendre à traiter ses diagnostics de façon ciblée.

Ajouter mypy à la configuration du projet

Mypy lit les annotations de vos modules et compare les types déclarés aux valeurs effectivement manipulées dans le code. Il ne lance pas l’application et ne prouve pas que sa logique métier est correcte : il vérifie une partie des erreurs susceptibles de survenir à l’exécution. Les annotations de variables, de fonctions et de collections ont été présentées dans « Définir les contrats de données » ; ici, vous utilisez ces contrats comme base d’une vérification automatisée.

Installez mypy dans l’environnement de développement du projet, puis ajoutez sa configuration à pyproject.toml. Si ce fichier contient déjà des sections de configuration, conservez-les et ajoutez uniquement la section tool.mypy ci-dessous. Le mode strict active plusieurs vérifications utiles, notamment le signalement des fonctions publiques sans annotation de retour ; il est exigeant et peut révéler des points à traiter dans les modules existants.

[tool.mypy]
python_version = "3.11"
files = ["src/depenses"]
strict = true
show_error_codes = true

La clé files fixe le périmètre par défaut à votre paquet, plutôt que de dépendre du répertoire depuis lequel vous lancez la commande. Vérifiez que python_version correspond à la version réellement ciblée par le projet. La configuration stricte constitue un niveau élevé ; si votre code n’est pas encore prêt à le satisfaire, commencez avec strict désactivé et activez les contrôles progressivement, en conservant le même périmètre.

Lancer la vérification et lire les diagnostics

Depuis la racine du projet, exécutez mypy sur le paquet. La commande échoue avec un code de sortie différent de zéro si l’analyse trouve des erreurs ; vous pouvez donc l’intégrer ensuite à une vérification automatisée. Le nombre de messages et leur texte dépendent du contenu exact des fichiers : considérez la sortie ci-dessous comme un exemple de forme, pas comme un résultat garanti pour votre dépôt.

python -m pip install mypy
python -m mypy src/depenses

Exemple de résultat si aucun diagnostic n’est détecté :
Success: no issues found in 5 source files

Un diagnostic indique généralement un fichier, une ligne, une description et un code entre crochets. Par exemple, un retour de type incompatible signale qu’une valeur renvoyée ne respecte pas le type annoncé. Une incompatibilité d’argument signale que l’appelant transmet une valeur différente de celle attendue par la fonction. Le code d’erreur facilite la recherche dans la documentation de mypy et rend les rapports plus faciles à comparer.

Corriger sans masquer les incohérences

Dans cet outil, les échanges entrants sont décrits par DepenseRecue, tandis que le service utilise le tuple Depense, défini dans modeles.py. Si mypy signale qu’un dictionnaire reçu est utilisé comme un tuple métier, le problème n’est pas résolu en forçant le type : il faut passer par la conversion prévue, depense_depuis_donnees ou vers_depense_metier, selon le sens de l’échange. Les modèles et conversions ont été construits dans « Structurer les échanges entre modules » ; la vérification vous aide maintenant à repérer les endroits où leur contrat n’est pas respecté.

Un autre diagnostic fréquent concerne une valeur optionnelle : une fonction qui peut renvoyer None ne peut pas être traitée sans précaution comme si elle renvoyait toujours un objet. Vérifiez la valeur avant de l’utiliser, ou ajustez le contrat si l’absence n’est réellement pas possible. De même, si un objet est annoté avec un Protocol, vérifiez qu’il fournit bien les attributs et méthodes attendus ; le protocole permet de contrôler le comportement, sans imposer une classe concrète.

Évitez de désactiver globalement un contrôle à la première difficulté. Si une dépendance ou une zone particulière ne peut pas encore être vérifiée, réduisez la portée de l’exception et documentez-en la raison. À chaque correction, relancez mypy sur le paquet entier : une modification de signature peut révéler des appels incohérents dans plusieurs modules. La vérification statique complète les tests, mais ne les remplace pas ; la prochaine section du cours portera sur les tests unitaires du service.

À retenir

• Configurez mypy dans pyproject.toml et définissez explicitement le périmètre analysé.
• Choisissez le niveau de vérification en fonction de l’état du projet ; le mode strict est exigeant.
• Lisez chaque diagnostic comme une indication sur un contrat non respecté, puis corrigez la cause à la source.
• Relancez l’analyse sur tout le paquet après les corrections ; conservez aussi les tests automatisés.