Comment réussir un AI system design interview senior ?

Il faut montrer que vous savez construire un produit IA fiable, pas réciter une architecture LLM. Je détaille ici le raisonnement attendu, les questions à clarifier, les briques comme le RAG, le routage de modèles, puis les compromis coût, latence, qualité et sécurité.

Que cherche le recruteur ?

Le recruteur cherche une chose simple : voir si je sais concevoir, défendre et faire tenir en production une architecture IA complète autour d’un LLM. Un LLM, c’est un grand modèle de langage, le moteur derrière des outils comme ChatGPT. Et aujourd’hui, ça ne suffit plus de dessiner trois services, une base de données, un cache et une file de messages.

Les questions ont changé parce que les postes IA ont explosé. Avant, on me demandait souvent de concevoir une plateforme vidéo, une messagerie, un feed social, un moteur de recherche. Maintenant, on peut me demander de concevoir un assistant type ChatGPT, un assistant juridique, un agent de revue de code, ou un outil interne qui interroge toute la documentation de l’entreprise.

Le piège, c’est de croire que l’entretien teste ma connaissance des détails internes du modèle. Ce n’est pas le sujet. Je n’ai pas besoin d’expliquer comment chaque couche du transformer fonctionne mathématiquement. Ce que le recruteur veut voir, c’est ma capacité à raisonner sur un système probabiliste, donc un système qui peut répondre différemment selon le contexte, les données, le prompt, le modèle, la température, ou même le provider utilisé.

Et là, les vraies contraintes arrivent très vite :

• La latence : Est-ce que l’utilisateur accepte d’attendre 2 secondes, 10 secondes, ou plus ?
• Le coût : Chaque appel au modèle coûte de l’argent, surtout avec beaucoup de tokens.
• La qualité : Est-ce que la réponse est utile, précise, vérifiable ?
• La sécurité : Est-ce qu’un utilisateur peut extraire des données qu’il ne devrait pas voir ?
• Les hallucinations : Est-ce que le modèle invente une réponse avec aplomb ?
• La panne de provider : Est-ce que tout tombe si OpenAI, Anthropic ou un autre service est indisponible ?
• La fraîcheur des données : Est-ce que le système répond avec les bonnes informations, à jour ?
• Les droits d’accès : Est-ce que le commercial voit les mêmes documents que le juridique ?

J’ai vu des profils très solides techniquement se faire piéger là-dessus. Ils partaient trop vite sur une solution. Ils dessinaient un schéma avant d’avoir compris ce que le système devait réussir. Et c’est exactement ce que l’entretien teste.

Un junior décrit les composants. Un senior explique pourquoi chaque couche existe, ce qu’elle protège, ce qu’elle coûte, et comment elle casse en production.

Avant de proposer une architecture, il faut donc clarifier le problème. Sinon, on optimise dans le vide.

Quelles exigences clarifier ?

Les exigences à clarifier sont les données, la confidentialité, la latence, la tolérance aux erreurs, l’échelle, la fraîcheur de l’information, les coûts et le choix entre API tierce ou modèle auto-hébergé.

C’est souvent la partie la plus importante de l’entretien. Pas la plus spectaculaire, clairement. Mais celle qui montre si vous savez concevoir un vrai produit, avec des contraintes réelles, ou juste dessiner une belle architecture au tableau blanc.

Je pose toujours les questions tôt, avant de parler modèle, vector database ou agents. Quelles sources de données le système utilise ? Des documents internes, des tickets support, une base SQL, des pages web, des fichiers PDF ? Est-ce qu’il y a des données sensibles, de la PII, donc des informations personnelles identifiables comme un email, un numéro client ou une adresse ? Qui peut accéder à quoi ? Un commercial peut-il voir les contrats enterprise ? Un support externe peut-il lire des données client ?

Il faut aussi cadrer le comportement attendu. Quelle latence est acceptable ? Une réponse en 500 ms, 3 secondes, 20 secondes ? Est-ce que la réponse doit streamer, c’est-à-dire s’afficher progressivement comme dans ChatGPT ? Quel niveau d’erreur factuelle est toléré ? Sur un moteur de recommandation interne, une petite approximation peut passer. Sur du médical ou du juridique, c’est une autre histoire.

Ensuite, je fais estimer les ordres de grandeur, sans inventer des chiffres si l’interviewer ne les donne pas. Combien d’utilisateurs ? Quel pic de QPS, donc de requêtes par seconde ? Quelle taille de fenêtre contextuelle faut-il, autrement dit combien de tokens le modèle doit lire à chaque appel ? Quel volume d’embeddings doit-on stocker ? Quel coût par appel ? Combien de tokens générés par seconde sont nécessaires pour garder une bonne expérience utilisateur ?

Élément	Question à poser	Risque si on oublie
Données	Quelles sources sont utilisées ?	Construire un système incompatible avec la réalité métier.
PII	Y a-t-il des données personnelles ou sensibles ?	Créer un risque légal ou sécurité.
Latence	Quel temps de réponse est acceptable ?	Choisir une architecture trop lente.
Coût	Quel budget par appel ou par mois ?	Proposer une solution impossible à opérer.
Échelle	Combien d’utilisateurs et quel QPS de pointe ?	Sous-dimensionner le système.
Fraîcheur	Les documents doivent-ils être à jour en temps réel ?	Répondre avec des informations périmées.
Tolérance aux hallucinations	Quel niveau d’erreur factuelle est acceptable ?	Livrer une IA dangereuse ou inutilisable.

Je clarifie aussi si on peut appeler des APIs externes, ou si certains composants doivent être hébergés nous-mêmes pour des raisons de sécurité, de coût ou de souveraineté. Une fois ces contraintes posées, l’architecture devient beaucoup plus facile à défendre.

Quelle architecture proposer ?

Une bonne architecture IA comprend une couche d’entrée, un filtre sécurité et PII, un orchestrateur, une couche de retrieval, un modèle routé selon la difficulté, des garde-fous post-LLM, du streaming et de l’observabilité. Si vous posez ça clairement en entretien, vous montrez tout de suite que vous pensez produit, sécurité, coût et qualité, pas juste “appel API vers un LLM”.

Je la dessine souvent comme un flux assez simple. L’utilisateur envoie une demande. La couche d’entrée vérifie le format, l’authentification, le tenant, la langue, le contexte de session, parfois aussi les quotas. Elle évite déjà pas mal de bruit. Ensuite, la requête passe dans un filtre sécurité et PII. PII veut dire données personnelles identifiables, comme un email, un numéro client, une adresse, un IBAN. Cette couche limite les prompt injections, les demandes abusives, les données sensibles envoyées par erreur.

L’orchestrateur arrive juste après. C’est le cerveau opérationnel du système. Il décide quoi faire avec la demande. Il peut appeler un retrieveur, choisir un modèle, enrichir le prompt, activer un cache, envoyer vers un outil externe, ou demander une clarification si la requête est floue. Dans un entretien senior, c’est un point important. Vous ne voulez pas une architecture figée, vous voulez une architecture qui prend des décisions.

La couche retrieval est critique dès que l’assistant répond sur des connaissances métier. Elle va chercher les bons passages dans une base vectorielle, souvent avec de la recherche sémantique, donc une recherche par sens plutôt que par mots exacts. Sur des cas exigeants, j’ajoute un reranker. Il reprend les résultats candidats et les trie plus finement. Et surtout, je contrôle les droits d’accès avant d’injecter quoi que ce soit dans le prompt. Un assistant RH qui montre un document confidentiel à la mauvaise personne, c’est fini.

• Les requêtes simples partent vers un modèle rapide et moins cher.
• Les cas ambigus ou critiques vont vers un modèle plus puissant.
• Les réponses longues peuvent être streamées pour réduire la latence perçue.

Après le LLM, je mets toujours une couche de contrôle. Vérification du format, citations si le produit l’exige, filtrage sécurité, détection de réponse non fiable, fallback, ou escalade humaine. Chez un client support, ce simple post-traitement a évité beaucoup de réponses “propres” mais fausses.

Et je termine par l’observabilité. Logs, traces, coût par requête, latence, taux d’erreur, qualité perçue, feedback utilisateur. Sans ça, on ne pilote pas un produit IA, on le subit.

Comment défendre le RAG ?

Le RAG se défend quand le système doit répondre avec des connaissances externes, fraîches, contrôlées, ou propres à l’entreprise, sans tout mettre dans le prompt ni fine-tuner à chaque changement documentaire. C’est souvent la réponse la plus saine en interview senior, parce qu’elle montre que je sépare deux sujets : ce que le modèle sait déjà, et ce que mon produit doit savoir maintenant.

RAG veut dire Retrieval-Augmented Generation. En clair, je récupère d’abord les bons documents ou passages, puis je demande au LLM de répondre à partir de ce contexte. Les briques sont simples. Un encodeur de requête transforme la question en représentation numérique, souvent un embedding. Un retrieveur cherche les passages les plus proches dans un index. Puis le générateur, donc le LLM, produit une réponse conditionnée par ce contexte récupéré.

En production, je ne dis pas juste “on met une base vectorielle”. Je parle de toute la chaîne. Je découpe les documents en chunks, c’est-à-dire en morceaux assez petits pour être retrouvés proprement, mais assez grands pour garder le sens. Je génère des embeddings, j’indexe dans une base vectorielle, je cherche les passages pertinents, et parfois je rerank, c’est-à-dire que je reclasse les résultats avec un modèle plus précis. J’applique aussi les droits d’accès. Ça, c’est non négociable. Un commercial ne doit pas récupérer un passage RH sensible juste parce que l’embedding est proche. Je mets du cache quand les requêtes reviennent souvent, je loggue les questions, les documents utilisés, les réponses, et j’évalue la qualité avec des jeux de tests.

Le RAG ne supprime pas toutes les hallucinations. Il les réduit souvent fortement, avec des ordres de grandeur qu’on voit autour de 40 à 71 pourcent selon les contextes, mais il peut rater. Si les chunks sont mauvais, si les embeddings dérivent, si le retrieval ramène les mauvais passages, ou si les permissions sont mal gérées, le système peut répondre avec assurance sur une mauvaise base. J’ai vu ça chez un client avec une documentation produit dupliquée partout. Le modèle ne mentait pas vraiment, il citait juste la mauvaise version.

Besoin	RAG	Fine-tuning
Connaissance fraîche	Très adapté, il suffit de réindexer les documents	Peu adapté si la connaissance change souvent
Style de réponse	Possible via prompt et exemples	Très utile pour stabiliser un ton ou un format
Coût de mise à jour	Plutôt faible, surtout avec une bonne pipeline documentaire	Plus lourd, il faut préparer des données et réentraîner
Traçabilité	Bonne, on peut citer les sources récupérées	Plus faible, la connaissance est dans les poids du modèle
Risque d’hallucination	Réduit, mais dépend beaucoup du retrieval	Peut rester élevé sur les faits non appris ou obsolètes

Je ne caricature pas le fine-tuning. Il peut être très bon pour le style, les formats, les comportements répétables. Mais pour injecter une base documentaire mouvante, je défends d’abord le RAG. Une fois la connaissance maîtrisée, il reste un problème très concret. Chaque appel modèle coûte du temps et de l’argent.

Comment gérer coût et risques ?

Je gère le coût et les risques avec du routage de modèles, du cache, des garde-fous, des fallbacks, de l’observabilité et des boucles d’évaluation avant la mise en production. C’est la réponse simple, et franchement c’est souvent celle qui fait la différence en entretien senior.

Le model routing, c’est le fait d’envoyer chaque requête vers le bon modèle, pas forcément vers le plus puissant. Toutes les demandes n’ont pas besoin d’un modèle frontier, c’est-à-dire un modèle très avancé, cher, plus lent, mais meilleur sur les cas complexes. Une question routinière peut passer sur un modèle moins cher et plus rapide. Une demande ambiguë, longue, sensible, juridique, médicale, ou avec beaucoup de contexte, peut partir vers un modèle plus robuste.

Je donne toujours des ordres de grandeur, parce que ça montre que je pense produit et budget. Un modèle de type GPT-4 peut coûter autour de 10 à 30 dollars par million de tokens entrée plus sortie, avec une latence autour de 3 à 5 secondes. Si votre agent traite 10 000 conversations par jour avec 5 000 tokens par conversation, vous pouvez dépasser environ 7 500 dollars par mois chez un seul fournisseur. Le routage peut souvent économiser 40 à 70 %, surtout quand 60 à 80 % des requêtes sont routinières. J’ai déjà vu des équipes diviser leur facture sans dégrader l’expérience, juste en arrêtant d’utiliser le “gros modèle” pour dire bonjour ou reformuler une FAQ.

• Cache exact : Je réutilise la réponse quand la question est identique.
• Cache sémantique : Je réutilise une réponse quand la question est proche en sens, même si les mots changent.
• Plafond de coût : Je limite le budget par utilisateur, client ou tenant, donc par espace client isolé.
• Fallback : Je bascule vers un autre modèle si le provider tombe.
• Dégradation contrôlée : Je coupe certaines fonctions coûteuses si le système est sous charge.

Risque	Détection
Hallucinations	Feedback utilisateur, tests offline, évaluation automatique des réponses.
Prompt injection	Logs, règles de sécurité, tests adversariaux avant déploiement.
Panne fournisseur	Taux de fallback, erreurs API, alertes de disponibilité.
Dérive des embeddings	Métriques de retrieval, baisse du taux de bonnes sources retrouvées.
Fuite entre tenants	Tests d’isolation, audits de logs, contrôles d’accès stricts.
Documents obsolètes	Date des sources, score de fraîcheur, signalement utilisateur.
Latence qui explose	P95, P99, temps par étape, taux de timeout.
Mauvaise attribution des sources	Évaluation citation par citation, comparaison réponse-document.

Le système doit évoluer sans tout casser. Je teste les prompts en A/B testing, je collecte le feedback, je bloque les mises en prod avec des gates d’évaluation, et je migre les modèles progressivement. C’est souvent ça qui sépare une réponse scolaire d’une vraie réponse de production.

Vous voyez maintenant ce qu’il faut vraiment défendre ?

Un AI system design interview ne se gagne pas avec un schéma joli. Il se gagne avec un raisonnement clair. Je commence par clarifier les exigences, j’estime les volumes et les coûts, je propose une architecture défendable, puis je creuse les briques qui comptent vraiment comme le RAG, le routage de modèles, les garde-fous et l’observabilité. Le recruteur veut voir comment vous pensez quand le système devient incertain, cher, lent ou risqué. Si vous structurez votre réponse comme ça, vous montrez que vous savez construire un produit IA réel. Et ça, c’est le vrai bénéfice pour vous.

FAQ

• Qu’est-ce qu’un AI system design interview ?
  C’est un entretien où vous devez concevoir l’architecture d’un produit IA, souvent autour d’un LLM. Le but n’est pas juste de nommer des composants. Il faut expliquer les choix, les contraintes, les risques et les compromis entre coût, latence, qualité et sécurité.
• Quelle est l’erreur la plus fréquente dans ce type d’entretien ?
  L’erreur classique, c’est de proposer une solution trop vite. Il faut d’abord clarifier les données, la confidentialité, la latence, l’échelle, la tolérance aux erreurs factuelles et les contraintes de coût. Sinon, l’architecture n’a pas de base solide.
• Pourquoi le RAG revient aussi souvent dans les entretiens IA ?
  Le RAG permet à un LLM de répondre avec un contexte récupéré dans des documents ou bases métier. C’est utile quand les réponses doivent être fraîches, traçables et liées à des connaissances internes. Il réduit les hallucinations, mais il demande un vrai travail sur le chunking, les embeddings, le retrieval, le reranking et les droits d’accès.
• Comment parler du coût des LLM en entretien ?
  Il faut raisonner en tokens, volume d’usage, coût par appel et QPS de pointe. Un modèle puissant peut coûter cher si toutes les requêtes passent par lui. Le routage de modèles, le cache et les plafonds de coût permettent de garder un système plus prévisible.
• Quels risques faut-il absolument citer ?
  Les hallucinations, la prompt injection, les pannes fournisseur, la dérive des embeddings, les problèmes multi-tenant, les documents obsolètes et les fuites de données. Le point important, c’est d’expliquer comment vous les détectez avec logs, métriques, feedback, tests offline et évaluations avant mise en production.

 

 

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 sur des sujets data et IA très concrets, avec des clients comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Je dirige l’agence webAnalyste et l’organisme Formations Analytics. Si vous voulez structurer vos projets IA, vos architectures data ou vos automatisations business, contactez-moi.