Jeu de blackjack en réseau

Cette réalisation a été menée dans le cadre de la SAE 4.01 : Développement d’une application complexe du BUT Informatique, entre janvier et mars 2023, dans une période où les projets de formation demandaient déjà une approche proche d’un vrai cycle de développement logiciel. Le projet ne consistait pas seulement à produire une application fonctionnelle, mais à traiter un besoin, à le cadrer, à l’analyser, à le concevoir, à le développer en équipe et à en justifier les choix techniques et organisationnels.

Le sujet a été proposé par M. Guinaldo, enseignant tuteur, avec un rôle proche de celui d’un commanditaire. Les échanges menés avec lui ont permis de préciser les technologies attendues, les règles du jeu, les contraintes réseau et certaines orientations comme l’usage de C/C++, SDL pour la partie graphique, SQLite pour les statistiques et un hébergement pensé pour fonctionner sur le réseau local de l’IUT.

Le projet consistait à concevoir Gamblitz, un jeu de blackjack multijoueur en réseau local, basé sur une variante dite “3 dés” du blackjack classique. Le principe était de permettre à plusieurs joueurs de créer ou rejoindre une partie, de jouer simultanément, de gérer une réserve de jetons, de suivre les scores et de faire circuler l’ensemble des informations via une architecture client-serveur commune aux versions console et graphique.

Le périmètre comprenait plusieurs briques : une version console pour stabiliser rapidement les règles du jeu, une version graphique avec SDL2, une base de données SQLite pour conserver certaines statistiques, et un site web statique de présentation du jeu et de ses règles. Cette combinaison en faisait un projet particulièrement complet, à la fois réseau, applicatif, graphique et méthodologique.

Le contexte du projet était à la fois pédagogique et professionnalisant. La SAE demandait de structurer le travail comme un véritable projet logiciel, avec analyse du besoin, maquettes, conception, diagrammes, planification, développement, qualité et bilan, ce qui imposait déjà une logique d’ingénierie et non un simple enchaînement de tâches techniques.

Les objectifs étaient multiples. Sur le plan technique, il fallait développer une application client-serveur en C/C++, gérer les communications réseau sur le standard POSIX, intégrer une base SQLite, proposer une version console puis une version graphique avec SDL2, et mettre en place des pratiques de tests et d’intégration continue. Sur le plan méthodologique, l’objectif était aussi de mieux travailler en équipe, d’utiliser des outils de gestion de projet, de suivre l’avancement dans le temps et de produire des livrables cohérents avec les attentes de la formation.

Les principaux enjeux portaient sur la complexité réseau, la montée en compétence sur des technologies peu familières, la difficulté de produire une interface graphique légère avec SDL2, et la nécessité de livrer quelque chose de crédible dans un temps limité. Plusieurs risques avaient été identifiés dès le départ : sous-estimation de la charge réelle, bugs sur la liaison client-serveur, dépendance à des contraintes externes comme l’authentification LDAP, et temps de développement plus élevé que prévu sur les briques les plus sensibles.

Le projet a commencé par une phase de cadrage, avec formalisation du besoin, clarification des règles, définition des objectifs, rédaction de user stories, réalisation de maquettes et première structuration du périmètre. Cette étape a transformé une idée de jeu en une base de travail exploitable, avec une vision plus claire des fonctionnalités attendues et des contraintes techniques.

Le projet a été mené en équipe de cinq étudiants : Marc Thiery, Hugo Thibon, Noé Garnier, Matis Mazingue et moi-même. La complémentarité des profils a facilité la répartition initiale des tâches, même si certaines briques, notamment le réseau et l’interface graphique, ont demandé des réajustements au fil de l’avancement.

Le principal interlocuteur externe était M. Guinaldo, à la fois tuteur, initiateur du sujet et référent fonctionnel. Les entretiens menés avec lui ont permis de préciser les technologies à utiliser, le fonctionnement du serveur, les statistiques à conserver, les modalités de jeu et le niveau de priorité de certaines fonctionnalités. Son rôle était donc proche de celui d’un client ou d’un responsable de besoin, avec une vraie influence sur l’orientation du projet.

Les interactions internes reposaient sur des réunions régulières, des échanges sur Discord, un kanban, un backlog, des wikis individuels et des points de suivi avec le tuteur. Cette organisation a amélioré la communication dans l’équipe, rendu les contributions plus visibles et facilité les réaffectations de tâches quand certaines zones du projet se révélaient plus complexes que prévu.

Le projet a abouti à une application de blackjack multijoueur en réseau local, structurée autour d’une architecture client-serveur, avec une version console fonctionnelle, une version graphique avancée, une base SQLite pour les statistiques et une documentation technique et méthodologique conséquente. Même si certaines ambitions initiales n’ont pas été finalisées intégralement, notamment sur certaines extensions ou finitions, le résultat livré restait suffisamment abouti pour démontrer la cohérence du projet et la solidité de son architecture.

Pour moi, le résultat principal ne se limite pas au produit final. Cette réalisation m’a permis de consolider des compétences en gestion de données, en qualité logicielle, en organisation de projet, en travail d’équipe et en articulation entre contribution technique et logique collective. Elle a marqué une étape importante dans ma manière d’aborder un projet : moins comme une succession de fonctionnalités à coder, davantage comme un ensemble cohérent à concevoir, suivre et faire évoluer.

À la fin de la SAE, plusieurs pistes d’évolution restaient ouvertes. Le projet pouvait être prolongé avec une finalisation plus complète de l’interface graphique, l’ajout d’options de configuration des parties, l’amélioration du tableau des scores, une visualisation plus poussée des statistiques ou encore un approfondissement des mécanismes d’authentification. Le projet constituait donc une base solide, mais non figée, sur laquelle de nouvelles itérations étaient envisageables.

Avec du recul, les effets les plus durables de cette réalisation se situent surtout dans ma manière de travailler aujourd’hui. Cette expérience m’a rendu plus attentif à la planification, à la répartition réelle des tâches, à l’anticipation des risques et à la nécessité de disposer d’outils de suivi concrets pour éviter de subir le projet en fin de parcours.

Avec le recul, cette réalisation reste l’une des plus formatrices de mon parcours en BUT. Elle m’a confronté à un projet plus ambitieux que ceux menés auparavant, avec suffisamment de complexité pour faire apparaître les limites d’une planification trop optimiste, les difficultés de coordination d’équipe et l’écart fréquent entre un périmètre imaginé au départ et ce qu’il est réellement possible de livrer dans le temps imparti.

Elle m’a aussi appris qu’un projet ne se réussit pas uniquement par la technique. Les outils de suivi, la qualité de la communication, la documentation, la clarté des rôles et la capacité à réajuster le périmètre ont eu un impact aussi important que le code lui-même. C’est probablement l’enseignement le plus utile que je retiens de cette expérience, parce qu’il rejoint directement la posture attendue dans un parcours d’ingénierie logicielle.

Enfin, cette réalisation a marqué une progression importante dans ma façon de me situer dans un collectif. Elle m’a fait gagner en rigueur, en autonomie, en capacité à contribuer à une architecture plus large et en compréhension du lien entre contribution personnelle et réussite d’ensemble.