AI engineer : construire tout ce qui entoure le modèle
L’AI engineer construit le système autour du modèle, et non le modèle lui-même. La recherche qui va chercher la bonne information, la boucle qui enchaîne les étapes, les garde-fous qui empêchent une sortie aberrante de partir, le jeu d’évaluation qui dit si le tout fonctionne, et la maîtrise du coût et de la latence sans laquelle rien ne passe en production. C’est un métier d’ingénierie logicielle appliqué à des composants probabilistes, ce qui en change la pratique sans en changer la nature : on conçoit, on mesure, on exploite, on diagnostique. Sa particularité tient à ce sur quoi il est jugé. La mesure n’est pas la qualité du code mais un chiffre obtenu contre un jeu d’évaluation qu’il peut lancer quand il veut. Cette boucle courte est ce qui rend le métier agréable, et elle contient aussi sa façon caractéristique d’échouer : le jour où ce jeu cesse de ressembler à ce que les utilisateurs envoient, les chiffres continuent de monter pendant que le produit se dégrade.
AI engineer, en bref
Métier établi| En une phrase | Construit le système autour du modèle : recherche, agents, évaluation, garde-fous, latence et coût. |
|---|---|
| Jugé sur | Le fait que le système soit assez juste, assez rapide et assez peu cher, mesuré contre un jeu d’évaluation qu’il peut lancer quand il veut. |
| Échoue quand | Le jeu d’évaluation cesse de ressembler à ce que les utilisateurs envoient, et les chiffres continuent de s’améliorer pendant que le produit se dégrade. |
| Confondu avec | L’ingénieur en apprentissage automatique, qui entraîne des modèles au lieu de construire par-dessus. |
Recruté comme poste distinct dans de nombreuses entreprises, avec un périmètre reconnaissable. Aucun chiffre de rémunération : voir notre méthode.
Ce que le poste recouvre réellement
La recherche d’information. Découper les sources, indexer, retrouver le bon passage, et surtout gérer les droits pour que chacun ne voie que ce qu’il a le droit de voir. Cette dernière partie est la moins spectaculaire et la plus coûteuse à rattraper.
La boucle et les outils. Quand une étape suffit, une étape suffit. Quand plusieurs sont nécessaires, l’enjeu est d’en limiter le nombre, chaque étape ajoutant du coût, de la latence et de l’imprévisibilité.
Les garde-fous. Ce que le système refuse de faire, ce qu’il signale comme hors de son domaine, et ce qu’il remonte à une personne. Un système qui ne remonte jamais rien traite avec assurance des cas qu’il ne maîtrise pas.
L’évaluation. La partie la plus déterminante et celle que les fiches de poste mentionnent le moins. Construire le jeu, le faire étiqueter par les bonnes personnes, le rejouer, lire ses résultats par catégorie.
Le coût et la latence. Deux contraintes qui éliminent des architectures entières et qu’on découvre trop tard quand on ne les pose pas au cadrage.
Le jeu d’évaluation, cœur du métier
Ce qui sépare un bon AI engineer d’un ingénieur compétent qui travaille sur ces sujets tient rarement à la connaissance des outils, qui s’acquiert en quelques semaines. Cela tient à la façon dont il traite l’instrument de mesure.
Un jeu construit une fois, au lancement du projet, et jamais mis à jour devient trompeur en quelques mois. De nouvelles catégories de cas apparaissent, l’équipe finit par optimiser pour les cas qu’elle connaît, et les chiffres s’améliorent sur un monde qui n’existe plus.
L’ingénieur qui sait cela ajoute régulièrement des cas récents, retire ceux qui ne représentent plus rien, et lit ses résultats par catégorie plutôt qu’en moyenne. C’est une discipline modeste, et c’est ce qui distingue un système qui tient trois ans d’un système qui se dégrade en silence.
La confusion avec l’apprentissage automatique
Les deux intitulés s’échangent dans les annonces et désignent des métiers différents. L’ingénieur en apprentissage automatique entraîne, règle et sert des modèles ; l’AI engineer construit par-dessus des modèles fournis par d’autres.
Le signe le plus fiable dans une annonce est le vocabulaire des données. Une offre qui parle de jeux d’entraînement, de distribution, de chaîne d’alimentation et de réentraînement désigne le premier métier. Une offre qui parle de recherche documentaire, de garde-fous, de latence et de coût par requête désigne le second.
Cette distinction compte pour un candidat parce que les deux carrières divergent. Le premier métier mène vers la recherche appliquée et l’infrastructure de données ; le second vers l’ingénierie de plateforme et, pour ceux qui aiment le contact, vers le déploiement.
Où mène ce poste
Trois suites reviennent régulièrement. L’ingénierie de plateforme, pour ceux qui prennent goût à rendre réutilisable ce qu’ils ont construit une fois. L’architecture, pour ceux qui préfèrent décider en amont plutôt que construire. Et le déploiement, pour ceux qui découvrent que la partie la plus intéressante de leur semaine est le moment où le système rencontre des gens.
Cette troisième voie est la moins prévue et la plus fréquente chez les profils solides. Elle suppose d’accepter une mesure du succès différente : non plus un chiffre qui bouge, mais une organisation qui travaille autrement. C’est ce que décrivent nos pages sur le forward deployed engineer.
