Un SRE avec un profil en T pourrait par exemple avoir une grosse expertise en infrastructure (Kubernetes, Observabilité, Linux…​) et des connaissances générales dans des domaines comme le développement backend, la communication, ou le marketing (pourquoi pas?).

Et c’est d’ailleurs ce que l’on retrouve traditionnellement dans l’industrie: on est "assigné" en début de carrière à un rôle (dev, ops, data, product…​) et on y reste.

Personnellement, plus le temps passe et plus je trouve cette vision un peu dommage. Une carrière, ça dure 43 ans (pour l’instant, on peut s’attendre à plus une fois que les boomers auront terminé de cramer la caisse), et ce serait dommage de se cantonner qu’à une seule spécialité.
Pourquoi ne pas viser un profil en n (avec deux spécialités), voire en m ?

Je vais prendre un cas concret: je pense qu’un SRE ayant travaillé comme développeur par le passé (pour de vrai hein: dans une équipe produit) sera toujours avantagé. Le SRE book de Google insiste d’ailleurs là-dessus, mais ce ne sont pas des profils très communs en réalité.

Pourquoi ? Un SRE aujourd’hui écrit souvent du code pour piloter l’infrastructure. Et puis il aura une compréhension profonde des problématiques des développeurs car il l’aura vécu, et donc sera plus à même de travailler avec eux et de construire la bonne infrastructure pour répondre à leurs besoins.
Bon, ça c’est la partie politiquement correcte, mais ça évite aussi de se faire bullshiter. Vous serez plus à même de détecter des problèmes liés aux pratiques de développement ou d’architecture si vous avez passé plusieurs années à faire le métier. Vous n’aurez pas qu’un "gut feeling" quand un truc vous semblera bizarre, vous aurez l’expérience et un historique vous donnant de la légitimité.
C’est pas pour ça que vous allez toujours réussir à convaincre (on parlera de la relation dev et ops dans un autre article prochainement) mais ça aide énormément, et vous aurez les compétences pour aller mettre les mains directement dans le code des services si besoin.

Et c’est la même chose dans l’autre sens : vous serez un meilleur développeur si vous avez fait quelques années de SRE avant. Je peux vous garantir qu’après avoir passé quelques années à bosser sur de l’infrastructure, de l’observabilité, de la CI/CD, et avoir participé à une bonne centaine d’incidents de prod plus ou moins critiques, vous ne développerez plus de la même manière.

Et je pense qu’on peut étendre la réflexion. L’informatique est ultra vaste (les métiers du dev, de l’infrastructure, de la data, de la sécurité, les DBA…​ ont chacun des sous-catégories avec des spécialisations), et ce n’est pas que de la tech: les compétences produit, marketing, management, communication…​ sont également très importantes.

Et c’est ces personnes avec des compétences variées qui sont capables de faire le pont entre équipes, et de bosser sur des sujets de fond car elles ont la "big picture" complète en tête. Une fois la double (ou triple) compétence débloquée, on peut les exploiter pour traiter des sujets transverses qui mélangent les deux, et ça, ça a une énorme valeur.

Je trouve aussi que c’est très enrichissant d’apprendre un nouveau domaine, et aussi de se prouver qu’on a toujours cette capacité d’apprentissage et de reconstruire une expertise sur quelque chose de nouveau.

Comme dit précédemment, faut changer de poste pour vivre d’autres expériences. Et c’est là que le bât blesse.

J’ai eu la chance dès le début de ma carrière d’avoir réussi à basculer régulièrement entre deux mondes (développement et infrastructure), ce qui me permet de pouvoir prétendre à des postes de niveau expert d’un côté ou de l’autre.

Je pense que ça aurait été beaucoup plus compliqué si j’étais resté dans le même domaine pendant 10 ans: comment convaincre une entreprise de prendre le risque de laisser quelqu’un repartir sur un poste hors de sa spécialité avec probablement des prétentions salariales d’expert ?

Le mieux est probablement de partir de son expertise et de commencer au sein de la même entreprise à regarder ce qu’il se passe autour, et de peu à peu contribuer. Et avec le temps, peut-être négocier une mobilité interne ?

Mais si vous êtes junior, je n’ai qu’un conseil pour vous: restez curieux et n’hésitez pas à prendre quelques risques pour élargir rapidement vos horizons, ça vous aidera énormément pour la suite.