Passer au contenu principal

Documentation Index

Fetch the complete documentation index at: https://docs.fim.ai/llms.txt

Use this file to discover all available pages before exploring further.

​
Aperçu

Les organisations sont l’unité de collaboration d’équipe de FIM One. Elles permettent aux groupes d’utilisateurs de partager des ressources — Agents, Connecteurs, Bases de connaissances, Serveurs MCP, Workflows et Compétences — dans un périmètre de confiance. Chaque ressource dans FIM One commence comme personnelle (visible uniquement pour son créateur). Lorsque vous publiez une ressource dans une organisation, elle devient découvrable par les autres membres de l’organisation via le périmètre d’organisation du Marché. Les membres parcourent les ressources partagées de l’organisation et s’abonnent à celles dont ils ont besoin. Les organisations et le Marché mondial partagent le même modèle d’accès basé sur l’abonnement. La différence clé est la confiance : les organisations représentent une équipe ou une entreprise où les membres se connaissent et se font confiance, donc l’examen est facultatif et le partage des identifiants est simple.

​
Création et gestion des organisations

Chaque utilisateur peut créer des organisations illimitées et rejoindre un nombre quelconque d’entre elles. Une organisation dispose de trois rôles :
RôlePermissions
PropriétaireContrôle total — gérer les membres, configurer les paramètres, contourner l’examen
AdministrateurGérer les membres et examiner les ressources publiées
MembreParcourir et s’abonner aux ressources partagées
Le propriétaire est toujours l’utilisateur qui a créé l’organisation. La propriété peut être transférée mais non partagée.

​
Publication de ressources

Lorsque vous publiez une ressource dans votre organisation, elle n’apparaît pas automatiquement dans l’espace de travail de chaque membre. Au lieu de cela, la ressource devient découvrable dans l’étendue organisation du Marché, où les membres peuvent la parcourir et s’y abonner. Ce modèle basé sur l’abonnement donne à chaque membre le contrôle sur son espace de travail. Une grande organisation peut partager des dizaines de connecteurs, mais un membre individuel ne s’abonne qu’à ceux pertinents pour son travail.

​
Système d’examen

L’examen est optionnel et configuré par type de ressource. Chaque organisation dispose de drapeaux de basculement indépendants :
  • review_agents
  • review_connectors
  • review_kbs
  • review_mcp_servers
  • review_workflows
  • review_skills
Lorsque l’examen est désactivé pour un type de ressource, les ressources publiées sont immédiatement découvrables par les membres — aucune action d’administrateur n’est nécessaire. Lorsque l’examen est activé, les ressources entrent dans un état pending_review et nécessitent l’approbation d’un administrateur avant de devenir visibles.
Les propriétaires d’organisation contournent automatiquement l’examen. Leurs ressources publiées sont toujours immédiatement découvrables.
Cette flexibilité permet aux organisations d’adapter leurs besoins de gouvernance. Une petite startup pourrait désactiver tous les drapeaux d’examen pour un partage sans friction, tandis qu’une entreprise axée sur la conformité active l’examen sur les Agents et Connecteurs pour maintenir une supervision.

​
Mécanisme de secours des identifiants

Les connecteurs et les serveurs MCP nécessitent souvent des identifiants (clés API, mots de passe de base de données, jetons OAuth). FIM One fournit un mécanisme de secours pour que les membres n’aient pas à configurer chaque identifiant eux-mêmes. Il existe deux modes :
  • Mécanisme de secours activé (allow_fallback=true, par défaut) : Les membres qui ne fournissent pas leurs propres identifiants utilisent automatiquement les identifiants par défaut du propriétaire. Cela fonctionne bien pour les clés API partagées par l’équipe ou les services internes où une seule clé couvre toute l’équipe.
  • Mécanisme de secours désactivé (allow_fallback=false) : Chaque membre doit configurer ses propres identifiants. Ceci est approprié lorsque chaque utilisateur a besoin d’une clé API personnelle (par exemple, les licences SaaS par siège).
Les ressources qui ne nécessitent pas d’identifiants — comme un connecteur API public en lecture seule ou un Agent sans authentification — fonctionnent immédiatement après l’abonnement. Aucune configuration nécessaire.
Le mécanisme de secours des identifiants s’applique uniquement après qu’un membre s’abonne à la ressource. Le mécanisme de secours détermine comment les identifiants sont résolus à l’exécution, non si la ressource est accessible.

​
Visibilité des ressources

Chaque ressource dans FIM One a une visibility qui détermine sa portée d’accès :
VisibilitéPortéeQui peut la découvrir
personalPropriétaire uniquementL’utilisateur qui l’a créée
orgOrganisationLes membres de l’organisation peuvent parcourir et s’abonner (si approuvé)
Le filtre de visibilité suit un modèle de requête unifié : 
A resource is available in your workspace if:
  1. You own it (any visibility), OR
  2. It's published to an org you belong to, approved, AND you've subscribed to it
Publier une ressource dans une organisation n’accorde pas d’accès automatique. Les membres doivent s’abonner via la portée org du Marché pour ajouter la ressource à leur espace de travail.

​
Ressources d’infrastructure (à l’échelle de l’organisation, sans abonnement)

Une deuxième classe de ressource à l’échelle de l’organisation ne suit pas le cycle de vie personnel → publier → s’abonner décrit ci-dessus. Ces ressources sont configurées une seule fois par un propriétaire d’organisation ou un administrateur et ensuite disponibles de manière transparente pour chaque agent de l’organisation :
RessourceObjectifConfigurée parConsommée par
ChannelsPont sortant vers une plateforme de messagerie instantanée (Feishu aujourd’hui ; Slack / WeCom / Teams prévus)Propriétaire d’organisation / AdministrateurSystème de Hook de chaque agent et outils de notification proactive
Fournisseurs OAuthIdentifiants de connexion sociale (GitHub, Google, Feishu, Discord)Administrateur système (variables d’environnement)Page de connexion
Clés APIJetons d’accès programmatique pour les clients sans interfaceChaque utilisateur, à l’échelle de l’organisationIntégrations externes
La distinction clé : les ressources publiables (Agents, Connecteurs, BCs, …) sont des artefacts par utilisateur qui nécessitent un abonnement explicite des membres ; les ressources d’infrastructure (Channels, OAuth, clés API) sont le câblage au niveau de la plateforme que tous les agents partagent implicitement. Les Channels en particulier sont la ligne directe de messagerie instantanée pour toute l’organisation — un seul channel Feishu bien maintenu soutient la porte d’approbation de chaque agent, chaque rapport planifié, chaque événement d’escalade. Consultez Aperçu des Channels pour le cycle de vie des channels et les plateformes prises en charge.

​
Scénarios Pratiques

​
Partage d’un connecteur de base de données en équipe

  1. Alice crée un connecteur vers la base de données PostgreSQL de l’équipe
  2. Alice le publie dans l’org de son équipe (l’examen est désactivé pour les connecteurs)
  3. Le connecteur devient découvrable dans la portée org de la Market
  4. Bob parcourt les ressources partagées de l’org, trouve le connecteur et s’y abonne
  5. Le connecteur apparaît dans l’espace de travail de Bob, en utilisant les identifiants de base de données d’Alice comme solution de secours
  6. Carol s’y abonne aussi. Dave (un entrepreneur externe) s’y abonne et configure ses propres identifiants en lecture seule à la place

​
Organisation avec examen strict

  1. Une entreprise axée sur la conformité active review_agents=true et review_connectors=true sur son organisation
  2. Quand un employé publie un nouvel Agent, il entre dans l’état pending_review
  3. Un administrateur de l’organisation examine la configuration de l’Agent et l’approuve
  4. L’Agent devient découvrable — les autres membres peuvent maintenant le trouver et s’y abonner
  5. Si l’éditeur modifie ultérieurement l’Agent approuvé, il revient automatiquement à pending_review pour une nouvelle approbation

​
Abonnement sélectif dans une grande organisation

  1. Une organisation publie 50+ connecteurs couvrant les API internes, les bases de données et les services tiers
  2. L’équipe data s’abonne uniquement aux connecteurs de bases de données et aux API d’analyse
  3. L’équipe marketing s’abonne uniquement aux connecteurs CRM et plateforme email
  4. L’espace de travail de chaque membre de l’équipe reste concentré et organisé

​
Voir aussi

  • Architecture du Marché — Pour le Marché global et sa relation avec les organisations. Les deux utilisent le même modèle d’abonnement, mais le Marché sert de canal de découverte inter-organisations avec révision obligatoire.
  • Découverte d’agents et de ressources — Comment les ressources abonnées sont assemblées en ensembles d’outils lors du chat.