Entretien AI Engineer : les 2 premières questions
Article 1 de la série The AI Engineer Loop — À quoi ressemble un entretien d'AI Engineer en 2026, question par question.
Un entretien d'AI Engineer commence rarement par de la théorie. Selon les entreprises, il s'ouvre par un appel de trente minutes avec un recruteur ou le responsable de l'équipe, et son seul objectif est de décider si vous avez déjà livré quelque chose ou si vous avez surtout suivi des tutoriels.
Ce premier appel pose deux questions, presque toujours les mêmes. Cet article les prend une à une : ce qu'elles testent, comment y répondre en une minute trente, et ce qui fait décrocher l'interlocuteur.
C'est la première étape d'une boucle qui en compte une dizaine : l'écran, les fondamentaux, la recherche documentaire (RAG), les agents, le contexte, l'évaluation, la production, l'exercice de code, la conception de système, vos projets, puis vos propres questions. Chaque étape a son article.
Ce que le recruteur cherche
Quelqu'un capable de faire se comporter un composant non déterministe comme une fonctionnalité de produit : de façon fiable, à coût maîtrisé, et preuves à l'appui.
Retenez ce dernier mot, il revient dans toute la boucle. La plupart des candidats savent décrire un système RAG. Beaucoup moins savent dire comment ils ont su qu'un changement était une amélioration. Cette capacité à mesurer est ce qui sépare les candidats, et on la cherche dès les premières minutes.
« Parlez-moi de ce que vous avez construit avec des LLM. »
Ce que la question teste. Si vous avez des cicatrices de production ou une aisance de tutoriel. Les deux se distinguent à la première phrase.
La structure qui tient en 90 secondes
- Le problème et la contrainte, pas la stack. « Le support passait six heures par jour à répondre à des questions déjà présentes dans la documentation » vaut mieux que « j'ai monté un RAG avec LangChain ».
- Ce que vous avez construit, en une phrase.
- Une chose difficile qui a cassé, et comment vous l'avez trouvée. C'est la phrase la plus informative de tout l'entretien : elle montre que vous avez diagnostiqué avec des preuves, pas au feeling.
- Un chiffre : taux de résolution automatique, latence p95, coût par ticket résolu, score d'évaluation avant et après.
Puis arrêtez-vous. Quatre-vingt-dix secondes, et laissez l'interlocuteur tirer le fil.
Un exemple de réponse complète
Cet exemple est inventé pour illustrer le format. Remplacez l'histoire et les chiffres par les vôtres.
Chez un éditeur de logiciels, l'équipe support passait environ six heures par jour à répondre à des questions dont la réponse figurait déjà dans la documentation. La contrainte : aucune réponse inventée, une documentation qui change chaque semaine, et un budget de quelques centimes par conversation.
J'ai construit un assistant qui retrouve les passages pertinents dans la documentation et répond en les citant.
Ce qui a cassé : au bout de deux semaines, une réponse sur cinq était fausse, alors que le modèle n'avait pas changé. J'ai étiqueté cinquante échecs réels, et dans deux cas sur trois le bon passage n'était même pas récupéré : c'était un problème de découpage des documents, pas de modèle.
En corrigeant le découpage et en ajoutant une recherche par mots-clés, le taux de bonnes réponses sur mon jeu de test est passé de 71 % à 88 %, et le support a vu le volume de tickets sur ces sujets baisser d'un tiers.
Une minute environ à voix haute. Et chaque phrase répond d'avance à une relance probable.
Au lieu de… dites plutôt…
Mêmes exemples fictifs.
| Au lieu de dire… | Dites plutôt… |
|---|---|
| « J'ai fait un RAG avec LangChain et une base vectorielle. » | « Le support perdait six heures par jour sur des questions déjà documentées. » |
| « Ça marchait plutôt bien. » | « Le taux de bonnes réponses est passé de 71 % à 88 % sur 150 questions étiquetées. » |
| « On a eu quelques soucis de qualité. » | « Une réponse sur cinq était fausse ; deux fois sur trois, le bon passage n'était jamais récupéré. » |
La relance qui suit presque toujours est : « Comment avez-vous su que c'était mieux ? » Si vous avez un jeu de test et un avant/après, vous avez déjà répondu. C'est le thème de l'étape « évaluation », celle où se jouent le plus souvent les offres.
Signal d'alarme : énumérer des frameworks. Personne ne recrute pour une connaissance de LangChain : on recrute pour le jugement sur le moment où le modèle est la mauvaise réponse.
« Pourquoi l'AI engineering plutôt que la recherche en ML ? »
Ce que la question teste. Que vous avez compris le métier pour lequel vous postulez.
Ce qu'il faut dire
- Le travail intéressant s'est déplacé des poids vers le système qui les entoure : la recherche d'information, les outils, l'état, l'évaluation, les garde-fous, le coût.
- Dites simplement que vous optimisez des systèmes, pas des fonctions de perte.
- Et que vous êtes à l'aise d'être mesuré sur ce que les utilisateurs obtiennent, plutôt que sur un score de benchmark.
La phrase à prononcer en entretien
Parce que le travail qui m'intéresse s'est déplacé : il n'est plus dans les poids du modèle, il est dans le système autour — la recherche, les outils, l'état, l'évaluation, les garde-fous, le coût. Je n'optimise pas une fonction de perte, j'optimise un système, et je suis à l'aise d'être mesuré sur ce que les utilisateurs obtiennent plutôt que sur un score de benchmark. Sur le projet que je viens de décrire, le gain n'est pas venu d'un meilleur modèle : il est venu de l'étiquetage de cinquante échecs.
Remarquez la dernière phrase : elle reprend votre histoire de la question précédente. Les deux réponses sont lues ensemble, et leur cohérence est un signal en soi. Une motivation abstraite est oubliée ; une motivation illustrée par ce que vous avez réellement fait reste.
Les deux manières de rater cette question
- Présenter l'AI engineering comme un repli (« je ne suis pas assez bon en maths pour la recherche »). L'étape suivante de la boucle teste justement les fondamentaux — voir l'attention calculée à la main — et elle vous contredira.
- Rester abstrait (« j'aime les produits », « j'aime l'impact »). Sans exemple ni mesure, ça ne se distingue pas d'une réponse générée à la chaîne.
Comment vous y préparer
Le plus important tient en une ligne : répondez à voix haute. Dans votre tête, tout paraît fluide ; c'est en parlant que les phrases qui ne tiennent pas se révèlent.
- Chronométrez-vous : 90 secondes pour la première question, 30 pour la seconde.
- Écrivez vos chiffres sur une page : taille du corpus, trafic, latence p95, coût par requête, score avant et après. Relisez-la deux fois.
- Préparez une seconde histoire que vous n'aurez peut-être pas à raconter : ce qui a cassé en production, ou ce que vous avez abandonné parce que l'évaluation ne justifiait pas de livrer. Celle-là, la plupart des candidats ne l'ont pas, et c'est celle dont on se souvient.
Signal d'alarme : « c'était plutôt rapide », « ça marchait bien ». Le flou sur son propre système se lit comme l'absence d'avoir été responsable de quoi que ce soit.
Article suivant de la série The AI Engineer Loop : « Expliquez un transformer » — ce qu'on attend vraiment de vous, et la différence entre citer le papier et connaître la machine.
Chez Viite, nous simplifions les processus d'entreprise avec l'IA, mais pour l'humain. Nous éditons aussi l'application Business Studio pour gérer vos vies privées ou pros.