Action réelle protégée par confirmation en deux temps

Le danger d’un agent qui agit seul

Jusqu’ici, l’agent ne fait que lire des données (offres, fiches entreprises). La dernière capacité — postuler à une offre — modifie un état réel. Un agent qui agirait de sa propre initiative, sans validation, pourrait envoyer une candidature non désirée, ou la dupliquer.

Le patron dry-run / confirmation

def apply_to_offer(conn, offre_id, confirme=False):
    if not confirme:
        return {
            "action": "dry_run",
            "message": f"Postulerait a l'offre {offre_id}. Confirmez avec confirme=True.",
        }
    conn.execute(
        "INSERT INTO candidatures (offre_id, statut) VALUES (?, 'envoyee')", (offre_id,)
    )
    conn.commit()
    return {"action": "execute", "message": f"Candidature envoyee pour l'offre {offre_id}."}

print(apply_to_offer(conn, offre_choisie))

{'action': 'dry_run', 'message': "Postulerait a l'offre 7. Confirmez avec confirme=True."}

Le premier appel (confirme=False par défaut) annonce ce qui serait fait, sans toucher à la base — aucune ligne insérée, aucun effet de bord. C’est uniquement au second appel, avec confirme=True explicite, que l’action a réellement lieu :

print(apply_to_offer(conn, offre_choisie, confirme=True))

{'action': 'execute', 'message': "Candidature envoyee pour l'offre 7."}

Vérifier la garantie, pas juste l’observer

def test_apply_dry_run_does_not_write_to_database(conn):
    result = apply_to_offer(conn, offre_id=1, confirme=False)
    assert result["action"] == "dry_run"
    assert len(list_applications(conn)) == 0

Ce test ne vérifie pas seulement le message renvoyé : il vérifie l’absence d’effet de bord en interrogeant directement l’état de la base après l’appel — la seule façon de garantir que le dry-run est un vrai dry-run, pas juste un message rassurant qui accompagnerait une écriture silencieuse.

Un patron généralisable

Ce principe (simuler avant d’agir, exiger un signal explicite pour la version réelle) s’applique à tout agent capable de modifier un état réel : envoyer un e-mail, déclencher un paiement, modifier une configuration de production. Plus l’action est coûteuse à annuler, plus cette double confirmation est indispensable.

Prochaine étape

👉 Synthèse et bilan du parcours

---

Junior TSAFACK – 12/09/2026