MCP, RAG et outils connectés : comment concevoir l’IA d’entreprise sans vendre de science-fiction à l’équipe

Toute entreprise qui expérimente l’IA a déjà vécu une version similaire de la scène : une démonstration impressionnante, un assistant qui répond avec fluidité, des documents internes consultés, des outils mis en route, un flux apparemment intelligent qui se déploie devant tout le monde.

La réaction est généralement immédiate : « c’est ça, il faut le mettre en production ».

L’enthousiasme est compréhensible. RAG, MCP, agents et outils connectés ont réellement ouvert des possibilités très intéressantes pour l’IA d’entreprise. Mais il existe une différence énorme entre une démonstration bien contrôlée et une solution prête à opérer en production.

Les démonstrations d’IA fonctionnent presque toujours mieux lorsque personne ne demande de coûts, de latence, de fallback, d’autorisation, d’audit et de qualité continue.

L’IA d’entreprise sérieuse commence lorsque l’émerveillement s’éteint et que l’ingénierie entre dans la salle.

RAG n’est pas de la magie, c’est une architecture de récupération

RAG, ou Retrieval-Augmented Generation, a gagné en place parce qu’il répond à une douleur réelle : les modèles de langage, par défaut, ne savent pas tout du contexte spécifique d’une entreprise. Ils ont besoin de rechercher des informations externes, des documents, des enregistrements, des bases de connaissances, des politiques internes ou des données de domaine pour répondre mieux.

L’idée générale est simple :

Utilisateur demande
  -> réécriture de requête
  -> recherche vectorielle / hybride
  -> classement
  -> assemblage du contexte
  -> réponse avec sources
  -> évaluation / feedback

Le problème, c’est que beaucoup de gens prennent le RAG comme s’il était une couche magique propre à l’entreprise. Ce n’est pas le cas.

Le RAG améliore l’accès au savoir, mais ne corrige pas tout seul :

• Documents de mauvaise qualité
• Données non à jour
• Bases dupliquées
• Sémantique ambiguë
• Permissions mal définies
• Absence de propriétaire
• Contenu sans versionnage
• Manque d’évaluation de la réponse

Si la base est médiocre, le RAG ne récupère que des déchets avec plus de sophistication.

C’est un point critique pour les équipes seniors : le RAG n’élimine pas la gouvernance des données et du contenu. Il accroît au contraire ce besoin.

La valeur du MCP réside dans la connexion, mais le risque aussi

MCP, Model Context Protocol, apparaît dans de nombreuses conversations récentes car il propose une approche plus standardisée pour connecter les modèles à des outils, des systèmes et des sources de contexte.

La promesse est puissante : au lieu que chaque intégration soit réalisée de manière isolée, le modèle peut désormais dialoguer avec des outils et des sources via une couche plus organisée. Cela aide à réduire les intégrations ad hoc et ouvre la voie à des architectures plus cohérentes.

Mais connecter les modèles au monde réel augmente à la fois la valeur et le risque.

Une chose, c’est qu’un modèle qui répond à une question. Une autre chose, c’est qu’il consulte le CRM, recherche des données financières, ouvre un ticket, met à jour le statut, génère un rapport ou déclenche un workflow.

Plus il y a d’outils connectés, plus les questions à résoudre se multiplient :

• Qui peut appeler cet outil ?
• Quelles données expose-t-il ?
• Quelles actions permet-il ?
• Cette action nécessite-t-elle une approbation humaine ?
• Comment auditer l’utilisation ?
• Que se passe-t-il si l’outil échoue ?
• Comment limiter le périmètre par profil, contexte ou domaine ?

Un exemple conceptuel d’outil :

{
  "tool": "crm.search_customer",
  "allowed_roles": ["support_agent", "account_manager"],
  "requires_approval": false,
  "data_scope": "customer_basic_profile"
}

Parece simples, mais esse tipo de definição separa arquitetura de produção de demonstração improvisada.

La différence entre répondre et agir

La plupart des risques augmentent lorsque l’IA cesse de se contenter de répondre et passe à l’action.

Répondre implique la qualité de l’information, la clarté, la source et la fiabilité. Agir implique un impact opérationnel.

Quand une IA exécute des actions, de nouvelles exigences apparaissent :

• Autorisation
• Validation
• Confirmation
• Idempotence
• Audit
• Fallback
• Rollback possible
• Limites par contexte

Un agent qui répond « ce client semble qualifié » comporte un risque. Un agent qui met à jour le statut du client dans le CRM en comporte un autre. Un agent qui envoie un e-mail au client en comporte encore un. Un agent qui effectue un remboursement, accorde un crédit ou modifie une configuration système entre dans un autre niveau de criticité.

Toutes les actions ne devraient pas être automatiques.

Certaines doivent exiger une confirmation humaine. D’autres doivent être bloquées. D’autres peuvent être autorisées uniquement dans des contextes très spécifiques.

Cette séparation doit exister dès la conception de l’architecture, et non dans l’espoir que le modèle « ait du flair ».

Les cinq points qui tuent habituellement des projets d’IA en production

Les projets d’IA d’entreprise meurent rarement parce que la démo n’a pas impressionné. Ils meurent parce que l’opération commence à facturer ce que la démo a ignoré.

1. Données de mauvaise qualité

Si les documents ne sont pas à jour, sont en double ou n’ont pas de propriétaire, la réponse peut sembler bonne et être cependant erronée.

2. Coût imprévisible

Chaque appel au modèle, chaque récupération de contexte, chaque re- ranking, chaque outil déclenché et chaque tentative de fallback a un coût. Sans estimation, le projet peut croître financièrement avant de croître en valeur.

3. Latence élevée

Les utilisateurs tolèrent un certain temps d’attente dans certains scénarios, mais pas partout. Les flux opérationnels nécessitent de la prévisibilité. Une IA trop lente peut devenir un goulot d’étranglement.

4. Absence de fallback

Si l’IA ne sait pas, si la source n’apparaît pas, si l’outil échoue ou si la fiabilité est faible, que se passe-t-il ? Sans fallback, le système improvise exactement là où il devrait être mieux contrôlé.

5. Manque d’évaluation continue

Une solution d’IA n’est pas prête juste parce qu’elle a bien répondu à vingt tests. Il faut évaluer la qualité au fil du temps, avec des cas réels, des retours et des critères clairs.

Ces points ne sont pas des accessoires. Ils constituent le cœur de la différence entre une démo et une architecture.

Comment concevoir une architecture réaliste

Une architecture d’IA d’entreprise connectée doit être pensée par couches.

Un dessin simplifié pourrait comprendre :

Interface de l'utilisateur
  -> Orchestration
  -> Récupération de contexte (RAG)
  -> Politiques et autorisations
  -> Outils connectés
  -> Observabilité
  -> Évaluation et feedback
  ->Fallback humain ou systémique

Chaque couche a une fonction.

L’interface capte l’intention et le contexte initial. L’orchestration décide du flux. Le RAG recherche des informations pertinentes. La couche de politiques détermine ce qui peut ou ne peut pas se faire. Les outils exécutent des requêtes ou des actions. L’observabilité enregistre le comportement. L’évaluation mesure la qualité. Le fallback protège l’utilisateur lorsque le système ne doit pas avancer tout seul.

L’erreur courante est de sauter directement de l’interface au modèle et du modèle à un outil.

Cela fonctionne en démonstration. En production, cela devient un risque.

Sécurité et autorisation ne peuvent pas être ajoutées après coup

Beaucoup de prototypes d’IA commencent avec des permissions larges car c’est plus facile à tester. Le problème survient lorsque cet esprit se rapproche de la production.

En IA d’entreprise, la sécurité doit être conçue dès le départ :

• Quelles données peuvent entrer dans le contexte ?
• Quelles sources sont autorisées pour cet utilisateur ?
• Quelles outils peuvent être appelés ?
• Quelles actions exigent une approbation ?
• Comment éviter les fuites entre domaines ?
• Ce qui doit être masqué ?
• Comment auditer l’interaction ?

Il ne suffit pas d’authentifier l’utilisateur à l’interface. L’autorisation doit suivre tout le flux : récupération de contexte, appel d’outil et action exécutée.

Un utilisateur sans autorisation pour voir des données financières ne devrait pas pouvoir les obtenir seulement parce qu’il a posé une question de manière créative à l’agent. Un agent sans autorisation pour exécuter des paiements ne devrait pas activer cet outil par déduction.

L’IA ne peut pas servir d’allier pour contourner les règles d’accès existantes.

Fallback est architecture, pas demande de pardon

Tout système d’IA devrait savoir échouer en sécurité.

Fallback n’est pas seulement un message disant « je n’ai pas pu répondre ». C’est une décision architecturale sur ce qu’il faut faire lorsque la confiance chute, que la source n’apparaît pas, que l’outil échoue ou que l’action est sensible.

Exemple conceptuel :

fallback:
when:
-confidence_below:0.72
-source_not_found:true
-action_is_sensitive:true
action: escalate_to_human

Cette approche évite l’un des pires comportements des systèmes basés sur l’IA : continuer à répondre avec assurance alors qu’il faudrait s’arrêter.

Dans les environnements d’entreprise, “je ne sais pas” peut être une réponse bien plus sûre qu’une réponse plausible et erronée.

L’observabilité en IA doit aller au-delà des logs techniques

Surveiller une IA connectée exige plus que la latence et les erreurs HTTP.

Il faut observer :

• Question de l’utilisateur
• Sources récupérées
• Score de récupération
• Contexte monté
• Réponse générée
• Outil appelé
• Action exécutée
• Approbation humaine
• Coût par interaction
• Latence par étape
• Retour utilisateur
• Taux de fallback

Sans cela, l’exploitation reste aveugle.

Quand une réponse est mauvaise, l’équipe doit pouvoir reconstruire le flux : le problème venait-il de la question, de la récupération, du classement, du contexte, du prompt, du modèle, de l’outil ou de l’autorisation ?

Sans observabilité, tout devient suspect.

Commencez petit : cas d’usage avant une plateforme générique

Une erreur classique consiste à vouloir démarrer avec « un copilote d’entreprise pour tout ». Cela peut paraître stratégique, mais se transforme souvent en champ d’application sans fin.

L’approche la meilleure consiste généralement à choisir un cas précis, important et mesurable.

Les bons candidats présentent certaines caractéristiques :

• Douleur clairement identifiée
• Base de connaissances délimitée
• Utilisateurs réels identifiés
• Risque maîtrisable
• Métrique de réussite objective
• Flux avec fallback possible
• Owner métier et technologique

Exemples :

• Assistant pour le support interne d’une politique spécifique
• Recherche intelligente dans la documentation technique d’un produit
• Résumé assisté de tickets avec révision humaine
• Soutien au triage des tickets
• Consultation contrôlée à une base de connaissances commerciale

Ces cas permettent de valider la valeur sans promettre de fiction scientifique.

Un cadre pratique pour revoir l’idée

Avant de mener le RAG, le MCP et les outils connectés en production, il convient de répondre à :

1. Quel problème précis cherchons-nous à résoudre ?

Si la réponse est « augmenter la productivité avec l’IA », ce n’est pas encore assez spécifique.

2. Quelles sources peuvent être utilisées ?

Une source sans propriétaire et sans qualité claire est risquée.

3. Qui valide la réponse ?

Sans validation, la qualité devient une perception subjective.

4. Quelles outils peuvent être appelés ?

Les outils connectés nécessitent des limites, un périmètre et une autorisation.

5. Existe-t-il un fallback ?

S’il n’existe pas, le système improvisera probablement là où il devrait évoluer.

6. Quel est le coût par interaction ?

Sans ce calcul, la solution peut ne pas être durable.

7. Comment mesurons-nous la qualité ?

Le retour, l’évaluation humaine, les tests de régression et les métriques de réussite doivent être intégrés à la conception.

8. Qui est le propriétaire ?

Sans propriétaire, la solution devient une automatisation orpheline.

Ces questions aident à séparer l’enthousiasme de l’architecture.

La séniorité, c’est ne pas vendre de la magie à l’équipe

Des équipes techniques expérimentées ne devraient pas nier le potentiel de l’IA. Il est réel.

Mais elles ne devraient pas non plus vendre à l’organisation une promesse que l’architecture ne soutient pas encore.

L’attitude la plus mature est justement celle du juste milieu : reconnaître la valeur, limiter le périmètre, concevoir correctement les couches, mesurer les résultats et évoluer avec une gouvernance.

Une IA d’entreprise sérieuse n’a pas besoin de paraître moins ambitieuse. Elle doit simplement être plus responsable.

Conclusion

Le RAG, le MCP et les outils connectés peuvent générer énormément de valeur dans les environnements d’entreprise. Ils permettent aux modèles de consulter des connaissances internes, d’interagir avec des systèmes et de soutenir des flux de travail réels.

Mais aucune de ces pièces n’élimine le besoin d’ingénierie.

Au contraire. Plus l’IA devient connectée, plus elle exige d’architecture.

Le défi n’est pas de créer une démonstration impressionnante. Le défi est de concevoir une solution qui tienne en production : avec sécurité, latence acceptable, coût prévisible, fallback, observabilité, évaluation et gouvernance.

L’IA d’entreprise sérieuse commence lorsque l’équipe cesse de se demander si la démonstration impressionne et commence à se demander si l’architecture tient la production.

Choisissez un cas petit et mesurable pour valider la valeur avant de proposer un copilote générique et difficile à exploiter.