Le piège du généraliste : pourquoi je me suis senti comme un “débutant professionnel”

Récemment, j’ai remarqué quelque chose de dérangeant dans les technologies avec lesquelles je travaille.

Ce n’est pas lié à un seul projet. Cela s’est fait progressivement, au fil de plusieurs projets dans le temps. Chacun ajoutait quelques outils à la stack.

À un moment, j’ai pris du recul et regardé la liste.

• Des outils d’infrastructure et d’observabilité comme Docker, Kubernetes, Helm et Grafana.
• Des langages comme Go, C/C++, Python, JavaScript, TypeScript, Rust et Bash.
• Des systèmes de messagerie comme Kafka et ZeroMQ, ainsi que des frameworks RPC comme gRPC (Protobuf).
• Des sujets réseau comme TCP/IP et les fonctionnement interne de Linux.
• Un peu de frontend avec Angular, Tailwind, Ionic, HTML et CSS.
• Des pratiques de test et d’architecture, avec des outils comme Testcontainers pour gérer des environnements d’intégration, tout en travaillant avec des architectures microservices, event-driven et clean architecture.
• Et bien sûr, la colle qui maintient tout ensemble : les fichiers de configuration. Principalement en YAML. Parfois en TOML.

Rien de tout cela n’est inhabituel. Les systèmes modernes ont besoin de beaucoup de ces éléments. Mais avec le temps, un schéma a commencé à apparaître. Sur une période relativement courte, j’avais touché à beaucoup d’entre eux.

​

Pourquoi j’aimais être généraliste

Au début, j’aimais vraiment cette variété.

J’aimais pouvoir naviguer à travers toute la stack. Si quelque chose cassait dans le pipeline de déploiement, je pouvais aller voir les manifests Kubernetes. Si un service se comportait de manière étrange, je pouvais lire ou corriger le code Go. Je pouvais mettre en place des dashboards Grafana pour comprendre ce qui se passait dans le système.

J’écrivais des producers et des consumers Kafka pour connecter les services entre eux, et je développais des services dans différents langages quand c’était nécessaire.

Avec le temps, cela construit une carte mentale de la façon dont le système s’articule.

J’ai aussi travaillé sur des projets assez différents les uns des autres : travailler sur un projet en C, puis passer à du Python ou du JavaScript sur un autre. Parfois je discutais de l’architecture d’un nouveau système ; d’autres fois je faisais des modifications sur des charts Helm.

Pendant longtemps, j’aimais être la personne capable de passer d’une couche à l’autre, une sorte d’ingénieur « couteau suisse ». Pas l’expert le plus pointu sur chaque outil, mais quelqu’un capable d’aider dans beaucoup de situations.

Pendant un moment, cela ressemblait à une force.

​

Quand le généralisme commence à atteindre ses limites

Avec le temps, j’ai commencé à remarquer autre chose.

Kubernetes à lui seul peut demander des années pour être bien maîtrisé. C’est aussi vrai pour les réseaux, les systèmes d’exploitation, la messagerie distribuée ou les frameworks frontend modernes.

Mais mon travail continuait de passer de l’un à l’autre. J’apprenais juste assez pour résoudre le problème du moment. Puis le projet changeait, ou un autre problème apparaissait ailleurs dans le système.

Après quelques années, j’ai réalisé que j’avais vu beaucoup de technologies, mais que je restais rarement assez longtemps sur une seule pour vraiment approfondir.

C’est à ce moment-là que ce sentiment étrange est apparu. Je n’étais plus débutant. Mais je ne me sentais pas expert non plus. À la place, j’avais l’impression d’être un débutant professionnel sur beaucoup d’outils et de concepts.

Je savais faire fonctionner les choses. Mais j’atteignais rarement le point où je comprenais vraiment les patterns plus profonds ou les solutions les plus élégantes.

Et sans cette profondeur, une partie de la curiosité a commencé à disparaître.

​

Pourquoi cela arrive

Le problème ne vient pas seulement de la complexité. Il vient aussi de la manière dont le travail est structuré. Beaucoup de projets valorisent des résultats rapides plutôt qu’une compréhension en profondeur. On apprend juste assez pour résoudre le problème, puis on passe à l’outil suivant, au système suivant, au prochain problème à résoudre.

Mais les systèmes réels connectent toutes ces couches, et beaucoup d’ingénieurs naviguent entre elles en permanence.

L’infrastructure seule couvre les conteneurs, l’orchestration, le réseau, l’observabilité et les pipelines de déploiement. Chacun de ces domaines peut représenter une carrière à lui seul. À cela s’ajoutent les langages, les frameworks, les bases de données, les systèmes de messagerie et les outils frontend.

Cela crée une tension permanente entre largeur et profondeur.

​

Comment les gens s’adaptent

Avec le temps, j’ai observé plusieurs approches.

Certains ingénieurs choisissent de se spécialiser.
Ils se concentrent sur un domaine précis et y investissent en profondeur : systèmes distribués, réseau, infrastructure ou runtimes de langage. Ils comprennent toujours le reste de la stack, mais la majorité de leur effort va dans un seul domaine.

D’autres se concentrent sur les principes plutôt que sur les outils. Les outils et frameworks changent rapidement, mais les fondamentaux durent dans le temps. Les concepts issus du réseau, des systèmes d’exploitation et de la conception de systèmes s’appliquent à de nombreuses technologies. Dans cette approche, les outils sont appris quand nécessaire, sans chercher à tous les maîtriser.

Une troisième voie apparaît souvent plus tard dans une carrière. Certains ingénieurs évoluent vers des rôles où la largeur est centrale (tech lead, architecte ou staff engineer). Leur travail consiste moins à maîtriser un outil spécifique qu’à comprendre comment les systèmes s’assemblent et à faire les bons compromis.

​

Où j’en suis aujourd’hui

Je n’essaie plus d’approfondir tout ce que je touche. Cela signifie accepter que certaines parties du système resteront superficielles pour moi, et c’est un compromis.

À la place, je me concentre sur des fondamentaux solides et je choisis quelques domaines où aller en profondeur. Le reste sont des outils que j’utilise quand j’en ai besoin, en cherchant à maîtriser ceux qui m’intéressent le plus.

Sinon, il est facile de redevenir un débutant professionnel.

​

Une question pour les autres ingénieurs

Si vous êtes dans ce domaine depuis un certain temps, vous avez probablement ressenti cette tension.

Trop d’outils et technologies. Pas assez de temps pour les maîtriser.

Comment avez-vous géré cela ?

Vous êtes-vous spécialisé dans un domaine ? Avez-vous privilégié les principes plutôt que les outils ? Ou avez-vous évolué vers des rôles où la variété fait partie du travail ?

Je serais curieux de savoir comment d’autres ont navigué cette tension avec le temps.