Devenir expert IT est un objectif de carrière pour beaucoup de développeurs. Dans l’imaginaire collectif, un expert n’a pas de mal à trouver de travail, il a accès à des salaires supérieurs (ou des TJs à plus de 1000€). Et pour obtenir ce statut il s’agirait d’accumuler des connaissances théoriques et pratiques chaque jour de sa vie jusqu’au jour où on sera reconnu par nos pairs.
Sauf que ça ne fonctionne pas comme ça. Un expert IT n’est pas un puits de connaissance que l’on peut consulter comme Wikipédia. C’est une fonction dans l’entreprise, dans une organisation.
Le chemin pour y accéder est donc loin de celui que l’on imagine. On fait le point sur ce rôle et les parcours de carrière qui y mènent pour que vous restiez en maîtrise de votre vie professionnelle.
La pire chose qui puisse arriver à un expert IT, c’est de changer d’entreprise. Et que dans la nouvelle il ne soit plus un expert. Parce que l’expertise est relative.
Un expert du Japonais à Paris ne le sera pas forcément à Tokyo.
Cela marche également pour les développeurs. Dans un de mes premiers jobs, j’avais été recruté comme développeur mobile. Mes années à faire du Rails étaient bien inutiles d’un coup vu que le backend était en Java Spring.
“What’s Your Edge? Rethinking Expertise in the Age of AI” sur MIT Sloan le souligne. Quelle est la valeur ajoutée d’un expert à l’ère de l’IA ? Celle de poser les bonnes questions en ayant compris le contexte.
Il y a dix ans on se posait déjà la question en école d’ingénieur : “À quoi ça sert d’apprendre tout par coeur ? Quand je serai au bureau j’aurai Google et Stackoverflow”. Et la réponse n’a pas changé avec ChatGPT.
Et si toute ton expertise du jour au lendemain n’était plus utile ?
Ce n’est pas si anodin, j’ai eu plusieurs fois la conversation avec des développeurs qui pensaient être à la pointe mais étaient en fait dans une impasse. “Ça fait 10 ans que je développe mon expertise sur cette techno, et maintenant je trouve plus de poste ? Je vais quand même pas repartir de zéro”.
Dans l’IT, les compétences techniques se périment plus vite que dans la plupart des autres métiers. Harvard Business Review évoque une “demi-vie” de quelques années, environ deux à trois ans, contre cinq à six ans dans des secteurs moins exposés aux ruptures technologiques.
Et moi-même je l’ai vécu. Des années à me passionner pour les détails et secrets derrière l’Objective-C pour qu’il soit remplacé par Swift.
Il y a un autre ouvrage qui est souvent cité dans ce domaine d’expertise c’est “The Tacit Dimension” de Michael Polanyi qui a été publié en 1966. Le cœur du livre est de valoriser la connaissance acquise par la pratique, l’expérience et donc non formalisée. Et tout ça est situé dans un contexte. Il explique également que cette connaissance peut être endormie, quand le contexte n’existe plus.
Ce qu’il faut retenir c’est que les expert•es IT ne forment pas un cercle fermé. Ce n’est pas un acquis inaliénable. Les experts IT d’aujourd’hui sont en haut d’une colline. Sauf que demain c’est une autre colline qui sera au soleil. Et personne n’est dessus. Il faut imaginer que les expertises montent et descendent comme une bulle dans une lampe à lave. Et vous pouvez chercher à prendre la prochaine bulle qui monte.
La fonction des experts IT souvent c’est juste de réduire la charge cognitive collective.
Imaginez que vous soyez seul devant une décision. Par exemple : est-ce qu’on va utiliser Typescript sur ce projet ? En fait, c’est pratique s’il existe une convention “Tous les projets passent sur Typescript”.
Mais sans ça, j’ai besoin d’un expert ou d’un référent. On va aller voir Jérémie ou Kévin qui ont déjà pris le temps de réfléchir à ce sujet, parce qu’on leur a déjà posé la question un paquet de fois. Et ils vont nous aider. Parfois ils ne vont pas juste trancher, mais aider à la décision en expliquant les enjeux, les conséquences.
C’est ce qu’on appelle déléguer la décision. La charge de réflexion cumulée serait bien plus grande si on avait besoin de conduire une étude complète à chaque décision. Donc déjà sans dire qu’on cherche à prendre de meilleures décisions, l’organisation a besoin d’experts pour réduire la charge de décision.
Ils servent de mémoire vivante, en complément de la connaissance formelle qui existe dans les ADRs, les wikis etc…
La référence ici dans la littérature c’est Organizations qui a été publié en 1958. Le livre introduit le concept de rationalité limitée.
Pour l’exemple de Typescript, le choix est quand même vite fait, on devrait faire tous les projets JS avec Typescript.
Est-ce que toutes les équipes doivent faire du Scrum ? C’est moins simple déjà. Une solution consiste à diviser. Les équipes backend vont faire des sprints, les équipes frontend vont faire du kanban. Et encore, ça ne règle pas tout.
Donc quand il faut arbitrer plus finement en prenant le contexte en compte, on a besoin d’experts. Et sur la méthode agile, on a des coachs qui servent à ça.
Admettons que votre organisation ait décidé d’adopter les OKRs. Les coachs agiles vont maintenant frapper à la porte de chaque équipe : “Je vais vous aider à adopter la méthodologie OKR”. Est-ce qu’ils sont vraiment dans un rôle d’expert à ce moment-là ? S’ils vous aident à arbitrer des micro-décisions pour aller plus vite au succès du projet, alors oui. Ils ont réduit votre charge de décision.
Bien sûr qu’ensuite on pourra dire que c’est de la faute des agilistes si OKR ne fonctionne pas comme prévu. Et on dira que c’était la faute du référent frontend si Typescript n’améliore pas la productivité.
Est-ce que c’est grave ? Pas forcément. Parce qu’ils seront encore là pour assumer la décision, proposer un plan alternatif, travailler sur des solutions et incarner cette mémoire collective.
Vous remarquerez dans mon exemple, mais aussi au quotidien que les experts évitent de trancher et préfèrent aider à la décision. C’est parce que dans le second cas la responsabilité est partagée.
Qu’il ait le rôle d’une manière formelle ou non, il arrive toujours un point où l’expert a trop de responsabilités, trop de sujets à trancher.
C’est là que va se créer un peu de vide.
Il y a cette petite décision. Par exemple, choisir une librairie plutôt qu’une autre.
Cela ne vaut probablement pas le coût d’attendre qu’un expert soit disponible. Alors on va faire nos recherches, trancher, et documenter proprement.
À ce moment-là, on prend une responsabilité. Si l’arbitrage n’est pas dans le bon sens, on devra assumer les conséquences, gérer le rollback ou le correctif.
Ce sont les coûts associés au rôle de l’expert, sans la reconnaissance, ni le mandat clair. Et les problèmes ne font que commencer.
Il se trouve qu’une autre équipe a rencontré le même problème. Et l’architecte, l’expert a proposé une autre solution. Probablement qu’il avait plus de recul, un point de vue différent.
Sauf que d’autres équipes ont adopté la même librairie que vous et demandent un retour d’expérience.
Il faut bien voir que dans cette lampe à lave, les bulles qui montent percutent celles qui descendent.
Et rappelez-vous la règle de la rationalisation. Si une règle permet de simplifier la charge cognitive, c’est plus efficace qu’un expert.
C’est ce qui est en train de se passer. Est-ce qu’on utilise votre librairie ou l’autre ?
Le débat va peut-être devenir intense. L’expert du sujet va probablement vous reprocher d’avoir décidé sans lui. Le leadership va s’impliquer et pas forcément pour lancer des fleurs.
Parce que oui, c’est à ça que ressemble le quotidien de ceux qui ont pu transformer la posture d’expert IT en une fiche de poste.
Les autres chemins existent. Souvent on divise en deux chemins : d’un côté la voie du contributeur individuel de Junior à Sénior. Et d’un autre côté le management. Et honnêtement ils sont tout aussi honorables et épanouissants.
Dans certaines organisations, le rôle d’expert est cumulable avec un rôle organisationnel.
Et oui, la posture peut être compliquée à tenir. Demain un autre junior arrivera et remettra en question ta légitimité à faire des arbitrages. Et si tu fais pas attention, on va finir par te mettre tous les maux de l’informatique sur le dos. Et parfois les attentes seront fortes : est-ce que tu peux résoudre ce problème ? Bien sûr c’est toi l’expert du sujet.
Si tu es prêt pour tout ça, alors voici comment s’y prendre.
Cette recette comprend de nombreux ingrédients. Et il faut au moins un peu de tout, mais sans se disperser non plus. L’important est d’apprécier chaque addition qui t’as permis d’avancer vers l’objectif.
La recette marche aussi à l’envers. Voici comment faire pour ne pas devenir un expert subi. À quel moment dire non.
Avant de demander à un expert IT d’arbitrer, prends une heure ou deux pour faire tes recherches. Documente tes apprentissages. Et lorsque tu seras devant l’oracle tu pourras discuter, approfondir.
On pourra même te solliciter pour partager tes retours d’expériences.
Tout ça, ce sont des fonctions d’une entreprise apprenante. On peut citer à ce niveau-là le livre “The Fifth Discipline” qui est contemporain des deux précédents, il date de 1990. L’auteur Senge, mets particulièrement l’emphase sur la compréhension du système.
Cela ne dit pas qu’il faut travailler plus. Mais on ne délègue pas aveuglément la décision.
Prendre une posture d’expert IT commence par une chose simple : comprendre le système existant et ne pas ajouter de friction inutile. On a expliqué avant qu’une règle permet de réduire la charge décisionnelle. Alors quand une règle est établie, on la respecte scrupuleusement.
Ce qui n’empêche pas de proposer de la challenger. On veut utiliser une nouvelle méthode, une nouvelle technique. Et bien on demande un cadre, un territoire sanctuarisé pour tester et apprendre.
Personne d’autre n’a le temps de faire des POCs, des expérimentations ? L’entreprise n’a pas eu le temps d’apprendre encore sur ce sujet ? On peut le faire, mais en suivant les processus.
C’est assez souvent que dans une fiche de poste pour un développeur on arrive à la conclusion qu’on a besoin d’un référent sur un sujet technique. Sur de l’IAM en cybersécurité, sur Java dans le backend et ainsi de suite.
Une certification Java par exemple montre que tu as pris le temps d’apprendre beaucoup de détails qui ne sont pas forcément utiles au quotidien pour la majorité des développeurs Java. Mais ce petit détail fera peut-être la différence le jour de la mise en production.
Ça peut être au sein d’une équipe ou d’une guilde, avec un groupe de 5 personnes que tu connais. Ou bien ça peut être sur scène à une conférence nationale. Dans les deux cas on travaille une compétence clé qui est la capacité à s’exprimer en public.
Vous avez probablement beaucoup de connaissances et de compétences, mais si vous n’êtes pas capable de les faire passer, de les véhiculer, ça ne fonctionnera pas forcément.
Et rappelez-vous la morale de “Tacit Dimension”. Vous en savez sûrement plus que ce que vous ne le pensez. Chaque expérience est l’occasion d’apprendre des compétences et connaissances informelles. Les partager et l’occasion de les formaliser.
On espère que cet article vous permettra de prendre des choix de carrières plus éclairés.
Pendant des années chef de projet ou le manager était l’évolution logique du développeur. C’était faux. Et aujourd’hui vous aurez compris que ce n’est pas non plus le rôle d’expert.
Et oui, les organisations, les parcours de carrière vous donnent cette impression. Parce que c’est un besoin rationnel des organisations d’avoir des gens qui décident, qui arbitrent rapidement. Mais arbitrer vite ce n’est jamais gratuit. Et c’est souvent plus l’individu qui porte ce coût plus que l’organisation.
Avec un peu de chance votre organisation a un parcours de carrière qui valorise les contributeurs individuels, ceux qui ont plus d’impact sans changer de parcours. Et oui ce n’est pas grave d’avoir 15 ans de bouteille et d’être “encore développeur” et pas expert IT. Cela montre juste que vous avez trouvé votre rôle, votre place au sein de l’organisation.
Les devs passent leur temps à râler sur leur Stack. Et pourtant, dès qu’ils ont…
Vous avez déjà tapé « manager non-tech » dans Google à 23h, après une réunion…
Le marché de la tech en 2026 est en pleine mutation. Entre la démocratisation massive…
Comment optimiser tes coûts data dans le cloud ? Face à des factures cloud qui…
Changer de stack ça fait peur parce qu'on ne sait pas comment s’y prendre. Ça…
Ah, le télétravail... Travailler en slip (ou en pyjama licorne, on ne juge pas) avec…
