Projet 01 / Étude de cas
Prototype expérimental fonctionnelUn prototype local pour explorer des profils League of Legends, leurs parties et des statistiques observées. Mon premier projet pour apprendre à relier une interface, une API et des données.
Lire l’expérience
Capture du prototype local. Le profil et les statistiques présentés sont simulés.
Prototype expérimental fonctionnel en local, non déployé publiquement. Le mode réel nécessite une clé Riot privée côté serveur ; un mode démonstration distinct utilise des profils fictifs. Aucune démonstration publique, clé API ou base SQLite n’est accessible depuis ce portfolio.
01 / Présentation
L’idée de départ : explorer ce qu’il est possible de construire autour des données de League of Legends. Les plateformes d’analyse existantes ont donné envie d’essayer, à l’échelle d’un projet personnel.
Le projet a progressivement relié une interface Nuxt aux API officielles Riot, puis à une collecte locale et à des statistiques issues des parties. L’objectif était de découvrir ces outils et leurs limites en construisant un résultat concret.
02 / Objectifs
03 / Réalisation technique
Nuxt 4, Vue 3 et TypeScript structurent les pages et les contrats de données. Les composants d’interface sont réutilisés, avec Tailwind CSS et des styles dédiés. Le portfolio et LoL Analytics restent deux applications autonomes dans un monorepo pnpm.
Les services Account-v1, Summoner-v4, League-v4 et Match-v5 permettent de retrouver un compte, son profil, son classement et ses matchs. La clé reste côté serveur. Un cache, la déduplication et la gestion de Retry-After limitent les appels inutiles ; Data Dragon fournit les ressources officielles.
Les matchs et timelines Match-v5 sont collectés en quantité bornée. Weekly Meta utilise SQLite avec déduplication et séparation des patchs. Les statistiques personnelles partent du propre historique du joueur, distinct de l’échantillon multi-joueurs.
Cartes, tableaux et graphiques présentent les résultats avec leurs échantillons. Les tests Playwright couvrent les calculs, les erreurs et les parcours. Git, GitHub, les pull requests et les vérifications automatisées accompagnent les changements par étapes.
04 / Méthode & IA
J’ai utilisé des assistants de développement IA pour produire et faire évoluer le code. Mon travail a consisté à définir les objectifs, préciser les contraintes, essayer les versions en local et demander des corrections à partir des problèmes rencontrés.
Le projet a avancé par sprints et pull requests : démonstration, intégration Riot, exploration des données, statistiques personnelles, puis présentation visuelle. Cette méthode m’a permis d’expérimenter un dialogue de travail avec des agents IA et d’apprendre à examiner leurs résultats.
05 / Le prototype en images
Toutes les captures ci-dessous utilisent des données de validation simulées. Elles ne montrent pas les véritables statistiques de mon compte. Le prototype peut utiliser les API Riot réelles lorsqu’il est configuré localement.
La recherche au premier plan, avec des modes réel et démonstration explicitement séparés.
Ouvrir la capture complète
Une navigation adaptée au petit écran pour retrouver le profil, les statistiques et l’historique.
Ouvrir la capture complète
Un historique filtrable et des cartes de match pour relier les chiffres aux parties observées.
Ouvrir la capture complète
Des métriques accompagnées de leur couverture, de leurs définitions et des limites des timelines.
Ouvrir la capture complète
Des fréquences d’observation et des confrontations descriptives, sans les présenter comme un meilleur build ou une tierlist.
Ouvrir la capture complèteLeague of Legends et les visuels associés appartiennent à Riot Games. Projet personnel, non affilié à Riot Games.
06 / Difficultés rencontrées
Une clé de développement et les limites de requêtes imposent une collecte raisonnable. Les erreurs, les délais Retry-After et la reprise doivent rester compréhensibles, sans remplacer une panne par des données fictives.
Un compte peut être non classé, un match incomplet ou une timeline absente. Une valeur indisponible et sa raison sont plus utiles qu’un chiffre inventé.
Une base locale limitée ne décrit pas toute la région EUW. Les patchs, rôles et dénominateurs doivent rester visibles. Un objet fréquent n’est pas automatiquement le meilleur choix.
Les solo kills reposent sur les assistances enregistrées. Les morts isolées et la proximité du jungler utilisent des positions échantillonnées : ce sont des estimations, avec des cas non évaluables et des dénominateurs propres.
Un outil personnel peut fonctionner en local sans être prêt pour une ouverture publique. Les quotas, la confidentialité des données, l’exploitation et la maintenance demanderaient un travail supplémentaire.
07 / Ce que j’ai appris
08 / Résultat
Le résultat est un prototype expérimental fonctionnel en local, avec un mode Riot réel et une démonstration distincte. Il permet de parcourir une chaîne complète : récupérer des données, les stocker, les traiter et les rendre lisibles.
J’ai choisi d’arrêter l’ajout de fonctionnalités après avoir atteint mes objectifs d’apprentissage. Cette étude de cas conserve une trace de l’expérience, de la méthode et des limites du projet.
Pour aller plus loin, il faudrait notamment étudier la robustesse sur davantage de cas et les conditions d’une éventuelle ouverture publique. Ces pistes ne constituent pas un engagement de développement.
Une première exploration, documentée pour garder une trace du chemin parcouru.
Retour aux projets