Guide de l'administrateur
Cette page s’adresse aux personnes qui administrent Abra. Elle explique d’abord une distinction essentielle et souvent source de confusion — la différence entre l’admin d’organisation et l’admin de plateforme — puis détaille tout ce qu’un admin d’organisation pilote au quotidien : les rôles, les membres et les équipes, l’encadrement de l’IA (modèles autorisés, budgets), le SMTP, le SSO, la marque et la validation des créations soumises par les développeurs.
Vue d’ensemble : deux niveaux d’administration
Section intitulée « Vue d’ensemble : deux niveaux d’administration »Abra héberge plusieurs organisations sur une même instance. Il existe donc deux niveaux d’administration bien distincts, qui ne voient pas les mêmes écrans et n’ont pas les mêmes responsabilités.
L’admin d’organisation gère son organisation, et elle seule. C’est le responsable côté client : il invite les membres, crée les équipes, encadre l’usage de l’IA pour ses collaborateurs, règle le SMTP, le SSO et la marque de son espace. Il ne voit jamais les autres organisations et n’a aucune prise sur l’instance elle-même. C’est le rôle décrit dans l’essentiel de ce guide.
L’admin de plateforme est l’opérateur : l’hébergeur ou l’ESN qui exploite l’instance Abra pour le compte de tous ses clients. Il se place au-dessus des organisations. C’est lui qui crée les organisations, gère la licence et le catalogue global, fixe les tarifs des modèles, alimente les clés LLM partagées, impose (le cas échéant) des plafonds de dépense à chaque organisation, et valide les workflows et agents promus. Un même individu peut cumuler les deux casquettes sur une petite installation, mais ce sont bien deux portées différentes.
Le sélecteur d’organisation (en haut à gauche) : un admin d’organisation n’y voit que la ou les organisations dont il fait partie ; l’admin de plateforme, lui, les voit toutes.
| Admin d’organisation | Admin de plateforme (opérateur) | |
|---|---|---|
| Qui | Le responsable côté client | L’hébergeur / l’ESN qui exploite Abra |
| Portée | Une seule organisation | Toute l’instance, au-dessus des organisations |
| Crée les organisations | Non | Oui |
| Voit les autres organisations | Non | Oui |
| Gère | Membres, équipes, agents, connecteurs, SMTP/SSO/marque, budgets par membre | Licence, catalogue global, tarifs et clés des modèles, plafonds par org, file de promotion |
| Encadre l’IA | Choisit les modèles autorisés dans la limite fixée par la plateforme | Fixe la limite haute (clés, allowlist globale, quotas) pour toutes les orgs |
À retenir. Certaines limites que vous constatez ne viennent pas de vos propres réglages mais de ceux de l’opérateur : la liste des modèles réellement disponibles, un plafond mensuel de dépense IA, ou le fait que votre organisation doive utiliser sa propre clé fournisseur. Ces leviers-là se discutent avec votre hébergeur — ils ne sont pas dans votre main.
Rôles et permissions
Section intitulée « Rôles et permissions »Un rôle définit ce qu’une personne a le droit de faire dans une organisation. Abra en distingue cinq. 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 coexistent, c’est toujours le plus fort qui l’emporte.
| Rôle | Résumé |
|---|---|
| Membre | Utilise les agents, workflows et automations qui lui sont attribués. Aucune action d’administration. |
| Développeur | Construit et téléverse des workflows et des agents, configure les applications de connecteurs, puis soumet ses créations à validation. Peut appartenir à plusieurs organisations. |
| Manager | Un membre qui gère ses équipes : y ajoute/retire des personnes, leur attribue agents et workflows, invite de nouveaux membres. |
| Super-manager | Variante de manager conservée pour compatibilité, avec les mêmes capacités et une priorité un cran au-dessus quand deux rôles se cumulent. |
| Admin d’organisation | Contrôle toute l’organisation : membres, équipes, connecteurs, agents, gouvernance des modèles, réglages (SMTP, SSO, marque). |
La matrice, en clair
Section intitulée « La matrice, en clair »Ce que chaque rôle peut faire, domaine par domaine :
| Domaine | Membre | Développeur | Manager / Super-manager | Admin d’org |
|---|---|---|---|---|
| Utiliser / discuter avec les agents attribués | Oui | Oui | Oui | Oui |
| Connecter ses propres comptes (OAuth), documents personnels | Oui | Oui | Oui | Oui |
| Construire et téléverser des workflows / agents | — | Oui | — | Oui |
| Soumettre une création à la file de promotion | — | Oui | — | Oui |
| Configurer les applications de connecteurs | — | Oui | — | Oui |
| Inviter des membres | — | — | Oui (ses équipes) | Oui (toute l’org) |
| Créer des équipes, attribuer agents / workflows / bases | — | — | Oui (ses équipes) | Oui (toute l’org) |
| Poser des budgets LLM par membre | — | — | Oui (ses équipes) | Oui |
| Choisir les modèles autorisés de l’organisation | — | — | — | Oui |
| Régler SMTP, SSO, marque | — | — | — | Oui |
| Valider / refuser les promotions | — | — | — | Admin de plateforme |
Deux nuances importantes. Un membre peut voir certains écrans de gouvernance, mais en lecture seule : il constate les modèles autorisés ou le quota de son organisation sans pouvoir les modifier. Et la validation des promotions n’est pas dans les mains de l’admin d’organisation : elle revient à l’admin de plateforme (voir plus bas).
Gérer les membres et les équipes
Section intitulée « Gérer les membres et les équipes »Inviter un membre
Section intitulée « Inviter un membre »Depuis la page de votre organisation, cliquez sur « Inviter un membre », saisissez son e-mail et choisissez son rôle. La personne reçoit une invitation par e-mail :
- Elle n’a pas encore de compte → elle le crée et rejoint l’organisation en une étape.
- Elle a déjà un compte → elle se connecte et accepte l’invitation.
L’invitation ne donne le rôle choisi que dans votre organisation. Elle ne confère jamais de droits sur une autre organisation ni sur la plateforme. Les managers peuvent aussi inviter, mais seulement dans le périmètre des équipes dont ils sont responsables.
L’invitation d’un membre : e-mail + rôle. Le rôle s’applique uniquement à l’organisation active.
Créer des équipes et cadrer l’accès
Section intitulée « Créer des équipes et cadrer l’accès »Une équipe est un sous-groupe de membres (Finance, Support, Marketing…). Les équipes servent à décider qui accède à quoi : un agent, un workflow ou une base de connaissances peut être attribué à une équipe précise plutôt qu’à toute l’organisation. Un membre peut appartenir à plusieurs équipes, et être simple membre de l’une tout en étant responsable (manager) d’une autre.
Une équipe et ses attributions : ouvrir les bonnes ressources aux bonnes personnes, sans tout exposer à toute l’entreprise.
Les équipes sont un sujet à part entière — création, rôles internes, attribution des ressources, budgets par membre. Reportez-vous au guide des équipes pour le détail.
Gouvernance des modèles LLM
Section intitulée « Gouvernance des modèles LLM »C’est le réglage le plus structurant pour un admin d’organisation : il décide quels modèles d’IA toute l’organisation a le droit d’utiliser, et qui paie pour cet usage.
Choisir les modèles autorisés
Section intitulée « Choisir les modèles autorisés »Dans la section Organisation des réglages de l’agent (réservée aux admins), vous cochez, pour chaque fournisseur (OpenAI, Anthropic, Mistral, Google Gemini, OpenRouter, Azure OpenAI, modèle local/Ollama), la liste des modèles autorisés. Vous pouvez découvrir automatiquement les modèles d’un fournisseur ou en ajouter un à la main par son identifiant.
L’effet est simple et global : un modèle absent de la liste devient inutilisable pour tout le monde dans l’organisation — y compris les agents déjà configurés dessus et les préférences personnelles des membres. À l’inverse, cocher un modèle l’ouvre à tous.
Les modèles autorisés de l’organisation : la liste s’applique à tous les membres. Décocher un modèle en cours d’usage peut interrompre un agent en production — vérifiez toujours ce qui tourne dessus avant.
Rayon d’impact. Cette liste peut être encore restreinte par l’opérateur au niveau plateforme. Le résultat effectif est l’intersection des deux : vous pouvez resserrer, jamais élargir au-delà de ce que la plateforme autorise.
Qui paie : clé plateforme ou clé du client (BYOK)
Section intitulée « Qui paie : clé plateforme ou clé du client (BYOK) »Deux modèles de facturation coexistent, et le choix entre les deux revient à l’opérateur, organisation par organisation :
- Clé plateforme. Votre organisation utilise une clé fournisseur alimentée et payée par l’opérateur. Vous n’avez aucune clé à saisir ; en contrepartie, vous ne pouvez utiliser que les modèles ouverts sur cette clé, et un quota de dépense peut vous être imposé.
- BYOK (« Bring Your Own Key », clé du client). Votre organisation utilise exclusivement sa propre clé fournisseur, saisie dans les Connecteurs. Vous payez directement votre fournisseur et vous décidez des modèles, dans la limite de ce que votre clé permet.
Une carte en lecture seule vous indique, côté organisation, quelle politique s’applique à vous, quels modèles sont disponibles sur la clé partagée et où en est votre quota.
La carte de politique (lecture seule) : elle reflète le choix fait par l’opérateur — clé plateforme avec quota, ou BYOK avec votre propre clé.
Quand la gouvernance plateforme est inactive, aucune de ces restrictions ne s’applique : vos modèles dépendent alors uniquement de vos propres clés et réglages d’agent.
Budgets et suivi de consommation
Section intitulée « Budgets et suivi de consommation »Encadrer l’usage de l’IA, c’est aussi surveiller la dépense et poser des plafonds.
Voir la consommation
Section intitulée « Voir la consommation »La page Usage (accessible depuis les réglages de l’agent) détaille la consommation IA de l’organisation : dépense par modèle, par période, et le détail qui permet de comprendre d’où vient le coût. C’est votre tableau de bord pour repérer un agent ou un usage qui coûte cher.
L’admin de plateforme dispose, lui, d’une vue par organisation et par utilisateur sur toute l’instance, avec un détail (drill-down) permettant de voir qui consomme quoi.
La page Usage : suivre la dépense IA de l’organisation, modèle par modèle.
Poser des plafonds
Section intitulée « Poser des plafonds »Deux niveaux de plafond peuvent s’appliquer :
- Par utilisateur. Un budget mensuel LLM se règle depuis la page Équipes (section Budgets LLM), tout comme le quota d’accès web par membre. C’est votre levier pour éviter les dérives individuelles.
- Au niveau de l’organisation. Un plafond mensuel global peut être imposé par l’opérateur. Une fois atteint, les appels IA sont refusés jusqu’à la période suivante (remise à zéro le 1er du mois). Ce plafond n’est pas dans votre main : il se discute avec votre hébergeur.
À quoi ça sert. Garder la dépense sous contrôle à la fois par personne (vos budgets d’équipe) et globalement (le garde-fou de l’opérateur).
E-mail sortant (SMTP) de l’organisation
Section intitulée « E-mail sortant (SMTP) de l’organisation »Abra envoie des e-mails : invitations, notifications, rapports. Vous avez le choix pour l’expéditeur :
- Hériter du SMTP de la plateforme. C’est le comportement par défaut : rien à configurer, les e-mails partent via le serveur fourni par l’opérateur.
- Renseigner votre propre SMTP. Les e-mails partent alors à votre nom et depuis votre domaine, ce qui améliore la délivrabilité et la reconnaissance par vos membres et vos clients.
Le SMTP de l’organisation : laissez vide pour hériter de la plateforme, ou renseignez vos propres paramètres pour envoyer depuis votre domaine.
Conseil. Testez l’envoi après configuration (en réinvitant un membre, par exemple) et vérifiez que le message n’atterrit pas en indésirables — c’est souvent une question d’enregistrements SPF/DKIM sur votre domaine.
Connexion d’entreprise (SSO)
Section intitulée « Connexion d’entreprise (SSO) »Vous pouvez brancher votre organisation sur votre annuaire d’entreprise pour que vos membres se connectent avec leurs identifiants habituels, sans mot de passe Abra. Deux fournisseurs d’identité sont pris en charge, et les deux peuvent être actifs en même temps :
- Microsoft Entra ID (Azure AD)
- Google Workspace
Comment ça marche
Section intitulée « Comment ça marche »La déclaration de l’application côté Microsoft/Google, puis la saisie des identifiants (Client ID, secret, tenant/domaine) se font avec l’opérateur : l’application d’identité est partagée par l’instance. Trois mécanismes rendent le SSO pratique au quotidien :
- Découverte par domaine. Après connexion, Abra identifie l’organisation de
l’utilisateur à partir du domaine de son e-mail. Un collaborateur de
@votresociete.comest automatiquement rattaché à la bonne organisation. - Mapping groupe → rôle. Les groupes de l’annuaire (Entra ID) peuvent être traduits en rôles Abra, avec une règle « attrape-tout » pour les autres. Vos responsables héritent ainsi du bon rôle sans réglage manuel.
- Provisioning automatique (JIT) ou sur invitation. Vous choisissez si un utilisateur inconnu qui se connecte via SSO obtient automatiquement un compte, ou si seules les personnes déjà invitées peuvent passer par le SSO.
La configuration SSO : un onglet par fournisseur, l’URI de redirection à coller côté IdP, et le mapping groupe → rôle.
Prudence. Avant d’imposer le SSO seul, assurez-vous qu’au moins un administrateur conserve un accès de secours. Un mauvais réglage de domaine ou de secret peut sinon verrouiller tout le monde dehors.
Marque et white-label
Section intitulée « Marque et white-label »Abra est white-label : vos utilisateurs voient votre plateforme, pas celle de l’éditeur. Au niveau de l’organisation, vous pilotez :
- le nom de l’organisation (affiché dans le sélecteur en haut à gauche, les invitations et les rapports) ;
- le logo, par URL externe ou par téléversement d’un fichier (PNG, JPEG, WebP ou SVG, jusqu’à 5 Mo).
Selon votre déploiement, les couleurs et l’habillage global peuvent en outre être définis au niveau de l’instance par l’opérateur.
La marque de l’organisation : nom et logo, appliqués partout où votre organisation apparaît.
La file de promotion
Section intitulée « La file de promotion »Vos développeurs construisent workflows et agents dans un espace de travail, puis les soumettent pour qu’ils deviennent des modèles utilisables par les membres. Ces soumissions n’apparaissent pas directement en production : elles atterrissent dans une file de promotion où elles doivent être validées.
La file rassemble deux types de demandes — les workflows et les agents — et se filtre par statut : en attente, approuvées, rejetées. Pour chaque demande, vous voyez ce qui est soumis, par qui, et vous pouvez ouvrir la revue : inspecter le contenu, ajuster les paramètres si besoin, puis approuver ou refuser.
La file de promotion : chaque création soumise par un développeur y attend une validation avant de devenir un modèle disponible.
Qui valide ? La validation des promotions est une prérogative de l’admin de plateforme (l’opérateur), pas de l’admin d’organisation. C’est cohérent avec le rôle : le catalogue partagé et les créations promues relèvent de la plateforme. Pour comprendre le cheminement complet (espace développeur → soumission → validation → mise à disposition), voir le guide de la promotion.
Questions fréquentes
Section intitulée « Questions fréquentes »Quelle est la différence entre admin d’organisation et admin de plateforme ? L’admin d’organisation gère une seule organisation (ses membres, équipes, agents, réglages) et ne voit rien des autres. L’admin de plateforme est l’opérateur (hébergeur / ESN) : il se place au-dessus de toutes les organisations, les crée, gère la licence, les clés et tarifs des modèles, les plafonds imposés et la file de promotion. Sur une petite installation, une même personne peut cumuler les deux, mais ce sont deux portées différentes.
Comment restreindre les modèles d’IA utilisables dans mon organisation ? Dans la section Organisation des réglages de l’agent, cochez uniquement les modèles que vous autorisez. Tout modèle non coché devient inutilisable pour tous vos membres. Attention : votre liste ne peut jamais dépasser ce que la plateforme autorise (le résultat est l’intersection des deux), et retirer un modèle en cours d’usage peut interrompre des agents en production.
Un simple membre voit-il les réglages de gouvernance ? Il peut voir certains écrans (par exemple les modèles disponibles ou le quota de l’organisation) mais toujours en lecture seule. Seul un admin d’organisation peut modifier les modèles autorisés, le modèle par défaut, le SMTP, le SSO ou la marque.
Qui paie l’usage de l’IA : nous ou l’hébergeur ? Cela dépend de la politique fixée par l’opérateur pour votre organisation. En mode clé plateforme, l’opérateur fournit et paie la clé (souvent avec un quota mensuel). En mode BYOK, votre organisation saisit sa propre clé dans les Connecteurs et paie directement son fournisseur. La carte de politique (lecture seule) vous indique le mode actif.
Comment configurer le SSO de mon entreprise ? Le SSO (Microsoft Entra ID et/ou Google Workspace) se met en place avec l’opérateur, car l’application d’identité est partagée par l’instance. Une fois en place, vos membres se connectent avec leur compte d’entreprise ; Abra les rattache automatiquement à votre organisation grâce au domaine de leur e-mail, et vous pouvez choisir la création automatique de comptes (JIT) ou le mode sur invitation uniquement.
Un développeur peut-il mettre son agent en production tout seul ? Non. Un développeur construit et soumet, mais la mise à disposition passe par la file de promotion, validée par l’admin de plateforme. C’est ce qui garantit que rien n’atteint les utilisateurs sans revue.
Puis-je poser un budget d’IA différent selon les personnes ? Oui. Depuis la page Équipes, section Budgets LLM, vous fixez un budget mensuel par membre (et un quota d’accès web). En complément, l’opérateur peut imposer un plafond global à toute l’organisation, indépendant de vos budgets individuels.
Cette page compte 10 sections (##) et 10 emplacements de capture
d’écran (admin-1 à admin-10).