# Coaster World DATA — Cahier des charges fonctionnel v0.1 Date de référence : 27 septembre 2026 ## 1. Vision Coaster World DATA est la plateforme centrale de données de l'écosystème Coaster World. Elle doit constituer une encyclopédie aussi complète et fiable que possible des parcs de loisirs, coasters, attractions et autres POI du monde entier, puis alimenter `coaster-world.com` et l'application mobile via une API stable. Coaster World DATA n'est pas un site grand public. C'est avant tout : **une encyclopédie + un moteur de collecte + un moteur de fiabilisation + une API.** ## 2. Objectifs principaux Le système doit répertorier un maximum de parcs, resorts, coasters, attractions, spectacles, attractions aquatiques, zones thématiques, restaurants, boutiques, hôtels et autres POI utiles. Il doit pouvoir stocker et faire évoluer un grand nombre d'informations : nom, anciens noms, traductions, descriptions, coordonnées, parc et zone, constructeur, modèle, type, propriétaire, exploitant, concepteur, dates d'ouverture et de fermeture, statut, coût, durée de construction, hauteur, longueur, vitesse, inversions, capacité, durée, trains/véhicules, restrictions de taille, accessibilité, propulsion, lift, thème, licences, historique, horaires, médias et liens externes. ## 3. Séparer collecte et donnée canonique Un fournisseur ne doit jamais modifier directement la donnée finale utilisée par Coaster World. Le flux de référence est : **SOURCE → DONNÉE COLLECTÉE → ANALYSE → COMPARAISON → VALIDATION → DONNÉE CANONIQUE → API** Les valeurs contradictoires doivent être conservées avec leur provenance au lieu d'être silencieusement écrasées. ## 4. Traçabilité champ par champ Chaque donnée importante doit pouvoir conserver sa valeur, sa source, sa date de récupération, sa dernière vérification, le fournisseur, l'URL d'origine, un niveau de confiance et, si pertinent, son historique. ## 5. Niveau de confiance La fiabilité doit pouvoir être pondérée selon le type de donnée. Exemple général : source officielle, API officielle, constructeur, base spécialisée fiable, base communautaire, Wikipedia/Wikidata, autres sites, IA non confirmée. Cette priorité doit rester configurable par type de donnée. ## 6. Fournisseurs de données Le système doit accepter des fournisseurs indépendants et extensibles : ThemeParks.wiki, Queue-Times, Wikidata, Wikipedia, OpenStreetMap, IGN, DataTourisme, Foursquare, sites et API officiels de parcs, applications mobiles de parcs, sources spécifiques Coaster World et agents IA. Un fournisseur peut couvrir le monde, un pays, une chaîne, un seul parc ou même une seule attraction. ## 7. Fournisseurs spécifiques à un parc Un connecteur spécifique, par exemple `DisneylandParisProvider`, doit pouvoir fournir uniquement les temps d'attente, horaires ou fermetures d'un parc et devenir la source prioritaire pour ces données dans ce parc. ## 8. Système de providers Chaque provider doit annoncer ses capacités (`park_details`, `attractions`, `wait_times`, `opening_hours`, etc.). L'administration doit permettre de l'activer, le configurer, définir sa priorité et sa couverture, tester sa connexion, consulter ses erreurs et lancer une synchronisation manuelle. ## 9. Temps d'attente Coaster World DATA doit devenir la source unique de temps d'attente pour le site et l'application. Chaque mesure doit au minimum connaître l'attraction, le parc, le temps, l'état ouvert/fermé, une éventuelle panne, les timestamps source/récupération, le fournisseur, la fraîcheur et la fiabilité. ## 10. Historique des temps d'attente Les anciennes mesures doivent être conservées afin de calculer moyennes, tendances par heure/jour/saison, fréquentation, comparaisons et à terme des prédictions. ## 11. Sources indisponibles La panne d'un fournisseur ne doit jamais faire tomber Coaster World. La dernière donnée valide doit rester servie avec un indicateur de fraîcheur (`fresh`, `stale`, etc.). ## 12. Enrichissement IA Depuis une fiche, l'administrateur doit pouvoir demander un enrichissement IA. L'IA peut rechercher des caractéristiques, historiques et informations complémentaires, mais doit proposer les valeurs avec leurs sources et un niveau de confiance. ## 13. Pas de donnée IA non sourcée publiée automatiquement Une valeur trouvée par IA sans source vérifiable peut être conservée comme suggestion non vérifiée, mais ne doit pas devenir automatiquement une donnée canonique Coaster World. ## 14. Recherche universelle L'administration doit être centrée sur une grande recherche : parc, coaster, attraction ou POI. Le résultat doit permettre d'ouvrir, enrichir et actualiser une fiche rapidement. ## 15. Fiche d'une entité La fiche doit montrer clairement les données principales, leur provenance, leur confiance et leur dernière vérification sans surcharger l'interface. ## 16. Enrichissement depuis une fiche Un bouton **Enrichir les données** doit interroger les providers compatibles, présenter les nouvelles informations, les différences et les incertitudes, puis laisser valider ce qui nécessite un contrôle humain. ## 17. Enrichissement automatique À terme, le système pourra identifier une nouvelle entité, chercher ses sources, récupérer et comparer les données, créer ou compléter la fiche puis signaler uniquement les conflits importants. ## 18. Administration simple Navigation cible : Accueil, Recherche, Données, Live, Sources, À vérifier, API, Système. Les détails techniques ne doivent pas envahir l'usage quotidien. ## 19. Création d'une entité L'administrateur doit pouvoir créer un parc, coaster, attraction ou POI, saisir quelques informations de départ puis lancer une recherche automatique pour compléter la fiche. ## 20. Champs extensibles Les données structurantes et très utilisées restent dans des colonnes/tables structurées. Les besoins futurs doivent pouvoir être ajoutés proprement sans transformer la base en un énorme JSON ni imposer une refonte globale. ## 21. Identité indépendante des fournisseurs Chaque objet possède un identifiant Coaster World interne. Les identifiants ThemeParks.wiki, Wikidata, Queue-Times et autres sont associés séparément afin de ne dépendre d'aucun fournisseur. ## 22. Détection des doublons Le système doit rapprocher noms proches, coordonnées, anciens noms et identifiants externes afin d'éviter de créer plusieurs fiches pour la même entité. ## 23. Historique Les modifications importantes (nom, statut, propriétaire, caractéristiques, etc.) doivent pouvoir être historisées afin de conserver une vraie dimension encyclopédique. ## 24. Multilingue Prévoir dès le départ français, anglais, allemand, espagnol et italien, avec possibilité d'ajouter d'autres langues. Les valeurs techniques ne sont pas dupliquées par langue ; les textes et noms traduisibles le sont. ## 25. API Coaster World Le site et l'application doivent consommer une API versionnée et stable. Exemples futurs : `/api/v1/parks`, `/api/v1/parks/{id}`, `/api/v1/parks/{id}/attractions`, `/api/v1/parks/{id}/live`, `/api/v1/coasters/{id}`, `/api/v1/search`. Les évolutions de DATA ne doivent pas casser les anciennes versions de l'application. ## 26. Performance Collecte externe et lecture publique doivent être séparées. Les synchronisations passent par des jobs/workers ; l'API lit des données locales déjà préparées et ne doit pas attendre une source externe. ## 27. Cache Les listes et fiches stables peuvent être fortement mises en cache. Le Live utilise une durée de cache beaucoup plus courte. ## 28. Montée en charge Démarrage simple : Laravel + MySQL + queues/workers + cache + scheduler. Pas de microservices prématurés. L'architecture doit toutefois permettre de séparer des briques plus tard si le trafic l'exige. ## 29. Sécurité Authentification admin, rôles et permissions, CSRF, validation, ORM/requêtes préparées, protection XSS, rate limiting API, secrets providers hors clients, logs d'actions et sauvegardes. ## 30. Supervision Un tableau simple doit montrer l'état de l'API, de la base, des workers et des providers. L'administrateur doit voir rapidement ce qui fonctionne et ce qui est en erreur. ## 31. Sauvegardes Prévoir sauvegardes automatiques de la base et des configurations nécessaires, rétention de plusieurs versions et procédure de restauration testée. ## 32. Mode dégradé IA indisponible, provider en panne ou worker arrêté ne doivent pas empêcher l'API de servir la dernière base valide. ## 33. Médias Les médias pourront être référencés avec leur origine, auteur, licence et droits d'utilisation afin d'éviter les publications non autorisées. ## 34. Score de complétude Une fiche peut afficher un pourcentage de complétude pour identifier ce qu'il reste à enrichir. Ce score mesure la complétude, pas la popularité. ## 35. Fraîcheur Chaque famille de données possède sa propre durée de validité : quelques minutes pour le Live, beaucoup plus pour un constructeur ou une date d'ouverture. ## 36. File « À vérifier » L'administrateur doit surtout voir les exceptions : valeurs contradictoires, attraction potentiellement fermée, nouvelle entité, renommage, provider inaccessible, etc. ## 37. Données brutes Conserver temporairement, lorsque c'est utile et permis, les réponses brutes des providers pour diagnostiquer, refaire un mapping ou améliorer un importer. La rétention doit rester maîtrisée. ## 38. Statistiques providers Chaque provider pourra présenter sa couverture, le nombre de données utilisées, les erreurs, la fiabilité constatée, le temps de réponse et la dernière synchronisation. ## 39. Priorités 1. Exactitude — une donnée inconnue vaut mieux qu'une donnée fausse. 2. Disponibilité — le site et l'app doivent continuer à fonctionner. 3. Traçabilité — toujours savoir d'où vient une information. 4. Complétude — collecter le maximum pertinent. 5. Automatisation — automatiser sans perdre la maîtrise. 6. Simplicité — garder l'administration compréhensible. ## 40. Ce que DATA ne doit pas devenir Pas d'usine à gaz, pas de multiplication de pages techniques, pas de dépendance au terminal pour l'usage quotidien, pas de copie brute d'API, pas d'IA écrivant sans contrôle, pas d'architecture enfermée dans un fournisseur. ## 41. Parcours d'administration cible **Je cherche → j'ouvre → j'enrichis → je vérifie les conflits éventuels → je valide → la donnée est publiée via l'API.** ## 42. Architecture logique Cinq briques : - **Base centrale** : données canoniques Coaster World. - **Collecte** : providers/connecteurs externes. - **Intelligence** : comparaison, rapprochement, doublons, IA, validation. - **Administration** : recherche, enrichissement, correction, supervision. - **API** : distribution rapide et stable au site et à l'application. ## 43. Phases de développement 1. Base propre : parcs, attractions, coasters, POI, organisations, sources et identifiants externes. 2. Administration minimale : recherche universelle + fiches principales. 3. Moteur providers : contrat commun pour brancher n'importe quelle source. 4. Premiers enrichissements : ThemeParks.wiki, Wikidata, Wikipedia, etc. 5. Validation/provenance : comparaison, confiance et conflits. 6. API publique versionnée. 7. Live et historique des temps d'attente. 8. IA d'enrichissement. 9. Providers spécifiques à des parcs. 10. Automatisation avancée. Chaque phase doit être terminée, vérifiée et validée avant de passer à la suivante. ## 44. Règle de développement Aucune fonction n'est développée uniquement parce qu'elle pourrait être intéressante. Elle doit améliorer la donnée, sa fiabilité, sa collecte, sa distribution, son administration, sa disponibilité ou sa sécurité. ## 45. Objectif final À terme, l'administrateur doit pouvoir demander d'ajouter un parc et laisser DATA identifier le parc, ses coordonnées, propriétaire, horaires, attractions, coasters, constructeurs, caractéristiques, sources officielles, éventuels temps d'attente, médias autorisés et contradictions, puis ne demander que les validations réellement nécessaires. Les données validées sont ensuite immédiatement disponibles pour `coaster-world.com` et l'application Coaster World.