Architecture d’IA d’entreprise : RAG pour la recherche, LLM pour le raisonnement, modèles de décision pour le choix

Identifier des faits et en déduire des conclusions n’est plus une compétence rare. Le problème du design ouvert consiste à fournir des choix rapides et encadrés en qui le logiciel d’entreprise peut avoir confiance, sans transformer chaque étape microscopique en génération de texte libre.

Les discussions dans le secteur suivent une séquence familière : les modèles de base, l’amélioration par récupération d’informations, la récupération améliorée par graphes, puis les agents. Chaque étape comble un manque différent. Une étape reste peu développée : la prise de décision — pas une délibération conversationnelle, ni un simple texte généré, mais un résultat structuré et limité que l’application peut exécuter.

Des outils de décision de type System 1, tels que Jev (TypeSafe AI), rendent ce niveau concret. Ils suggèrent que les architectures de production pourraient avoir besoin d’un chemin de décision dédié en plus de la récupération d’informations et du raisonnement linguistique.

L’évolution de l’IA d’entreprise

Un calendrier simplifié aide à comprendre ce qui manque.

1. LLMs : « Quel texte peut être généré ? »

Les modèles de base ont permis aux machines de maîtriser la lecture et l’écriture en langage naturel. Ce qu’ils « savent » dépend encore du pré-entraînement ainsi que de la fenêtre de contexte fournie lors de l’inférence.

Dans les entreprises, ce manque apparaît immédiatement. Les connaissances essentielles ne se trouvent que rarement dans les poids du modèle ; elles résident plutôt dans des documents, des dépôts, des API, des bases de données, des politiques, des guides opérationnels, des tickets, du courrier électronique, des règles métier, des wikis et des applications.

Cette pression a poussé l’architecture technique à évoluer vers un niveau supérieur.

2. RAG : « Où se trouve le matériel ? »

La génération augmentée par la récupération permet aux modèles de consulter les ressources internes de l’entreprise. Au lieu d’exiger une récupération totale des informations depuis les poids du modèle, les pipelines chargent le matériel pertinent et l’intègrent comme contexte de travail.

Le pipeline devient alors :

Ressources de l’entreprise → Chargement → Contexte de travail → Modèle de langage → Réponse

Ce saut en avant a été très utile. RAG rencontre toujours un obstacle structurel : la recherche de documents similaires n’est pas équivalente à la compréhension des liens entre les données de l’entreprise.

Considérons un différend lié à la couverture :

« Qu’est-ce qui a entraîné le rejet de cette demande, et mérite-t-elle d’être escaladée ? »

Pour y répondre, il peut être nécessaire de suivre cette séquence :

Client → Police d’assurance → Produit → Couverture → Demande → Diagnostic → Exclusion → Clause de la police → Règle réglementaire

Ce n’est pas seulement un problème de recherche par mots-clés. C’est un problème de relations et de raisonnement.

3. GraphRAG : « Comment ces éléments sont-ils reliés ? »

Les graphes et GraphRAG sont ensuite apparus. Au lieu de fragments isolés, ces plateformes modélisent des entités et des liens entre elles. Par exemple :

Customer
   │
   ├── owns → Policy
   │              │
   │              ├── covers → Product
   │              │
   │              └── governed by → Rule
   │
   └── submitted → Claim
                       │
                       ├── relates to → Diagnosis
                       │
                       └── evaluated against → Coverage

La navigation remplace la récupération du « paragraphe le plus proche ». Il s’agit de la couche de connaissances d’entreprise qui sous-tend les connaissances structurées, le travail de type OKF et les expériences GraphRAG.

Même ainsi, une autre question demeure. Une fois le contexte compris et analysé : que doit faire réellement le système ?

4. Agents : « Que doit se passer ensuite ? »

Les conceptions d’agents considèrent le modèle de langage comme un chef d’orchestre. Il peut délibérer, choisir des outils, appeler des API, examiner les résultats, sélectionner l’étape suivante, invoquer un autre outil et continuer jusqu’à ce que la tâche soit terminée.

Cette capacité crée une pression architecturale : on demande au même modèle polyvalent de gérer chaque étape :

Understand
   ↓
Reason
   ↓
Choose
   ↓
Route
   ↓
Decide
   ↓
Call API
   ↓
Inspect result
   ↓
Decide again
   ↓
Call another API

Des questions dérangeantes en découlent. Chaque petite décision prise par un agent a-t-elle besoin d’un modèle de raisonnement puissant ? Un modèle axé sur le langage devrait-il prendre en charge des décisions telles que :

« Diriger ce ticket vers l’équipe A ou l’équipe B ? » « Poursuivre ce flux de travail ? » « Un humain doit-il intervenir ? » « Laquelle des cinq actions prédéfinies s’applique ? » « Cette transaction dépasse-t-elle le seuil d’escalade ? »

Ce sont souvent des problèmes de décision, et non des problèmes de génération de langage.

Les modèles de décision du Système 1

Ici, Jev joue un rôle important. TypeSafe AI le présente comme un modèle de Système 1. Conceptuellement, la distinction est simple :

• Un LLM est principalement optimisé pour produire du langage (« Quelle formulation convient ? »).
• Un modèle de décision prend en compte un état structuré et répond à des questions prédéfinies par des résultats structurés (« Laquelle des décisions logicielles s’applique ? »).

Les documents publics décrivent Jev comme un système qui génère des réponses tapées ainsi que de la confiance à partir de l’état partagé de l’application, en donnant la priorité à la vitesse plutôt qu’à la prose. Cette séparation permet une architecture plus propre.

La couche manquante

L’IA d’entreprise n’a pas besoin de ressembler uniquement à :

Enterprise Data
      ↓
     RAG
      ↓
     LLM
      ↓
    Agent
      ↓
   Actions

Un design plus séparé ressemble à :

Enterprise Systems
        ↓
Knowledge Engineering
        ↓
Enterprise Knowledge Layer
        ↓
Context Engineering
        ↓
 ┌──────────────┬──────────────┐
 │              │              │
 ▼              ▼              ▼
Reasoning    Decision       Rules
 LLM          Model          Engine
 │              │              │
 └──────────────┴──────────────┘
                ↓
          Agent Control
                ↓
        Deterministic Code
                ↓
        APIs / Workflows

Les responsabilités deviennent plus claires.

Les LLM n’ont pas besoin de tout faire

Prenons l’exemple d’un flux de service d’assurance. Un client écrit :

« Cette demande de remboursement pour hospitalisation a été rejetée, mais semble mériter une couverture. »

La plateforme doit d’abord établir le contexte. Elle peut récupérer les données du client, les détails de la police d’assurance, la configuration du produit, les garanties, les données relatives aux demandes de remboursement, des informations sur l’hôpital, les exclusions, les clauses de la police et les règlements en vigueur. C’est là que la couche de connaissances d’entreprise et GraphRAG deviennent utiles.

L’LLM peut alors raisonner :

« Le rejet semble lié à l’exclusion X. La clause Y pourrait créer une exception dans des conditions Z. »

Viennent ensuite des choix définis :

Does this require human review?
        → YES

Which workflow?
        → Claims InvestigationPriority?
        → HighAdditional evidence required?
        → YESCustomer communication template?
        → Coverage Review

Il s’agit de décisions structurées, et non d’une génération ouverte — c’est précisément là que convient un modèle de décision comme Jev.

L’architecture commence à prendre une forme différente

L’intelligence artificielle d’entreprise peut être représentée comme des responsabilités cognitives distinctes.

Couche de connaissances

Quelles sont les informations dont dispose l’entreprise ?

OKF — graphes de connaissances — documents — code source — API — bases de données.

Couche de contexte

Quelles informations sont pertinentes pour ce problème ?

RAG, GraphRAG, ingénierie du contexte.

Couche de raisonnement

Que signifient ces informations ?

LLM et modèles de raisonnement.

Couche de décision

Compte tenu de cette situation, que devrait faire la plateforme ?

Des modèles de décision tels que Jev.

Couche d’exécution

Comment cette décision doit-elle être exécutée ?

API, flux de travail, règles métier, logiciels déterministes.

Cette séparation est importante : l’intelligence ne nécessite pas un modèle géant qui fait tout.

Cela change la façon dont nous devrions envisager les connaissances d’entreprise

L’infrastructure de connaissances d’une entreprise va au-delà d’une simple amélioration des recherches. Elle peut devenir le substrat d’état pour la prise de décision par les machines.

Imaginez un graphe contenant :

Customer
Policy
Product
Claim
Agent
Branch
API
Business Rule
Regulation
Risk
Transaction

avec des relations telles que :

Customer → owns → Policy

Policy → belongs to → ProductPolicy → covers → BenefitClaim → relates to → PolicyClaim → triggered by → EventProduct → governed by → RuleRule → derived from → Regulation

Le système ne se contente plus de récupérer des « documents sur les demandes ». Il crée une vue structurée de l’état métier que différents éléments d’intelligence peuvent utiliser :

• LLM pour le raisonnement
• Modèle de décision pour des choix limités
• Règles pour des contraintes déterministes
• Code pour l’exécution

Cette composition est plus facile à maintenir qu’un seul mega-prompt.

La partie intéressante : la confiance devient une primitive architecturale

Les modèles de décision permettent également d’exprimer la confiance. De nombreuses applications d’IA se contentent de dire « le modèle a généré X ». Les opérateurs ont également besoin de savoir : à quel point l’appel est-il fiable, et qu’est-ce qui s’exécute lorsque la confiance est trop faible ?

Imaginez :

Decision
   ↓
Confidence
   ↓
 ┌───────────────┐
 │               │
High           Low
 │               │
 ▼               ▼
Auto           Human
execute       review

Les seuils doivent être ajustés en fonction de chaque cas d’usage, mais le principe est puissant. Traitez la sortie de l’IA comme une décision avec incertitude, puis encodez la politique d’autonomie :

High confidence
        ↓
Autonomous execution

Medium confidence
        ↓
Secondary validationLow confidence
        ↓
Human intervention

Les industries régulées ont particulièrement besoin de cette approche.

Cela pourrait également changer l’économie de l’IA

Si chaque petite décision prise par un agent consomme beaucoup de ressources de traitement, les coûts et les délais augmentent à l’échelle d’une flotte — avec des milliers ou des millions d’appels. Lorsque de nombreuses décisions sont restreintes et répétitives, un décideur spécialisé peut modifier la courbe des coûts et des délais.

Cela donne naissance à une autre couche de routage :

Complex reasoning
        ↓
       LLM

Bounded decision
        ↓
   Decision ModelDeterministic rule
        ↓
     Rule EngineExecution
        ↓
       Code

L’objectif n’est pas de remplacer les LLM. Il s’agit plutôt de cesser de les utiliser pour des tâches qu’ils n’ont pas besoin d’exécuter.

Cela change également la manière dont nous évaluons l’IA

Les tableaux de bord actuels suivent souvent les utilisateurs, les prompts, les tokens, l’utilisation du modèle, les délais, le taux d’adoption et les coûts. Ces indicateurs restent utiles. Une fois que l’IA prend des décisions opérationnelles, une autre couche de métriques apparaît.

Métriques d’intelligence décisionnelle

Nombre de décisions prises par l’IA Latence de décision Vitesse à laquelle les décisions apparaissent Distribution de confiance Niveau de certitude du système Taux de résolution automatique Fréquence à laquelle les humains sont dépassés Taux d’escalade Fréquence à laquelle l’intervention humaine est requise Précision des décisions Si le choix était correct Taux de décisions erronées Fréquence à laquelle le choix était faux Cost par décision Coûts économiques liés aux décisions de l’IA Effort de révision humaine Charge opérationnelle Résultat commercial Valeur réellement créée

Cela déplace la discussion de l’adoption de l’IA vers l’économie de l’intelligence artificielle.

Et il existe une mise en garde importante

Jev est complètement nouveau. Il convient de noter que les présentations publiques ne sont prévues qu’en septembre 2026, ce qui signifie que les preuves indépendantes restent limitées. Il serait prématuré de considérer Jev — ou tout autre outil émergent destiné à prendre des décisions — comme un substitut fiable aux modèles de langage grand public.

La question expérimentale pertinente est la suivante :

Dans quels cas un outil conçu spécifiquement pour prendre des décisions surpasse-t-il un modèle de langage, un moteur de règles classique ou une combinaison des deux ?

C’est quelque chose qui mérite d’être mesuré, plutôt que supposé.

L’expérience à mener

Choisissez un flux de processus d’entreprise bien défini — à titre d’exemple, l’affectation des demandes de service — et fournissez le même contexte structuré à plusieurs approches différentes.

Approche 1

Modèle de langage grand public → sortie structurée → logique d’application

Approche 2

Moteur de règles → décision déterministe

Méthode 3

Modèle de décision → décision typée

Méthode 4

Hybride :

Rules
  ↓
Decision Model
  ↓
LLM when ambiguity requires reasoning
  ↓
Human when confidence is insufficient

Ensuite, on mesure la précision, la calibration de la certitude, le délai, le coût, l’utilisation des tokens, le taux d’escalade, l’explicabilité, la maintenabilité, les modes de défaillance et les résultats commerciaux.

Cet essai est supérieur à d’autres classements qui affirment simplement qu’un modèle est « meilleur ». L’objectif n’est pas de couronner Jev. Il s’agit d’apprendre quel primitif d’intelligence doit être utilisé où.

De RAG au raisonnement à la prise de décision

En regardant à nouveau l’échelle :

RAG a demandé :

« Où se trouve le matériel ? »

Les graphes de connaissances ont demandé :

« Comment ces éléments sont-ils connectés ? »

GraphRAG a demandé :

« Quel chemin contextuel doit être emprunté ? »

Les LLM ont demandé :

« Que signifie ce contexte ? »

Les agents ont demandé :

« Que doit se passer ensuite ? »

Les modèles de décision ajoutent :

L’intelligence décisionnelle se demande :

« Étant donné cet état, quelle action définie devrait la plateforme choisir ? »

C’est une distinction architecturale significative.

L’ensemble technologique d’IA d’entreprise peut donc devenir cognitif, et non seulement technique

Les équipes représentent souvent l’architecture d’IA sous forme de composants :

LLM
Vector DB
Embedding Model
RAG
Orchestrator
API Gateway
Guardrails

Une approche axée sur les responsabilités cognitives ressemble plutôt à ceci :

ENTERPRISE AI
                          │
             ┌────────────┴────────────┐
             │                         │
          KNOWLEDGE                 CONTEXT
             │                         │
       KG / OKF / Data          RAG / GraphRAG
             │                         │
             └────────────┬────────────┘
                          │
                ┌─────────┴─────────┐
                │                   │
            REASONING            DECISION
                │                   │
             LLM/SLM            Jev / similar
                │                   │
                └─────────┬─────────┘
                          │
                     ORCHESTRATION
                          │
                      GUARDRAILS
                          │
                    HUMAN-IN-LOOP
                          │
                     EXECUTION
                          │
                  APIs / Workflows

la conception de l’IA au sein des entreprises s’éloigne du principe d’un seul modèle pour tout gérer pour se diriger vers un portefeuille de primitives d’intelligence — chacune adaptée à une tâche cognitive différente.

Le contexte global

Un thème récurrent dans la conception de l’IA d’entreprise :

L’avenir ne sera peut-être pas déterminé par celui qui possède le plus grand modèle. Il pourra être décidé par celui qui construit le meilleur système autour de ses modèles.

La différenciation réside de plus en plus dans la combinaison de connaissances propriétaires — de relations structurées — d’ingénierie contextuelle — de délibération — d’intelligence décisionnelle — et d’exécution contrôlée. Il convient de noter que le LLM n’est qu’un seul composant.

L’évolution suivante se présente comme suit :

Les modèles de génération laissent place aux systèmes de compréhension, puis aux systèmes de raisonnement, ensuite aux systèmes de décision, et enfin aux systèmes d’action.

Un avantage durable réside donc moins dans un seul point de contrôle que plutôt dans les liens qui relient les connaissances, le contexte, le raisonnement, les décisions et l’action — un problème d’ingénierie plus complexe que de se concentrer uniquement sur le nombre de paramètres.