> For the complete documentation index, see [llms.txt](https://library.zoom.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://library.zoom.com/technical-library/fr/ai/ai-whitepaper/agentic-search.md).
# Recherche agentique
## **Qu'est-ce que la recherche agentique ?**
#### Agentic Search est une couche de contexte unifiée et tenant compte des Autorisation, qui couvre le contenu Zoom et les sources de données Entreprise connectées
La recherche agentique est une capacité de récupération de connaissances de niveau Entreprise qui collecte, indexe et met en corrélation des informations pertinentes provenant de contenus natifs Zoom et de sources de données tierces connectées, pour former un seul ensemble de connaissances organisationnelles auquel une requête répond. Ce qui la distingue de la recherche conventionnelle, c’est l’ampleur de ce qu’une seule requête peut mobiliser : une transcription de réunion, un message Team Chat et un document hébergé dans un lecteur cloud d’entreprise peuvent tous contribuer au même résultat. La forme de ce résultat dépend du point d’entrée — une réponse synthétisée en langage naturel, ou un ensemble classé de sources étayées sur lequel un autre modèle peut raisonner — mais les sources couvertes, et les autorisations appliquées à celles-ci, ne changent pas.
Dans Zoom, la récupération s’étend à l’enregistrer du travail qui s’accumule déjà sur la plateforme — réunion enregistrer et transcriptions, résumés de réunion, conversations Team Chat, ainsi que les documents, notes et autres artefacts créés en parallèle. Au-delà de Zoom, la récupération s’étend à des systèmes d’enregistrer et des référentiels de contenu connectés, qui peuvent inclure des services tels que Salesforce, Google Drive, OneDrive, SharePoint, Confluence, Box, ServiceNow, Workday, Zendesk et Seismic. Lorsque l’indexation est prise en charge et activée, le contenu de ces systèmes est importé dans la couche de récupération de Zoom avec les informations natives de Zoom, de sorte qu’une question se résout par rapport à un seul ensemble de connaissances organisationnelles plutôt qu’à une série de référentiels isolés que chacun doit être recherché selon ses propres modalités.
La récupération est sensible à l’Autorisation tout au long du processus. Les contrôles d’Access de chaque système source sont hérités et appliqués, de sorte que les informations exposées — natives de Zoom ou tierces — sont limitées en fonction des Autorisation applicables de l’utilisateur demandeur ou de l’agent. L’élargissement de l’ensemble des sources interrogeables n’élargit pas l’accessibilité de quiconque à celles-ci.
#### "Agentic Search" décrit une capacité, pas une interface
Agentic Search est mieux compris comme une capacité sous-jacente plutôt que comme un écran ou un bouton spécifique. Cette même capacité est accessible de plusieurs façons : via l’interface ZoomMate pour les utilisateurs quotidiens, et via les API Search et Ask ainsi que le Model Context Protocol (MCP) pour les applications et les agents IA. Quel que soit le point d’entrée utilisé, le terme désigne la même fonction fondamentale : récupérer et synthétiser des informations pertinentes à travers différentes sources.
#### ZoomMate utilise Agentic Search pour récupérer des données indexées à partir des connaissances organisationnelles connectées, puis synthétise les résultats en une réponse en langage naturel
Pour les utilisateurs quotidiens, ZoomMate est l’endroit où la recherche agentique devient routinière. Préparer une réunion à venir, se rappeler une décision prise lors de plusieurs réunions passées ou retrouver un document lié à un élément d’action ouvert peut être résolu en une seule requête, plutôt que de nécessiter des recherches distinctes dans les réunions, les chats, les documents, le stockage sur le cloud et les systèmes CRM ou de billetterie.
#### MCP et les API Search et Ask étendent la même récupération aux applications et aux agents d’IA externes
Les applications et les agents IA externes, y compris ceux construits sur des LLM tiers, font appel à Agentic Search comme outil via MCP. Les contrôles d’Access accompagnent l’appel, de sorte qu’un agent récupère des informations conformes aux permissions de l’utilisateur authentifié.
Le **API de recherche** renvoie un ensemble classé de résultats pertinents et laisse la génération au propre modèle de l’appelant, ce qui convient aux cas où le matériau source brut et fondé est le résultat souhaité.
Le **API Ask** effectue à la fois la récupération et la génération dans Zoom, en renvoyant une réponse synthétisée et sourcée en langage naturel.
#### Un index permanent et une récupération à la demande maintiennent à jour les données qui changent fréquemment
Agentic Search n’est pas limité à un index statique. Le contenu est vectorisé, indexé et doté de mots-clés, avec du contenu tiers approuvé intégré via une synchronisation incrémentale à portée admin pour une récupération ultérieure efficace. Les données qui changent fréquemment, ou qui bénéficient d’une fraîcheur à la demande, peuvent à la place être interrogées directement via MCP ou des connexions temps réel équivalentes plutôt qu’être servies depuis l’index.
Ensemble, l’index permanent et la récupération à la demande signifient que la couche de contexte reflète l’état actuel des systèmes connectés plutôt que leur état lors de la dernière synchronisation.
## **Sources de données et indexation**
#### L’architecture d’indexation de Zoom est spécialement conçu-es pour la récupération par IA conversationnelle
L’architecture d’indexation de Zoom est spécialement conçu-es pour l’IA conversationnelle, en utilisant la recherche vectorielle, le découpage du contenu et un schéma conçu autour de la manière dont les systèmes conversationnels récupèrent le contexte. De nombreuses technologies de recherche d’Entreprise et de graphe ont été à l’origine conçues autour d’un objectif différent : la connexion des documents, des personnes, des métadonnées et d’autres entités dans un environnement de productivité. Cette différence architecturale compte, car l’IA conversationnelle doit identifier et récupérer les éléments d’information qui sont sémantiquement pertinents pour la question d’un utilisateur, plutôt que de naviguer principalement entre les relations entre des documents ou des entités. L’approche de Zoom structure et indexe le contenu autour de ce modèle de récupération, faisant des cas d’usage conversationnels une considération architecturale centrale plutôt qu’une capacité superposée à un système conçu pour un autre objectif.
Autrement dit : c’est la différence entre indexer une bibliothèque par livre individuel et l’indexer par les passages dont quelqu’un pourrait réellement avoir besoin pour répondre à une question.
#### Les connecteurs tiers étendent la couche de contexte de Zoom aux systèmes tiers autorisés, sous réserve d’une activation par admin
Agentic Search prend en charge l’indexation à partir de connecteurs tiers autorisés, notamment Google Drive, OneDrive, Box, Salesforce, ServiceNow, Zendesk, Seismic, Confluence et SharePoint, avec des connecteurs supplémentaires disponibles selon l’état actuel de la version. Le fait qu’un connecteur soit disponible ne signifie pas que son contenu soit automatiquement interrogeable — chaque source doit être activée par un administrateur avant qu’Agentic Search puisse commencer à l’ingérer. Ce modèle contrôlé par admin est délibéré : il est conçu pour maintenir le périmètre d’indexation aligné sur ce qu’une organisation a réellement autorisé, plutôt que d’exposer par défaut tous les systèmes connectables.
#### Comment fonctionne l’indexation : de l’ingestion à un index interrogeable
Lorsqu’un connecteur est activé, Agentic Search construit un index interrogeable du contenu approuvé plutôt que d’interroger à nouveau le système source pour chaque requête. Le processus passe par plusieurs étapes :
1. **Ingestion** — Le contenu approuvé est récupéré depuis la source connectée, dans la limite du périmètre qu’un administrateur a autorisé et selon les autorisations de connexion des utilisateurs. Pour les sources basées sur des fichiers, comme les lecteurs cloud, le contenu du document est récupéré pour traitement plutôt que simplement lié.
2. **Segmentation** — Le contenu récupéré est découpé en passages plus petits afin que la récupération puisse renvoyer la portion spécifique pertinente d'un document, plutôt que des fichiers entiers.
3. **Vectorisation** — Chaque passage est converti en un vecteur de plongement numérique à l'aide d'un modèle de plongement, ce qui permet à la récupération de faire correspondre le sens et pas seulement le libellé exact.
4. **Indexation par mots-clés** — Le contenu est également indexé pour la correspondance par mots-clés. Les fonctionnalités Search et Ask dépendent à la fois des correspondances de mots-clés et de la similarité vectorielle, de sorte que les deux approches fonctionnent ensemble plutôt que comme des alternatives.
5. **Indexation des métadonnées d'Autorisation** — Les informations d'accès de l'utilisateur sont indexées avec le contenu, à partir de l'Autorisation native du système source, afin qu'un filtrage tenant compte de l'Autorisation puisse être appliqué au moment de la requête.
Le résultat est un index de récupération spécifique au client — le contenu provenant d'une source est stocké dans un format limité à ce client et régi par l'Autorisation de ce client, plutôt que dans un stockage partagé ou inter-locataires.
#### Des diagrammes et des flux de données sont Disponible pour référence
Des diagrammes illustrant comment la recherche agentique de Zoom se connecte à des applications, services et sources de données tierces — y compris les flux de données de connexion et d'indexation — sont Disponible dans le [Livre blanc Zoom AI](https://library.zoom.com/ai/ai-whitepaper/diagrams#zoommate-third-party-connections-and-indexing).
#### Ce qui est indexé est régi par la portée qu'un administrateur autorise pour le Connecteur
Le contenu qui est indexé est régi par la portée qu'un administrateur autorise pour le Connecteur. Une fois qu'une source est connectée, l'index est maintenu grâce à des mises à jour continues plutôt qu'à une ingestion unique :
1. **Synchroniser initiale**: Lors de la configuration initiale, le Connecteur effectue une synchronisation complète du contenu dans le périmètre, y compris le contenu historique existant.
2. **Mise à jour d'indexation quotidienne**: Pour certaines sources, le Connecteur actualise le contenu dans le périmètre une fois par jour.
3. **Synchroniser incrémentale**: Pour d'autres, le Connecteur exécute des synchronisations périodiques tout au long de chaque journée qui traitent uniquement le contenu ajouté, modifié ou changé depuis la dernière synchronisation, plutôt que de retraiter à chaque fois l'ensemble du référentiel.
#### La récupération indexée et la récupération en temps réel fonctionnent ensemble
Agentic Search utilise deux chemins de récupération, et celui qui s’applique est déterminé par la manière dont une source est connectée et par le type de données qu’elle contient — et non par un paramètre par requête ou par dossier qu’un utilisateur ou un admin active.
Le contenu connecté en tant que **source de données au niveau du compte** dans le panel admin est ingéré dans un index spécifique au Client et recherché à partir de là. C’est le chemin par défaut pour le contenu non structuré — documents, articles de connaissance et fichiers — car un index préconstruit rend la récupération rapide et efficace au moment de la requête, et il produit un index consultable partagé dans toute l’organisation.
Le contenu est accessible **directement, en temps réel, via MCP ou une API** dans les autres cas : des Connecteurs personnels qu’un utilisateur individuel autorise (comme son propre e-mail, calendrier ou option de stockage sur le cloud personnelle), des enregistrements structurés comme des données d’objet CRM, et d’autres contenus qui changent assez fréquemment pour tirer parti d’une fraîcheur au moment de la requête. Un Connecteur personnel récupère uniquement les documents auxquels l’utilisateur de connexion peut accéder, et les connexions de données structurées conservent leur propre authentification et autorisation utilisateur plutôt que d’être servies depuis l’index.
Parce que le chemin suit la connexion, la même application sous-jacente peut être atteinte dans les deux sens selon sa configuration. Un service d’option de stockage sur le cloud connecté en tant que source de données gérée par un admin est indexé pour une recherche à l’échelle de l’organisation, tandis que le même service connecté comme Connecteur personnel d’un individu est interrogé directement et limité à l’accès propre à cet utilisateur.
#### Les connexions externes d’Agentic Search sont basées sur le Model Context Protocol (MCP)
Les connexions entre Zoom et des modèles, outils et sources de données externes sont basées sur le Model Context Protocol (MCP), une norme client-serveur ouverte pour relier les modèles aux outils et aux données. Les serveurs MCP fonctionnent à la périphérie de Zoom, fournissant une interface cohérente par laquelle les requêtes de récupération sont effectuées — à la fois pour la récupération en temps réel depuis les systèmes connectés et pour les agents externes qui accèdent à Agentic Search en tant qu’outil. Ce transport standardisé remplace les intégrations ponctuelles, source par source, par un modèle de connexion commun.
#### La durée d’indexation varie selon le client, le volume de données et le type de données
Il n’existe pas de délai fixe pour le temps nécessaire à un Connecteur donné pour être entièrement indexé. Le temps requis varie selon chaque client, en fonction de la quantité de données indexées et du type de données concerné. Les limites de débit imposées par la plateforme tierce indexée sont un facteur contributif — chaque système source limite la quantité de données pouvant être extraite dans une fenêtre donnée, et cette limitation varie selon la plateforme, le niveau de plan et la conception de l’API. Les clients qui prévoient une première indexation d’un dépôt volumineux ou très utilisé doivent s’attendre à un délai de plusieurs semaines plutôt qu’à un résultat dans la journée ou la semaine.
#### La capacité d’indexation évolue avec le niveau de licence ZoomMate et est mutualisée au niveau de l’organisation
La capacité d’indexation dépend du niveau de licence plutôt que d’une allocation universelle fixe. Chaque Détenteur de licence contribue à une capacité par siège selon son niveau, et ces montants se combinent en un pool unique à l’échelle de l’organisation, partagé dans toute l’organisation plutôt que réparti entre chaque utilisateur individuel.
Le volume total de contenu indexé sur toutes les sources connectées et pour tous les utilisateurs doit rester dans le pool combiné de l’organisation — ce qui signifie qu’un utilisateur qui indexe un vaste dépôt puise dans la même capacité partagée disponible pour tous les autres. Comme le pool augmente avec chaque siège de licence, la capacité totale d’une organisation est la somme de ce que contribuent tous ses utilisateurs Détenteur de licence.
Par exemple, si une licence accorde 1 Go de stockage, avec 25 licences, le compte dispose d’un total de 25 Go de stockage. Avec 100 utilisateurs, 100 Go.
Les organisations qui prévoient d’indexer de grands dépôts (un espace Confluence complet, un grand site SharePoint, une instance CRM mature) doivent dimensionner leur niveau de licence et leur nombre de sièges en fonction du volume total de contenu attendu, et non des schémas d’utilisation par utilisateur. Une capacité d’index supplémentaire est disponible — contactez votre équipe de compte Zoom pour plus d’informations.
#### La taille du fichier et le type de fichier influencent tous deux ce qui est indexé
Deux limites de taille distinctes s’appliquent, et elles se comportent différemment :
* **Limite de 64 Mo pour le fichier d’origine (téléchargement) :** Si la taille d’origine d’un fichier source dépasse 64 Mo, il est ignoré et n’est pas téléchargé pour traitement.
* **Limite de 16 Mo pour le contenu traité (indexation) :** Les fichiers téléchargés sont convertis dans un format de traitement unifié. Si le fichier traité résultant dépasse 16 Mo, seuls les premiers 16 Mo de son contenu sont indexés ; le reste ne l’est pas.
Les deux limites échouent différemment : un original trop volumineux est entièrement ignoré, tandis qu’un fichier traité trop volumineux est tronqué plutôt qu’exclu, de sorte que son contenu d’ouverture apparaît toujours dans la récupération alors que le contenu ultérieur n’y apparaît pas.
Par ailleurs, l’indexation dépend du type de fichier, indépendamment de la taille. Le contenu multimédia — audio, vidéo et images — n’est pas indexé, quelle que soit sa taille. Il est supprimé lors de la conversion vers le format de traitement unifié, avant même l’évaluation de l’une ou l’autre limite de taille. Les métadonnées sont indexées pour tous les documents, mais le contenu intégral n’est indexé que pour les types de fichiers pris en charge et non multimédias. Pour les types non pris en charge, le document reste खोजable grâce à ses métadonnées, mais son contenu n’est pas consultable.
#### Les admins ne peuvent actuellement pas contrôler l’ordre dans lequel le contenu est indexé
Il n’existe actuellement aucun mécanisme permettant à un administrateur de prioriser certains dossiers, espaces ou types de contenu afin qu’ils soient indexés avant d’autres au sein d’une source connectée. L’indexation progresse sur le contenu éligible dans un Connecteur activé sans possibilité de séquencement, ce qui signifie que les organisations ne peuvent pas mettre en avant l’indexation de leur contenu le plus précieux et doivent s’attendre à ce que la couverture d’indexation se construise progressivement sur l’ensemble du dépôt plutôt que de commencer par le matériel le plus critique pour l’entreprise.
L’indexation ne peut pas non plus être planifiée pour s’exécuter à une heure ou selon une cadence choisie. Une fois qu’une source est activée, l’indexation s’exécute selon son propre rythme plutôt que selon un planning défini par un administrateur ; il vaut donc mieux la considérer comme un processus d’arrière-plan qui se termine lorsqu’il se termine, plutôt que comme un processus qu’on peut caler sur une fenêtre spécifique.
## **Administration, Autorisation et gouvernance**
#### Les administrateurs peuvent contrôler quelles sources sont connectées, et les utilisateurs authentifient leur propre accès
Les Connecteurs sont activés par un administrateur, qui détermine quels systèmes tiers sont disponibles pour l’indexation et la recherche au sein de l’organisation. L’activation d’un Connecteur rend une source disponible pour l’organisation, mais ne donne pas intrinsèquement accès à son contenu. Chaque utilisateur doit authentifier son accès à la source individuellement — une fois authentifié, ses Autorisation de récupération s’alignent sur ses Autorisations existantes dans le système source, de sorte qu’il ne peut afficher que ce à quoi il pouvait déjà accéder là-bas.
#### La récupération est sensible aux autorisations (Autorisation) et en lecture seule
Agentic Search est conçu pour appliquer les contrôles d’accès de chaque système source, de sorte que les réponses reflètent uniquement le contenu que l’utilisateur est déjà autorisé à voir ; deux utilisateurs posant la même question peuvent recevoir des résultats différents selon leurs Autorisations respectives dans la source de données tierce. La récupération est en lecture seule et suit les politiques de conservation de chaque source — par exemple, le contenu de réunion Zoom suit sa période de conservation applicable plutôt que d’être conservé séparément par la couche de recherche. Parce que la récupération est gouvernée et sensible aux autorisations au moment de la requête, elle offre aussi une alternative à l’exportation en masse de transcriptions ou d’enregistrements bruts, en maintenant l’accès aligné sur la source tierce d’origine.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://library.zoom.com/technical-library/fr/ai/ai-whitepaper/agentic-search.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.