La recette continue : E2E, environnements, versions

Recette événementielle vs continue

La recette classique est événementielle : avant une release, un humain déroule des scénarios. Le problème : entre deux recettes, on ignore l'état réel. La recette continue inverse : des suites E2E tournent en permanence contre l'environnement déployé et alertent au premier écart — la question « est-ce que ça marche ? » a une réponse à jour, tout le temps.

L'anatomie observée (projet copilot)

suites Playwright (E2E black-box, ~70 scénarios : Quotes, Mappings IA)
  → tournent 2×/jour contre l'ENV DÉPLOYÉ (pas en local, pas en mock)
  → rapport dans un canal Slack dédié :
      • succès/échecs par FAMILLE (auth ✓, cascade ✗ D4…) — on voit QUOI casse
      • le commit ET la version réellement servie par l'env
  → un échec ping le canal (<!channel>) — la régression se sait en heures, pas en jours

Deux finesses qui font la différence :

1. black-box, contre l'env réel : on teste par l'UI ce qui est déployé, pas ce qui est dans le code local — le seul test qui reflète l'expérience utilisateur (et qui attrape les bugs d'intégration/config que les tests unitaires ratent) ;
2. la version servie tracée dans le rapport : c'est le garde-fou contre le déploiement décalé — le cas vicieux où les tests passent sur du code qui n'est pas encore (ou plus) celui de l'environnement. Sans afficher « env sert le commit X », un échec devient un mystère (« ça marche chez moi »).

Le partage humain/machine

La recette continue ne supprime pas l'œil humain — elle le libère : les parcours mécaniques (un devis se crée, un mapping se persiste) sont verrouillés par les E2E ; l'humain se concentre sur ce qui ne s'automatise pas bien (le ressenti, la cohérence visuelle, les cas tordus non encore scénarisés). Et chaque bug trouvé à la main devient un nouveau scénario E2E — la suite grandit des erreurs, comme le golden set du matching grandit des siennes.