L'un de mes premiers boulots était agent de gardiennage en Belgique. Je faisais pas mal de sport à l'époque, notamment du Penchak Silat chez Fred Mastro. Je me souviens d'un entraînement avec l'un de ses portiers qui était aussi mon éducateur – il a été surpris de mes appuis, malgré mes 20 kg et 10 cm de moins que lui.
J'étais mince et jeune, pas vraiment le physique standard du videur. Ça n'a pas été tous les jours facile, croyez-moi. Je bossais au Bunker, une discothèque qui a fait faillite depuis. Un soir, un type bien plus imposant m'a proposé qu'on "sorte dehors" –Quel génie. Ma solution ? Le laisser passer devant, inviter mes collègues et fermer la porte.
Ces expériences pas franchement académiques m'ont pourtant appris des trucs qui, bizarrement, s'appliquent parfaitement à mon métier de développeur. Voici les cinq plus importantes.
1. S'appuyer sur les bons outils pour rester vigilant
Personne ne peut rester en alerte maximale 24h/24 - c'est juste impossible humainement. La solution ? Utiliser des systèmes et des outils qui compensent nos limitations.
Dans mes nuits de gardiennage, j'ai vite compris qu'il fallait travailler intelligent, pas forcément dur. C'est pareil quand je code. Au lieu de prétendre pouvoir tout contrôler manuellement (bonne chance avec ça !), j'utilise des outils d'analyse de code, des tests automatisés et du monitoring.
Ce n'est pas de la paresse, c'est de l'humilité. La vraie expertise, ce n'est pas de tout faire soi-même comme un superhéros, mais de savoir quels outils déployer pour créer un système plus efficace qu'un développeur seul ne pourrait jamais l'être – même en buvant des litres de café.
2. L'apprentissage continu et le réseau sont essentiels
J'ai vite compris qu'on ne peut pas tout savoir ni tout anticiper seul. Quand vous êtes face à un groupe de dix gars éméchés, croyez-moi, vous appréciez d'avoir des collègues et leurs expériences.
Ce qui m'aide vraiment face aux bugs et aux défis techniques, ce n'est pas une capacité mystique à tout prévoir, mais mon réseau. J'apprends continuellement des nouveautés et j'échange avec des seniors qui ont déjà affronté les mêmes problèmes.
Je participe à des communautés de développeurs, et je n'hésite pas à demander de l'aide. En sécurité comme en développement, les héros solitaires finissent généralement par se planter – et souvent de façon spectaculaire.
3. La communication est complexe mais essentielle
La communication parfaite, c'est comme le videur parfait ou le code parfait : ça n'existe pas. Malgré toutes les bonnes intentions, les malentendus sont inévitables quand des êtres humains se parlent.
Le pire c’était vraiment l’invitation à la sortie des derniers pleins mort, j'ai développé une approche plus méthodique. Parfois, s'acharner à expliquer les règles à un client bien éméché ne sert à rien. Mieux vaut temporiser et revenir plus tard – ou trouver un autre angle d'approche.
Ce que j'apprécie dans le développement, c'est l'approche empirique. Comprendre comment les gens utilisent réellement les technologies, plutôt que de leur imposer ma vision de geek, ça change tout. C'est comme comprendre pourquoi ce client veut absolument entrer avec ses chaussures boueuses plutôt que de simplement lui bloquer l'entrée.
L'important n'est pas d'avoir toujours raison, mais d'être authentique. Chaque interaction est un moment de partage, même quand ça part en vrille.
4. Savoir dire non est plus important que l'adaptabilité
« Sois flexible », ils disent. « Adapte-toi », ils répètent. Mais voilà, j'ai appris que connaître ses limites est bien plus crucial. Dire que je m'adapte à tout, c’est faux et ça nous pousse dans des retranchements qu’on ne souhaite pas.
Quand vous gérez l'entrée, si vous laissez passer tout le monde pour être "flexible", vous créez le chaos. Dans le développement, c'est pareil. L'adaptabilité sans bornes étend les délais, dilue la qualité et vous mène droit au burn-out – je l'ai vu trop souvent.
J'ai appris à dire non. Non à certains projets. Non à des demandes irréalistes. Non à des deadlines impossibles. Je ne peux pas tout faire, et prétendre le contraire serait mentir. Je préfère être honnête sur mes capacités et livrer un travail bien fait plutôt que de jouer les super-héros et m'écraser en plein vol.
Cette transparence sur mes limites a paradoxalement renforcé la confiance de mes clients. Comme en sécu : « tu vois les deux là, les laisses pas rentrer? », « ok, Pierre, pourquoi? », «c'est des petites merdes », « Ok, les gars vous pouvez rentrer, dites merci à Pierre ;) »
5. L'humilité de service avant la visibilité
Voici une révélation qui surprend : être visible ne crée pas automatiquement la confiance. En fait, dans une boîte de nuit, le videur qui se la joue trop provoque souvent plus de bagarres qu'il n'en évite.
J'ai compris que ce n'est pas ma visibilité qui compte, mais ma capacité à mettre mon ego de côté. Les projets appartiennent au client, pas à moi – même si parfois leurs idées me font intérieurement lever les yeux au ciel (comme vouloir absolument un effet parallaxe sur leur site d’onglerie).
Être présent ne signifie pas bombarder le client de mises à jour pour montrer que je travaille. C'est être disponible quand nécessaire, écouter les besoins réels, et parfois savoir rester en retrait. Comme quand vous surveillez une salle : vous n'êtes pas là pour attirer l'attention, mais pour que tout se passe bien.
Cette humilité de service est devenue l'une de mes compétences les plus précieuses. Mon rôle n'est pas d'être la star, mais de faire briller le projet.
Conclusion
Ces cinq leçons issues de mon parcours pas vraiment conventionnel ont façonné ma façon de travailler. Elles me rappellent tous les jours que la technique seule ne fait pas un bon développeur.
Ce n'est pas la vigilance surhumaine, mais les bons outils au bon moment. Ce n'est pas l'expertise solitaire, mais le réseau et l'entraide. Ce n'est pas le discours parfait, mais l'authenticité dans les échanges. Ce n'est pas dire oui à tout, mais savoir quand dire non. Ce n'est pas se mettre en avant, mais servir le projet avec humilité.
Finalement, passer du Bunker au code n'était pas un si grand écart. Dans les deux cas, il s'agit de créer des espaces où les gens peuvent entrer, naviguer et ressortir avec une bonne expérience – sans se prendre les pieds dans le tapis.
