FDE vs AI engineer : où les deux métiers divergent
Un AI engineer construit le système : recherche, agents, évaluation, garde-fous, latence et coût. Il est jugé sur le fait que ce système soit assez juste, assez rapide et assez peu cher, mesuré contre un jeu d’évaluation qu’il peut lancer quand il veut. Un forward deployed engineer prend un système qui satisfait déjà cette mesure et découvre ce qui se passe quand une organisation réelle y touche. Il est jugé sur le fait que cette organisation ait changé sa façon de travailler, et que le changement ait survécu à son départ. Les deux écrivent du code autour de modèles, et ce code se ressemble souvent. La différence porte sur ce qui compte comme terminé. Pour l’AI engineer, terminé est un chiffre qui bouge sur une mesure. Pour le forward deployed engineer, terminé est quelqu’un qui faisait une chose d’une façon et la fait désormais autrement, volontairement, quand plus personne de chez l’éditeur n’est dans les locaux.
| Forward deployed engineer | AI engineer | |
|---|---|---|
| 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 des systèmes autour des modèles : recherche, agents, évaluation, garde-fous, latence et coût. |
| Jugé sur | Le fait que le travail du client ait changé, et que le changement ait survécu à son départ. | La justesse, la vitesse et le coût du système, mesurés contre un jeu d’évaluation. |
| Travaille dans | Les systèmes, les données et les réunions du client, souvent dans ses locaux. | La base de code du produit, la couche modèle et le harnais d’évaluation. |
| Mène le plus souvent à | Diriger une équipe de déploiement, ou le management produit avec une crédibilité terrain rare. | Staff ou principal sur la plateforme, ou la création d’un produit d’IA appliquée. |
| 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é | Moyen |
| É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.
Le même code, une autre définition de terminé
Placez les deux sur le même problème et pendant une semaine vous auriez du mal à les distinguer. Les deux regarderont les données, les deux écriront la recherche, les deux discuteront du découpage et de ce que doit contenir le jeu d’évaluation. La divergence commence au moment où le système est suffisamment bon sur le papier.
L’AI engineer, à cet instant, a un résultat. Le chiffre a bougé, la suite de non-régression passe, le budget de latence tient. Un problème suivant attend, et y passer est le comportement professionnel correct : son employeur achète un produit qui fonctionne pour tout le monde.
Le forward deployed engineer, au même instant, commence à peine. Sa question suivante est de savoir qui, précisément, regardera cette sortie mardi matin, et ce que cette personne fera quand elle sera fausse. Cette question n’a pas de réponse d’ingénierie. On y répond en s’asseyant à côté de la personne, en la regardant ne pas faire confiance au système, et en découvrant que la raison est une colonne qu’elle corrige mentalement depuis six ans sans l’avoir jamais dit à personne.
Le jeu d’évaluation, ligne de partage honnête
S’il ne fallait qu’un test pour distinguer les deux métiers, ce serait de demander qui possède le jeu d’évaluation et d’où viennent ses cas.
Celui d’un AI engineer est un artefact produit. Il doit se généraliser, il est versionné avec le système, et un cas y entre parce qu’il représente une classe d’entrées que le produit doit traiter. C’est l’instrument par lequel l’équipe sait si elle recule.
Celui d’un forward deployed engineer est une discussion avec un client. Ses cas viennent des dossiers de ce client, ses étiquettes de ses propres experts, et son objectif premier n’est pas de mesurer le système. Il est d’obtenir qu’un groupe de personnes s’accorde, à l’avance, sur ce à quoi ressemble une bonne réponse. La moitié de la valeur est produite avant qu’un seul cas soit lancé, pendant les disputes sur ce qui doit y figurer. Ces disputes font remonter les désaccords internes qui, sinon, seraient apparus trois mois plus tard sous la forme d’une affirmation selon laquelle le système ne marche pas.
Où se situe la difficulté
Les deux métiers sont difficiles, et il vaut la peine d’être précis sur l’endroit où la difficulté se loge, parce que les ingénieurs qui choisissent entre les deux supposent souvent que le déploiement est le plus facile.
La difficulté de l’AI engineer est une profondeur sur un sol mouvant. Les techniques qui comptaient il y a dix-huit mois ont été partiellement absorbées par les modèles, l’outillage est instable, et un système bien conçu l’an dernier peut être battu par quelque chose de plus simple aujourd’hui. Rester à jour occupe une part importante du métier, et le travail est impitoyable comme l’ingénierie l’est d’ordinaire : le système tient sous charge ou il ne tient pas.
Celle du forward deployed engineer est d’une autre nature. Les problèmes techniques sont rarement ce qu’il y a de plus dur dans la pièce. Le plus dur est que la personne dont le système change le travail ne l’a pas demandé, est peut-être évaluée sur l’ancienne façon de faire, et n’a aucune obligation de vous aider. Aucune quantité de compétence technique ne résout cela. On le résout en comprenant ce que cette personne cherche réellement à optimiser, ce qui suppose de s’intéresser à son métier plutôt qu’à votre système.
Les ingénieurs qui trouvent le second type de difficulté dégradant ne devraient pas prendre ce poste. Ceux qui le trouvent la partie la plus intéressante de la semaine sont d’une valeur inhabituelle, parce que l’offre de gens solides sur les deux plans est étroite.
Passer de l’un à l’autre
Le passage de l’ingénierie IA vers le déploiement est le plus courant, et il est plus simple qu’il n’en a l’air sur le papier. Le socle technique se transfère entier. Ce qu’il faut ajouter n’est pas une connaissance mais une habitude : supposer que le problème énoncé est une traduction du problème réel, et considérer la traduction comme votre travail plutôt que comme une contrariété.
Le passage inverse, du déploiement vers l’ingénierie IA, est moins fréquent sans être rare, et ceux qui l’effectuent apportent ce qui manque d’ordinaire à l’équipe cœur. Ils ont vu des systèmes échouer pour des raisons qui n’apparaissent dans aucun harnais d’évaluation. Un ingénieur qui a vu vingt organisations refuser une réponse juste conçoit ses garde-fous différemment.
Le conseil pratique pour qui choisit : la question qui départage n’est pas la technologie que vous préférez. C’est de savoir si vous préférez passer votre mardi à améliorer un chiffre, ou à découvrir pourquoi quelqu’un ne croit pas ce chiffre. Les deux sont de l’ingénierie véritable. Ce ne sont pas la même semaine.
Lire une offre pour savoir laquelle c’est
Les intitulés n’étant normalisés nulle part, le titre vous renseigne moins que les missions. Trois signaux trient la plupart des annonces de façon fiable.
D’abord, quels systèmes sont nommés. Une offre qui parle de la base de code du produit, de son infrastructure d’évaluation et de son budget de latence est un poste d’ingénierie IA, quel que soit son titre. Une offre qui parle d’environnements clients, d’intégrations et de parties prenantes est un poste de déploiement.
Ensuite, si les déplacements sont mentionnés. C’est le signe le plus fiable, et leur absence dans une annonce qui se lit par ailleurs comme du déploiement mérite une question directe plutôt qu’une supposition.
Enfin, quelle est la mesure du succès. Une offre qui décrit le succès en termes de qualité de modèle est un métier. Une offre qui le décrit en termes de comptes, d’adoption ou de délai avant valeur est l’autre. Quand une annonce décrit les deux, il s’agit généralement d’une petite structure où une personne fait les deux, ce qui est un poste légitime et qu’il vaut mieux connaître à l’avance.
