Une demande client arrive par mail. L’IA la résume, identifie le sujet et propose une réponse. Mais quelqu’un doit encore ouvrir le dossier, vérifier les informations, retrouver les conditions applicables, décider de la suite et mettre à jour l’outil de suivi. La rédaction a avancé. Une grande partie du travail reste à faire.
C’est sur cet enchaînement qu’un workflow agentique peut intervenir. Il relie des capacités d’IA à des outils et à des étapes de travail, avec des règles et des décisions humaines. L’enjeu devient alors de faire aboutir une demande dans les conditions attendues par l’activité.
Chez The Spark, on distingue ce sujet de l’usine agentique utilisée pour construire un logiciel. Ici, les agents participent au travail que le produit permet d’accomplir : instruire un dossier, préparer une intervention, traiter une demande. Leur fonctionnement engage aussi la façon dont les équipes se répartissent ce travail.
Ce qu’on confie réellement à un agent
Prenons un exemple illustratif : un client demande de modifier une prestation déjà commandée. Ce cas ne décrit pas une mission réalisée. Il permet de suivre les choix à faire pour concevoir un tel fonctionnement.
Une personne reçoit le message et cherche la commande concernée. Elle vérifie ce qui peut encore être modifié, consulte les disponibilités, demande éventuellement une précision, puis prépare une proposition. Une fois la décision prise, elle effectue la modification et informe le client.
Dans ce parcours, certaines étapes suivent des règles stables. Retrouver une commande avec son numéro ou vérifier qu’une date précède une échéance peut relever d’un traitement classique. Comprendre une demande formulée librement, rapprocher plusieurs informations ou préparer une explication peut justifier l’intervention d’un modèle.
Le terme « agentique » recouvre des degrés d’autonomie différents. Anthropic distingue les workflows dont le parcours est défini à l’avance des agents qui choisissent davantage leurs étapes et leurs outils. Un même produit peut combiner les deux. On peut ainsi prévoir le parcours général et confier à un agent la recherche des informations utiles à l’intérieur de ce cadre.
Le nombre d’agents découle de ce qu’il faut accomplir. Pour notre exemple, un seul agent disposant de quelques outils peut suffire, si les essais confirment qu’il accomplit correctement la tâche.
Avec quels outils peut-on construire ce fonctionnement ?
Des plateformes comme Dust ou n8n permettent de mettre en place ces usages, avec des points de départ différents.
Dust permet de créer des agents reliés aux connaissances et aux outils de l’entreprise. Dans notre exemple, un agent pourrait retrouver les conditions applicables à une commande, les rapprocher de la demande du client et préparer une proposition pour l’équipe, selon les connexions et les accès configurés.
n8n permet de composer un parcours entre plusieurs applications, en associant des traitements classiques et des agents IA. On pourrait y organiser la réception de la demande, la recherche du dossier, la préparation d’une modification et la mise à jour de l’outil de suivi. Une validation humaine peut être requise avant l’exécution d’un outil, par exemple avant une action qui engage l’entreprise.
Ces approches peuvent se recouvrir. Le choix dépend des outils déjà utilisés, des actions à réaliser et des personnes qui entretiendront le dispositif. Une plateforme existante peut couvrir une grande partie du besoin ; des développements spécifiques peuvent compléter les connexions ou les règles propres à l’activité. Dans tous les cas, il reste à définir ce que l’agent est autorisé à faire et comment vérifier que le travail a abouti.
Définir ce que « terminé » veut dire
Avant de construire, on décrit le résultat attendu. Pour une modification acceptée, la commande doit être effectivement mise à jour, le client informé et le dossier de suivi cohérent. Pour une demande incomplète, le bon résultat peut être une question précise adressée au client et un dossier en attente.
Cette distinction compte : un message bien rédigé ne prouve pas que la commande a changé. Et une demande transmise à une personne peut être correctement traitée par le workflow si elle dépasse le périmètre autorisé.
On précise donc avec les équipes ce qui peut aboutir automatiquement, ce qui nécessite un accord et ce qui doit leur revenir. Dans notre exemple, une modification sans incidence sur le prix pourrait suivre un parcours simple. Une exception commerciale resterait soumise à une décision humaine. Ces limites dépendent des engagements de l’entreprise et des conséquences d’une erreur.
Les expliciter peut aussi révéler un problème déjà présent dans l’organisation : une règle interprétée différemment, une information sans source fiable ou une responsabilité mal définie. Il faut résoudre ce point pour donner au workflow un fonctionnement compréhensible.
Relier les outils sans donner tous les droits
Pour préparer une modification, l’agent a besoin d’accéder à la commande, aux conditions applicables et aux disponibilités. Cela ne lui donne pas nécessairement le droit de modifier un prix ou de déclencher un remboursement.
On sépare les accès à l’information des autorisations d’action. Les limites doivent être appliquées par les outils et les services qui exécutent les opérations. Une instruction dans le contexte de l’agent ne suffit pas à garantir leur respect.
Le contenu du mail reste lui aussi une donnée à interpréter. Même s’il demande de contourner une validation, il ne peut pas accorder une nouvelle autorisation. Cette séparation et la limitation des permissions font partie des recommandations de l’OWASP pour les agents IA.
Ces choix techniques ont une traduction très concrète pour l’équipe : ce que l’agent peut consulter, préparer, proposer et exécuter doit être identifiable.
Concevoir le moment où une personne reprend la main
Dans notre exemple, une demande exceptionnelle arrive au responsable commercial. Pour décider, il doit voir la modification proposée, ses conséquences, les conditions concernées et les informations qui manquent encore. Lui transmettre une conversation entière à relire déplace le travail de recherche au lieu de le faciliter.
La validation porte sur une action précise. Si le client change sa demande après l’accord du responsable, cet accord ne vaut pas automatiquement pour la nouvelle proposition.
Il faut également prévoir l’attente et les incidents. Si personne n’est disponible pour valider, le dossier garde un état explicite. Si la commande a été modifiée mais que l’envoi du message échoue, la reprise doit permettre de renvoyer le message sans appliquer une seconde fois la modification.
On conserve pour cela une trace des actions réalisées, de leurs résultats et des validations reçues. Elle sert à comprendre où le travail s’est arrêté et à reprendre depuis cet état. C’est aussi ce qui permet à une personne de traiter directement un dossier lorsque le parcours prévu ne convient plus.
Évaluer le travail complet, y compris les reprises
Une démonstration sur une demande simple permet de voir le principe. Pour décider de poursuivre, on utilise des situations représentatives : référence absente, commandes similaires, information contradictoire, exception commerciale, outil indisponible. Les cas qui demandent une intervention font partie de l’évaluation.
On regarde ce qui a effectivement changé dans les outils, la justesse de la réponse et le respect des autorisations. Les travaux d’Anthropic sur l’évaluation des agents soulignent cette différence entre ce qu’un agent affirme avoir fait et le résultat observable de ses actions.
On mesure aussi le temps passé par les équipes à vérifier, corriger et reprendre. Un traitement rapide peut perdre son intérêt si chaque dossier impose une longue relecture. À l’inverse, une préparation fiable, même soumise à validation, peut faciliter le travail en réunissant les éléments nécessaires à la décision.
La comparaison se fait avec le fonctionnement actuel : délais, erreurs, temps de traitement, dossiers laissés en attente. Elle permet de choisir un niveau d’automatisation utile, puis de l’ajuster à partir de l’usage.
Construire un fonctionnement que l’équipe peut faire évoluer
On peut commencer sur un périmètre limité, en laissant l’agent préparer les actions sans les exécuter. L’équipe examine les propositions sur des dossiers réels autorisés, identifie les erreurs et précise les conditions d’un passage à l’action. C’est le rôle d’une expérimentation orientée vers une décision.
La suite demande de faire évoluer ensemble le produit et le fonctionnement de l’équipe. Qui entretient les règles ? Qui examine les dossiers interrompus ? Comment une nouvelle condition commerciale est-elle prise en compte ? Un changement de modèle ou de connexion à un outil doit pouvoir être vérifié sur les cas déjà rencontrés.
C’est ainsi qu’on aborde la construction de workflows agentiques chez The Spark : à partir du travail à accomplir, des outils de l’activité et des personnes qui en portent la responsabilité. La valeur se juge dans les demandes qui aboutissent, le temps que l’équipe y consacre et sa capacité à comprendre et à corriger ce qui se passe.