Les workflows automatisés

Ce que l'IA fait bien ici, ce qu'elle fait mal

Ce qu'elle fait bien

• Classer une entrée dans une liste fermée: le modèle range chaque message parmi les catégories que l'analyste a fixées.
• Tirer des champs d'un texte libre: il rend un format fixe que l'outil suivant lit tel quel.
• Résumer un signalement pour l'équipe: il ramène le message d'un habitant au lieu et au problème à traiter.
• Renvoyer les cas que le prompt décrit: il met en escalade le message qui contient un déclencheur nommé dans le prompt.

Ce qu'elle fait mal

• Tenir son format à chaque passage: une sortie hors format bloque l'étape suivante ou y entre comme une valeur juste.
• Reconnaître seul un cas hors liste: une photo sans texte reçoit une catégorie au lieu de l'escalade.
• Escalader sans déclencheur écrit: le modèle classe en voirie un message qui demande un remboursement.
• Mesurer ce qu'une phrase engage: le modèle écrit une promesse de remboursement aussi volontiers qu'un accusé de réception.
• Garder ses sorties quand le fournisseur change de modèle: le workflow reste le même et ses résultats changent.

Déroulé

De la chaîne au workflow

Dans une chaîne de prompts, l'analyste lance chaque appel, lit le résultat et le colle dans l'appel suivant. Un workflow automatisé fait ce travail sans lui. Un événement le démarre: un formulaire envoyé, un e-mail reçu, une heure fixe. Des outils lisent et modifient les applications de l'organisation. Les données de ces applications entrent dans le workflow sans copier-coller. Aucune personne n'intervient entre deux étapes sauf là où l'analyste l'a prévu.

Zapier, Make et n8n emploient le même vocabulaire. Le déclencheur (trigger) démarre le workflow. Les actions suivent dans l'ordre. Chaque action atteint une application par un identifiant de connexion que la plateforme conserve. Un passage complet s'appelle une exécution. L'analyste lance une exécution à la main pour tester la logique. Une fois publié, le workflow s'exécute seul sur un événement ou selon un horaire.

Pour un premier workflow, l'analyste choisit un chemin fixe: il dessine les étapes et place le modèle là où il faut lire un texte. Vous trouverez dans la page Chatbot, assistant, agent ce qui sépare ce chemin fixe de celui qu'un agent choisit.

MCP (Model Context Protocol) est un standard ouvert qui relie une application d'IA à des sources de données, à des outils et à des workflows. Un agent appelle une application par son interface de programmation (API) ou par un serveur MCP. Dans n8n, l'analyste qui branche un serveur MCP choisit les outils que l'agent peut appeler. Il retient la liste la plus courte qui couvre la tâche.

Lire un workflow publié

La galerie de n8n affiche des workflows sans demander de compte. Le workflow AI agent chat part d'un déclencheur qui reçoit un message de chat. Le message passe à un nœud d'agent. L'agent est relié au modèle de langage, à une mémoire de la conversation et à un outil de recherche sur le web. Vous avez besoin d'un compte n8n pour exécuter le workflow.

Dans ce workflow, la réponse du modèle revient à l'utilisateur sans approbation humaine.

L'étape qui attend une personne

Une étape est irréversible quand son effet sort du workflow et ne se reprend pas: envoyer, publier, payer, supprimer, écrire dans l'application qui fait foi. Une erreur à une étape réversible reste dans le workflow. Une erreur à une étape irréversible atteint un habitant, un fournisseur ou un compte.

Dans un workflow à chemin fixe, une étape envoie le cas à une personne et attend sa réponse avant de continuer. Un membre de la communauté a publié dans la galerie de n8n un workflow qui attend la réponse d'une personne avant d'envoyer un e-mail rédigé par le modèle.

Pour un agent, n8n peut exiger une approbation humaine avant l'appel d'un outil. Le workflow se met en pause. La personne voit l'outil et ses paramètres, puis elle approuve ou refuse. Un refus annule l'action et en informe l'IA. La documentation de n8n recommande cette approbation pour les actions irréversibles (supprimer des données, envoyer une communication externe, faire un achat), pour les exigences de conformité et pour les décisions à fort enjeu. Elle conseille de démarrer avec la revue activée et de la réduire à mesure que la confiance grandit.

La spécification de MCP recommande qu'une personne puisse toujours refuser l'appel d'un outil.

Vous trouverez dans la fiche Humain dans la boucle comment le coût d'une erreur et la fiabilité mesurée fixent le mode de contrôle: approbation avant l'action, renvoi des cas signalés ou revue d'un échantillon. Dans un workflow, la valeur «escalade» renvoie les cas signalés.

Ce que l'analyste construit, ce que l'informatique reprend

Une plateforme sans code met la construction et l'exploitation dans la même interface. La documentation de Make, de n8n et de Zapier ne les sépare pas. Nous recommandons cette frontière: l'analyste construit et teste dans un environnement de test avec des données fictives. Le service informatique reprend la main dès que le workflow touche des données réelles ou un compte réel.

Dans n8n, un identifiant de connexion est fixe ou personnel. L'identifiant fixe sert à chaque exécution. L'identifiant personnel n'est visible que de son propriétaire. Vous trouverez dans la fiche Matrice des rôles et permissions comment choisir entre les droits propres d'un agent et les droits délégués de la personne qui l'invoque. Le service informatique choisit la forme de l'identifiant et donne au compte les seuls droits de la liste d'outils.

Vous trouverez dans la page Politique d'usage comment une organisation fixe les outils que son personnel peut connecter. Vous trouverez dans la page Du prototype à la production comment une solution passe en service par paliers.

Les étapes

1. L'analyste dessine le processus et marque les étapes irréversibles. Il part du processus actuel en BPMN ou en liste d'étapes. Il note pour chaque étape qui agit, ce qu'elle lit et ce qu'elle écrit.
2. Un assistant rédige la spécification du workflow, puis l'analyste la relit. L'analyste remplit le prompt modèle avec le processus et les outils disponibles. Il vérifie que chaque étape irréversible porte une approbation ou un texte fixe et que chaque outil de la liste sert une étape.
3. L'analyste écrit le prompt de chaque étape du modèle. Il suit le prompt structuré. Le modèle rend le format fixe de la spécification et choisit ses valeurs dans une liste fermée. Le format prévoit une valeur «escalade» pour le cas que la liste ne couvre pas.
4. L'analyste construit le workflow dans un environnement de test. Il emploie des données fictives et des comptes de test. Il lance chaque exécution à la main.
5. Le modèle traite les cas de test, puis une deuxième personne relit les sorties. L'analyste prépare des entrées justes et des entrées fausses: un champ vide, une langue inattendue, une demande hors du périmètre, une consigne glissée dans le message. Vous trouverez dans la fiche AMDEC comment recenser les modes de défaillance de chaque étape. Une collègue du métier compare chaque sortie à la sortie attendue.
6. L'analyste corrige le workflow d'après les tests et nomme la personne qui approuve. Quand un test montre que le modèle peut écrire un engagement, l'analyste retire le texte libre de l'étape ou y ajoute une approbation. Il fixe ce que la personne qui approuve voit: l'outil appelé, ses paramètres, l'extrait du message qui justifie l'action.
7. L'analyste remet le dossier au service informatique. Le dossier contient la spécification relue et les résultats des tests. Le service informatique crée les comptes et les identifiants, règle les journaux et met le workflow en service. Vous trouverez dans la fiche Matrice RACI comment écrire qui répond de chaque activité.
8. Chaque étape irréversible qui porte un texte du modèle démarre avec une approbation à chaque exécution. Une étape réduite à un texte fixe peut démarrer sur une revue d'un échantillon. Le responsable du processus réduit ensuite l'approbation sur la seule base des résultats journalisés. Il la retire par exemple d'une catégorie après un mois sans refus.

Prompt modèle

L'analyste donne ce prompt à un assistant pour obtenir la spécification d'un workflow. Il la relit avant de construire.

[RÔLE ET CONTEXTE SELON LE PROMPT STRUCTURÉ]

<processus>
[ÉTAPES DU PROCESSUS ACTUEL, UNE PAR LIGNE, AVEC QUI AGIT AUJOURD'HUI]
</processus>

<outils>
[APPLICATIONS QUE LE WORKFLOW PEUT LIRE OU MODIFIER]
</outils>

<consignes>
Tâche: rédige la spécification d'un workflow qui automatise ce processus sur [PLATEFORME].
Décris le déclencheur puis chaque étape dans l'ordre.
Pour chaque étape, indique qui agit (outil, modèle ou personne), les données lues et les données écrites.
Indique pour chaque étape si elle est réversible. Une étape qui envoie, publie, paie, supprime ou écrit dans [APPLICATION QUI FAIT FOI] est irréversible.
Place une approbation par une personne avant chaque étape irréversible. Indique ce que cette personne voit pour décider: l'outil appelé, ses paramètres et l'extrait du message qui justifie l'action.
Pour chaque étape du modèle, donne le format de sortie et la liste fermée des valeurs permises. Ajoute une valeur «escalade» et dis à qui le cas part.
Décris ce qui se passe quand une étape échoue.
Liste les outils requis et le droit minimal sur chacun: lecture, création ou modification. Emploie seulement les outils de <outils>. Signale toute étape qui en demande un autre.
Décris les étapes sans chemin de menu ni nom de module.
Format de sortie: un tableau aux colonnes n°, étape, acteur, données lues, données écrites, réversible, contrôle. Ajoute sous le tableau la liste des questions que l'analyste doit trancher avec [RESPONSABLE DU PROCESSUS].
</consignes>

• [RÔLE ET CONTEXTE…] donne au modèle un métier, un secteur et le but du workflow.
• [ÉTAPES DU PROCESSUS ACTUEL…] reçoit sans nom de personne le processus dessiné à l'étape 1.
• [APPLICATIONS…] nomme les applications que la politique d'usage autorise, par exemple «la messagerie du service, le logiciel des bons de travail».
• [PLATEFORME] nomme la plateforme choisie: Make, n8n, Zapier ou une autre.
• [APPLICATION QUI FAIT FOI] nomme les applications dont les données font foi: le registre des habitants, la comptabilité, le logiciel des bons de travail.
• [RESPONSABLE DU PROCESSUS] nomme la fonction qui répond du processus, par exemple «le chef du service des travaux».

Exemple

Une commune vaudoise fictive reçoit environ soixante signalements par semaine par le formulaire de son site: un nid-de-poule, un lampadaire éteint, un conteneur plein. La secrétaire du service des travaux lit chaque message, le transmet à l'équipe et répond à l'habitant. L'analyste conçoit un workflow. Le modèle classe le signalement et résume le problème pour l'équipe. Un outil crée un bon de travail en brouillon. Le contremaître le valide chaque matin, puis un outil le transmet à l'équipe. Un autre outil envoie l'accusé de réception.

Dans la première version, le modèle rédigeait l'accusé de réception. L'analyste a lancé douze cas de test fictifs dans l'environnement de test. La secrétaire a relu les sorties. Les sorties du tableau sont reconstituées pour l'exemple.

T07 et T09 auraient produit un e-mail envoyé sans relecture. L'analyste retire donc le texte libre de l'étape. Le modèle rend seulement la catégorie, le résumé pour l'équipe et la valeur «escalade». L'accusé de réception devient un texte type par catégorie. Chaque texte donne le délai que le chef de service a validé. Le prompt envoie en escalade tout message qui parle de dommage, de remboursement ou de danger. Il y envoie aussi le message qui évoque une mesure de la commune et celui qui ne décrit aucun problème. La secrétaire reçoit ces cas et y répond elle-même.

Au deuxième passage, T07, T09 et T11 partent en escalade. L'envoi de l'accusé reste irréversible. Une erreur de catégorie y produit au pire un délai faux. L'analyste propose donc une revue d'un échantillon de vingt envois par semaine au lieu d'une approbation de chaque envoi. Le chef de service accepte. Le bon de travail garde l'approbation du contremaître parce qu'il engage l'équipe.

Vérifier le résultat

• Chaque étape irréversible est-elle précédée d'une approbation ou réduite à un texte fixe?
• La personne qui approuve voit-elle l'outil appelé, ses paramètres et l'extrait du message qui justifie l'action?
• Chaque étape du modèle rend-elle un format fixe avec une liste fermée de valeurs?
• Le format prévoit-il une valeur «escalade» que reçoit une personne nommée?
• Les cas de test comprennent-ils un champ vide, une langue inattendue et une consigne glissée dans le message?
• Une deuxième personne a-t-elle relu chaque sortie des tests?
• Le workflow a-t-il tourné dans un environnement de test avec des données fictives avant de toucher une donnée réelle?
• Chaque outil de la liste sert-il une étape du workflow?
• Le compte du workflow a-t-il seulement les droits que ces outils demandent?
• Le service informatique a-t-il créé et stocké les identifiants de connexion?
• Le journal montre-t-il pour chaque exécution l'entrée, la sortie du modèle et la décision de la personne?
• Une personne nommée traite-t-elle les exécutions en échec?
• Les cas de test repassent-ils après chaque changement de modèle ou de prompt?

Limites et risques

Une erreur se répète à chaque exécution. Dans une chaîne, l'analyste lit chaque résultat. Dans un workflow, une consigne fausse produit la même erreur sur chaque message jusqu'à ce que quelqu'un la remarque. Le responsable du processus fait relire chaque semaine un échantillon d'exécutions dans le journal. L'échantillon comprend les exécutions que personne n'a approuvées.

Le fournisseur change le modèle sans toucher au workflow. Le workflow appelle un modèle qu'un tiers héberge. Une nouvelle version peut rendre d'autres sorties pour le même prompt. L'analyste garde les cas de test et les repasse après chaque changement de modèle ou de prompt.

Les données partent à chaque exécution. Chaque message traverse la plateforme du workflow et le service qui héberge le modèle. Quand il contient des données personnelles, la LPD s'applique. Son art. 9 encadre le traitement confié à un sous-traitant. Son art. 16 encadre la communication de données personnelles à l'étranger. Le service informatique vérifie le lieu d'hébergement et le contrat de chaque fournisseur avant la mise en service.

Un message peut détourner le modèle. Dans le cas T09, une consigne glissée dans le signalement a changé la sortie du modèle. Vous trouverez dans la page Chatbot, assistant, agent comment des fonctions réduites et une validation avant l'envoi limitent ce risque.

Le workflow ne relie pas les signalements. La secrétaire qui lisait chaque message voyait le même lampadaire revenir trois fois en un mois. Le workflow range chaque message à part. Le chef de service lit chaque mois les signalements par lieu.

La responsabilité reste au métier. Le responsable du processus répond des décisions que le workflow prend en son nom. L'analyste répond de la spécification et des tests. Le service informatique répond de l'exploitation. Chacun signe sa part avant la mise en service.

Techniques liées

• Humain dans la boucle: le registre des décisions qu'un assistant pré-remplit et les cas à erreur connue qui testent la supervision.
• BPMN: le premier jet qu'un modèle tire d'une procédure écrite et les décisions qui ne se délèguent pas.
• AMDEC: les modes de défaillance qu'un modèle propose pour chaque fonction et que l'équipe trie.
• Matrice RACI: les défauts de structure qu'un modèle trouve dans une grille, par exemple une activité sans A.
• Matrice des rôles et permissions: le choix entre les droits propres d'un agent et les droits délégués de la personne qui l'invoque.