Depuis 2023, la plupart des entreprises ont expérimenté l’IA générative à travers des assistants conversationnels comme ChatGPT, Claude ou Gemini. Les collaborateurs s’en servent pour rédiger un mail, synthétiser un document, explorer une idée. Cette phase exploratoire touche à sa fin. Le sujet n’est plus de savoir si l’IA générative est utile, mais comment elle s’ancre dans les processus métier et dans le système d’information.
Shadow AI et limites du chatbot isolé
Le premier problème que rencontrent les DSI n’est pas technique, il est organisationnel. Quand chaque collaborateur utilise un assistant IA dans son navigateur, sans connexion aux données internes, les usages échappent à tout contrôle. IBM a documenté ce phénomène sous le terme de shadow AI : des modèles appelés hors de tout cadre de gouvernance, avec des données copiées-collées dans des interfaces publiques.
Ce fonctionnement pose un double problème. Les réponses produites par le modèle ne s’appuient pas sur les données métier réelles (référentiel client, état des stocks, historique de commandes). Et les données sensibles transitent par des canaux non maîtrisés. Le chatbot généraliste reste un outil individuel, déconnecté du SI. Pour qu’il produise des résultats fiables et exploitables, il faut l’intégrer.
Des acteurs comme Eleven Labs accompagnent cette transition en structurant le développement d’applications IA connectées aux briques existantes du système d’information, plutôt que de laisser les usages se disperser.
Connecter l’IA générative aux APIs, CRM et ERP
L’intégration concrète passe par un travail d’architecture. Un modèle de langage, qu’il soit hébergé chez OpenAI, Mistral ou un autre fournisseur, doit pouvoir interroger les sources de données de l’entreprise : CRM pour le contexte client, ERP pour les flux logistiques et financiers, plateformes Data pour les indicateurs métier.
Cette connexion repose sur des APIs. Le modèle n’accède pas directement à la base de données. Il passe par des couches d’abstraction qui filtrent, transforment et sécurisent les échanges. C’est la différence entre un assistant qui répond sur la base de son entraînement générique et une application métier qui génère une réponse à partir de données réelles et à jour.
Les points d’accès se multiplient : un agent spécialisé intégré à un outil interne, une interface conversationnelle embarquée dans le CRM, un module de génération de documents connecté à l’ERP. Le modèle de langage devient un composant du SI parmi d’autres, appelé par des applications métier selon des règles définies.
Le standard MCP et l’ouverture des systèmes
Pour que cette intégration passe à l’échelle, il faut des standards. Le protocole MCP (Model Context Protocol) répond à ce besoin en définissant une interface normalisée entre un modèle d’IA et les outils qu’il peut appeler. Plutôt que de développer un connecteur spécifique pour chaque couple modèle/application, MCP propose un contrat d’échange commun.
L’intérêt est double :
- Les éditeurs de logiciels métier exposent leurs fonctionnalités via un serveur MCP, ce qui les rend accessibles à tout modèle compatible, sans développement sur mesure à chaque intégration.
- Les équipes techniques peuvent remplacer ou mettre à jour le modèle sous-jacent sans réécrire les connecteurs, ce qui réduit la dette technique liée à ces intégrations.
- Les agents IA peuvent enchaîner plusieurs actions (consulter un CRM, créer un ticket, envoyer une notification) dans un flux cohérent, chaque étape étant un appel MCP documenté et traçable.
Les retours terrain divergent sur le niveau de maturité réel de ce standard. Certaines équipes l’utilisent en production, d’autres constatent que l’écosystème de serveurs MCP reste limité à quelques éditeurs. La direction est claire, le déploiement reste progressif.
Sécurité et conformité : ce que le AI Act change pour les intégrateurs
Les obligations européennes visant les modèles d’IA à usage général s’appliquent depuis le 2 août 2025. Les fournisseurs de modèles doivent fournir une documentation technique, préciser les capacités et limites du modèle, et publier un résumé des données d’entraînement. Pour les entreprises qui appellent un modèle via une API, cela transforme le choix du fournisseur en décision de gouvernance.
Au-delà de la conformité réglementaire, l’intégration au SI soulève des questions concrètes de sécurité :
- L’authentification : chaque appel au modèle doit être associé à une identité utilisateur et à un périmètre de droits d’accès. Un commercial ne doit pas obtenir les mêmes données qu’un directeur financier via le même agent IA.
- La confidentialité des données : les requêtes envoyées au modèle peuvent contenir des informations sensibles (données clients, montants contractuels). Le choix entre un modèle hébergé en externe et un modèle déployé sur infrastructure privée dépend directement de cette contrainte.
- La traçabilité : chaque interaction entre le modèle et le SI doit être journalisée, tant pour des raisons de conformité que pour le diagnostic en cas d’erreur.
Qualité des données et observabilité : industrialiser l’IA métier
Un modèle connecté à des données incomplètes ou incohérentes produira des résultats faux avec une grande assurance. C’est le risque principal quand on passe d’un assistant généraliste à une application métier. La qualité des données devient un prérequis non négociable.
Cela implique un travail en amont sur les référentiels : dédoublonnage des fiches clients dans le CRM, normalisation des nomenclatures produit dans l’ERP, documentation des schémas de données. Sans cette fondation, l’intégration d’un modèle amplifie les problèmes existants au lieu de les résoudre.
L’observabilité est l’autre pilier. Quand un modèle génère une recommandation ou déclenche une action métier, il faut pouvoir reconstituer le chemin : quelle donnée a été consultée, quel prompt a été envoyé, quelle réponse a été produite. Sans cette visibilité, le diagnostic d’une erreur ou d’un biais devient impossible, et la confiance des utilisateurs s’érode rapidement.
Passer d’un chatbot dans un navigateur à une application IA intégrée au SI n’est pas un changement d’échelle, c’est un changement de nature. Le modèle de langage cesse d’être un outil périphérique pour devenir un composant logiciel soumis aux mêmes exigences que tout autre élément du système d’information : disponibilité, sécurité, maintenabilité, conformité. Les entreprises qui traitent cette intégration comme un projet d’architecture, et pas comme un déploiement d’outil, sont celles qui transforment l’expérimentation en capacité durable.
