Comment réussir un AI system design interview ?

Je le réussis en cadrant le problème avant de dessiner l’architecture. Un bon entretien IA teste surtout votre raisonnement face au coût, à la latence, à la qualité et à la sécurité. Je vous montre le cadre simple que j’utiliserais pour répondre proprement, sans réciter une checklist.

Pourquoi ces entretiens ont changé ?

Les entretiens de conception système ont changé parce que les rôles IA ont explosé. Avant, on vous demandait surtout de designer une architecture web classique. Une API, une base de données, du cache, une file de messages, un peu de scaling. Aujourd’hui, les recruteurs veulent voir si vous savez penser un produit IA complet.

Et ça change tout.

Un système IA n’est pas juste déterministe. Déterministe, ça veut dire qu’à entrée égale, vous obtenez toujours la même sortie. Avec un modèle IA, vous êtes souvent dans du probabiliste. Le modèle peut répondre différemment, halluciner, mal interpréter une intention, coûter trop cher, ou prendre trop de temps.

Quand on vous demande de concevoir un chatbot IA, un système RAG, un agent de code ou un assistant vocal, le sujet dépasse largement le choix entre PostgreSQL et DynamoDB. Le RAG, pour Retrieval Augmented Generation, consiste à chercher des informations dans vos données avant de les donner au modèle pour générer une réponse. Il faut penser au retrieval, donc à la recherche d’information. Il faut penser à l’orchestration, c’est-à-dire comment les composants s’enchaînent. Il faut penser aux boucles agentiques, quand un agent IA planifie, agit, observe le résultat, puis recommence.

Et là, les questions deviennent vite très concrètes. Combien coûte un appel modèle ? Quelle latence est acceptable ? Que se passe-t-il si le modèle invente une réponse ? Comment protéger les données sensibles ? Comment empêcher une injection de prompt, c’est-à-dire une instruction malveillante glissée dans une entrée utilisateur ou un document ?

Le piège classique, c’est de commencer directement par dessiner une architecture. J’ai vu beaucoup de candidats faire ça. Ils sortent les boîtes trop vite. API, vector database, LLM, monitoring. Ça donne l’impression de maîtriser, mais souvent ils ratent le vrai test.

Le vrai sujet, c’est de comprendre le besoin, les contraintes et les risques avant de proposer une solution. Qui utilise le système ? Quel niveau d’erreur est acceptable ? Quelle donnée est critique ? Quel budget par utilisateur ? Quel temps de réponse ? Quelle traçabilité ?

J’ai vu le même phénomène côté data et analytics. Les profils solides ne sont pas ceux qui connaissent le plus d’outils. Ce sont ceux qui savent expliquer pourquoi chaque couche existe. Pourquoi on stocke ici. Pourquoi on filtre là. Pourquoi on met une validation avant la réponse finale. C’est ça qui rassure un recruteur.

Ancien entretien système	Entretien AI system design
Architecture web classique avec API, base de données, cache et files de messages.	Produit IA complet avec modèle, orchestration, retrieval, mémoire, garde-fous et monitoring.
Qualité mesurée avec disponibilité, scalabilité et cohérence des données.	Qualité mesurée avec pertinence, hallucinations, évaluation des réponses et feedback utilisateur.
Coût surtout lié à l’infrastructure serveur et au stockage.	Coût lié aux appels modèles, aux tokens, aux embeddings, au retrieval et aux retries.
Sécurité centrée sur authentification, permissions et chiffrement.	Sécurité centrée aussi sur prompt injection, fuite de données, abus du modèle et contrôle des sorties.
Évolution du système surtout technique, avec plus de trafic et plus de données.	Évolution du système aussi comportementale, avec modèles qui changent, prompts à versionner et évaluations continues.

Que cherchent vraiment les recruteurs ?

Les recruteurs cherchent surtout à voir comment je raisonne dans un système incertain, coûteux et imparfait. Pas si je connais tous les composants à la mode. Un entretien d’AI system design ne récompense pas une liste de briques jetées sur un schéma. Il récompense ma capacité à dire “je choisis ça, pour cette raison, avec ce risque, et voilà comment je le mesure”.

Le cœur du sujet, c’est l’arbitrage. Dans un vrai système IA, tout se contredit un peu. La latence, le coût, la qualité et la sécurité tirent rarement dans la même direction.

Critère	Arbitrage typique
Latence	Un retrieval plus profond peut réduire les hallucinations, mais ralentir la réponse.
Coût	Un modèle plus puissant améliore parfois la qualité, mais il coûte plus cher à chaque appel.
Qualité	Plus de contexte peut aider, mais trop de contexte peut aussi noyer le modèle.
Sécurité	Des garde-fous stricts protègent mieux, mais peuvent bloquer des demandes légitimes.

Ce que j’ai vu chez les bons candidats, c’est qu’ils ne cherchent pas à tout couvrir avec le même niveau de détail. Ils choisissent 3 à 5 zones clés et ils creusent vraiment. Par exemple la stratégie RAG, c’est-à-dire comment on récupère des documents fiables pour aider le modèle à répondre. Ou le routage de modèles, quand on envoie les requêtes simples vers un petit modèle moins cher et les cas complexes vers un modèle plus robuste.

Je peux aussi creuser le caching, pour éviter de recalculer les mêmes réponses. Les garde-fous post-LLM, pour contrôler ce que le modèle a produit avant de l’envoyer à l’utilisateur. L’observabilité, pour suivre les erreurs, les coûts, les latences et les dérives. La gestion des permissions et la sécurité PII, les données personnelles identifiables, parce qu’un chatbot interne qui expose un salaire ou un dossier RH, c’est un incident, pas une feature.

Parler des échecs passés aide beaucoup. Les hallucinations, les prompt injections, la dérive d’embeddings, les pannes d’index vectoriel, les timeouts API… Tout ça montre que j’ai déjà vu la production, pas juste un notebook propre. Souvent, c’est là qu’un candidat se distingue.

• Clarifier le besoin avant de designer.
• Estimer les volumes, les coûts et la latence.
• Arbitrer au lieu d’empiler des outils.
• Expliquer les risques et les limites.
• Parler d’observabilité dès le départ.
• Prévoir l’évolution du système dans le temps.

Quel cadre utiliser en entretien ?

J’utilise un cadre en sept étapes, parce qu’il m’évite de partir dans tous les sens et il donne une réponse propre sans faire scolaire. En entretien, le but n’est pas de réciter une architecture parfaite. Le but, c’est de montrer que je sais garder le contrôle quand le problème est flou.

Je ne saute jamais la clarification initiale. C’est souvent là que le recruteur voit si je pense produit, data, sécurité et production. Un candidat qui part directement sur “On met un RAG avec un vector store” peut avoir l’air technique, mais il manque peut-être le vrai sujet : qui utilise le système, avec quelles données, quel niveau de risque, quel coût acceptable.

Mon ouverture ressemble souvent à ça : “Avant de proposer l’architecture, je clarifie le type d’utilisateur, les données disponibles, la tolérance à l’erreur factuelle et le budget de latence.” Ça pose le cadre. Ça calme aussi l’entretien.

• Clarifier les exigences : Sources de données, confidentialité, budget de latence, tolérance aux erreurs factuelles, échelle, fraîcheur des données, autorisations d’API.
• Estimer : Tokens par seconde, taille du contexte, volume d’embeddings, coût par appel, QPS de pointe. QPS veut dire requêtes par seconde.
• Esquisser l’architecture : Entrée utilisateur, filtrage sécurité et PII, orchestrateur, retrieval vectoriel, reranker, routage modèle, garde-fous post-LLM, streaming, observabilité. PII veut dire données personnelles identifiables.
• Approfondir un ou deux composants : Stratégie RAG, prompt design, caching ou model tiering. Le RAG consiste à récupérer des documents avant de générer une réponse.
• Énoncer les compromis : Latence vs qualité, RAG vs fine-tuning, plafonds de coût, modèles de secours.
• Prévoir les modes de défaillance : Hallucinations, prompt injection, pannes, dérive d’embeddings, isolation multi-tenant, détection.
• Préparer l’évolution : A/B testing de prompts, boucles de feedback, gates d’évaluation, migration progressive de modèles.

J’ai vu des candidats très bons se faire piéger juste parce qu’ils voulaient aller trop vite. Sur un système IA, la qualité de la question de départ compte presque autant que la réponse.

Étape	Ce qu’il faut dire	Ce que ça prouve
Clarifier	“Je vérifie les utilisateurs, données, risques, latence et sécurité.”	Vous pensez produit, data et production.
Estimer	“Je calcule tokens, contexte, coût, embeddings et QPS.”	Vous savez dimensionner.
Architecturer	“Je pose l’orchestrateur, le retrieval, les garde-fous et l’observabilité.”	Vous structurez un vrai système.
Approfondir	“Je détaille le RAG, le prompt, le cache ou le routage modèle.”	Vous avez de la profondeur technique.
Compromis	“Je compare qualité, coût, latence et robustesse.”	Vous savez arbitrer.
Défaillances	“Je prévois hallucinations, injections, pannes et dérives.”	Vous pensez sécurité et fiabilité.
Évolution	“Je mets feedback, évaluations, A/B tests et migrations progressives.”	Vous pensez amélioration continue.

Quelles briques IA faut-il maîtriser ?

Il faut maîtriser les primitives qui reviennent partout, surtout RAG, retrieval, reranking, caching, routage de modèles, garde-fous et observabilité. Ce ne sont pas des buzzwords. Ce sont des briques qui changent vraiment le comportement du système, son coût, sa vitesse, et sa fiabilité.

Le RAG, pour Retrieval Augmented Generation, c’est assez simple. Un encodeur transforme la question en vecteur, donc une représentation numérique du sens. Un récupérateur cherche les documents utiles. Puis un générateur, souvent un LLM, produit la réponse à partir de ce contexte. Le retrieval, c’est juste cette étape de recherche.

En production, le RAG demande plus qu’un appel API. Il faut du chunking, donc découper les documents en morceaux exploitables. Il faut un pipeline d’embeddings pour transformer ces morceaux en vecteurs. Il faut une recherche vectorielle, un cache pour éviter de refaire les mêmes appels, de la journalisation pour comprendre ce qui s’est passé, et des frontières d’accès pour éviter qu’un utilisateur voie des documents interdits. J’ai vu des systèmes RAG corrects en démo devenir dangereux en prod juste à cause de droits mal filtrés.

Le RAG réduit les hallucinations parce qu’il ancre la réponse dans des documents récupérés. Mais il ne supprime pas tous les risques. Si les documents sont mauvais, trop vieux, mal découpés, ou si le modèle ignore le contexte, il peut encore raconter n’importe quoi. Les réductions rapportées tournent parfois autour de 40 à 71 % selon les cas cités, mais je ne traiterais jamais ça comme une garantie universelle.

Le model routing, c’est l’autre brique à connaître. Toutes les requêtes ne doivent pas passer par le modèle le plus cher. Une demande simple peut aller vers un modèle moins coûteux. Une demande complexe, sensible, ou ambiguë peut être envoyée vers un modèle haut de gamme. Les modèles type GPT-4 peuvent tourner autour de 10 à 30 dollars par million de tokens en entrée et sortie, avec des latences autour de 3 à 5 secondes. À 10 000 conversations par jour, avec 5 000 tokens chacune, on peut dépasser environ 7 500 dollars par mois chez un fournisseur. Le routage peut économiser 40 à 70 % dans certains cas, selon les volumes, les modèles et l’usage réel.

Brique	Rôle	Risque	Question recruteur
RAG	Ancrer la réponse dans des documents	Mauvais contexte, droits mal filtrés	Comment vous évaluez la qualité du contexte récupéré ?
Reranker	Reclasser les documents les plus pertinents	Latence et coût en plus	Pourquoi ajouter un reranker après la recherche vectorielle ?
Cache	Réduire coût et latence	Réponses obsolètes	Qu’est-ce que vous mettez en cache, et combien de temps ?
Model routing	Envoyer chaque demande vers le bon modèle	Mauvais choix de modèle	Quels critères utilisez-vous pour router une requête ?
Garde-fous	Bloquer sorties dangereuses ou non conformes	Faux positifs, contournement	Où placez-vous les contrôles dans le pipeline ?
Observabilité	Suivre qualité, coût, erreurs et dérives	Trop peu de traces pour déboguer	Quels signaux surveillez-vous en production ?

Comment conclure une bonne réponse ?

Je conclus une réponse d’AI system design interview en montrant que le système peut vivre en production, pas seulement fonctionner sur un schéma. C’est souvent là que la différence se fait. Un prototype IA peut impressionner en 10 minutes. Un produit IA, lui, doit tenir quand les utilisateurs arrivent, quand les coûts montent, quand le modèle se trompe, quand un fournisseur tombe.

Je reviens toujours sur trois choses simples : les compromis, les risques, et l’évolution. Si j’ai choisi un modèle plus rapide mais moins précis, je le dis. Si j’ai mis du cache, je parle de fraîcheur des données. Si j’ai un RAG, donc une recherche dans des documents avant génération, je parle de qualité des embeddings, ces vecteurs qui représentent le sens des textes.

Je montre aussi que j’ai prévu les modes de défaillance. Pas avec une phrase vague du style “on monitorera”. Je rattache chaque risque à une limite concrète.

• Hallucinations : Évaluations régulières, réponses sourcées, seuil de confiance, fallback vers une réponse “je ne sais pas”.
• Prompt injection : Garde-fous, séparation des instructions système, filtrage des entrées, tests adversariaux.
• Panne d’un fournisseur : Modèle de secours, circuit breaker, file d’attente, mode dégradé.
• Dérive d’embeddings : Monitoring de qualité de recherche, jeux de tests fixes, réindexation contrôlée.
• Mauvaise isolation multi-tenant : Contrôles d’accès stricts, séparation logique par client, tests de permissions.
• Fuite de données sensibles : Masquage des PII, logs nettoyés, alertes, politiques de rétention.
• Erreurs de permission : Vérification côté serveur, audit logs, tests automatisés sur les rôles.

Je parle aussi des coûts et de la latence. Une IA qui répond bien mais coûte trop cher à chaque appel, ça ne passe pas longtemps. Je mets donc des limites de coût, du monitoring de latence, des alertes, et parfois un modèle plus petit pour les cas simples.

Pour l’évolution, je veux montrer que le système apprend sans devenir incontrôlable. A/B testing de prompts, donc comparaison entre deux versions. Boucle de feedback utilisateur. Gates d’évaluation avant changement de modèle, c’est-à-dire des tests obligatoires avant mise en production. Migration progressive vers un nouveau modèle, d’abord sur 5 %, puis 20 %, puis plus si les métriques tiennent. C’est là qu’on passe d’un prototype IA à un produit IA maîtrisé.

Mon conseil perso : Je préfère une réponse moins spectaculaire mais exploitable, plutôt qu’une architecture énorme impossible à maintenir. J’ai vu des candidats perdre le fil en empilant trop de briques. Les recruteurs sérieux le sentent très vite.

• J’ai clarifié le besoin.
• J’ai estimé le volume, la latence et les coûts.
• J’ai proposé l’architecture.
• J’ai creusé les briques critiques.
• J’ai posé les compromis.
• J’ai prévu les échecs.
• J’ai expliqué l’évolution.

Et si votre vraie réponse était votre façon de raisonner ?

Un AI system design interview ne se gagne pas en récitant des noms de briques IA. Je dois montrer que je sais clarifier, estimer, arbitrer et penser production. Le RAG, le routage de modèles, les garde-fous, le cache ou l’observabilité ne valent quelque chose que si je sais expliquer pourquoi je les mets là. Le point clé, c’est de parler des contraintes réelles : coût, latence, qualité, sécurité, échecs possibles et évolution du système. Si vous structurez votre réponse comme ça, vous donnez au recruteur ce qu’il cherche vraiment : une preuve de jugement technique, pas juste un schéma joli.

FAQ

• Qu’est-ce qu’un AI system design interview ?
  C’est un entretien où on vous demande de concevoir un système IA complet, par exemple un chatbot, un système RAG, un agent de code ou un assistant vocal. Le recruteur regarde surtout votre capacité à raisonner sur un système probabiliste avec des contraintes de coût, de latence, de qualité et de sécurité.
• Quelle est l’erreur la plus fréquente dans ce type d’entretien ?
  L’erreur classique, c’est de commencer directement par l’architecture. Il faut d’abord clarifier les exigences : données disponibles, confidentialité, budget de latence, tolérance aux erreurs, échelle, fraîcheur des données et permissions d’API. Sans ça, la solution flotte un peu dans le vide.
• Pourquoi le RAG revient souvent dans les questions IA ?
  Le RAG revient souvent parce qu’il permet de connecter un modèle à des documents ou connaissances externes. Il combine un encodeur de requête, un récupérateur et un générateur. En production, il faut aussi penser au chunking, aux embeddings, à la recherche vectorielle, au cache, aux logs et aux droits d’accès.
• Comment parler du coût dans un AI system design interview ?
  Il faut estimer les tokens, le coût par appel, le QPS de pointe et les volumes. Le routage de modèles est une réponse utile : envoyer les requêtes simples vers des modèles moins chers et garder les modèles haut de gamme pour les cas difficiles. Ça montre que vous pensez business et production.
• Comment se démarquer face aux autres candidats ?
  Le plus efficace, c’est d’expliquer les compromis et les échecs possibles. Parlez d’hallucinations, de prompt injection, de pannes, de dérive d’embeddings, d’isolation multi-tenant et d’observabilité. Un candidat solide ne vend pas un système parfait, il montre comment il le surveille et le fait évoluer.

 

 

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 data, IA et automatisation très concrets, 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, vos workflows data ou vos usages d’automatisation, contactez-moi.