Comment réussir un AI system design interview ?

En montrant que je sais concevoir un système IA fiable, pas juste appeler une API LLM. L’entretien teste surtout mes compromis entre latence, coût, qualité et sécurité. Je vais cadrer la méthode, l’architecture type, les primitives à connaître et les pièges à anticiper.

Que cherche vraiment le recruteur ?

Ce que le recruteur cherche vraiment, c’est assez simple : il veut voir si je sais architecturer un produit IA probabiliste sous contraintes, pas si je peux réciter comment fonctionne un LLM ou expliquer les transformers pendant 20 minutes.

Les entretiens ont changé. Avant, on tombait souvent sur des classiques comme “concevoir YouTube”, “concevoir Uber”, “concevoir un système de cache distribué” ou “designer un moteur de recherche”. Maintenant, on voit arriver des sujets comme “concevoir ChatGPT”, “concevoir un assistant juridique”, “concevoir un copilote interne pour les équipes support” ou “concevoir un chatbot métier branché sur la base documentaire de l’entreprise”.

Ce changement est logique. Les rôles liés à l’IA explosent. Les annonces d’AI Engineer ont augmenté de +143 % sur un an en 2025, et la part des jobs IA/ML serait passée de 10 % à 50 % dans certains périmètres de recrutement tech. Donc le recruteur ne veut plus juste savoir si je connais les bases du backend ou du machine learning. Il veut vérifier une compétence beaucoup plus concrète : est-ce que je sais intégrer des LLM dans un vrai produit utilisé par de vraies personnes.

Parce que beaucoup de candidats savent appeler une API. Franchement, ça ne suffit plus. Faire un appel à OpenAI, Anthropic ou Mistral, c’est rarement le problème. La vraie différence, c’est d’expliquer pourquoi chaque couche existe autour du modèle : orchestration, retrieval, sécurité, observabilité, coûts, fallback, routage de modèles.

Le retrieval, par exemple, c’est la couche qui permet d’aller chercher les bonnes informations dans vos documents avant de répondre. L’observabilité, c’est ce qui permet de comprendre ce qui se passe en production : latence, erreurs, hallucinations, coût par requête, taux de satisfaction. Le fallback, c’est le plan B quand le modèle répond mal, met trop de temps ou tombe en erreur.

En mission, je vois souvent des équipes qui démarrent par le modèle. Elles comparent GPT-4, Claude, Mistral, Llama, puis elles pensent avoir presque fini. Mais le vrai sujet est souvent ailleurs. Le LLM n’est qu’un composant. Ce n’est pas le produit complet. Le produit, c’est tout ce qu’on construit autour pour rendre la réponse utile, fiable, sécurisée et mesurable.

Critère	System design classique	AI system design interview
Objectif	Construire un système scalable et fiable.	Construire un produit IA utile malgré l’incertitude des réponses.
Incertitude	Faible, le comportement est plutôt déterministe.	Forte, le modèle peut se tromper, halluciner ou varier.
Métriques	Latence, disponibilité, débit, stockage.	Qualité de réponse, coût, latence, taux d’erreur, satisfaction utilisateur.
Risques	Panne, surcharge, perte de données.	Hallucination, fuite de données, biais, coût incontrôlé, mauvaise décision.
Composants clés	API, base de données, cache, queue, load balancer.	LLM, retrieval, prompts, guardrails, monitoring, fallback, routage de modèles.

Quelles questions poser au début ?

Je commence toujours par clarifier les contraintes métier, les données, la qualité attendue et les limites de sécurité avant de dessiner quoi que ce soit. C’est tentant de partir direct sur une architecture RAG, c’est-à-dire un système qui va chercher des documents avant de répondre, ou sur un agent autonome. Mais en entretien, ça donne souvent l’impression qu’on plaque une solution à la mode sans comprendre le problème.

Un bon candidat demande d’abord ce que le système doit vraiment faire. Qui l’utilise ? Sur quelles données ? Avec quel niveau de risque ? J’ai déjà vu des équipes construire un chatbot interne très propre techniquement, puis découvrir trop tard que certaines données RH ne devaient jamais sortir vers une API externe. Là, l’architecture change complètement.

Les premières questions doivent couvrir quatre blocs simples : le métier, les données, la performance et la sécurité. Je veux savoir quelles sources sont utilisées, quelle fraîcheur est nécessaire, quelle latence est acceptable, quelle tolérance aux erreurs factuelles existe, et si on peut utiliser une API tierce ou si le modèle doit être auto-hébergé. Auto-héberger veut dire faire tourner le modèle sur notre propre infra, souvent pour des raisons de confidentialité, coût ou contrôle.

Ensuite, je produis quelques estimations. Pas besoin d’être parfait, mais il faut montrer que je sais dimensionner.

Métrique	Pourquoi je l’estime
Tokens par seconde	Pour estimer la vitesse de génération.
Taille moyenne du contexte	Pour contrôler coût, latence et qualité.
Volume d’embeddings	Pour dimensionner la base vectorielle.
Coût par appel	Pour éviter une architecture impossible à financer.
QPS de pointe	Pour gérer le trafic maximal, QPS veut dire requêtes par seconde.
Conversations par jour	Pour estimer le coût mensuel et la charge globale.

Les ordres de grandeur comptent. Des modèles GPT-4-tier peuvent coûter environ 10 à 30 dollars par million de tokens entrée plus sortie. Un agent avec 10 000 conversations par jour à 5 000 tokens peut dépasser 7 500 dollars par mois chez un seul fournisseur. Donc oui, ces chiffres changent l’architecture.

Si le coût explose, je dois parler cache, routage vers des modèles moins chers, réduction du contexte ou réponses pré-calculées. Si la latence est critique, je dois parler streaming, pré-calcul et retrieval optimisé, c’est-à-dire une recherche documentaire plus rapide et plus précise.

• Quel problème métier doit-on résoudre exactement ?
• Qui sont les utilisateurs et dans quel contexte utilisent-ils le système ?
• Quelles sources de données peut-on utiliser ?
• Les données contiennent-elles des informations sensibles ou personnelles ?
• Quelles règles de confidentialité s’appliquent ?
• Quelle fraîcheur des données est nécessaire ?
• Quelle latence maximale est acceptable pour l’utilisateur ?
• Quelle tolérance aux erreurs factuelles avons-nous ?
• Quelle échelle doit-on viser au lancement et à terme ?
• Combien de conversations par jour faut-il prévoir ?
• Quel est le QPS de pointe attendu ?
• Peut-on utiliser une API tierce ou faut-il auto-héberger le modèle ?
• Quel budget mensuel est acceptable pour l’inférence ?

Quelle architecture IA proposer ?

Je propose une architecture IA défendable en couches. Pas une recette magique. Une base solide que j’adapte au contexte, aux données, aux droits d’accès, au niveau de risque et à la latence attendue.

Pour un assistant IA ou un copilote métier, je pars souvent sur ce flux : entrée utilisateur, authentification, détection des données sensibles, orchestration, retrieval, modèle, garde-fous, streaming et observabilité. Ça montre que je ne pense pas juste “appel API vers un LLM”, mais système complet.

Le RAG, Retrieval Augmented Generation, reste souvent le bon point de départ. En simple : on découpe les documents en chunks, donc en petits passages exploitables, on crée des embeddings, c’est-à-dire des représentations numériques du sens, puis on récupère les passages pertinents et on les injecte dans le contexte du modèle pour générer une réponse appuyée sur des sources. Les trois briques clés sont l’encodeur de requête, le retriever et le générateur.

En production, je défends quelques choix très concrets :

• Un chunking propre, parce que des morceaux trop gros ou trop petits dégradent vite les réponses.
• Des embeddings adaptés au domaine, pas choisis au hasard.
• Une récupération vectorielle, souvent combinée avec BM25, une recherche lexicale classique très efficace sur les mots exacts.
• Un reranker, qui reclasse les résultats récupérés avant de les envoyer au modèle.
• Un cache exact ou sémantique, pour réduire les coûts et la latence.
• Du logging d’évaluation, pour mesurer la qualité réelle et pas juste “ça a l’air bon”.
• Un contrôle d’accès strict, parce que le retrieval ne doit jamais retourner un document que l’utilisateur n’a pas le droit de voir.

Le RAG peut réduire les hallucinations d’environ 40 à 71 %. Je le dis clairement en entretien : ça ne supprime pas le problème. Ça le réduit si le pipeline est bien conçu, avec de bonnes sources, un bon ranking, un prompt cadré et des garde-fous après génération.

Couche	Rôle	Risque couvert	Ce que je dis en entretien
Entrée utilisateur	Capturer la demande	Requête ambiguë ou malveillante	Je normalise et je qualifie l’intention avant d’appeler le modèle.
Authentification	Identifier l’utilisateur	Accès non autorisé	Je lie chaque requête à une identité et à des permissions.
Sécurité et PII	Détecter les données sensibles	Fuite de données personnelles	Je filtre ou masque avant traitement si nécessaire.
Orchestrateur	Router les étapes	Pipeline rigide	Je garde la logique métier hors du prompt autant que possible.
Retrieval et base vectorielle	Retrouver les sources utiles	Réponses inventées	Je combine dense, BM25 et contrôle d’accès au niveau document.
Reranker	Reclasser les passages	Contexte bruité	Je préfère envoyer moins de contexte, mais plus pertinent.
Modèle et prompt	Générer la réponse	Hallucination ou mauvais ton	Je choisis le modèle selon coût, latence, qualité et criticité.
Post-processing et garde-fous	Vérifier la sortie	Réponse dangereuse ou non conforme	Je valide citations, format, règles métier et sécurité.
Streaming et observabilité	Servir et mesurer	Mauvaise expérience ou bugs invisibles	Je trace latence, coût, feedback, erreurs et qualité des réponses.

Quels compromis défendre en entretien ?

Je dois surtout montrer que je sais arbitrer. Entre latence, coût, qualité et sécurité. Parce qu’un système IA parfait n’existe pas, et en entretien, le piège c’est de vendre une architecture magique qui répond vite, pas cher, avec une qualité maximale et zéro risque.

Les meilleurs candidats ne font pas ça. Ils expliquent les compromis. Une meilleure qualité peut coûter plus cher et augmenter la latence. Un modèle plus rapide peut répondre moins précisément. Un RAG, c’est-à-dire un système qui va chercher des documents avant de répondre, peut améliorer le rappel si on élargit la recherche, mais il peut aussi ajouter du bruit et dégrader la réponse.

Les grands arbitrages à connaître sont assez simples à défendre à l’oral :

• Latence contre qualité : Je peux utiliser un gros modèle pour mieux raisonner, mais la réponse sera plus lente.
• RAG contre fine-tuning : Je choisis le RAG si la connaissance change souvent, et le fine-tuning si je veux apprendre un style, un format ou un comportement stable.
• Modèle cher contre modèle léger : Je garde le modèle puissant pour les cas complexes, pas pour toutes les requêtes.
• Contexte long contre coût : Plus j’envoie de texte au modèle, plus je paie, et plus je risque de diluer l’information utile.
• Cache contre fraîcheur : Le cache accélère et baisse les coûts, mais il peut servir une réponse dépassée.
• Sécurité stricte contre expérience fluide : Plus je filtre, plus je protège, mais je peux aussi bloquer des demandes légitimes.

Le sujet que je défends presque toujours, c’est le model routing. L’idée est simple : Je route les requêtes simples vers des modèles moins coûteux, et je garde les modèles plus puissants pour les questions complexes. Dans beaucoup de produits, 60 à 80 % des requêtes sont routinières. Avec un bon routage, on peut économiser 40 à 70 % du coût modèle sans trop perdre en qualité.

À l’oral, je le présente comme ça. Je définis d’abord des classes de requêtes. Question simple, recherche documentaire, raisonnement complexe, action sensible. Je choisis ensuite un modèle par classe. Puis je garde un fallback si le modèle léger échoue, si le score de confiance est faible, ou si la réponse touche un sujet critique.

Chez certains clients, j’ai vu le premier prototype marcher très bien, puis devenir trop cher dès qu’on passait à l’échelle. C’est là que le routage, le cache et les plafonds de coût deviennent des sujets de design, pas une optimisation qu’on colle à la fin.

Compromis	Choix possible	Bénéfice	Risque	Phrase à dire
Latence contre qualité	Modèle rapide par défaut	Réponses plus rapides	Moins bon raisonnement	Je privilégie la vitesse sauf sur les demandes complexes.
RAG contre fine-tuning	RAG pour données changeantes	Information plus fraîche	Bruit documentaire	Je choisis le RAG si la connaissance évolue souvent.
Modèle cher contre léger	Routage par complexité	Coût réduit	Erreur de classification	Je garde le gros modèle pour les cas qui le justifient.
Contexte long contre coût	Contexte filtré	Moins de tokens	Perte d’information	Je n’envoie au modèle que ce qui est utile.
Cache contre fraîcheur	Cache avec expiration	Moins cher et plus rapide	Réponse obsolète	Je cache ce qui est stable, pas ce qui change vite.
Sécurité contre fluidité	Contrôles selon le risque	Meilleure protection	Friction utilisateur	Je renforce les contrôles sur les actions sensibles.

Comment gérer les pannes et l’évolution ?

Pour moi, la bonne réponse tient en une phrase simple : j’anticipe les modes de défaillance, je les mesure, puis je fais évoluer le système avec des tests contrôlés. C’est souvent là que l’entretien devient vraiment senior. Le recruteur va creuser 3 à 5 axes pour voir si j’ai déjà pensé aux problèmes réels, pas juste au schéma propre sur un tableau blanc.

Les pannes IA ne ressemblent pas toujours à une API qui tombe. Parfois, le système répond vite, mais il répond faux. Parfois, il fuit une donnée client. Parfois, il coûte 10 fois plus cher parce qu’un prompt est trop long ou qu’un retrieval ramène trop de documents.

Mode de défaillance	Détection
Hallucinations, c’est-à-dire réponses inventées mais crédibles.	Évaluations humaines, tests automatisés, score de factualité, comparaison avec sources attendues.
Prompt injection, quand un utilisateur tente de contourner les consignes du système.	Logs de prompts et réponses, taux de refus, tests d’attaque, alertes sur comportements anormaux.
Panne fournisseur ou modèle indisponible.	Taux de fallback, erreurs API, latence, monitoring par fournisseur.
Dérive des embeddings, quand les vecteurs ne représentent plus bien les nouveaux usages.	Score de récupération, taux de clic sur sources, pertinence du retrieval, alertes sur dérive.
Fuite de données entre tenants, donc entre clients ou espaces isolés.	Tests d’isolation, logs d’accès, audits de permissions, requêtes de contrôle.
Latence ou coût qui explose.	Métriques de latence, coût par requête, taille des prompts, nombre d’appels modèle.

L’observabilité IA va plus loin que “est-ce que le service répond”. Je surveille la disponibilité et le temps de réponse, oui, mais aussi la qualité, la factualité, la sécurité, le taux d’hallucination, la pertinence du retrieval et le comportement par segment d’usage. Un client m’avait déjà montré un chatbot “stable” techniquement, sauf que les commerciaux recevaient de bonnes réponses et le support recevait n’importe quoi. Sans segmentation, on ne voyait rien.

Pour faire évoluer le système, je ne pousse pas un changement au feeling. Je fais des tests A/B de prompts, je garde une boucle de feedback utilisateur, je mets des gates d’évaluation avant release, puis je migre progressivement vers un nouveau modèle. Je compare l’ancien et le nouveau sur les mêmes jeux de tests, avec rollback possible si la qualité baisse ou si le coût explose.

La phrase clé à faire passer : Je ne déploie pas un prompt en production comme une note dans un coin. Je le versionne, je le teste, je le mesure.

• Au lancement : Je surveille latence, erreurs, coût par requête, taux de fallback, hallucinations, refus et incidents de sécurité.
• Après 30 jours : J’améliore les prompts, le retrieval, les règles de sécurité et les évaluations à partir des vrais usages.
• Pour le passage à l’échelle : Je prépare la migration graduelle de modèle, les quotas, le rollback, les alertes de dérive et les tests multi-tenants.

Vous êtes prêt à défendre votre architecture ?

Pour réussir un AI system design interview, je ne cherche pas à sortir l’architecture la plus brillante. Je montre que je sais poser les bonnes questions, estimer les volumes, construire une architecture IA cohérente, défendre mes compromis et anticiper les pannes. Le cœur du sujet, c’est ça : un LLM est probabiliste, coûteux, parfois lent, parfois faux. Mon rôle est de concevoir le système autour pour le rendre utile, mesurable et sûr. Si vous structurez votre réponse comme ça, vous donnez au recruteur ce qu’il attend vraiment : la preuve que vous pouvez construire un produit IA qui tient en production.

FAQ

• Qu’est-ce qu’un AI system design interview ?
  C’est un entretien où je dois concevoir un système IA complet, souvent autour d’un LLM. Le recruteur ne vérifie pas seulement si je sais utiliser une API. Il regarde si je sais gérer les données, le retrieval, les coûts, la latence, la sécurité, les erreurs et l’évolution du produit.
• Quelle est la meilleure structure pour répondre ?
  Je pars sur une structure simple : clarifier le besoin, estimer les volumes, dessiner l’architecture, approfondir un ou deux composants, expliquer les compromis, parler des pannes, puis montrer comment le système évolue. Cette trame évite de partir dans tous les sens.
• Pourquoi le RAG revient souvent dans ces entretiens ?
  Le RAG permet au modèle de répondre avec des informations récupérées dans des sources contrôlées. C’est utile pour réduire les hallucinations, gérer des connaissances métier et éviter de tout mettre dans le modèle. Le point important en entretien, c’est aussi de parler chunking, embeddings, contrôle d’accès, reranking et évaluation.
• Comment parler du coût des LLM en entretien ?
  Je donne des ordres de grandeur et je montre que j’y pense dès le design. Des modèles puissants peuvent coûter autour de 10 à 30 dollars par million de tokens entrée plus sortie. À gros volume, la facture monte vite. Je peux donc proposer du cache, du routage de modèles, des plafonds de coût et des fallbacks.
• Qu’est-ce qui différencie une réponse junior d’une réponse senior ?
  Une réponse junior décrit souvent un pipeline qui marche en théorie. Une réponse senior parle des compromis, des limites, des pannes fournisseur, des hallucinations, de la prompt injection, de l’isolation multi-tenant, des métriques et de la migration progressive des modèles. C’est plus réaliste, et ça rassure tout de suite.

 

 

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 et intégration de l’IA en entreprise. J’accompagne des équipes sur des sujets très concrets : architecture data, qualité de mesure, automatisation, agents IA, observabilité et passage à l’échelle. J’ai travaillé avec des références comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football et Texdecor. Je dirige l’agence webAnalyste et l’organisme Formations Analytics. Si vous voulez structurer vos projets IA ou former vos équipes, contactez-moi.