Préparer un entretien AI Engineer : les trois axes réellement évalués

Ce qu'un process AI Engineer évalue réellement

Les intitulés varient d'une entreprise à l'autre, mais l'entretien cherche presque toujours à répondre à trois questions : savez-vous concevoir un système reposant sur un modèle, savez-vous mesurer s'il fonctionne, et savez-vous le maintenir quand il tourne pour de vrai.

Cela explique une frustration fréquente : des candidats très à l'aise techniquement sont écartés parce qu'ils traitent l'entretien comme un examen de connaissances. Connaître les familles de modèles, les bases vectorielles ou les frameworks d'orchestration est supposé. Ce qui est évalué, c'est votre manière de décider sous contrainte.

• Conception : traduire un besoin flou en système dont les composants ont une raison d'être.
• Évaluation : définir ce que « ça marche » veut dire, puis le mesurer.
• Exploitation : tenir le système dans la durée, avec un coût, une latence et des régressions.

Un process comporte souvent aussi un échange produit ou métier. Il n'est pas accessoire : c'est là que se juge votre capacité à discuter d'un cas d'usage sans le réduire à une implémentation.

L'échange de cadrage : situer votre périmètre en une phrase

Le premier entretien sert à savoir où vous placer. L'erreur consiste à dérouler un parcours chronologique. Situez d'abord votre périmètre actuel — le type de systèmes que vous construisez, pour quel usage, avec quel niveau de responsabilité — puis reliez-le au besoin décrit dans l'offre.

La conception d'un système reposant sur un LLM

L'exercice le plus courant est ouvert : « comment construiriez-vous un assistant qui répond aux questions de nos clients à partir de notre documentation ». Ce qui est observé, c'est l'ordre dans lequel vous procédez. Commencer par nommer une architecture avant d'avoir cadré le problème est souvent pénalisé.

1. 1

   Cadrer l'usage

   5 min

   Qui pose les questions, à quelle fréquence, et que se passe-t-il si la réponse est fausse ? Le coût d'une erreur détermine tout le reste : niveau de garde-fous, place de l'humain, exigence de traçabilité.

2. 2

   Cadrer la donnée

   5 min

   Qui possède les documents, comment évoluent-ils, sont-ils propres, versionnés, soumis à des droits d'accès différents ? Beaucoup de systèmes échouent ici, pas sur le modèle. Le cas le plus sensible : un système qui restitue à un utilisateur un document auquel il n'a pas accès. Dites comment les droits suivent la donnée jusqu'à la réponse — filtrage à la récupération, cloisonnement des index, traçabilité des sources citées.

3. 3

   Proposer une première version simple

   10 min

   Une architecture minimale qui répond au besoin, avec les composants justifiés un par un. Annoncez explicitement ce que vous ne mettez pas dans la version 1 et pourquoi.

4. 4

   Nommer les points de rupture

   5 min

   Volume, fraîcheur, ambiguïté des questions, documents contradictoires. Décrivez ce qui casserait en premier et comment vous le détecteriez.

Un candidat solide dit aussi ce qu'il écarte : pas d'agent multi-outils tant qu'une récupération simple n'est pas fiable, pas de fine-tuning tant que le problème relève du contexte et non du comportement du modèle. Un arbitrage explicite porte plus loin qu'une réponse exhaustive. Si l'exercice prend la forme d'un system design complet, notre guide dédié au system design en entretien IA en détaille le déroulé ; inutile de le rejouer ici.

L'évaluation : la question qui départage le plus vite

« Comment saviez-vous que c'était bon ? » Cette question tranche un entretien en deux minutes. Une réponse vague — « on a testé, les retours étaient positifs » — signale un prototype. Une réponse précise signale un système.

• Un jeu d'exemples représentatifs, constitué avec les personnes qui connaissent le métier, pas généré au hasard.
• Des critères explicites : réponse correcte, réponse fondée sur les sources, absence d'invention, format exploitable.
• Un mélange assumé de mesures automatiques et de relecture humaine, avec la part de chacune.
• Une comparaison entre versions : ce que change une modification de prompt, de modèle ou de récupération.
• Des cas volontairement difficiles : questions hors périmètre, documents contradictoires, formulations ambiguës.

Si vous n'avez jamais construit d'évaluation formelle, dites-le, puis décrivez comment vous procéderiez sur le cas discuté. Un raisonnement structuré sur un manque assumé passe mieux qu'une réponse générique récitée.

L'exploitation : coût, latence, régressions

Beaucoup d'organisations sont sorties de la phase d'exploration. Elles cherchent des personnes capables de tenir un système existant, pas seulement d'en démarrer un. Préparez un exemple d'incident réel : ce qui s'est passé, comment vous l'avez vu, ce que vous avez changé.

• Ce qui pilotait le coût : taille du contexte, nombre d'appels, choix du modèle, cache.
• Ce que vous observiez en continu, et pourquoi : la latence de bout en bout parce qu'elle conditionne l'usage réel, le taux d'appels en échec ou hors format parce qu'il révèle une dérive du fournisseur, la part de questions sans réponse ou sans source citée parce qu'elle annonce une perte de qualité avant que les utilisateurs ne la signalent.
• Comment vous détectiez une régression après une modification de prompt ou un changement de version de modèle.
• Ce qui déclenchait un retour arrière, et qui prenait cette décision.

Un changement de version de modèle qui dégrade silencieusement la qualité est l'un des sujets les plus discutés en entretien. Savoir dire comment vous le détecteriez suffit souvent.

La partie code : ce qui est réellement observé

L'exercice de code d'un process AI Engineer est rarement un exercice algorithmique difficile. Il porte le plus souvent sur ce qui entoure l'appel à un modèle : un contrat de sortie à respecter, un service qui répond mal, un résultat qui change d'une exécution à l'autre.

• Une réponse hors format : validez le schéma attendu et définissez le comportement quand la validation échoue, plutôt qu'un parsing optimiste.
• Un appel modèle ou service qui échoue ou expire : dites ce que vous retentez, ce que vous dégradez, et ce que reçoit l'utilisateur quand rien ne répond.
• Des sorties non déterministes : montrez comment vous rendez le test possible malgré tout — cas figés, tolérance explicite, vérification d'une propriété plutôt que d'une chaîne exacte.
• Un repli assumé quand la qualité n'est pas au rendez-vous : renvoyer « je ne sais pas » en citant les documents trouvés reste préférable à une réponse fabriquée.

Préparer trois exemples plutôt que dix projets

Un process entier se couvre avec trois exemples travaillés en profondeur : un système que vous avez conçu, une évaluation que vous avez mise en place, un problème de production que vous avez résolu. Ils peuvent venir du même projet.

Pour chacun, préparez la même trame : le problème, la contrainte dominante, deux décisions et leur motif, la manière dont la qualité était mesurée, une limite assumée. Cette trame permet de répondre à des questions très différentes sans réciter. Notre guide sur la présentation d'un projet IA en entretien détaille la méthode complète pour construire ces exemples.

Les questions à poser en fin d'entretien

Vos questions signalent votre niveau autant que vos réponses. Trois suffisent, à condition qu'elles portent sur le réel.

• Qui possède la donnée nécessaire, et dans quel état est-elle aujourd'hui ?
• Y a-t-il déjà un système en production, et qui l'exploite au quotidien ?
• Qui décide de la feuille de route et comment la valeur du système est-elle jugée en interne ?

Les réponses vous diront plus sur le poste que l'intitulé : une organisation sans donnée disponible ni système en production cherche souvent un défricheur, pas un ingénieur d'exploitation — et l'inverse est vrai.

• Entretiens
• AI Engineering
• Évaluation
• Production