35 points,
publiés dès le premier jour.

Le sujet du sprint est traité de bout en bout, vérifié par les tests d'acceptation publiés avec le sujet, identiques pour les 5 équipes.

Ces tests sont livrés au démarrage du sprint et vous les lancez quand vous voulez. Ils décrivent le comportement attendu, pas la façon de l'obtenir : l'architecture, le découpage et les choix techniques restent les vôtres, et ce sont les 9 autres critères qui les notent.

• Les tests d'acceptation passent sur la base gelée, cas d'erreur prévus compris.
• Aucun chemin critique ne plante sur une entrée valide.
• Une partie du sujet reste non traitée, ou traitée « presque » : le cas nominal passe, un cas prévu échoue.
• Des tests d'acceptation modifiés ou contournés pour les faire passer.

Ce critère note la densité cognitive : fonctions courtes, code mort supprimé, commentaires qui expliquent le pourquoi.

Le formatage ne rapporte pas de points : le linter s'en occupe déjà, et il tourne à chaque envoi de code. Ce qu'on regarde ici, c'est ce qu'aucun outil ne voit. Une fonction qu'il faut relire 2 fois pour comprendre fera perdre du temps à l'équipe qui reprendra la base, même si elle est parfaitement formatée.

• Des fonctions qui tiennent à l'écran, une idée par fonction, retour au plus tôt.
• Des fonctions de 80 lignes, 4 niveaux d'imbrication, du code commenté laissé là.

Ce critère note des noms qui disent l'intention, sans abréviation cryptique. L'exemple Après se lit sans deviner, et les types documentent en prime.

Un bon nom évite d'écrire le commentaire qui aurait expliqué le mauvais.

def calc(d, t):
    return d / t if t else 0

def vitesse_moyenne_kmh(distance_km: float, duree_h: float) -> float:
    if duree_h == 0:
        return 0.0
    return distance_km / duree_h

On mesure surtout le S (une responsabilité par unité) et le D (dépendre d'abstractions, pas de détails). Le symptôme n°1 chez le débutant : la route qui valide, calcule et parle à la base en même temps.

On peut se tromper dans les 2 sens. Pas assez de structure : une fonction qui valide, calcule et écrit en base de données en même temps. Trop de structure : une interface qui n'apporte rien, ou un découpage qui oblige à ouvrir 4 fichiers pour suivre une seule règle. La question à se poser est toujours la même : est-ce que le métier est séparé de l'affichage et du stockage ?

@app.post("/orders")
def create_order(payload: dict):
    if "items" not in payload:
        raise HTTPException(400, "items manquant")
    total = 0
    for it in payload["items"]:
        total += it["price"] * it["qty"]
    conn = psycopg2.connect(DSN)
    cur = conn.cursor()
    cur.execute("INSERT INTO orders (total) VALUES (%s)", (total,))
    conn.commit()
    return {"total": total}

# 1) Validation : le schéma Pydantic
class OrderItem(BaseModel):
    price: Decimal
    qty: int = Field(gt=0)

class OrderIn(BaseModel):
    items: list[OrderItem]

# 2) Métier : une fonction pure, testable sans base de données ni HTTP
def compute_total(items: list[OrderItem]) -> Decimal:
    return sum(item.price * item.qty for item in items)

# 3) Persistance : un repository injecté (dépendance abstraite)
@router.post("/orders", response_model=OrderOut, status_code=201)
def create_order(payload: OrderIn, repo: OrderRepository = Depends(get_order_repo)):
    total = compute_total(payload.items)
    return repo.create(total=total)

Bénéfice concret : compute_total se teste en une ligne, la route devient triviale, changer de base de données ne touche pas au métier.

Ce critère note la duplication de logique. Copier-coller une mécanique, c'est un bug à corriger à N endroits ; le texte répété n'en relève pas.

Dupliquer n'est pas toujours une faute. 2 morceaux de code qui se ressemblent aujourd'hui mais qui vont évoluer séparément valent mieux séparés. Ce qu'on vous demande, c'est de l'écrire : une duplication avec un commentaire # pourquoi : est un choix, la même sans rien est un oubli. À l'inverse, regrouper 2 choses qui n'ont rien à voir crée un problème que l'équipe suivante paiera. Une abstraction se juge à ce qu'elle apporte (isoler une dépendance, rendre un test possible), pas au nombre de ses implémentations.

function Users() {
  const [data, setData] = useState<User[]>([])
  const [loading, setLoading] = useState(true)
  useEffect(() => {
    fetch("/api/users").then(r => r.json()).then(d => { setData(d); setLoading(false) })
  }, [])
  // …
}

function useResource<T>(url: string) {
  const [data, setData] = useState<T | null>(null)
  const [loading, setLoading] = useState(true)
  const [error, setError] = useState<Error | null>(null)

  useEffect(() => {
    let alive = true
    fetch(url)
      .then(r => { if (!r.ok) throw new Error(`HTTP ${r.status}`); return r.json() })
      .then(d => { if (alive) setData(d) })
      .catch(e => { if (alive) setError(e) })
      .finally(() => { if (alive) setLoading(false) })
    return () => { alive = false }   // nettoyage : pas de setState après démontage
  }, [url])

  return { data, loading, error }
}

Le signe qu'un refactor DRY était justifié : il corrige souvent des bugs au passage (ici, la gestion d'erreur et une fuite de setState).

Ce critère note la couverture des règles métier et de leurs cas limites, en priorité là où une erreur coûte cher (argent, données, sécurité, action irréversible), et des tests qui tournent d'une seule commande.

La couverture ne dit pas si vos tests sont bons. Elle dit seulement quelles lignes ne sont jamais exécutées pendant les tests : on peut atteindre 100 % sans rien vérifier du tout. Alors ne visez pas un pourcentage. Partez des règles du projet, par exemple « une commande vide est refusée » ou « une remise ne dépasse jamais 50 % », et écrivez un test par règle, puis un test par cas limite. Un seul gros test qui rejoue tout le parcours ne suffit pas : quand il casse, il ne dit pas où.

# Test unitaire du métier : rapide, sans base de données ni réseau
def test_compute_total_somme_prix_fois_quantite():
    items = [OrderItem(price=Decimal("2.50"), qty=3),
             OrderItem(price=Decimal("1.00"), qty=1)]
    assert compute_total(items) == Decimal("8.50")

# Test d'API : le contrat HTTP est-il respecté ?
def test_create_order_refuse_quantite_negative(client):
    resp = client.post("/orders", json={"items": [{"price": "2.5", "qty": -1}]})
    assert resp.status_code == 422        # Pydantic rejette qty <= 0

• Un test par règle métier, un test par cas limite (entrée vide, zéro, négatif).
• Seul le « chemin heureux » est testé, ou lancer les tests demande un setup manuel.
• Des tests sur les accesseurs, les objets de transport ou le framework lui-même.
• Un test sans assertion utile : pire qu'une absence de test, il donne une fausse assurance et gonfle une couverture qui ne veut alors plus rien dire.

Ce critère note des erreurs attrapées au bon niveau, avec le bon statut, sans fuite d'information sensible ni except fourre-tout.

L'hygiène de sécurité se note ici : une image Docker non figée, une dépendance obsolète, des droits trop larges. Les 3 failles lourdes (entrée qui devient du code, secret en clair, authentification contournable) mettent ce critère à zéro.

try:
    user = repo.get(user_id)
    return user
except Exception:
    return {"error": "oops"}

user = repo.get(user_id)
if user is None:
    raise HTTPException(status_code=404, detail="Utilisateur introuvable")
return user

Ce critère note la documentation qui accompagne la base, et sa véracité.

• README qui couvre le lancement et l'architecture, document de reprise à jour, commentaires qui expliquent le pourquoi.
• Procédure de lancement documentée, dépendances épinglées, limites connues signalées.
• Doc absente ou mensongère (pire que pas de doc), versions flottantes, « ça marche sur ma machine ».

Le code utilise le langage et le framework tels qu'ils sont conçus, au lieu de réinventer ce qu'ils fournissent déjà, et n'ajoute pas une dépendance pour ce que la bibliothèque standard fait. Beaucoup de manières de faire la même chose se valent ; certaines pas du tout.

On vous demande de vérifier, avant d'écrire, si le langage ou le framework le fait déjà. Refaire à la main ce qui existe, c'est du code en plus à maintenir et des bugs déjà corrigés ailleurs qu'on réintroduit.

@app.post("/users")
def create_user(payload: dict):
    if "email" not in payload or "@" not in payload["email"]:
        raise HTTPException(400, "email invalide")
    if not isinstance(payload.get("age"), int) or payload["age"] < 0:
        raise HTTPException(400, "age invalide")
    return repo.create(payload["email"], payload["age"])

class UserIn(BaseModel):
    email: EmailStr
    age: int = Field(ge=0)

@app.post("/users", status_code=201)
def create_user(payload: UserIn, repo: UserRepository = Depends(get_user_repo)):
    return repo.create(payload.email, payload.age)

• Validation par le schéma, injection par Depends, hooks React pour l'état et les effets, requêtes via l'ORM ou paramétrées, utilitaires standard (dates, parsing).
• Validation à la main, état global bricolé, un utilitaire réécrit alors que la stdlib le fournit, une dépendance lourde pour une fonction triviale, le framework contourné plutôt qu'utilisé.

Les décisions structurantes du sprint sont écrites, avec leurs alternatives et leurs conséquences, dans des fichiers numérotés placés dans docs/adr/.

# 0004 - Un repository pour l'accès aux commandes

## Contexte
Les requêtes SQL étaient écrites dans les routes HTTP : le métier
n'était pas testable sans base de données.

## Options
1. Laisser en l'état, plus rapide à écrire.
2. Un repository injecté, testable avec un double.
3. Un ORM complet, plus puissant mais plus lourd pour ce périmètre.

## Décision
Option 2.

## Conséquences
Le métier devient testable sans base de données. Un fichier de plus par entité.
Si un jour on a besoin de requêtes complexes, il faudra rouvrir ce choix.

• Toute décision qui engage les sprints suivants, ou qui avait plusieurs options raisonnables, est écrite ; les alternatives sont réelles ; les conséquences incluent ce que la décision coûte.
• Les écarts aux critères 04 et 05 sont justifiés là, ou par un commentaire # pourquoi : à l'endroit du choix.
• Un changement d'architecture sans trace écrite, un ADR rédigé après coup pour cocher la case, des décisions annoncées à l'oral et introuvables dans le dépôt.

Écrire ce que vous avez écarté et pourquoi prend 10 lignes, et rend votre architecture lisible pour celui qui arrive après. C'est aussi la seule façon de montrer votre raisonnement sans passer par l'oral.