# Analyse du backlog — Mediknode / Unified

> Analyse réalisée le 2026-06-17 par Claude Code, après exploration du codebase.
> Légende des colonnes :
> - **Clair ?** : Oui / Partiel / Non (ai-je compris le besoin ?)
> - **Intérêt** : valeur métier perçue (Faible / Moyen / Fort)
> - **Impact projet** : ampleur technique du changement
> - **Estimation** : ordre de grandeur (h = heures, j = jours). À affiner après réponses.
> - **Priorité (mon avis)** : P0 (critique/bloquant), P1 (important), P2 (utile), P3 (nice-to-have)
>
> ⚠️ Les estimations sont des ordres de grandeur. Beaucoup de points sont des intitulés très courts qui cachent une vraie ambiguïté — voir la colonne **Question**.

---

## Observations transversales (faits vérifiés dans le code)

Ces constats reviennent sur plusieurs tickets, je les pose une fois ici :

- **Soft delete** : seulement 5 modèles utilisent `SoftDeletes` (`Participant`, `User`, `Show`, `Doctor`, `Lista`). → concerne directement #33, #36, #58, #29.
- **Indexation BO** : un middleware `NoIndexBackend` existe déjà. → #140 est probablement déjà résolu (à vérifier qu'il est appliqué partout).
- **Sitemap** : commande `GenerateSitemap` + tâche planifiée quotidienne 2h existent déjà. → #25, #147 sont partiellement faits.
- **Paiement en ligne** : `FlouciPayment` + contrôleurs existent déjà. → #139 est entamé (Flouci), Konnect/Paymee restent à faire.
- **Imports** : ~17 classes d'import existent (`ImportParticipants`, `ImportUsers`, `ImportHebergements`, `ImportPress`, `ImportDocuments`, `ImportAttestations`…). → toute la famille #34/#37/#38/#39/#40/#46/#53/#56/#64 s'y greffe.
- **`has_evaluation`** existe déjà sur le modèle `Event`. → #4 = juste exposer dans le form d'édition.
- **Pas de dossier Livewire** trouvé sous le nom attendu (CLAUDE.md mentionne `resources/views/livewire/backend/`) — la migration Participants est en cours, donc certains tickets « front » sont à confirmer sur l'ancien vs nouveau contrôleur.

---

## MEDIKNODE

| # | Tâche | Clair ? | Intérêt | Impact | Estim. | Prio | Question / Note |
|---|-------|---------|---------|--------|--------|------|-----------------|
| 1 | add document import model XLSX | Oui | Moyen | Faible | 0.5j | P2 | `ImportDocuments` existe déjà — s'agit-il de fournir un **template XLSX téléchargeable** comme modèle d'import ? |
| 2 | Frontend - prix chambre hôtel (2 chiffres) | Oui | Faible | Faible | 1h | P2 | Simple formatage à 2 décimales sur l'affichage du prix chambre. Confirmer : arrondi ou juste affichage ? |
| 3 | affichage de l'info prise en charge | Partiel | Moyen | Faible | 0.5j | P2 | Modèles `PriseEnCharge`/`PriseEnChargeHebergement` existent. Où l'afficher (front participant ? badge ? BO) ? |
| 4 | add has_evaluation to event edit | Oui | Moyen | Faible | 1h | P1 | Champ déjà en BDD/modèle — juste l'ajouter au formulaire d'édition événement. Tâche rapide à fort ROI. |
| 5 | Mhamed attestations | Non | ? | ? | ? | — | **Trop vague.** Que doit faire Mhamed exactement sur les attestations ? Lui donner accès ? Une feature ? |
| 6 | Vérifier et afficher les preuves de paiement | Oui | Fort | Moyen | 1-2j | P1 | `attachment_1/2/3_path` sur Participant = preuves. Besoin : visualiseur dans le BO + workflow de validation ? |
| 7 | voir détails en mode mobile | Partiel | Fort | Moyen | 1-2j | P1 | Lié à #12. Quelle vue précisément (fiche participant ?). Responsive ou vue dédiée mobile ? |
| 8 | test VPs for sending emails | Non | Moyen | ? | ? | — | « VPs » = VPS (serveurs) ou autre ? Tester la délivrabilité des emails depuis plusieurs serveurs ? |
| 9 | step 0 : modifier profile | Oui | Fort | Moyen | 1-2j | P1 | Ajouter une étape 0 « modifier profil » avant l'inscription 7 étapes. Confirmer le périmètre des champs éditables. |
| 10 | monitoring avec notification par mail | Oui | Fort | Moyen | 1-2j | P1 | `MonitoringController` existe. Quoi monitorer (queue, erreurs, paiements échoués) ? Seuils ? |
| 11 | nettoyage physique des documents | Partiel | Moyen | Moyen | 1j | P2 | Supprimer fichiers orphelins du disque (docs sans ligne BDD). ⚠️ Risqué — prévoir dry-run + log. Lié #52, #58. |
| 12 | mobile render | Non | Fort | Fort | ? | — | **Trop large.** Tout le front ? Le BO ? Une page ? Périmètre à délimiter absolument. |
| 13 | mail hébergement confirm without data only from DB | Partiel | Moyen | Faible | 0.5j | P2 | Le mail de confirmation hébergement doit lire uniquement depuis la BDD (pas de données passées en session) ? |
| 14 | interdire (.) ou espace pour autres domaines | Oui | Moyen | Faible | 2h | P2 | Validation email/domaine. Préciser le champ concerné (email pro ? domaine événement ?). |
| 15 | How to check user_workshop table validity | Partiel | Moyen | Faible | 0.5j | P2 | Besoin d'une requête/commande de contrôle d'intégrité de `participant_workshop`. C'est une question d'analyse, pas une feature. |
| 16 | hébergement tableau récap à l'étape confirmation | Oui | Fort | Faible | 0.5j | P1 | Récap hébergement à l'étape de confirmation du parcours. Clair. |
| 17 | Hébergement : manage children and babies | Oui | Fort | Moyen | 2-3j | P1 | `ChildReductionRule` existe déjà. Gérer tarifs/comptage enfants & bébés dans la résa. Demande des règles métier précises. |
| 18 | exposant nombre badge limitation | Oui | Moyen | Moyen | 1j | P2 | Limiter le nombre de badges par exposant. Limite par défaut ? Configurable par event/sponsor ? |
| 19 | FRONT redirection to the right events | Partiel | Fort | Moyen | 1j | P1 | Routing multi-subdomain existant. Quel cas de mauvaise redirection observé ? Besoin d'un repro. |
| 20 | Frontend - generate documents attestation adhésion | Oui | Fort | Moyen | 1-2j | P1 | `AttestationTemplate`/`EventAttestation` existent. Générer l'attestation d'adhésion côté front participant. Lié #63. |
| 21 | Frontend - generate documents reçu paiement | Oui | Fort | Moyen | 1-2j | P1 | Reçu de paiement PDF côté front. `PDFGenerationService` existe. Lié #20. |
| 22 | enable/disable auto by datetime (abstracts + price) | Oui | Fort | Moyen | 1-2j | P1 | Ouverture/fermeture automatique abstracts et tarifs selon dates. Lié #131/#132. Champs dates déjà présents sur Event ? à vérifier. |
| 23 | delete participant + cancel participation => notifications | Oui | Fort | Moyen | 1-2j | P1 | Notifier (mail) lors d'une suppression/annulation. Lié au soft delete #33. Qui est notifié (admin ? participant ?). |
| 24 | check quality title + check titre académique | Oui | Moyen | Faible | 0.5j | P2 | `override_quality_title`/`override_academic_title` existent. Validation/contrôle de cohérence de ces titres. |
| 25 | Mhamed google analytics + SEO + sitemap | Partiel | Moyen | Moyen | 1-2j | P2 | Sitemap déjà fait. Reste : intégrer GA + balises SEO. Quel compte GA ? Par instance ? |
| 26 | Export users from MEDIKNODE db | Oui | Moyen | Faible | 0.5j | P2 | Export existe peut-être déjà (`RegisteredExport`). Quel format/colonnes attendus ? |
| 27 | workshop 2 stocks (réel et affiché) | Oui | Fort | Moyen | 1-2j | P1 | Stock réel vs affiché (overbooking maîtrisé). Bonne idée métier. `WorkshopPricingService` existe. |
| 28 | Tester API de Sami | Non | ? | ? | ? | — | Quelle API ? Quel objectif de test ? Contexte manquant. |
| 29 | test integrity when delete | Oui | Fort | Moyen | 1j | P1 | Tester l'intégrité référentielle aux suppressions. Lié #33/#36. Écrire des tests + vérifier cascades FK. |
| 30 | quiz app - Slido like | Non | Fort | Fort | 1-2sem | P3 | **Gros projet.** Modèles `Vote`/`VoteItem`/`Question`/`Answer` existent déjà — base présente. Périmètre à cadrer (live polling, Q&A, projection ?). |
| 31 | notification abstracts (approuvé) | Oui | Fort | Faible | 0.5j | P1 | Mail au soumissionnaire quand abstract approuvé. `Abst` existe. Lié #41. |
| 32 | notify when add a new User | Oui | Moyen | Faible | 0.5j | P2 | Notif (mail) à la création d'un user. Qui notifier ? Via `UserObserver`. |
| 33 | pas de delete physique | Oui | Fort | Moyen | 1-2j | P0 | Généraliser soft delete (5/60 modèles seulement aujourd'hui). **Décision d'architecture** — lié #36. Forte valeur (audit/sécurité). |
| 34 | Pas import avec le même phone ou email | Oui | Fort | Faible | 0.5j | P1 | Dédoublonnage à l'import sur phone/email. S'applique à `ImportParticipants`/`ImportUsers`. Lié #39. |
| 35 | migration 5CNMGF | Non | ? | ? | ? | — | Migration de données d'un événement spécifique (5CNMGF) ? Source/cible ? |
| 36 | mettre le soft delete dans tous les models | Oui | Fort | Moyen | 1-2j | P0 | = #33 côté implémentation : migrations `deleted_at` + trait sur chaque modèle. Doublon avec #33. |
| 37 | Pré-import participant + delete document par import | Partiel | Moyen | Moyen | 1-2j | P2 | `code_pre_registration` existe. Workflow de pré-import + suppression de docs via import. Préciser. |
| 38 | force import + import pour validé + import Presse | Partiel | Moyen | Moyen | 1-2j | P2 | `ImportPress` existe. « force import » = ignorer les doublons #34 ? Trois sous-tâches à séparer. |
| 39 | à l'import check si NOM et PRENOM coïncide | Oui | Moyen | Faible | 0.5j | P2 | Vérif cohérence nom/prénom à l'import. Coïncide avec quoi exactement (user existant ?). |
| 40 | import force atelier is present | Partiel | Moyen | Faible | 0.5j | P2 | Forcer la présence atelier lors d'un import ? Préciser le comportement attendu. |
| 41 | Email lors du changement de l'abstract | Oui | Moyen | Faible | 0.5j | P2 | Mail quand un abstract est modifié. Lié #31. Qui notifier (auteur ? comité ?). |
| 42 | clean data - Ville demandes d'infos | Partiel | Faible | Faible | 0.5j | P3 | Nettoyage des données « ville ». Lié #143 (listes en dur). Tâche ponctuelle de data-cleaning. |
| 43 | check dashboard bon de commande anciens events | Partiel | Moyen | Faible | 0.5j | P2 | `isBDC`/`bdc` existent. Vérifier l'affichage BDC sur anciens events. Bug supposé — repro nécessaire. |
| 44 | check is valid email in BO | Oui | Moyen | Faible | 0.5j | P2 | Validation/indicateur email valide dans le BO. Lié à `ImportEmailStatus`/Brevo webhook ? |
| 45 | adhésion year 2024 2023 | Partiel | Moyen | Faible | 0.5j | P2 | `MembershipType`/`AdherentController` existent. Gérer les adhésions par année (historique) ? |
| 46 | améliorer import attestations + participants | Partiel | Moyen | Moyen | 1-2j | P2 | Plusieurs classes attestations (`ImportAttestations`, `2`, `OLD`) → dette à consolider. Que veut dire « améliorer » ? |
| 47 | Ajout hébergement capacity + plateforme | Oui | Fort | Moyen | 2-3j | P1 | `Hotel`/`RoomType`/`RoomReservation` existent. Gestion capacité + plateforme de résa. Lié #144. |
| 48 | timeline dashboard | Partiel | Moyen | Moyen | 1-2j | P2 | Timeline d'activité sur le dashboard. Quelles données (audits ? inscriptions ?). |
| 49 | For all not active event - no email register no confirm | Oui | Fort | Faible | 0.5j | P1 | Ne pas envoyer mails register/confirm si event inactif. **Évite des envois parasites** — bon garde-fou. |
| 50 | AuthO - google - facebook | Oui | Moyen | Moyen | 2-3j | P2 | Social login (Socialite). Auth magic link existe déjà. Quels providers prioritaires ? |
| 51 | état financier (comme demande à Salma) | Non | Fort | Moyen | ? | — | Quel rapport financier exactement ? `CashboardController` existe. Besoin du modèle de rapport attendu. |
| 52 | clean documents SELECT count(*)... | Oui | Moyen | Faible | 0.5j | P2 | Requête de comptage/nettoyage docs. Lié #11/#58. Tâche d'analyse. |
| 53 | Import check if country EXIST | Oui | Moyen | Faible | 2h | P2 | Vérifier que le pays existe (`Country`) à l'import. Lié #34/#39. |
| 54 | présence session masterclass + multiple | Oui | Fort | Moyen | 1-2j | P1 | `ImportPresenceSessions`/`is_present` existent. Gérer présence multi-sessions/masterclass. |
| 55 | Salma pièce jointe problem | Non | ? | ? | ? | — | Quel est le bug exact sur les pièces jointes signalé par Salma ? Repro nécessaire. |
| 56 | save every import in a log file | Oui | Fort | Faible | 0.5j | P1 | Logger chaque import. Forte valeur traçabilité (lié soft delete/audit). Quel niveau de détail ? |
| 57 | send mail to registers add mode + resend | Oui | Fort | Faible | 1j | P1 | Envoyer/renvoyer mail lors d'un ajout manuel de participant. Lié #49. |
| 58 | supprimer les documents pour noms congressistes | Partiel | Moyen | Moyen | 1j | P2 | `is_congressiste` existe. Supprimer docs liés aux congressistes ? Préciser le critère et le pourquoi. |
| 59 | manage events + workshops + attestations | Non | Fort | Fort | ? | — | **Trop large** — recoupe #20/#21/#27/#54. À éclater en sous-tickets. |
| 60 | new Mhamed stats design | Partiel | Moyen | Moyen | 2-3j | P2 | `StatistiqueController`/`EventStatWidget` existent. Refonte UI des stats. Maquette dispo ? |
| 61 | sponsors platforme (prise en charge) | Partiel | Fort | Fort | 1sem | P2 | `Sponsor`/`PriseEnCharge` existent. Plateforme sponsors pour prise en charge participants. Gros périmètre à cadrer. |
| 62 | event validation code (tokens) | Oui | Moyen | Moyen | 1-2j | P2 | `AccessCode`/`AccessCodeService` existent. Code de validation par event. Quel cas d'usage (accès ? validation inscription ?). |
| 63 | Module UX : attestation / documents | Partiel | Fort | Moyen | 2-3j | P1 | Refonte UX du module attestations/documents côté participant. Lié #20/#21. Maquette ? |
| 64 | refactor import users + add meta data | Oui | Fort | Moyen | 1-2j | P1 | `ImportUsers` + `ImportUserMetas`. Refactor + support métadonnées (pattern Meta). Bonne dette à traiter. |
| 65 | participations avec un faux total + interface check TOTAUX | Oui | Fort | Moyen | 1-2j | P1 | `total_price` parfois faux. Interface de contrôle des totaux. **Sujet argent — important.** Lié #6/#51. |
| 66 | app scan MEDIKNODE | Non | Fort | Fort | ? | — | App mobile de scan badge (check-in) ? `is_present`/QR. Natif ou web ? Gros sujet — voir #138. |
| 67 | création de compte - autolog mail existant | Oui | Fort | Moyen | 1j | P1 | Auto-login si email existe déjà à la création. Lié magic link. Attention sécurité (ne pas connecter sans vérif). |
| 68 | bouton annuler validation (ne fonctionne pas) | Oui | Fort | Faible | 0.5j | P1 | **Bug.** `validated_at`/`validated_by`. Annulation de validation cassée — à corriger. Repro utile. |
| 69 | test mail (ne fonctionne pas) | Oui | Fort | Faible | 0.5j | P1 | **Bug.** Fonction « test mail » cassée. Lié #8. Repro nécessaire. |
| 70 | souci export gestion tester BLS workshop | Partiel | Moyen | Faible | 0.5j | P2 | Bug export workshop (`WorkshopListExport`). « BLS » = un atelier précis. Repro nécessaire. |
| 71 | création de badges pour les events en cours | Oui | Fort | Moyen | 1-2j | P1 | `BadgeTemplate`/`ParticipantBadge`/`EventBadge` existent. Générer badges pour events actifs. |
| 72 | delete __events | Oui | Faible | Faible | 1h | P3 | Suppression d'events de test (`__events`). Tâche de cleanup ponctuelle. ⚠️ vérifier dépendances avant. |
| 73 | prettify export abstract | Oui | Moyen | Faible | 0.5j | P2 | Améliorer le rendu de `AbstractsExport`. Cosmétique. |
| 74 | clean MEDIKNODE data | Non | Moyen | Moyen | ? | — | Trop vague. Quelles données ? Recoupe #42/#52/#145. |
| 75 | events@MEDIKNODE.com | Non | Faible | Faible | ? | — | Config d'une adresse email d'envoi ? Tâche admin/infra plutôt que code. |

---

## FPI

| # | Tâche | Clair ? | Intérêt | Impact | Estim. | Prio | Question / Note |
|---|-------|---------|---------|--------|--------|------|-----------------|
| 76 | news + programme | Partiel | Moyen | Moyen | 1-2j | P2 | Pages news + programme pour FPI. Contenu statique ou géré en BO ? |
| 77 | dhamir todos : news partenaire | Non | ? | ? | ? | — | Liste de todos de Dhamir non détaillée. Besoin du détail. |
| 78 | insert TPE or online paiement (register + booking) | Oui | Fort | Moyen | 2-3j | P1 | Paiement TPE/en ligne dans inscription + résa. Lié #139 (Flouci existant). |
| 79 | clean codebase + commit diff codebase #6 | Partiel | Moyen | Moyen | 1-2j | P2 | Nettoyage + commit d'un diff. « #6 » = quel diff ? Lié #142. |
| 80 | ajouter les instances avec Laaroussi | Non | ? | ? | ? | — | Ajout d'instances `.env.*` (multi-instance). Lesquelles ? Coordination avec Laaroussi. |
| 81 | archiver FPI code in github | Oui | Faible | Faible | 1h | P3 | Pousser/archiver le code FPI sur GitHub. Tâche infra. Lié #142. |
| 82 | Do my CV | Oui | — | — | — | — | **Hors périmètre projet** (personnel). |
| 83 | Fix IPGETS PC | Non | — | — | — | — | **Hors périmètre code** (matériel/poste). |
| 84 | remove print accounts | Partiel | Faible | Faible | 0.5j | P3 | Retirer des comptes « print » ? Préciser ce que sont ces comptes. |

---

## KOL AL ARAB

| # | Tâche | Clair ? | Intérêt | Impact | Estim. | Prio | Question / Note |
|---|-------|---------|---------|--------|--------|------|-----------------|
| 85 | update KEA | Non | ? | ? | ? | — | `KeaPageController` existe. « update » = quoi exactement (contenu ? feature ?). |
| 86 | add RIB + link registration with booking | Oui | Fort | Moyen | 1-2j | P1 | Afficher RIB + lier inscription ↔ résa hébergement. Lié #101. |
| 87 | mail participation NOT TN + TN | Oui | Moyen | Faible | 0.5j | P2 | Mails distincts participants tunisiens / non-tunisiens. `is_resident` existe. |
| 88 | not pre-checked payment mode + set missing mode | Oui | Moyen | Faible | 0.5j | P2 | Ne pas pré-cocher le mode de paiement + renseigner mode manquant. Lié #65. |
| 89 | transfer module in bo | Partiel | Moyen | Moyen | 1-2j | P2 | Module de transfert (participants entre events ?) dans le BO. Préciser. |
| 90 | Export datas | Oui | Moyen | Faible | 0.5j | P2 | Export de données KEA. Quel périmètre/colonnes ? |
| 91 | email : information@kol-el-arab-tunis.com | Non | Faible | Faible | ? | — | Config adresse email. Infra. Lié #75. |

---

## 13 MONASTIR

| # | Tâche | Clair ? | Intérêt | Impact | Estim. | Prio | Question / Note |
|---|-------|---------|---------|--------|--------|------|-----------------|
| 92 | abstract button + Hébergement à la fin du processus | Oui | Fort | Faible | 0.5j | P1 | Placer boutons abstract + hébergement en fin de parcours. Lié #131/#132/#16. |
| 93 | comités pages + Export 13Monastir | Partiel | Moyen | Faible | 1j | P2 | Page « comités » + export dédié. Contenu comités géré où ? |
| 94 | fermer hébergement + export data 13JMFM | Oui | Moyen | Faible | 0.5j | P2 | Fermer la résa hébergement + export. Lié #22 (fermeture auto par date). |

---

## JPT

| # | Tâche | Clair ? | Intérêt | Impact | Estim. | Prio | Question / Note |
|---|-------|---------|---------|--------|--------|------|-----------------|
| 95 | news + update JPT + upgrade to Unified | Partiel | Fort | Fort | 1sem | P2 | `JPTPageController` existe. Migrer JPT vers le codebase Unified. Lié #137. Gros chantier. |
| 96 | post event (2h) | Partiel | Moyen | Faible | 2h | P2 | Tâche « post event » de 2h — actions après événement ? Préciser. |
| 97 | config BREVO + Disable BREVO in JPT | Oui | Moyen | Faible | 0.5j | P2 | Désactiver Brevo pour JPT. `BrevoWebhookController` existe. Lié #118. |
| 98 | rule badge number + prestataire + influencer | Oui | Moyen | Moyen | 1j | P2 | Règles de numérotation badge par type (prestataire/influencer). Lié #18. |

---

## AGOB

| # | Tâche | Clair ? | Intérêt | Impact | Estim. | Prio | Question / Note |
|---|-------|---------|---------|--------|--------|------|-----------------|
| 99 | 5min to convince + google drive video | Non | — | — | — | — | Tâche commerciale/contenu (vidéo). Hors code probable. |
| 100 | hébergement + stats + webhooks | Partiel | Fort | Moyen | 2-3j | P2 | Triple sujet à éclater. Webhooks de quoi (paiement ? Brevo) ? |
| 101 | open hébergement + Footer : RIB for hébergement | Oui | Moyen | Faible | 0.5j | P2 | Ouvrir résa + afficher RIB en footer. Lié #86/#47. |
| 102 | add délai + add conditions | Partiel | Moyen | Faible | 0.5j | P2 | Délai + conditions sur quoi (résa ? paiement) ? Préciser. |
| 103 | claude prompt : google drive | Non | — | — | — | — | Note personnelle (prompt). Hors périmètre. |

---

## ATMFM / TUSAMED

| # | Tâche | Clair ? | Intérêt | Impact | Estim. | Prio | Question / Note |
|---|-------|---------|---------|--------|--------|------|-----------------|
| 117 | page comité (ATMFM) | Oui | Moyen | Faible | 0.5j | P2 | Page comités ATMFM. Lié #93. Contenu statique ou BO ? |
| 118 | Disable BREVO + update TUSAMED | Oui | Moyen | Faible | 0.5j | P2 | Désactiver Brevo + maj TUSAMED. Lié #97. |

---

## DIVERS

| # | Tâche | Clair ? | Intérêt | Impact | Estim. | Prio | Question / Note |
|---|-------|---------|---------|--------|--------|------|-----------------|
| 120 | Mhamed tasks mails | Non | ? | ? | ? | — | Tâches mail non détaillées. Besoin du détail. |
| 121 | update CONV + corporate | Partiel | Moyen | Moyen | 1-2j | P2 | `CorporatnodePageController` existe. Maj instance corporate. Préciser. |
| 122 | Tester envoi mail Reprise hébergement avec voucher | Oui | Fort | Faible | 0.5j | P1 | Test du mail de reprise hébergement + voucher. `HebergementPaymentService` existe. Récents commits voucher → pertinent maintenant. |
| 123 | Demander à ChatGPT la meilleure archi storage/images | Oui | Moyen | Moyen | — | P3 | Tâche de recherche/conception. Lié #128. Je peux proposer une archi storage si voulu. |
| 124 | send mailing with doctors table + mail list | Oui | Fort | Moyen | 1-2j | P2 | `Doctor`/`Campaign`/`DiffusionList` existent. Mailing depuis table doctors. Lié module Campaign. |
| 125 | send sms with phone list | Oui | Fort | Faible | 1j | P2 | `SmsCampaign`/`SmsCampaignRecipient` existent. Quel provider SMS ? |
| 126 | reply Maher + deploy SwiftFlow | Non | — | — | — | — | Tâche perso/déploiement externe. Hors périmètre code. |
| 127 | kouaichi.com + import press + send communiqué | Partiel | Moyen | Moyen | 1-2j | P2 | `ImportPress` existe. Import presse + communiqué pour un site. Éclater. |
| 128 | scrapping images for Maher | Non | Faible | Moyen | ? | — | Scraping d'images. Cadre légal ? Hors cœur produit. |
| 129 | Check Whois for all domains | Oui | Faible | Faible | 1h | P3 | Audit Whois des domaines. Tâche infra/admin. |
| 130 | QR Code fond transparent + dans le mail | Oui | Fort | Faible | 0.5j | P1 | QR transparent + intégré au mail. Lié badges/check-in #66/#71. Bon ROI. |
| 131 | toujours afficher hébergement button + abstract button | Oui | Moyen | Faible | 0.5j | P2 | ⚠️ **Contradiction apparente avec #22** (ouverture auto par date). Clarifier la règle voulue. |
| 132 | boutons abstracts toujours ouverts | Oui | Moyen | Faible | 0.5j | P2 | Idem #131 — contradiction avec #22. Trancher : toujours ouvert vs piloté par dates. |
| 133 | leo event + 414 event | Partiel | Moyen | Moyen | 1-2j | P2 | `District414PageController` existe. Setup d'events spécifiques. Détail attendu. |
| 134 | check e-pirana VPS + wincard pour Maher | Non | — | — | — | — | Infra/matériel. Hors code. |
| 135 | W : Elepho | Non | — | — | — | — | Intitulé cryptique. Besoin contexte. |
| 136 | compare with tusamed / FPI : listing des points | Partiel | Moyen | Faible | 0.5j | P2 | Comparer fonctionnalités entre instances. Tâche d'analyse — je peux produire le listing. |
| 137 | create JPT with unified codebase | Partiel | Fort | Fort | 1sem | P2 | = #95. Migration JPT vers Unified. Doublon. |
| 138 | app MEDIKNODE ? + refaire module hébergement ? | Non | Fort | Fort | — | — | Questions stratégiques (= #66 app + refonte hébergement #47). À décider, pas à coder tout de suite. |
| 139 | Konnect - Flouci - Paiement en ligne | Partiel | Fort | Moyen | 2-3j | P1 | Flouci déjà entamé. Ajouter Konnect. Lié #78. Quel provider prioriser ? |
| 140 | Les BO ne doivent pas être indexés | Oui | Moyen | Faible | 1h | P1 | **Déjà fait** via `NoIndexBackend`. Juste vérifier qu'il est appliqué à toutes les routes BO. |
| 141 | Prepare meeting with ADN | Non | — | — | — | — | Tâche perso (réunion). Hors périmètre. |
| 142 | commit all project in bitbucket + remove all hard code | Partiel | Fort | Moyen | 1-2j | P2 | Archivage + suppression du hard-code. Lié #143. « all hard code » très large — cibler. |
| 143 | aucune liste en dur (gouvernorat + mode + pays + specialty) | Oui | Fort | Moyen | 1-2j | P1 | Modèles `Gouvernorat`/`Mode`/`Country`/`Specialty` existent déjà ! → migrer les listes en dur vers la BDD. Bonne dette. |
| 144 | résa new feature (dispo - discount - rules ...) | Partiel | Fort | Fort | 1sem | P2 | Refonte résa : disponibilités, remises, règles. Lié #47/#17. Gros — à cadrer en specs. |
| 145 | query to clean booking old/deleted data | Oui | Moyen | Faible | 0.5j | P2 | Requête de nettoyage des résas obsolètes. Lié soft delete #33. ⚠️ dry-run. |
| 146 | comparateur para + list of para sites | Non | Faible | ? | ? | — | « para » = parapharmacie ? Hors cœur produit événementiel ? Contexte manquant. |
| 147 | manage robots.txt -> sitemap (by site) | Partiel | Moyen | Faible | 0.5j | P2 | Sitemap déjà généré. Reste : robots.txt par instance/site. Lié #25/#140. |
| 148 | GM - W : general metal - notification if fail | Partiel | Moyen | Faible | 0.5j | P2 | Notif en cas d'échec pour client « General Metal ». Lié #10 (monitoring). |
| 149 | 1 heure clean CRONOS + use GitPilot | Non | — | — | — | — | Tâche outillage perso. Hors code produit. |
| 150 | JPC - code generation (6h) | Non | Moyen | ? | 6h | — | Génération de code pour « JPC » — quel besoin précis ? |
| 151 | read all maher mail (1h) | Non | — | — | — | — | Tâche perso (lecture mails). Hors périmètre. |
| 152 | deploy webhook | Partiel | Moyen | Faible | 0.5j | P2 | Déployer un webhook. Lequel (Brevo ? paiement) ? Lié #100. |

---

## Synthèse & recommandations

### Quick wins (fort ROI, < 1j, clairs) — à faire en premier
- **#4** has_evaluation au form edit (1h)
- **#140** vérifier no-index BO (déjà quasi fait)
- **#49** pas de mails pour events inactifs (garde-fou)
- **#68 / #69** bugs : annuler validation + test mail (cassés en prod)
- **#16** récap hébergement à la confirmation
- **#130** QR code transparent dans le mail
- **#56** logger les imports
- **#122** tester mail reprise hébergement + voucher (cohérent avec les derniers commits)

### Chantiers structurants (P0/P1, à cadrer puis planifier)
- **#33 + #36** soft delete généralisé → **décision d'archi** (un seul ticket).
- **#65 + #6** fiabilité des totaux / preuves de paiement → **sujet argent, critique**.
- **#143** sortir les listes en dur (les modèles existent déjà).
- **#22 vs #131/#132** → **contradiction à trancher** : ouverture auto par dates **ou** boutons toujours ouverts ?
- **#34/#39/#53/#64** durcissement & refacto des imports (famille cohérente).

### ✅ Déjà fait (totalement ou en grande partie) — à vérifier puis fermer
Constaté directement dans le code :
- **#140** Les BO ne doivent pas être indexés → middleware `NoIndexBackend` existe déjà. *(reste à vérifier qu'il couvre toutes les routes BO)*
- **#25 / #147** sitemap → commande `GenerateSitemap` + tâche planifiée quotidienne 2h existent. *(reste GA + robots.txt par site)*
- **#4** has_evaluation → le champ existe déjà sur le modèle `Event` (juste à exposer dans le form).
- **#139 / #78** paiement en ligne → `FlouciPayment` + contrôleurs déjà en place (Flouci fait, Konnect à ajouter).
- **#143** listes en dur → les modèles `Gouvernorat`/`Mode`/`Country`/`Specialty` existent déjà en BDD (reste à brancher le front dessus).
- **#33 / #36** soft delete → déjà présent sur 5 modèles (`User`, `Participant`, `Show`, `Doctor`, `Lista`) — donc partiellement fait, à généraliser.
- Infrastructure mailing/SMS/campagnes (#124/#125) → modèles `Campaign`/`DiffusionList`/`SmsCampaign` déjà présents (la « plomberie » existe).

### ❌ Pas intéressants / à ne pas faire en dev (mon avis)
- **#82** (CV), **#83** (Fix PC), **#141** (préparer réunion), **#149** (clean Cronos perso), **#151** (lire mails Maher), **#103** (prompt perso), **#99** (vidéo commerciale) → **tâches personnelles/admin**, aucune valeur produit.
- **#134** (VPS e-pirana / wincard), **#129** (Whois domaines) → **infra pure**, à déléguer hors backlog dev.
- **#128** (scraping images), **#146** (comparateur parapharmacie) → **hors cœur métier** (plateforme événementielle) + zone grise légale pour le scraping. À écarter sauf justification forte.
- **#72** (delete `__events`), **#74/#42/#52** (cleanups data ponctuels) → utiles mais **faible valeur récurrente** : à faire une fois en scripts jetables, pas à prioriser comme features.
- **#123** (demander archi à ChatGPT) → pas une tâche de dev en soi ; je peux te proposer l'archi storage directement si tu veux.

### Doublons / regroupements détectés
- #33 ≡ #36 (soft delete)
- #95 ≡ #137 (migration JPT → Unified)
- #66 / #138 (app mobile MEDIKNODE)
- #47 / #144 / #17 (refonte module hébergement)
- #20 / #21 / #63 (module documents/attestations front)
- #97 / #118 (désactiver Brevo)
- #25 / #147 / #140 (SEO / sitemap / robots / indexation)

### Hors périmètre code (à sortir du backlog dev)
#82 (CV), #83 (PC), #99/#103 (contenu/prompt perso), #126, #129, #134, #141, #149, #151.

### Points trop vagues — j'ai besoin de précisions avant estimation fiable
#5, #8, #12, #28, #35, #51, #55, #59, #74, #77, #80, #85, #120, #135, #138, #146, #150.

---

### Mes questions prioritaires pour toi
1. **#22 vs #131/#132** : règle finale pour abstracts/hébergement — piloté par dates ou toujours ouvert ?
2. **#33/#36** : on valide le soft delete sur **tous** les modèles ? (impact migrations + cascades à tester #29)
3. **#139/#78** : quel provider de paiement prioriser — Flouci (déjà entamé), Konnect, ou TPE ?
4. **#66/#138** : l'app mobile de scan, c'est natif ou une web-app PWA ? (oriente toute l'archi)
5. Pour les bugs (#68, #69, #43, #70) : peux-tu me donner un cas de reproduction ? Je peux les corriger rapidement.