Comment réussir un AI system design interview LLM ?

En clarifiant le besoin avant de dessiner l’architecture. C’est souvent là que tout se joue. Je vais détailler le cadre, les primitives LLM à connaître, les compromis coût-latence-qualité, et la manière de parler production sans raconter une architecture magique.

Pourquoi ces entretiens ont changé ?

Les entretiens ont changé parce que les produits IA ont changé. On n’est plus en train de parler d’une petite démo sympa qui répond à trois questions dans un notebook. On parle de systèmes qui tournent en production, avec des utilisateurs réels, des coûts variables, de la latence, des données privées, des risques de sécurité, et des réponses probabilistes. C’est ça le vrai changement.

Avant, un entretien system design tournait souvent autour d’un CRUD classique, d’un feed, d’un raccourcisseur d’URL, d’un système de réservation. C’était utile, mais assez stable. Avec les LLM, le recruteur veut voir si vous savez penser AI-first. C’est-à-dire concevoir un produit où le modèle n’est pas juste une API magique au milieu du schéma, mais une brique incertaine, chère, parfois lente, parfois brillante, parfois complètement à côté.

La croissance des rôles IA a accéléré ce déplacement. Le rôle d’AI Engineer a explosé, avec environ +143% d’annonces en 2025. LinkedIn a aussi observé environ +75 000 annonces liées à ces rôles entre 2023 et 2025. Je ne dis pas ça pour faire un tunnel de chiffres. Je le dis parce que ça explique pourquoi les recruteurs ne testent plus seulement votre capacité à designer une base SQL propre. Ils veulent savoir si vous savez construire avec des modèles, des embeddings, du RAG, des guardrails, de l’observabilité et des compromis produit.

Les prompts d’entretien ont suivi le mouvement. Aujourd’hui, on vous demande souvent de concevoir quelque chose comme ça :

• Un chatbot support capable de répondre avec les données internes de l’entreprise.
• Un système Q&A avec RAG, donc un système qui récupère les bons documents avant de demander au modèle de répondre.
• Un agent de code qui lit un repo, propose une modification, puis vérifie son travail.
• Un assistant vocal avec transcription, raisonnement, réponse et synthèse vocale.
• Un système proche de ChatGPT, avec historique, mémoire, sécurité et gestion des coûts.

Ce que ces questions testent vraiment, ce n’est pas votre capacité à dessiner une architecture jolie. C’est votre capacité à assembler des briques instables et sensibles sans exploser le budget, sans fuite de données, sans réponse dangereuse, et avec une expérience utilisateur acceptable. J’ai vu des équipes très bonnes techniquement se planter là-dessus, simplement parce qu’elles traitaient le LLM comme une fonction déterministe. Il ne l’est pas.

Donc oui, le contexte a changé. La suite logique, c’est de comprendre ce que les recruteurs évaluent vraiment derrière ces questions, puis de dérouler une méthode claire pour répondre sans partir dans tous les sens.

Que cherche vraiment le recruteur ?

Le recruteur cherche à voir si je sais raisonner sur un système IA réel, avec de l’incertitude, des coûts, des pannes, des compromis et des utilisateurs qui font parfois n’importe quoi. C’est ça le cœur du sujet. Pas réciter LangChain, RAG, vector database et deux noms de modèles à la mode.

Dans un système classique, type CRUD, je crée, lis, modifie ou supprime une donnée. Une requête bien formée donne souvent un résultat attendu. Si je demande l’utilisateur 42, la base me renvoie l’utilisateur 42, ou une erreur claire. Dans un produit basé sur un LLM, un Large Language Model, donc un modèle qui génère du texte à partir d’un contexte, la sortie peut changer d’un appel à l’autre. Elle peut être brillante, fausse, trop lente, trop chère, ou divulguer une information sensible si le système est mal conçu.

C’est là que l’entretien devient intéressant. Le recruteur veut voir si je pense production, pas démo. Un utilisateur peut coller un prompt malveillant, demander au modèle d’ignorer les règles, injecter du contenu piégé dans un document, ou poser une question ambiguë. Le modèle peut halluciner. Le fournisseur externe peut tomber. Le coût peut exploser parce qu’on envoie trop de tokens, les morceaux de texte traités par le modèle.

En entretien, plusieurs points reviennent presque toujours :

• Clarifier les exigences. Qui utilise le système, pour faire quoi, avec quel niveau de risque acceptable ?
• Justifier chaque couche. Pourquoi un orchestrateur, un retriever, une base vectorielle, un reranker, des garde-fous, du streaming, de l’observabilité ou du cache ?
• Estimer les volumes. Combien d’utilisateurs, de documents, de requêtes par minute, de tokens, de coût mensuel ?
• Comprendre les pannes. Que se passe-t-il si le modèle répond n’importe quoi, si la recherche récupère les mauvais documents, si l’API ralentit ?
• Défendre des compromis. Latence contre qualité, coût contre précision, sécurité contre fluidité utilisateur.

Dans mes échanges avec des équipes data et produit, les profils les plus solides ne sont pas forcément ceux qui connaissent le plus de modèles. Ce sont ceux qui savent expliquer ce qui casse en production. Les recruteurs creusent souvent 3 à 5 domaines, puis ils demandent des incidents passés. La meilleure manière de répondre, c’est d’avoir un cadre réutilisable.

Quel cadre utiliser en entretien ?

J’utilise un cadre en sept temps, parce qu’il force à clarifier avant de concevoir, puis à défendre l’architecture au lieu de la dessiner trop vite. En entretien LLM, le piège classique c’est de partir direct sur “base vectorielle + GPT + cache”. Ça sonne bien, mais ça montre surtout qu’on n’a pas compris le problème.

Je commence par clarifier. Je demande quelles sont les sources de données, les règles de confidentialité, le budget de latence, la tolérance aux erreurs factuelles, l’échelle, la fraîcheur attendue des données, et la contrainte entre API tierce et modèle self-hosted. API tierce, c’est OpenAI, Anthropic ou autre fournisseur externe. Self-hosted, c’est un modèle hébergé chez vous, plus contrôlable mais plus lourd à opérer. L’erreur la plus courante, je l’ai vue même chez de bons profils, c’est de sauter ça. Derrière, toute l’architecture flotte.

Ensuite j’estime. Pas besoin d’être exact au token près, mais je pose les ordres de grandeur : tokens par seconde, taille de contexte, volume d’embeddings, coût par appel, QPS de pointe, donc requêtes par seconde, et nombre de conversations par jour. Ça évite de proposer une Ferrari pour un chatbot interne utilisé 200 fois par semaine.

Puis j’esquisse l’architecture. Une entrée utilisateur, un filtrage sécurité et PII, donc données personnelles, un orchestrateur, un retrieval avec base vectorielle et reranker, un routage des modèles selon la difficulté, des garde-fous après le LLM, du streaming de réponse, et de l’observabilité. L’observabilité, c’est les logs, métriques et traces pour comprendre ce qui se passe en prod.

Après ça, je choisis un ou deux sujets pour creuser. RAG, prompts, cache exact ou sémantique, model tiering. Model tiering, c’est router les demandes simples vers un petit modèle moins cher, et les cas complexes vers un gros modèle.

Je parle aussi des compromis. Latence contre qualité. RAG contre fine-tuning. Plafonds de coût. Modèles de secours si le fournisseur tombe. Puis je couvre les pannes : hallucinations, prompt injection, panne API, dérive des embeddings, isolation multi-tenant. Enfin, je fais évoluer le système avec tests A/B de prompts, feedback utilisateur, portes d’évaluation avant déploiement, et migration progressive des modèles.

Étape	Ce que je dis en entretien	Pourquoi ça compte
Clarifier	Je pose les données, la confidentialité, la latence, l’échelle et le choix API ou self-hosted.	Ça évite de concevoir à l’aveugle.
Estimer	Je chiffre tokens, contexte, embeddings, coût, QPS et conversations.	Ça rend l’architecture réaliste.
Concevoir	Je dessine le flux avec sécurité, retrieval, reranking, routage, garde-fous et observabilité.	Ça montre le système complet, pas juste le LLM.
Creuser	Je deep dive un ou deux composants clés.	Ça prouve que je sais opérer les détails.
Comparer	Je défends les compromis coût, latence, qualité et résilience.	Ça montre du jugement.
Sécuriser	Je couvre hallucinations, injection, pannes et multi-tenant.	Ça prépare la prod.
Faire évoluer	Je prévois tests, feedback, évaluations et migration progressive.	Ça évite un système figé.

Quels composants LLM faut-il maîtriser ?

Il faut maîtriser les primitives qui reviennent presque toujours : RAG, routage de modèles, cache, garde-fous, observabilité et évaluation. C’est rarement plus exotique que ça en entretien. Le sujet, c’est surtout de montrer que vous savez les assembler proprement.

Le RAG, pour Retrieval Augmented Generation, veut dire génération augmentée par récupération d’information. L’idée est simple. Un encodeur transforme la requête utilisateur en représentation numérique, souvent un vecteur. Un retriever cherche ensuite les documents les plus proches ou les plus pertinents. Puis le modèle génératif répond avec deux choses sous les yeux : la question et le contexte récupéré.

En production, ça devient un peu plus sérieux. On ajoute du chunking, c’est-à-dire le découpage des documents en morceaux exploitables. On met en place un pipeline d’embeddings, donc une chaîne qui transforme les textes en vecteurs. On utilise une base vectorielle pour retrouver vite les bons passages. Parfois, on ajoute un reranker, un modèle qui reclasse les résultats avant de les donner au LLM. Et derrière, on garde du cache, des journaux d’évaluation, du contrôle d’accès, parce que tous les utilisateurs ne doivent pas voir les mêmes documents.

Le RAG peut réduire fortement les hallucinations, j’ai vu des ordres de grandeur autour de 40 à 71% selon les cas et les datasets. Mais ce n’est pas magique. Si vos documents sont mauvais, mal découpés ou mal récupérés, le modèle répondra quand même à côté.

Le model routing, c’est l’autre brique à connaître. Envoyer toutes les requêtes à un modèle frontier, donc un modèle très puissant type GPT-4, coûte vite cher. On parle souvent d’environ 10 à 30 dollars par million de tokens en entrée-sortie, avec une latence autour de 3 à 5 secondes. Avec 10 000 conversations par jour à 5 000 tokens, la facture peut dépasser 7 500 dollars par mois selon le fournisseur.

Le piège, c’est que 60 à 80% des requêtes sont souvent routinières. Pas besoin d’un monstre pour reformuler un mail ou répondre à une question simple. Un bon routage peut économiser 40 à 70% des coûts, tout en gardant les meilleurs modèles pour les vrais cas difficiles.

Si la requête est simple et non sensible	Utiliser un modèle rapide et moins cher
Si la requête demande du raisonnement, plusieurs documents ou implique un risque métier	Utiliser un modèle plus puissant
Si le fournisseur échoue ou dépasse le temps limite	Basculer vers un modèle de secours

Le cache évite de recalculer les réponses fréquentes. Les garde-fous filtrent les sorties dangereuses ou hors politique. L’observabilité permet de suivre latence, coût, erreurs, qualité et dérives. L’évaluation mesure si le système répond mieux qu’hier. Connaître ces briques ne suffit pas, il faut maintenant expliquer comment elles vivent en production.

Comment parler production et évolution ?

Je parle production en expliquant ce qui peut casser, comment je le détecte, et comment je fais évoluer le système sans mettre les utilisateurs en danger. C’est ça qui rassure en interview. Pas le diagramme parfait avec trois flèches et un joli modèle au milieu.

Un système LLM casse rarement d’un seul coup. Il se dégrade. Il hallucine, il répond hors format, il expose une donnée personnelle, il se fait manipuler par une prompt injection, il tombe parce que le fournisseur LLM est indisponible. Parfois le retrieval ramène les mauvais documents, les embeddings dérivent après une mise à jour, la latence explose, les coûts partent en vrille, ou un tenant voit des données qui appartiennent à un autre tenant. Là, c’est grave. L’OWASP Top 10 for LLM Applications documente très bien ces risques, notamment l’injection de prompt, la fuite de données, la mauvaise gestion des permissions et la dépendance excessive au modèle. Le NIST AI Risk Management Framework pousse la même logique côté pilotage du risque : mesurer, gouverner, surveiller, améliorer. Ce n’est pas théorique, c’est juste du bon sens appliqué à l’IA.

Je veux donc voir ce qui se passe vraiment en production. Un système IA sans mesure, c’est juste une boîte noire chère.

• Je logue les prompts et réponses, mais avec masquage ou suppression des données sensibles.
• Je trace chaque étape : requête utilisateur, retrieval, ranking, appel LLM, post-traitement, fallback.
• Je mesure la latence, le coût par requête, le taux d’erreur, le taux de fallback et les timeouts.
• Je suis le score de retrieval, les documents utilisés, les réponses refusées et le feedback utilisateur.
• Je garde des échantillons audités et des jeux d’évaluation avant chaque déploiement.

Pour faire évoluer le système, je ne pousse pas un nouveau prompt en prod “au feeling”. Je teste. Je compare. Je limite le risque. Les prompts passent par des tests A/B, avec des métriques claires. Les nouveaux modèles tournent d’abord sur du shadow traffic, c’est-à-dire du trafic réel copié sans impacter l’utilisateur. Puis je fais une canary release sur une petite partie des utilisateurs. Si les métriques se dégradent, rollback immédiat.

J’ai vu un client diviser ses coûts par deux juste en ajoutant un routage simple : petit modèle pour les demandes faciles, gros modèle uniquement quand c’est nécessaire. Rien de magique. Juste de l’observation et des garde-fous.

Dans un AI system design interview, je ne cherche pas à vendre une architecture parfaite. Je montre que je sais piloter un système imparfait avec méthode, et que je sais le faire évoluer sans transformer les utilisateurs en cobayes.

Alors, comment je me démarque vraiment en entretien ?

Je me démarque en évitant le piège classique : dessiner trop vite. Un bon AI system design interview commence par les exigences, continue avec des estimations simples, puis déroule une architecture défendable. RAG, routage de modèles, cache, garde-fous et observabilité ne sont pas des mots à placer. Ce sont des choix à expliquer. Le recruteur veut voir si je sais gérer la latence, le coût, la qualité, la sécurité et les pannes. Si vous préparez ce cadre sérieusement, vous répondez avec plus de calme, plus de précision, et surtout avec une logique de production. Le bénéfice pour vous est clair : vous passez d’une réponse théorique à une vraie posture d’ingénieur IA.

FAQ

• Qu’est-ce qu’un AI system design interview ?
  C’est un entretien où on vous demande de concevoir un système basé sur l’IA, souvent avec des LLM. Le sujet peut être un chatbot, un moteur Q&A avec RAG, un agent de code ou un assistant vocal. Le but n’est pas de réciter une architecture, mais de montrer comment vous raisonnez sur les données, la latence, le coût, la sécurité, la qualité des réponses et les pannes possibles.
• Quelle est l’erreur la plus fréquente dans ce type d’entretien ?
  L’erreur la plus fréquente, c’est de commencer par dessiner l’architecture sans clarifier le besoin. Avant de parler base vectorielle ou orchestrateur, il faut demander quelles données sont disponibles, quelles règles de confidentialité s’appliquent, quel est le budget de latence, quel niveau d’erreur est acceptable, quelle échelle est visée et si on peut utiliser une API externe ou non.
• Pourquoi le RAG revient si souvent dans les entretiens IA ?
  Le RAG revient souvent parce qu’il permet à un LLM de répondre avec un contexte récupéré dans des documents ou bases internes. C’est une brique très utilisée pour les systèmes Q&A, les assistants métier et les chatbots connectés à de la connaissance privée. En production, il faut parler chunking, embeddings, base vectorielle, reranking, contrôle d’accès, cache et évaluation.
• Comment parler des coûts pendant l’entretien ?
  Il faut raisonner en tokens, volume, QPS et modèle utilisé. Une bonne réponse montre qu’on ne met pas toutes les requêtes sur le modèle le plus cher. Le routage de modèles aide à envoyer les demandes simples vers un modèle rapide et économique, et les demandes difficiles vers un modèle plus puissant. C’est souvent un levier majeur pour réduire les coûts sans trop perdre en qualité.
• Comment montrer une vraie expérience de production ?
  Il faut parler de ce qui casse : hallucinations, prompt injection, panne fournisseur, dérive des embeddings, fuite de données, latence, explosion des coûts. Puis expliquer comment on mesure : logs, traces, métriques, feedback, jeux d’évaluation, tests A/B, canary release et rollback. C’est là qu’on voit la différence entre une démo IA et un système exploitable.

 

 

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. J’accompagne des équipes qui doivent connecter data, IA et systèmes réels, pas juste faire des prototypes propres en démo. Avec mon agence webAnalyste et l’organisme Formations Analytics, j’ai travaillé pour des clients comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Si vous voulez structurer vos projets IA, vos workflows ou votre architecture data, contactez-moi.