Vous évaluez un assistant IA pour votre entreprise. Le prestataire vous montre une démonstration fluide : l'agent répond en quelques secondes à des questions sur vos contrats fournisseurs, vos engagements en cours, vos factures en attente. Le commercial vous explique qu'ils ont besoin d'une copie de vos données dans leur propre infrastructure pour des raisons de performance.
Ce que le commercial ne vous dit pas : cette copie parallèle fait perdre l'intégralité de votre modèle de droits. Un assistant qui devait répondre uniquement aux questions d'un responsable achats peut maintenant restituer toutes les données de votre SI, y compris les contrats que ce responsable n'a pas le droit de consulter.
Deux façons de brancher une IA sur vos données, et une seule qui tient
Quand vous connectez un assistant IA à votre système d'information, deux architectures sont possibles.
La première : le prestataire extrait une copie de vos données, la charge dans un index séparé (souvent un moteur vectoriel), et branche son agent sur cette copie. Chaque fois qu'un collaborateur pose une question, l'agent cherche dans l'index séparé puis restitue ce qu'il trouve. Cette approche est simple à implémenter et permet des réponses rapides, parce que l'index est optimisé pour la recherche sémantique.
La seconde : l'assistant interroge votre plateforme métier à travers les API que vous exposez déjà, avec un profil utilisateur qui porte des droits. Quand un collaborateur pose une question, l'agent formule une requête vers la plateforme en se présentant comme ce collaborateur, reçoit uniquement les données auxquelles ce collaborateur a accès, puis construit sa réponse. Cette approche demande que votre plateforme ait une interface programmatique stable et que vous définissiez un profil d'accès pour l'assistant.
Seule la seconde préserve vos droits d'accès. Seule la seconde permet de tracer qui a consulté quoi. Seule la seconde garantit que les données de la réponse sont à jour au moment de la question. Tout le reste est un compromis de commodité que l'on vous présente comme une contrainte technique.
La copie parallèle : pourquoi l'index séparé perd vos habilitations en chemin
Un index vectoriel est un magasin de fragments textuels transformés en coordonnées numériques. Pour remplir cet index, le prestataire extrait vos documents : contrats, factures, rapports, demandes d'achat, suivis de projets. L'extraction peut être complète (une copie miroir de votre base métier) ou partielle (un export mensuel sur un périmètre choisi).
Le problème apparaît au moment de l'indexation. Les fragments textuels portent leur contenu, mais ils ne portent plus le contexte des droits d'accès que votre plateforme attachait à chaque document. Un contrat fournisseur dans votre ERP peut être visible uniquement par les responsables achats, le responsable financier, et le directeur général. Dans l'index vectoriel, ce même contrat devient un fragment de texte parmi d'autres, sans indication de qui peut le consulter.
Résultat : quand un collaborateur qui n'a pas les droits sur ce contrat pose une question dont la réponse se trouve dans le fragment indexé, l'assistant restitue cette réponse. La fuite n'est pas un accident, elle est structurelle. Elle est inscrite dans l'architecture, parce que l'index ne peut pas évaluer les droits à chaque requête s'il n'a pas reçu ces droits au moment de l'indexation.
Certains prestataires ajoutent des filtres sur l'index : ils segmentent les fragments par département, par niveau hiérarchique, ou par projet. Ces filtres réduisent la surface de fuite, mais ils ne recréent pas votre modèle de droits. Un collaborateur qui change de poste reste associé au filtre de son ancien périmètre tant que vous n'avez pas mis à jour la segmentation dans l'index. Un collaborateur qui obtient un accès temporaire à un projet ne reçoit jamais les fragments de ce projet dans l'assistant, sauf si vous modifiez manuellement le filtre.
L'index séparé fait aussi perdre la journalisation. Votre plateforme métier trace toutes les consultations : qui a ouvert quel document, quand, depuis quel poste. L'assistant branché sur l'index interroge cet index, pas votre plateforme, donc aucune trace de consultation ne remonte dans vos journaux d'audit. En cas de contrôle ou de litige, vous n'avez aucun moyen de prouver qu'un collaborateur n'a jamais consulté une donnée sensible, parce que l'assistant ne vous a jamais dit si cette donnée était incluse dans une réponse.
La règle : l'IA est un utilisateur comme un autre, avec son profil et son périmètre
L'architecture sûre repose sur une règle simple : l'IA consomme votre plateforme comme un utilisateur humain, avec les mêmes interfaces, les mêmes droits, les mêmes traces.
Concrètement, cela signifie que l'assistant interroge les API de votre ERP, de votre CRM, de votre GED, exactement comme le ferait une application mobile ou un tableau de bord interne. Chaque requête de l'assistant est authentifiée avec le profil du collaborateur qui pose la question. Votre plateforme évalue les droits attachés à ce profil, filtre les résultats en conséquence, et renvoie uniquement les données que ce collaborateur peut voir.
Cette approche fait disparaître le risque de fuite par architecture. Si un collaborateur n'a pas le droit de lire un contrat, l'API ne retournera pas ce contrat à l'assistant, donc l'assistant ne pourra pas construire une réponse à partir de ce contrat. Il n'y a pas de copie parallèle, donc il n'y a pas de fragment orphelin de ses droits.
Elle préserve aussi la journalisation. Chaque appel de l'assistant vers l'API génère une ligne dans les journaux d'audit de votre plateforme, avec le profil du collaborateur concerné, l'heure, les données consultées. Ces journaux sont les mêmes que ceux qui tracent les actions des utilisateurs humains, donc vos procédures d'audit existantes s'appliquent sans modification.
Elle garantit enfin la fraîcheur des données. L'assistant lit les données au moment où le collaborateur pose la question, pas au moment d'une indexation qui a eu lieu la nuit précédente ou la semaine dernière. Si un contrat fournisseur a été modifié il y a dix minutes, la réponse de l'assistant intègre cette modification.
Le coût de cette architecture, c'est que votre plateforme doit exposer une interface programmatique stable. Si votre ERP n'a pas d'API documentée, ou si votre GED ne permet pas d'interroger les documents par le biais d'une requête structurée, brancher l'assistant en mode sécurisé demande d'abord de construire cette interface. Ce n'est pas un coût technique négligeable, mais c'est un investissement qui sert toutes les intégrations futures, pas uniquement l'assistant IA.
Ce que cela implique côté plateforme : une interface unique, des droits évalués à chaque requête, une journalisation des consultations
Pour que l'IA fonctionne comme un utilisateur, votre plateforme doit remplir trois conditions techniques.
Première condition : une interface unique. Tous les systèmes qui doivent être interrogeables par l'assistant doivent exposer une API REST ou GraphQL avec une documentation à jour. Cette API doit couvrir les mêmes opérations que celles accessibles via l'interface humaine : consulter un document, lire une liste de fournisseurs, récupérer l'historique d'un projet, extraire les factures en attente. Si un collaborateur peut voir une donnée dans l'application web de votre ERP, cette donnée doit être accessible via l'API.
Cela suppose que vos systèmes métiers aient une couche d'exposition programmatique. Les plateformes SaaS récentes ont cette couche par défaut. Les ERP legacy (SAP, Oracle, Microsoft Dynamics) ont des API, mais elles demandent souvent une configuration spécifique et des modules complémentaires. Les applications développées en interne n'ont parfois aucune API : il faut alors en construire une, ou accepter qu'elles restent hors de portée de l'assistant.
Deuxième condition : des droits évalués à chaque requête. L'API doit recevoir un jeton d'authentification qui identifie le collaborateur pour lequel l'assistant pose la question, puis filtrer les résultats en fonction des droits de ce collaborateur. Ce filtrage doit être dynamique : si un collaborateur perd un droit d'accès à un projet à 15h, une requête de l'assistant formulée à 15h05 pour ce collaborateur ne doit plus retourner les documents du projet.
Ce modèle de droits existe déjà dans votre plateforme métier. Il ne s'agit pas d'en créer un nouveau pour l'assistant, il s'agit de vérifier que l'API applique le même modèle que l'interface humaine. Le piège classique : une API qui contourne les droits pour des raisons de performance. Une API qui retourne toutes les données puis laisse l'application cliente filtrer selon les droits de l'utilisateur connecté. Ces raccourcis cassent l'architecture sécurisée.
Troisième condition : une journalisation des consultations. Chaque appel de l'assistant doit générer une trace dans les journaux d'audit de la plateforme, avec le profil du collaborateur, l'heure, la ressource consultée, et le périmètre de données retourné. Ces journaux doivent être accessibles à vos équipes de conformité avec la même granularité que les journaux des actions humaines.
Cette journalisation est rarement un problème technique. La plupart des plateformes métiers tracent déjà toutes les requêtes API. Le problème est plutôt opérationnel : qui analyse ces journaux, à quelle fréquence, et avec quel outil. Si vos équipes n'ont jamais consulté les journaux d'audit de l'ERP, elles ne consulteront pas non plus ceux de l'assistant. Brancher une IA est une bonne occasion de mettre en place les processus de suivi que vous auriez dû avoir depuis longtemps.
Fraîcheur des données : ce que vous acceptez comme décalage, et pour quels usages
L'architecture connectée garantit que l'assistant lit des données à jour au moment de la question. Cela ne signifie pas que toutes les questions exigent cette garantie.
Certains usages tolèrent un décalage. Un assistant qui répond à des questions sur les politiques internes de l'entreprise peut travailler sur une copie de la documentation mise à jour une fois par mois. Un assistant qui aide les collaborateurs à comprendre un catalogue produit peut indexer ce catalogue toutes les nuits sans risque opérationnel. Dans ces cas, une copie parallèle simplifie l'intégration sans créer de fuite de droits, parce que les données indexées sont publiques au sein de l'entreprise.
D'autres usages ne supportent aucun décalage. Un assistant qui répond à des questions sur l'état d'avancement d'un projet doit interroger le système de suivi en temps réel, parce qu'une information périmée peut conduire à une décision erronée. Un assistant qui extrait les factures en attente de validation doit lire les données au moment de la requête, parce qu'une facture peut avoir été validée dix minutes plus tôt.
La règle pratique : si l'assistant restitue des données qui influencent une décision opérationnelle, il doit interroger la plateforme en temps réel. Si l'assistant restitue des données de référence ou de documentation, un décalage de quelques heures ou de quelques jours est acceptable. Si l'assistant manipule des données personnelles ou sensibles, la fraîcheur est secondaire par rapport au respect des droits d'accès : dans ce cas, la connexion en temps réel est obligatoire même si le décalage serait tolérable.
Les trois questions à poser au prestataire avant la démonstration
Quand un prestataire vous présente une solution d'assistant IA, posez trois questions avant d'aller plus loin.
Première question : où sont stockées nos données pendant que l'assistant les utilise ? Si la réponse mentionne un index séparé, un data lake, ou une base vectorielle hébergée par le prestataire, demandez comment le modèle de droits de votre plateforme est répliqué dans cet index. Si la réponse est floue ou si le prestataire parle de filtres par département, considérez que vous êtes en train de perdre vos habilitations.
Deuxième question : comment l'assistant s'authentifie-t-il auprès de nos systèmes métiers ? Si l'assistant utilise un compte de service unique avec des droits élevés pour interroger toutes les données, puis filtre les réponses en fonction du collaborateur qui pose la question, cette architecture introduit un risque. Un bug dans le filtrage, une faille dans le code de l'assistant, ou une attaque sur la session de l'assistant expose toutes les données accessibles par ce compte de service.
La réponse sûre : l'assistant formule chaque requête avec le profil du collaborateur qui pose la question, en utilisant un jeton d'authentification délégué ou un mécanisme d'impersonation géré par votre plateforme. Si le prestataire n'a jamais entendu parler d'OAuth delegated access ou de service account impersonation, considérez que son architecture n'est pas compatible avec un SI d'entreprise.
Troisième question : comment traçons-nous les consultations réalisées par l'assistant ? Si la réponse est que le prestataire vous fournira des journaux de son côté, ces journaux ne seront jamais audités par vos équipes de conformité, parce qu'ils ne sont pas dans le même outil que les journaux de votre plateforme métier. La réponse sûre : toutes les consultations de l'assistant génèrent des traces dans les journaux d'audit de votre ERP, de votre CRM, de votre GED, exactement comme les consultations humaines.
Ce qui reste hors de portée d'un assistant, et pourquoi c'est un bon signe
Un assistant connecté de façon sûre ne peut répondre qu'aux questions dont les données sont accessibles via les API de votre plateforme, dans le périmètre de droits du collaborateur qui pose la question. Cela laisse beaucoup de cas hors de portée.
Un assistant ne peut pas répondre à une question sur un document qui n'a pas été versé dans la GED. Si un collaborateur garde un contrat fournisseur en local sur son poste, l'assistant ne le verra jamais. Cela peut sembler une limitation, mais c'est en réalité une incitation à centraliser les documents dans des systèmes traçables.
Un assistant ne peut pas répondre à une question qui demande d'agréger des données provenant de plusieurs systèmes métiers si ces systèmes n'exposent pas d'API. Par exemple, croiser les factures de l'ERP avec les projets du CRM et les demandes d'achat du système de gestion des achats. Cette limitation force à construire les interfaces programmatiques manquantes ou à accepter que certaines questions restent hors de portée.
Un assistant ne peut pas contourner les droits d'accès pour répondre à une question posée par un collaborateur qui n'a pas les habilitations nécessaires. Si un responsable d'équipe demande à l'assistant de lui montrer les contrats signés par la direction générale, et que ce responsable n'a pas accès à ces contrats dans l'ERP, l'assistant refusera de répondre. Cette limitation protège votre modèle de droits, mais elle peut frustrer les collaborateurs qui s'attendent à ce qu'un assistant IA soit omniscient.
Ces limitations sont des indicateurs de qualité. Un prestataire qui vous présente un assistant capable de répondre à toutes les questions, y compris sur des données que vous ne gérez pas de façon centralisée, est en train de vous vendre une copie parallèle qui contourne vos droits. Un prestataire qui vous dit dès le début ce que l'assistant ne pourra pas faire est en train de vous proposer une architecture respectueuse de vos contraintes de sécurité et de conformité.
FAQ
Si on branche un assistant IA sur nos données via les API, est-ce que les temps de réponse restent acceptables pour un utilisateur ?
Les temps de réponse dépendent de la performance de vos API et de la complexité de la question posée. Une question qui interroge une seule ressource (par exemple, "donne-moi la liste des factures en attente") peut être résolue en une à deux secondes si l'API de votre ERP répond rapidement. Une question qui demande d'agréger des données provenant de plusieurs systèmes (par exemple, "combien avons-nous dépensé sur le projet X entre janvier et mars") peut prendre cinq à dix secondes si l'assistant doit appeler plusieurs API puis reconstruire un résultat global. Ces délais sont supérieurs à ceux d'un index vectoriel qui retourne une réponse en moins d'une seconde, mais ils restent acceptables pour des usages professionnels où la fiabilité et la traçabilité comptent plus que la rapidité brute.
Comment gérer le cas d'un collaborateur qui a besoin d'un accès temporaire à des données sensibles ?
L'architecture connectée résout ce cas naturellement. Vous accordez au collaborateur un accès temporaire via votre plateforme métier, avec une date d'expiration. Tant que l'accès est actif, l'assistant pourra répondre aux questions du collaborateur en incluant ces données. Dès que l'accès expire, l'assistant cessera de les inclure dans les réponses, parce que l'API filtrera ces données au moment de la requête. Aucune intervention manuelle sur l'assistant n'est nécessaire, et aucune copie parallèle ne conserve les données après expiration de l'accès.
Est-ce qu'un assistant connecté aux API peut encore fonctionner si l'un des systèmes métiers tombe en panne ?
Non, et c'est une conséquence assumée de l'architecture. Si votre ERP est indisponible, l'assistant ne pourra pas répondre aux questions qui demandent des données de l'ERP. En revanche, il pourra toujours répondre aux questions qui ne sollicitent que le CRM ou la GED, parce que ces systèmes sont toujours en ligne. Cette dépendance est la même que celle de vos applications métiers : si l'ERP est en panne, les utilisateurs humains ne peuvent pas non plus accéder aux données de l'ERP. Un assistant qui continue de fonctionner pendant une panne d'un système métier est forcément en train de lire une copie périmée, ce qui peut être pire qu'une absence de réponse.
Quel est le coût d'intégration d'un assistant connecté aux API, par rapport à un assistant sur index séparé ?
Le coût initial est plus élevé si vos systèmes métiers n'ont pas d'API documentées ou si votre modèle de droits n'est pas exposé de façon programmatique. Il faut alors construire ces interfaces, ce qui peut représenter plusieurs semaines de développement. En revanche, ces interfaces servent aussi toutes les autres intégrations futures : applications mobiles, tableaux de bord décisionnels, synchronisations inter-systèmes. Le coût d'intégration d'un assistant sur index séparé est faible au début (quelques jours pour extraire les données et remplir l'index), mais il génère une dette technique permanente : chaque modification de votre modèle de droits doit être répliquée dans l'index, chaque nouveau système métier doit être extrait et segmenté, et vous n'avez aucune traçabilité unifiée.
Comment savoir si notre plateforme métier expose déjà les API nécessaires pour brancher un assistant de façon sécurisée ?
Consultez la documentation technique de votre ERP, de votre CRM, et de votre GED. Si ces systèmes sont des solutions SaaS récentes (Salesforce, HubSpot, Microsoft Dynamics 365, SAP S/4HANA Cloud), ils ont presque certainement une API REST bien documentée. Si vous utilisez des versions on-premise ou des systèmes legacy, vérifiez auprès de vos équipes IT si une couche d'API a été construite en interne. Si aucune API n'existe, le projet d'assistant IA devient aussi un projet de modernisation de votre SI, ce qui peut être une opportunité pour régler des dettes techniques qui bloquent d'autres intégrations.
Vous voulez connecter un assistant IA à votre système d'information sans perdre le contrôle de vos données ? ClaroDigi vous aide à auditer votre SI, à identifier les API manquantes, et à concevoir une architecture d'intégration sécurisée. Explorez l'intégration API pour l'IA, consultez notre approche de l'intégration systèmes, ou découvrez nos services de transformation IA.