Les trois voies d’accès au métier
Presque tout le monde arrive par l’une de trois voies, et chacune arrive avec la moitié du métier déjà acquise. Les ingénieurs produit apportent la moitié technique et doivent prouver qu’on peut leur faire confiance seuls chez un client. Les gens d’avant-vente apportent la moitié relationnelle et doivent prouver qu’ils livrent encore du code en production. La troisième voie est la moins discutée et souvent la plus solide : ceux qui viennent du secteur dans lequel le logiciel se déploie, qui connaissent le métier du client pour l’avoir exercé, et qui doivent prouver qu’ils savent construire. Aucune de ces voies ne suppose de repartir de zéro, ce qui explique que le passage soit généralement plus rapide qu’on ne le croit. Ce dont chacune a besoin n’est pas une compétence nouvelle mais une preuve précise, et cette preuve est toujours une histoire sur une personne plutôt que sur un système.
Première voie : depuis l’ingénierie produit
C’est la plus fréquente et la moins risquée, parce que le socle technique est la part qui ne se simule pas et que vous la détenez déjà. Ce dont celui qui recrute n’est pas sûr est tout le reste : allez-vous vous figer quand un client est agacé, allez-vous insister pour construire la solution générale, pouvez-vous être seul dans une pièce à représenter l’entreprise.
La preuve qui lève ce doute est plus modeste qu’on ne l’imagine. Une histoire sur une fois où vous avez travaillé directement avec ceux qui employaient ce que vous aviez construit, et sur ce que vous avez changé à cause d’eux, vaut plus que trois ans d’architecture impressionnante. Si vous n’avez pas encore cette histoire, elle est généralement disponible dans votre poste actuel en un trimestre : prenez l’intégration avec le partenaire externe, animez le déploiement auprès du service qui doit changer, passez une semaine au support.
L’erreur que cette voie commet une fois en poste est de construire la version générale. L’instinct qui faisait de vous un bon ingénieur produit est précisément celui qui vous coûtera le premier déploiement. La correction ne consiste pas à baisser vos exigences mais à les déplacer : ce qu’on optimise est le fait que le travail du client ait changé, et un script qui code en dur trois valeurs et y parvient est ici une meilleure pièce d’ingénierie qu’un cadre élégant livré deux mois trop tard.
Deuxième voie : depuis l’avant-vente
Les solutions engineers et les ingénieurs commerciaux arrivent avec la moitié que les ingénieurs produit trouvent la plus difficile. Vous savez déjà tenir une pièce, entendre ce qu’un client veut dire, rester utile quand la conversation devient politique. C’est réellement la moitié la plus dure à acquérir.
Ce qu’il faut prouver est que vous livrez. Le travail d’avant-vente produit du logiciel réel, mais qui a le droit d’être jetable, et ceux qui recrutent connaissent la différence. La preuve qui fonctionne est quelque chose que vous avez construit, qui tourne encore, dont quelqu’un d’autre dépend, et que vous avez dû maintenir une fois la partie intéressante terminée. Un outil interne dont l’équipe commerciale se sert vraiment compte. Une maquette démontrée puis archivée ne compte pas, si impressionnante fût-elle.
L’erreur de cette voie est de transporter le caractère jetable. Un ingénieur de déploiement qui met une maquette en production la maintiendra pendant un an, et le client aura raison d’être mécontent. L’habitude à construire délibérément consiste à se demander, avant d’écrire quoi que ce soit, combien de temps cela doit vivre et qui en répondra dans six mois.
Troisième voie : depuis le métier
La moins discutée, et dans certains secteurs la plus solide. Quelqu’un qui a passé cinq ans comme souscripteur, gestionnaire de sinistres, planificateur logistique ou codeur médical, et qui a appris à construire du logiciel en chemin, sait quelque chose qu’aucune phase de découverte ne produit. Il sait en quoi le travail consiste réellement, exceptions comprises, et il le sait sans avoir à le demander.
Cet avantage est plus grand qu’il n’y paraît à cause de l’endroit où les déploiements échouent. La première étape consiste à traduire le problème, et quelqu’un de l’intérieur du métier fait cette traduction instantanément. Il dispose en outre d’une crédibilité auprès de ceux dont le travail change, monnaie qui ne s’achète pas et que les fournisseurs passent des mois à gagner.
Ce qu’il faut prouver est l’ingénierie, et l’exigence est réelle : du logiciel livré et maintenu, pas des scripts. La version honnête de cette voie prend plus de temps que les deux autres et produit les ingénieurs les plus difficiles à remplacer. Qui l’emprunte a intérêt à viser des postes de déploiement dans son propre ancien secteur plutôt que des postes généralistes, où l’avantage disparaît.
Ce dont aucune des trois n’a besoin
Aucune ne suppose un parcours de recherche en apprentissage automatique. Aucune ne suppose une certification cloud particulière. Aucune ne suppose d’avoir travaillé dans une entreprise réputée pour ce métier, même si cela aide évidemment auprès des recruteurs.
Ce que les trois supposent est une chose simple à énoncer et qui demande une certaine honnêteté à s’évaluer : s’intéresser sincèrement au métier de quelqu’un d’autre. Non pas le tolérer, s’y intéresser. Le poste vous place dans un entrepôt, une salle de marché ou un service administratif hospitalier à poser des questions pour gagner votre vie, et les ingénieurs qui trouvent cela ennuyeux le montrent, ce que les clients remarquent en une semaine.
À quoi ressemble une première année
Attendez-vous à ce que le premier déploiement dure plus longtemps que le plan et vous apprenne que la deuxième étape est le vrai sujet. Attendez-vous à être surpris par la part de la semaine qui n’est pas de l’ingénierie, et à découvrir vers le quatrième mois que c’est soit la meilleure partie du métier, soit la pire. Attendez-vous à un moment seul dans une pièce avec un responsable client mécontent, qui est exactement l’expérience que tout le processus de recrutement cherchait à prédire.
Au bout d’un an vous saurez si le métier vous convient, et le signal n’est pas de savoir si les déploiements se sont bien passés. C’est de savoir si la moitié non technique vous a paru une interruption ou le métier lui-même.
