Le modèle avec lequel je travaille est 100 fois plus petit que le vôtre, et mon agent IA fonctionne toujours très bien

Il y a quelques mois, j'ai demandé à un agent IA que je construis d'analyser un grand dépôt. Cela a commencé de manière prometteuse — il lisait des fichiers, cartographiait les dépendances, pendant un moment cela ressemblait exactement à la démo qu'ils lancent juste avant un tour de table — puis il s'est étouffé. J'ai arrêté l'exécution et j'ai regardé les chiffres : l'analyse nécessitait 633 000 jetons, dans une fenêtre de contexte de 131 000. Je l'ai exécuté sur deux autres dépôts, juste au cas où : 287 000. 513 000. Deux à cinq fois la fenêtre, à chaque fois. Une cohérence impressionnante, juste pas du genre qu'on télécharge sur les réseaux sociaux.

Et voici un petit aveu : une fenêtre de 131 000 n'est pas un choix théorique. Le modèle qui écrit du code pour moi est Qwen2.5-Coder-32B — un modèle ouvert qui tourne localement pour moi, sur un seul A100 — des ordres de grandeur plus petit que les modèles auxquels vous parlez via API. Quand le modèle est petit, vous n'avez pas le privilège d'espérer qu'il va "juste s'en sortir". Chacune de ses faiblesses vous rencontre en face, rapidement, et sans équipe de support pour couper les coins ronds. Et la première faiblesse est l'arithmétique de l'école primaire. Un agent accumule du contexte à chaque action — chaque fichier lu, chaque résultat de recherche, chaque sortie de terminal s'accumulent dans la fenêtre — et la tâche ne s'engage sur aucune taille.

Mon premier instinct était celui d'un ingénieur : compresser. J'ai construit un mécanisme qui réduit chaque lecture de fichier — un squelette de déclarations plus un résumé au lieu du contenu complet — une économie de cinq à vingt fois par lecture. L'agent a planté à nouveau, un peu plus tard. Parce que la compression améliore la constante, et le problème croît linéairement. Et non, un million de jetons ne résolvent pas cela. J'entends déjà la première réponse : "C'est pour ça qu'il y a aujourd'hui des modèles avec une fenêtre d'un million". Vrai. Faisons quand même le calcul que la diapositive a sauté. Une fenêtre de contexte, aussi grande soit-elle, est une constante. Le contexte d'un agent croît à chaque étape, et les tâches que nous donnons aux agents croissent encore plus vite — un dépôt plus grand, une enquête plus longue, une tâche d'une journée au lieu d'une heure. Un million de jetons déplacent le mur huit fois plus loin. Impressionnant. Un monorépertoire d'entreprise moyen mange cet écart avant la réunion de l'après-midi.

Toute taille finie perd face à quelque chose qui croît. Une fenêtre plus grande est le même marché, avec une facture plus salée. Et c'est avant même les deux murs que vous rencontrez plus tôt :

Le mur de la qualité : la fenêtre effective d'un petit modèle est plus petite que la fenêtre de la présentation. Les grands chiffres sont mesurés dans des tests "aiguille dans une botte de foin" — le modèle extrait une phrase d'un roman, tout le monde applaudit. Demandez-lui de dire quelque chose d'intelligent sur le roman entier, et vous obtiendrez un étudiant qui n'a lu que le résumé.
Le mur de l'économie : un agent traîne son contexte à nouveau à chaque étape, et une tâche sérieuse, c'est des centaines d'étapes. Deux cents étapes multipliées par un contexte gras — quelqu'un paie cette facture à la fin.

Et il y a un indice du monde réel qui vaut plus que tous les benchmarks : aucun ingénieur ne garde un monorépertoire entier dans sa tête. La mémoire de travail humaine est terriblement minuscule — et les humains naviguent dans des bases de code de dizaines de millions de lignes, chaque jour, sans se plaindre de la taille de la fenêtre. Ils ont une méthode : une carte mentale, une décomposition en sous-problèmes, et le transfert de la moitié du travail à quelqu'un d'autre. Par conséquent, ce n'est pas la "faute" du modèle, et la mise à niveau du modèle ne vous sauvera pas. C'est l'architecture.

Changer l'algorithme, pas le seau

La solution au mur des 633K était de changer la façon d'exécuter. L'agent principal a cessé de lire les fichiers lui-même : il divise l'enquête entre des sous-agents, chacun tournant avec sa propre fenêtre de contexte fraîche, creusant autant que nécessaire — et renvoyant au père un résumé de quatre mille jetons. Division du travail. Dans un autre monde, ils appellent cela "gestion" et obtiennent des options pour cela.

Mais le calcul change fondamentalement : 200 lectures de fichiers par un agent — 300 000 jetons, plantage. Cinq sous-agents, chacun lisant quarante fichiers et renvoyant un résumé — vingt mille jetons chez le père. Le contexte de l'agent principal est bloqué par le nombre de sous-agents, pas par le nombre de fichiers dans le dépôt. Changement asymptotique, pas une amélioration constante — et complètement indifférent à la taille de la fenêtre. Avec 131 000 ou avec un million, cela fonctionne de la même manière. Le mur cesse simplement d'être pertinent, sans que personne n'ait rien mis à niveau.

Et c'est, soit dit en passant, le seul benchmark auquel je fais vraiment confiance : le même modèle, la même tâche, avec le levier et sans lui. Les trois dépôts de l'intro — ceux qui nécessitaient 287, 513 et 633 mille jetons et qui ont planté — passent aujourd'hui du début à la fin, avec exactement le même modèle. Et pour ceux qui veulent un chiffre d'une source qui n'est pas moi : Anthropic a publié que le passage à une architecture multi-agents a amélioré leurs performances sur les tâches de recherche de plus de 90 pour cent par rapport à un agent unique, sur les mêmes modèles.

Casting au lieu de prompt

Le modèle est aveugle ? Mettez-lui des lunettes. Le modèle qui écrit du code pour moi est complètement textuel. Un utilisateur qui a joint une capture d'écran d'un bug visuel — un bouton cassé, une mise en page qui s'est effondrée — ne recevait auparavant absolument rien. Ce que j'ai fait à la place : j'ai connecté un minuscule modèle de vision séparé — Qwen2.5-VL-3B, dix fois plus petit que le modèle de code — comme outil. Il reçoit l'image et renvoie une description structurée — mise en page, éléments, état, suspects immédiats — et le programmeur textuel débogue l'UI à partir du texte. Un modèle qui ne voit pas corrige des bugs visuels.

Deux limitations qu'aucun prompt ne corrige, et plus le modèle est petit, plus elles sont aiguës : il n'a aucun sens de l'achèvement, et il n'a aucune autocritique. La solution, c'est le casting. Les mêmes poids tournent pour moi dans plusieurs rôles que la plomberie dirige : un exécutant qui écrit le code ; un vérificateur qui s'assure qu'il tourne dans un contexte complètement propre ; et dans les tâches critiques aussi un sceptique, qui se lève le matin pour trouver des failles. Et la décision "nous avons fini" a complètement quitté les mains du modèle — pas d'approbation du vérificateur, pas d'achèvement. Un modèle, comme un doctorant, ne soumet jamais si vous ne lui prenez pas le travail de force.

Et parallèlement au casting, des retours de la réalité : après chaque édition de fichier, la plomberie pousse les erreurs de compilation au modèle sans qu'il le demande. Un agent qui reçoit le rouge en pleine face après chaque étape se corrige lui-même ; un agent qui travaille à l'aveugle soumet du code cassé avec une confiance totale.

La mémoire est un problème de récupération

Une longue conversation doit être compressée à un moment donné — la fenêtre, comme mentionné, est finie. La solution acceptée dans l'industrie : résumer l'histoire et jeter la source. Mais un résumé garde l'esprit et tue exactement ce dont vous aurez besoin plus tard — le chemin exact, le nom de la variable, le message d'erreur mot pour mot. J'ai donc inversé la direction : rien n'est supprimé. L'histoire va aux archives, le résumé entre dans le contexte, et le modèle obtient un outil de recherche pour tout ce qui a été coupé. Et un petit détail qui résume tout l'article pour moi : dans la première version, le modèle n'utilisait pas l'outil de recherche. Jamais. Ce qui l'a corrigé, c'est une phrase que j'ai ajoutée au résumé lui-même : "Les détails complets sont disponibles via l'outil de recherche". Une ligne de contexte au bon endroit, et la capacité qui était déjà là a pris vie.

Les poids sont une commodité, l'architecture est cumulative. Tous les six mois, un "modèle qui change les règles du jeu" sort, et chaque janvier est à nouveau déclaré "année des agents". En attendant, remarquez ce qui est commun à tout ce que j'ai décrit : aucun levier ne nécessite un modèle plus intelligent, et aucun d'entre eux n'est jeté à la poubelle lorsqu'un nouveau modèle sort. Un nouveau modèle soulève le sol ; l'architecture soulève le plafond. Et l'investissement dedans, contrairement à un modèle qui change tous les six mois, est cumulatif. Donc, quand un nouveau modèle sort, je télécharge et vérifie naturellement, comme tout le monde — mon addiction n'est pas différente de la vôtre, je paie juste pour cela en électricité. Mais je ne demande plus "à quel point il est intelligent". Je demande jusqu'où ma plomberie va l'emmener.

Yehuda Neuman est le CTO et architecte en chef de PAIS.