IA agentique en entreprise : 7 garde-fous avant la production

L'IA agentique n'est pas simplement un chatbot plus puissant. Un chatbot répond à une demande. Un agent peut enchaîner des étapes, consulter plusieurs sources, appeler des outils et agir dans votre environnement au nom d'un utilisateur.

C'est précisément ce qui la rend intéressante pour une startup : un agent peut qualifier une demande, chercher l'information utile, préparer une réponse et déclencher une action. Mais c'est aussi ce qui rend son déploiement plus exigeant. Plus un système peut agir, plus une erreur de compréhension, une instruction malveillante ou un accès trop large peut produire des conséquences réelles.

La CNIL et le Conseil de l'IA et du Numérique ont récemment décrit ce changement d'échelle : multiplication des sources, circulation parfois opaque des données, mémoire persistante et capacité d'action autonome. L'IA agentique mérite donc une gouvernance différente d'une simple fonctionnalité de génération de texte.

Voici les sept garde-fous que je recommande avant de donner à un agent un accès à des données ou à des outils de production.

1. Commencer par une action précise, pas par un agent généraliste

Le premier risque est de construire un agent capable de "gérer le support", "piloter les opérations" ou "faire gagner du temps" sans définir ce qu'il a réellement le droit de faire.

Une bonne première version répond à une question beaucoup plus étroite :

• quelles entrées l'agent reçoit-il ?
• quelles sources peut-il consulter ?
• quelles décisions peut-il prendre seul ?
• quelles actions peut-il déclencher ?
• dans quels cas doit-il s'arrêter et demander une validation humaine ?

Un agent qui classe des tickets et propose une réponse n'a pas besoin du même périmètre qu'un agent qui modifie un compte client. La fonctionnalité doit être limitée par le risque de l'action, pas par la liste des outils disponibles dans votre stack.

2. Donner à l'agent le minimum de droits nécessaire

Un agent ne devrait jamais hériter automatiquement des droits de la personne qui l'a configuré. Il doit disposer d'une identité technique distincte, de permissions explicites et d'un périmètre vérifiable.

En pratique, cela signifie :

• un compte ou un rôle dédié à l'agent ;
• des permissions séparées pour lire, créer, modifier et supprimer ;
• des accès limités aux espaces de données réellement utiles ;
• aucune capacité d'administration par défaut ;
• des secrets stockés dans un gestionnaire adapté, jamais dans un prompt ou un fichier de configuration exposé.

Cette séparation réduit l'impact d'une erreur et rend l'audit possible. Elle évite surtout le scénario classique où un agent reçoit un accès global simplement parce que c'était le chemin le plus rapide pour faire fonctionner le prototype.

3. Séparer la préparation de l'action et son exécution

Faire rédiger un e-mail, proposer un remboursement et envoyer effectivement le remboursement ne sont pas la même opération.

Pour les actions sensibles, je recommande un parcours en deux temps :

1. l'agent prépare une proposition structurée ;
2. une règle métier ou un humain valide avant l'exécution.

Cette séparation est particulièrement utile pour l'envoi de messages externes, les changements de droits, les suppressions, les remboursements, les déploiements et toute action irréversible. Un agent peut être autonome sur les tâches à faible impact et rester soumis à approbation sur les actions qui engagent l'entreprise ou ses clients.

L'autonomie n'est pas un interrupteur. Elle se règle action par action.

4. Traiter les données comme un flux à cartographier

Quand un agent consulte un CRM, une base documentaire, une boîte e-mail et un outil métier, la question n'est plus seulement "quel modèle utilisons-nous ?". Il faut savoir quelles données circulent, entre quels services, pour quelle finalité et pendant combien de temps.

Avant la mise en production, documentez au minimum :

• les sources consultées par l'agent ;
• les données personnelles susceptibles d'être lues ou produites ;
• les fournisseurs externes appelés par le workflow ;
• les journaux et les mémoires persistantes ;
• les durées de conservation ;
• les personnes ou systèmes qui peuvent accéder aux sorties.

La CNIL rappelle que les systèmes agentiques peuvent multiplier les traitements et rendre la circulation des données difficile à appréhender. Une cartographie simple, tenue à jour, permet de repérer les transferts inutiles et les zones où la responsabilité devient floue.

Si l'agent manipule des données personnelles, le sujet doit être traité avec votre DPO ou votre conseil juridique. L'architecture technique ne remplace pas l'analyse de conformité, mais elle doit la rendre possible.

5. Considérer les instructions externes comme non fiables

Un agent qui lit un e-mail, une page web, un ticket ou un document importé lit potentiellement du contenu contrôlé par un tiers. Ce contenu peut contenir des instructions qui cherchent à détourner son comportement : c'est le principe de l'injection indirecte de prompt.

La consigne "résume ce document" ne doit pas devenir "exécute toutes les instructions trouvées dans ce document".

Quelques protections concrètes :

• distinguer les instructions de contrôle des données à analyser ;
• ne jamais laisser un document lu modifier silencieusement les règles de l'agent ;
• filtrer et normaliser les entrées avant de les transmettre aux outils ;
• limiter les actions possibles après la lecture d'une source non fiable ;
• tester des documents contenant volontairement des instructions adverses.

L'OWASP classe la prompt injection parmi les risques majeurs des applications fondées sur des LLM. Ce n'est pas un problème que l'on règle avec une phrase magique dans le prompt système. La défense doit se trouver dans les permissions, les validations et l'isolement des outils.

6. Valider les sorties avant de les envoyer dans le système

Une sortie générée par un modèle ne doit pas être considérée comme une donnée métier fiable par défaut. Elle peut être incomplète, mal formée, trop permissive ou dangereuse dans le contexte où elle est réutilisée.

Chaque sortie qui alimente un autre système doit passer par des contrôles adaptés :

• schéma strict pour les données structurées ;
• validation des identifiants et des droits ;
• échappement selon le contexte, notamment HTML, SQL ou commande ;
• limites de taille, de montant et de fréquence ;
• détection des champs manquants ou incohérents ;
• refus explicite en cas d'incertitude.

Ne demandez pas seulement à l'agent de renvoyer du JSON. Vérifiez réellement que le JSON respecte le contrat attendu, puis appliquez les règles métier en dehors du modèle.

Cette frontière entre la sortie du modèle et l'exécution applicative est l'un des endroits où l'on voit la différence entre une démonstration et un système exploitable.

7. Observer, rejouer et couper

Un agent autonome sans traces exploitables est impossible à diagnostiquer. Vous devez pouvoir répondre à trois questions après chaque action :

1. quelles données l'agent a-t-il reçues ?
2. quels outils a-t-il appelés, avec quels paramètres ?
3. pourquoi l'action a-t-elle été autorisée ?

Journalisez les étapes utiles sans recopier inutilement des données personnelles ou des secrets. Ajoutez des identifiants de corrélation, des durées, des résultats de validation et la décision finale. Conservez aussi un moyen de rejouer un cas anonymisé en environnement de test.

Enfin, prévoyez un bouton d'arrêt réel : désactivation de l'agent, révocation de ses jetons, blocage d'un outil ou arrêt d'une file de traitement. Une procédure d'urgence qui exige de retrouver manuellement six variables d'environnement n'est pas une procédure d'urgence.

Une checklist avant d'accorder un accès de production

Avant le premier déploiement, je passe cette liste avec l'équipe :

• le cas d'usage et les actions autorisées sont écrits en une page ;
• l'agent utilise une identité technique dédiée ;
• chaque outil dispose de permissions minimales ;
• les actions sensibles nécessitent une validation ;
• les données et les fournisseurs impliqués sont cartographiés ;
• les contenus externes sont traités comme des données non fiables ;
• les sorties sont validées par l'application ;
• les appels d'outils et les décisions sont traçables ;
• une procédure de coupure a été testée ;
• un jeu de tests couvre les erreurs, les abus et les cas limites.

Si plusieurs réponses sont non, l'agent n'est probablement pas encore prêt pour la production. Il peut rester utile en environnement de test, avec des données synthétiques et des actions simulées.

FAQ : déployer une IA agentique en entreprise

Quelle est la différence entre une IA générative et une IA agentique ?

Une IA générative produit principalement une réponse à partir d'une demande. Une IA agentique peut enchaîner des étapes, utiliser des outils, consulter plusieurs sources et agir sur un environnement. Cette capacité d'action augmente à la fois le potentiel d'automatisation et les risques à encadrer.

Faut-il laisser un humain valider toutes les actions d'un agent ?

Non. La validation humaine doit être proportionnée à l'impact de l'action. Une classification réversible peut être automatisée, tandis qu'un remboursement, une suppression ou un changement de droits devrait généralement être contrôlé par une règle métier ou une personne habilitée.

Comment sécuriser un agent qui lit des e-mails ou des documents ?

Considérez le contenu lu comme une donnée non fiable, pas comme une nouvelle consigne. Séparez les instructions de contrôle du contenu analysé, limitez les permissions de l'agent, validez les actions déclenchées et testez des documents contenant des tentatives d'injection indirecte.

L'IA agentique est-elle compatible avec le RGPD ?

Elle n'est pas automatiquement conforme ou non conforme. La réponse dépend du traitement, des données, des finalités, des acteurs et des mesures mises en place. La CNIL souligne que le RGPD et les règles européennes applicables à l'IA encadrent déjà ces usages, mais que l'autonomie, la mémoire persistante et la multiplicité des services rendent leur mise en œuvre plus complexe.

Peut-on mettre un agent en production sans observabilité ?

C'est une mauvaise idée. Sans journal des entrées utiles, des appels d'outils, des validations et des résultats, vous ne pourrez ni comprendre un incident, ni mesurer la qualité, ni couper rapidement un comportement indésirable.

Ce que je recommande, en tant que CTO hands-on

L'IA agentique peut devenir un vrai levier d'automatisation, mais elle ne doit pas être introduite comme une couche de magie au-dessus d'un système existant. Elle doit être conçue comme un composant logiciel avec une identité, des permissions, des contrats, des tests, de l'observabilité et un plan d'arrêt.

C'est le type de sujet que je traite dans une mission de structuration d'un projet IA et automatisation : cadrer le cas d'usage, choisir le niveau d'autonomie pertinent, sécuriser les intégrations et mesurer la valeur réelle. Si votre équipe a déjà un agent en fonctionnement, un audit technique permet aussi d'identifier les accès trop larges, les sorties non contrôlées et les angles morts opérationnels.

Le bon agent n'est pas celui qui fait tout sans demander. C'est celui qui sait exactement ce qu'il peut faire, ce qu'il doit vérifier et quand il doit s'arrêter.

Sources et références

• CNIL et CIANum, IA agentique et données personnelles, 20 juillet 2026
• CNIL, IA : professionnels, comment se mettre en conformité ?
• OWASP GenAI Security Project, Top 10 for LLM Applications