System design IA en entretien : structurer sa réponse en 6 étapes

Ce que l'exercice évalue réellement

Un exercice de system design IA commence presque toujours par une phrase trop courte : « concevez un assistant qui répond aux questions internes », « proposez un système de tri automatique des demandes ». L'imprécision est volontaire. Ce que l'on observe, ce n'est pas votre capacité à produire un schéma complet en quarante minutes, c'est votre manière d'avancer quand le problème n'est pas encore posé.

Trois qualités sont regardées en parallèle : la capacité à cadrer, la capacité à choisir en assumant un compromis, et la capacité à parler de ce qui casse. Un candidat qui dessine immédiatement une architecture complète perd la première ; un candidat qui empile les composants sans hiérarchie perd la deuxième ; un candidat qui décrit un système sans jamais évoquer ses modes d'échec perd la troisième.

Ce guide porte uniquement sur l'exercice de conception. La préparation d'ensemble d'un entretien AI Engineer, incluant les autres formats d'épreuves, est traitée séparément.

Cadrer avant de concevoir

Les premières minutes servent à transformer une demande en spécification. Le réflexe attendu est de poser des questions, à voix haute, en expliquant pourquoi chaque réponse changerait la conception. Une question dont la réponse ne change rien à l'architecture n'a pas d'intérêt en entretien.

Utilisateur et décision

Qui utilise le système, à quel moment de son travail, et quelle décision prend-il ensuite ? Un assistant consulté par un support client sous pression n'a pas les mêmes exigences qu'un outil d'analyse utilisé une fois par semaine. La fréquence d'usage, le niveau d'expertise de l'utilisateur et le coût d'une erreur pour lui déterminent l'essentiel des arbitrages ultérieurs.

Contraintes fonctionnelles et non fonctionnelles

• Fonctionnel : quelles questions sont dans le périmètre, lesquelles doivent être refusées, quel format de réponse est attendu.
• Volume : nombre d'utilisateurs, requêtes en pointe, taille et fréquence de mise à jour du corpus.
• Latence : réponse perçue comme immédiate, tolérance à quelques secondes, ou traitement asynchrone acceptable.
• Exactitude : coût d'une réponse fausse, obligation ou non de citer une source.
• Contraintes de déploiement : hébergement, région, données pouvant ou non sortir du système d'information.

Données disponibles et droits d'accès

La question des données précède celle du modèle. Où sont-elles, dans quels formats, qui a le droit de les lire, et ce droit varie-t-il selon l'utilisateur ? Un corpus documentaire d'entreprise est presque toujours hétérogène en permissions. Poser cette question tôt évite de concevoir un système qu'il faudra reprendre entièrement lors de la revue de sécurité.

Choisir une architecture et savoir la justifier

La progression attendue va du simple vers le complexe, chaque couche étant introduite par un besoin identifié dans le cadrage. Commencer par l'architecture la plus élaborée est une erreur de méthode, même si elle se révèle finalement nécessaire.

• Sans recherche : un appel de modèle avec des instructions et un contexte fourni par l'application suffit quand le périmètre est étroit et la connaissance stable.
• Recherche documentaire (RAG) : justifiée quand la réponse dépend d'un corpus volumineux, évolutif, ou dont la source doit être citée.
• Outils : dès que la réponse suppose une donnée transactionnelle, un calcul ou une action dans un système tiers, l'accès à des outils devient nécessaire.
• Orchestration multi-étapes ou agentique : à réserver aux tâches réellement décomposables, dont chaque étape est vérifiable, et en acceptant explicitement le coût de la latence et de la variabilité.

Chaque ajout doit être formulé comme une conséquence, pas comme une préférence : « comme le corpus change chaque semaine et que la citation de la source est obligatoire, j'introduis une couche de recherche ». Le jury retient cette phrase davantage que le schéma.

Retrieval et gestion du contexte

Sur un système à base de recherche, la qualité perçue vient rarement du modèle. Elle vient de ce qui lui est donné à lire. Ce sont donc les décisions d'indexation et de sélection qu'il faut détailler.

• Découpage : unité de sens plutôt que taille fixe, avec conservation du titre, de la section et de la date d'origine.
• Métadonnées : source, périmètre, version, droits ; elles servent au filtrage autant qu'à la citation.
• Sélection : recherche lexicale et vectorielle combinées lorsque le vocabulaire métier est spécifique, réordonnancement quand la précision prime.
• Budget de contexte : nombre de passages retenus, gestion des documents contradictoires, comportement lorsque rien de pertinent n'est trouvé.
• Fraîcheur : réindexation à la mise à jour, suppression effective des documents retirés.

Le cas « aucun passage pertinent » mérite d'être traité explicitement. Un système qui répond quand même est un système qui invente.

Le rôle du modèle, sans comparatif

L'exercice ne demande pas d'élire un modèle. Il demande de dire quel rôle il joue et sous quelle contrainte on le choisit : taille de contexte utile, coût par requête au volume visé, latence acceptable, capacité à produire une sortie structurée, hébergement compatible avec les données traitées. Formuler ces critères, puis indiquer que le choix se tranche par un test sur le jeu d'évaluation, est une réponse plus solide qu'un nom de modèle.

Le point réellement discriminant est l'isolation : le système doit rester fonctionnel si le modèle est remplacé. Une interface d'appel unique, des instructions versionnées et une sortie validée par schéma rendent ce remplacement possible sans réécriture.

Évaluation et gestion des échecs

C'est la partie la plus souvent survolée, et celle qui distingue le plus nettement les niveaux. Concevoir sans dire comment on mesure revient à livrer une intuition.

• Un jeu d'évaluation construit à partir de cas réels, y compris des questions hors périmètre et des questions ambiguës.
• Sur la partie recherche : les bons passages sont-ils retrouvés, et à quel rang.
• Sur la réponse : exactitude, ancrage dans les sources fournies, respect du format attendu.
• Une évaluation humaine sur un échantillon, périodique, pour les critères que l'automatisation ne capture pas.
• Une mesure de la fréquence des refus et des réponses sans source, suivie dans le temps.

Côté échecs, décrivez les comportements attendus : indisponibilité du fournisseur, dépassement du délai, sortie non conforme au schéma, absence de source. Un repli explicite — réponse partielle, renvoi vers un humain, message d'indisponibilité — vaut mieux qu'une réponse produite à tout prix.

Latence, coût et observabilité comme contraintes de conception

Ces trois sujets ne sont pas des ajustements de fin de projet : ils déterminent l'architecture. Une exigence de réponse en moins de deux secondes interdit une orchestration en cinq appels séquentiels. Un volume élevé impose un cache, une réduction du contexte transmis ou un modèle plus petit sur les étapes intermédiaires.

• Latence : la décomposer par étape (recherche, génération, post-traitement) et dire laquelle domine.
• Coût : le raisonner par requête et au volume cible, en identifiant le levier principal plutôt qu'en promettant une optimisation générale.
• Observabilité : tracer chaque requête, les passages retenus, la version des instructions et du modèle, la latence par étape et le résultat des validations.
• Dérive : surveiller l'évolution du comportement après une mise à jour du corpus ou du modèle fournisseur.

Sécurité et permissions

Un système de réponse sur corpus interne est un système d'accès à l'information. Les permissions doivent être appliquées au moment de la recherche, en filtrant sur l'identité de l'utilisateur, et non après génération : un passage confidentiel qui entre dans le contexte a déjà fuité, même si la réponse finale semble anodine.

• Filtrage des documents par droits de l'utilisateur au niveau de l'index.
• Traitement des instructions injectées dans les documents récupérés comme des données, jamais comme des consignes.
• Cloisonnement des outils : périmètre minimal, actions sensibles soumises à confirmation humaine.
• Journalisation des accès, gestion des données personnelles et durée de rétention des traces.

Cas concret : assistant de réponse aux questions internes

Énoncé volontairement vague : « une équipe support passe trop de temps à chercher des informations dans la documentation interne, concevez un assistant ». Voici comment dérouler.

1. 1

   Cadrer

   5 min

   Support de niveau 1, pendant l'appel client, réponse attendue en quelques secondes, source obligatoire pour que l'agent puisse vérifier. Corpus : documentation produit et procédures, mis à jour chaque semaine, avec des sections réservées à certaines équipes.

2. 2

   Poser la version simple

   5 min

   Recherche sur le corpus filtré par droits, génération d'une réponse courte avec citation, refus explicite si aucun passage pertinent. Pas d'agent, pas d'outil : la tâche est une question-réponse ancrée.

3. 3

   Détailler la chaîne de recherche

   10 min

   Découpage par section avec titre conservé, métadonnées de périmètre et de version, recherche hybride pour absorber le vocabulaire produit, réordonnancement pour ne transmettre que quelques passages.

4. 4

   Définir l'évaluation

   8 min

   Cent questions réelles issues des tickets, dont dix hors périmètre. Mesure du rappel des passages, de l'exactitude et du taux de réponses sans source. Revue humaine mensuelle sur un échantillon.

5. 5

   Traiter les contraintes

   7 min

   Latence dominée par la génération : réponse en flux, cache sur les questions fréquentes. Sécurité : filtrage par droits à l'index. Observabilité : trace complète par requête, alerte sur le taux de refus.

6. 6

   Assumer les limites

   5 min

   Pas de réponse sur les cas contractuels particuliers, renvoi vers le niveau 2. Extension possible vers la consultation du dossier client, mais elle suppose des outils et une revue de sécurité distincte.

Assumer les arbitrages et les limites

Terminez en énonçant ce que le système ne fait pas, ce que vous avez sacrifié et pourquoi, et ce que vous mesureriez en premier après la mise en production. Cette dernière minute est souvent celle qui décide de l'évaluation : elle montre que vous concevez pour un contexte réel, pas pour un schéma.

La même exigence de justification s'applique lorsque vous racontez un projet déjà réalisé : le raisonnement compte davantage que la stack. C'est un exercice différent, mais évalué avec le même regard.

• AI Engineering
• Évaluation
• Cloud & production