La guerre des fenêtres de contexte est déjà terminée

Depuis près de deux ans, un chiffre revient systématiquement dans les annonces des grands laboratoires d’intelligence artificielle.

128 000 tokens.

256 000 tokens.

1 million de tokens.

10 millions de tokens.

À chaque nouvelle génération de modèles, la taille de la fenêtre de contexte semble être devenue un argument marketing. À croire que le modèle capable de lire le plus grand nombre de pages serait automatiquement le plus intelligent.

Pourtant, plus j’observe l’évolution des modèles et les recommandations publiées par OpenAI, Anthropic, Google ou encore Microsoft, plus je suis convaincu que nous regardons le mauvais indicateur.

La véritable révolution n’est plus la taille de la fenêtre de contexte.

Elle est dans la manière de la construire.

Une grande fenêtre ne rend pas un modèle plus intelligent

Il est facile de comprendre pourquoi les fenêtres de contexte sont devenues un sujet aussi populaire.

Une fenêtre de contexte représente tout ce que le modèle peut « voir » au moment où il produit sa réponse :

• vos instructions ;
• la conversation précédente ;
• vos documents ;
• vos fichiers ;
• les résultats d’une recherche ;
• les appels d’outils ;
• parfois même des images ou de l’audio.

Intuitivement, on pourrait croire que plus cette fenêtre est grande, meilleure sera la réponse.

En réalité, ce n’est pas ce que montrent les modèles actuels.

Certaines versions récentes disposent d’une fenêtre plus petite que leur prédécesseur tout en obtenant de meilleurs résultats sur les benchmarks de raisonnement.

À l’inverse, certains modèles capables d’accepter plusieurs millions de tokens ne produisent pas nécessairement de meilleures réponses lorsqu’on leur fournit un immense volume d’informations.

Pourquoi ?

Parce que le problème n’est pas la quantité d’information.

Le problème est la qualité de cette information.

La fenêtre de contexte ne contient pas seulement le prompt visible de l’utilisateur. Elle regroupe toutes les informations transmises au modèle au moment de l’inférence : les instructions système, l’historique de la conversation, les parties des documents récupérés (On reviendra la dessus dans un autre article…), les résultats d’outils et les données propres à l’organisation.

flowchart LR
    A[Instructions système] --> F[Fenêtre de contexte]
    B[Prompt de l’utilisateur] --> F
    C[Historique de la conversation] --> F
    D[Documents et sources] --> F
    E[Résultats de recherche et outils] --> F
    G[Connaissances de l’entreprise] --> F

    F --> H[Inférence du modèle]
    H --> I[Réponse générée]

    classDef context fill:#e8f1ff,stroke:#2563eb,stroke-width:2px;
    classDef inference fill:#f3e8ff,stroke:#7c3aed,stroke-width:2px;
    classDef output fill:#e8fff2,stroke:#059669,stroke-width:2px;

    class F context;
    class H inference;
    class I output;

Ce schéma permet de comprendre pourquoi la taille nominale de la fenêtre ne suffit pas à prédire la qualité d’une réponse. Le modèle ne dispose que de ce qui a réellement été placé dans cette fenêtre. Une immense capacité inutilisée ou remplie de données peu pertinentes n’apporte aucun avantage particulier.

Une bibliothèque n’est pas un cerveau

Imaginez deux situations.

Dans la première, je vous donne un dossier de quinze pages parfaitement organisé contenant exactement les informations dont vous avez besoin.

Dans la seconde, je vous donne accès à une bibliothèque de plusieurs centaines de milliers de livres.

Dans quel cas serez-vous le plus efficace ?

La réponse paraît évidente.

Le cerveau humain fonctionne mieux lorsque l’information pertinente est facilement accessible.

Les modèles génératifs ne sont pas si différents.

Une fenêtre de contexte remplie de documents inutiles, redondants ou contradictoires devient rapidement du bruit.

Et ce bruit finit par masquer les informations réellement importantes.

Autrement dit, une fenêtre de contexte utilisée à 100 % n’est pas nécessairement une fenêtre bien utilisée.

La performance d’un modèle ne progresse pas automatiquement avec le volume d’information fourni. Lorsque le contexte pertinent augmente, la réponse peut gagner en précision. Mais lorsque l’on ajoute des documents redondants, contradictoires ou inutiles, le bruit commence à masquer les informations importantes.

flowchart TD
    A[Augmentation du volume de contexte] --> B{Les informations sont-elles pertinentes ?}

    B -->|Oui| C[Réduction de l’incertitude]
    C --> D[Meilleur ancrage factuel]
    D --> E[Réponse plus précise]

    B -->|Partiellement| F[Contexte dilué]
    F --> G[Informations importantes plus difficiles à repérer]
    G --> H[Qualité instable]

    B -->|Non| I[Accumulation de bruit]
    I --> J[Contradictions et distractions]
    J --> K[Risque accru d’erreur ou d’hallucination]

    classDef positive fill:#e8fff2,stroke:#059669,stroke-width:2px;
    classDef warning fill:#fff7df,stroke:#d97706,stroke-width:2px;
    classDef negative fill:#ffeaea,stroke:#dc2626,stroke-width:2px;

    class C,D,E positive;
    class F,G,H warning;
    class I,J,K negative;

La bonne question n’est donc pas :

Combien de tokens puis-je placer dans la fenêtre ?

Elle devient plutôt :

Quelle proportion de cette fenêtre contribue réellement au raisonnement demandé ?

C’est exactement pour cela que le Context Engineering est apparu

Pendant longtemps, nous avons parlé de Prompt Engineering.

L’objectif consistait essentiellement à écrire de meilleurs prompts.

Aujourd’hui, les grands laboratoires parlent de plus en plus de Context Engineering.

Le changement est profond.

Le prompt n’est plus considéré comme l’élément principal.

Il devient simplement une petite partie d’un contexte beaucoup plus vaste comprenant :

• les documents sélectionnés ;
• les connaissances récupérées via un moteur de recherche (RAG) ;
• les conversations précédentes ;
• les mémoires de l’utilisateur ;
• les outils disponibles ;
• les contraintes métier ;
• les exemples de réponses attendues.

Autrement dit, le véritable travail consiste désormais à construire le meilleur contexte possible avant même de demander au modèle de raisonner.

Le prompt devient l’orchestre.

Le contexte devient la partition.

Le Prompt Engineering se concentre principalement sur la formulation de la demande. Le Context Engineering intervient plus tôt et couvre un périmètre beaucoup plus large : il faut rechercher, sélectionner, structurer et présenter les connaissances dont le modèle aura besoin.

flowchart TB

    subgraph PE[Prompt Engineering]
        direction TB

        A[Formuler la demande]
        B[Préciser le rôle]
        C[Définir le format attendu]

        A --> B
        B --> C
    end

    subgraph CE[Context Engineering]
        direction TB

        D[Identifier les connaissances nécessaires]
        E[Rechercher les bonnes sources]
        F[Évaluer leur fiabilité]
        G[Éliminer le bruit et les doublons]
        H[Structurer les informations]
        I[Construire le prompt final]

        D --> E
        E --> F
        F --> G
        G --> H
        H --> I
    end

    C --> I
    I --> J[Inférence du modèle]
    J --> K[Réponse contextualisée]

    classDef prompt fill:#fff7df,stroke:#d97706,stroke-width:2px;
    classDef context fill:#e8f1ff,stroke:#2563eb,stroke-width:2px;
    classDef output fill:#e8fff2,stroke:#059669,stroke-width:2px;

    class A,B,C prompt;
    class D,E,F,G,H,I context;
    class K output;

Le prompt reste important, mais il devient la dernière étape d’un processus plus vaste. Un prompt bien écrit ne peut pas compenser indéfiniment l’absence de connaissances fiables.

La prochaine étape : orchestrer plusieurs raisonnements

Je pense que nous assistons aujourd’hui à une nouvelle évolution.

Les architectures agentiques montrent qu’il n’est plus nécessaire de résoudre un problème complexe dans une seule fenêtre de contexte.

Il devient souvent plus efficace de découper le problème.

Une première étape recherche les informations.

Une seconde les trie.

Une troisième les résume.

Une quatrième vérifie leur cohérence.

Une cinquième produit la réponse.

Chaque étape dispose de son propre contexte.

Chaque étape travaille sur une quantité d’information limitée mais extrêmement pertinente.

Cette approche ressemble davantage à la manière dont nous raisonnons nous-mêmes.

Nous ne lisons pas une bibliothèque entière avant de prendre une décision.

Nous recherchons.

Nous sélectionnons.

Nous résumons.

Nous vérifions.

Puis nous décidons.

L’IA agentique reproduit progressivement ce fonctionnement.

Ce n’est plus une seule immense fenêtre de contexte.

C’est une succession de fenêtres spécialisées, orchestrées les unes avec les autres.

Pour réaliser une tâche complexe, il n’est pas toujours nécessaire de charger toutes les connaissances disponibles dans une seule fenêtre. Une architecture orchestrée peut distribuer le travail entre plusieurs étapes, chacune recevant uniquement le contexte dont elle a besoin.

flowchart TB

    U[Demande complexe] --> O[Orchestrateur]

    O --> R[1. Recherche]
    R --> RC[Contexte de recherche]
    RC --> RS[Sources candidates]

    RS --> S[2. Sélection]
    S --> SC[Contexte de sélection]
    SC --> SV[Sources pertinentes]

    SV --> Y[3. Synthèse]
    Y --> YC[Contexte de synthèse]
    YC --> YR[Résumé structuré]

    YR --> V[4. Vérification]
    V --> VC[Contexte de vérification]
    VC --> VR[Résultat vérifié]

    VR --> G[5. Génération]
    G --> GC[Contexte final]
    GC --> A[Réponse complète]

    A --> Q{Qualité suffisante ?}
    Q -->|Oui| Z[Livrable final]
    Q -->|Non| O

    classDef orchestration fill:#f3e8ff,stroke:#7c3aed,stroke-width:2px;
    classDef context fill:#e8f1ff,stroke:#2563eb,stroke-width:2px;
    classDef result fill:#e8fff2,stroke:#059669,stroke-width:2px;
    classDef decision fill:#fff7df,stroke:#d97706,stroke-width:2px;

    class O orchestration;
    class RC,SC,YC,VC,GC context;
    class A,Z result;
    class Q decision;

Cette représentation correspond à ce que l’on peut appeler une logique de Loop Engineering : le système ne tente pas nécessairement de résoudre toute la tâche en une seule inférence. Il exécute plusieurs boucles spécialisées, vérifie les résultats intermédiaires et réinjecte les informations utiles dans les étapes suivantes.

La taille de la fenêtre reste importante, mais elle cesse d’être la seule solution au problème. Une tâche qui exigerait théoriquement une gigantesque fenêtre monolithique peut être traitée au moyen de plusieurs fenêtres plus petites et mieux spécialisées.

Ce que cela change pour nos prompts

Je constate très souvent le même comportement chez les utilisateurs.

Ils ouvrent ChatGPT, Claude ou Copilot.

Puis ils écrivent trois lignes.

« Fais-moi une présentation sur… »

Ou :

« Explique-moi… »

Puis ils espèrent que le modèle ira lui-même chercher toutes les informations pertinentes.

C’est exactement l’inverse de ce qu’il faudrait faire.

Le rôle du moteur de recherche est de rechercher.

Le rôle du modèle est de raisonner.

Lorsque nous mélangeons ces deux fonctions dans un prompt extrêmement pauvre, nous obligeons le modèle à compléter les informations manquantes avec ses connaissances générales.

C’est précisément dans ces zones d’incertitude que naissent la plupart des hallucinations.

Plus de contexte… mais du bon contexte

Faut-il alors remplir complètement la fenêtre de contexte ?

Ma réponse est oui…

…à condition que chaque token apporte réellement de la valeur.

Chaque document devrait avoir une raison d’être présent.

Chaque paragraphe devrait contribuer au raisonnement.

Chaque information inutile augmente le bruit.

Chaque information pertinente réduit l’incertitude.

La différence est immense.

Et si l’IA écrivait nos prompts ?

C’est probablement l’idée qui me paraît la plus sous-estimée aujourd’hui.

Nous continuons à écrire nos prompts comme nous écrivions nos recherches Google il y a vingt ans.

Quelques mots-clés.

Deux ou trois phrases.

Puis nous demandons au modèle de faire des miracles.

Pourtant, l’intelligence artificielle est probablement le meilleur outil dont nous disposions pour produire… de meilleurs contextes.

Elle peut :

• reformuler une demande ;
• identifier les informations manquantes ;
• rechercher les documents nécessaires ;
• structurer les connaissances ;
• éliminer les redondances ;
• construire automatiquement un contexte cohérent avant même de lancer le raisonnement.

Autrement dit, l’IA devient progressivement l’ingénieur de son propre contexte.

Et c’est probablement là que se situe la prochaine grande rupture.

Et Microsoft 365 Copilot dans tout ça ?

La différence fondamentale entre les deux expériences ne réside pas uniquement dans le modèle utilisé. Elle tient surtout aux sources de contexte auxquelles le système peut accéder au moment de produire sa réponse.

flowchart TB
    U[Utilisateur]

    subgraph FREE["Microsoft Copilot gratuit"]
        FP[Prompt et conversation]
        FW[Informations publiques du Web]
        FM[Modèle génératif]

        FP --> FM
        FW --> FM
    end

    subgraph M365["Microsoft 365 Copilot"]
        MP[Prompt et conversation]
        MG[Microsoft Graph]
        MM[Modèles génératifs et orchestration]

        subgraph GRAPHCTX["Contexte organisationnel"]
            E[Courriels]
            T[Réunions et conversations Teams]
            D[Documents]
            S[SharePoint et OneDrive]
            B[Données métier autorisées]
        end

        E --> MG
        T --> MG
        D --> MG
        S --> MG
        B --> MG

        MP --> MM
        MG --> MM
    end

    U --> FP
    U --> MP

    FM --> FR[Réponse fondée principalement sur le prompt et le Web]
    MM --> MR[Réponse fondée sur le contexte de travail autorisé]

    classDef freeStyle fill:#f5f5f5,stroke:#64748b,stroke-width:2px
    classDef orgContext fill:#e8f1ff,stroke:#2563eb,stroke-width:2px
    classDef m365Style fill:#f3e8ff,stroke:#7c3aed,stroke-width:2px
    classDef outputStyle fill:#e8fff2,stroke:#059669,stroke-width:2px

    class FP,FW,FM freeStyle
    class E,T,D,S,B,MG orgContext
    class MP,MM m365Style
    class FR,MR outputStyle

Microsoft 365 Copilot ne connaît cependant pas magiquement toute l’entreprise. Il travaille dans le respect des droits d’accès de l’utilisateur et à partir des contenus réellement retrouvés par les mécanismes de recherche, d’indexation et de mise en contexte.

Microsoft apporte une dimension supplémentaire à cette réflexion : le contexte n’est plus seulement constitué de ce que vous écrivez dans votre prompt.

Il devient également constitué de vos propres connaissances d’entreprise.

C’est toute la différence entre Copilot et Microsoft 365 Copilot.

Le Copilot grand public travaille essentiellement avec les informations que vous lui fournissez pendant la conversation et, selon les fonctionnalités utilisées, avec les connaissances publiques du Web.

Microsoft 365 Copilot, lui, peut exploiter le Microsoft Graph : vos courriels, vos réunions, vos conversations Teams, vos documents Word, Excel, PowerPoint, vos sites SharePoint, vos espaces OneDrive, vos documents Loop et bien d’autres sources auxquelles vous avez déjà accès.

Sur le papier, cela semble être une révolution.

Dans la pratique, beaucoup d’organisations sont déçues.

Pourquoi ?

Parce qu’elles pensent que donner accès à toute leur bibliothèque documentaire suffira à rendre Copilot plus intelligent.

C’est une illusion.

Une bibliothèque mal organisée ne devient pas intelligente parce qu’on lui ajoute une intelligence artificielle.

Donner accès à une vaste bibliothèque documentaire n’est pas suffisant. La qualité des réponses dépend aussi de la qualité du patrimoine informationnel que le système est autorisé à consulter.

flowchart TD
    A[Bibliothèque Microsoft 365] --> B{État des connaissances}

    B -->|Documents structurés et à jour| C[Métadonnées cohérentes]
    C --> D[Versions de référence identifiables]
    D --> E[Recherche plus précise]
    E --> F[Contexte plus fiable]
    F --> G[Réponse plus utile]

    B -->|Documents mal organisés| H[Doublons et versions obsolètes]
    H --> I[Noms de fichiers imprécis]
    I --> J[Contradictions et absence de propriétaires]
    J --> K[Recherche incertaine]
    K --> L[Contexte incomplet ou bruité]
    L --> M[Réponse peu probante]

    classDef good fill:#e8fff2,stroke:#059669,stroke-width:2px;
    classDef bad fill:#ffeaea,stroke:#dc2626,stroke-width:2px;
    classDef neutral fill:#e8f1ff,stroke:#2563eb,stroke-width:2px;

    class A,B neutral;
    class C,D,E,F,G good;
    class H,I,J,K,L,M bad;

Copilot ne répare donc pas automatiquement la gouvernance documentaire. Il agit plutôt comme un révélateur de sa qualité.

Une organisation qui possède des connaissances bien structurées obtient plus facilement un contexte exploitable. Une organisation qui accumule les fichiers sans logique expose simplement son désordre à un système capable de le parcourir plus rapidement.

Si vos documents sont dupliqués, mal nommés, obsolètes, contradictoires, sans propriétaire identifié ou rangés dans des espaces incohérents, Microsoft 365 Copilot ne fera qu’hériter de cette désorganisation.

L’intelligence artificielle ne transforme pas le désordre en connaissance.

Elle exploite la connaissance qui existe déjà.

C’est précisément la raison pour laquelle je considère que la réussite d’un projet Microsoft 365 Copilot repose beaucoup moins sur le choix du modèle de langage que sur la qualité de la gouvernance documentaire.

Le véritable projet n’est pas un projet d’IA.

C’est un projet de gestion des connaissances.

J’y consacrerai d’ailleurs un prochain article, car je suis convaincu que l’arrivée de Microsoft 365 Copilot oblige les entreprises à repenser complètement l’organisation de leurs connaissances.

Le Context Engineering ne concerne plus uniquement le prompt.

Il concerne désormais toute l’architecture documentaire de l’entreprise.

La qualité finale provient moins d’une caractéristique isolée du modèle que d’une chaîne complète de décisions : partir d’une intention précise, rechercher les bonnes informations, construire le contexte, générer, vérifier, puis recommencer lorsque le résultat est insuffisant.

flowchart TB

    A[Intention de l’utilisateur]
    B[Formulation de la question]
    C[Recherche documentaire]
    D[Sélection des sources]
    E[Structuration des connaissances]
    F[Construction du contexte]
    G[Inférence]
    H[Vérification]
    I{Réponse satisfaisante ?}
    J[Identifier les informations manquantes]
    K[Réponse finale]

    A --> B
    B --> C
    C --> D
    D --> E
    E --> F
    F --> G
    G --> H
    H --> I

    I -->|Oui| K
    I -->|Non| J
    J --> C

    classDef preparation fill:#e8f1ff,stroke:#2563eb,stroke-width:2px;
    classDef inference fill:#f3e8ff,stroke:#7c3aed,stroke-width:2px;
    classDef control fill:#fff7df,stroke:#d97706,stroke-width:2px;
    classDef output fill:#e8fff2,stroke:#059669,stroke-width:2px;

    class A,B,C,D,E,F preparation;
    class G inference;
    class H,I,J control;
    class K output;

Ce cycle met en évidence une idée centrale : le modèle ne devrait pas toujours être chargé de rechercher, sélectionner, comprendre et rédiger simultanément à partir d’une demande de quelques mots.

Le moteur de recherche doit contribuer à retrouver les sources.

Le système de gestion des connaissances doit permettre de les organiser.

Le Context Engineering doit sélectionner et structurer ce qui sera transmis.

Le modèle peut alors consacrer sa capacité de raisonnement à la tâche pour laquelle il est réellement attendu.

Une stratégie qui dépasse désormais les modèles d’OpenAI

Cette évolution est d’autant plus intéressante que Microsoft semble progressivement changer de stratégie.

Pendant plusieurs années, Microsoft s’est appuyé presque exclusivement sur les modèles d’OpenAI pour alimenter Copilot.

Ce n’est plus la direction prise aujourd’hui.

L’entreprise investit massivement dans ses propres modèles MAI (Microsoft AI) et a annoncé une nouvelle famille de modèles internes couvrant le texte, le raisonnement, la génération d’images, la voix, la transcription et le développement logiciel. https://microsoft.ai/models/

Parallèlement, Microsoft adopte une approche multi-modèle. Microsoft 365 Copilot peut désormais orchestrer plusieurs modèles spécialisés au sein d’un même processus. Des fonctionnalités comme Critique dans l’agent Copilot Researcher permettent, par exemple, à un modèle de produire une réponse tandis qu’un second la relit et en vérifie la qualité avant de la présenter à l’utilisateur. Microsoft a également présenté Council, qui permet de comparer ou de faire collaborer plusieurs modèles selon la tâche à accomplir. https://techcommunity.microsoft.com/blog/microsoft365copilotblog/introducing-multi-model-intelligence-in-researcher/4506011

Cette stratégie est particulièrement révélatrice.

Microsoft ne cherche plus simplement à disposer du « meilleur modèle ».

L’objectif devient de sélectionner le modèle le plus adapté à chaque étape d’un raisonnement complexe, voire de faire collaborer plusieurs modèles pour réduire les erreurs, améliorer la qualité et limiter les hallucinations.

Nous retrouvons ici exactement la philosophie évoquée plus tôt dans cet article : l’avenir ne réside probablement pas dans une unique fenêtre de contexte gigantesque, mais dans une orchestration intelligente de plusieurs raisonnements spécialisés, chacun disposant du contexte dont il a réellement besoin.

Finalement, le contexte devient une ressource distribuée, organisée et pilotée, bien davantage qu’un simple volume de tokens disponible pour un modèle.

Conclusion

Pendant plusieurs années, nous avons cherché à écrire de meilleurs prompts.

Aujourd’hui, nous devons apprendre à construire de meilleurs contextes.

Demain, nous apprendrons à orchestrer plusieurs contextes spécialisés qui collaboreront entre eux pour résoudre des problèmes complexes.

La taille de la fenêtre de contexte restera importante.

Elle continuera d’augmenter.

Mais elle ne sera plus le véritable facteur de différenciation.

Ce qui fera la différence, ce sera notre capacité à fournir au modèle exactement les informations dont il a besoin, au bon moment, dans le bon ordre et avec le minimum de bruit.

La prochaine bataille de l’intelligence artificielle ne sera probablement pas celle des modèles. Elle sera celle de la connaissance. Les organisations qui sauront structurer, gouverner et orchestrer leur patrimoine informationnel disposeront d’un avantage concurrentiel bien plus durable que celles qui chercheront simplement à adopter le dernier modèle à la mode.