Quand j’ai monté mon premier serveur Minecraft, j’avais quatorze ans et aucune idée de ce qu’était un fichier de configuration. J’éditais server.properties à la main parce qu’un forum disait qu’il fallait changer max-players. Le serveur redémarrait, ça marchait ou ça plantait, et j’apprenais lentement, par essai-erreur, que chaque ligne voulait dire quelque chose. Dix ans plus tard, j’ouvre config/packages/security.yaml dans un projet Symfony, et je fais exactement le même geste. Le vocabulaire a changé, pas le geste.
On me demande parfois comment je suis « passé » du bidouillage de serveurs de jeu à un projet Symfony noté en formation. La vérité, c’est que je ne suis pas vraiment passé de l’un à l’autre. Le bidouillage — le tinkering — n’est pas une étape qui précède le développement : c’en est la forme la plus brute.
Parce que le tinkering, ce n’est pas un niveau de compétence, c’est une posture : ouvrir un système, lire sa config, comprendre ses interactions, modifier prudemment, mesurer l’effet. Que je bidouille un level.dat, un Dockerfile ou un EntityRepository Doctrine, le geste mental ne bouge pas — décomposer, isoler, formuler une hypothèse, tester. Ce qui sépare un développeur d’un simple utilisateur, ce n’est ni le diplôme ni la techno : c’est cette habitude de considérer les outils comme ouverts par défaut.
Concrètement, le serveur Minecraft m’a tout appris avant que j’en connaisse les noms. Avant de comprendre la JVM, j’avais compris qu’il fallait lui donner de la mémoire. Avant de connaître systemd, j’écrivais des scripts screen qui relançaient le serveur quand il tombait. Avant d’avoir entendu parler de reverse proxy, je redirigeais un sous-domaine vers une IP fixe pour que mes potes se connectent sans retenir un numéro de port. Aucune de ces bricoles n’avait de nom canonique à l’époque — mais elles m’ont préparé à reconnaître les concepts le jour où la formation me les a présentés.
Du coup, quand je découvre un bundle, un pattern ou une annotation, je ne pars jamais de zéro : je rattache le truc à quelque chose que j’ai déjà manipulé ailleurs.
- Le service container de Symfony, c’est l’idée d’injection que j’avais déjà dans mes plugins Foundry.
- Les events Symfony, c’est ce que je codais à la main dans mes bots Discord.
- Les migrations Doctrine, c’est la version sérieuse des scripts
.sqlque je versionnais déjà dans mes premiers projets PHP.
Alors si tu doutes d’un parcours fait de bidouille plutôt que de cursus bien rangé : ces années à bricoler pour toi-même n’ont produit aucun diplôme, c’est vrai, mais elles ont produit autre chose, plus dur à monnayer et plus durable — une compréhension intuitive de la façon dont les systèmes se cassent. C’est précisément ce qu’on cherche quand on recrute un dev ou un admin sys. Je n’ai pas appris Symfony en commençant Symfony ; je l’ai appris en passant dix ans à bidouiller tout ce qui me tombait sous la main. La formation, elle, a juste mis des noms sur ce que je faisais déjà.