Agents IA en entreprise : le vrai blocage n'est pas le modèle, c'est l'accès aux logiciels

Les démonstrations d'agents IA impressionnent : un assistant lit un e-mail, prépare un devis, met à jour une fiche client. En entreprise, la plupart de ces projets ne butent pourtant pas sur l'intelligence du modèle. Ils butent sur une question beaucoup plus terre à terre : l'agent peut-il lire et écrire dans les logiciels que l'équipe utilise déjà ?

Trois situations, trois projets très différents

Avant de choisir un modèle, il faut regarder comment chaque logiciel métier laisse entrer les données. On rencontre en pratique trois cas.

1. Le logiciel propose une API documentée. C'est le cas idéal. L'agent peut lire une commande, créer un brouillon de facture ou ajouter une note dans le CRM, avec des droits limités à ce qu'il doit faire. La plupart des CRM et des outils de facturation récents entrent dans cette catégorie.

2. Le logiciel permet seulement un export. L'agent peut lire des fichiers CSV ou Excel exportés régulièrement, mais ne peut rien écrire. Il prépare alors des propositions qu'une personne saisit ou importe. Le gain existe, il est simplement plus limité.

3. Le logiciel ne propose aucun accès. Outil hébergé chez l'éditeur, accès par prise en main à distance, pas d'export : l'agent ne peut ni lire ni écrire. Les contournements, comme simuler des clics à l'écran, sont fragiles et cassent à chaque mise à jour de l'interface.

C'est pour cette raison qu'un audit IA sérieux commence par l'inventaire des accès, avant même de parler de modèle. Chez Noxcod, c'est la troisième étape de la méthode, juste après le choix de la tâche et la mesure du temps qu'elle prend.

Les droits : donner à l'agent le strict nécessaire

Une fois l'accès possible, la question devient : avec quels droits ? Un agent qui peut tout modifier dans un ERP représente un risque disproportionné pour une tâche qui consiste à préparer des brouillons.

L'ANSSI le rappelle dans ses recommandations de sécurité pour un système d'IA générative : les flux entre le système d'IA et les autres ressources doivent être filtrés, authentifiés, soumis à un contrôle des autorisations et journalisés. Concrètement, cela donne trois règles simples :

• un compte dédié à l'agent, jamais le compte d'un salarié ;
• des droits limités à la lecture et à la création de brouillons tant que le test n'est pas concluant ;
• un journal des actions, pour savoir à tout moment ce que l'agent a lu, écrit ou proposé.

Où tourne le modèle ?

Dernier point technique souvent sous-estimé : l'endroit où les données sont traitées. Pour des documents sensibles (brevets, données de santé, dossiers juridiques), envoyer le contenu à un service en ligne n'est pas toujours acceptable. Des modèles ouverts comme Qwen ou GLM peuvent tourner sur un serveur installé dans l'entreprise, au prix d'un investissement matériel et d'une maintenance à prévoir. Ce choix doit être fait au moment du cadrage, pas une fois le projet lancé. Il en va de même pour le cadre réglementaire : la législation européenne sur l'IA fixe des obligations qui dépendent du niveau de risque de l'usage, et mieux vaut le savoir avant de développer.

La checklist avant de lancer un agent

• Le logiciel concerné propose-t-il une API, un export, ou rien ?
• L'agent a-t-il besoin d'écrire, ou seulement de lire ?
• Qui valide ce que l'agent produit, et en combien de temps ?
• Les données peuvent-elles quitter l'entreprise ?
• Existe-t-il vingt exemples réels pour tester avant de déployer ?

Si une de ces réponses manque, le projet n'est pas prêt, quel que soit le modèle choisi. À l'inverse, une tâche répétitive, un logiciel ouvert et une personne qui valide suffisent souvent à obtenir un premier résultat mesurable en quelques semaines.