Gouverner les agents IA n8n : souveraineté et preuve d'audit

n8n est souvent choisi pour une raison précise : garder l'automatisation chez soi. Serveur dans son pays, données qui ne transitent pas par un service tiers, contrôle complet du code. C'est une posture de souveraineté sérieuse, et elle a de vraies conséquences positives.

Mais elle crée aussi un angle mort. Héberger le moteur dans sa juridiction ne dit rien de la juridiction des services qu'il appelle. Un workflow n8n auto-hébergé en Europe qui enrichit une fiche client via une API américaine, puis écrit dans un outil hébergé ailleurs encore, réalise exactement les transferts que l'auto-hébergement était censé éviter — simplement un cran plus loin dans la chaîne.

Le scénario d'intégration

n8n est le terrain le plus simple de ce wiki : un nœud de requête HTTP avant le nœud sensible, et un nœud conditionnel qui route sur la décision. Et parce que n8n exécute votre code, vous pouvez rendre le comportement strict — échouer fermé sur les actions irréversibles — sans dépendre de quiconque.

1. 1

   Générez le profil de votre organisation

   L'évaluation gratuite (commencer ici) établit vos juridictions, votre secteur et vos catégories de données. Ce profil rend chaque décision spécifique à votre déploiement.

2. 2

   Cartographiez les nœuds qui sortent

   Dans chaque workflow, listez les nœuds qui envoient des données personnelles vers un service externe, et notez où ce service héberge. C'est un exercice de quelques heures qui vaut pour tous vos workflows.

3. 3

   Insérez le nœud de décision

   Un nœud HTTP vers l'endpoint de décision, avec les métadonnées du nœud suivant. Puis un nœud conditionnel qui aiguille selon la réponse.

   curl -X POST https://structureclerk.ca/api/v1/authority/decide \
     -H 'Authorization: Bearer $CLE_API' \
     -H 'Content-Type: application/json' \
     -d '{"agent":{"id":"n8n-enrichment-agent","autonomy_level":3},"action":{"type":"share.customer_record","data_categories":["personal"],"destination_jurisdiction":"US_FED"},"context":{"jurisdictions":["FR"],"sector":"health"}}'

4. 4

   Choisissez votre posture d'échec

   Vous exécutez le workflow, donc vous décidez : échouer fermé (ne pas appeler le service externe si la décision est indisponible) pour les données sensibles, échouer ouvert pour le reste. C'est un avantage de l'auto-hébergement — la politique est vraiment la vôtre.

Le contrat de décision

POST https://structureclerk.ca/api/v1/authority/decide
{
  "agent": { "id": "n8n-enrichment-agent", "autonomy_level": 3 },
  "action": {
    "type": "share.customer_record",
    "data_categories": ["personal"],
    "destination_jurisdiction": "US_FED"
  },
  "context": { "jurisdictions": ["FR"], "sector": "health" }
}
// →
{
  "decision": "DENY",
  "reason": "sensitive_data_regulated_sector",
  "confidence": 0.96,
  "evidence_id": "ev_0d18…bb45"
}

La décision est consultative — StructureClerk décide, votre infrastructure applique. Dans un déploiement auto-hébergé, cette séparation est un atout : le moteur d'autorité ne voit jamais vos données, et votre workflow ne dépend jamais de sa disponibilité.

La souveraineté, prouvée plutôt qu'affirmée

Auto-héberger est un argument que beaucoup d'équipes avancent auprès de leurs clients. La preuve signée le rend démontrable : chaque décision d'autorité laisse une trace Ed25519 chaînée, vérifiable sur notre page de vérification sans compte, qui montre quelles données ont été autorisées à sortir, vers quelle juridiction, et sur quelle base.

C'est la différence entre « nous hébergeons en Europe » — une affirmation — et une chaîne de décisions qu'un client contrôle lui-même. La seconde survit à un questionnaire fournisseur ; la première y répond mal.