Workflow IA : définition, 3 exemples et mise en place

Qu’est-ce qu’un workflow IA ?

Un workflow IA est un enchaînement de tâches dans lequel l’intelligence artificielle intervient pour analyser, classer, produire ou interpréter une information. Il peut suivre un parcours entièrement défini : lire un document, extraire des champs, puis préparer une fiche.

Un workflow agentique confie au modèle le choix de certaines vérifications ou de certains outils selon le contexte découvert. Un branchement prédéfini « champ manquant → demander une revue » reste une règle ; il ne suffit pas à rendre le workflow agentique.

Anthropic distingue les workflows aux étapes prédéfinies des agents qui dirigent leur utilisation des outils. Dans cet article, le terme « workflow agentique » désigne un processus métier délimité qui confie une décision précise à un agent.

Le déclencheur, les droits, les validations et le résultat attendu peuvent rester fixes. Seule l’investigation a besoin de souplesse.

Automatisation, étape IA ou agent : comment répartir le travail ?

Prenons la création d’un projet client. Copier des champs approuvés dans une fiche projet peut suivre une règle. Extraire les besoins d’un document peut demander une étape IA. Rechercher pourquoi le dossier reste incomplet peut justifier un agent.

Une suite d’étapes IA suffit souvent. Notre guide sur les agents IA en entreprise traite du choix de leur architecture d’exécution.

Comment fonctionne un workflow IA agentique ?

La boucle est simple : recevoir un objectif → consulter le contexte → choisir la prochaine vérification → utiliser un outil autorisé → vérifier le résultat → poursuivre ou s’arrêter.

Pour un onboarding bloqué, l’agent peut lire la note du compte, suivre un lien vers un ticket d’accès, constater que le ticket est résolu, puis vérifier la configuration encore attendue. La prochaine action dépend des informations découvertes. Une règle « jalon en retard → envoyer une relance » ne réalise pas cette investigation.

Si une action autorisée crée une tâche interne, le workflow vérifie la tâche retournée et son responsable avant d’enregistrer le succès. Un texte annonçant sa création ne prouve pas qu’elle a eu lieu.

Les exemples ci-dessous sont des conceptions illustratives. Ils ne décrivent pas des réalisations clients ni des résultats mesurés.

Exemple 1 : préparer la transmission des ventes au delivery

Une entreprise de services vient de remporter une mission. L’historique commercial est dans le CRM, le périmètre signé dans un document, et l’équipe de réalisation a besoin d’un dossier exploitable.

Déclencheur : l’engagement est prêt pour une revue de transmission. Le statut « Gagné » ne prouve pas à lui seul que toutes les conditions de lancement sont réunies.

Contexte : le périmètre convenu et sa version, les interlocuteurs, les notes commerciales, les dépendances, les éléments attendus du client et la date envisagée.

Travail de l’agent : repérer les manques et les contradictions. Si le brief évoque une migration absente du périmètre accepté, l’agent consulte la source concernée et signale l’écart. Si un contact manque, il vérifie la fiche entreprise liée au lieu d’inventer un interlocuteur.

Résultat : un dossier de transmission proposé, avec les éléments confirmés, leurs sources, les questions ouvertes et la personne chargée de les résoudre.

Le responsable delivery vérifie ce dossier. Sa validation peut ensuite déclencher une action déterministe qui crée le projet et reprend les champs convenus.

Dans une architecture possible, Attio porte la relation commerciale et l’opportunité, Airtable le projet et le travail opérationnel. Un identifiant d’engagement relie les deux. L’action doit supporter une nouvelle tentative sans doublon, même si deux exécutions se chevauchent : ce contrôle se construit dans l’action ou l’intégration, pas seulement dans une consigne à l’agent.

L’agent prépare la transmission. Il ne négocie pas un périmètre manquant et ne promet pas une date de démarrage. Un conflit entre documents revient à la personne responsable.

Test utile : soumettre un dossier complet, un ancien document de périmètre, un contact absent et deux fois le même dossier approuvé. Vérifier le brief, le traitement des exceptions et le nombre de projets créés.

Mesurer le délai jusqu’à l’acceptation du dossier et les reprises dues aux informations manquantes. Un brief produit plus vite n’aide que si l’équipe peut réellement travailler avec.

Exemple 2 : rechercher un blocage dans l’onboarding SaaS

Un client SaaS a signé, mais n’a pas franchi un jalon important de son onboarding. Une simple relance suffit parfois. Dans d’autres cas, le blocage se trouve entre les tickets de support, les notes d’implémentation et l’activité du compte.

Déclencheur : un jalon reste incomplet au-delà du point de revue défini par l’équipe.

Contexte : le plan d’onboarding, les signaux produit autorisés, les tickets ouverts, les notes du compte et le responsable du prochain jalon.

Travail de l’agent : choisir les vérifications pertinentes. Il peut examiner un ticket d’accès non résolu, vérifier si une configuration attendue a été effectuée, puis confronter ces informations à la dernière note d’implémentation.

Chaque blocage peut demander une investigation différente. La recherche reste limitée au compte et aux sources nécessaires.

Résultat : une synthèse du blocage appuyée sur des sources, une tâche interne attribuée au bon responsable et une prochaine action proposée. Une contradiction entre sources doit rester visible.

Par exemple, le CRM indique « formation en attente », mais le support montre que les utilisateurs ne peuvent pas se connecter. L’action utile consiste à résoudre l’accès, avec une source et un responsable, avant d’envoyer une nouvelle invitation à la formation.

L’agent ne doit pas clôturer l’onboarding, modifier les permissions du client ou promettre un correctif produit sur la seule base d’une explication plausible.

Test utile : prévoir un problème d’accès connu, un dossier en attente d’un retour client, un ticket résolu avec des notes obsolètes et un compte insuffisamment documenté. Contrôler les recommandations et les situations remontées pour revue.

Mesurer le délai de résolution, les recommandations acceptées et les escalades incorrectes. Le nombre de tâches générées ne constitue pas un résultat métier.

Exemple 3 : comparer des devis fournisseurs incomplets

Une équipe e-commerce reçoit des devis dans des formats différents. Une fois les unités, quantités, devises et conditions connues, les prix peuvent être comparés par des règles. Le travail difficile se situe souvent avant le calcul.

Déclencheur : un devis arrive pour une demande d’achat identifiée.

Contexte : les produits demandés, les références fournisseurs, les unités, les quantités, les documents et les règles de comparaison validées.

Travail de l’agent : rechercher les manques et les écarts. Un fournisseur chiffre à la boîte, un autre à l’unité ; le transport est inclus dans un document et absent dans l’autre. L’agent peut consulter le conditionnement produit ou préparer une demande de précision lorsque les conditions restent inconnues.

Résultat : une comparaison structurée, accompagnée des sources et des valeurs manquantes. Les données confirmées alimentent les calculs déterministes. Un transport inconnu reste inconnu : il ne devient pas égal à zéro.

La séparation est importante : l’agent interprète les documents, le système applique les calculs convenus. Si la demande d’achat évolue, la comparaison doit porter sur sa nouvelle version.

L’acheteur tranche les ambiguïtés d’unité ou de conditions, puis valide la décision d’achat. Le workflow peut préparer un bon de commande après cette validation ; une comparaison incertaine ne doit pas engager automatiquement l’entreprise auprès du fournisseur.

Test utile : inclure un devis scanné, deux conditionnements différents, un transport absent, un document révisé et une pièce jointe reçue en double. Vérifier les données extraites, leurs sources, les calculs et le traitement des devis incomparables.

Mesurer le temps de revue, le taux de correction et la part des devis encore incomparables. Une synthèse lisible ne doit pas masquer une hypothèse d’achat non résolue.

Comment mettre en place un workflow IA ?

Choisir une tâche récurrente, un responsable et un résultat vérifiable. Si le fonctionnement actuel est flou, commencer par la cartographie des processus.

1. Définir le résultat : préciser à quoi ressemble une tâche terminée et comment elle sera acceptée.

2. Répartir le travail : conserver les actions prévisibles sous forme de règles et isoler l’investigation confiée à l’agent.

3. Connecter quelques outils : donner accès aux seules sources et actions nécessaires.

4. Configurer la revue et l’exécution : distinguer une action proposée, une action approuvée et une action effectuée.

5. Tester puis déployer progressivement : vérifier les cas courants, les exceptions et les effets réels avant d’élargir les accès.

Un contrat de fonctionnement court permet de rendre ces choix explicites :

Les règles métier restent dans le système qui en fait autorité. Les documents et emails consultés apportent des informations ; leur contenu ne doit pas donner de nouvelles consignes ou permissions à l’agent.

Séparer les suggestions des faits confirmés. Une cause probable de blocage ne doit pas écraser le statut du client avant sa vérification.

L’architecture CRM fournit le cadre plus large : quel système porte chaque information, quels identifiants relient les fiches et comment les changements circulent entre les outils.

Intégrer le workflow dans les outils déjà utilisés

Commencer par l’espace de travail existant. Le responsable doit pouvoir consulter la source, la recommandation et la décision attendue là où il traite déjà ce travail.

La bibliothèque de blocs Workflows d’Attio associe des étapes agentiques à des actions sur les fiches. Le texte retourné par un agent n’est pas enregistré automatiquement dans un attribut : cette écriture demande une étape explicite. Cela aide à distinguer une analyse d’une mise à jour acceptée.

Les Field Agents d’Airtable peuvent contribuer à l’analyse au sein des données opérationnelles. Les automatisations Airtable apportent des déclencheurs et des actions autour de ce traitement.

Ce sont des briques de construction. Les exemples précédents demandent encore une configuration, des sources connectées, des permissions adaptées et des tests. Une investigation entre plusieurs systèmes peut nécessiter une intégration ou une couche agentique supplémentaire ; un besoin contenu dans un seul outil peut s’en passer.

Commencer par un workflow et mesurer la tâche complète

Exécuter d’abord le workflow sur des exemples représentatifs sans lui permettre de modifier les données opérationnelles. Inclure des informations manquantes, des sources contradictoires, des outils indisponibles et des événements reçus plusieurs fois. Faire ensuite revoir les résultats dans l’espace habituel des utilisateurs, avant d’autoriser quelques actions ciblées.

Comparer la tâche complète avec le fonctionnement actuel : temps de revue humaine, corrections, dossiers non résolus, coût d’exécution et utilité du résultat pour l’équipe suivante. Définir les limites acceptables avant le pilote.

Le workflow mérite davantage d’autonomie lorsqu’il fonctionne de manière fiable dans ce périmètre. Si une règle ou une seule étape IA produit le même résultat utile avec moins de maintenance, cette conception plus simple suffit.

HyperOps aide les équipes à relier leur CRM, leurs données opérationnelles et les actions IA dans des systèmes utilisables. Notre accompagnement en automatisation des processus et IA part du workflow, de ses responsables et de ses données de référence.

Questions fréquentes sur les workflows IA