Préparer une réponse à une demande commerciale peut exiger de lire plusieurs documents, consulter un catalogue, vérifier une règle et solliciter un responsable. Une seule requête adressée à un modèle ne suffit pas à organiser ces dépendances.
Les workflows agentiques permettent de répartir un objectif entre plusieurs étapes, outils et contrôles. Pour une DSI, leur intérêt réside dans la capacité à intégrer ces traitements au système d’information avec des responsabilités, des limites et des résultats observables.
Un workflow agentique est un processus dans lequel un ou plusieurs modèles participent à des tâches et, selon l’architecture, au choix des étapes à exécuter. Il peut combiner génération, recherche documentaire, appels d’outils, règles métier et validations humaines.
Il faut distinguer deux niveaux d’autonomie. Dans un workflow prédéfini, le logiciel fixe le chemin. Dans un système agentique plus autonome, le modèle peut sélectionner des outils ou adapter sa progression à partir des résultats obtenus. Anthropic explicite cette distinction entre workflows et agents et recommande de commencer par une solution simple. Building Effective Agents, Anthropic.
Une entreprise peut donc disposer d’un traitement utile sans confier au modèle la totalité de l’orchestration. Le degré d’autonomie doit répondre à une difficulté réelle du processus.
Une requête unique peut suffire pour reformuler un texte ou produire une synthèse courte à vérifier. Un enchaînement prédéfini convient lorsque les étapes et les règles sont stables.
La participation d’un agent devient intéressante lorsque le chemin dépend d’informations découvertes pendant l’exécution : déterminer quels documents consulter, identifier une pièce manquante ou choisir une vérification supplémentaire.
Avant de retenir cette approche, posez trois questions : les choix intermédiaires demandent-ils réellement une interprétation ? Les outils disponibles permettent-ils de réaliser les actions ? Peut-on vérifier que le résultat est correct ? Si la dernière réponse reste incertaine, limitez le système à une aide à la préparation.
Les schémas courants comprennent l’enchaînement d’étapes, le routage vers un traitement spécialisé, l’exécution parallèle et la coordination par un orchestrateur. Ces approches sont notamment décrites par Anthropic. Panorama des architectures.
Pour votre projet, comparez-les à partir des contraintes du processus :
| Architecture | Question de conception | Point à vérifier |
|---|---|---|
| Étapes séquentielles | L’ordre est-il connu à l’avance ? | Critère de passage entre deux étapes |
| Routage | Les catégories de demandes sont-elles définissables ? | Traitement des cas ambigus |
| Exécution parallèle | Les sous-tâches sont-elles indépendantes ? | Consolidation des réponses contradictoires |
| Orchestration adaptative | Faut-il découvrir les prochaines actions ? | Budget, droits et conditions d’arrêt |
Ces questions constituent une grille de conception. Elles permettent d’expliquer pourquoi un système reçoit un degré d’autonomie donné et de préparer ses tests.
Considérons un scénario illustratif de préparation d’une proposition commerciale pour un distributeur B2B. Il ne s’agit pas d’un cas client réalisé.
Le système reçoit une demande et ses pièces jointes. Il extrait les références, les quantités et les contraintes de livraison. Il consulte ensuite les sources autorisées pour préparer un dossier, puis soumet une proposition à un commercial.
Le chemin peut être représenté ainsi :
Réception → extraction → vérification des données → consultation des sources → préparation → validation humaine → enregistrement autorisé.
Les bifurcations doivent être explicites. Si une référence est inconnue, le système signale l’incertitude. Si deux documents indiquent des quantités différentes, il demande un arbitrage. Si le stock n’est pas accessible, il ne le déduit pas à partir d’anciens échanges.
Le modèle peut contribuer à interpréter la demande et préparer un texte. Le prix applicable, les règles de remise et l’autorisation d’engager l’entreprise restent contrôlés par les systèmes et les personnes désignés.
Chaque exécution doit disposer d’un identifiant et d’un état : reçue, en traitement, en attente, validée ou en échec. Conservez les résultats nécessaires à la reprise sans dépendre uniquement de l’historique conversationnel.
Dans le scénario commercial, l’état peut contenir la version de la demande, les références reconnues, les contrôles effectués et la décision du valideur. Il devient possible d’expliquer où le traitement s’est arrêté.
Privilégiez des opérations limitées et des paramètres contrôlables. Une fonction « lire le stock de cette référence » est plus facile à gouverner qu’un accès général à la base. Distinguez les opérations de consultation et celles qui modifient les données.
Les contrôles d’autorisation doivent être appliqués par le logiciel côté serveur, en fonction de l’utilisateur et de la ressource. Une instruction écrite dans un prompt ne constitue pas un mécanisme de contrôle d’accès. Ces choix suivent les principes de limitation des permissions mis en avant par l’OWASP. OWASP : excessive agency.
Une coupure réseau peut laisser le système sans réponse alors qu’une opération a déjà réussi. Pour les écritures, prévoyez un identifiant d’opération et vérifiez son statut avant de relancer. L’objectif est qu’une reprise ne crée pas deux commandes ou deux tickets.
Cette exigence doit être traitée au niveau du connecteur et de l’application cible. Demander au modèle de « faire attention aux doublons » ne suffit pas à assurer la cohérence métier.
Un document reçu peut contenir une instruction malveillante cherchant à modifier le comportement de l’agent. Les contenus externes doivent être traités comme des données à analyser, sans leur attribuer le pouvoir de modifier les règles du système. Les défenses doivent combiner limitation des accès, contrôles des entrées et supervision des actions sensibles. OWASP : prévention des injections de prompt.
Dans le scénario commercial, cela signifie par exemple qu’une pièce jointe ne peut pas autoriser une remise, changer le destinataire final ou demander l’export d’un portefeuille clients. Ces décisions passent par les contrôles de l’application.
La validation humaine doit afficher les informations nécessaires à une décision : données utilisées, action proposée, destinataire et points d’incertitude. L’approbation doit être liée à une version déterminée ; une modification substantielle après validation exige un nouveau contrôle.
Fixez un nombre maximal d’étapes, une durée limite et un budget d’utilisation. Prévoyez une sortie exploitable lorsqu’une limite est atteinte : dossier partiel, explication de l’échec ou transfert à un opérateur. L’OWASP identifie les boucles non bornées comme une source de dépenses excessives dans les systèmes agentiques. Guide de sécurité des agents IA.
Les limites doivent être adaptées au processus. Une préparation de réponse client n’a pas les mêmes contraintes qu’une analyse documentaire exécutée en arrière-plan.
Constituez un jeu de dossiers représentatifs, avec les résultats attendus validés par le métier. Ajoutez les cas incomplets, contradictoires, dupliqués et les indisponibilités des services externes.
La recette doit mesurer plusieurs dimensions :
Un taux de réussite calculé uniquement sur les réponses produites masque les abandons. Conservez donc une définition stable du dossier entrant et du résultat accepté.
Nous recommandons de commencer en lecture seule ou en mode proposition. Le système prépare les éléments, tandis que l’équipe conserve les actions finales. Cette phase permet de comparer les résultats sur des cas réels autorisés.
L’extension des droits intervient ensuite par étapes, après validation des critères d’acceptation. Documentez chaque outil ajouté et son responsable. Préparez également un mode dégradé afin que le service métier puisse continuer en cas d’indisponibilité.
L’infrastructure et les conditions de traitement des données doivent être étudiées en parallèle. Notre article sur le déploiement des modèles IA et les choix d’hébergement détaille cette dimension.
Non. Un seul modèle, des outils limités et une orchestration explicite peuvent suffire. Chaque agent supplémentaire doit justifier son utilité au regard du coût, du délai et de la coordination.
Non. Le système peut sélectionner un document inadapté ou mal interpréter son contenu. Il faut tester la recherche, contrôler les accès et vérifier que les réponses sont étayées par les sources pertinentes.
Cela dépend des interfaces, des licences et des droits disponibles. L’analyse doit aussi traiter les erreurs, les doublons et la synchronisation des données.
Nous vous proposons de partir d’un processus précis pour définir son architecture, ses limites et ses critères de réussite. Découvrez notre accompagnement pour intégrer l’IA à vos opérations ou les possibilités pour former vos équipes aux workflows IA.
Échangez avec Value IT sur votre premier workflow agentique.
Contactez ValueIT pour échanger sur votre projet et identifier les meilleures solutions pour votre organisation.
LabelVie | MarsaMaroc | CDG | CIH BANK | M2M Group | Sofac | SQLI
IT Services & Digital Transformation Casablanca Maroc Value it
adresse : 33, Bd Hassan Sghir, Bureau 7-9, Casablanca
Tel : 06 66 81 83 81 | mail : contact@valueit.ma | info@valueit.ma
Nous accompagnons la croissance de nos clients en leur proposant des solutions adaptées à leurs besoins et alignés avec leurs objectifs stratégiques.
Vous souhaitez rester informé des dernières actualités, de nos services et nos offres d’emplois ? Abonnez-vous à notre newsletter pour ne rien manquer
