L’intelligence artificielle a introduit tout un nouveau vocabulaire dans les conversations technologiques et stratégiques.
Les entreprises entendent désormais parler d’agents IA, de Retrieval-Augmented Generation, d’ingénierie du contexte, de LLM Wikis, d’intégrations MCP et de Forward Deployed Engineers.
Le problème est que ces expressions sont souvent utilisées avant que leur signification pratique ne soit correctement expliquée.
Certaines désignent des technologies. D’autres décrivent des architectures, des fonctions d’ingénierie ou des méthodes permettant d’intégrer l’IA dans une organisation.
Il est important de comprendre ces différences.
Une entreprise n’a pas nécessairement besoin de tous les nouveaux concepts liés à l’IA. Elle doit identifier la combinaison de modèles, de données, de logiciels et de compétences capable de résoudre un problème opérationnel précis.
Ce guide présente les principaux termes qui façonnent actuellement le marché de l’IA et explique leur signification pour les entreprises envisageant une mise en œuvre concrète.
1. Qu’est-ce qu’un LLM ?
Un LLM, ou Large Language Model, est un modèle d’intelligence artificielle entraîné à comprendre et à produire du langage.
Les LLM alimentent de nombreux assistants d’IA modernes et peuvent notamment :
- Répondre à des questions ;
- Résumer des documents ;
- Extraire des informations ;
- Classer des textes ;
- Générer des rapports ;
- Produire du code informatique ;
- Traduire du contenu ;
- Soutenir des processus métier.
Le LLM constitue la composante intelligente d’une solution d’IA, mais il représente rarement la solution complète.
Un système utilisé en production a également besoin d’interfaces, de connexions aux données, de permissions, de règles métier, d’un suivi technique et de mécanismes permettant de vérifier les résultats du modèle.
Donner accès à un assistant d’IA généraliste n’est donc pas équivalent à intégrer l’intelligence artificielle dans un processus d’entreprise.
2. Qu’est-ce que le RAG ?
RAG signifie Retrieval-Augmented Generation, ou génération augmentée par la recherche.
Cette architecture permet à un modèle d’IA de consulter des informations externes avant de produire une réponse.
Sans RAG, un LLM s’appuie principalement sur les connaissances acquises pendant son entraînement et sur le contenu fourni directement dans la conversation.
Avec le RAG, l’application recherche des informations dans une collection définie de documents ou d’enregistrements. Elle transmet ensuite les passages pertinents au modèle comme contexte supplémentaire.
Un système RAG peut, par exemple, permettre à un collaborateur de demander :
- Que prévoit notre politique interne de déplacement ?
- Quelle procédure d’assistance s’applique à ce client ?
- Quelles sont les conditions de ce contrat ?
- Comment cette machine doit-elle être entretenue ?
- Quelle réglementation s’applique à ce produit ?
Un pipeline RAG traditionnel divise généralement les documents en sections plus petites, souvent appelées chunks. Lorsqu’une question est posée, le système recherche les sections les plus susceptibles de contenir la réponse.
Le RAG est utile lorsque les informations évoluent régulièrement, sont propres à l’entreprise ou ne doivent pas être intégrées de manière permanente au modèle.
Cependant, la récupération de quelques fragments ne fournit pas toujours suffisamment de structure pour comprendre les relations entre plusieurs documents.
C’est l’un des problèmes auxquels les LLM Wikis tentent de répondre.
3. Qu’est-ce qu’un LLM Wiki ?
Un LLM Wiki est une base de connaissances structurée conçue pour être recherchée, consultée et parfois mise à jour par des agents IA.
Au lieu de conserver les connaissances de l’entreprise uniquement sous forme de fragments de documents indépendants, un LLM Wiki organise les informations en pages connectées.
Une page peut décrire :
- Un client ;
- Un produit ;
- Un processus métier ;
- Un système technique ;
- Une politique interne ;
- Un contrat ;
- Un problème d’assistance récurrent ;
- Une décision prise au cours d’un projet.
Les pages peuvent contenir des liens vers des concepts associés ainsi que des références vers les sources originales.
Des travaux de recherche récents décrivent le LLM Wiki comme une architecture native pour les agents. Les documents sont transformés en pages structurées reliées par des liens bidirectionnels. L’agent peut effectuer une recherche, lire les pages et suivre les connexions jusqu’à disposer de suffisamment d’éléments pour répondre.
Quelle est la différence entre un LLM Wiki et un RAG traditionnel ?
Le RAG traditionnel récupère généralement des fragments de documents en fonction de leur similarité avec la question de l’utilisateur.
Un LLM Wiki tente de fournir une représentation plus organisée des connaissances.
Pour analyser un problème récurrent chez un client, un agent peut, par exemple, naviguer entre des pages concernant :
- Le client ;
- Le produit utilisé ;
- Les incidents précédents ;
- Le contrat de service concerné ;
- Le composant technique à l’origine du problème.
La différence peut être résumée ainsi :
- Le RAG récupère des informations pertinentes ;
- Le LLM Wiki organise les connaissances pour permettre à un agent d’explorer leurs relations.
Les deux approches peuvent être combinées. Le RAG peut localiser les documents sources tandis qu’un wiki structuré conserve les connaissances régulièrement utilisées.
Quels sont les risques d’un LLM Wiki ?
Un LLM Wiki n’est pas automatiquement fiable.
Lorsqu’un modèle transforme des documents en résumés ou en pages structurées, certains détails importants peuvent être omis ou simplifiés de manière incorrecte.
Une transformation automatique et non contrôlée peut supprimer des faits essentiels si le système ne dispose pas de mécanismes d’évaluation et d’amélioration.
Une mise en œuvre professionnelle nécessite donc :
- Des liens vers les sources originales ;
- Une gestion des versions ;
- Des contrôles d’accès ;
- Des processus de mise à jour ;
- Des évaluations automatisées ;
- Une validation humaine pour les contenus critiques ;
- Une responsabilité clairement définie pour la base de connaissances.
4. Qu’est-ce qu’un agent IA ?
Un agent IA est un système logiciel qui utilise un modèle d’intelligence artificielle pour déterminer les étapes à suivre afin d’atteindre un objectif.
Un chatbot classique répond à un message.
Un agent peut exécuter une séquence d’actions.
Un agent de support peut, par exemple :
- Recevoir la demande d’un client ;
- Rechercher dans la documentation interne ;
- Consulter le compte du client ;
- Analyser les incidents précédents ;
- Préparer une réponse ;
- Créer un ticket ;
- Demander à un collaborateur d’approuver l’action.
L’agent ne se limite donc pas à générer du texte. Il interagit avec des outils et des systèmes.
Cette capacité rend les agents potentiellement plus utiles, mais également plus complexes et plus risqués.
Un agent déployé en production doit être strictement encadré concernant :
- Les données auxquelles il peut accéder ;
- Les outils qu’il peut utiliser ;
- Les actions qu’il peut exécuter ;
- Les situations nécessitant une validation humaine ;
- La journalisation de ses actions ;
- La manière dont il réagit en cas d’incertitude.
Les meilleurs cas d’usage sont généralement limités et mesurables. Un agent chargé d’exécuter un processus clairement défini est plus simple à évaluer et à contrôler qu’un « collaborateur IA » généraliste.
5. Qu’est-ce qu’un Forward Deployed Engineer ?
Un Forward Deployed Engineer, ou FDE, est un ingénieur qui travaille étroitement avec un client pour intégrer une technologie dans son environnement opérationnel réel.
La fonction se situe à l’intersection de l’ingénierie logicielle, du conseil technique, de la découverte produit et de l’implémentation.
Au lieu de recevoir une spécification complète et de développer le système à distance, le FDE contribue à étudier le problème, définir la solution, connecter les systèmes existants et accompagner l’adoption en production.
Un FDE peut notamment :
- Interroger les utilisateurs et les équipes opérationnelles ;
- Cartographier les processus existants ;
- Étudier les systèmes et les données de l’entreprise ;
- Développer des intégrations et des logiciels de production ;
- Tester la solution dans des processus réels ;
- Mesurer son adoption et son impact ;
- Adapter l’implémentation en fonction des retours.
Quelle est la différence entre un FDE et un développeur externalisé ?
Un développeur externalisé reçoit généralement des tâches au sein d’un projet déjà structuré.
Un FDE assume souvent une responsabilité plus large : comprendre ce qui doit être développé et s’assurer que la solution fonctionne réellement.
La différence ne repose donc pas uniquement sur l’expérience technique. Elle repose également sur la proximité avec le problème métier.
Ce modèle est particulièrement pertinent pour l’intelligence artificielle, car une partie des exigences ne devient visible qu’après avoir connecté la solution aux données, aux utilisateurs et aux processus réels de l’entreprise.
6. Qu’est-ce que l’ingénierie du contexte ?
L’ingénierie du contexte consiste à concevoir les informations, instructions et outils auxquels un modèle d’IA a accès pendant l’exécution d’une tâche.
Le prompt ne représente qu’une partie de ce contexte.
Le contexte complet peut inclure :
- Les instructions système ;
- Les documents de l’entreprise ;
- Les informations concernant l’utilisateur ;
- Les interactions précédentes ;
- Les données issues d’une base de données ;
- Les outils disponibles ;
- Des exemples de réponses correctes ;
- Les règles métier ;
- Le format attendu ;
- Les restrictions de sécurité.
Prenons l’exemple d’un assistant chargé d’analyser des contrats.
La qualité de son travail dépend non seulement du prompt, mais aussi de sa capacité à recevoir :
- La bonne version du contrat ;
- Les clauses standards de l’entreprise ;
- Les réglementations applicables ;
- Le contexte commercial du client ;
- Les instructions concernant les risques à identifier ;
- Un format structuré pour l’analyse.
L’ingénierie du contexte est donc plus proche de la conception d’un système que de la simple rédaction d’un meilleur prompt.
7. Qu’est-ce que le MCP ?
MCP signifie Model Context Protocol.
Il s’agit d’un standard ouvert permettant de connecter des applications d’IA à des sources de données, à des outils et à des processus externes.
Avant l’apparition de protocoles comme le MCP, les développeurs créaient souvent une intégration spécifique pour chaque combinaison entre un modèle d’IA et un outil externe.
Le MCP propose une structure commune permettant d’exposer :
- Des ressources pouvant être consultées par l’IA ;
- Des outils pouvant être exécutés ;
- Des prompts ou des processus réutilisables ;
- Des mécanismes d’authentification et d’autorisation.
Un serveur MCP peut, par exemple, permettre à une application autorisée de :
- Consulter la documentation interne ;
- Rechercher un produit dans une base de données ;
- Interroger un CRM ;
- Créer une tâche dans un outil de gestion de projet ;
- Lire les données de surveillance d’un système.
Le MCP ne garantit pas automatiquement la sécurité d’une intégration. Les permissions, l’authentification, la validation des données et la journalisation doivent toujours être correctement conçues.
8. Que sont les evals ?
Les evals, ou évaluations, sont des tests structurés permettant de mesurer les performances d’un système d’IA.
Un logiciel traditionnel peut souvent être testé avec des règles déterministes : une entrée précise doit produire un résultat précis.
Les systèmes d’IA sont moins prévisibles. Deux réponses formulées différemment peuvent être correctes, tandis qu’une réponse convaincante peut contenir une erreur factuelle.
Les évaluations peuvent notamment mesurer :
- L’exactitude des réponses ;
- Leur niveau de complétude ;
- L’utilisation correcte des sources ;
- Le respect des instructions ;
- La qualité d’une classification ;
- Le choix des outils par un agent ;
- Le nombre de tâches correctement exécutées ;
- La fréquence des actions non autorisées ;
- Le coût et le temps de réponse.
Les scénarios d’évaluation doivent refléter les processus réels de l’entreprise.
Sans evals, les équipes évaluent souvent une solution sur la base de quelques démonstrations impressionnantes. Cela ne suffit pas pour déterminer sa fiabilité en production.
9. Que sont les guardrails et les processus human-in-the-loop ?
Les guardrails sont des contrôles techniques et opérationnels qui limitent ce qu’un système d’IA peut faire.
Ils peuvent notamment :
- Bloquer l’accès à certaines informations ;
- Vérifier les données avant leur envoi au modèle ;
- Limiter les outils utilisables par un agent ;
- Exiger une confirmation avant une action importante ;
- Détecter la présence de données sensibles ;
- Restreindre les actions selon le rôle de l’utilisateur ;
- Enregistrer les opérations dans un journal d’audit.
Un processus human-in-the-loop impose l’intervention d’une personne pour contrôler ou approuver certaines décisions.
Une IA peut, par exemple, préparer une instruction de paiement, mais un collaborateur du service financier doit la valider avant son exécution.
Le niveau de contrôle humain dépend du risque associé au processus.
Le résumé d’un document interne peut nécessiter peu de supervision. Une décision liée à un paiement, un contrat, un recrutement, un traitement médical ou une infrastructure critique nécessite des contrôles beaucoup plus stricts.
Ces termes décrivent les composants d’un système
Les LLM, le RAG, les LLM Wikis, le MCP, les agents et les evals ne sont pas nécessairement des solutions concurrentes.
Ils représentent différentes couches d’un système d’IA.
Une architecture d’entreprise simplifiée peut fonctionner ainsi :
- Un LLM fournit des capacités linguistiques et de raisonnement ;
- Le RAG récupère les documents pertinents ;
- Un LLM Wiki organise les connaissances récurrentes ;
- L’ingénierie du contexte détermine les informations reçues par le modèle ;
- Le MCP ou des API spécifiques connectent le modèle aux outils métier ;
- Un agent IA coordonne une série d’actions ;
- Les evals mesurent les performances ;
- Les guardrails contrôlent les risques ;
- Un FDE ou une équipe d’implémentation met l’ensemble en production.
Toutes les entreprises n’ont pas besoin de chacune de ces couches.
L’architecture adaptée dépend du processus métier, des systèmes existants, des données disponibles et du niveau de risque.
Commencer par le problème métier
L’une des erreurs les plus fréquentes consiste à commencer un projet par une technologie simplement parce qu’elle bénéficie d’une forte visibilité.
Une entreprise entend parler des agents IA et décide qu’elle en a besoin. Ce n’est qu’ensuite qu’elle cherche à déterminer ce que l’agent devrait faire.
Une meilleure approche commence par les questions suivantes :
- Quel processus est actuellement trop lent ou trop coûteux ?
- Où les collaborateurs perdent-ils du temps à rechercher des informations ?
- Quelles décisions dépendent de données fragmentées ?
- Quelles tâches manuelles peuvent être automatisées en toute sécurité ?
- Comment mesurer une amélioration ?
- À quels systèmes la solution devra-t-elle accéder ?
- Quelles seraient les conséquences d’une erreur ?
Ce n’est qu’après avoir répondu à ces questions que l’entreprise devrait choisir son architecture.
La meilleure solution peut être un agent, mais il peut également s’agir d’une interface de recherche, d’une automatisation traditionnelle, d’une nouvelle intégration ou de la modernisation d’un système existant.
L’approche de Dink concernant l’IA d’entreprise
Dink considère l’intégration de l’IA comme un défi métier et d’ingénierie logicielle, et non comme une simple expérimentation autour d’un modèle.
La démarche commence par l’analyse des processus, des systèmes, des sources de données et de l’environnement technique de l’entreprise.
La solution peut ensuite prendre la forme d’un agent IA, d’une automatisation, d’une application intégrant l’intelligence artificielle ou d’une plateforme développée sur mesure.
Après le déploiement, la solution est suivie et améliorée en fonction de son adoption, de ses performances et de son impact.
Dink associe également les mises à niveau IA sur mesure à des assessments technologiques, au développement de logiciels personnalisés et à la maintenance à long terme des systèmes existants.
Cette approche est particulièrement pertinente pour les entreprises disposant de systèmes historiques.
Il n’est pas toujours nécessaire de remplacer la plateforme centrale. Il peut être plus efficace de la documenter, de créer des intégrations sécurisées et d’introduire progressivement l’IA autour de l’environnement existant.
Pour en savoir plus, consultez le site de Dink.
Questions fréquentes
Un LLM Wiki est-il meilleur que le RAG ?
Pas dans toutes les situations. Le RAG est efficace pour rechercher des informations dans de grandes collections de documents. Un LLM Wiki peut être intéressant lorsqu’un agent doit explorer des relations structurées et réutiliser régulièrement des connaissances accumulées.
Un agent IA peut-il fonctionner sans supervision humaine ?
Un agent peut effectuer certaines actions prédéfinies de manière autonome. Les processus présentant davantage de risques doivent toutefois inclure des validations, des restrictions et des mécanismes d’audit.
Une entreprise a-t-elle besoin d’un FDE pour intégrer l’IA ?
Pas nécessairement sous ce titre précis. Les projets complexes bénéficient néanmoins d’ingénieurs qui travaillent directement avec les équipes métier et assument la responsabilité de l’implémentation, de la découverte au déploiement.
Le MCP est-il obligatoire pour connecter une IA à des systèmes ?
Non. Les API conventionnelles et les intégrations spécifiques restent parfaitement utilisables. Le MCP fournit une approche standardisée, mais ne remplace pas une architecture et une sécurité correctement conçues.
Peut-on ajouter de l’IA à un système historique ?
Oui. Des API et des couches d’intégration peuvent généralement introduire de nouvelles fonctionnalités sans remplacer l’ensemble du système. Un assessment technique doit d’abord examiner les données, la sécurité, l’architecture et les contraintes opérationnelles.
Conclusion
Le vocabulaire de l’intelligence artificielle continuera à évoluer.
Certains termes deviendront des composantes permanentes de l’ingénierie logicielle. D’autres seront remplacés au fur et à mesure de l’évolution des modèles et des architectures.
Les entreprises n’ont pas besoin de suivre chaque nouvelle tendance.
Elles doivent comprendre le rôle de chaque concept, le problème métier auquel il répond et les conditions nécessaires pour qu’il fonctionne de manière fiable en production.
L’avantage concurrentiel ne vient pas de l’utilisation du terme le plus récent. Il vient de la capacité à combiner la bonne technologie, les bonnes données, une architecture solide et une mise en œuvre adaptée afin de produire un résultat mesurable.