Travailler avec des documents longs et des inputs volumineux

Déposez un contrat de 60 pages dans ChatGPT et demandez « extrais toutes les clauses » : vous obtiendrez une réponse assurée et fluide qui passe discrètement à côté d'un tiers du document. Le modèle n'a pas menti. Il a heurté un mur que vous ne voyiez pas. Cette leçon consiste à voir ce mur, puis à le contourner par conception.

Les deux limites que vous combattez réellement

Il y a deux contraintes distinctes, et on les confond en permanence.

La première est la context windowcontext windowLa context window est la quantité maximale de texte (mesurée en tokens) qu'un modèle de langage peut traiter en une seule fois, prompt d'entrée et sortie générée compris.Voir la définition complète → : la quantité de texte que le modèle peut garder en mémoire de travail d'un coup. Les modèles ChatGPT récents ont de grandes fenêtres, mais « grand » n'est pas « infini », et la fenêtre contient votre fichier *plus* vos instructions *plus* toute la conversation antérieure *plus* la production du modèle lui-même. Un contrat de 60 pages peut à lui seul en consommer une bonne partie.

La seconde est le budget d'attention : même quand le texte tient techniquement, les modèles répartissent leur attention de façon inégale sur un input long. Le contenu situé au milieu d'un gros bloc est moins bien traité que celui du début ou de la fin. C'est pourquoi un contrat qui « tient » produit quand même un résumé qui rate la clause 34 enfouie page 41.

Le mode de défaillance est donc rarement une erreur franche. C'est l'omission silencieuse. **Votre travail consiste à concevoir des prompts et des pipelines qui rendent l'omission *visible* et *peu coûteuse à détecter***.

Comment ChatGPT ingère un fichier (et pourquoi ça compte)

Quand vous uploadez un PDF dans ChatGPT, il se passe l'une de deux choses selon l'outil en jeu.

Si Advanced Data Analysis (le sandbox Code Interpreter) est actif, ChatGPT peut exécuter du Python pour ouvrir le fichier, le parser et en extraire le texte page par page. Il ne « lit » pas l'ensemble dans le modèle d'un seul coup. Il écrit du code qui traite le document programmatiquement, puis raisonne sur les résultats.

Si vous êtes dans un chat simple sans le sandbox, le fichier est chargé plus directement dans le contexte, et vous êtes bien plus exposé aux deux limites ci-dessus.

Cette distinction est le levier le plus important dont vous disposez. Pour un document long et structuré, vous voulez que le modèle écrive du code sur le fichier, pas qu'il s'entasse le fichier dans la tête. Voir la présentation par OpenAI de la gestion des fichiers et des outils pour le comportement actuel.

Stratégie 1 : imposer une extraction structurée, pas un résumé

« Résume ce contrat » est la mauvaise demande. Les résumés compressent, et la compression est là où les clauses meurent.

Définissez plutôt un schéma : les champs exacts que vous voulez pour chaque élément, répétés mécaniquement. Cela transforme une tâche de lecture floue en une tâche de remplissage de cases, que les modèles exécutent bien plus fiablement.

Voici le pattern de prompt pour le contrat :

Parcours le contrat joint section par section. Pour chaque clause et sous-clause numérotée, produis une ligne avec : clause_id, heading, verbatim_text (200 premiers caractères), plain_english, obligations_on_us, obligations_on_them, risk_flag (low/med/high). Ne résume pas d'une clause à l'autre. Si une clause a des sous-parties, liste chaque sous-partie comme sa propre ligne. Termine par un décompte du total de clauses trouvées.

Deux choses font que ça marche. Le schémamaUtiliser un logiciel pour automatiser les tâches et campagnes marketing répétitives, afin de personnaliser à grande échelle sur des canaux comme l'email, le web et le social.Voir la définition complète → par clause empêche le modèle d'écraser le détail, et le décompte final vous donne un contrôle d'intégrité peu coûteux. Si la numérotation en page 1 s'arrarrL'Annual Recurring Revenue (ARR) est le revenu normalisé et prévisible qu'une entreprise par abonnement attend de ses contrats actifs sur une année.Voir la définition complète →ête à 9.4 mais que le modèle annonce 22 clauses, vous avez un écart à instruire.

Stratégie 2 : découper volontairement, pas par accident

Pour un contrat de 60 pages, ne collez pas l'ensemble en espérant que ça passe. Découpez-le en unités logiques (par Article, par Section), et traitez chaque morceau avec le *même* schéma. Le chunking signifie ici découper l'input en morceaux assez petits pour que le modèle prête attention à l'intégralité de chacun.

La règle clé : découpez sur des frontières sémantiques, pas sur des comptes de caractères arbitraires. Couper au milieu d'une clause crcrLe pourcentage de visiteurs ou de prospects qui réalisent une action attendue (achat, inscription, formulaire de contact), calculé en divisant les conversions par le nombre total d'opportunités.Voir la définition complète →ée du texte orphelin qui perturbe l'extraction. Coupez à « Article 5 », « Article 6 », et ainsi de suite.

Dans ChatGPT, vous pouvez le faire de façon conversationnelle à l'intérieur d'un même Project (pour que le schéma et les instructions persistent) :

1. « Voici le contrat. D'abord, liste chaque titre d'Article et sa plage de pages. N'extrais rien encore. »
2. Vérifiez vous-même cette liste face au sommaire.
3. « Maintenant extrais les clauses des Articles 1 à 3 uniquement, en utilisant le schéma. »
4. Répétez par lot d'Articles, puis demandez un tableau fusionné.

Le faire dans un Project a son importance : votre schéma, vos custom instructions et le fichier uploadé restent cantonnés à cet espace de travail, si bien que chaque lot hérite des mêmes règles sans avoir à tout recoller.

Stratégie 3 : laisser Code Interpreter faire le gros du travail

Pour un document de 60 pages, la voie la plus fiable dans ChatGPT est de faire découper le fichier de façon déterministe par Advanced Data Analysis, puis d'extraire chunk par chunk. Vous pouvez littéralement demander :

Avec Python, ouvre le PDF, découpe le texte avec la regex des numéros de clause (par ex. lignes commençant par \d+\. ou \d+\.\d+), et montre-moi combien de clauses tu as détectées et leurs IDs. N'extrais pas encore le contenu.

Maintenant c'est le *code* qui a trouvé les clauses, pas l'attention du modèle. Vous obtenez un décompte déterministe sur lequel ancrer tout le reste. Ensuite vous extrayez le texte des clauses par lots, là encore via du code, pour que rien ne disparaisse silencieusement.

Quand ChatGPT ne suffit pas : l'APIAPIApplication Programming Interface : une interface standardisée qui permet aux applications de communiquer et d'échanger des données sans connaître leur fonctionnement interne respectif.Voir la définition complète → et les structured outputs

L'interface de chat est très bien pour un contrat ponctuel. Pour des dizaines de contrats, ou pour une sortie à laquelle vous pouvez vous fier sans relire chaque ligne, passez à l'API OpenAI, où vous pouvez imposer le schéma programmatiquement.

La fonctionnalité concernée est Structured Outputs : vous fournissez au modèle un JSON SchemaSchemaUn schema est le plan formel qui définit comment les données sont structurées, nommées, typées et reliées entre elles au sein d'une base de données, d'un fichier ou d'un message.Voir la définition complète →, et la réponse est *garantie* conforme à cette forme. Pas de surprise du type « le modèle a oublié un champ ». Combinez-la au chunking et vous avez un vrai pipelinepipelineL'ensemble des opportunités commerciales actives réparties selon les étapes du processus de vente, avec leur valeur potentielle cumulée et leur probabilité de conclusion.Voir la définition complète → d'extraction.

Voici un exemple compact avec la Responses API. Vous bouclez sur des chunks pré-découpés et forcez chaque résultat dans votre schéma de clauses :

from openai import OpenAI

client = OpenAI()

clause_schema = {
    "type": "object",
    "properties": {
        "clauses": {
            "type": "array",
            "items": {
                "type": "object",
                "properties": {
                    "clause_id": {"type": "string"},
                    "heading": {"type": "string"},
                    "plain_english": {"type": "string"},
                    "risk_flag": {"type": "string", "enum": ["low", "med", "high"]},
                },
                "required": ["clause_id", "heading", "plain_english", "risk_flag"],
                "additionalProperties": False,
            },
        }
    },
    "required": ["clauses"],
    "additionalProperties": False,
}

def extract(chunk_text: str) -> dict:
    resp = client.responses.create(
        model="gpt-4.1",
        input=[
            {"role": "system", "content": "Extract every clause. Do not summarize across clauses."},
            {"role": "user", "content": chunk_text},
        ],
        text={"format": {"type": "json_schema", "name": "clauses", "schema": clause_schema, "strict": True}},
    )
    return resp.output_text

for i, chunk in enumerate(article_chunks):
    print(f"Article {i + 1}:", extract(chunk))

Parce que strict vaut True, chaque chunk renvoie du JSON valide exactement à votre forme. Vous fusionnez les tableaux, dédupliquez par clause_id, et vous avez une extraction complète, vérifiable par machine. La référence officielle est Structured Outputs dans la documentation OpenAI.

Notez ce que nous n'avons *pas* fait : nous n'avons pas envoyé 60 pages en un seul appel. Nous avons envoyé des chunks sémantiques, chacun largement dans une plage d'attention confortable, et le schéma garantissait la complétude par chunk.

Vérification : l'étape que tout le monde saute

Un pipeline documents longs ne vaut que ses contrôles. Trois contrôles peu coûteux attrapent la plupart des défaillances.

Réconciliation des décomptes. Code Interpreter (ou votre regex) a trouvé N identifiants de clause. Votre tableau extrait a M lignes. Si N est différent de M, listez les IDs manquants. Ce seul contrôle attrape le bug d'omission silencieuse le plus courant.

Contrôle ponctuel verbatim. Demandez : « Pour les clauses 12.3, 31.1 et 48.2, colle le texte source exact à côté de ta version en langage clair. » Si le texte verbatim n'existe pas dans le document, le modèle l'a inventé, et vous avez attrapé une hallucinationhallucinationUne hallucination, c'est lorsqu'un modèle d'IA produit une réponse fluide et assurée mais factuellement fausse, inventée, ou non étayée par ses données sources.Voir la définition complète → avant qu'elle n'atteigne votre synthèse.

Relecture adversariale. « Rebalaye le document à la recherche de toute clause d'indemnisation, de résiliation ou de reconduction tacite NON déjà présente dans le tableau. » Les relectures ciblées trouvent ce qu'un passage unique a raté, parce que vous dirigez désormais l'attention vers des catégories de risque précises.

Choisir votre approche

Un guide de décision rapide pour les inputs longs :

• Un document, en exploration : chat ChatGPT avec Advanced Data Analysis, plus le prompt d'extraction structurée. Rapide, conversationnel, suffisant.
• Un document, enjeux élevés : pareil, mais ajoutez les trois étapes de vérification et exigez des citations verbatim pour toute clause à risque élevé.
• Beaucoup de documents, en répétable : API avec chunking et Structured Outputs. Vous obtenez du JSON auditable et pouvez comparer les contrats entre eux.
• Un flux d'entrée continu (par ex. chaque nouveau contrat qui arrive dans un dossier) : encapsulez le pipeline API et déclenchez-le. Les connecteurs et l'outillage agent plus large peuvent acheminer les documents, mais le cœur de l'extraction reste le même : chunk, schéma, vérification.

La tentation, avec des context windows plus grandes, est de balancer tout le document dedans et de faire confiance au modèle. Résistez. Un contrat de 60 pages n'est pas un problème de context window qu'on règle en achetant plus de fenêtre. C'est un problème d'attention et de vérification qu'on règle avec de la structure.

Points clés à retenir

• Le schéma bat le résumé. Définissez des champs exacts par clause et exigez un décompte final. L'omission passe d'invisible à mesurable.
• Découpez sur des frontières sémantiques (Articles, Sections), jamais sur des comptes de caractères arbitraires, et traitez chaque chunk avec le schéma identique.
• Faites d'abord trouver la structure par le code. Faites découper le PDF par Advanced Data Analysis et compter les clauses de façon déterministe avant toute extraction, pour disposer d'un nombre de référence à confronter.
• Pour l'échelle et la confiance, passez à l'API avec Structured Outputs (strict: true) pour que chaque chunk renvoie du JSON garanti valide, fusionnable et auditable.
• Faites toujours la réconciliation des décomptes et un contrôle ponctuel verbatim. Un pipeline documents longs sans vérification n'est qu'une supposition assurée.