Tester des workflows : Pin Data, Mock Data, mode Debug

Toute personne travaillant sur un workflow n8n qui envoie un e-mail, déclenche un paiement ou écrit un enregistrement dans un CRM ne veut pas envoyer un vrai message ou créer un vrai enregistrement client à chaque test. C'est exactement pour cela que n8n propose deux fonctionnalités complémentaires : Pin Data fige la sortie d'un nœud, Mock Data génère des données de test sans même contacter une source externe. Cela est complété par le mode Debug, qui permet de reproduire directement dans l'éditeur des exécutions de production ayant échoué.

Pour toi en tant qu'équipe qui construit des automatisations en production, c'est plus qu'une fonctionnalité de confort. Sans données de test fixées, chaque clic sur "Execute workflow" teste contre des systèmes réels, consomme des quotas d'API et risque qu'un test déclenche accidentellement une action réelle. Avec Pin Data, Mock Data et le mode Debug, tu gardes le contrôle sur quelles données passent par ton workflow et quand, et tu peux vérifier de manière fiable la même logique plusieurs fois avec les mêmes entrées.

Pourquoi fixer les données de test plutôt que de tester en direct contre des systèmes de production

Un problème typique lors de la construction de workflows : le premier nœud récupère des données depuis une source externe, par exemple un webhook, un tableau ou une API. À chaque fois que tu exécutes le workflow pour le tester, cette requête est relancée, cela coûte du temps, consomme éventuellement un quota et ne garantit pas les mêmes valeurs que lors du dernier passage. C'est exactement là que Pin Data et Mock Data interviennent : selon n8n, ces deux fonctionnalités sont conçues comme des outils de test pendant le développement, "pour gagner du temps et des ressources pendant le développement, travailler avec des jeux de données cohérents et protéger les systèmes en production contre des appels de test répétés". Au lieu de solliciter un système réel à chaque test, tu travailles avec un jeu de données fixe et reproductible et tu vois immédiatement si une modification de ta logique produit le résultat souhaité.

Pin Data : figer la sortie d'un nœud

Le Data Pinning enregistre les données de sortie d'un nœud et utilise ces données enregistrées lors des exécutions futures, au lieu de récupérer à nouveau des données fraîches. Voici comment procéder :

• Exécute une fois le nœud concerné afin que des données apparaissent dans la vue OUTPUT.
• Clique sur l'icône d'épingle dans la vue OUTPUT. Une bannière confirme que les données sont désormais épinglées.
• Via le lien Unpin dans la même bannière, tu annules la fixation ; ensuite, le nœud récupère à nouveau des données fraîches lors du prochain passage.
• Les données épinglées peuvent aussi être modifiées ultérieurement : passe à la vue JSON dans la vue OUTPUT, sélectionne Edit, ajuste les valeurs et enregistre avec Save.

C'est particulièrement pratique pour les workflows déclenchés par un système externe comme un webhook : une fois les données de départ épinglées, tu n'as pas besoin de solliciter à nouveau le système déclencheur à chaque test, mais tu continues à travailler directement avec le jeu de données fixé. Tu peux aussi réutiliser pour cela des données d'une exécution précédente : dans l'onglet Executions, ouvre une exécution passée, ouvre le nœud souhaité par double-clic, passe à la vue JSON, copie les données, puis colle-les et enregistre-les dans la vue cible d'un nœud.

Mock Data : générer des données de test sans aucune source réelle

Le Data Mocking consiste à créer ou simuler des données de test sans se connecter du tout à une source de données réelle. Cela est utile chaque fois que tu n'as pas encore accès au système réel, qu'un cas limite doit être testé alors que les données réelles ne le fournissent pas actuellement, ou que tu veux développer indépendamment de la disponibilité et des droits d'une source externe. n8n mentionne principalement deux méthodes pour cela :

• Nœud Edit Fields ou nœud Code : Pour de petits cas de test simples, le nœud Edit Fields convient, te permettant de définir manuellement des champs et des valeurs individuels. Pour des structures de données plus complexes ou des cas limites précis, le nœud Code te donne un contrôle total sur la structure et le contenu des données de test.
• Nœud Customer Datastore : Ce nœud fournit un jeu de données d'exemple tout prêt lorsque tu n'as pas tes propres données de test sous la main et que tu veux quand même continuer à travailler avec des jeux de données d'apparence réaliste.

En pratique, tu combines souvent les deux fonctionnalités : tu génères d'abord des Mock Data pour un scénario de test précis, tu ajustes les valeurs de manière ciblée, puis tu les épingles ensuite afin de retrouver exactement la même situation à chaque nouveau passage de test.

Limites de Pin Data et Mock Data

Les deux fonctionnalités sont explicitement conçues pour la phase de développement, pas pour l'exploitation courante. Selon la documentation officielle de n8n sur Pin Data et Mock Data, les règles suivantes s'appliquent :

• Le Data Pinning n'est pas disponible pour les exécutions de workflow en production. Dès qu'un workflow activé s'exécute, n8n ignore les données épinglées et récupère des données réelles.
• Tu ne peux pas épingler de données si la sortie contient des données binaires.
• Le Data Pinning ne fonctionne que pour les nœuds ayant exactement une seule sortie principale.

Ces restrictions ne sont pas un hasard : elles empêchent que des données de test fixées ne s'infiltrent accidentellement dans des exécutions en production et n'y fournissent des valeurs obsolètes ou incorrectes. Lorsque tu mets un workflow en service en production, tu devrais donc vérifier spécifiquement une nouvelle fois avant l'activation si des données de test épinglées subsistent encore quelque part.

Mode Debug : retravailler avec de vraies données d'erreur

Le mode Debug prend le relais exactement là où Pin Data et Mock Data s'arrêtent : sur une exécution en production déjà effectuée mais ayant échoué. Selon la documentation n8n sur le débogage des exécutions, cette fonctionnalité charge les données d'une exécution passée dans ton workflow actuel, ce qui est particulièrement précieux pour comprendre des passages en production ayant échoué. Voici comment procéder :

• Ouvre l'onglet Executions dans le workflow pour voir l'historique des exécutions.
• Sélectionne l'exécution que tu veux examiner.
• Pour les exécutions échouées, clique sur Debug in editor, pour celles réussies, clique sur Copy to editor.
• n8n transfère automatiquement les données d'exécution dans ton éditeur de workflow et épingle les données au premier nœud du workflow.

Tu peux ainsi continuer à travailler exactement avec les données ayant déclenché l'erreur, tester ta correction directement contre ce cas, puis seulement remettre le tout en ligne. Selon n8n, la fonctionnalité est disponible sur n8n Cloud ainsi que pour les instances communautaires enregistrées ; les exécutions qui apparaissent effectivement dans la liste dépendent en outre des paramètres de rétention de ton workflow.

Si tu exploites des workflows n8n en production et que tu ne veux pas repartir de zéro à chaque erreur, une routine fixe est payante : épingler les données de test avant de travailler sur la logique, reproduire les cas d'erreur réels via le mode Debug, et ne remettre en ligne qu'après un passage de test propre sans données épinglées. Dans le cadre de l'automatisation avec n8n, nous intégrons dès le départ ce type de routines de test dans les workflows de nos clients, afin que les modifications ne s'exécutent pas au hasard contre des systèmes en production.

Questions fréquentes

Puis-je aussi utiliser Pin Data avec un déclencheur webhook ?

Oui. Surtout lorsqu'un workflow est démarré par un système externe comme un appel webhook, Pin Data t'aide à éviter de solliciter à nouveau le système déclencheur à chaque test. Tu épingles les données de départ reçues une fois et tu continues ensuite à travailler directement avec ce jeu de données fixé.

Pin Data fonctionne-t-il aussi avec des données binaires comme des fichiers ou des images ?

Non. Si la sortie d'un nœud contient des données binaires, cette sortie ne peut pas être épinglée selon la documentation n8n. Dans ce cas, il ne reste plus qu'à solliciter réellement une fois la source binaire en direct pendant le test, ou à travailler avec un jeu de données de remplacement simplifié sans composante binaire.

Que se passe-t-il avec les données de test épinglées lorsque j'active le workflow ?

Rien de problématique, tant que tu as travaillé proprement : le Data Pinning n'a aucun effet sur les exécutions en production, un workflow activé récupère donc automatiquement à nouveau des données réelles. Cela vaut tout de même la peine de vérifier délibérément avant la mise en ligne si des données de test épinglées subsistent dans certains nœuds, afin d'éviter toute confusion lors de la prochaine modification.

Quelle est la différence concrète entre Pin Data et Mock Data ?

Mock Data crée un jeu de données de test à partir de zéro, par exemple via le nœud Edit Fields ou Code, sans aucune source de données réelle. Pin Data, en revanche, fige la sortie réelle d'un nœud, que cette sortie provienne d'un véritable appel système ou qu'elle ait elle-même été générée auparavant comme Mock Data. En pratique, les deux fonctionnalités sont souvent combinées.

Le mode Debug est-il aussi disponible sur une instance n8n autohébergée ?

Selon la documentation n8n, la fonction de débogage est disponible sur n8n Cloud ainsi que pour les instances communautaires enregistrées. Les exécutions précises qui apparaissent dans l'historique et la durée pendant laquelle elles sont conservées dépendent en outre des paramètres de rétention des données d'exécution du workflow.