Classer et router automatiquement les documents entrants avec l’IA dans n8n (Drive, Dropbox)

Un dossier partagé « À traiter » qui reçoit factures, contrats, CV et pièces d’identité en vrac est un classique dans presque toute PME. Quelqu’un dépose le fichier, personne ne le renomme, et trois semaines plus tard il faut fouiller à la main pour retrouver « le contrat signé par le client X en juin ». Un pipeline n8n qui lit chaque document à son arrivée, en identifie la nature et le range au bon endroit avec un nom cohérent élimine ce travail de rangement — sans changer les habitudes de dépôt de personne.

Pourquoi automatiser le classement plutôt que trier à la main

Le tri manuel de documents souffre de trois défauts structurels :

• Il dépend d’une discipline individuelle : tant que chacun renomme et range ses fichiers correctement, le dossier reste propre. Il suffit d’une personne pressée pour que le système se dégrade ;
• Il ne scale pas : dix documents par semaine se trient sans effort, deux cents deviennent un projet à part entière ;
• Il ne laisse pas de trace exploitable : sans journal de qui a classé quoi et quand, retrouver l’historique d’un document précis reste une recherche manuelle dans l’arborescence de fichiers.

Un LLM branché en aval d’un déclencheur de stockage résout les trois points à la fois : il lit le contenu (pas seulement le nom du fichier), classe selon un schéma défini une fois pour toutes, et journalise chaque décision.

Étape 1 — Détecter l’arrivée d’un nouveau document

Le node Google Drive Trigger de n8n surveille un dossier précis (indispensable de préciser l’ID du dossier plutôt que de laisser « Mon Drive » entier, sous peine de déclencher le workflow sur chaque fichier existant de votre compte). Réglé sur un intervalle d’une minute, il détecte les créations et mises à jour de fichiers dans ce dossier. Pour un usage sur un Drive partagé d’équipe, pensez à activer l’option « Use Shared Drive » à la fois sur le credential et sur le node : c’est l’oubli le plus fréquent, il se traduit par des erreurs 404 sur des fichiers pourtant bien visibles dans l’interface.

Pour une équipe qui centralise déjà ses fichiers sur Dropbox, le node Dropbox Trigger couvre le même besoin avec une logique de polling équivalente sur un dossier surveillé — la suite du pipeline (extraction, classification, rangement) reste identique quel que soit le stockage d’origine.

Étape 2 — Extraire le contenu et classifier par IA

Une fois le fichier détecté, le node Extract from File récupère le texte pour les PDF natifs et les documents Office. Pour un scan ou une photo de document, un LLM multimodal (vision) traite directement l’image sans étape d’OCR séparée — la même approche que celle détaillée dans notre article sur l’extraction de données de factures PDF par IA.

Le contenu extrait passe ensuite dans une Basic LLM Chain couplée à un Structured Output Parser, avec un schéma qui force une réponse exploitable plutôt qu’un texte libre :

{
  "categorie": "facture | contrat | cv | piece_identite | bon_commande | autre",
  "confiance": 0.0,
  "nom_suggere": "2026-07-facture-fournisseur-x.pdf",
  "resume": "Résumé en une phrase du contenu du document"
}

Le prompt système doit énumérer explicitement les catégories possibles — exactement comme pour la classification d’emails du Pack Inbox IA — pour éviter que le modèle invente des libellés proches mais non identiques (« facture » un jour, « invoice » le lendemain), impossibles à agréger ensuite dans un Switch ou un rapport.

Ce principe de classification automatique de documents n’est pas nouveau : dès 2014, une étude de Kang, Kumar et al. (ICPR 2014) montrait qu’un réseau de neurones convolutif pouvait classer des images de documents avec des performances nettement supérieures aux approches à base de règles et de features manuelles de l’époque. La différence aujourd’hui : un LLM généraliste atteint un niveau comparable en zero-shot, sans corpus d’entraînement dédié ni pipeline de vision spécialisé à maintenir — ce qui rend l’automatisation accessible à une PME en une après-midi plutôt qu’à une équipe data en plusieurs semaines.

Étape 3 — Router et renommer automatiquement

Le champ categorie structuré alimente un node Switch qui aiguille le document vers l’une de ses branches. Sur chaque branche, un node Google Drive (opération Move) déplace le fichier dans le sous-dossier correspondant (/Factures, /Contrats, /RH/CV, /KYC…), et une opération Update applique le nom suggéré par le modèle — typiquement AAAA-MM-categorie-identifiant.ext, un format qui trie naturellement par date dans l’explorateur de fichiers sans effort supplémentaire.

Pour les documents sensibles (pièces d’identité, contrats), il est recommandé de router également vers un dossier à accès restreint plutôt qu’un dossier partagé large — le Switch peut très bien avoir une sortie dédiée qui applique en plus un changement de permissions via l’API Drive.

Étape 4 — Journaliser et gérer les cas ambigus

Chaque décision de classement s’écrit dans une table Supabase (documents_classes : nom original, catégorie, confiance, chemin final, horodatage) via le node Supabase. C’est la même logique de piste d’audit que celle décrite dans notre guide de connexion n8n-Supabase, et elle rejoint directement l’architecture du Pack Conformité & Audit pour les organisations qui doivent démontrer une traçabilité documentaire complète.

Le champ confiance sert de garde-fou : sous un seuil défini (0,7 par exemple), un node IF détourne le document vers une notification Slack plutôt que vers un classement automatique — exactement le pattern décrit dans notre article sur l’approbation humaine avec le node Wait et des boutons Slack. Un scan illisible ou un document hybride (facture qui contient aussi des conditions contractuelles) finit ainsi devant une relecture humaine plutôt que mal classé silencieusement.

Pièges à éviter

• Traiter un import massif sans cadencement : si vous branchez ce pipeline sur un dossier déjà rempli de plusieurs centaines de fichiers, le déclencheur va tous les envoyer d’un coup vers l’API du modèle. Un Loop Over Items avec un Wait entre chaque lot évite les erreurs 429 — voir notre article sur les rate limits des API IA dans n8n ;
• Ignorer les doublons : deux dépôts du même fichier (renommé légèrement différemment) produisent deux entrées distinctes. Une vérification par hash de contenu avant classement, plutôt que par nom de fichier, réduit ce risque ;
• Laisser les erreurs disparaître silencieusement : un timeout sur l’extraction ou l’appel LLM ne doit jamais faire disparaître un document important sans notification — un Error Workflow dédié, comme décrit dans notre guide de gestion des erreurs n8n, couvre ce cas.

Combien ça coûte

Pour un LLM économique (GPT-4o mini ou équivalent), classer un document d’une à quelques pages coûte de l’ordre de quelques centimes en tokens, OCR vision inclus sur un scan. Pour un flux de cent documents par mois, la facture reste de l’ordre de quelques euros — largement compensée par le temps de tri manuel économisé, sans compter la fiabilité de retrouver un document classé plutôt que perdu dans un dossier fourre-tout.

Conclusion

Un pipeline de classement documentaire tient en quatre briques : détection à l’arrivée (Google Drive ou Dropbox Trigger), extraction et classification par IA avec sortie structurée, rangement et renommage automatiques, et journalisation avec garde-fou de confiance pour les cas ambigus. C’est exactement l’architecture d’ingestion documentaire du Pack Assistant RAG, réutilisable telle quelle : si vos documents classés doivent ensuite être interrogeables (« retrouve-moi la clause de préavis du contrat X »), le pipeline RAG prend le relais directement là où celui-ci s’arrête.