# AI FIRST — Meetup 29/06 — Doodle-killer

**Le sujet — un Doodle-killer**

> Brief du meetup AI FIRST du 29/06 : construire un doodle-killer en 2 heures, palier par palier.

- **Document** : Brief du meetup
- **Format** : Build de 2 heures — 4 paliers de difficulté
- **Périmètre** : Sondage de créneaux pour caler une réunion ou un déjeuner

---

## § 01 — Esprit de l'exercice

Construire, en deux heures, une application qui marche à partir d'un besoin réel du quotidien. Le sujet de cette édition : un **sondage de créneaux** — l'outil qu'on utilise tous pour caler une réunion ou un déjeuner d'équipe, et dont les solutions en ligne (type Doodle) sont une plaie : pubs envahissantes, comptes obligatoires, interfaces lourdes. Tout le monde dans la salle a déjà souffert de ce genre d'outil : le besoin parle tout de suite.

### Parti pris #1 — Un brief volontairement sous-spécifié

Le brief décrit ce qui est attendu — le besoin, le comportement, les cas limites — mais jamais *comment* le réaliser. C'est délibéré : un brief trop précis devient un prompt prêt à coller, et l'intérêt s'effondre. Partout où une décision se présente, elle vous appartient.

### Parti pris #2 — Une difficulté progressive

Le niveau de la salle est hétérogène, des profils aguerris comme des débutants. La grille est graduée pour que chacun reparte avec quelque chose qui tourne. Trois paliers attendus, un bonus hors session.

## § 02 — La mise en situation

*Lundi matin, un collègue débarque à ton bureau, visiblement pressé.*

« Dis, il faut qu'on cale notre point d'équipe et c'est l'enfer. J'ai voulu passer par un de ces sites de sondage en ligne — tu sais, le truc avec quinze pubs qui a failli faire fondre mon PC. Impossible de partager le lien proprement, et il fallait que tout le monde se crée un compte. On laisse tomber.

Tu peux pas nous bricoler un petit truc à nous ? Un machin tout simple : je propose quelques créneaux, j'envoie un lien aux gens, chacun coche ses dispos, et on voit lequel rassemble le plus de monde. Pas de pub, pas de compte pour ceux qui répondent. Juste ça. »

**C'est le besoin. À toi de le faire exister.**

## § 03 — Les paliers

Un seul métier : faire émerger le bon créneau. La promesse est étroite — pas de pub, pas de compte imposé à ceux qui répondent, un lien qui se partage proprement — mais elle doit tenir parfaitement. Chaque palier la pousse plus loin.

1. **Socle** — Attendu de tous
2. **Avancé** — Déployable et réutilisable
3. **Poussé** — Décisions produit & cas limites
4. **Bonus** — Hors session — aucune attente

---

## Palier 1 — Socle — Attendu de tous

Le strict nécessaire pour une application qui tourne et qui sert vraiment. Un participant qui ne livre que ce palier repart avec un produit utilisable.

### Fonctionnalités

- **Créer un sondage.** L'organisateur saisit un titre et propose plusieurs créneaux.
- **Répondre.** Un participant ouvre le sondage, se nomme, et indique ses disponibilités sur les créneaux proposés.
- **Voir le résultat.** Une vue récapitule les réponses et fait ressortir le créneau qui réunit le plus de monde.
- **Administrer son sondage.** L'organisateur dispose d'un accès d'administration distinct de la page de participation, lui permettant au minimum de clôturer le sondage et de retirer une réponse.

### Règles de gestion — Palier 1

| Domaine | Règle |
| --- | --- |
| Création | Un titre est obligatoire. |
| Création | Un sondage propose au moins deux créneaux. |
| Création | Un créneau se situe dans le futur au moment de la création. |
| Création | Deux créneaux strictement identiques ne devraient pas coexister. |
| Réponse | Le nom du participant est obligatoire. |
| Réponse | Un participant peut n'indiquer aucune disponibilité, une seule, ou plusieurs. Une réponse sans aucune coche reste valide (« je ne peux à aucun »). |
| Réponse | Une réponse porte sur les créneaux existant au moment où elle est donnée. |
| Résultat | Le gagnant provisoire est le créneau qui réunit le plus de disponibilités. |
| Résultat | **À TRANCHER (participant) :** en cas d'égalité entre deux créneaux, le comportement doit être défini et cohérent (les deux ressortent, ou l'antériorité départage). |
| Admin | L'accès d'administration est distinct de la page de participation. |
| Admin | Clôturer un sondage le rend consultable mais ferme toute nouvelle réponse et fige les résultats. |
| Admin | Retirer une réponse recalcule immédiatement les décomptes et le gagnant provisoire. |

> **Note de cadrage** — Au palier 1, aucune authentification n'est exigée : seul compte le fait que l'accès d'administration soit séparé de la page de participation. Le moyen d'y parvenir vous appartient entièrement.

---

## Palier 2 — Avancé — Déployable et réutilisable

L'application change de nature : on passe d'un outil « qui tourne » à un outil « qu'on peut déployer et réutiliser ». C'est ici qu'arrivent la persistance et l'authentification.

### Fonctionnalités

- **Persistance réelle.** Les sondages et les réponses survivent au rechargement et sont accessibles à distance par plusieurs personnes.
- **Authentification de l'organisateur.** L'accès d'administration ne repose plus sur un simple lien : l'organisateur s'authentifie pour piloter ses sondages et les retrouver regroupés. La participation reste ouverte sans compte.
- **Modifier sa réponse.** Un participant peut revenir corriger ses disponibilités.
- **Capacité par créneau.** L'organisateur peut plafonner le nombre de participants sur un créneau.
- **Date limite de réponse.** Le sondage se ferme automatiquement à une échéance.

### Règles de gestion — Palier 2

| Domaine | Règle |
| --- | --- |
| Persistance | Un sondage et ses réponses survivent au rechargement et restent accessibles à distance à plusieurs personnes simultanément. |
| Persistance | Deux réponses concurrentes ne doivent pas s'écraser l'une l'autre. |
| Auth | L'organisateur s'authentifie pour piloter ses sondages et les retrouve regroupés. |
| Auth | La participation reste ouverte sans compte. |
| Auth | Seul l'organisateur d'un sondage peut l'administrer. |
| Modif. réponse | Le système doit pouvoir reconnaître un participant entre deux visites. |
| Modif. réponse | Une modification remplace l'ancienne réponse, elle ne s'y ajoute pas. |
| Capacité | L'organisateur peut plafonner le nombre de participants sur un créneau. |
| Capacité | Une fois le plafond atteint, le créneau n'accepte plus de nouvelle disponibilité et s'affiche comme complet. |
| Date limite | Passé l'échéance, le sondage se ferme automatiquement, plus aucune réponse n'est acceptée et les résultats sont figés — même comportement qu'une clôture manuelle. |

---

## Palier 3 — Poussé — Décisions produit & cas limites

Les fonctionnalités qui forcent de vraies décisions produit et regorgent de cas tordus — celles où un agent lâché seul se plante ou simplifie à outrance.

### Fonctionnalités

- **Quorum / participants indispensables.** L'organisateur peut désigner certaines personnes comme indispensables : un créneau ne devient réellement valable que si elles y sont disponibles.
- **Masquer qui a voté.** L'organisateur peut activer une option où les participants voient les décomptes sans voir qui a répondu quoi.
- **Clôture et notification automatiques.** À l'échéance, le système fige le créneau retenu et prévient les participants.
- **Créneaux récurrents.** Le sondage peut porter sur un événement qui se répète.
- **Notifications aux participants.** Relances avant l'échéance, confirmation une fois le créneau arrêté.

### Règles de gestion — Palier 3

| Domaine | Règle |
| --- | --- |
| Quorum | L'organisateur désigne certaines personnes comme indispensables. |
| Quorum | Un créneau n'est « valable » que si toutes ces personnes y sont disponibles, même s'il rassemble moins de monde au total — ce qui peut renverser le gagnant apparent. |
| Quorum | Si aucun créneau ne satisfait le quorum, l'état doit être affiché clairement plutôt que de désigner un faux gagnant. |
| Anonymat | Les participants voient les décomptes par créneau sans voir qui a répondu quoi ; l'organisateur conserve la vue complète. |
| Anonymat | L'option n'empêche pas un participant de retrouver et modifier sa propre réponse. |
| Clôture auto | À l'échéance (ou quand les conditions sont réunies), le système fige le créneau retenu et prévient les participants. |
| Clôture auto | Le gagnant suit une cascade de critères à départager proprement : disponibilités → quorum satisfait → capacité respectée. L'ordre exact est un choix à assumer. |
| Récurrence | Le sondage peut porter sur un événement qui se répète plutôt que sur des dates isolées. |
| Récurrence | La récurrence s'exprime selon différents motifs : jour et heure fixes (« tous les lundis à 14h ») ; rang dans le mois (« le premier mercredi », « le dernier vendredi ») ; avec une borne de fin ou un nombre d'occurrences. |
| Récurrence | Le dépouillement raisonne sur les occurrences engendrées par le motif. |
| Récurrence | **À TRANCHER (participant) :** sort d'une occurrence tombant un jour férié ; façon pour un participant de se déclarer disponible « en général » mais absent sur une occurrence précise ; latitude de l'organisateur pour modifier le motif une fois des réponses enregistrées. |
| Notifications | Relancer ceux qui n'ont pas répondu avant l'échéance ; confirmer à tous une fois le créneau arrêté. |

---

## Palier 4 — Bonus — Hors session — aucune attente

Un réservoir d'ambition pour qui aurait solidifié les trois premiers paliers : « et si on corrigeait ce qui cloche vraiment dans Doodle ». **À ne pas attaquer avant d'avoir consolidé le reste.** Ce palier reste à étoffer ; pistes de départ : tout ce qui manque ou agace dans les outils existants. *(À compléter ensemble.)*