# Étude de cas : dropyour, livré avec runward

dropyour, un produit en production construit avec runward de bout en bout : 17 ADR, 60 tests, mesuré sur trafic réel, une porte au vert. La preuve qu'une méthode tient.

Une méthode se prouve par un produit qui a shippé, pas par une démo. dropyour a été construit avec runward de bout en bout, du cadrage à la production, la chaîne complète en un jour. Ce jour est une fonction du périmètre, volontairement petit ici (trois ports, un opérateur) : sur une mission client, la même chaîne prend les semaines que le contrat de mission énonce. La profondeur se choisit, les portes sont les mêmes. Voici la trace, porte par porte.

> **Schéma.** La livraison va de l’idée à la production en six phases : cadrer, architecturer, plancher, itérer, gouverner, transmettre. Chaque porte se franchit sur une preuve, jamais sur une affirmation. Itérer (phase 4, en pointillés) n’a pas de fichier livrable : elle est gardée par la discipline (un ADR par bascule), pas par une porte de présence.

## Le produit

dropyour héberge instantanément les fichiers HTML autonomes que produisent les harness IA (Claude, ChatGPT, Cursor, v0). Vous déposez un `.html`, vous obtenez un lien en moins de 5 secondes, sans compte. Déployé sur l'edge Cloudflare, deux origines, stockage en UE, un serveur MCP pour les agents. En production sur [dropyour.io](https://dropyour.io).

Un produit qui tourne, avec anti-abus, RGPD, et une adresse promise à vie à ses utilisateurs. Un produit, pas une slide.

## La méthode, porte par porte

L'agent construit le système ; runward en trace le chemin, et [chaque porte se franchit sur preuve](https://runward.dev/docs/concepts/six-phases/), jamais sur déclaration. Voici où chaque porte a atterri pour dropyour.

| Phase | Ce que dropyour a fait | La preuve à la porte |
|---|---|---|
| **Cadrer** | Problème (deux personas observés), valeur (10 min de déploiement ramenées à 5 s), un critère de succès observable | Critère écrit : TTL médian drop vers lien sous 5 s, sur ≥ 10 drops réels, sur le système déployé |
| **Architecturer** | Trois [ports](https://runward.dev/docs/concepts/architecture/) côté domaine (stockage, métadonnées, scan), deux entrypoints Workers, le modèle hors du chemin de décision | Frontières décidées, stack encore ouverte ; le scan LLM vit derrière un port et ne peut que *mettre en quarantaine* |
| **Plancher** | Le plus petit système qui tourne et prouve le geste, sur trafic réel | TTL médian **420 ms**, 10 drops réels sur 10, remplacement à URL constante démontré |
| **Gouverner** | Modèle de menace (la trifecta gardée cassée), rubrique d'évaluation, schéma d'observabilité | Instrumenté dès le jour zéro ; anti-abus posé au fondement, pas rajouté après |
| **Itérer** | Paste, QR, compteur de vues, réglages, puis les vrais domaines (une origine par drop) | Chaque ajout attaché à un déclencheur objectif, pas à une envie |
| **Transmettre** | Runbook exécutable (takedown, recovery, checklist de lancement) ; la succession démontrée | Le sponsor, l'opérateur humain là où l'agent avait construit le système, a rejoué la preuve sans l'agent, avec le seul runbook : 10 drops sur 10, TTL médian **524 ms**. Mission close |

La décision qui compte le plus est dans Architecturer : le modèle reste hors du chemin. Le code déterministe décide en premier ; le modèle propose, le domaine dispose. C'est la même frontière que garde la porte de runward : [le modèle vit en amont, jamais dans le verdict](https://runward.dev/docs/concepts/the-gate/).

## Ce que la trace laisse

Une méthode se juge à ce qu'elle laisse derrière. dropyour a laissé un dossier auditable, pas un souvenir :

| Artefact | Ce que c'est |
|---|---|
| **17 ADR** | Chacun daté, avec ses alternatives écartées et un déclencheur de revue. Six semaines plus tard, « pourquoi ce choix ? » a une réponse écrite |
| **60 tests déterministes** | Plus un script de mesure rejouable : les chiffres ci-dessus se reproduisent, ils ne se croient pas sur parole |
| **Un gap-analysis** | Ce qui est livré face à la V1 complète : chaque écart avec son trigger, zéro dette cachée, zéro décision à ratifier |
| **Un `runward check --strict` au vert** | Du code déterministe : les décisions qui font tenir le système ont été prises et écrites, [vérifiées et scellées](https://runward.dev/docs/concepts/evidence/), impossibles à embobiner par un prompt |

## Un artefact, ouvert

Des comptes sont des affirmations ; voici à quoi ressemble une ligne du dossier. L'ADR-0005, la décision anti-abus du jour zéro, en extrait (le dépôt dropyour est privé : la trace part avec le produit, le dossier est donc cité ici plutôt que lié) :

> **ADR-0005 : Anti-abus jour 0, scan déterministe fail-closed derrière `ScanPort`, rate limiting pseudonymisé, badge injecté au service (blob original intact)** · daté, statut : accepté
>
> **Décision** : trois défenses jour zéro, toutes déterministes et testables. Un verdict `ScanPort` fail-closed au dépôt (« toute erreur du scan = rejet : publier est une action, pas une lecture ») ; un rate limiting par IP sur un hash salé quotidiennement, l'IP en clair jamais stockée ; le badge et les en-têtes de sécurité injectés au moment du service, le fichier stocké reste l'original de l'utilisateur.
>
> **Alternatives écartées, au dossier** : un scan LLM dans le chemin de publication dès le jour un (« un scan probabiliste dans le chemin de publication sans rubrique d'évaluation posée serait ingouvernable : le déterministe d'abord, le modèle sur trigger », différé avec son déclencheur écrit). Un badge cousu dans le blob : corrompt l'original, rejeté. Un captcha au jour zéro : friction sans signal d'abus mesuré, différé avec son déclencheur.
>
> **Conséquences, acceptées par écrit** : des faux négatifs passeront ; assumé au plancher, et dit.

Chacun des 17 ADR a cette forme : daté, décidé, les alternatives écartées au dossier, les conséquences acceptées par écrit. `runward check --strict` vérifie la présence, les pointeurs et l'intégrité de ce dossier, [jamais sa qualité](https://runward.dev/docs/concepts/the-gate/) : la qualité, c'est ce que vous venez de lire, et la juger reste le travail d'un humain.

## Doser la discipline

Le palier d'arrêt fixe jusqu'où la méthode va : cadrage seul, plancher, ou chaîne complète. dropyour a pris la chaîne complète parce qu'il devait tenir : anti-abus existentiel, RGPD ferme, adresse promise à vie, utilisateurs réels. C'est là que la discipline se rembourse. Un script jetable de 500 lignes en demanderait bien moins ; l'idée, c'est que vous choisissez la profondeur exprès.

## Le point

dropyour a shippé, tourne en production, et pourrait être repris par une autre équipe sans son auteur d'origine, parce que chaque décision est tracée. C'est ça, la preuve qu'une méthode tient, et c'est la même [preuve prête pour l'audit](https://runward.dev/docs/compliance/evidence/) que runward laisse sur n'importe quelle mission.

[dropyour.io](https://dropyour.io) pour le produit. `npx runward init` pour la méthode. L'argumentaire complet est dans [Après la spec : le comparatif](https://runward.dev/docs/compare/).

## Voir aussi

- [Après la spec : le comparatif](https://runward.dev/docs/compare/)
- [Les six phases](https://runward.dev/docs/concepts/six-phases/)
- [Preuve et intégrité](https://runward.dev/docs/concepts/evidence/)
- [Architecture et choix](https://runward.dev/docs/concepts/architecture/)