Ce projet, l’un des plus conséquents de ma formation, est la suite directe du travail mené en S3 sur l’application web de gestion de jeux de société. En S4, nous avons repris l’existant pour l’optimiser et l’enrichir : refonte et normalisation du schéma de base de données, ajout d’index, amélioration des performances SQL, développement de nouvelles fonctionnalités majeures comme un système de réservation et de suivi des boîtes de jeux, l’ajout de filtres de recherche avancés pour l’administration et les utilisateurs, la gestion de l’historique des jeux, la création d’une interface d’administration plus complète, ainsi qu’une refonte partielle du design et la documentation technique détaillée.
J’ai approfondi mes compétences en PHP, SQL et HTML/CSS, et j’ai mieux compris les enjeux de l’optimisation des systèmes web dynamiques. J’ai aussi appris à utiliser Git Flow pour la gestion de projet en équipe, ce qui était nouveau pour moi : cela nous a permis d’organiser le travail de façon plus structurée, de mieux gérer les branches et d’éviter les conflits, contrairement aux méthodes plus simples utilisées auparavant. Mais surtout, cette expérience m’a appris à ne jamais me contenter de la première version d’une solution : au départ, notre application était fonctionnelle, mais pas assez performante ni agréable à utiliser. J’ai compris que l’optimisation, c’est aller au-delà du « ça marche » : il faut toujours chercher à améliorer, à remettre en question ses choix, à tester différentes approches. Cette remise en question permanente m’a permis de progresser, de gagner en rigueur et de prendre confiance dans ma capacité à trouver des solutions plus efficaces et plus élégantes, même face à la complexité d’un projet déjà existant.
L’une des difficultés majeures a été d’améliorer un existant en groupe : il n’est pas toujours évident d’avoir tous la même vision, ni de se mettre d’accord sur les priorités ou les choix techniques. Il a fallu apprendre à écouter les idées de chacun, à argumenter, à faire des compromis, et à penser au projet dans son ensemble plutôt qu’à sa propre partie. Un autre défi a été la refonte et l’optimisation de la base de données : il a fallu revoir entièrement la structure existante pour intégrer les nouvelles fonctionnalités, tout en garantissant la cohérence et la performance. Pour y parvenir, nous avons organisé des réunions régulières pour confronter nos idées, tester différentes solutions, et valider collectivement chaque étape avant de passer à la suivante. J’ai aussi appris à accepter les critiques constructives de mes coéquipiers et à transformer les retours en axes d’amélioration concrets. Cette démarche collaborative et itérative a permis d’obtenir un résultat bien plus abouti que si chacun avait travaillé isolément.
Cette expérience m’a permis de prendre du recul sur la conception d’applications, de développer mon sens du détail et de la performance, et de renforcer ma capacité à anticiper les besoins utilisateurs. J’ai aussi gagné en autonomie dans la gestion de projets techniques et en rigueur dans l’optimisation de solutions existantes.
J’ai participé à la mise en place des algorithmes de recommandation et à l’analyse de leur complexité
(temps/mémoire). Pour les activités par exemple, nous avons représenté les contenus et le profil utilisateur
sous forme de vecteurs, puis calculé une distance pour classer les résultats (Top 3 + suggestions).
J’ai aussi étudié quelles parties pouvaient devenir coûteuses quand le volume de données augmente, et j’ai
contribué à simplifier/optimiser certains traitements pour garder une application fluide sur smartphone.
J’ai appris à raisonner en optimisation au-delà du “ça marche” : comparer plusieurs approches (scoring, pondérations, distance), mesurer l’impact en performance, et adapter les calculs aux contraintes du mobile (fluidité, mémoire, consommation de ressources).
La difficulté a été de faire tourner 3 algorithmes de recommandation tout en gardant de bonnes
performances et des résultats cohérents. Chaque algo n’avait pas exactement les mêmes critères, et comme nous
n’avions pas tous les mêmes goûts, il fallait éviter que les recommandations paraissent “bizarres” ou
injustifiées.
On a donc comparé plusieurs pondérations/scorings, limité certains traitements pour rester rapide, et validé
les compromis via des tests sur différents profils (et pas seulement nos propres préférences).
Nous avons commencé par créer une interface graphique en Python avec Pygame afin d’afficher le
rendu du diagramme. L’une des premières étapes a été de gérer le chargement du fichier contenant les points
(coordonnées), puis de stocker ces points pour le calcul.
Les points ont ensuite été transformés en “germes”, chacun ayant une position et une représentation graphique.
Pour générer le diagramme, nous avons utilisé une méthode basée sur le calcul de distance : pour chaque
pixel de l’écran, la distance à tous les points est calculée, puis on attribue la couleur du point le plus
proche.
Les données étaient stockées dans un fichier JSON afin de pouvoir modifier/ajouter des points
facilement
sans toucher au code, et nous avons ajouté une fonctionnalité d’export en image PNG ainsi qu’une
palette
de couleurs plus cohérente pour améliorer la lisibilité.
Cette SAÉ m’a appris à aborder un sujet mathématique/théorique et à le rendre concret via une visualisation
interactive. J’ai aussi mieux compris l’impact de la complexité sur la performance : la boucle “pixel par
pixel” peut rendre l’exécution lente.
Le projet a aussi été enrichi par la comparaison avec des solutions proposées par des IA : nous avons
développé certaines parties par nous-mêmes puis utilisé des IA pour explorer d’autres approches (logique de
calcul, optimisation), ce qui m’a permis de mieux comprendre les choix techniques derrière chaque solution.
J’ai aimé comparer ce que nous avions développé nous-mêmes avec différentes propositions d’IA. Certaines approches donnaient très vite un résultat convaincant, et d’autres étaient au final plus lourdes que notre solution : nous avons parfois été plus rapides avec une méthode plus simple, pour un rendu équivalent, en consommant moins de ressources et avec moins de lignes de code (donc une solution plus “sobriété numérique”).
Le principal inconvénient du projet a été la performance : le calcul repose sur une boucle qui teste
chaque pixel de l’écran, ce qui rend l’exécution assez lente. De plus, le projet restait limité à une certaine
plage de points.
Pour avancer, nous avons procédé progressivement : tests réguliers, ajustements à partir du rendu affiché et
comparaison de plusieurs approches (y compris avec l’aide d’IA) pour identifier des pistes d’optimisation.