Comprendre la machine
C, algorithmes et système. Écrire un allocateur mémoire ou un interpréteur de commandes oblige à savoir ce qui se passe réellement sous le langage.
J'ai pris l'habitude de comprendre pourquoi un système fonctionne avant de le construire. Cette page explique d'où me vient cette habitude, ce qu'elle change concrètement dans ma façon de travailler, et ce que je cherche à faire de la suite.
Ce qui m'intéresse le plus, ce n'est pas de livrer un système impressionnant le jour de sa mise en production, mais de pouvoir le regarder quelques années plus tard et constater qu'il fonctionne toujours, qu'il a absorbé des besoins qui n'existaient pas au départ, et que d'autres ont pu le reprendre sans le réécrire.
C'est ce qui oriente mes choix aujourd'hui : préférer une architecture qui vieillit bien à une technologie récente mais fragile, et accepter d'y passer plus de temps au début. Cette préférence n'a rien d'une certitude définitive - c'est simplement ce que j'ai observé jusqu'ici, sur mes projets comme en entreprise, et ce que je compte continuer à vérifier.
J'ai choisi l'informatique un peu par défaut - j'aimais les jeux vidéo et j'étais bon NSI/SNT au lycée. Le COVID a compliqué l'orientation et je n'ai eu qu'un an pour décider vers où aller. EPITA s'est imposé naturellement : je savais que j'étais bon en programmation, même si je ne savais pas encore pourquoi.
Retourner en Inde après y avoir voyagé enfant à 3 ans puis 9 ans. Revoir ce pays de mes propres yeux, découvrir sa cuisine si différente, ses mélanges d'épices. C'est un choix personnel qui reflète ma curiosité pour l'ailleurs et ma volonté de comprendre par moi-même.
JWS, 42sh... Ces projets m'ont appris à me connaître. Comprendre que ma façon de questionner avant d'agir n'était pas une perte de temps mais mon atout principal. Découvrir ma méthode de travail et ma façon de penser.
Cette première expérience chez Enedis m'a permis de découvrir le monde du travail sous l'angle de l'ingénieur, une approche radicalement différente des jobs étudiants classiques. J'y ai également compris comment le code s'intègre concrètement dans un environnement professionnel.
Au second semestre de ma quatrième année, j'ai choisi ma spécialisation : SIGL (Systèmes d'Information et Génie Logiciel). Cette majeure se déroulant sur le campus parisien, je quitte Lyon pour Paris. Je recherche en parallèle un stage de pré-embauche ou de fin d'études pour février 2027.
Concrètement, cette habitude se traduit par trois réflexes que j'ai pu observer et affiner sur des projets réels.
Chez Enedis, une suite de tests ne fonctionnait presque plus. La réponse rapide aurait été de corriger les tests un par un. En analysant les échecs, il est apparu que le problème était structurel : la façon dont les tests identifiaient les éléments de l'interface était trop rigide, et cassait à la moindre modification. Corriger cette cause a réglé des dizaines de symptômes d'un coup.
Toujours pendant ce stage, l'outil de test utilisé pouvait sembler dépassé face aux alternatives plus récentes. Mais il avait une qualité décisive : les équipes métier, non techniques, pouvaient lire et comprendre les scénarios. Le remplacer aurait coupé ce lien. J'ai préféré garder l'outil et compenser sa faiblesse technique autrement - un choix qui n'a de sens que si on regarde le contexte, pas seulement la technologie.
C'est la différence que j'ai le plus ressentie entre le code d'école et le code d'entreprise. À l'école, un programme qui marche suffit. En entreprise, quelqu'un d'autre reprendra ce code dans six mois. Nommer clairement, documenter, structurer pour que ce soit modifiable : ce n'est pas de la cosmétique, c'est ce qui détermine si le travail survit.
Mon parcours n'a pas suivi un plan défini à l'avance : chaque étape a répondu à une limite rencontrée à la précédente.
C, algorithmes et système. Écrire un allocateur mémoire ou un interpréteur de commandes oblige à savoir ce qui se passe réellement sous le langage.
Java, C++ et architecture. Passé une certaine taille, un projet ne tient plus par la seule qualité du code : il tient par la façon dont ses parties sont séparées.
Git, intégration continue, tests et revue de code. Mon stage m'a appris que ces outils ne servent pas à contrôler, mais à permettre à des dizaines de personnes de modifier le même système sans le casser.
C'est le sens de la majeure SIGL que j'ai choisie : comprendre comment un système d'information répond à un besoin réel, et pas seulement comment il est codé.
Le trekking, c'est d'abord un exercice de planification intensive. Calculer les besoins en eau selon le dénivelé et la météo, anticiper les variations de température, prévoir les équipements pour la pluie comme pour la forte chaleur. Chaque détail compte, chaque scénario doit être envisagé. Mais paradoxalement, une fois cette préparation méticuleuse terminée, on part vers l'inconnu, vers l'aventure.
Ce que j'aime dans cette contradiction, c'est qu'elle reflète parfaitement ma philosophie : préparer au maximum pour pouvoir ensuite oser sortir de sa zone de confort. La structure rigoureuse devient le tremplin vers l'imprévisible. On quitte le confort de la ville pour affronter des défis qu'on ne peut pas totalement contrôler, mais qu'on peut appréhender.
Les jeux vidéo sont mon terrain d'expérimentation favori. Chaque nouveau jeu, c'est un système complexe à décrypter : comprendre les règles explicites et implicites, analyser les mécaniques sous-jacentes, identifier les leviers d'optimisation. C'est un exercice d'analyse systémique en temps réel du jeu mais aussi de moi.
Mais au-delà de la compréhension, c'est surtout l'endroit où je peux exercer librement mon esprit tactique et stratégique. Planifier des campagnes complexes, gérer des ressources limitées, anticiper les réactions adverses - tout cela sans craindre les conséquences réelles. C'est mon laboratoire personnel pour tester des approches, échouer, itérer, et affiner ma façon de penser les problèmes complexes.
En cuisine, je suis un "reverse engineer". Quand je découvre une nouvelle recette, je ne me contente pas de la suivre - je veux comprendre pourquoi elle fonctionne. Quelle réaction chimique crée cette texture ? Pourquoi cette combinaison d'épices produit-elle cette saveur particulière ? C'est une forme de découverte méthodique.
L'un de mes projets illustre parfaitement cette approche : déconstruire les deux versions des pâtes carbonara - française et italienne - pour comprendre les principes derrière chaque tradition. L'objectif ? Créer une synthèse qui garde le meilleur des deux écoles. C'est complexe parce que chaque modification en cascade affecte l'équilibre global, mais c'est exactement ce type de défi qui me passionne.
Il y a une forme d'audace qui ne cherche pas à impressionner : celle qui vous emmène si haut que plus personne ne pourrait vous voir. J'ai découvert avec le parapente cette audace discrète, et cinquante vols plus tard, elle ne m'a pas quitté.
Le parapente, c'est accepter de prendre des risques calculés pour vivre quelque chose d'unique. Chaque vol demande une lecture fine des conditions météo, une compréhension des thermiques, une anticipation des dangers - mais au final, on s'élance dans le vide. C'est ma façon de cultiver cette forme d'audace mesurée que je veux appliquer partout ailleurs.