Concepts clés

Abra tient sur une poignée de concepts. Une fois qu’ils sont clairs, tout le reste de la plateforme se lit sans effort : créer un assistant, le connecter à vos outils, automatiser une tâche, ouvrir un agent à vos clients. Cette page est le glossaire de référence — un concept par section, chacun expliqué en trois temps : ce que c’est, pourquoi ça existe, et comment il se relie aux autres, avec à chaque fois un mini-exemple concret.

Pas besoin d’être technique pour la lire : elle s’adresse aux utilisateurs métier, aux administrateurs d’organisation et aux intégrateurs.

Vue d’ensemble

Tout part de votre organisation. À l’intérieur, des membres (avec un rôle chacun) sont regroupés en équipes. Ces personnes utilisent des agents IA et des workflows. Un agent, lui, se compose de trois ingrédients : un modèle (le cerveau), des outils (ce qu’il sait faire), et une base de connaissances (ce qu’il sait). Les outils, à leur tour, puisent dans vos connecteurs (Google, Microsoft, Slack…) et dans vos workflows. Enfin, un agent prêt peut être publié hors d’Abra — sur un site, par un lien, ou via une clé API.

ORGANISATION  (l'espace étanche de votre entreprise)
│
├── Membres ──(rôle)──▶ Équipes        « qui a accès à quoi »
│
├── AGENT IA
│     ├── Modèle (LLM)                 le cerveau
│     ├── Outils                       ce qu'il sait FAIRE
│     │     ├── Connaissances (RAG)  ─▶ vos documents
│     │     ├── Connecteurs         ─▶ Google / Microsoft / Slack / CRM…
│     │     ├── MCP                 ─▶ serveurs d'outils externes
│     │     ├── Exécution de code   ─▶ calculs dans un bac à sable
│     │     └── Workflows-as-tools  ─▶ déclencher un workflow
│     └── Base de connaissances        ce qu'il SAIT
│
├── WORKFLOWS & AUTOMATIONS            tâches multi-étapes (moteur d'automatisation)
│
└── PUBLICATION                        widget · lien SSO · clé API

Gardez ce schéma en tête : chaque section ci-dessous zoome sur une de ces briques.

Organisation

Ce que c’est. Une organisation est l’espace de votre entreprise dans Abra : ses membres, ses équipes, ses agents, ses workflows, ses connexions aux outils externes et ses documents. C’est le contenant de tout le reste.

Pourquoi ça existe. Parce qu’une même instance Abra peut héberger plusieurs entreprises côte à côte (mode SaaS mutualisé) ou une seule (installation dédiée). L’organisation est la frontière d’étanchéité : personne en dehors de la vôtre ne voit vos données, vos conversations ou vos secrets, et cette séparation est revérifiée à chaque requête. Rien ne fuit d’une organisation à l’autre.

Comment ça se relie. Tout ce que décrivent les autres sections vit à l’intérieur d’une organisation. Un membre, un agent, un connecteur, une clé API appartiennent toujours à une organisation et une seule.

Mini-exemple. Le cabinet « Durand & Associés » et l’agence « Studio Neo » tournent sur la même instance Abra hébergée par leur prestataire. Chacun a son propre logo, ses membres, ses agents et ses clés — et aucun des deux ne soupçonne l’existence de l’autre.

Équipe

Ce que c’est. À l’intérieur d’une organisation, une équipe est un sous-groupe de membres — par exemple « Finance », « Support » ou « Marketing ».

Pourquoi ça existe. Pour cadrer qui accède à quoi sans tout ouvrir à toute l’entreprise. Un agent, un workflow ou une base de connaissances peut être attribué à une équipe précise plutôt qu’à l’organisation entière. L’équipe est aussi l’endroit où l’on pose des budgets IA par membre.

Comment ça se relie. L’équipe fait le lien entre les membres et les ressources (agents, workflows, connaissances). Un même membre peut appartenir à plusieurs équipes, et être simple membre de l’une tout en étant responsable (manager) d’une autre.

Mini-exemple. L’agent « Juridique » n’est attribué qu’à l’équipe Legal. L’équipe Support ne le voit même pas dans sa liste d’agents — inutile de lui expliquer de ne pas s’en servir, il n’existe pas pour elle.

Membre & rôles

Ce que c’est. Un membre est une personne rattachée à une organisation. Son rôle définit ce qu’elle a le droit d’y faire. Abra distingue cinq rôles, du plus restreint au plus large, plus un rôle spécial au-dessus des organisations.

Pourquoi ça existe. Pour donner à chacun exactement les droits dont il a besoin — ni plus, ni moins — et protéger les réglages sensibles (gouvernance des modèles, connecteurs, dépense IA).

Rôle	En langage simple
Membre	Utilise et exécute les agents, workflows et automations auxquels il a accès, discute avec les agents, connecte ses propres comptes et ajoute ses documents personnels. Aucune action d’administration.
Manager	Tout ce que fait un membre, plus la gestion des équipes dont il est responsable : y ajouter/retirer des membres, leur attribuer agents et workflows, inviter de nouveaux membres — dans le périmètre de ses équipes uniquement.
Développeur	Construit et téléverse des workflows, configure les applications de connecteurs, et soumet ses créations à validation. Peut appartenir à plusieurs organisations. Ne gère ni les membres ni les réglages.
Admin d’organisation	Contrôle toute l’organisation : membres, équipes, connecteurs, agents, base de connaissances, gouvernance des modèles, réglages (SMTP, SSO, marque). Ne voit pas les autres organisations.
Admin plateforme	L’opérateur de l’instance — l’hébergeur ou l’ESN. Au-dessus des organisations : il les crée, gère la licence, le catalogue global, les tarifs des modèles et la gouvernance IA au niveau plateforme. Invisible depuis l’intérieur d’une organisation.

Comment ça se relie. Le rôle s’applique par organisation : la même personne peut être simple membre chez l’une et administratrice chez une autre. Quand plusieurs rôles se cumulent, le plus fort l’emporte. À retenir : certaines limites que vous constatez (liste des modèles disponibles, plafond mensuel de dépense IA) ne viennent pas de vous mais de l’admin plateforme — elles se discutent avec votre hébergeur.

À CAPTURER : la table d'invitation d'un membre — champ e-mail et sélecteur de rôle (membre / manager / développeur / admin) sur la page de l'organisation

Inviter un membre revient à lui attribuer un rôle : c’est ce rôle qui décide de tout ce qu’il pourra faire ensuite.

Mini-exemple. Camille est manager de l’équipe RH : elle y invite des collègues et leur ouvre l’agent « Congés ». Mais elle ne peut pas modifier la liste des modèles autorisés de l’entreprise — ça, c’est le rôle de l’admin d’organisation.

Agent IA

Ce que c’est. Un agent IA est un assistant conversationnel que vous configurez. On le définit par quatre ingrédients : un prompt système (ses instructions et sa personnalité), un ou plusieurs modèles autorisés, un jeu d’outils qu’il peut actionner, et une base de connaissances où il va chercher des réponses.

Pourquoi ça existe. Pour donner à chaque métier un assistant taillé sur mesure, qui connaît vos documents et sait déclencher vos outils — au lieu d’un chatbot générique. Chaque organisation démarre avec un agent par défaut prêt à l’emploi ; on peut en créer d’autres, spécialisés.

Comment ça se relie. L’agent est le point central : il consomme un modèle, des outils, des connecteurs et une base de connaissances (RAG). Une fois approuvé, il peut être publié hors d’Abra.

Mini-exemple. L’agent « Assistant RH » a pour instruction de répondre aux questions congés/paie/onboarding, tourne sur un modèle rapide, dispose de l’outil « base de connaissances » branché sur le règlement intérieur, et sait déclencher le workflow « demande de congé ».

Modèle (LLM) & gouvernance des modèles

Ce que c’est. Un modèle (ou LLM, large language model) est le moteur de langage qui fait « réfléchir » l’agent — par exemple ceux d’OpenAI, Anthropic, Mistral, Google Gemini, ou un modèle local (Ollama). C’est le cerveau interchangeable de l’agent.

Pourquoi la gouvernance existe. Tous les modèles n’ont ni le même coût, ni le même niveau de confidentialité, ni la même qualité. L’administrateur choisit donc une liste de modèles autorisés pour toute l’organisation : cocher un modèle l’ouvre à tous ; le retirer le rend inutilisable pour tous — y compris les agents déjà réglés dessus. On fixe aussi un modèle par défaut et une fenêtre de contexte (combien de messages récents l’agent garde en mémoire).

Comment ça se relie. Chaque agent choisit son modèle dans cette liste autorisée. La liste de l’organisation peut elle-même être restreinte par l’admin plateforme : le résultat effectif est l’intersection des deux — vous pouvez resserrer, jamais élargir au-delà de ce que l’opérateur permet.

Mini-exemple. L’entreprise autorise trois modèles seulement, pour maîtriser coût et confidentialité. Un développeur qui essaie d’en choisir un quatrième pour son agent ne le voit tout simplement pas proposé.

Outils

Ce que c’est. Les outils sont ce qu’un agent sait faire au-delà de parler. Sans outils, un agent ne fait que discuter ; avec des outils, il agit — il cherche, calcule, lit vos documents, envoie un e-mail, déclenche un processus. Abra propose plusieurs familles d’outils :

Connaissances (RAG) — interroger vos documents pour répondre avec vos informations à jour (voir RAG / base de connaissances).
Connecteurs — agir dans vos applications externes : lire un mail, écrire dans un tableur, poster sur Slack… (voir Connecteur).
MCP (Model Context Protocol) — un standard qui branche des serveurs d’outils externes sur vos agents. L’administrateur active des serveurs MCP depuis un catalogue (ou en ajoute un interne via son URL), et chaque utilisateur connecte ensuite son propre compte. C’est la façon moderne d’étendre les capacités d’un agent sans développement.
Exécution de code — l’agent écrit et lance du code dans un bac à sable isolé (sans accès réseau ni système) pour filtrer, croiser ou calculer sur des données. Utile pour réduire fortement la consommation de tokens sur de gros volumes. Désactivé par défaut, à ouvrir en connaissance de cause.
Workflows-as-tools — donner à l’agent le droit de déclencher un workflow en cours de conversation, puis d’en récupérer le résultat.

Pourquoi ça existe. Pour transformer un assistant qui répond en un assistant qui fait. Chaque famille d’outils est un interrupteur : on n’ouvre que ce qui est utile et sûr pour l’usage visé.

Comment ça se relie. Les outils sont attachés à un agent. Plusieurs d’entre eux (accès web, exécution de code, serveurs MCP, outils de workflow) sont encadrés par des interrupteurs de gouvernance à l’échelle de l’organisation : couper l’interrupteur suspend la capacité pour tout le monde, sur-le-champ.

Mini-exemple. L’agent « Support » a deux outils actifs : la base de connaissances (pour citer la doc produit) et un workflow « ouvrir un ticket ». Quand un client décrit un bug, l’agent répond et crée le ticket dans la foulée.

Connecteur

Ce que c’est. Un connecteur relie Abra à un outil externe — Google (Gmail, Drive, Calendar, Sheets), Microsoft 365 (Outlook, Teams, SharePoint), Slack, Salesforce, HubSpot, et bien d’autres. C’est le « câble » entre vos agents/workflows et vos applications.

Pourquoi ça existe. Pour que vos agents et automatisations agissent dans vos outils habituels, en toute sécurité, sans manipuler de mots de passe à la main. Les secrets sont chiffrés et jamais visibles par les membres.

Comment ça se relie. Un connecteur alimente les outils d’un agent et les étapes d’un workflow. Il existe deux façons de se connecter, selon l’outil :

OAuth — chaque utilisateur autorise son propre compte d’un clic. L’administrateur prépare l’application une fois (identifiants côté Google/Microsoft), puis chacun connecte le sien. Idéal quand chaque personne agit sous sa propre identité (ex. envoyer un mail depuis mon Gmail).
Clé API — l’administrateur saisit une clé partagée valable pour toute l’organisation. Idéal pour un service commun (ex. une clé d’un fournisseur de données ou d’un modèle).

Mini-exemple. Le connecteur Gmail est en OAuth : chaque commercial connecte sa boîte, et l’agent envoie les e-mails sous son nom à lui. Le connecteur d’un service de météo est en clé API : une seule clé, partagée, configurée une fois par l’admin.

Workflow vs Automation

Ce que c’est. Un workflow est une automatisation métier construite visuellement : une suite d’étapes qui s’enchaînent — lire une donnée, appeler une API, transformer, écrire un résultat. Une automation est le même objet, mais qui se déclenche tout seul au lieu d’attendre un clic.

Pourquoi la distinction existe. C’est le déclencheur qui les sépare, pas le moteur (les deux tournent sur le moteur d’orchestration d’Abra — que vous n’avez pas à manipuler) :

	Workflow	Automation
Déclencheur	À la demande : on clique « Exécuter »	Tout seul : à intervalle (chaque matin…) ou sur événement (mail reçu, formulaire soumis, webhook)
Interface	Un bouton, parfois un petit formulaire d’entrée	Un simple interrupteur marche / arrêt
Trace	Un historique de chaque exécution (entrées, sorties, statut)	Idem, à chaque déclenchement automatique

Comment ça se relie. Workflows et automations sont attribués aux équipes comme les agents. Un agent peut aussi les déclencher lui-même via l’outil workflows-as-tools, et un workflow peut renvoyer son résultat dans la conversation.

Mini-exemple. Le même enchaînement « traiter une facture » existe en deux saveurs : en workflow, le comptable clique « Exécuter » quand une facture arrive ; en automation, il se lance seul dès qu’un PDF atterrit dans un dossier surveillé.

RAG / base de connaissances

Ce que c’est. Une base de connaissances rassemble vos documents (PDF, Word, Excel, Markdown, pages web…) pour qu’un agent puisse les consulter au moment de répondre. Le mécanisme s’appelle le RAG (retrieval-augmented generation, « génération augmentée par la recherche ») : l’agent va d’abord chercher les passages pertinents dans vos documents, puis rédige sa réponse en citant ses sources.

Pourquoi ça existe. Pour ancrer les réponses dans vos informations à jour et vérifiables, au lieu des connaissances générales — forcément génériques et parfois périmées — du modèle.

Comment ça se relie. La base de connaissances est l’un des outils de l’agent. Elle se décline en plusieurs portées qui se combinent : partagée avec toute l’organisation, propre à une équipe, propre à un agent, ou strictement personnelle. Règle d’or : pouvoir lire une base ne donne jamais le droit d’y écrire, et les documents personnels d’un membre restent privés — y compris vis-à-vis de l’administrateur.

À CAPTURER : une réponse d'agent citant ses sources — bulle de conversation avec des puces de citation renvoyant aux documents de la base de connaissances

Avec le RAG, l’agent ne « devine » pas : il retrouve le passage dans vos documents et l’affiche comme source.

Mini-exemple. Un salarié demande « Combien de jours de RTT me reste-t-il cette année ? ». L’agent trouve la règle exacte dans le PDF « Accord RTT 2026 » de la base RH et répond en pointant la page — pas une réponse inventée.

Marketplace / template

Ce que c’est. La marketplace est le catalogue des agents et workflows prêts à l’emploi disponibles dans votre organisation. Chaque entrée du catalogue est un template : un modèle générique (un agent RH, un workflow de traitement de factures…) que vous pouvez activer en un clic.

Pourquoi ça existe. Pour démarrer vite avec des briques éprouvées, sans tout reconstruire à chaque besoin.

Comment ça se relie. Un template naît souvent d’une création qu’un développeur soumet, qu’un admin valide, puis qui devient disponible dans le catalogue. Quand vous activez un template, il devient le vôtre : une copie apparaît dans votre espace avec ses propres réglages et son propre historique, et disparaît du catalogue pour éviter les doublons. C’est ainsi qu’un agent ou un workflow entre dans votre organisation sans repartir de zéro.

Mini-exemple. L’admin parcourt la marketplace, repère le template « Agent Onboarding », clique « Activer » : l’agent apparaît dans l’espace de l’équipe RH, prêt à être personnalisé (ton, documents, modèle).

Clé API (Agents-as-API)

Ce que c’est. Une clé API (préfixe abra_live_…) est un identifiant secret qui autorise l’appel de vos agents depuis l’extérieur d’Abra — vos applications, vos scripts, votre site. C’est le socle de l’offre Agents-as-API : chaque agent approuvé est joignable derrière une URL stable.

Pourquoi ça existe. Pour réutiliser le même agent (mêmes outils, mêmes documents, mêmes garde-fous) partout, sans réimplémenter la logique côté client. Le secret ne s’affiche qu’une seule fois à la création : Abra n’en conserve qu’une empreinte, personne ne peut le réafficher ensuite.

Comment ça se relie. Une clé est rattachée à une organisation et à un utilisateur ; on lui définit un périmètre : quels agents elle peut appeler, quels domaines sont autorisés (pour un appel depuis un navigateur, via CORS), un rate-limit et un plafond mensuel de dépense. Chaque appel est audité (usage, coût, tokens). Une clé se révoque ou se fait tourner à tout moment.

Mini-exemple. Pour brancher l’agent « FAQ » sur son site vitrine, l’équipe crée une clé dédiée limitée à ce seul agent, plafonnée à 50 € / mois, avec le domaine du site comme seule origine autorisée.

Publication

Ce que c’est. La publication consiste à mettre un agent approuvé à disposition hors du chat interne d’Abra. Trois modes coexistent, du plus public au plus contrôlé :

Mode	Pour qui	Connexion de l’utilisateur final
Widget embarquable	Visiteurs d’un site public	Aucune (via clé API) ou login SSO
Lien de partage SSO	Membres / clients identifiés	Connexion requise (page hébergée `…/a/{agent}`)
API (Agents-as-API)	Vos applications et scripts	Clé API

Pourquoi ça existe. Pour rencontrer vos utilisateurs là où ils sont : un visiteur anonyme sur votre site (widget), un collaborateur identifié via un lien interne (SSO), ou un système qui appelle l’agent par programme (API).

Comment ça se relie. La publication est la dernière étape du cycle de vie d’un agent : une fois approuvé, on l’expose. Le widget et l’API s’appuient sur une clé API ; le lien SSO s’appuie sur la connexion d’entreprise de l’organisation et trace chaque conversation jusqu’à l’utilisateur réel. Dans tous les cas, chaque échange garde son origine (clé / SSO / chat interne) pour la traçabilité.

Mini-exemple. Le même agent « FAQ » est publié deux fois : en widget avec clé sur le site public (chat anonyme), et en lien SSO sur l’intranet (chaque salarié identifié, conversations rattachées à son compte).

Récapitulatif

Concept	En une phrase
Organisation	L’espace étanche de votre entreprise : membres, agents, données, secrets.
Équipe	Répartir l’accès aux ressources par métier ou projet, à l’intérieur de l’organisation.
Membre & rôles	Qui peut quoi : membre, manager, développeur, admin d’org, + admin plateforme (l’opérateur).
Agent IA	Un assistant configurable = prompt + modèle + outils + connaissances.
Modèle (LLM)	Le cerveau interchangeable de l’agent, encadré par une liste de modèles autorisés.
Outils	Ce que l’agent sait faire : RAG, connecteurs, MCP, exécution de code, workflows.
Connecteur	Le câble vers vos outils externes — en OAuth (compte de chacun) ou clé API (partagée).
Workflow vs Automation	Même moteur, déclencheur différent : à la demande vs tout seul.
RAG / base de connaissances	Ancrer les réponses dans vos documents, avec citations et portées.
Marketplace / template	Activer en un clic des agents et workflows prêts à l’emploi.
Clé API (Agents-as-API)	Appeler vos agents depuis l’extérieur, sous périmètre contrôlé et audité.
Publication	Exposer un agent : widget, lien SSO, ou API.

Pour la suite : Prise en main pour activer votre premier agent, ou Créer un agent pour construire le vôtre.