FDE vs ingénieur logiciel : le même code, un autre métier
Mettez les deux devant le même éditeur et vous verrez la même chose : le même langage, les mêmes bibliothèques, les mêmes demandes de relecture. La différence ne se voit pas dans le code, elle se voit dans les conditions. Un ingénieur logiciel travaille sur un système qu’il possède, dans une infrastructure que son équipe a choisie, pour des utilisateurs qu’il connaît par des statistiques. Un forward deployed engineer travaille sur un système qu’il ne possède pas, dans une infrastructure qu’on lui impose, pour des utilisateurs qu’il voit en face de lui et dont il connaît le prénom. Le premier optimise une chose pour beaucoup de monde ; le second adapte une chose à une seule organisation. Cela produit deux carrières très différentes à partir d’une compétence de départ identique, et le choix entre les deux ne se joue presque jamais sur le niveau technique. Il se joue sur ce qu’on accepte de ne pas contrôler.
| Forward deployed engineer | Ingénieur produit | |
|---|---|---|
| En une phrase | Un ingénieur employé par l’éditeur, qui travaille dans l’organisation du client pour que le produit règle le vrai problème de ce client. | Un ingénieur qui construit et maintient le produit lui-même, pour tous les clients plutôt que pour un seul. |
| Jugé sur | Le fait que le travail du client ait changé, et que le changement ait survécu à son départ. | Le fait que le logiciel soit correct, maintenable et livré. |
| Travaille dans | Les systèmes, les données et les réunions du client, souvent dans ses locaux. | La base de code du produit, ses tests, ses revues et sa chaîne de livraison. |
| Mène le plus souvent à | Diriger une équipe de déploiement, ou le management produit avec une crédibilité terrain rare. | Senior, staff et principal, ou le management d’équipe. |
| Temps passé chez le client La part de la semaine passée avec ceux qui emploieront la chose. | Élevé | Faible |
| Profondeur technique Jusqu’où va l’ingénierie attendue du poste. | Élevé | Élevé |
| Profondeur métier À quel point le poste doit comprendre le métier du client lui-même. | Élevé | Faible |
| Écriture de code La part du travail qui consiste réellement à écrire et intégrer du logiciel. | Élevé | Élevé |
| Responsable du résultat Si le poste est jugé sur la livraison, ou sur ce que la livraison a changé. | Élevé | Moyen |
Ces niveaux décrivent le centre de gravité d’un poste, pas une règle. Les intitulés ne sont normalisés nulle part : une offre donnée peut se situer loin de sa colonne. Lisez ce qu’elle dit que la personne va construire plutôt que son titre.
Ce que vous contrôlez, et ce que vous subissez
L’ingénierie produit repose sur un socle stable. Vous connaissez la version de la base de données, vous décidez du calendrier de déploiement, et lorsqu’une dépendance vous gêne, vous pouvez ouvrir une discussion pour en changer. Les contraintes existent, mais elles sont internes et négociables.
Le déploiement fonctionne à l’inverse. La version de la base de données est celle que la direction informatique du client a validée il y a trois ans, la fenêtre de mise en production est mensuelle, et la bibliothèque qui vous simplifierait la vie ne passera pas la revue de sécurité avant six semaines. Rien de tout cela n’est négociable, et protester coûte du crédit sans rien changer.
C’est le point de rupture réel entre les deux métiers. Les ingénieurs qui vivent mal le déploiement sont rarement ceux qui manquent de niveau ; ce sont ceux pour qui l’absence de contrôle sur l’environnement est une souffrance quotidienne. Ceux qui s’y épanouissent traitent la contrainte comme la matière du problème plutôt que comme un obstacle à sa résolution.
La boucle de retour
Un ingénieur produit apprend par l’agrégat. Une fonctionnalité sort, les courbes bougent ou ne bougent pas, et l’enseignement arrive sous forme statistique, plusieurs semaines après l’écriture du code. C’est une boucle lente mais fiable : elle porte sur des milliers d’utilisateurs et résiste aux cas particuliers.
Un forward deployed engineer apprend par l’observation directe. Il voit une personne utiliser ce qu’il a écrit une heure plus tôt, et il voit surtout ce qu’aucune courbe ne remonte : l’hésitation avant de cliquer, le retour à l’ancienne méthode dès que le résultat surprend, la feuille de calcul gardée ouverte à côté par méfiance. Cette boucle est rapide et riche, mais elle porte sur une poignée de personnes, et la généraliser est une erreur classique du métier.
Les meilleurs profils font circuler l’information entre les deux boucles. Ils rapportent à l’équipe produit ce qu’ils ont vu de leurs yeux, formulé comme une observation et non comme une demande de fonctionnalité, et c’est souvent leur contribution la plus durable à l’entreprise.
La forme de la compétence
Au bout de cinq ans, les deux profils sont forts, mais pas de la même forme.
L’ingénieur produit a de la profondeur. Il connaît un système comme peu de gens connaissent quoi que ce soit, il sait où sont les zones dangereuses, et il peut prévoir l’effet d’un changement sans le tester. Cette connaissance est précieuse et partiellement intransférable : elle porte sur ce système précis.
Le forward deployed engineer a de la largeur et une compétence particulière que le métier fabrique presque à son insu : lire vite un système qu’il n’a pas écrit. Ouvrir une base de code inconnue, trouver la couche qui compte, repérer les endroits où l’on ment sur les données, tout cela devient un réflexe quand on le fait quatre fois par an. Cette compétence se transfère partout, et elle explique pourquoi ces profils atterrissent fréquemment sur des postes de plateforme ou d’architecture ensuite.
Comment choisir, sans se tromper de question
Trois questions départagent mieux que n’importe quelle grille de rémunération.
La première : qu’est-ce qui vous satisfait en fin de semaine ? Un système plus propre qu’au lundi, ou une personne qui fait son travail autrement. Les deux réponses sont honorables, elles ne mènent pas au même poste.
La deuxième : comment réagissez-vous quand la cause d’un problème se révèle politique ? Si cela vous paraît hors sujet, l’ingénierie produit vous protégera ; si cela vous paraît être le problème intéressant, le déploiement vous en servira toutes les semaines.
La troisième : à quoi ressemble votre vie en dehors du travail dans deux ans ? Le déplacement n’est pas un détail de poste, c’est une structure de vie, et c’est la raison la plus fréquente de départ du métier, loin devant l’ennui ou la rémunération.
