Aller au contenu principal

Formats de fichiers supportés

Mis à jour le 29 juillet 2026

Le critère qui décide de tout

Avant de vous demander si tel format passe ou non, posez-vous une question plus simple : le fichier contient-il du texte extractible ? La Files API de xAI traite des fichiers textuels. Si un outil quelconque peut en sortir des caractères sans faire de reconnaissance optique, le document est très probablement accepté. Les fichiers purement binaires — images, audio, vidéo — n’ont rien à y faire ; pour une image, la voie correcte est input_image dans l’API Responses, pas la Files API.

Ce critère unique explique la plupart des refus que vous rencontrerez. Il explique aussi pourquoi un PDF de rapport financier fonctionne parfaitement tandis qu’un PDF issu d’un scanner de bureau échoue : le premier porte une couche de texte, le second n’est qu’une suite de photographies de pages.

Les quatre familles acceptées

Les formats supportés se rangent en quatre familles, chacune avec ses usages privilégiés.

FamilleFormatsCe que Grok en tire
Documents bureautiquesPDF, DOCX, ODT, EPUB, RTFTexte, tableaux, structure des sections
Code source.py, .js, .ts, .java, .go, .rs, .cpp, HTML, CSS, XML et 80+ langagesImports, dépendances, structure du fichier
Données structuréesCSV, TSV, JSON, JSON-LD, vCardHiérarchie des champs, statistiques, tendances
Texte brutTXT, MDContenu linéaire, titres et listes en Markdown

Du côté bureautique, le PDF reste le format le plus courant et Grok en extrait le texte, les tableaux et le découpage en sections. Le DOCX de Word conserve sa mise en forme — gras, italique, listes — dans l’extraction, tout comme son équivalent libre ODT. L’EPUB devient intéressant dès que vous travaillez sur des publications longues, un livre blanc ou un manuel entier, et le RTF, plus ancien, reste suffisamment répandu pour être pris en charge.

Le code source est le terrain où la Files API se distingue le plus nettement du copier-coller. Envoyer paiement.py en entier plutôt qu’une fonction isolée change la nature de l’analyse : Grok voit les imports, les dépendances et l’organisation du fichier, et peut donc repérer qu’une exception est attrapée trente lignes plus haut ou qu’une constante définie en tête contredit un commentaire du bas. Plus de quatre-vingts langages à syntaxe textuelle sont couverts.

Les formats de données servent surtout l’analyse quantitative. Un CSV de ventes mensuelles permet à Grok de calculer des écarts, de repérer une saisonnalité et de résumer un jeu de plusieurs milliers de lignes ; un JSON de configuration ou de réponse d’API lui donne accès à la hiérarchie et aux relations entre champs, ce qu’un tableau aplati ne montrerait pas. JSON-LD ajoute un contexte sémantique aux données liées, et vCard couvre les fiches de contact. Enfin, TXT et MD fonctionnent sans surprise, le Markdown ayant l’avantage de transmettre une structure légère de titres et de listes.

Là où ça bloque

Quatre contraintes reviennent constamment en production. La première est la taille : 48 MB par fichier, au-delà desquels il faut découper le document. La deuxième est l’encodage : vos fichiers doivent être en UTF-8, et un export en ISO-8859 ou Windows-1252 produira des caractères accentués corrompus, parfois de façon discrète — un « é » devenu « é » au milieu d’un contrat passe inaperçu jusqu’à ce qu’une recherche ne trouve plus rien. La troisième est l’absence de traitement des images : PNG, JPG ou GIF n’ont pas leur place ici, il faut passer par input_image. La quatrième est le cas du PDF scanné sans couche texte OCR, qui sera accepté à l’upload mais restera muet à l’interrogation.

Cette dernière situation mérite un réflexe : avant d’uploader un lot de PDF d’origine incertaine, ouvrez-en un et tentez de sélectionner un paragraphe à la souris. Si rien ne se sélectionne, vos documents devront passer par une océrisation en amont.

Choisir le format le plus structuré possible

Quand la même information existe sous plusieurs formes, prenez systématiquement la plus structurée. Pour l’analyse d’un rapport, préférez le PDF ou le DOCX d’origine, qui conservent la hiérarchie, plutôt qu’un export texte à plat. Pour de l’analyse de données, un CSV pour les tableaux et un JSON pour les données hiérarchiques donneront de meilleurs résultats qu’une capture de tableur transformée en prose. Pour une revue de code, envoyez le fichier source original avec son extension d’origine. Pour de la documentation, le Markdown ou le PDF conviennent selon ce dont vous disposez à la source. La règle tient en une phrase : chaque niveau de structure que vous conservez est un niveau de contexte que le modèle n’aura pas à reconstituer.

Points clés à retenir

  • La Files API supporte les documents (PDF, DOCX, EPUB), le code (80+ langages), les données (CSV, JSON) et le texte brut
  • La limite est de 48 MB par fichier en encodage UTF-8
  • Les images et fichiers binaires ne sont pas supportés — utilisez input_image pour les images
  • Privilégiez le format le plus structuré possible pour obtenir de meilleures analyses