Joignez des PDF, des images, des enregistrements audio, des documents Office, des feuilles de calcul, des diapositives et des fichiers texte à n'importe quelle requête d'enrichissement, de génération de schéma, de génération d'échantillon, de modification de schéma par IA ou de playground. Les fichiers parviennent au modèle soit sous forme d'octets natifs (pour les modèles compatibles PDF, vision et audio), soit sous forme de texte extrait côté serveur et intégré au prompt — aucun OCR, transcription, conversion ou découpage manuel requis.
Chaque type MIME pris en charge possède un mode de livraison configuré par l'administrateur. Ce mode détermine comment le fichier parvient au modèle.
Les octets d'origine sont transmis au modèle sous forme de BinaryContent. Le modèle lit le fichier directement — aucun prétraitement côté serveur.
Nécessite un modèle doté de l'indicateur de capacité correspondant (supports_pdf_input pour les PDF, supports_vision pour les images, supports_audio_input pour l'audio). Le sélecteur de modèles est automatiquement filtré pour n'afficher que les modèles compatibles.
Un extracteur côté serveur s'exécute une seule fois au moment de l'envoi et met en cache le texte obtenu. À chaque appel LLM ultérieur, le texte en cache est inséré dans le prompt utilisateur.
Aucune capacité de modèle requise — fonctionne avec tous les modèles. Le texte brut et le Markdown contournent l'extracteur et décodent directement les octets bruts.
19 formats sont activés par défaut. Les administrateurs système peuvent basculer n'importe quel format entre le mode binary et inline_text, modifier son libellé ou le désactiver entièrement depuis Gestion des modèles → Politiques de documents.
| Format | Extensions | Mode par défaut | Capacité / extracteur |
|---|---|---|---|
| Document PDF | binary | supports_pdf_input | |
| Image PNG | .png | binary | supports_vision |
| Image JPEG | .jpg, .jpeg | binary | supports_vision |
| Audio MP3 | .mp3 | binary | supports_audio_input |
| Audio WAV | .wav | binary | supports_audio_input |
| Audio M4A | .m4a | binary | supports_audio_input |
| Audio OGG | .ogg, .oga | binary | supports_audio_input |
| Audio FLAC | .flac | binary | supports_audio_input |
| Texte brut | .txt | inline_text | décodage brut |
| Markdown | .md, .markdown | inline_text | décodage brut |
| Word (ancien .doc) | .doc | binary | docx2txt |
| Word (.docx) | .docx | binary | python-docx |
| Texte OpenDocument | .odt | binary | odfpy |
| Format de texte enrichi | .rtf | binary | striprtf |
| Livre numérique EPUB | .epub | binary | ebooklib |
| HTML | .html, .htm | binary | beautifulsoup |
| CSV | .csv | binary | csv (stdlib) |
| Feuille de calcul (.xlsx) | .xlsx | binary | openpyxl |
| Présentation (.pptx) | .pptx | binary | python-pptx |
Lorsque vous joignez plusieurs fichiers à la génération d'échantillon, la première question est de savoir quel rapport ils ont entre eux — et se tromper là-dessus produit silencieusement un échantillon absurde. La question est donc posée explicitement avant toute génération.
Un contrat et son avenant, une spécification et sa fiche technique : les fichiers sont lus ensemble comme une seule entité.
Dix factures, dix CV. Le type le plus étroit couvrant l'ensemble est déduit, et les valeurs de l'échantillon proviennent d'un seul document choisi plutôt que d'un mélange des dix — un échantillon assemblé à partir de dix sources ne décrit rien de réel.
Neuf factures et une photo de vacances : plutôt que de deviner, le job s'interrompt et demande s'il faut exclure l'intrus. Des fichiers n'ayant absolument rien en commun font échouer le job d'emblée, avec cette raison.
Le même mécanisme de pause et de question couvre toute autre ambiguïté rencontrée par le planificateur : la tâche s'arrête, expose ses questions et reprend avec vos réponses — dans l'application sous forme de boîte de dialogue, et via l'API et MCP sous forme d'étape de réponse explicite. Mieux vaut prévenir une hypothèse erronée que la découvrir dans le schéma généré.
Une chose dont les documents ne vous dispensent pas : un schéma généré à partir de vos fichiers démarre avec la vérification d'ambiguïté activée, exactement comme n'importe quel autre. Cette vérification demande si un nom de propriété admet plusieurs sens — une question sur la formulation du schéma, non sur l'origine des valeurs de cette exécution. Votre document a fixé les valeurs une fois ; le schéma, lui, sera réutilisé sur des entités qu'il ne couvrait pas.
(organization_id, sha256).inline_text, l'extracteur s'exécute au moment du téléversement et le texte obtenu est mis en cache sur la ligne de la pièce jointe. Les appels LLM suivants réutilisent le texte en cache — aucun coût de ré-extraction. Les formats binary ignorent cette étape.DELETE /api/attachments/{id} — une étape de nettoyage pratique après enrichissement. La suppression est limitée à l'organisation et renvoie { success, id, filename }.Les pièces jointes peuvent être téléversées et supprimées par programmation, pas seulement depuis l'interface web : le connecteur n8n téléverse en multipart natif, les connecteurs Make.com et MCP téléversent via la route JSON base64, et tout client peut utiliser directement l'API REST (DELETE /api/attachments/{id} pour le nettoyage).
Lorsque vous joignez un fichier binaire avec une exigence de capacité (PDF, image ou audio), le sélecteur de modèles est filtré pour n'afficher que les modèles qui déclarent cette capacité. Si vous joignez plusieurs fichiers avec des exigences différentes, seuls les modèles satisfaisant toutes les exigences apparaissent.
L'API applique la même règle : associer un modèle incompatible à une pièce jointe binaire renvoie 400 model_lacks_attachment_capability, de sorte que les intégrations qui contournent l'interface obtiennent une erreur claire en amont plutôt qu'un échec du fournisseur en cours de tâche. Les pièces jointes en texte intégré n'imposent jamais d'exigence.
| Fichiers joints | Modèles éligibles |
|---|---|
| 1 PDF | supports_pdf_input |
| 1 PNG | supports_vision |
| 1 MP3 | supports_audio_input |
| 1 PDF + 1 PNG | supports_pdf_input ET supports_vision |
| 1 DOCX (mode binaire, aucune capacité) | Tous les modèles — la prise en charge native des octets est supposée quand aucun indicateur de capacité n'est défini |
| 1 TXT ou 1 MD (mode inline_text) | Tous les modèles — le texte est inséré directement dans le prompt |
Les pièces jointes sont facturées comme des jetons d'entrée rapportés par le fournisseur du modèle — Entity Enricher n'applique aucuns frais distincts par document. Le coût dépend du type de fichier et du modèle sélectionné.
Consomment des tokens d'entrée spécifiques au modèle. Anthropic facture environ 1700 tokens par page PDF ; OpenAI tarifie les entrées vision selon le nombre de tuiles ; les modèles compatibles audio mesurent l'entrée audio proportionnellement à sa durée. Consultez la fiche tarifaire de votre modèle dans Modèles et tarifs.
Le texte extrait consomme des jetons d'entrée au tarif texte standard. Les documents volumineux sont plafonnés à 500 Ko de texte extrait — le contenu au-delà est tronqué.