UE1 - Réaliser un développement

Concevoir et développer des applications informatiques

Je vous présente Néo

Au début du premier film, Néo ne sait rien de ce qu'il est capable de faire. Il n'est pas né développeur senior : il apprend en avançant, par la pratique, par l'essai-erreur, par les murs dans lesquels il se cogne littéralement — le premier saut entre deux immeubles ressemble beaucoup à un premier déploiement en prod qui ne se passe pas comme prévu. Aucun don magique au départ, juste de la persévérance et des heures passées devant l'écran la nuit, à essayer de comprendre un système qui ne dit pas tout.

Et puis il y a « Sony Handerson ». Si vous avez déjà vu une version pirate mal sous-titrée de Matrix, vous savez de quoi je parle : "Mr. Anderson" devient, au gré d'une traduction automatique ratée, un improbable "Sony Anderson" — un bug de traduction culte. Apprendre à développer, c'est un peu ça : on tape du code en croyant avoir écrit "Anderson", et le compilateur répond "Sony Handerson" — une erreur qu'on ne voit pas venir et qu'il faut débugger sans s'énerver.

Qu'est-ce que l'UE1 ?

"Réaliser un développement", c'est l'UE la plus "mains dans le cambouis" du parcours : écrire du code, le faire tourner, comprendre pourquoi il ne tourne pas, le corriger, recommencer. Pas de théorie abstraite ici — on prend un besoin, on le traduit en algorithme puis en code, on teste, on casse, on répare. C'est l'UE où on apprend le métier en le pratiquant, ligne après ligne.

Mes projets SAE

Anime Rivals — SAE 2e année

Contexte : Projet de SAE sur l'année consistant à développer une application web de jeu de cartes. Le projet repose sur une réinvention des règles de la bataille et du Top Trump afin de proposer une expérience de jeu plus stratégique et dynamique.

Ce qui a été fait : Développement de plusieurs éléments centraux du jeu : implémentation des bots avec différents comportements, système de résolution des duels et des manches, gestion des decks (composition, utilisation des cartes, cycle de jeu), mise en place du système de boutique permettant d'obtenir ou d'améliorer des cartes.

Difficultés : La principale difficulté a été d'implémenter correctement des règles de jeu originales tout en garantissant un fonctionnement cohérent. La gestion des enchaînements de duels et des manches a nécessité une attention particulière pour éviter les incohérences ou bugs.

Ce qui a été appris : Ce projet a permis de renforcer la logique algorithmique, la structuration du code, et la capacité à transformer des règles théoriques en comportements programmés.

Ressenti : Projet très formateur techniquement, avec une forte dimension concrète. Le fait de développer un jeu complet permet de voir immédiatement l'impact du code sur l'expérience utilisateur.

Voir le projet →

Fête des Lumières 2025 — Application Java Swing (IHM)

Contexte : Interface graphique Java Swing pour la visualisation et la comparaison de trajets calculés par l'application de graphe. L'IHM permet d'importer des points, générer des points aléatoires, visualiser un trajet sur une carte ou un plan, et comparer les performances des algorithmes.

Ce que j'ai fait : J'ai développé la frame principale et les panneaux d'interface : bannière, menu, boutons de contrôle, panneau carte/plan avec zoom et déplacement, et une fenêtre de comparaison des algorithmes. J'ai aussi géré l'import/export de fichiers et la synchronisation de l'affichage avec l'état des calculs.

Difficultés : Synchroniser l'état des parcours calculés avec l'affichage graphique, gérer différents formats de coordonnées, et intégrer des composants Swing externes (ex : JXMapViewer). Les interactions entre le panneau de droite et la carte centrale ont nécessité plusieurs itérations pour un comportement propre.

Ce qui a marché : L'architecture UI modulaire (CardLayout, listeners) et le dessin personnalisé des trajets fonctionnaient bien localement. L'application rechargeait les données, affichait les trajets et proposait une comparaison visuelle des résultats.

Ressenti : Projet formateur pour l'ergonomie et la structuration d'une IHM desktop. J'ai apprécié rendre visible le résultat d'algorithmes abstraits.

Capture de l'interface de comparaison de trajets

Gestion de clients — Application console en C

Contexte : Projet de première année consistant à développer un gestionnaire de clients en langage C, avec une interface en ligne de commande. L'application permet de charger, ajouter, modifier, supprimer, afficher, rechercher, trier et filtrer des clients, avec sauvegarde automatique dans un fichier CSV.

Ce qui a été fait : Conception complète du programme modulaire : structures de données (CLIENT), lecture/écriture de fichiers, menu interactif, fonctions de gestion (ajout, modification, suppression), affichage avec tri selon plusieurs critères (nom, code postal, profession, date de naissance), recherche par nom/prénom/téléphone/email, filtrage par critères multiples, calcul de l'âge à partir d'une date de référence saisie par l'utilisateur. Gestion des cas particuliers (champs vides, clé primaire basée sur le téléphone).

Difficultés : La gestion des chaînes de caractères en C (buffer overflow, nettoyage du tampon d'entrée), le parsing de fichiers CSV avec des séparateurs, la manipulation dynamique des tableaux de structures, et la mise en place d'un menu robuste sans erreurs de saisie.

Ce qui a été appris : Maîtrise des pointeurs, des chaînes, des entrées/sorties, de la modularité (fichiers .h et .c), et des bonnes pratiques de validation des données. Découverte de l'importance de la clé primaire et de la cohérence des données.

Ressenti : Projet fondateur, très concret, qui donne une vision complète du cycle de vie d'une application console, du code à la sauvegarde persistante.

Voir le code source (exemple) →

Expériences professionnelles

Stage SNCF — Projet Ripley (observabilité des métriques systèmes)

Contexte : Stage de fin de 2e année de BUT Informatique au sein de la SNCF Voyageurs, division Econova — équipe des experts Bases de données (DBA). Mission : redynamiser l'application Ripley, un outil d'observabilité permettant de collecter, stocker et restituer des métriques systèmes et bases de données. Durée : 8 à 12 semaines en autonomie.

Ce qui a été fait : Conception et implémentation de zéro de la partie collecte et stockage des métriques systèmes du projet Ripley. Le projet se décompose en plusieurs lots : métriques système (Lot 1), métriques bases de données (Lot 2), métriques applicatives (Lot 3), indicateurs fonctionnels (Lot 4). J'ai dû concevoir une base de données non seulement pour le Lot 1, mais avec suffisamment de recul pour que le schéma reste extensible aux lots suivants sans remettre en cause les travaux déjà réalisés.

Difficultés : Anticiper les besoins des lots futurs dès la conception du Lot 1 a été la principale difficulté. Les décisions de modélisation étaient fortement irréversibles : une erreur en amont se paie cher plus tard. Adapter le schéma au passage Lot 1 → Lot 2 sans tout casser a aussi posé problème, notamment avec les métriques BD qui admettaient des valeurs non numériques.

Ce qui a été appris : Comprendre que la maintenabilité et l'évolutivité sont des contraintes de conception, pas des bonus optionnels. J'ai aussi appris à épurer un modèle : une base industrielle orientée volumétrie n'est pas une base académique qui cherche la complétude. Découverte du MCT (Modèle Conceptuel de Traitement) comme modèle Merise inexistant dans ma formation mais pertinent en contexte professionnel.

AC validés : AC 4.01.01 (choisir et implémenter les architectures adaptées), AC 4.01.02 (faire évoluer une application existante), AC 4.01.03 (intégrer des solutions dans un environnement de production).

Ressenti : Stimulant et parfois intimidant. La responsabilité de concevoir quelque chose qui sera utilisé en production par une équipe d'experts n'était pas anodine. Fier du résultat.

« Je ne savais pas écrire une seule ligne sans planter le programme entier. Maintenant, je sais juste où regarder en premier. C'est déjà beaucoup. »
— Néo