Sécurité et contrôle

Accès contrôlé de l’IA aux outils métiers

Un chat d’IA isolé peut préparer un message ou résumer un document, mais sa valeur pour l’entreprise atteint rapidement une limite faute de pouvoir agir. Pour vérifier la fiche d’un client, rechercher un contenu, actualiser un itinéraire ou préparer un rapport, l’assistant a besoin des outils du système d’entreprise. Cet accès constitue aussi le principal risque : le modèle ne doit pas obtenir davantage de pouvoirs que le collaborateur ni transformer de sa propre initiative une consultation en modification.

Dans Sapphire, l’accès de l’IA est conçu comme une composante administrée de la plateforme. Les modules métiers existants publient des opérations strictement définies, tandis que l’environnement central AIControl détermine lesquelles sont autorisées pour l’organisation et pour chaque groupe. Le collaborateur ne voit que l’ensemble qui lui est accessible et le serveur vérifie de nouveau la politique à chaque appel. L’interface de chat facilite le choix d’un outil, mais elle ne constitue pas la frontière de sécurité.

Trois niveaux de contrôle

Le premier niveau est le catalogue de l’entreprise. L’administrateur n’active que les outils prêts à être utilisés dans des scénarios d’IA. La présence d’une fonction dans un module ne la rend pas automatiquement accessible au modèle. L’entreprise peut ainsi introduire l’IA par étapes : commencer par des recherches et des analyses sûres, ajouter la préparation de brouillons après avoir contrôlé les processus, puis ouvrir seulement certaines opérations de modification.

Le deuxième niveau repose sur les droits de groupe. Le marketing, la logistique, la rédaction et le support peuvent employer des modules et des actions différents. Une autorisation générale d’utiliser l’IA ne donne pas accès à toutes les fonctions métiers. L’ensemble effectif résulte de la politique globale, des droits du groupe et de l’état actuel de l’outil. Si un droit du collaborateur est révoqué, l’IA perd elle aussi la capacité correspondante.

Le troisième niveau est le choix effectué pour une session de travail donnée. L’utilisateur peut réduire l’ensemble disponible selon sa tâche, par exemple en ne conservant que la recherche dans la base de connaissances et la lecture du catalogue. Il ne peut pas étendre ses droits au-delà des limites définies par l’administrateur. Certains outils de service obligatoires peuvent être maintenus de manière centralisée afin de préserver la stabilité du scénario de travail.

Lecture, modification et opérations critiques

Pour l’entreprise, il est essentiel de distinguer l’obtention d’informations de la modification de l’état du système. Les outils Sapphire décrivent la nature de chaque opération et les intégrations externes séparent les périmètres de lecture, d’écriture et de suppression. Le client peut aussi demander une confirmation avant une modification, mais la décision finale reste toujours côté serveur : celui-ci vérifie si le compte, le groupe, l’autorisation et le périmètre d’accès sont valides à cet instant précis.

Les modifications sont réalisées dans les limites du module métier. Le modèle ne dispose pas d’un accès direct et universel à la base de données et ne construit pas de commandes arbitraires. Il appelle une action précise avec des paramètres vérifiables : créer un enregistrement, actualiser des champs autorisés, changer un statut ou obtenir un rapport. Si la vérification échoue ou si le module refuse l’opération, le refus concerne cet appel sans désactiver les autres capacités de l’assistant.

Ce contrat améliore la protection autant que la qualité. L’outil renvoie un résultat structuré ; l’IA peut donc corriger des paramètres incomplets, demander une précision à l’opérateur ou poursuivre par une autre voie sûre. Des limites empêchent une boucle infinie en cas d’échecs répétés, tout en préservant la capacité de fournir une réponse ordinaire à l’utilisateur.

Assistant interne et connexions externes

Sapphire prend en charge un environnement d’IA interne et, séparément, un accès MCP externe, actuellement au stade developer-alpha, aux outils publiés explicitement. Tous deux utilisent les droits métiers, mais ne sont pas fusionnés automatiquement. Un outil disponible pour l’assistant intégré ne devient pas externe du seul fait de son existence. L’environnement MCP externe exige une publication distincte et sa propre politique.

Une connexion OAuth commence avec le minimum mcp.basic et s’étend au moyen d’un scope step-up lorsque le client demande un outil supplémentaire. Dans cette implémentation developer-alpha, un personal bearer token reçoit un ensemble fixe de scopes défini et géré exclusivement par le serveur ; l’exécution réelle est en outre limitée par les droits actuels de l’utilisateur et par la politique du module. La sélection granulaire des scopes pour le personal token n’est pas encore annoncée. L’utilisateur ou l’administrateur peut consulter des informations sûres sur la connexion et la révoquer sans exposer les identifiants actifs.

Cette approche permet d’intégrer la plateforme d’entreprise à des clients d’IA approuvés sans accorder à une application un accès universel et permanent. Chaque connexion reste liée à un propriétaire, à ses droits actuels et à un périmètre limité. Un changement de rôle ou la révocation d’une autorisation empêche toute utilisation ultérieure des opérations concernées.

Observabilité sans exposition inutile

L’exécution d’une tâche d’IA conserve le lien entre la demande, l’outil appelé et son résultat. Il devient ainsi plus simple d’examiner une modification contestée, d’évaluer la qualité de l’automatisation et d’améliorer les consignes de travail. L’utilisateur ordinaire reçoit une description sûre de l’activité ; les arguments détaillés et les résultats techniques sont réservés à un rôle disposant d’une autorisation distincte.

Les informations obtenues par les outils sont traitées comme des données et non comme de nouvelles règles système destinées au modèle. Les instructions de pilotage sont définies dans des profils et des politiques centralisés. Cette séparation réduit le risque qu’un texte provenant d’un document externe, d’une fiche ou d’une page web tente de modifier les limites de comportement établies par l’organisation.

Scénario de déploiement

Identifier les processus dans lesquels l’IA doit seulement rechercher et résumer des informations.
Activer un ensemble limité d’outils pour un groupe pilote et vérifier les tâches réelles.
Ajouter des opérations d’écriture uniquement avec des responsables de processus et des critères de résultat clairement définis.
Séparer les droits par groupe et laisser l’utilisateur réduire encore l’ensemble pour sa session.
Analyser régulièrement le journal des appels, les refus et la qualité des modifications préparées.

Au final, l’IA dans Sapphire n’agit pas comme un robot privilégié placé à côté du système d’entreprise, mais comme un autre participant contrôlé du processus. Elle utilise l’identité actuelle du collaborateur, un catalogue limité et les règles du module concerné. L’entreprise peut ainsi tirer un bénéfice pratique de l’automatisation sans échanger sa maîtrise contre de la vitesse.