Gouvernance : qui a le droit de faire quoi, et à quel coût

Pourquoi une plateforme d’IA a besoin de sa propre gestion des droits

Une plateforme d’IA a besoin de sa propre gestion des droits, car une fenêtre de chat sans règles transmet chaque question à chaque système connecté. Dès que l’IA est reliée à un système d’entreprise, la question n’est plus de savoir si quelqu’un peut discuter, mais quelles données l’IA peut lire pour le compte de cette personne.

Une interdiction ne fait que déplacer l’usage, elle n’y met pas fin

Sans voie autorisée, chacun prend la suivante. Une interdiction déplace l’usage vers des comptes privés chez des fournisseurs publics, où ni contrat, ni journal, ni droit à l’effacement ne s’appliquent. Les données de l’entreprise se retrouvent alors dans un service que personne chez vous n’administre et dont vous ne pouvez pas justifier le traitement.

La contre-mesure qui fonctionne est une voie autorisée meilleure que la voie privée. Elle doit toutefois rendre quatre choses contrôlables, sinon vous ne faites que déplacer le risque vers l’intérieur :

• Quelles personnes peuvent utiliser la plateforme, et via quelle authentification.
• Quels systèmes connectés et quels outils individuels sont accessibles à une personne.
• Ce qui s’est réellement passé, de manière prouvable et exportable.
• Ce que coûte l’exploitation, détaillé et plafonnable, avant l’arrivée de la facture.

Ces quatre points de contrôle constituent précisément les rubriques du panneau d’administration de Kisuno : gestion des utilisateurs, règles d’accès, audit et consommation.

D’où viennent les utilisateurs, les rôles et les groupes

Vous gérez les utilisateurs, les rôles et les groupes dans le panneau d’administration ou vous les reprenez depuis Entra ID. Un rôle regroupe des droits fonctionnels, c’est-à-dire ce que quelqu’un peut faire dans l’interface. Un groupe regroupe des personnes pour les règles d’accès et de budget. Les deux se combinent indépendamment.

Utilisateurs locaux et connexion à Entra ID

Sans fournisseur d’identité, Kisuno fonctionne avec des comptes locaux : invitation par lien, mot de passe défini par la personne invitée. La connexion via Entra ID ou un autre fournisseur OIDC est prise en charge par la plateforme et configurée pour votre instance. Une fois en place, chaque personne se connecte via OIDC, le compte est créé à la première connexion et les informations de groupe et de rôle issues du jeton d’authentification sont mises en correspondance avec vos groupes dans Kisuno.

Le retrait des droits se joue donc à la porte d’entrée : une personne désactivée dans Entra ID n’entre plus et perd ainsi tout accès, y compris aux systèmes connectés. Le provisionnement et le déprovisionnement automatiques des comptes via SCIM sont prévus, mais pas encore disponibles aujourd’hui.

Ce que définit un rôle, ce que définit un groupe

Un rôle régit les droits fonctionnels dans la plateforme, par exemple la possibilité de créer des agents, d’utiliser la recherche web ou d’ouvrir le panneau d’administration. Un groupe régit les données et outils accessibles ainsi que le budget sur lequel la consommation est imputée.

Invitation, attribution, désactivation

Une invitation part par e-mail ou par lien et peut déjà indiquer le groupe cible. L’appartenance est appliquée dès que la personne invitée a terminé son inscription. Personne ne démarre donc dans un état intermédiaire sans droits, et vous n’avez rien à compléter après chaque inscription.

Il existe deux façons de mettre fin à l’accès. Le blocage conserve le compte mais refuse la connexion. La suppression retire le compte, les conversations et les entrées de l’index de recherche ; un export des données pour la personne concernée reste possible au préalable, afin de répondre aussi bien aux demandes d’accès qu’aux demandes d’effacement.

Des droits jusqu’au niveau de l’outil

Les appels d’outils passent par la passerelle MCP, un composant situé entre le chat et le système connecté. Pour la personne à l’origine de la demande, la passerelle vérifie si le serveur et l’outil concret sont autorisés, consigne la décision et ne transmet l’appel qu’en cas d’autorisation. Les outils bloqués n’apparaissent pas dans la liste d’outils de l’utilisateur ; après une modification des droits, cela prend effet avec un léger décalage. Le véritable verrou est le contrôle effectué à chaque appel.

Les systèmes sont connectés via MCP, le standard ouvert pour l’accès aux outils par les modèles d’IA. La passerelle se place en amont afin que l’autorisation soit décidée de façon centrale par personne, rôle et groupe, et non dispersée dans le système connecté. Les systèmes connectables et ceux déjà préparés figurent sur la page Intégrations ; des droits sans outils n’ont pas d’objet.

L’exemple : lire les factures oui, lire les salaires non

Un ERP connecté n’offre pas à l’IA un accès unique, mais de nombreux outils individuels : rechercher des factures, lire les données clients, lire les données salariales, écrire des enregistrements. Le groupe Comptabilité reçoit les outils de facturation, les outils salariaux restent réservés aux ressources humaines. Même serveur, outils différents, décisions distinctes.

En dessous se trouve une seconde limite. Si Kisuno se connecte à votre ERP avec l’identité de la personne concernée, les règles d’accès de cet ERP restent déterminantes : celui qui n’y voit que certains enregistrements n’en voit pas davantage via l’IA. Si la connexion passe par un compte de service commun, la passerelle est le seul point d’application, et la sélection des outils doit alors être découpée de façon restrictive.

Les droits à l’intérieur d’un outil, c’est-à-dire sur des champs ou des lignes, ne sont pas appliqués par Kisuno. C’est la gestion des droits du système connecté qui s’en charge. Un outil au périmètre fonctionnel large ne doit donc pas être autorisé du tout, ou seulement à un groupe qui a de toute façon le droit de voir ces données.

La chaîne de règles : utilisateur avant rôle avant groupe avant valeur par défaut

Les droits sont évalués dans un ordre fixe : utilisateur individuel, puis rôle, puis groupe, puis réglage par défaut du serveur. La première règle correspondante décide, la recherche s’arrête là. Chaque décision est donc explicable et une autorisation ponctuelle ne nécessite aucun rôle spécial. Le fait que les droits s’appliquent par outil individuel constitue l’élément différenciant dans le comparatif avec d’autres plateformes.

Que se passe-t-il si aucune règle ne s’applique

Si aucune règle d’utilisateur, de rôle ou de groupe ne s’applique, c’est le réglage par défaut du serveur concerné qui décide. Réglez ce paramètre sur « refuser » juste après la connexion d’un système, puis autorisez de façon ciblée certains groupes. Ainsi, un système fraîchement connecté ne peut pas laisser voir par mégarde plus que prévu.

Si le contrôle des droits lui-même tombe en panne, par exemple parce que la base de règles est injoignable, la passerelle refuse l’appel au lieu de le laisser passer. Une panne se traduit donc par un message d’erreur dans le chat, et non par un accès ouvert. Un interrupteur « lecture seule » par serveur, bloquant globalement les outils d’écriture, est prévu.

Audit : chaque accès traçable

Chaque appel d’outil via la passerelle est consigné avec l’horodatage, la personne, le système cible, l’outil et la décision, y compris les appels refusés. La plateforme tient en outre un journal chaîné en continu des actions d’administration, des connexions et des modifications de droits. Les deux journaux résident dans votre propre instance et sont exportables en CSV.

Ce qui est journalisé

• Les appels d’outils vers les systèmes connectés, avec la décision prise, autorisée ou refusée.
• Les connexions à la plateforme et au panneau d’administration.
• Les modifications des rôles, groupes, droits et règles d’accès.
• Les modifications de la configuration de l’instance.
• La création, l’invitation, le blocage et la suppression de comptes.

Le journal d’audit est une preuve d’accès, pas un enregistrement des conversations. Il indique qui a appelé quel outil, sur quel système et quand. Les conversations elles-mêmes sont stockées séparément dans la base de données de votre instance et sont soumises à la durée de conservation configurée.

Durée de conservation et destinations d’export

Les journaux restent dans votre instance, dans votre base de données. En auto-hébergement, ils ne quittent pas votre infrastructure. L’export se fait en CSV, filtré par période et par personne, et peut donc être remis directement à une révision, au service juridique ou à un outil d’audit.

Le journal des actions d’administration est chaîné : chaque entrée porte une somme de contrôle de l’entrée précédente, et une vérification intégrée signale si la chaîne ne se referme plus. La suppression a posteriori d’entrées est donc détectée. Pour les conversations, la durée de conservation est paramétrable ; les contenus expirés sont supprimés avec leur index de recherche.

Rendre les coûts visibles et les plafonner

La consommation est enregistrée par personne, groupe, modèle et jour, et indiquée à la fois en tokens et en euros. Un budget mensuel commun plafonne le total pour toute l’organisation, une limite mensuelle facultative par personne plafonne les comptes individuels. Lorsqu’un budget est épuisé, un blocage souple (soft block) s’applique.

Consommation par personne, groupe et modèle

Le panneau d’administration affiche la consommation en euros, ventilée par personne, par modèle et par jour, ainsi que les requêtes individuelles avec le modèle et l’horodatage. Les montants et la ventilation sont visibles par l’administration ; les utilisateurs finaux reçoivent seulement un message dans le chat lorsque le budget est épuisé. Cela retire la pression des coûts du quotidien tout en gardant les chiffres visibles là où ils doivent l’être.

Les prix sont enregistrés par modèle afin que l’analyse ne repose pas sur une approximation. C’est plus important qu’il n’y paraît : pour un même déroulement de conversation, l’écart de coût entre un modèle économe et un très grand modèle se compte en multiples. Une sélection de modèles organisée fait donc partie du contrôle des coûts, et pas seulement de l’ergonomie.

Un budget mensuel commun plutôt que des limites individuelles

Le budget mensuel s’applique à l’organisation dans son ensemble, et non par tête. La raison est pratique : la consommation ne se répartit jamais uniformément. Les personnes qui utilisent intensivement la plateforme buteraient sur une limite individuelle rigide, tandis que le quota d’autres personnes expirerait sans être utilisé. Un pot commun compense cela sans que personne ait à réajuster des limites.

Pour les cas extrêmes, il existe en plus une limite mensuelle facultative par personne. Elle est désactivée tant que vous ne la définissez pas et elle est appliquée strictement lors du même rapprochement que le budget global. Usage typique : un compte unique qui envoie des requêtes automatisées ne doit pas vider à lui seul le pot commun.

Un blocage souple plutôt qu’un dépassement silencieux

Lorsque le budget est épuisé, le blocage souple s’applique : la requête suivante est refusée, avec un message dans le chat plutôt qu’une facturation silencieuse. Une réponse en cours est menée à son terme. L’administrateur peut relever le budget à tout moment, après quoi l’exploitation reprend immédiatement. Sans ce relèvement, aucun supplément n’est facturé.

Le rapprochement entre la consommation enregistrée et le budget s’effectue chaque minute, et l’estimation préalable d’une requête n’en connaît pas la longueur exacte. Une réponse isolée peut donc dépasser légèrement la limite. Il s’agit d’un blocage souple qui empêche une explosion des coûts, et non d’une réservation préalable à la seconde près.

Autoriser les agents au lieu de les interdire

Les agents et les skills sont autorisés de manière encadrée, ni permis ni interdits en bloc. Les comptes ordinaires utilisent les agents qui leur sont attribués et ne voient pas l’atelier de création d’agents. Un rôle privilégié crée et partage les agents, et l’administrateur autorise les skills personne par personne.

La raison tient aux droits : un agent embarque une consigne fixe et un jeu d’outils. Si chacun pouvait créer et partager ses propres agents, un second canal de diffusion incontrôlé s’ajouterait à votre chaîne de droits. Le contrôle des droits à la passerelle continuerait certes de s’appliquer à chaque appel, mais la vue d’ensemble de qui travaille avec quoi serait perdue.

En pratique, cela donne quelques agents bien entretenus par groupe plutôt que de nombreux agents à moitié finis : un pour l’établissement des offres, un pour les analyses issues de l’ERP, un pour la recherche de connaissances internes.

Questions fréquentes