Agent IA en entreprise : choisir un cas d’usage et garder le contrôle

Un agent IA en entreprise est un système qui reçoit un objectif, s’appuie sur un modèle de langage pour choisir les étapes à suivre et utilise des outils pour y parvenir : consulter des documents, interroger une application, rédiger une réponse ou déclencher une action. Pour un premier projet, la question utile n’est pas « quel agent choisir ? », mais « quelle tâche lui confier, avec quels accès, et qui valide avant que l’action produise ses effets ? »

L’usage progresse vite. Selon l’Insee, 18 % des entreprises françaises de 10 salariés ou plus utilisaient au moins une technologie d’IA en 2025, contre 10 % en 2024, et 58 % de celles de 250 salariés ou plus. Ce guide propose une méthode pour passer d’une idée à un pilote maîtrisé : choisir le cas d’usage, limiter les données et les actions, placer la validation humaine, puis industrialiser. Vous pouvez télécharger la grille de qualification utilisée dans les exemples.

Agent IA, assistant, workflow : de quoi parle-t-on ?

Le mot « agent » recouvre des réalités très différentes. Le critère le plus utile est simple : qui décide de l’étape suivante ?

Notre comparatif AI Assistant vs AI Agent détaille ces différences. Côté réglementation, le terme n’a pas de définition propre : la FAQ de la Commission européenne sur le règlement IA précise que les agents relèvent des définitions générales des systèmes d’IA.

En pratique, les projets réussis combinent souvent les trois : un workflow porte le processus et ses règles, l’agent prépare les éléments qui demandent de la lecture ou de la rédaction, et une personne décide aux étapes qui engagent l’entreprise.

Ce qu’un agent peut faire, et ses limites

Un agent apporte surtout de la valeur sur des tâches de lecture, de tri et de préparation :

• retrouver et synthétiser l’information utile dans des procédures, des contrats ou des historiques ;
• classer une demande, extraire des informations d’un document, signaler une pièce manquante ;
• rédiger un brouillon de réponse, de synthèse ou de compte rendu ;
• enchaîner plusieurs consultations pour préparer un dossier avant décision.

Ses limites sont connues et doivent être traitées dès la conception :

• Des réponses plausibles mais fausses, d’autant plus difficiles à repérer qu’elles sont bien rédigées.
• Des résultats variables : deux demandes proches ne produisent pas toujours la même proposition.
• Des instructions cachées dans un e-mail ou un document traité, qui tentent de détourner l’agent de sa tâche.
• Une « agentivité excessive » : l’OWASP classe ce risque parmi les dix principaux des applications fondées sur les grands modèles de langage (LLM06:2025 Excessive Agency). Il naît de fonctionnalités, de permissions ou d’une autonomie plus larges que nécessaire.

L’ANSSI en tire des règles concrètes dans ses recommandations de sécurité pour un système d’IA générative : proscrire l’usage automatisé de systèmes d’IA pour des actions critiques sur le système d’information (R9), limiter les actions automatiques d’un système d’IA qui traite des entrées non maîtrisées (R27) et journaliser l’ensemble des traitements, y compris les appels aux extensions (R29).

Choisir un premier cas d’usage pour un agent IA

La CNIL recommande de partir d’un besoin concret plutôt que d’une technologie. Un bon premier cas est une tâche fréquente, dont le résultat est vérifiable rapidement, dont les erreurs sont rattrapables et dont un responsable métier accepte de porter le pilote.

Éliminer d’abord les conditions bloquantes

Avant toute notation, écartez ou reportez le cas si l’une de ces situations se présente :

• aucun responsable métier n’accepte de porter le cas et de contrôler les résultats ;
• les données nécessaires ne peuvent pas être utilisées pour cette finalité ou par ce fournisseur ;
• l’agent devrait décider seul d’une mesure produisant des effets importants pour une personne ;
• une erreur ne pourrait être ni détectée ni corrigée avant de produire ses effets ;
• le résultat attendu ne peut pas être décrit assez précisément pour être vérifié ;
• les actions demandées exigent des droits d’écriture larges qui ne peuvent pas être restreints.

Noter les cas restants

La grille du modèle note dix critères de 1 à 4, pondérés selon leur importance :

Dans l’exemple fourni, trois cas fictifs obtiennent 79 (achats), 65 (RH) et 77 (qualité) sur 100. Le cas RH est moins bien placé non parce qu’il serait inutile, mais parce qu’il touche des données personnelles et que ses sources sont moins structurées. Les seuils proposés, 75 pour un candidat au pilote et 55 pour un cas à retravailler, sont une convention à ajuster. La grille sert à comparer et à argumenter, pas à décider à la place des responsables.

Données, actions autorisées et supervision

Limiter les données et les droits de l’agent

Un agent agit avec les droits qu’on lui donne. Appliquez-lui les mêmes règles qu’à un compte utilisateur : périmètre défini, droits minimaux, responsable nommé et revue régulière. L’ANSSI recommande de revoir les droits d’accès des outils d’IA dès leur activation, puis régulièrement (R35). Notre guide de la gestion des habilitations fournit une matrice des droits : ajoutez-y un profil par agent, comme pour un compte technique ; le modèle en donne un exemple.

Deux règles évitent beaucoup de difficultés : l’agent ne doit jamais disposer de plus de droits que la personne qui le sollicite, et chaque source de données doit être explicitement autorisée pour cet usage. Pour les données personnelles, associez votre DPO dès le cadrage : finalité, minimisation, hébergement du modèle et conditions de réutilisation par le fournisseur.

Choisir un niveau d’autonomie par action

L’autonomie ne se décide pas pour l’agent dans son ensemble, mais action par action :

Commencez bas. Un agent qui propose (niveau 1) apporte souvent une bonne part du gain sur les tâches de préparation. Ne montez d’un niveau qu’après avoir mesuré le taux de propositions corrigées sur un volume suffisant.

Concevoir une validation humaine réelle

Une validation n’a de valeur que si le valideur peut réellement juger. Il doit voir la proposition, les sources utilisées et les éléments qui l’ont motivée ; pouvoir corriger ou rejeter sans friction ; et disposer du temps nécessaire. Pour les systèmes à haut risque, le règlement européen sur l’IA nomme le risque à éviter (article 14) : le biais d’automatisation, c’est-à-dire la tendance à se fier à la sortie d’un système sans l’examiner.

Surveillez donc le taux d’acceptation sans modification. S’il approche 100 % alors que le contrôle prend quelques secondes, la validation est peut-être devenue une formalité. Prévoyez aussi l’inverse : un moyen simple d’arrêter l’agent et de reprendre le traitement manuellement. La note exploratoire publiée par la CNIL et le CIANum en juillet 2026 évoque d’ailleurs une validation humaine pour les décisions les plus critiques et un bouton d’arrêt d’urgence à la main de l’utilisateur.

Tracer les propositions et les décisions

Conservez, pour chaque dossier, l’entrée reçue, les sources consultées, la proposition de l’agent, la décision humaine, son auteur et sa date. Ces traces servent à expliquer une décision, à analyser les erreurs et à améliorer les instructions. Définissez leur durée de conservation et les personnes autorisées à les consulter : elles contiennent souvent des données sensibles.

Agent IA et réglementation : ce que prévoient les textes en octobre 2026

Les obligations dépendent de l’usage, pas du mot « agent ». Quelques repères, sans valeur d’avis juridique :

• Usages à haut risque. Le règlement (UE) 2024/1689 sur l’IA classe notamment certains usages liés à l’emploi et à la gestion des travailleurs parmi les systèmes à haut risque (annexe III). Pour ces systèmes, il exige un contrôle humain effectif (article 14) et impose aux déployeurs de le confier à des personnes disposant des compétences, de la formation et de l’autorité nécessaires, ainsi que de conserver les journaux au moins six mois (article 26). En vertu du règlement (UE) 2026/1744, dit omnibus numérique sur l’IA, ces obligations s’appliquent aux systèmes de l’annexe III à compter du 2 décembre 2027.
• Maîtrise de l’IA. Depuis l’omnibus, l’article 4 demande aux fournisseurs et aux déployeurs de prendre des mesures pour favoriser la maîtrise de l’IA par leur personnel.
• Décisions automatisées. L’article 22 du RGPD encadre les décisions fondées exclusivement sur un traitement automatisé qui produisent des effets juridiques ou significatifs pour une personne.

Faites qualifier votre cas par vos juristes et votre DPO avant le pilote, surtout s’il touche des salariés, des candidats ou des clients.

Agent IA en entreprise : trois scénarios métier

Les scénarios suivants décrivent des organisations fictives. Ils illustrent des choix de conception ; ils ne présentent ni des résultats clients ni des fonctions préconfigurées.

Achats : pré-analyser les demandes d’achat

À chaque demande soumise, l’agent vérifie la complétude, propose une catégorie, signale un fournisseur absent du référentiel ou un contrat cadre existant, puis rédige une synthèse pour le valideur. Sans validation, il peut seulement ajouter un commentaire de pré-analyse et demander une pièce manquante : deux actions réversibles. Il ne peut ni approuver, ni refuser, ni créer un fournisseur, ni modifier un montant.

Le valideur prévu par le circuit voit la synthèse à côté des pièces sources et décide. Le pilote suit le délai entre soumission et décision, le taux de demandes renvoyées pour pièce manquante et la part des synthèses corrigées.

RH : répondre aux questions administratives des salariés

L’agent répond aux questions générales (congés, attestations, mutuelle) en citant la procédure ou l’accord dont la réponse est tirée. Pendant le pilote, il n’accède à aucun dossier individuel : toute question qui porte sur une situation personnelle est transmise à un gestionnaire RH, avec un brouillon de réponse si les sources le permettent. Au démarrage, un gestionnaire relit aussi les réponses générales avant envoi (niveau 1) ; leur envoi direct n’est envisagé qu’après mesure du taux de réponses corrigées, car une réponse envoyée ne peut pas être reprise.

Ce périmètre volontairement étroit tient compte de la sensibilité des données et du fait que les usages liés à la gestion des travailleurs peuvent relever du haut risque. Indicateurs : questions résolues sans escalade, réponses signalées incorrectes et délai de réponse.

Qualité : pré-qualifier les fiches de non-conformité

Lorsqu’un opérateur crée une fiche, l’agent propose un code défaut et une gravité, rapproche la fiche de non-conformités similaires sur le même article et prépare une description structurée. Le responsable qualité confirme ou corrige chaque élément : la gravité déclenche des obligations, elle reste donc une décision humaine. L’agent ne clôt aucune fiche et ne décide pas de la libération d’un lot.

Le pilote mesure le délai de qualification et le taux de codes défauts corrigés. Une alerte signale toute non-conformité proche d’un cas récent, pour éviter qu’une gravité sous-estimée retarde le traitement.

Une grille de qualification à télécharger

Télécharger la grille de qualification d’un cas d’usage d’agent IA (.xlsx) — modèle gratuit, sans formulaire.

Le classeur réunit les conditions bloquantes, la grille pondérée avec calcul du score, les trois scénarios détaillés (données, actions permises, soumises à validation ou interdites, traces, indicateurs), les niveaux d’autonomie par action et un plan de préparation du pilote. Les notes des exemples sont illustratives ; des colonnes vierges servent à évaluer votre propre cas.

Complétez la grille avec le responsable métier et l’équipe informatique : les écarts de notation révèlent souvent les points à clarifier avant le pilote, par exemple la disponibilité réelle des données ou la personne qui validera.

Passer du pilote à une application maintenable

Un pilote convaincant ne suffit pas à mettre un agent en service. Avant d’élargir le périmètre :

1. Mesurez une référence : délai, volume et taux de retour avant le pilote, sur une période comparable.
2. Constituez un jeu de test : dossiers représentatifs, cas limites et tentatives hors périmètre, avec le résultat attendu. Un cahier de recette informatique s’y prête bien.
3. Séparez les environnements et versionnez les instructions, les sources et les règles : une modification se teste avant d’atteindre les utilisateurs.
4. Nommez les responsables : propriétaire métier, administrateur, personne qui traite les signalements.
5. Suivez le coût par dossier et les incidents, puis fixez une date de revue avec des critères de poursuite, d’ajustement ou d’arrêt.

Un agent utile vit rarement seul : il s’insère dans un processus, avec un formulaire d’entrée, des rôles, des étapes de validation et un historique. C’est cette application qui rend le contrôle humain concret et durable. Le guide AI-driven automation replace ces choix dans une démarche d’automatisation plus large.

Avec Flowy AI, vous décrivez votre application en français : Flowy AI en génère une première version, avec modèle de données, interfaces, workflow et règles métier, que vous modifiez ensuite dans les éditeurs de Softyflow. Le guide Prompt to App détaille cette démarche. Dans Softyflow, les étapes de validation deviennent des tâches attribuées à des rôles ; la délégation datée, les relances programmées et le journal d’audit complètent le dispositif. L’agent lui-même peut être un service d’IA externe appelé par API depuis le processus : sa logique, ses connexions et ses droits se paramètrent ensuite et se vérifient en démonstration sur votre propre cas.

Décrire mon application à Flowy AI en précisant l’étape où une personne doit valider.