RAG : est-ce encore une compétence différenciante pour un profil IA ?

Un rappel court, parce que ce n'est pas le sujet

Un système RAG (retrieval-augmented generation) va chercher, au moment de la question, des extraits de documents jugés pertinents, puis les fournit à un modèle de langage qui rédige une réponse à partir de ces extraits. Le schéma courant tient en une ligne : documents → embeddings → base vectorielle → retrieval → LLM. Ce schéma est juste, il est utile pour se repérer, et il est aujourd'hui connu de presque tous les candidats qui postulent sur un poste GenAI.

C'est précisément pour cette raison qu'il ne démontre plus rien. Savoir dessiner cette chaîne indique que vous avez lu la documentation ou suivi un tutoriel. La question professionnelle est ailleurs : que faites-vous quand la chaîne est en place et que les réponses restent mauvaises ? Cet article décrit ce qui distingue réellement quelqu'un capable de travailler sur un système RAG, et comment situer honnêtement son propre niveau.

Pourquoi le schéma d'architecture ne prouve pas une compétence

Assembler un RAG fonctionnel sur un corpus propre est devenu une opération courte. Les bibliothèques masquent l'essentiel des difficultés, les valeurs par défaut fonctionnent, et une démonstration convaincante peut être produite en quelques heures. Ce que la démonstration ne dit pas, c'est comment le système se comporte sur des documents réels : formats hétérogènes, versions multiples du même document, tableaux, scans, vocabulaire propre au métier, droits d'accès différents selon les utilisateurs.

La compétence recherchée n'est donc pas la connaissance des composants, mais la capacité à diagnostiquer. Quand une réponse est fausse, sait-on dire si le problème vient de l'ingestion, du découpage, du retrieval, du contexte transmis, ou du modèle ? Cette question, posée telle quelle en entretien, sépare très vite les profils.

Aucune des pratiques décrites ici n'est obligatoire dans l'absolu. Un corpus de quelques centaines de pages homogènes ne demande pas le même dispositif qu'une base documentaire d'entreprise multilingue avec des permissions fines. La compétence consiste aussi à savoir ce qu'on peut ne pas faire.

Ce qui se joue avant le modèle : données, découpage, métadonnées

La qualité des données décide du plafond

Un système de recherche ne peut pas restituer une information qui a été perdue à l'ingestion. Un PDF dont les tableaux ont été aplatis en texte continu, un document dont l'en-tête contextuel disparaît, deux versions contradictoires d'une même procédure indexées sans distinction : ces défauts ne se rattrapent en aval ni par un meilleur modèle, ni par un meilleur prompt. Une partie importante du travail réel sur un RAG consiste à regarder les documents un par un, ce qui est rarement montré dans les démonstrations.

Le découpage n'est pas un paramètre par défaut

Le chunking détermine ce qui pourra être retrouvé. Un découpage à taille fixe coupe au milieu des raisonnements et sépare une définition de son exemple ; un découpage guidé par la structure du document (titres, sections, articles, questions) conserve des unités qui ont un sens pour un lecteur. Le recouvrement entre segments, la reprise du titre de section dans chaque segment, le traitement particulier des tableaux ou des listes : ce sont des décisions, pas des réglages à copier.

Les métadonnées sont ce qui rend un corpus exploitable

Source, date, version, entité émettrice, langue, périmètre applicable, niveau de confidentialité. Sans elles, on ne peut ni filtrer, ni citer proprement, ni gérer la fraîcheur, ni appliquer des droits. Les métadonnées sont souvent ce qui manque le plus dans les projets repris après une phase de prototype, et les ajouter après coup implique de réindexer.

La stratégie de retrieval : le vrai terrain de compétence

La recherche vectorielle seule rapproche des textes qui parlent de la même chose. C'est utile lorsque la question est formulée autrement que le document, et insuffisant dès que la requête contient un identifiant, une référence de produit, un code d'erreur, un nom propre rare ou un sigle interne. La recherche lexicale, elle, retrouve exactement ces éléments et échoue sur les reformulations.

• Recherche lexicale : robuste sur les termes exacts, les références, les acronymes ; aveugle aux synonymes.
• Recherche sémantique : robuste aux reformulations ; peut rapprocher des documents thématiquement proches mais factuellement inadaptés.
• Recherche hybride : combine les deux et couvre une partie des angles morts, au prix d'une fusion de scores à régler et à évaluer.
• Filtres sur métadonnées : réduisent l'espace de recherche à ce qui est applicable (périmètre, date, entité) avant tout calcul de similarité.
• Reranking : réordonne un ensemble de candidats plus large avec un modèle plus coûteux mais plus fin, ce qui améliore souvent davantage la qualité perçue qu'un changement de modèle génératif.

Savoir énumérer ces options ne suffit pas non plus. Ce qui compte, c'est de pouvoir dire pourquoi telle combinaison a été retenue sur tel corpus, ce qu'elle a amélioré, et ce qu'elle a coûté en latence.

Ce que le modèle reçoit : contexte, citations, droits, fraîcheur

Le passage du retrieval au modèle est un endroit où beaucoup de qualité se perd. Combien de passages transmettre, dans quel ordre, avec quel niveau de troncature, faut-il inclure le titre de la section et la date du document, que fait le système lorsqu'aucun passage n'atteint un seuil de pertinence ? Un système qui préfère répondre « je n'ai pas trouvé d'élément suffisant » est souvent plus exploitable qu'un système qui répond toujours.

• Citations : rattacher chaque affirmation à un passage identifiable, avec sa source et sa version, sans quoi la réponse n'est pas vérifiable par l'utilisateur.
• Permissions : filtrer selon les droits réels de la personne qui interroge, au moment de la recherche et non après génération. Un système qui filtre la réponse mais laisse fuiter le titre d'un document confidentiel a déjà un problème.
• Fraîcheur : définir la fréquence de réindexation, le traitement des documents obsolètes et le comportement attendu quand deux versions coexistent.
• Traçabilité : conserver, pour une réponse donnée, la requête, les passages retenus et la version de configuration utilisée.

Évaluer le retrieval séparément de la génération

C'est probablement le marqueur le plus discriminant. Tant que l'évaluation porte sur la réponse finale, on mesure un mélange de deux étapes et on ne sait pas laquelle corriger. Séparer les deux permet de répondre à une question simple : le passage nécessaire à la réponse était-il présent dans ce qui a été fourni au modèle ?

1. 1

   Constituer un jeu de questions réelles

   étape 1

   Des questions posées par les utilisateurs, pas des questions inventées à partir des documents. Avec les experts métier, on associe à chaque question le ou les passages qui contiennent la réponse. Quelques dizaines de cas bien choisis sont plus utiles qu'un grand volume généré automatiquement.

2. 2

   Mesurer d'abord le retrieval

   étape 2

   Pour chaque question, le passage attendu figure-t-il dans les résultats retournés, et à quelle position ? Cela suffit à distinguer un défaut de recherche d'un défaut de rédaction, et cette mesure ne dépend pas du modèle génératif.

3. 3

   Mesurer ensuite la génération

   étape 3

   À passages fournis identiques, la réponse est-elle fidèle aux passages, complète, correctement citée, et sait-elle s'abstenir quand l'information manque ? Le jugement peut être humain sur un échantillon, ou automatisé, à condition d'avoir vérifié que l'automatisation est d'accord avec les experts sur les cas connus.

4. 4

   Rejouer à chaque modification

   étape 4

   Changement de découpage, de modèle d'embedding, de seuil, de prompt, de fournisseur : la même série est rejouée. Sans cela, chaque amélioration reste une impression, et les régressions passent inaperçues jusqu'à ce qu'un utilisateur les signale.

Cas pratique : changer de modèle ne répare pas un mauvais retrieval

Situation fréquente. Un assistant interne répond de façon incomplète sur les procédures internes. L'équipe conclut que le modèle est trop faible et bascule vers un modèle plus performant et plus cher. Les réponses deviennent mieux écrites, plus assurées — et restent fausses sur les mêmes questions.

Latence, coût, observabilité, échecs

Un système interrogé quotidiennement par une équipe entière n'a pas les mêmes contraintes qu'une démonstration. Chaque étape ajoutée — recherche hybride, reranking, appels multiples — améliore potentiellement la qualité et ajoute du délai et du coût. Arbitrer, c'est savoir quelle dégradation de qualité est acceptable pour rester dans une enveloppe tenable, et pouvoir l'expliquer.

• Observabilité : conserver les requêtes, les passages retenus, les scores, la latence par étape et le coût par requête. Sans ces traces, tout diagnostic devient une reconstitution.
• Modes de défaillance : indisponibilité du fournisseur, dépassement de contexte, dégradation silencieuse après une réindexation partielle, documents supprimés côté source mais toujours indexés.
• Retours utilisateurs : un canal simple pour signaler une réponse erronée, relié aux traces, alimente le jeu d'évaluation avec des cas réels.
• Coût : le poste dominant n'est pas toujours celui qu'on croit ; le reranking et les appels répétés pèsent parfois plus que la génération elle-même.

Trois niveaux, et ce qu'ils permettent de dire de soi

Ces niveaux ne sont pas des titres de poste, ce sont des degrés d'autonomie. Se situer honnêtement est plus solide que de revendiquer le niveau supérieur : en entretien, l'écart apparaît à la première question de diagnostic.

1. 1

   Connaître RAG

   niveau 1

   Comprendre le principe, le vocabulaire, le rôle de chaque composant, et pourquoi on ne se contente pas d'envoyer la question au modèle. Suffisant pour un rôle produit, projet ou métier qui doit dialoguer avec une équipe technique. Insuffisant pour revendiquer une compétence de mise en œuvre.

2. 2

   Savoir construire un prototype

   niveau 2

   Assembler les composants sur un cas d'usage, faire les choix de découpage, obtenir des réponses correctes sur un corpus maîtrisé, identifier les limites de ce qu'on a construit. C'est un vrai niveau, et le décrire comme tel est parfaitement recevable. Le présenter comme une expérience de production ne l'est pas.

3. 3

   Savoir travailler sur un RAG en production

   niveau 3

   Évaluer séparément retrieval et génération, diagnostiquer une réponse fausse, gérer droits et fraîcheur, arbitrer qualité contre coût et latence, instrumenter, absorber une régression et une panne de fournisseur, maintenir le système quand le corpus évolue. C'est ce niveau que la plupart des offres visent lorsqu'elles écrivent « expérience RAG ».

Comment le démontrer sans exagérer

Ce qui convainc n'est pas la liste des outils employés mais la chaîne de décisions. Une réponse qui vaut est de la forme : voici le problème, voici ce que j'ai mesuré, voici ce que j'ai changé, voici ce que cela a coûté, voici ce que je n'ai pas résolu. La dernière partie compte autant que les autres : nommer une limite restante est un signe de niveau, pas un aveu de faiblesse.

Si votre expérience s'arrête au prototype, dites-le et décrivez précisément ce que vous feriez avant une mise en production. C'est une réponse crédible, vérifiable, et elle vous évite la question suivante à laquelle vous ne pourriez pas répondre.

• RAG
• Évaluation
• Production