BLOG | BUREAU DU CTO

Gérer les fenêtres contextuelles en IA ne relève pas de la magie. C’est une question d’architecture.

Miniature de Lori MacVittie
Lori MacVittie
Publié le 27 août 2025

Clarifions cela, car comprendre où le contexte (session) s’intègre dans les architectures d’IA est crucial. Vous le savez, parce que j’ai utilisé le mot « dang » dans un article. Oui, je le pense vraiment.

Si vous créez votre propre application alimentée par LLM en utilisant l'API OpenAI, vous n’utilisez pas ChatGPT. Vous échangez avec un modèle. Un modèle brut. Si vous pensez que votre application va fonctionner comme ChatGPT simplement parce qu’elle utilise GPT-4, vous vous trompez déjà.

ChatGPT n’est pas un modèle, mais un environnement d’exécution.

Beaucoup se trompent constamment, car la marque OpenAI n’a pas facilité les choses. L’expérience « ChatGPT » — sa mémoire, son ton, son contexte, la manière dont il suit avec fluidité ce que vous avez dit six questions plus tôt sans inventer soudain un doctorat en botanique marine — n’est pas un tour de magie. C’est une architecture. Et cette architecture ne s’obtient pas gratuitement lorsque vous utilisez l’API.

L’application ChatGPT offre une expérience structurée et maîtrisée. Elle combine :

  • Ingénierie des prompts
  • Gestion des contextes
  • Mémoire persistante
  • Protections et solutions de secours
  • Synthèse, troncature et logique de contrôle

L'API ne vous offre rien de tout cela par défaut. Absolument rien.

Lorsque vous interrogez GPT-4 (ou tout autre modèle) directement, vous lui transmettez une séquence brute de messages sans état, en espérant que votre fenêtre contextuelle ne déborde pas ni ne se fragmente. C’est un modèle vierge, pas un assistant numérique.

La fenêtre contextuelle dépend de vous.

Dans ChatGPT, le serveur d’inférence gère l’intégralité de la fenêtre de contexte. Vous saisissez, il mémorise (jusqu’à ce qu’il cesse de le faire), et vous pouvez compter sur l’application pour conserver essentiellement ce qui importe. Un système de mémoire se superpose, et OpenAI sélectionne discrètement les éléments qui sont réinjectés.

Si vous utilisez l’API, vous devenez le serveur d’inférence. Autrement dit :

  • Vous créez la pile de messages.
  • Vous choisissez ce que vous incluez.
  • Vous gérez votre budget de jetons.
  • Vous coupez, résumez ou perdez la clarté.

Et si vous faites une erreur (ce que nous faisons tous au début), ce sera votre responsabilité lorsque le modèle oubliera le nom de l’utilisateur en plein milieu de la session ou commencera à créer des données que vous ne lui avez jamais fournies.

La mémoire ne constitue pas une fonctionnalité. Elle fait partie de l'infrastructure.

ChatGPT possède une mémoire. Vous, non. Sauf si vous la créez. Quand vous utilisez l’API, elle est sans état. Vous contrôlez tout le contexte, la mémoire et le déroulement. Avec l’application ChatGPT, OpenAI s’en charge pour vous. C’est intégré.

La « mémoire » de ChatGPT ne se limite pas à une simple note attachée à une requête. Elle repose sur un système qui conserve les faits, préférences, objectifs et contraintes des utilisateurs à travers les sessions, et les intègre au bon moment de manière contextuelle dans la requête. Pour intégrer une telle fonctionnalité dans votre application, vous devez disposer de :

  • Un entrepôt de données
  • Schéma des entrées mémoire
  • Logique qui détermine quand inclure chaque élément
  • Une méthode pour ne pas augmenter inutilement votre nombre de jetons

En d’autres termes : l’infrastructure.

C’est pourquoi la plupart des applications d’IA maison paraissent fragiles. Vous les traitez comme un chatbot, alors que ce devrait être un outil intégré dans un système. Le résultat ? Des fils de conversation interrompus, des requêtes répétitives, des régressions déroutantes et de la frustration chez l’utilisateur.

Et après ?

En vous appuyant sur l’API, vous créez une infrastructure, que vous le vouliez ou non. Si vos utilisateurs attendent une expérience comparable à ChatGPT, vous devrez leur fournir :

  • Mémoire persistante
  • Compression contextuelle intelligente
  • Gestion d'état tour par tour
  • Garde-fous, solutions de secours et logique d'injection

Mais ce n’est que le début. Parce que si vous bâtissez cela sur une architecture de prestation de services de niveau entreprise, ce que vous faites, n’est-ce pas ? N’EST-CE PAS ? — alors le reste de la plateforme doit également être à la hauteur.

C’est à ce moment que vos équipes en charge de la livraison et de la sécurité des applications entrent en action.

Livraison d’application : Vous ne diffusez plus seulement du HTML ou du JSON

Les applications natives d'IA gèrent l'état, sont pilotées par le dialogue et fonctionnent souvent en temps réel. Cela signifie :

  • L’affinité de session redevient essentielle. Vous ne pouvez pas répartir l’état des conversations sur des backends sans état, à moins de gérer les jetons de session comme en 2009.
  • La latence tue l’expérience utilisateur. Vous diffusez des interactions en plusieurs échanges, pas des pages statiques. Vos load balancers et la logique de edge doivent prioriser les flux conversationnels à faible latence.
  • Le coût du jeton correspond à la bande passante, au calcul et à l’argent. L’efficacité de la livraison compte désormais. La taille de la charge utile n’est pas qu’une question de réseau, c’est un élément de facturation.

Ce n’est pas un site publicitaire. C’est une interface dynamique. Vous ne pouvez pas simplement placer un CDN devant et arrêter là.

Sécurité : Ne pas contrôler la requête, c’est assumer le risque

Les LLM se programment via un prompt. Cela signifie que le prompt devient désormais la surface d’attaque.

  • Les attaques par injection sont bien réelles et déjà en cours. Si vous ne contrôlez pas rigoureusement la saisie, vous laissez les utilisateurs reprogrammer votre IA en temps réel.
  • La manipulation des invites peut exposer des mémoires sensibles, perturber vos flux de travail ou détourner vos intentions.
  • La sortie du modèle peut être exfiltrée, manipulée ou corrompue si vous ne l'intégrez pas à l’application des politiques et à la supervision.

Les contrôles de sécurité doivent progresser :

  • Vous avez besoin de WAF capables d’analyser le trafic IA. Bloquer du JSON malveillant ne suffit pas. Vous devez protéger les ensembles d’instructions, pas seulement la structure de la charge utile.
  • Vous devez disposer de pistes d’audit pour les décisions LLM, surtout dans les environnements réglementés.
  • Vous avez besoin d'une limitation du taux et d'une protection contre les abus, pas seulement pour les appels API, mais aussi pour gérer les pics de complexité et de coûts.

Et cela ne fait même pas référence au cauchemar de la gouvernance des données qu’implique l’insertion des enregistrements utilisateur dans les fenêtres de contexte.

Mettez en place la bonne architecture dès maintenant, avant que l'IA autonomique ne dérape.

En clair, ChatGPT est un produit abouti. L’API OpenAI reste un outil brut. Si vous les mélangez, votre stack va exploser.

Construisez intelligemment. Créez une pile de livraison et de sécurité d'applications de niveau entreprise pour prendre en charge votre portefeuille d'IA en plein essor . Croyez-moi, cela sera encore plus important lorsque vous commencerez à créer des agents d’IA et que vous adopterez avec enthousiasme l’architecture agentique . Car si vous pensez que la dérive du contexte et les hallucinations sont des problèmes pour les applications d’IA axées sur l’utilisateur final, attendez de voir ce que l’IA agentique peut faire à vos applications d’IA commerciales et opérationnelles.