Un agent qui rejoint l’entreprise a besoin d’un ordinateur et d’un badge

Illustration conceptuelle générée par IA : l’ordinateur et le badge évoquent l’exécution et l’accès aux outils métier.

Lorsqu’une personne rejoint une entreprise, on lui prépare généralement deux choses.

Un ordinateur, pour ouvrir des fichiers, exécuter des logiciels et travailler. Des comptes et des droits, pour accéder aux outils internes, consulter les documents du projet et utiliser le CRM, dans le périmètre de ses responsabilités.

Avec un ordinateur mais sans comptes, elle aura du mal à démarrer. Avec des comptes mais sans environnement de travail, de nombreuses tâches resteront impossibles.

Les agents IA rencontrent deux conditions similaires lorsqu’ils entrent dans l’entreprise.

Il leur faut un environnement pour exécuter leurs tâches et un mécanisme d’accès autorisé aux systèmes métier. Un sandbox peut fournir le premier. Les passerelles de connexion et d’autorisation, comme OpenConnector, répondent au second besoin.

Ces deux fondations permettent à un agent compétent de participer au travail réel de l’entreprise.

De la réponse à la prise en charge d’un travail

Les tâches utiles traversent souvent plusieurs systèmes.

Imaginons un agent chargé de préparer la réunion client de demain : vérifier les participants dans le calendrier, relire les derniers échanges par e-mail, résumer l’avancement dans le CRM et inscrire les sujets à discuter dans le document de réunion.

Il lui faut du discernement, mais aussi des accès concrets. Où chercher ? Avec quel compte ? Quelles données peut-il lire ? Où peut-il enregistrer le résultat ?

Si on lui demande ensuite de modifier le statut du client ou d’envoyer des invitations, les droits nécessaires changent. Pouvoir consulter une fiche client ne donne pas le droit de modifier une opportunité. Lire les e-mails n’autorise pas à en envoyer au nom de l’entreprise.

Dans notre article sur la sécurité des données des agents, nous expliquions qu’un contexte métier suffisant améliore le jugement. Il faut maintenant préciser comment l’entreprise donne accès à ce contexte et aux opérations utiles.

Les salariés utilisent des comptes, des rôles et des droits. Les agents ont eux aussi besoin de limites d’accès explicites.

Le sandbox est l’ordinateur de travail de l’agent

Comme un salarié exécute des logiciels sur son ordinateur, un agent a besoin d’un environnement d’exécution.

Il peut lancer du code, traiter des feuilles de calcul, produire des fichiers ou piloter un navigateur. Un sandbox encadre l’accès aux fichiers, aux processus et au réseau selon son implémentation et sa configuration. L’article technique d’Anthropic sur le sandboxing décrit le rôle de l’isolation du système de fichiers et du réseau dans l’exécution des agents.

Cela ressemble à la remise d’un ordinateur professionnel : fournir des outils et fixer leurs limites d’utilisation.

Mais pouvoir exécuter un logiciel ne donne pas automatiquement accès au système financier. Un sandbox capable d’exécuter du code ne reçoit pas pour autant les droits légitimes sur le CRM ou les outils internes.

Il répond à la question : où l’agent exécute-t-il sa tâche, et que permet cet environnement ?

L’accès aux systèmes métier demande une autre fondation.

La passerelle est le contrôle d’accès derrière le badge

Le badge représente une identité ; le système de contrôle d’accès décide quelles portes il ouvre. Les comptes, rôles et autorisations des logiciels d’entreprise suivent une logique comparable.

Pour l’agent, la passerelle prend en charge une partie de cette fonction : gérer les connexions et les identifiants, vérifier les droits d’appel et transmettre les opérations autorisées au système cible.

Connecter une application n’est qu’un début. Un accès durable doit aussi répondre à des questions pratiques :

• Quel compte utilise-t-on, et pour le compte de qui ?
• Quelles informations peut-on lire et quelles écritures sont permises ?
• Où les secrets des services tiers sont-ils stockés, protégés et renouvelés ?
• Peut-on retrouver la cause et la trace d’un appel en échec ?
• Comment retirer l’accès à la fin d’une tâche ou lors d’un changement de fonction ?

Placer toutes les clés d’application directement dans l’environnement de l’agent disperse ces responsabilités entre scripts, configurations et déploiements. Un changement de modèle ou d’environnement peut obliger l’équipe à tout réexaminer.

La passerelle centralise la gestion des connexions et des autorisations. L’agent passe par les interfaces permises, les secrets d’origine restent gérés par la passerelle et les opérations sont vérifiées au moment de leur exécution.

« Lis uniquement les données » peut figurer dans une consigne. Faire respecter « cet appel n’a aucun droit d’écriture » exige un contrôle système. Cette limite permet de déléguer progressivement de véritables opérations.

Deux limites pour deux parties du travail

Sandbox et passerelle peuvent fonctionner ensemble.

Schéma conceptuel d’un appel via une passerelle. Chaque couche impose ses propres limites ; les capacités réelles dépendent du déploiement et de la configuration.

Infrastructure	Analogie avec l’arrivée d’un salarié	Question principale
Sandbox	Ordinateur professionnel	Où exécuter le code et traiter les fichiers ?
Passerelle de connexion et d’autorisation	Contrôle d’accès derrière le badge	Avec quel compte et pour quelles opérations ?

Un programme peut rester dans le sandbox tout en envoyant des requêtes par une connexion réseau autorisée. S’il possède un secret permettant de supprimer des fiches clients, le sandbox ne sait pas si cette suppression correspond à sa mission.

Inversement, faire passer les appels par une passerelle ne gère pas tous les fichiers téléchargés, scripts locaux et résultats temporaires. Ils demandent toujours un environnement adapté.

Les deux limites comptent particulièrement pour les agents qui exécutent du code, manipulent des fichiers et interviennent dans plusieurs applications.

Le déploiement en entreprise nécessite aussi gestion des identités, orchestration, approbation et vérification des résultats. Certaines tâches effectuées uniquement par API contrôlées n’exigent pas de sandbox indépendant. L’analogie met en évidence deux capacités fondamentales : exécuter et disposer d’un accès métier accordé.

Pourquoi suivre cette infrastructure sur la durée

Un appel réussi suffit à montrer le potentiel d’un agent. L’usage régulier pose une autre question : plusieurs agents peuvent-ils utiliser durablement les mêmes systèmes, avec des comptes et des responsabilités différents ?

Aujourd’hui un assistant prépare les dossiers clients. Demain un autre modèle le remplace. Puis un agent spécialisé gère les commandes. Le CRM, les documents, les e-mails et les outils internes restent généralement, tout comme l’entretien de leurs connexions et droits.

Avec une intégration propre à chaque agent, on répète adaptation des API, stockage des secrets, renouvellement des jetons, restrictions et diagnostic des échecs.

Une infrastructure réutilisable permet aux nouveaux agents de reprendre les connexions existantes avec les droits adaptés à leur rôle. Les développeurs consacrent plus de temps aux processus métier et l’entreprise maintient plus facilement des règles cohérentes.

À mesure que les agents prennent en charge le travail réel, connexion et autorisation deviennent des besoins récurrents.

Pour les développeurs, c’est un effort d’ingénierie commun qui mérite du temps. Pour les entreprises, une frontière d’architecture à prévoir. Pour les investisseurs qui étudient le secteur des agents, un domaine d’infrastructure à examiner. Sa valeur durable dépend de la réduction des intégrations répétées, du réemploi dans plusieurs tâches et de la continuité de la maintenance et du contrôle des droits.

La contribution d’OpenConnector

OpenConnector est une passerelle de connexion open source maintenue par OOMOL. Elle gère connexions et identifiants et expose des opérations via SDK, CLI, MCP et HTTP.

L’agent ou un backend de confiance choisit une opération et une connexion. La passerelle contrôle les identifiants de l’appelant et la politique d’opérations, contacte le fournisseur avec le compte correspondant et renvoie le résultat.

Les développeurs peuvent consulter les définitions, paramètres et scopes requis, configurer les opérations permises ou bloquées en auto-hébergement et examiner des traces dont les données sensibles sont masquées. Le runtime ouvert, les définitions et les gestionnaires exécutables localement lorsqu’ils sont disponibles permettent d’inspecter et d’étendre le chemin d’appel. Voir la documentation OpenConnector.

Ces politiques s’appliquent avec les droits du compte et les scopes du service d’origine. Les fiches clients visibles dépendent aussi du système source. L’envoi d’un e-mail peut demander une confirmation humaine dans le processus métier. La passerelle s’intègre donc à la gestion globale des identités et des approbations.

Une équipe peut commencer avec l’hébergement OOMOL, ou auto-héberger OpenConnector pour gérer passerelle, secrets et runtime. Notre guide de choix du déploiement détaille ces options.

Une fondation à construire ensemble

L’intégration des applications demande un entretien constant. Les modes d’autorisation, paramètres, erreurs et limites diffèrent. Les API changent, les jetons expirent et les entreprises ajoutent des applications et systèmes internes.

Une grande partie de ce travail peut profiter à plusieurs équipes. Corriger une pagination aide les autres utilisateurs du connecteur. Préciser les scopes nécessaires évite une enquête au prochain développeur. Publier le code permet de l’examiner, de le corriger et de l’exécuter ailleurs.

C’est le sens d’une passerelle ouverte : transformer les efforts répétés dans chaque entreprise en capacités utiles à tout l’écosystème.

Une couche ouverte préserve aussi le choix. Agents et modèles peuvent évoluer ; les connexions restent utilisables à travers des interfaces et implémentations publiques. Une équipe qui veut maîtriser son environnement dispose du code et d’un chemin de déploiement.

L’open source rend possibles l’examen, la modification et la maintenance collective. La sécurité exige toujours revue de code, configuration correcte et exploitation continue ; les conditions des API tierces restent applicables. La collaboration prend sa valeur dans ces améliorations concrètes, réalisées puis réutilisées.

Préparer l’arrivée du prochain collègue numérique

Considérons l’agent comme un nouveau collègue. Où travaillera-t-il ? À quels systèmes pourra-t-il accéder ? Que pourra-t-il lire ou modifier ?

Des réponses effectivement appliquées par les systèmes permettent de lui confier progressivement des tâches plus utiles.

Nous souhaitons qu’OpenConnector fasse partie de cette infrastructure d’accueil. Chacun peut contribuer à partir d’une application quotidienne : ajouter une opération nécessaire, corriger une autorisation, améliorer une définition de paramètre ou signaler un problème de déploiement.

Consultez le site OOMOL pour découvrir le produit et les options d’intégration. Pour valider un usage, connectez une application dans OOMOL Console et commencez par une lecture au périmètre explicite.

Un agent qui rejoint l’entreprise a besoin d’un environnement de travail et d’une porte vers les systèmes métier, avec les bons droits. C’est par cette porte que nous commençons, avec la communauté.