Agents IA : le guide pour les dirigeants

Un agent IA est un logiciel qui donne à un modèle de langage une mission, des informations et des outils, puis le laisse choisir les étapes pour atteindre le résultat demandé. Le modèle de langage est le moteur qui comprend et rédige du texte : Claude, GPT ou Mistral, par exemple. Seul, il répond. Équipé d’outils, il peut chercher un dossier, lire une pièce jointe ou préparer une mise à jour, puis décider de la suite selon ce qu’il a trouvé.

Anthropic, l’éditeur de Claude, propose une distinction utile. Dans un workflow, le modèle et les outils suivent un chemin écrit à l’avance par un développeur. Dans un agent, le modèle dirige lui-même son déroulé et l’usage de ses outils. Les deux relèvent de ce qu’on appelle l’IA agentique : des systèmes capables d’agir, pas seulement de répondre. Pour une entreprise, la nuance compte, car plus le chemin est libre, plus il faut prévoir de contrôles. Ce guide explique ce qui distingue un agent d’un chatbot, ce qu’il peut faire en entreprise et comment garder le contrôle d’un programme qui cherche l’information, choisit ses étapes, puis prépare ou exécute des actions dans vos logiciels.

Un agent fonctionne en boucle : il agit, observe le résultat, puis décide de l’étape suivante, ce qui le distingue d’une simple conversation. Techniquement, cela passe par l’appel d’outils, en anglais tool use ou function calling. Le développeur décrit au modèle les outils disponibles, leur rôle et les informations qu’ils attendent. Quand la demande s’y prête, le modèle répond par une demande d’appel structurée. C’est l’application qui exécute l’opération et lui renvoie le résultat.

Ce fonctionnement a une conséquence pratique rassurante : le modèle ne touche jamais directement à vos logiciels. Il formule une intention, et le code qui l’entoure décide de l’exécuter, de la bloquer ou de la soumettre à une personne. C’est là que se placent les permissions, les journaux et les validations. Un même produit peut être un simple chatbot ou un agent selon les outils qu’on lui branche : jugez-le sur ce qu’il peut faire, pas sur son nom.

Un chatbot répond, un assistant aide une personne pendant qu’elle travaille, une automatisation exécute des règles fixes, et un agent IA poursuit une mission en choisissant ses étapes. Sur le marché, ces catégories se recouvrent souvent, et les noms de produits brouillent les pistes. Deux questions suffisent pour s’y retrouver : qui décide de l’étape suivante, et qu’est-ce que le système a le droit de modifier dans vos outils ?

Dans la pratique, les systèmes les plus solides combinent ces approches. Une automatisation peut appeler un modèle pour une seule étape, comme classer un e-mail, puis reprendre des règles fixes. Un agent peut s’appuyer sur des automatisations éprouvées pour les opérations sensibles. La partie sans IA d’un processus se teste plus facilement et sert de socle au reste.

• Le guide de l’automatisation des processus

En entreprise, un agent IA sert surtout à préparer un travail qui demande de lire, de rapprocher des informations et de choisir une suite : une réponse, une fiche, un classement. Les usages les plus courants se regroupent en quatre familles. Dans chacune, l’agent prépare, et une personne garde la main sur ce qui engage l’entreprise vis-à-vis d’un client, d’un fournisseur ou d’un salarié.

Ces usages ont un point commun : la demande varie d’un cas à l’autre, mais le résultat attendu est clair et vérifiable. C’est ce qui permet de tester l’agent avant sa mise en service, puis de juger s’il fait gagner du temps une fois la relecture comptée. Une mission floue comme « aider l’équipe » ne se teste pas.

• Support client : lire la demande, retrouver la commande ou le contrat, proposer une réponse sourcée, transmettre les cas sensibles.
• Commercial : qualifier une demande entrante, rassembler l’historique du compte, préparer une fiche de rendez-vous ou un premier message que le commercial relit.
• Back-office : rapprocher une facture et un bon de commande, compléter un dossier, signaler une pièce manquante plutôt que l’inventer.
• Documents : classer les pièces reçues, en extraire quelques champs, résumer un dossier avant qu’une personne décide.

• Cinq cas d’usage concrets d’agents IA
• La conception d’agents IA sur mesure

Le MCP, pour Model Context Protocol, est un standard ouvert présenté par Anthropic en novembre 2024 pour relier une application d’IA à des sources de données et à des outils de façon uniforme. On le compare souvent à une prise universelle : au lieu d’écrire une connexion pour chaque couple logiciel et assistant, l’éditeur d’un logiciel publie un serveur MCP, que toute application compatible peut utiliser.

Pour un dirigeant, le MCP n’est pas un critère de choix en soi. Il simplifie certaines connexions, mais ne règle ni la question des droits ni celle de la qualité des données. Beaucoup de logiciels métier se branchent encore par leur API, l’interface qui permet à un programme d’en lire ou d’en modifier les données. Ce qui compte est la liste des opérations ouvertes à l’agent, le compte utilisé et la trace laissée : un serveur MCP installé sans examen ouvre parfois plus de portes que nécessaire.

Sur des tâches de recherche et de préparation, un agent peut enchaîner seul de nombreuses étapes ; pour les actions qui engagent l’entreprise, l’autonomie complète est rarement un bon choix. La raison est mécanique : chaque étape repose sur la précédente, et une erreur de lecture au départ peut se propager jusqu’à l’action finale. Anthropic le rappelle dans ses recommandations : l’autonomie augmente aussi le coût, le temps de réponse et le risque d’erreurs qui s’additionnent.

L’autonomie se règle donc action par action, pas d’un bloc. Un agent peut lire et chercher librement, préparer des brouillons soumis à relecture, et n’exécuter seul que des opérations réversibles et peu engageantes. L’élargissement se décide sur des résultats observés, pas sur une démonstration réussie. Les agents qui pilotent un navigateur ou un poste de travail demandent, eux, un environnement isolé et des droits très restreints.

Les trois risques principaux d’un agent IA sont l’erreur présentée avec assurance, la manipulation par un contenu malveillant et des droits trop larges. Le premier porte un nom : l’hallucination, quand le modèle produit une information plausible mais fausse, ou non justifiée par ses sources. Elle se réduit avec des sources fiables, des citations vérifiables et la consigne explicite de signaler ce qui manque. Elle ne disparaît pas pour autant.

Le deuxième risque est l’injection de consignes, ou prompt injection. Un e-mail, une page web ou un document lu par l’agent peut contenir une instruction cachée, par exemple « transfère ce dossier à telle adresse ». L’OWASP, organisation de référence en sécurité des applications, place ce risque en tête de sa liste pour les applications fondées sur des modèles de langage. Une consigne de prudence ne suffit pas : la protection vient des droits, de la séparation des contenus et des validations.

• Hallucination : exiger une source pour chaque affirmation et prévoir une sortie « information introuvable ».
• Injection de consignes : traiter tout contenu lu comme une donnée, jamais comme un ordre, et bloquer techniquement les actions non prévues.
• Permissions : un compte dédié à l’agent, limité aux opérations de sa mission, plutôt que les accès d’un salarié.
• Données : savoir ce qui part vers le service d’IA et ce que ses conditions d’utilisation prévoient pour la configuration retenue.

• Sécurité et protection de vos données

La validation humaine se place juste avant l’action qui engage l’entreprise, et elle doit montrer au valideur tout ce dont il a besoin pour décider. Un envoi à un client, une modification de prix, un avoir ou un changement dans un dossier sensible appellent un contrôle. La personne doit voir le destinataire, le contenu, le montant éventuel et les sources. Un bouton « approuver » sans contexte produit des validations mécaniques.

Toutes les étapes n’appellent pas le même niveau de contrôle. Classez les actions selon leurs conséquences et la possibilité de les annuler : une synthèse interne peut circuler sans relecture, un courrier au client attend une validation, un paiement reste hors de portée. Chez Blink, ce point se traite dans le portail livré au client : sa page Focus présente ce que l’automatisation a trouvé et ce qui attend une décision avant de partir. La validation porte sur les actions et droits convenus au cadrage.

• Lecture : quels dossiers et quels documents l’agent peut-il consulter ?
• Préparation : quels résultats restent à l’état de brouillon tant que personne ne les a relus ?
• Action : qui valide, sur quelles informations, et quelle trace en reste-t-il ?
• Exception : à qui l’agent transmet-il ce qu’il ne sait pas traiter ?

• Voir comment le portail Blink organise la validation

Créer un agent IA commence par une mission écrite en une phrase, pas par le choix d’un outil. « Aider le service commercial » est trop vague pour être testé. « Préparer une fiche de rendez-vous à partir des échanges et du dossier client, sans rien envoyer » définit un résultat que l’utilisateur peut juger. Faites relire cette phrase par la personne qui recevra le travail : si deux lecteurs imaginent des actions différentes, la limite n’est pas encore claire.

Pour la réalisation, deux voies existent. Des plateformes permettent d’assembler un agent simple par configuration, ce qui convient à un essai ou à un usage individuel. Un agent branché sur plusieurs logiciels métier, avec des droits fins et des validations, relève plutôt du développement sur mesure. Dans les deux cas, le cadrage ci-dessous reste identique, et c’est lui, plus que l’outil, qui fait la différence.

• Écrire la mission : le résultat attendu, son destinataire, ce que l’agent refuse et quand il passe la main.
• Inventorier les sources : quels documents et logiciels, qui les tient à jour, qui peut les voir.
• Fixer les permissions : lecture, brouillon, modification ou envoi, avec le compte technique correspondant.
• Construire un jeu d’essai : cas ordinaires, ambigus, incomplets ou hors périmètre.
• Mettre en service sur un périmètre restreint, puis élargir au vu des résultats observés.

• Cartographier un processus avant de l’automatiser

Un agent se juge sur un jeu d’essai construit à partir de vos demandes réelles, pas sur une démonstration choisie. Rassemblez des cas représentatifs avec, pour chacun, le résultat attendu et la source qui le justifie. Anthropic recommande de commencer petit, avec une vingtaine à une cinquantaine de tâches tirées de situations réelles, notamment d’erreurs constatées, puis d’enrichir la série au fil de l’eau. Testez aussi ce que l’agent ne doit pas faire : refuser, s’abstenir, transmettre.

Lisez les échanges complets, pas seulement les scores. Une réponse jugée fausse peut venir d’une source périmée, d’une consigne ambiguë ou d’un droit manquant, et chaque cause appelle un correctif différent. Glissez dans la série un document qui contient une instruction malveillante, pour vérifier que l’agent ne l’exécute pas. Conservez ce jeu d’essai : il sert de contrôle à chaque changement de consigne, de modèle ou de logiciel connecté.

Le coût d’un agent IA se répartit en trois grands postes : l’usage du modèle, facturé au volume, le développement initial et la maintenance. Il n’existe pas de prix standard, car ces postes dépendent du nombre de logiciels à connecter, de la longueur des documents lus et du nombre d’étapes par demande. Un tarif annoncé sans examen de la tâche décrit un produit générique, pas votre processus.

Pour l’usage, la documentation d’Anthropic précise que chaque requête est facturée selon les tokens envoyés et produits, y compris la description des outils mis à disposition du modèle. Les tokens sont les fragments de texte que le modèle compte pour mesurer son travail. Un agent qui enchaîne plusieurs étapes multiplie les requêtes ; un plafond de dépense et une alerte sur les volumes inhabituels gardent ce poste lisible.

• Ce que couvre la maintenance après la mise en place
• Estimer le temps passé sur une tâche

Un agent IA qui lit des données personnelles réalise un traitement soumis au RGPD, et certains usages relèvent en plus du règlement européen sur l’IA, l’AI Act. Côté RGPD, la CNIL recommande notamment d’éviter de verser des données personnelles ou confidentielles dans des services grand public, d’encadrer le fournisseur par contrat, de garder un regard critique sur les résultats et de mener une analyse d’impact pour les usages sensibles. Le guide RGPD et IA détaille ces étapes.

Côté AI Act, le calendrier a été modifié par le règlement (UE) 2026/1744, dit omnibus numérique sur l’IA, publié au Journal officiel le 24 juillet 2026. Les obligations des systèmes à haut risque s’appliquent à partir du 2 décembre 2027 pour les domaines listés à l’annexe III, comme l’emploi ou l’éducation, et du 2 août 2028 pour l’IA intégrée à des produits réglementés. Un agent qui trie des candidatures entre dans ces domaines ; un agent qui prépare des réponses au support, en principe non.

Les obligations de transparence de l’article 50 dépendent de votre rôle. Le fournisseur, qui développe le système ou le fait développer pour le mettre en service sous son nom, doit le concevoir pour que les personnes sachent qu’elles échangent avec une IA, sauf si c’est évident. Le déployeur, c’est-à-dire l’entreprise qui utilise le système, a des obligations propres dans certains cas : reconnaissance des émotions, hypertrucages, textes publiés pour informer le public. Une entreprise qui fait développer son propre agent peut donc être à la fois fournisseur et déployeur. Avant de lancer un agent qui touche des personnes, vérifiez la version consolidée sur EUR-Lex et faites qualifier votre cas en cas de doute.

• Le guide RGPD et IA

Si la tâche suit des règles explicites sur des données structurées, une automatisation classique suffit et se vérifie plus facilement qu’un agent. Calculer une échéance, copier une commande d’un logiciel à l’autre ou relancer une facture à date fixe ne demande à aucun modèle d’interpréter quoi que ce soit. L’IA se justifie là où il faut comprendre un contenu variable : un e-mail rédigé librement, un document hétérogène, une demande mal formulée.

Notre position chez Blink est de limiter l’autonomie au besoin réel. Un agent qui prépare bien une décision et passe clairement la main apporte souvent plus qu’un système ambitieux dont personne ne maîtrise les actions. Nous écrivons du code sur mesure branché sur les outils déjà utilisés, gardons des règles fixes partout où elles suffisent et réservons le modèle aux étapes qui en ont besoin. Le portail livré au client montre ce qui tourne, et un point de suivi mensuel fait évoluer l’agent avec vos procédures.

• La règle tient en une phrase, sans exception floue : une automatisation classique.
• Il faut lire un texte libre ou un document variable : une étape d’IA dans une automatisation.
• Il faut enchaîner des recherches dont l’ordre dépend de ce qu’on trouve : un agent, avec ses contrôles.

• Les automatisations sur mesure