Donner les clés à une IA : le problème particulier des agents

Une conversation et un agent, ce n’est pas pareil

Dans une conversation normale, c’est vous qui choisissez :

Je choisis une information → je l’envoie à l’IA → elle répond.

Vous voyez exactement ce qui part. Si vous ne collez pas le fichier client, l’IA ne le voit pas.

Avec un agent, le chemin est différent :

IA → fichiers → base de données → fichier clients (CRM) → e-mails → autres services en ligne (API) → et parfois une action.

L’agent va chercher lui-même. Il peut lire vingt fichiers pour en trouver un. Il peut envoyer un e-mail, modifier une fiche client, supprimer une ligne. Vous ne voyez plus chaque information qui passe.

Une image simple : avec un chatbot, on donne souvent un document à l’IA. Avec un agent, on peut lui donner une clé. Un document, c’est une feuille. Une clé ouvre tout ce qui est derrière la porte.

Les questions à poser avant de donner une clé

La question du premier article reste valable : où vont mes données, et pour combien de temps ? Mais avec un agent, il faut en ajouter d’autres.

À quelles données l’agent a-t-il accès ? Tout le Drive, ou un seul dossier ? Tous les clients, ou ceux d’un projet ?

Quelles actions peut-il faire ? Lire seulement ? Écrire ? Envoyer ? Supprimer ? Une action qui ne peut pas être annulée devrait demander votre accord.

Quels journaux sont gardés ? Un agent laisse des traces : ce qu’il a lu, ce qu’il a fait. Ces journaux peuvent eux-mêmes contenir des données sensibles. Qui peut les lire, et combien de temps sont-ils gardés ?

Où les données sont-elles traitées ? Sur les serveurs d’un fournisseur, dans un cloud que votre entreprise contrôle, ou sur vos propres machines ?

Comment les permissions sont-elles limitées ? Et pour combien de temps ? Une clé qui expire dans une semaine est moins dangereuse qu’une clé valable pour toujours.

Comment les identifiants sont-ils protégés ? Les identifiants (credentials en anglais), ce sont les mots de passe, tokens et clés qui ouvrent les portes. Où sont-ils rangés, et qui peut les voir ?

Cloud privé, API contrôlée, self-hosting : pourquoi les entreprises regardent ailleurs

Quand un agent doit toucher des données internes, beaucoup d’entreprises regardent de plus près où tourne le modèle. Il y a plusieurs possibilités :

• utiliser l’API d’un fournisseur, c’est-à-dire l’accès direct à ses modèles depuis vos propres outils, avec un contrat et des réglages adaptés ;
• passer par un cloud que l’entreprise utilise déjà (Azure, AWS, Google Cloud) ;
• faire tourner le modèle sur ses propres serveurs, ce que l’on appelle le self-hosting.

Mistral, entreprise française, est souvent citée dans ces discussions. Sa documentation propose ces différentes voies. Ses modèles sont disponibles par son API, chez plusieurs grands fournisseurs de cloud, et ses modèles « à poids ouverts » (dont les fichiers sont publiés, sous licence Apache 2.0) peuvent être installés sur vos propres serveurs.

Mais Mistral n’est pas automatiquement privé. Tout dépend du produit et de sa configuration. Par exemple, d’après sa propre documentation, les conversations des offres gratuites et Pro de son assistant (Le Chat, qui s’appelle désormais Vibe) servent par défaut à l’entraînement, sauf si l’utilisateur le désactive. Les offres Enterprise, elles, sont exclues de l’entraînement par défaut. Et son option Zero Data Retention ne couvre ni l’assistant, ni les agents.

La bonne question n’est donc pas « quel fournisseur est sûr ? ». C’est : quel produit, avec quelle offre, déployé où, avec quels réglages ? La même question se pose pour OpenAI, Anthropic, Google ou n’importe quel autre fournisseur.

Un exemple concret : laisser un agent modifier un dépôt GitHub

Dans l’article précédent, nous avons vu qu’une IA peut enregistrer vos documents dans GitHub. Pour cela, elle a besoin d’une autorisation. Comment la donner proprement ?

Ouvrir la porte sans montrer la clé

La mauvaise méthode est aussi la plus tentante : créer un token et le coller dans la conversation. « Tiens, voilà la clé, débrouille-toi. » Le token est alors dans l’historique de la conversation, peut-être dans des journaux, peut-être pour longtemps.

La bonne idée est différente : l’IA peut utiliser l’autorisation sans connaître la clé. La clé est rangée dans le coffre-fort de votre ordinateur (le trousseau de mots de passe du système, ou un outil de connexion dédié). Quand l’agent lance l’envoi vers GitHub, c’est le système qui présente la clé. L’agent ouvre la porte, mais il ne voit jamais la clé, et il ne peut pas l’afficher dans une réponse.

C’est d’ailleurs ce que font déjà certains outils. OpenKnowledge, par exemple, se connecte à GitHub par une autorisation dans le navigateur, et garde le token dans le trousseau du système.

Attention : ce n’est pas une protection parfaite. Un agent qui peut lancer n’importe quelle commande sur votre ordinateur pourrait, dans certains cas, aller chercher la clé. C’est pour cela que la deuxième règle compte autant.

Donner une petite clé plutôt qu’un passe-partout

GitHub propose des tokens à permissions fines (fine-grained tokens). On peut les limiter à un seul dépôt, choisir exactement ce qu’ils permettent (lire, écrire le contenu…), et fixer une date d’expiration. GitHub recommande de les utiliser plutôt que les anciens tokens « classiques », qui donnent accès à tous vos dépôts.

Pour une entreprise ou une intégration durable, GitHub recommande plutôt une GitHub App : la personne qui l’installe choisit les dépôts autorisés, et les tokens utilisés sont de courte durée.

C’est le principe du moindre privilège : l’agent reçoit la clé d’une seule pièce, pour une durée limitée, et pas le passe-partout de l’immeuble. S’il se trompe, ou si la clé fuit, les dégâts restent petits.

De « que puis-je copier ? » à « à quoi puis-je donner accès ? »

Au début de l’IA générative, la question était simple :

« Qu’est-ce que je peux copier-coller dans ChatGPT ? »

Nous l’avons vue dans le premier article : elle demande déjà de distinguer traitement, conservation, entraînement et mémoire.

Avec les agents, la question devient plus large :

« À quoi suis-je prêt à donner accès à une IA ? »

Ce n’est pas une raison pour refuser les agents. Ils peuvent faire gagner beaucoup de temps. C’est une raison pour leur donner des accès comme on les donne à un nouveau collègue : ce qu’il faut pour sa mission, pas les clés de tout le bâtiment dès le premier jour.

Pour relire le début de la série : Peut-on confier des données sensibles à une IA ?

Article suivant : Quand un agent IA va trop loin

Vérification

Sources

• GitHub — Managing your personal access tokens
• GitHub — Deciding when to build a GitHub App
• Mistral — Deployment
• Mistral — Do you use my user data to train your AI models?
• Mistral — Zero data retention
• Mistral — Le Chat is now Vibe
• OpenKnowledge — GitHub sync : Authentication