Je me suis aperçu que les choses les plus difficiles à apprendre ne sont presque jamais techniques.
Ce sont les choses qu’il faut désapprendre.
Et le bizarre, c’est qu’en les désapprenant, on a l’impression de perdre quelque chose. Du statut, du contrôle, de l’identité. Puis, si ça va bien, on se rend compte qu’on lâchait juste une habitude qui nous tenait immobile.
Voici quelques notes éparses sur des choses que j’ai cessé de faire. Il m’a fallu quinze ans, plus ou moins. Et sur certaines, pour être honnête, je n’ai pas fini.
J’ai cessé d’écrire du code pour prouver que je suis encore tech
Il y a eu une période, juste après une étape importante de ma carrière, où ma façon de me légitimer devant l’équipe était toujours la même : j’ouvrais l’IDE et j’allais prendre le bug le plus laid de la semaine.
Je le faisais souvent le soir, seul. Le lendemain matin le commit était là, avec mon nom dessus. Au-dedans, j’appelais ça leadership. C’était de l’insécurité.
Parce que le message implicite était dévastateur, même sans le dire à voix haute. Le message était : je ne vous fais pas confiance. Et il y en avait un autre, encore plus toxique : les problèmes se résolvent la nuit, en solo, sans demander d’aide.
Sans le vouloir, j’enseignais que le geste héroïque vaut plus que le processus. Que la compétence est une performance individuelle. Que la fatigue est une médaille.
Puis j’ai fait un autre tour de manège. J’ai remplacé le code par les spécifications. Des documents si précis que l’équipe — ou un agent IA — pouvait les implémenter avec une supervision minimale. Pendant un temps, ça m’a paru la solution « adulte ». Mais cette phase aussi est passée.
Aujourd’hui, mon travail, quand je le fais bien, est ailleurs. C’est décider quoi on construit, pour qui, pourquoi maintenant. C’est de l’architecture de portefeuille, pas de code. C’est partenariats, hiring, positionnement. C’est comprendre où l’entreprise doit viser dans dix-huit mois, et quels choix d’aujourd’hui rendent cette direction plus probable.
Cette distance avec le code, parfois, fait mal. Pas parce que je veux retourner programmer chaque jour. C’est plus subtil. C’est la sensation que la légitimité d’un tech qui ne touche plus le code au quotidien est fragile, à reconstruire sur d’autres bases.
Plus sur la qualité de ce que tu écris, mais sur la qualité des décisions que tu prends et des personnes que tu choisis.
Et puis il y a une phrase qui me revient souvent et qui m’aide à ne pas retomber dans le vieux réflexe : chaque ligne que j’écris est une ligne que quelqu’un d’autre n’écrira pas. Chaque heure passée dans l’IDE est une heure où personne ne regarde où on va.
J’ai cessé de courir après le bon stack
Pendant des années, j’ai eu ce réflexe pavlovien de développeur. Un nouveau framework sort, il faut l’évaluer. Un nouveau langage sort, il faut au moins l’essayer.
Au fond, je crois que le sous-texte était : il existe un choix techno « juste » qui te place du côté des gagnants. Des cool kids. Des bonnes conférences. Des articles sur Hacker News.
Puis j’ai fait quelque chose d’impopulaire — du moins selon ma manière de penser : j’ai choisi un framework. Un. Et j’y suis resté.
Pas parce qu’il est le meilleur dans l’absolu. Mais parce qu’il me permet de livrer de la valeur avec peu de personnes sur plusieurs projets, sans devenir fou. Parce qu’il a une philosophie qui tient les contraintes réelles d’une boîte italienne. Convention sur configuration, batteries incluses, doc maniaque. Pas les contraintes imaginaires d’une startup de la Bay Area qui vit de slides et de runway.
La vérité inconfortable est que beaucoup de choix « courageux » dans les PME ne relèvent pas du courage. C’est de la vanité. Choisir Rust pour un outil de gestion qu’utiliseront quarante personnes n’est pas de l’ingénierie. C’est du narcissisme avec un compilateur.
À un moment, j’ai cessé de chercher le bon stack et j’ai commencé à chercher le stack honnête. Celui qui ne ment pas sur la complexité qu’il introduit. Celui que tu peux maintenir quand les seniors partent, quand le budget se serre, quand le client change d’avis trois fois.
J’ai cessé de protéger l’équipe du business
Le passage le plus difficile.
Pendant des années, j’ai fait bouclier. Le client demande une modif folle ? Je filtre. Le commercial vend quelque chose qui n’existe pas ? Je gère. Un document incompréhensible arrive ? Je traduis et je passe à l’équipe seulement la partie technique, propre, digérée.
Je me croyais bon leader. En réalité, je créais probablement des invalides.
D’excellents devs, oui, mais déconnectés. Ils ne savaient pas vraiment pourquoi ils construisaient ce qu’ils construisaient. Ils ne savaient pas lire une exigence métier. Ils n’avaient jamais parlé à un client. Et quand ils tombaient sur une ambiguïté, plutôt que d’appeler, ils ouvraient un ticket et attendaient.
Le changement, pour nous, a été de bâtir un parcours interne qu’on a appelé « du dev au product owner ». Pas pour transformer tout le monde en PM. Plutôt pour ôter le filtre.
Pour dire une chose simple, un peu inconfortable : le bordel est aussi le vôtre. Le client confus est aussi le vôtre. L’exigence ambiguë est aussi la vôtre.
Et surtout, la satisfaction de livrer quelque chose qui marche pour quelqu’un est aussi la vôtre.
Je pensais que ce serait impopulaire. Je me trompais. Ils m’ont surpris. Peut-être qu’ils attendaient juste qu’on leur donne la permission de sortir de la bulle.
J’ai cessé de dire « de toute façon c’est public » sur la compliance
Pendant des années, ma posture sur la compliance a été celle, typique, du secteur IT italien. Le minimum strict, fait au dernier moment, traité comme un coût et jamais comme un investissement.
RGPD ? Un bandeau cookies et une politique privée copiée. Accessibilité ? « On verra plus tard. » Sécurité ? « On n’est pas une cible. »
Puis j’ai commencé à lire vraiment certaines normes européennes. Pas les articles sur ces normes, les textes eux-mêmes. Et là, deux choses se sont éclaircies.
La première : le législateur européen, pour une fois, ne plaisante pas. Les sanctions sont réelles, les calendriers sont serrés, et la chaîne de responsabilité va jusqu’au fournisseur du composant logiciel. C’est-à-dire nous.
La seconde, plus importante : sur un marché où tout le monde attend la dernière minute, qui bouge en premier a un avantage concurrentiel énorme. Pas parce qu’il est meilleur. Parce qu’il est le seul à pouvoir dire au client « oui, on est prêts » quand le client, en panique, commencera à le demander.
À un moment, j’ai cessé de traiter la compliance comme une obligation. J’ai commencé à la traiter comme un produit.
Et je me demande souvent pourquoi on a mis si longtemps à le comprendre. Peut-être parce qu’il est plus confortable de croire que ce sont des paperasses, jusqu’à ce que ça devienne soudain un problème avec une échéance.
J’ai cessé d’embaucher pour des compétences techniques
Récente, et un peu douloureuse.
J’ai passé des semaines à chercher une figure importante. Des CV excellents. Des années d’expérience. Stacks solides. Bonnes références. J’en ai écarté plusieurs, non parce qu’ils n’étaient pas bons, mais parce qu’ils utilisaient l’IA comme ils utilisaient Stack Overflow il y a dix ans. Comme un oracle.
Ce que je cherchais, et que j’ai du mal à expliquer aux recruteurs, est différent. Je cherchais quelqu’un capable d’écrire une spécification déclarative si précise qu’un agent IA puisse l’implémenter avec une supervision minimale.
Pas un prompt engineer. Un penseur de systèmes qui utilise l’IA comme runtime, pas comme béquille.
La différence semble subtile, elle ne l’est pas. C’est la différence entre « j’ai demandé à ChatGPT de m’écrire le code » et qui maintient un fichier claude.md dans le repo avec conventions architecturales, patterns, contraintes de domaine. La différence entre conversation et spécification. Entre artisanat et ingénierie.
J’ai cessé d’embaucher des devs qui savent programmer. J’ai commencé à chercher des devs qui savent spécifier et qui ensuite vérifient ce que l’IA a produit avec la même rigueur qu’ils mettraient à reviewer le code d’un junior.
Le marché italien ne semble pas encore prêt à cette distinction, malheureusement. Mais j’ai l’intuition qu’il le sera vite. Et qui n’arrive pas à temps risque de se retrouver avec des équipes qui « produisent » beaucoup mais comprennent peu.
J’ai cessé de parler italien au travail
Cela paraît mince. Ça ne l’est pas.
Quand un nouveau junior non italien, excellent, est arrivé, on s’est trouvé devant un choix. Continuer à travailler en italien entre nous et utiliser l’anglais avec lui, en créant de fait une équipe à deux vitesses. Ou faire le switch complet.
On a choisi le switch complet. Tout en anglais. Jira en anglais. Chat en anglais. Daily en anglais. Rétro en anglais. Pour tout le monde.
Je ne l’ai pas fait que pour lui. Je l’ai fait pour nous.
Parce qu’une boîte de quelques personnes dans une ville italienne qui travaille uniquement en italien est une boîte qui restera probablement de quelques personnes dans cette ville. Il n’y a rien de mal à ça. Mais ce n’est pas ce qu’on voulait.
L’anglais, au final, n’est pas une langue. C’est une infrastructure. Comme Git, comme la CI/CD, comme la documentation. Soit tu l’as, soit tu es coupé.
C’était inconfortable. Certains ont peiné. Mais aujourd’hui, en lisant les descriptions des pull requests, les messages, les mails, je trouve que ça en valait la peine.
J’ai cessé de croire que le bon code parle de lui-même
C’est peut-être le plus dangereux mensonge de l’ingénierie logicielle. L’idée romantique selon laquelle, si le code est propre, testé, bien structuré, sa valeur est évidente. Que le mérite technique se défend tout seul.
Ça ne marche pas comme ça.
Le bon code que personne ne comprend est indissociable du code médiocre. Le refactoring que personne ne raconte devient un coût, pas un investissement. La migration architecturale sans business case écrit ressemble à un caprice de la tech.
J’ai appris, tard, que la moitié du boulot d’un tech leader, c’est raconter.
Expliquer au board pourquoi une migration n’est pas une lubie mais une réduction du risque. Expliquer au client pourquoi les tests automatisés qu’il a payés sont la raison pour laquelle il dort tranquille. Expliquer à l’équipe pourquoi la CI/CD n’est pas de la bureaucratie mais de la liberté et du confort.
Si tu ne sais pas raconter la valeur de ce que tu construis, quelqu’un d’autre la racontera à ta place. Et il la racontera mal.
Ce que je n’ai pas encore cessé de faire
Pour être honnête jusqu’au bout, il y a une chose que je devrais cesser de faire et que je n’arrive pas encore à lâcher.
Travailler comme si j’étais le seul à tenir les pièces ensemble.
Trop de choses passent encore par moi. Pas parce que l’équipe n’est pas capable, au contraire, mais parce que je n’ai pas encore bâti les systèmes qui me rendraient superflu dans chacun des domaines où on opère.
Et c’est ça qui me fait le plus peur.
Parce que chaque transition précédente avait un substitut clair. Cesser d’écrire du code ? Les spécifications. Cesser d’écrire des spécifications ? La stratégie. Cesser de faire les code reviews ? Un tech lead. Mais cesser d’être le point de convergence de tout, c’est différent.
Le substitut, c’est la confiance dans les systèmes. Et les systèmes, à dire vrai, je dois encore finir de les construire.
On en reparlera.
Ce qu'il faut retenir
Cesse d’écrire du code pour prouver que tu es encore tech : c’est un travail d’identité, pas d’ingénierie.
Cesse de courir après le bon stack ; cesse d’en défendre un parce que c’est toi qui l’as choisi.
Cesse de servir de bouclier entre l’équipe et le business : tu lui voles le contexte qui sert à grandir.
Cesse de répondre aux mails en temps réel, tu éduques l’attente que tu le feras toujours.
Ce que tu gagnes en désapprenant, ce n’est pas du désengagement — c’est du temps et de l’attention pour des décisions lentes, ce qui distingue presque toujours un senior fatigué d’un leader qui dure.
Questions & réponses
Pourquoi désapprendre est-il plus dur qu'apprendre ?
Parce qu’en désapprenant, on a l’impression de perdre quelque chose — statut, contrôle, identité. Les habitudes techniques qui t’ont fait progresser en début de carrière deviennent ensuite des contraintes qui te bloquent. Écrire du code pour prouver que tu es encore tech, c’était une validation à 25 ans ; à 40 c’est de l’insécurité. Reconnaître la transition est la partie difficile, le changement opérationnel est presque mécanique.
Quelles habitudes désapprendre le plus souvent à mi-carrière ?
Prouver qu’on est tech en prenant le bug le plus dur (c’est de l’insécurité). Dire oui à tout parce qu’« ainsi on ne m’oublie pas » (ça crée une équipe dépendante de toi qui ne grandira jamais). Défendre un stack parce que c’est toi qui l’as choisi, pas parce qu’il est juste. Répondre aux mails en temps réel, créant l’attente d’y répondre toujours en temps réel. Chacune avait une raison — qui a expiré.
Comment reconnaître une habitude qui a fait son temps ?
Trois signaux : tu la fais sans y penser — elle est devenue identité, plus choix ; elle ne produit plus le résultat pour lequel tu l’as adoptée ; quand on te suggère d’arrêter, ta réaction émotionnelle est disproportionnée. Cet agacement est l’indice que l’habitude est devenue constitutive de ton image de toi, plus un outil. C’est exactement là qu’il faut la remettre en question.
Que gagne-t-on à désapprendre ?
Du temps et de l’attention. Chaque habitude installée occupe agenda et tête. Les libérer rend de la place pour des choses que les premières années on ne pouvait pas se permettre : lire sérieusement un livre non technique par semaine, prendre des décisions lentes plutôt que réactives, dire non sans se justifier. Pas du désengagement, du recentrage — la différence entre un senior fatigué et un leader qui dure.
L'auteur
