Exploration GitHub
Ouvrir d’anciens projets, les nettoyer, les documenter et comprendre ce qu’ils racontent de mon évolution : du C et des contraintes bas niveau jusqu’à une application web complète.
De 42 Brussels à un portfolio technique lisible.
La majorité de ces projets a été réalisée pendant le cursus principal de 42 Brussels. Ils partent de sujets volontairement contraints : peu de bibliothèques, des comportements à reconstruire et une évaluation qui oblige à expliquer ses choix.
L’intérêt n’est pas de publier du « code scolaire » tel quel. Cette exploration reprend les dépôts les plus représentatifs pour montrer différents types de problèmes, le raisonnement qu’ils imposent et la progression entre programmation bas niveau, systèmes, réseau, infrastructure et web.
Six étapes, une progression.
Chaque projet isole une difficulté différente. Ensemble, ils montrent une façon de lire les contraintes, de construire une solution et de la rendre compréhensible.
-
Algorithmique sous contraintes
push_swap
- C
- Piles
- Tri
- Complexité
Trier une suite d’entiers avec deux piles et un nombre très limité d’opérations oblige à penser la stratégie avant l’implémentation. Bien que push_swap soit un projet de tri algorithmique, sa difficulté vient du fait que le tri doit être traduit en une suite de déplacements physiques contraints entre les deux piles. J’ai d’abord exploré le Turk algorithm, puis je l’ai abandonné parce que ses résultats n’étaient pas assez optimisés pour l’objectif que je visais.
Je me suis ensuite orienté vers une distribution par chunks et pivots, dans une logique que j’appelais « papillon ». Après avoir retenu cette piste, j’ai constaté que d’autres utilisaient une approche similaire sous le nom Butterfly et obtenaient de bons résultats. Cela m’a conforté dans le choix d’aller au bout de cette solution et d’en affiner le fonctionnement.
Consulter le repository ↗
-
Processus concurrents
Philosophers
- C
- Threads
- Mutex
- Sémaphores
Une mise en œuvre du Dining Philosophers Problem en deux approches distinctes. La version mandatory repose sur des threads partageant la même mémoire, synchronisés avec des mutexes pour gérer l’accès aux fourchettes et protéger l’état commun. La version bonus reprend le même problème avec des processus indépendants, coordonnés par des sémaphores, ce qui oblige à repenser la synchronisation et la surveillance avec un modèle d’exécution différent.
Le projet met en évidence les risques de course, de blocage et de famine, mais surtout la nécessité de raisonner sur l’ordre des événements et l’accès aux ressources partagées, plutôt que sur une simple suite d’instructions.
Consulter le repository ↗ -
Réseau et protocole HTTP
WebServ
- C++98
- Sockets
- HTTP
- CGI
Un serveur HTTP/1.1 développé en C++98 : lecture de configuration, sockets, parsing des requêtes, méthodes GET, POST et DELETE, CGI, uploads, redirections, pages d’erreur et serveurs virtuels.
Le projet relie le protocole à son exécution concrète : recevoir une connexion, interpréter la requête, résoudre la configuration et la route, effectuer le traitement approprié puis construire une réponse valide. Il demande de gérer des flux partiels, des états de connexion, des erreurs et plusieurs clients simultanément, sans masquer la complexité derrière un framework.
Consulter le repository ↗
-
Graphisme et représentation spatiale
cub3D
- C
- Raycasting
- MiniLibX
- Collisions
Un petit moteur de raycasting en C, inspiré des techniques qui ont rendu possibles les premiers FPS comme Wolfenstein 3D : parsing d’une carte 2D, projection d’un rayon par colonne d’écran, parcours DDA, calcul des distances, textures, déplacements et collisions. Projet réalisé en collaboration.
Le rendu est volontairement resté simple : l’objectif était avant tout de comprendre comment transformer une grille 2D en espace pseudo-3D navigable, à une époque où les développeurs ne disposaient pas de moteurs graphiques modernes et devaient construire eux-mêmes leurs solutions de rendu sous de fortes contraintes matérielles.
Consulter le repository ↗
-
Infrastructure conteneurisée
Inception
- Docker
- Nginx
- PHP-FPM
- MariaDB
Une infrastructure composée de services isolés, notamment Nginx, WordPress avec PHP-FPM et MariaDB, reliés par un réseau Docker et des volumes persistants.
Le projet déplace l’attention du code vers l’exploitation : configuration par environnement, responsabilités des services, persistance des données et reproductibilité du déploiement.
Consulter le repository ↗ -
Application web complète
ft_transcendence
- Next.js
- React
- TypeScript
- Fastify
- SQLite
- Docker
Une application full-stack collaborative autour d’un Pong, enrichie de tout l’écosystème d’un véritable produit web : comptes, sécurité, profils, amis, statistiques, historique, tournois et plusieurs modes de jeu.
L’enjeu n’était plus de faire fonctionner une fonctionnalité isolée, mais de faire cohabiter interface, API, données, authentification, logique de jeu et conteneurisation dans une application unique et cohérente.
Consulter le repository ↗
D’autres fondations du parcours.
Trois projets plus compacts complètent le récit sans diluer les six réalisations principales.
Minishell
Reconstruction d’un shell Unix : parsing, exécution, processus, pipes et redirections. Projet réalisé en binôme, jamais présenté comme un travail entièrement solo.
- C
- Parsing
- Processus
Pipex
Reproduire la circulation des données dans un pipeline Unix avec fork, execve, pipes, redirections et gestion rigoureuse des descripteurs de fichiers.
- C
- fork
- execve
- File descriptors
So_long
Un petit jeu 2D développé en C avec MiniLibX : parsing de cartes, déplacements, collecte et première boucle graphique du cursus.
- C
- MiniLibX
- Jeu 2D
Le code est public.
Le raisonnement compte davantage.
Ces dépôts montrent des étapes de travail, avec leur contexte et leurs contraintes. Les prochaines captures viendront documenter les résultats sans remplacer ce qui fait leur intérêt : la manière dont les problèmes ont été abordés.