Entretien d'AI Engineer en 2026 : RAG, évaluation et system design

Salut HaWkers, connaître les noms des modèles ne suffit plus pour expliquer le fonctionnement d'une application d'IA. Le dépôt public AI Engineering Interview Questions Company Wise, créé en septembre 2026, regroupe des questions sur la recherche d'informations, l'inférence, les agents, l'évaluation et la sécurité. Lors de la consultation de GitHub pour cet article, il comptait 1 562 étoiles. Ce chiffre témoigne de l'intérêt pour le sujet ; il ne prouve pas que chaque question ait été posée dans un véritable recrutement.

Si la personne qui mène l'entretien vous demande de concevoir un assistant répondant à partir de documents internes, par où commenceriez-vous ? Vous allez ici construire une réponse vérifiable : définir le problème, créer un petit jeu de cas, mesurer la recherche, observer les erreurs et défendre vos choix d'architecture. Ce plan permet de s'exercer en français et de s'adapter à un entretien dans une autre langue.

Commencez par le travail que le système doit accomplir

Avant de choisir un modèle, décrivez l'utilisateur, les informations disponibles et le résultat acceptable. Imaginez une équipe d'assistance qui consulte des règles internes. La question « Puis-je annuler après le renouvellement ? » semble simple, mais la réponse dépend de la version de la règle, du pays, du type de contrat et des droits de la personne qui interroge le système. Si vous ignorez ces détails, une réponse fluide peut être fausse.

Lors d'un entretien, précisez quels documents entrent dans l'index, à quelle fréquence ils changent et qui peut y accéder. Définissez ensuite la sortie : une réponse courte, la référence du passage source et un refus si les preuves sont insuffisantes. Vous montrez ainsi que vous comprenez le produit et ses risques. La documentation d'OpenAI sur les évaluations souligne qu'une application doit être testée avec des cas représentatifs et des critères clairs. Le cadre de gestion des risques liés à l'IA du NIST aide également à réfléchir au contexte, à la mesure et au suivi, sans transformer une liste de principes en garantie automatique de sécurité.

Une bonne question à poser en retour est : « Quelle erreur coûterait le plus cher ici : ne pas répondre ou répondre à partir d'une règle périmée ? » La réponse change le seuil de confiance, le besoin de validation humaine et même l'expérience d'utilisation. Posez cette question avant de promettre une précision donnée. Elle vaut mieux qu'une architecture générique récitée de mémoire.

Transformez des questions isolées en cas de test

Beaucoup de candidats préparent leurs entretiens en parcourant une longue liste de questions et en essayant de mémoriser les réponses. Pour un poste d'AI Engineer, il est plus utile de transformer certaines questions en petites expériences. Si le sujet est le RAG, créez un jeu comprenant la question, le document attendu et une réponse acceptable. Ajoutez un cas sans réponse : un système fiable doit pouvoir dire qu'il n'a pas trouvé l'information.

L'exemple suivant utilise uniquement la bibliothèque standard de Python. Enregistrez-le dans casos.py et lancez python casos.py. Les données sont fictives et servent à s'entraîner ; elles ne représentent pas les règles d'une entreprise. La vérification initiale évite qu'un cas reste sans question ou sans référence, erreur courante dans les tableaux d'évaluation préparés à la hâte.

# Cas fictifs pour préparer un entretien technique.
casos = [
    {"pergunta": "Qual é o prazo de cancelamento?", "fonte": "politica_2026", "resposta": "Consulte o contrato vigente."},
    {"pergunta": "Como redefinir a senha?", "fonte": "acesso", "resposta": "Use a página de recuperação."},
    {"pergunta": "Qual é o preço do plano futuro?", "fonte": None, "resposta": None},
]

for numero, caso in enumerate(casos, start=1):
    assert caso["pergunta"], f"Caso {numero} sem pergunta"
    assert (caso["fonte"] is None) == (caso["resposta"] is None), f"Caso {numero} incoerente"
    print(numero, "respondível" if caso["fonte"] else "sem evidência")

Ce jeu est encore bien trop petit pour estimer les performances réelles. Pendant l'entretien, expliquez comment l'élargir : questions fréquentes, formulations ambiguës, documents contradictoires, changements de règles et tentatives d'accès aux données d'une autre personne. Séparez les exemples de développement de ceux de l'évaluation finale afin de ne pas ajuster le système en regardant les réponses du test. Dans un domaine réglementé, demandez une revue par des spécialistes du sujet.

Le dépôt à l'origine de cet article est utile comme catalogue de thèmes, mais considérez ses descriptions des processus de recrutement comme des récits de leurs auteurs. Vérifiez toujours l'offre et le contact de l'entreprise. Les questions publiques changent ; savoir construire un test reproductible reste utile même si le déroulement d'un entretien évolue.

Expliquez le RAG comme une suite de décisions

Le RAG associe la recherche de passages à la génération d'une réponse. Son schéma minimal comprend l'ingestion, le découpage des documents, l'indexation, la recherche, la sélection des passages et la génération avec référence à la source. Mais chaque étape peut perdre de l'information. Découper un contrat au milieu d'une exception peut faire disparaître la condition qui rend une clause applicable. Une recherche qui retrouve le bon document, mais dans une ancienne version, échoue elle aussi.

Montrez que vous distinguez la qualité de la recherche de celle de la réponse. Si le bon passage ne parvient jamais au modèle, changer le prompt ne résout pas le problème principal. Une mesure simple pour s'entraîner est le recall@k : dans combien de cas le document attendu figure-t-il parmi les k premiers résultats ? Le code suivant reçoit des résultats simulés et compte les succès sans service externe.

# Vérifiez si la source attendue figure parmi les trois premiers résultats.
avaliacoes = [
    {"esperado": "politica_2026", "recuperados": ["faq", "politica_2026", "arquivo"]},
    {"esperado": "acesso", "recuperados": ["acesso", "suporte"]},
    {"esperado": "faturamento", "recuperados": ["vendas", "faq"]},
]

k = 3
acertos = sum(item["esperado"] in item["recuperados"][:k] for item in avaliacoes)
recall = acertos / len(avaliacoes)
print(f"recall@{k}: {recall:.1%} ({acertos}/{len(avaliacoes)})")

Le résultat ne mesure que cet échantillon fictif. Il ne démontre ni que la réponse générée est correcte, ni que la source citée justifie la phrase finale. Dites-le clairement. Proposez ensuite des filtres par version, langue et droits d'accès ; comparez la recherche lexicale, vectorielle et hybride sur les mêmes cas ; examinez les erreurs à la main avant de changer d'outil. Une réponse mûre en entretien précise également dans quelles conditions il faudrait arrêter ou revoir le système.

Évaluez la réponse, le refus et la provenance

Une réponse peut citer le bon document tout en inventant une conclusion. L'évaluation doit donc vérifier au moins trois points : répond-elle à la question, son contenu est-il étayé par le passage et le système refuse-t-il de répondre en l'absence de fondement ? Ne réduisez pas tout à une note unique sans savoir quelles erreurs elle masque. Pour une règle interne, une fausse affirmation peut être plus grave qu'un refus prudent.

L'exercice suivant présente un vérificateur déterministe très limité. Il n'accepte que les réponses dont le texte figure littéralement dans les passages autorisés. En production, les paraphrases légitimes demandent une évaluation plus élaborée et une revue humaine ; ici, la règle stricte rend le contrat visible et discutable pendant l'entretien.

# Démonstration : la réponse doit figurer dans le passage autorisé.
def verificar_resposta(resposta, trechos):
    if not resposta.strip():
        return "recusa"
    texto_permitido = " ".join(trechos).casefold()
    return "sustentada" if resposta.casefold() in texto_permitido else "revisar"

trechos = ["Use a página de recuperação para redefinir a senha."]
print(verificar_resposta("Use a página de recuperação", trechos))
print(verificar_resposta("A senha é enviada por SMS", trechos))
print(verificar_resposta("", []))

Ne présentez pas ce code comme un détecteur universel d'hallucinations. Il échoue avec les paraphrases, les négations et les textes longs. Une solution sérieuse combine des critères automatiques, des échantillons relus par des personnes, l'analyse des incidents et la surveillance après la mise en service. Pendant l'échange, expliquez ce que vous mesureriez par segment : langue, type de document, version et catégorie de question. Une moyenne globale peut cacher une erreur grave dans un petit groupe.

Enregistrez aussi la provenance de chaque affirmation présentée par le système. Si un document est mis à jour, vous devez pouvoir retrouver la version qui justifiait l'ancienne réponse. Sans cette trace, une réclamation devient une discussion fondée sur des souvenirs. Cette exigence relie l'évaluation à l'architecture : identifiant et version du document, date d'indexation et passages utilisés doivent accompagner la réponse.

Défendez votre system design avec des limites explicites

Au tableau ou dans le document d'entretien, dessinez deux parcours. Le premier met les documents à jour : il reçoit une version, valide les métadonnées, applique le contrôle d'accès et publie un nouvel index. Le second traite une question : il authentifie la personne, ne récupère que les données qu'elle peut consulter, produit une réponse référencée et consigne l'opération. Expliquez comment vous empêchez une mise à jour partielle de mélanger anciens et nouveaux passages.

Parlez ensuite de budget : délai maximal, coût par requête, taille du contexte et capacité à absorber les pics. N'inventez pas un objectif de latence si l'énoncé n'en fournit pas. Demandez l'objectif de service et indiquez comment vous le mesureriez. Une file d'attente, un cache ou un modèle plus petit peuvent aider, mais chaque choix a un coût : le cache doit être invalidé quand la règle change ; le plus petit modèle doit être évalué sur les cas difficiles ; une file d'attente peut ne pas convenir à une assistance interactive.

Une trace minimale aide à comparer les solutions. Le code suivant mesure une fonction locale et enregistre des identifiants fictifs sans conserver de texte sensible. Dans un vrai système, les identifiants doivent respecter la politique de confidentialité et la durée de conservation définie par l'organisation.

# Chronométrez l'opération et ne consignez que les métadonnées nécessaires.
from time import perf_counter

def responder(pergunta):
    return "Consulte a política vigente" if pergunta else "Pergunta vazia"

inicio = perf_counter()
resposta = responder("Posso cancelar?")
duracao_ms = (perf_counter() - inicio) * 1000
evento = {"documento": "politica_2026", "modelo": "exemplo_local", "duracao_ms": round(duracao_ms, 2)}
print(resposta, evento)

Cet exemple ne mesure pas un appel réseau et ne prédit pas les performances en production. Il illustre une discipline : mesurer l'opération réelle, enregistrer la version utilisée et comparer les résultats dans des conditions équivalentes. Lors de l'entretien, précisez ce qui se passe si la recherche échoue, si le modèle tarde ou si la citation pointe vers un document supprimé. Un parcours d'erreur clair révèle souvent plus de maturité qu'un diagramme rempli de cases.

La sécurité fait partie de la réponse technique

Les documents retrouvés sont des données, pas des instructions fiables. Un passage peut contenir une phrase malveillante demandant d'ignorer les règles ou d'envoyer des informations à une autre adresse. Le projet OWASP Top 10 pour les applications LLM recense des risques comme l'injection de prompt et l'exposition d'informations sensibles. Servez-vous-en pour structurer vos questions de sécurité, sans supposer qu'un filtre de texte éliminera tous les risques.

Décrivez des frontières concrètes : autorisation avant la recherche, outils dotés des permissions minimales, confirmation des actions sensibles, isolation des données entre clients et tests avec des entrées adverses. Si l'application se contente de répondre, ne lui donnez pas de droits d'écriture. Si elle peut agir, enregistrez qui a autorisé l'action, ce qui a été demandé et le résultat obtenu. Une réponse responsable distingue clairement lire, suggérer et exécuter.

Cela compte aussi pour la carrière. Une personne qui débute peut montrer sa maturité sans construire un produit complet. Un petit projet avec des cas de test, des erreurs documentées et des décisions justifiées apprend davantage qu'une démonstration parfaite fondée sur un seul prompt. L'article sur la façon de se démarquer sur le marché difficile des emplois juniors en 2026 explique comment présenter les preuves de son travail. Ici, la preuve est simple : montrer ce que vous avez testé, où le système a échoué et ce que vous feriez ensuite.

Un plan pratique pour le prochain entretien

Consacrez une séance à comprendre l'offre et à énumérer les tâches qu'elle demande réellement. « AI Engineer » peut désigner un produit fondé sur un LLM, une infrastructure d'inférence, l'évaluation ou l'intégration de données. Répartissez les thèmes de l'offre en trois groupes : je peux les expliquer et les démontrer ; je peux les expliquer, mais je dois m'exercer ; je ne peux pas encore défendre mes choix. Cette classification évite de consacrer tout votre temps à des nouveautés sans rapport avec ce recrutement.

À la séance suivante, choisissez un petit problème et construisez les cas. Rédigez d'abord la réponse manuelle attendue et sa source, puis implémentez une recherche simple et mesurez ses erreurs. Lors d'une autre séance, présentez l'architecture à voix haute : entrée, permissions, mises à jour, recherche, génération, évaluation et gestion des pannes. Demandez à quelqu'un de vous interrompre avec « Et si le document était périmé ? » ou « Comment savez-vous que la réponse est juste ? ». S'entraîner à répondre aux objections prépare mieux que mémoriser des sigles.

Terminez par une feuille de décisions : hypothèses connues, questions ouvertes, autres solutions écartées et mesures encore manquantes. Si la personne qui mène l'entretien modifie le scénario, vous pourrez adapter votre conception au lieu de défendre une recette figée. Soyez honnête sur les limites des exemples. Le code de cet article est pédagogique ; une vraie application exige une gestion des autorisations, des données représentatives, une surveillance et des tests proportionnés aux risques.

Perspectives : moins de récitation, plus de preuves

Les listes publiques de questions aident à explorer le sujet, mais elles ne remplacent pas une explication capable de tenir face à un nouveau cas. Le meilleur signe dans un entretien technique est de pouvoir dire ce que le système doit accomplir, comment vérifier le résultat et dans quelles conditions il doit refuser de répondre. RAG, évaluation et system design se rejoignent ici, car une erreur à une étape se propage aux autres.

Apportez un petit projet que vous pouvez ouvrir, exécuter et critiquer. Si le poste demande une autre technologie, gardez la méthode : délimitez le problème, montrez un test, présentez les compromis et rendez l'incertitude visible. C'est une preuve de pratique en ingénierie, y compris quand la bonne réponse consiste à demander plus de contexte avant de choisir un outil.

Allez, on y va! 🦅

📚 Vous Voulez Suivre Ce Qui Arrive?

Cet article a abordé les entretiens d'AI Engineer, mais cet écosystème évolue chaque semaine et tout ne devient pas un article ici.

Sur X, je partage mes essais, les coulisses de mes projets et les nouveautés avant qu'elles ne deviennent des articles.

Suivez-Moi La-Bas

👉 Suivre @jeffbruchado sur X

💡 Du contenu quotidien sur le développement, la carrière et les outils que j'utilise vraiment