Confession d’un diplômé aux bases fragiles
À l’époque de mes études en école d’ingénieur, je pensais sincèrement être un ‘crack’. Sans réaliser l’importance cruciale des Bases de l’Informatique (CS), je ne courais qu’après les notes et la validation des crédits.
J’assistais aux cours de spécialité, je participais aux hackathons et j’avais même remporté des prix lors de mon ‘PFE’ (Projet de Fin d’Études). Quand mes camarades s’arrachaient les cheveux sur une erreur de code, je venais leur donner des leçons avec un sentiment de supériorité. Mais je dois l’avouer aujourd’hui : mes résultats de l’époque n’étaient que du ‘bricolage’ d’amateur.
Au lieu d’intégrer une véritable base de données, je stockais mes données dans un fichier ‘.txt’ séparées par des virgules. Au lieu d’utiliser un Raspberry Pi nécessitant une gestion au niveau de l’OS, je me contentais d’un Arduino qui fonctionnait avec quelques lignes de code copiées. Les professeurs applaudissaient le résultat visuel, et je me berçais d’illusions en pensant que c’était là ma véritable compétence.
L’entretien réussi par cœur, le début de la tragédie
Dès mon arrivée sur le marché du travail, cette confiance sans fondement a volé en éclats. Les refus sur dossier se sont enchaînés. Le titre de ‘lauréat de concours’ ne suffisait pas à masquer mes lacunes béantes en théorie fondamentale.
Plus l’anxiété montait, plus je m’obsédais à accumuler des connaissances superficielles. La compréhension profonde passait au second plan ; je m’étais transformé en machine à réciter des réponses types pour passer les entretiens. Ma bible ? Les ‘100 questions d’entretien technique’ trouvées sur des blogs au hasard.
Quand un recruteur demandait : ‘Quelle est la différence entre TCP et UDP ?’, je répondais comme un distributeur automatique. ‘TCP est orienté connexion et garantit la fiabilité mais est lent, UDP est sans connexion et rapide mais moins fiable.’
En réalité, je n’avais aucune idée de ce qu’était un paquet, ni de comment se déroulait réellement le ‘3-way handshaking’. Ironiquement, grâce à cette mémoire mécanique, j’ai réussi à duper les recruteurs et à décrocher un emploi. Je croyais que c’était de la chance. Je ne savais pas encore que c’était le début d’une tragédie, le retour de bâton de quatre années de négligence.
Survivre en tant que Full Stack dans une petite équipe
J’ai atterri dans une petite structure, une start-up. Là-bas, il n’y avait pas de distinction bienveillante entre ‘Frontend’ et ‘Backend’.
Dès le premier jour, j’ai dû faire face à un tsunami technologique. Je pensais qu’il suffisait de maîtriser Java ou JavaScript. Mais la réalité m’a frappé : l’écran noir du terminal Linux SSH, des conteneurs Docker dont j’ignorais la nature, les pipelines GitLab CI/CD, Spring Boot, Vue.js, et même Redis… Toutes ces technologies que j’avais repoussées en me disant ‘je verrai ça plus tard’ ou ‘ce n’est pas important’ m’attaquaient désormais de toutes parts.
Les connaissances récitées lors de l’entretien ne servaient à rien. Ou pour être plus précis, je ne savais pas les ‘appliquer’. Pour comprendre pourquoi mon conteneur Docker mourait sans cesse (OOM) ou pourquoi Redis dévorait la mémoire, j’avais désespérément besoin de ces théories fondamentales que je n’avais fait que survoler.
Un château construit sur du sable
Finalement, j’étais devenu un ‘développeur copier-coller’ (Ctrl+C, V), assemblant du code à l’aveugle. Les fonctionnalités marchaient tant bien que mal, mais j’ignorais pourquoi.
- ‘CORS Error’ : Pourquoi mon navigateur refuse-t-il la réponse du serveur ? (Ignorance des en-têtes HTTP)
- ‘OOM (Out Of Memory)’ : Pourquoi le serveur plante-t-il soudainement ? (Ignorance des fuites de mémoire et du Garbage Collector)
- ‘Connection Refused’ : Ça marche en local, pourquoi pas en prod ? (Ignorance du Port Forwarding et des Firewalls)
Ne connaissant pas les principes cachés derrière le confort des frameworks, je n’avais aucune capacité à résoudre les problèmes. Je construisais un château technologique instable sur des fondations en sable mouvant.
Re: Booting, retour à la case départ
C’est pourquoi j’ai décidé de tout reprendre à zéro. Plutôt que d’ajouter une ligne de plus à mon portfolio, il m’a semblé plus urgent de répondre à cette question fondamentale : ‘Comment l’ordinateur comprend-il et exécute-t-il mon code ?’
Ce blog est le journal de bord intense d’un diplômé qui reconstruit ses Bases de l’Informatique depuis le sol. Il ne s’agira pas simplement d’une liste de commandes Linux ou de tutoriels d’installation Docker. Je vais plutôt poser les questions suivantes et documenter ma quête de réponses :
- Language & OS : Que se passe-t-il entre le moment où j’écris du code Java et celui où il touche le CPU ?
- Network : Quel est le voyage d’un paquet quand j’appuie sur Entrée dans la barre d’adresse ?
- Virtualization : Quelle est la différence entre mon PC portable et le serveur, et pourquoi a-t-on besoin de la virtualisation ?
- DevOps : Comment déployer mon code de manière sûre et automatisée ?
Au-delà du localhost
Mon objectif final est de construire et contrôler moi-même un environnement complet : Linux, Docker, CI/CD, jusqu’au Cloud. Je vous invite à suivre le parcours d’un ingénieur qui sort de la serre sécurisée du ‘localhost’ pour survivre dans la nature sauvage des serveurs de production.
À ceux qui, comme mon ancien moi, disent ‘Je l’ai appris à l’école mais je ne m’en souviens plus’, j’espère que ces écrits deviendront un petit repère qui vous fera dire : ‘Ah, c’est donc ça que le professeur voulait dire à l’époque !’