Assistant, agent IA ou automatisation : choisir selon le travail à accomplir

Trois mots qui ne décrivent pas la même chose

Je préfère examiner une tâche avant de choisir son niveau d’autonomie. Une démonstration qui semble tout faire seule peut être séduisante ; elle ne répond pas encore à la question de ce que votre organisation veut lui laisser faire. Vous pouvez vouloir une proposition très élaborée et conserver une validation avant son utilisation.

Dans cet article, « assistant » désigne d’abord une façon de travailler avec un outil, souvent par conversation. « Automatisation » désigne un déroulement prévu, qui peut intégrer de l’IA. « Agent » désigne un système capable de choisir des étapes ou des outils pendant l’exécution. Anthropic distingue justement workflows prédéfinis et agents guidant dynamiquement leur processus ; ce découpage n’est pas une définition universelle. ^[1]

Une fenêtre de discussion peut déclencher une automatisation. Un assistant peut aussi proposer un mode agentique. Demandez donc une description de la chaîne réelle : entrée, interprétation, décisions, outils, sortie et contrôles. Le nom affiché dans l’interface n’est qu’un début de discussion.

Comparer sur trois questions concrètes

Voici une grille de lecture proposée pour un premier échange avec un prestataire ou votre équipe technique. Elle ne classe pas les produits : elle rend visibles les choix à examiner.

Aucune colonne n’est dispensée de contrôle. Une règle fixe mal configurée peut envoyer un document au mauvais destinataire. Un agent limité à la lecture peut présenter moins de conséquences directes qu’une automatisation autorisée à modifier des données. Évaluez séparément le choix du chemin et le pouvoir d’action.

Exemple fictif : préparer une réponse à une demande de prestation

Une petite entreprise reçoit une demande : « Pouvez-vous intervenir auprès de nos responsables en novembre ? » Le résultat recherché est un brouillon qui reprend le public, les questions à préciser et les documents utiles. Il ne faut ni promettre une disponibilité non confirmée ni envoyer un prix inventé.

Option assistant : une personne fournit le message et les documents autorisés, demande un brouillon puis le vérifie. Cette organisation conserve le choix des informations et de la suite du travail dans les mains de la personne. Elle peut suffire lorsque les demandes sont peu nombreuses ou très différentes.

Option automatisation : le système récupère une demande depuis un formulaire, extrait des champs, range le dossier et prépare un brouillon selon un chemin fixé. Si la date manque, la demande rejoint une file « à préciser ». L’IA peut aider à reformuler ; le traitement des exceptions reste à concevoir.

Option agent : le système détermine quelles informations lui manquent, choisit parmi des outils autorisés pour les rechercher, puis prépare une réponse. Ce choix ne justifie pas automatiquement l’accès à tout le calendrier, aux échanges de toute l’équipe ou à une fonction d’envoi. Le périmètre doit correspondre au résultat demandé.

Dans les trois versions, le livrable reste ici un brouillon vérifié avant envoi. Le besoin d’un chemin plus flexible doit être démontré sur des demandes réelles autorisées ou des cas fictifs représentatifs. Cet exemple explique les options ; il n’en mesure pas la performance.

Le passage critique : d’une proposition à une action

Écrivez chaque capacité comme un verbe suivi d’une cible : lire les fiches validées, créer un brouillon dans un dossier, modifier un rendez-vous, envoyer un message à un destinataire. « Accès à la messagerie » est trop vague pour décider du périmètre. Lire, supprimer et envoyer sont trois pouvoirs différents.

OWASP recommande de réduire les fonctions et permissions au nécessaire, d’exiger une approbation humaine avant des actions à fort impact et de faire appliquer les autorisations par les systèmes destinataires. Une consigne écrite dans un prompt ne remplace donc pas un droit techniquement limité. ^[2]

Pour le cas fictif, ma proposition de cadrage serait : lecture d’un répertoire identifié, création de brouillons dans un espace dédié, aucun envoi. Si l’envoi devient ensuite un besoin, il fait l’objet d’une décision distincte : destinataires autorisés, contenu à approuver, validité de cette approbation et traitement des échecs. La fiche de périmètre d’un agent permet de documenter ce passage.

Un essai qui permet réellement de choisir

Définissez d’abord un résultat acceptable : dans notre exemple, les informations fournies sont reprises correctement, les inconnues sont signalées et aucune action non autorisée n’a lieu. Constituez ensuite un petit ensemble de situations différentes, avec le résultat attendu écrit avant l’essai.

• Une demande complète et simple : le parcours ordinaire.
• Une information absente : le système doit demander une précision ou laisser le champ ouvert.
• Deux documents contradictoires : la contradiction doit rester visible.
• Une demande sortant du périmètre : le système doit s’arrêter ou transmettre à la personne désignée.
• Un échec d’outil après une première action : vérifier ce qui a réellement eu lieu avant de relancer.

Ces cas sont des propositions de test, pas un protocole de certification. Notez la version du dispositif, les accès ouverts et les observations. Pour comparer l’effort humain, utilisez la méthode de mesure du temps complet : la préparation et la reprise d’une erreur font partie du travail.

Si le chemin fixe traite correctement vos situations avec une charge acceptable, rien n’oblige à ajouter une autonomie de décision. Si les exceptions rendent ce chemin impraticable, examinez ce qu’un choix dynamique résoudrait et les contrôles supplémentaires qu’il demanderait.

Questions à poser avant de retenir une solution

Un chatbot est-il nécessairement un simple assistant ? Non. L’interface ne permet pas de conclure sur les outils qu’il peut appeler ni sur les droits disponibles. Demandez une démonstration des actions effectives et des permissions.

Faut-il bannir toute action automatique ? Ce n’est pas la méthode proposée. Certaines actions bornées peuvent être adaptées à un besoin. Il faut pouvoir décrire leur périmètre, observer leur exécution et traiter les erreurs ; cette page ne peut pas décider à la place de votre analyse de contexte.

Une bonne réponse prouve-t-elle que l’agent a fini le travail ? Non. Distinguez le texte annoncé et l’état vérifiable du système destinataire. Un brouillon peut être prêt sans qu’un message ait été envoyé, et une erreur peut survenir après une action partielle.

Par quel document commencer ? Une page décrivant le résultat, les données, les actions permises, les validations et l’arrêt. Vous pourrez alors demander des explications précises au fournisseur et discuter du pilote avec les personnes qui feront le travail.

Pour un besoin de recherche documentaire, comparez RAG, documents joints et recherche web à partir des preuves attendues.