La conception de systèmes RAG (Retrieval-Augmented Generation) pour l'entreprise échoue souvent car les équipes appliquent systématiquement un modèle unique : découper les documents en morceaux, les vectoriser et interroger via la similarité de cosinus. Cependant, cette approche classique est inadaptée à de nombreux cas réels. Elle sur-ingénierie les documents structurés, échoue à capturer les nuances de ton dans les transcriptions et ignore le contenu visuel des schémas. Une approche efficace nécessite un diagnostic basé sur deux axes principaux : la complexité des documents et le contrôle des questions. Le premier axe mesure la structure des documents, classés en cinq niveaux. Au sommet se trouvent les documents à modèle fixe, comme les formulaires de déclaration fiscale ou les certificats d'assurance générés par le même logiciel. Pour ces cas, l'extraction par expressions régulières (regex) est plus rapide et moins coûteuse que l'IA. Au niveau suivant, les documents suivent une famille de modèles avec des variations mineures, nécessitant un mélange de regex et d'appels d'IA pour les exceptions. Les documents hétérogènes structurés, comme les contrats légaux personnalisés, exigent une extraction basée sur la structure du document. Les documents numérisés et non structurés, souvent altérés par l'OCR, requièrent une récupération hybride. Enfin, les documents riches en visuels, tels que les schémas techniques ou les graphiques sur diapositives, nécessitent impérativement des modèles de vision, car une analyse textuelle pure perd les informations cruciales. Le deuxième axe évalue le contrôle des questions, allant de demandes programmées par des ingénieurs à des requêtes libres nécessitant une clarification. Dans le cas d'ingénieurs programmant l'interrogation, l'extraction de champs structurés suffit sans besoin de compréhension linguistique complexe. Lorsque les utilisateurs remplissent des modèles prédéfinis, la récupération de sections suffit. Les requêtes libres à une seule étape correspondent au RAG classique où le système doit interpréter la question en une seule fois. Les systèmes les plus avancés permettent des clarifications itératives, posant des questions de retour pour lever les ambiguïtés, une fonctionnalité essentielle pour les services client ou la conformité. L'intersection de ces deux axes définit la stack technique appropriée. Le coin supérieur gauche, caractérisé par des documents fixes et des questions contrôlées, représente la zone la plus critique pour la réduction des coûts : l'utilisation d'un grand modèle de langage (LLM) est ici un gaspillage financier par rapport à des scripts déterministes. La bande centrale correspond aux cas d'usage RAG classiques sur documents hétérogènes avec des questions ouvertes, nécessitant un traitement complet de parsing, de récupération et de reranking. La ligne du bas concerne les données visuelles, où les modèles de vision sont indispensables. Les problèmes à l'échelle du corpus entier, impliquant des milliers de documents, sortent de cette grille et nécessitent des bases de données structurées et des requêtes SQL avant toute tentative de RAG. Il est crucial de choisir la technique la plus simple capable de résoudre le problème. L'utilisation de contextes longs pour tout ingérer dans le prompt de l'IA n'est pas une solution viable pour les environnements de production, car les modèles perdent souvent des informations critiques au milieu du contexte. De même, des techniques avancées comme HyDE, qui génère un document hypothétique pour améliorer la recherche, sont souvent inefficaces dans l'entreprise où un dictionnaire de mots-clés expert est suffisant et moins coûteux. L'architecture idéale combine souvent un noyau déterministe pour la majorité des cas avec une retombée d'IA pour les exceptions. Avant de développer, les équipes doivent identifier l'utilisateur expert réel, généralement un professionnel qui connaît déjà le domaine, et positionner le système comme un outil d'amplification plutôt que de remplacement. En répondant à des questions précises sur la structure des documents et le type de requêtes, l'organisation peut cartographier son cas sur cette grille et sélectionner uniquement les articles et techniques pertinents d'une série plus large, évitant ainsi des développements inutiles et coûteux.