Comment réussir un AI system design interview technique IA ?

Je le réussis en montrant que je sais concevoir un système IA complet, pas juste appeler un LLM. Il faut clarifier, estimer, dessiner l’architecture, défendre les compromis coût, latence, qualité, sécurité, puis parler pannes et production.

Pourquoi l’entretien a changé ?

Les entretiens ont changé parce que le métier a changé. Avant, on me demandait souvent de designer un service CRUD propre, avec une API, une base de données, du cache, une file de messages, et une stratégie de scalabilité. C’était utile, mais assez déterministe. Une requête rentre, une règle métier s’applique, une réponse sort.

Aujourd’hui, on me demande beaucoup plus souvent : Comment vous construiriez un chatbot IA pour le support client ? Un système RAG pour chercher dans une base documentaire ? Un agent de coding ? Un assistant vocal ? Un assistant juridique capable de citer ses sources ? Et là, on n’est plus dans le même monde.

Un LLM, c’est un grand modèle de langage. Il prédit du texte. Il ne “sait” pas au sens classique. Il peut répondre juste, répondre flou, inventer une info, coûter cher si le prompt est énorme, ou être lent si on enchaîne trop d’appels. C’est pour ça que l’entretien AI system design teste autre chose que “je sais appeler l’API d’OpenAI”. Le recruteur veut voir comment j’encapsule le modèle dans un produit robuste.

Je l’ai vu chez des clients aussi. Le prototype IA marche vite. La démo impressionne. Puis arrivent les vraies questions : Qui a accès aux données ? Combien coûte chaque conversation ? Comment je mesure la qualité ? Comment je limite les hallucinations ? Que se passe-t-il si l’agent boucle pendant 8 étapes et appelle trois outils inutiles ?

Les signaux marché vont dans le même sens. Plusieurs tendances emploi tech, dont des analyses visibles côté LinkedIn, montrent une forte progression des annonces liées à l’IA. Il faut rester prudent avec les chiffres, parce que les définitions changent vite, mais l’idée est claire : Les entreprises recrutent des profils capables de mettre des LLM en production, pas juste d’en parler.

En entretien, je dois donc parler de récupération d’information, d’embeddings, de confidentialité, de coût tokens, de latence modèle, de boucles agentiques et d’évaluation qualité. Un embedding, c’est juste une représentation numérique d’un texte pour retrouver des contenus proches. Un système RAG, c’est quand je récupère les bons documents avant de demander au modèle de répondre. Simple sur le papier, beaucoup moins simple en prod.

Ancien system design	AI system design interview
Logique déterministe	Logique probabiliste
Base de données	Contexte et embeddings
Scalabilité classique	Coût tokens et latence modèle
Monitoring technique	Évaluation qualité et hallucinations

Que regarde vraiment le recruteur ?

Le recruteur regarde surtout si je sais raisonner sous contraintes, pas si je connais trois noms de modèles à la mode. C’est vraiment ça le fond du sujet. Dans un AI system design interview, chaque couche doit avoir une raison d’exister. Si je propose un composant, je dois être capable de dire ce qu’il protège, ce qu’il coûte, et ce qui casse si je l’enlève.

Si je mets une couche de sécurité PII, donc une détection des données personnelles comme un email, un numéro de téléphone ou un identifiant client, je dois expliquer le risque sans elle. Fuite de données. Non-conformité. Réponse envoyée au mauvais endroit. Logs qui gardent des infos sensibles. J’ai déjà vu ce sujet exploser chez un client juste parce que les prompts étaient loggés “pour debug”. Sur le papier c’était pratique. En prod, c’était dangereux.

Si je propose un reranker, je dois aussi être honnête. Un reranker reclasse les documents récupérés avant de les donner au modèle. Il améliore souvent la qualité quand le retrieval remonte trop de résultats moyens. Mais il ajoute de la latence, du coût, et parfois il ne sert à rien si les requêtes sont simples ou si la base documentaire est petite. Même logique pour le cache. Un cache exact répond quand la même question revient mot pour mot. Un cache sémantique répond quand une question proche revient avec un sens similaire. C’est plus puissant, mais plus risqué si deux questions se ressemblent sans demander la même réponse.

Les trois compétences évaluées sont assez nettes.

Expliquer l’architecture	Je sais dire pourquoi chaque brique existe et comment les données circulent.
Défendre les compromis	Je compare qualité, coût, latence, sécurité et complexité sans vendre une solution magique.
Anticiper les modes d’échec	Je parle des pannes, des abus, des hallucinations, des dérives et des cas limites.

Sur un entretien senior, on ne couvre pas tout en surface. On plonge souvent dans trois à cinq zones précises. Le retrieval, le routing de modèles, les garde-fous, l’observabilité, ou l’isolation multi-tenant, c’est-à-dire la capacité à bien séparer les données et les accès entre plusieurs clients.

Les relances ressemblent souvent à ça. Que se passe-t-il si le fournisseur LLM tombe ? Que se passe-t-il si l’utilisateur tente une injection de prompt ? Que faites-vous si les embeddings dérivent avec le temps ? Que coupez-vous si le coût explose ? Comment réagissez-vous si le modèle hallucine sur une réponse sensible ?

Les repères sérieux existent. OWASP Top 10 for LLM Applications aide à cadrer les risques applicatifs des systèmes LLM. NIST AI RMF donne une logique de gestion des risques IA. Je n’ai pas besoin d’en faire un cours réglementaire, mais montrer que je connais ces cadres donne du crédit.

• Je pose des questions avant de dessiner.
• Je chiffre vite les volumes, la latence et les coûts.
• Je parle des pannes sans attendre qu’on me les impose.
• Je sais réduire les coûts sans casser la qualité.
• Je sais mesurer la qualité avec des métriques, des tests et du feedback utilisateur.

Quel cadre suivre sans paniquer ?

L’erreur classique, je l’ai vue souvent chez des profils très bons techniquement, c’est de sauter directement sur l’architecture. Ça rassure, on dessine des boîtes, on parle vector database, LLM, cache, mais l’entretien part vite dans le flou si on n’a pas cadré le problème.

Le cadre que j’utilise tient en sept mouvements. D’abord, je clarifie. Je pose les questions qui évitent les hors-sujets : quelles sources de données, quelles contraintes de confidentialité, quel budget de latence, quelle tolérance aux erreurs factuelles, quelle échelle, quelle fraîcheur des données, quelles APIs tierces autorisées, self-hosting ou fournisseur externe.

Ensuite, j’estime. Pas besoin d’être exact au centime près, mais je veux des ordres de grandeur : tokens par seconde, taille de contexte, volume d’embeddings, coût par appel, QPS de pointe. QPS veut dire requêtes par seconde, c’est souvent ce qui casse une belle architecture sur tableau blanc.

Clarifier	Je verrouille le besoin, les contraintes, les données et les risques.
Estimer	Je donne des ordres de grandeur sur trafic, tokens, coûts et stockage.
Dessiner	Je pose les couches : input utilisateur, sécurité et PII, orchestrateur, retrieval avec base vectorielle et reranker, modèle avec routage par difficulté, garde-fous post-LLM, streaming, observabilité.
Approfondir	Je choisis un ou deux sujets selon la question : RAG, prompts, cache exact ou sémantique, tiers de modèles.
Arbitrer	Je parle latence contre qualité, RAG contre fine-tuning, plafonds de coût, modèles de repli.
Prévoir les pannes	Je couvre hallucinations, prompt injection, panne fournisseur, dérive embeddings, isolation multi-tenant.
Expliquer l’évolution	Je prévois tests A/B de prompts, feedback utilisateurs, évaluations avant release et migration progressive de modèles.

Quand je dessine, je garde l’ordre simple. L’utilisateur envoie une demande. Je filtre les données personnelles, ou PII, c’est-à-dire les emails, numéros, noms sensibles. L’orchestrateur décide quoi faire. Le retrieval récupère le contexte utile dans une base vectorielle, puis un reranker reclasse les meilleurs passages. Le modèle est choisi selon la difficulté. Après génération, je valide la sortie, je stream la réponse, et je logge tout pour observer qualité, coût et erreurs.

# Orchestrateur pédagogique, sans fournisseur précis

def handle_request(user_input, user_id):
    # Détecter et masquer les données personnelles
    safe_input, pii_flags = detect_pii(user_input)

    # Récupérer du contexte via recherche vectorielle
    candidates = vector_search(safe_input, top_k=20)
    context = rerank(safe_input, candidates, top_k=5)

    # Scorer la complexité de la demande
    complexity = score_complexity(safe_input, context)

    # Choisir le modèle selon qualité, latence et coût
    if complexity > 0.75:
        model = "large_reasoning_model"
    else:
        model = "fast_cost_effective_model"

    # Générer une réponse avec contexte contrôlé
    answer = generate(
        model=model,
        prompt=safe_input,
        context=context
    )

    # Valider la sortie avant affichage
    validation = validate_output(answer, pii_flags)
    if not validation["ok"]:
        answer = fallback_answer()

    # Logger pour évaluation, coûts et amélioration continue
    log_eval(
        user_id=user_id,
        model=model,
        complexity=complexity,
        validation=validation,
        context_ids=[doc["id"] for doc in context]
    )

    return stream(answer)

Le bon signal en entretien, ce n’est pas d’avoir l’architecture parfaite. C’est de montrer que je sais avancer sans panique, poser les bonnes limites, et expliquer ce que je sacrifierais si le budget, la latence ou la qualité deviennent tendus.

Quelles briques IA maîtriser ?

Dans un entretien AI system design, je reviens toujours aux mêmes briques. Pas parce que c’est à la mode, mais parce que c’est là que le système tient ou casse en prod : RAG, routage de modèles, cache, garde-fous et observabilité.

Le RAG, Retrieval Augmented Generation, c’est simple à expliquer. J’ai une requête utilisateur, un encodeur la transforme en vecteur, un retriever renvoie une liste classée de documents proches, puis un générateur répond avec la requête et le contexte récupéré. En production, je parle aussi de chunking, donc le découpage des documents, du pipeline d’embeddings, de la recherche vectorielle, d’un reranker, du caching, des logs d’évaluation et des contrôles d’accès. Un RAG peut réduire fortement les hallucinations, avec des chiffres souvent cités autour de 40 à 71 % selon les cas. Mais ce n’est pas magique. Si les données sont mauvaises, si les chunks sont trop gros, ou si personne ne mesure la qualité, le RAG répondra mal avec beaucoup d’assurance.

def rag_answer(question):
    # Chunks fictifs récupérés depuis une base vectorielle
    chunks = [
        {"text": "Le remboursement prend 14 jours.", "score": 0.82},
        {"text": "Les retours sont gratuits en France.", "score": 0.76},
        {"text": "Le support répond sous 48h.", "score": 0.41},
    ]

    # Reranking simplifié : on garde les passages les plus utiles
    reranked = sorted(chunks, key=lambda x: x["score"], reverse=True)[:2]

    context = "\n".join([c["text"] for c in reranked])

    # Prompt final donné au modèle génératif
    prompt = f"""
    Réponds uniquement avec le contexte fourni.
    Question: {question}
    Contexte:
    {context}
    """

    return prompt

Le model routing, c’est l’autre brique que je veux maîtriser. Un modèle haut de gamme coûte cher et répond plus lentement. On voit souvent des fourchettes de 10 à 30 dollars par million de tokens selon les modèles et configurations, avec des latences qui montent à plusieurs secondes. Un agent à 10 000 conversations par jour, 5 000 tokens par conversation, peut dépasser plusieurs milliers de dollars par mois si tout part vers le modèle le plus cher.

La logique est saine : Les demandes simples vont vers un petit modèle, les demandes ambiguës vers un modèle moyen, les cas complexes vers le meilleur modèle. Dans certains produits, 60 à 80 % des requêtes sont routinières. Avec une vraie évaluation, le routage peut économiser 40 à 70 %. J’ai déjà vu un client diviser sa facture juste en arrêtant d’envoyer les “Bonjour, où est ma facture ?” au modèle premium.

def route_model(user_message):
    # Score simple basé sur longueur, ambiguïté et mots sensibles
    complex_words = ["juridique", "diagnostic", "analyse", "contrat", "erreur critique"]
    score = len(user_message.split()) / 50

    if any(word in user_message.lower() for word in complex_words):
        score += 2

    if "?" in user_message and len(user_message) > 200:
        score += 1

    if score < 1:
        return "small_model"
    if score < 3:
        return "medium_model"
    return "large_model"

Brique	Usage	Bénéfice	Risque	Question à préparer
RAG	Répondre avec des documents	Moins d’hallucinations	Mauvais chunks, mauvais droits	Comment évaluer la qualité du retrieval ?
Fine-tuning	Adapter le comportement	Style et tâches répétées	Coût, dérive, données faibles	Pourquoi ne pas faire juste du RAG ?
Cache	Réponses fréquentes	Coût et latence réduits	Réponse périmée	Quand invalider le cache ?
Model routing	Choisir le bon modèle	Économie et vitesse	Mauvais routage	Comment mesurer la perte de qualité ?

Et si le vrai sujet était la maîtrise des compromis ?

Un AI system design interview, ce n’est pas un concours de noms de modèles. Je dois montrer que je sais poser les bonnes questions, estimer vite, construire une architecture propre, puis défendre mes choix sous contraintes. Le recruteur veut voir si je comprends le coût, la latence, la qualité, la sécurité, les hallucinations, les pannes fournisseur et l’évolution en production. Les briques comme RAG, model routing, cache et observabilité servent à ça. Si vous arrivez avec ce cadre en tête, vous parlez comme quelqu’un qui a déjà pensé produit, pas juste démo. Le bénéfice pour vous est simple : des réponses plus solides, plus crédibles, plus senior.

FAQ

• Qu’est-ce qu’un AI system design interview ?
  C’est un entretien où je dois concevoir l’architecture d’un produit basé sur l’IA, souvent avec un LLM. Le sujet n’est pas juste de générer une réponse, mais de gérer le retrieval, la sécurité, la latence, le coût, les hallucinations, les pannes et l’observabilité.
• Quelle est l’erreur la plus fréquente en entretien ?
  Sauter directement sur la solution. Je préfère d’abord clarifier les contraintes : données disponibles, confidentialité, budget de latence, volume, tolérance aux erreurs, fraîcheur attendue et limites de coût. Sans ça, l’architecture flotte un peu.
• Faut-il toujours proposer un RAG ?
  Pas toujours. RAG est très utile quand la réponse dépend de connaissances internes, fraîches ou vérifiables. Mais il ajoute du chunking, des embeddings, une base vectorielle, du reranking, des contrôles d’accès et de l’évaluation. Je dois savoir expliquer ce coût de complexité.
• Pourquoi parler de model routing ?
  Parce que tout envoyer au modèle le plus puissant peut coûter cher et augmenter la latence. Le routage permet d’envoyer les demandes simples vers des modèles moins coûteux et de réserver les modèles avancés aux cas complexes. C’est souvent un très bon signal senior.
• Comment montrer une expérience production pendant l’entretien ?
  Je parle des pannes avant qu’on me les demande : hallucinations, prompt injection, panne fournisseur, dérive des embeddings, fuite de données, isolation multi-tenant. Puis j’explique comment je mesure : logs, évaluations, feedback, tests A/B de prompts et garde-fous avant release.

 

 

A propos de l’auteur

Je suis Franck Scandolera, expert et formateur en tracking avancé server-side, Analytics Engineering, automatisation No/Low Code avec n8n, intégration de l’IA en entreprise et SEO/GEO. Avec mon agence webAnalyste et l’organisme Formations Analytics, j’accompagne des équipes sur des sujets très concrets : architectures data, mesure, automatisation, IA opérationnelle et passage en production. J’ai travaillé avec des références comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Si vous voulez structurer vos projets IA ou former vos équipes, contactez-moi.