AI Engineer : ma définition pragmatique après 6 mois en prod

Je code sur MedGPT, un assistant médical IA en prod, depuis fin 2025. Main dev fullstack sur le produit, en collaboration avec un AI Engineer dédié. Six mois d’observation rapprochée du rôle, vu depuis la position du dev qui doit livrer le reste du produit à côté. Assez pour comprendre à quel point le terme est utilisé à tort par à peu près tout le monde sur LinkedIn.

Le rôle n’a pas encore de définition stable. Les annonces LinkedIn veulent tout dire en même temps. Un job demande un PhD en machine learning. Le suivant demande de savoir appeler l’API OpenAI. Le troisième mélange React, Terraform et prompt engineering dans la même bullet list. Ces trois profils ne font pas le même métier. On les confond parce qu’on ne sait pas encore comment découper.

Je propose ma définition. Elle tient en une phrase.

Un AI Engineer est un software engineer qui sait lire un prompt comme un contrat et mesurer un output comme un bench.

Deux axes. Ni ML, ni React. Autre chose.

Axe 1 : un prompt est un contrat

Un prompt qui pilote un LLM en production n’est pas de la prose. C’est une spec. Elle définit un comportement attendu : quel format en sortie, quel ton, quels cas à refuser, quelles citations à produire, quelles contraintes à respecter. Comme n’importe quelle spec, elle peut être incomplète, elle peut se contredire avec une autre spec en amont, elle peut être violée par un input adversarial.

La conséquence opérationnelle : un changement de prompt est un changement de comportement. Il doit être traité comme un déploiement. Version du prompt tracée. Rollback possible. Tests sur un eval set figé avant merge. Diff lu par quelqu’un qui comprend le produit, pas juste l’auteur.

Dans une équipe qui n’applique pas ça, on voit le pattern classique : quelqu’un modifie un prompt à chaud, l’output change, un utilisateur remonte un comportement inattendu, personne ne sait quel prompt était en prod à ce moment-là. C’est la même erreur que de patcher du code en prod sans commit. Mais beaucoup d’équipes l’autorisent sur les prompts parce que “c’est juste du texte”.

L’AI Engineer au sens où je l’entends refuse ça. Il impose le prompt comme un artefact de déploiement de première classe.

Axe 2 : un output est un bench

Un LLM est stochastique. Un même input peut produire deux outputs différents, même à température zéro sur certains modèles. “Ça a l’air bon” n’est pas un test. C’est une impression.

Pour savoir si un prompt marche, il faut un eval set. Un ensemble d’inputs connus, une heuristique de scoring (humaine, automatique, hybride), une métrique agrégée qu’on traque dans le temps. Success rate sur la tâche. Hallucination rate. Latence p95. Coût par requête. Ces chiffres doivent exister avant d’optimiser, sinon chaque optimisation est une superstition.

Un AI Engineer passe une part non-triviale de son temps à construire ces evals. Pas à les déléguer à un PM ou un designer. Pas à les improviser en fin de sprint. À les construire, les ajuster, les durcir quand un nouveau cas d’échec est observé en prod.

Sans bench, une équipe qui “fait de l’IA” fait surtout du sentiment. Elle croit que ça marche parce que le dernier output vu était satisfaisant. Quand le rate d’échec est à 15%, elle le découvre par un ticket utilisateur, pas par un dashboard.

Ce que ça n’est PAS

Trois profils que le terme AI Engineer absorbe à tort :

• ML Engineer. Training de modèles, fine-tuning, orchestration de pipelines data. Ce métier existe, il est précieux. Dans la majorité des produits IA en prod que je vois autour de moi, il n’est pas au centre du quotidien. L’équipe consomme des modèles fermés ou open-weights via API. Le training est souvent délégué à un fournisseur. Les heures passées sur le fine-tuning sont rares.

• Data Scientist. Analyses, notebooks, visualisations. Le cycle de dev est différent. Le livrable aussi. Un data scientist qui tente de shipper un produit en prod sans accompagnement software s’en sort mal, et inversement.

• Frontend developer qui intègre une API. C’est peut-être le contresens le plus fréquent. Tu peux câbler openai.createChatCompletion dans ton React en trois heures. Tu n’as pas fait de l’AI Engineering. Tu as fait de l’intégration. Le travail d’AI Engineer commence quand tu dois garantir que cette intégration produit des outputs fiables sur 10 000 requêtes et qu’un prompt modifié par erreur ne fait pas exploser le comportement en silence.

Pourquoi ça compte

Le rôle va se formaliser dans les 18 mois qui viennent. Les boîtes qui recrutent AI Engineer aujourd’hui vont durcir leurs critères. Celles qui embauchent un frontend-qui-a-touché-OpenAI en disant AI Engineer vont regretter dans six mois, quand les bugs en prod ne pourront pas être debuggés par quelqu’un qui n’a pas construit d’eval set. Celles qui embauchent un ML Engineer pour shipper un produit IA vont se rendre compte que personne dans l’équipe ne sait faire passer un prompt en code review.

Le rôle qui marche est entre les deux. Un software engineer avec un nouveau réflexe : traiter les comportements stochastiques avec la rigueur qu’on applique aux comportements déterministes. Versionner ce qui change. Mesurer ce qu’on affirme.

Sans bench, pas d’AI Engineering

Le code marche si ça compile. Un prompt marche si ça passe le bench. Si ton équipe AI Engineering n’a pas de bench, tu n’as pas d’AI Engineering.