Pydantic v2 et l'outillage : uv, ruff, import-linter

Pydantic v2 : valider aux frontières

La règle implicite du projet : dataclasses à l'intérieur, Pydantic aux frontières — tout ce qui entre (HTTP, sortie LLM, config) passe par un modèle validé :

from pydantic import BaseModel, Field

class StructuredLine(BaseModel):
    sku: str | None = None
    label: str
    quantity: float = Field(gt=0)
    unit_price: float | None = None

Trois usages dans le projet :

1. schémas d'API : FastAPI valide automatiquement les corps de requêtes/réponses ;
2. sortie LLM : le JSON produit par le structurer est validé par un modèle Pydantic — un LLM qui renvoie quantity: -3 explose ici, pas trois couches plus loin (fail loud) ;
3. Settings : pydantic-settings lit l'environnement en objets typés (DJUST_DB_SCHEMA, clés API…) — la config invalide tue le boot, pas la première requête.

uv workspace : le monorepo Python

Chaque module est un package du workspace uv (un pyproject.toml racine + un par package, un seul uv.lock). Tu as vu uv au cours ML (module 3) — la nouveauté ici est le workspace : uv sync installe tout l'arbre cohérent, et chaque package déclare SES dépendances (deptry vérifie qu'aucune n'est superflue).

La CI qui rend l'architecture obligatoire

Le projet ne « recommande » pas ses conventions — il les fait échouer en CI :