Caveman : Pourquoi il est avantageux que l'IA parle comme un homme des cavernes
Yabba-dabba-doo ! Vous vous souvenez de Fred Caillou ? Il habitait à Saint-Granit, conduisait une voiture propulsée par ses pieds nus, avait un dinosaure en guise de grue et un ptérodactyle comme tourne-disque. Pourtant, à y regarder de plus près, cette civilisation de l'âge de pierre possédait déjà tout le nécessaire pour une vie moderne confortable : des gadgets fonctionnels, une technologie efficace, des solutions pratiques. Il ne lui manquait que le vernis brillant du progrès. Peut-être aurions-nous dû comprendre dès lors que l'essentiel suffit, et qu'ajouter de la complexité ne signifie pas nécessairement ajouter de la valeur.
Julius Brussee, développeur néerlandais, semble avoir relu la leçon avec un regard neuf. Son projet Caveman, disponible sur GitHub sous licence MIT, ne fait qu'une chose : il oblige le modèle à répondre comme un homme des cavernes. Pas d'articles, pas de formules de politesse, pas de phrases d'introduction. Juste le cœur technique, exprimé de la manière la plus directe possible.
Le problème que Caveman cherche à résoudre est réel, et quiconque travaille avec des modèles linguistiques payants le connaît bien. Chaque réponse d'un LLM a un coût mesuré en tokens, les unités élémentaires dans lesquelles le modèle décompose et recompose le langage, quelque chose d'intermédiaire entre la syllabe et le mot. Via API, les tokens de sortie sont généralement plus coûteux que ceux d'entrée, et les modèles modernes ont tendance à être généreux en paroles : ils introduisent chaque réponse par des formules de politesse, précisent l'évidence, répètent le contexte déjà connu, concluent par un récapitulatif de ce qu'ils viennent de dire. C'est une prolixité systémique, entraînée pendant des années sur des retours humains qui récompensaient souvent la complétude apparente au détriment de la concision réelle.
Prenons un exemple concret, celui rapporté dans la documentation officielle du projet. La réponse standard de Claude à un problème de re-rendering dans React ressemble à ceci : "The reason your React component is re-rendering is likely because you're creating a new object reference on each render cycle. When you pass an inline object as a prop, React's shallow comparison sees it as a different object every time, which triggers a re-render. I'd recommend using useMemo to memoize the object." Soixante-neuf tokens. En mode Caveman, la même information devient : "New object ref each render. Inline object prop = new ref = re-render. Wrap in `useMemo`." Dix-neuf tokens. Même diagnostic, même solution, trois fois et demie moins de mots.
Comment ça marche
Techniquement, Caveman est un fichier .md à installer dans l'environnement de l'agent choisi avec une seule commande.
Une fois installé, l'outil s'active sur demande, via la commande /caveman ou $caveman sur Codex, et la phrase "talk like caveman", "caveman mode" ou simplement "less tokens please", et se désactive avec "stop caveman" ou "normal mode". Il s'agit d'un ensemble d'instructions contextuelles qui modifient le comportement du modèle au cours d'une session, sans le réentraîner ni modifier ses paramètres internes.
À cela s'ajoute un deuxième outil, /caveman:compress, qui agit sur le versant opposé : au lieu de comprimer les réponses du modèle, il comprime les fichiers de contexte (par exemple, Claude le charge à chaque session, typiquement CLAUDE.md et les fichiers de notes de projet). La commande réécrit ces fichiers en style homme des cavernes et en conserve automatiquement une copie lisible comme sauvegarde (CLAUDE.original.md). Tout ce qui est technique (blocs de code, URL, chemins de fichiers, commandes, en-têtes, dates, numéros de version) reste inchangé ; seule la prose descriptive est compressée. Les benchmarks du projet sur cinq types de fichiers réels montrent une réduction moyenne de 46 % des tokens d'entrée par session, avec un pic de 59,6 % sur les fichiers de préférences.
Le cœur du mécanisme est un ensemble de contraintes grammaticales et stylistiques qu'un commentaire d'utilisateur sur Hackaday a résumé de manière précise : on élimine les articles définis et indéfinis, on supprime les mots de remplissage (just, really, basically, actually), on efface les formules de politesse (sure, certainly, of course, happy to), on privilégie les synonymes courts (big au lieu d'extensive, fix au lieu d'implement a solution for), on interdit l'usage des formes d'hésitation (it might be worth considering). Les fragments de phrases sont acceptables. Le sujet n'est pas nécessaire s'il est implicite. La terminologie technique, en revanche, reste intacte : polymorphism reste polymorphism, les blocs de code sont écrits normalement, les messages d'erreur sont cités verbatim. Comme le dit le README du projet avec auto-dérision : "Caveman not dumb. Caveman efficient."
Cette distinction est fondamentale pour comprendre ce que Caveman fait réellement. Ce n'est pas un compresseur qui tronque les réponses au milieu, ni un outil qui simplifie les concepts pour les rendre plus digestes. C'est un filtre qui élimine le surplus communicatif, ces phrases que les modèles produisent non pas parce qu'elles contiennent des informations utiles, mais parce que leur entraînement, basé sur des évaluations humaines qui ont tendance à récompenser les réponses élaborées et polies, les a poussés dans cette direction. Caveman se comporte comme un éditeur sévère qui efface tout ce qui n'apporte pas de valeur technique, ne laissant sur la page que ce qui est nécessaire.
Le projet a ajouté entre-temps une granularité qui le rend plus adaptable que ce que la prémisse de l'homme des cavernes laissait supposer. Trois niveaux d'intensité sont disponibles, sélectionnables avec des déclencheurs dédiés : /caveman lite garde la grammaire intacte et n'élimine que le remplissage, renvoyant une sortie professionnelle mais sobre, adaptée aux contextes où la forme compte encore ; /caveman full est le mode par défaut, celui qui supprime les articles, accepte les fragments de phrases et vise le cœur technique sans médiation ; /caveman ultra pousse la compression au maximum, avec un style télégraphique qui abrège tout ce qui est compressible.
Le niveau sélectionné persiste pendant toute la session jusqu'à un changement explicite. Mais la surprise la plus inattendue est ailleurs : le README du projet documente également un mode en chinois classique littéraire, le wenyan (文言文), la langue écrite utilisée en Chine pendant plus de deux mille ans jusqu'au XXe siècle, notoire pour une densité sémantique sans équivalent dans les langues modernes. L'idée n'est pas folklorique : le wenyan est objectivement l'un des systèmes d'écriture les plus économes en tokens jamais inventés par l'humanité, et Brussee l'a intégré avec la même logique progressive que les niveaux latins, de /caveman wenyan-lite, qui garde la grammaire mais élimine le superflu, jusqu'à /caveman wenyan-ultra, que le README décrit avec une certaine ironie comme le mode de l'ancien érudit à court de budget. Certes, avec le wenyan, l'économie est extrême, mais il faut ensuite comprendre ce qu'il écrit...
Les données de benchmark rapportées sur la page du projet indiquent des réductions variables selon le type de tâche : de 87 % sur les problèmes de re-rendering React à 83 % sur le débogage de middleware d'authentification, 81 % sur les conditions de concurrence (race conditions) dans PostgreSQL, jusqu'à 58 % pour les explications de git rebase vs merge et 41 % pour les revues de sécurité sur les pull requests. La moyenne déclarée s'établit autour de 65 % de réduction des tokens de sortie. Il est important de noter que ces chiffres concernent exclusivement les tokens de sortie, et non l'intégralité de la session : les tokens d'entrée (ceux du contexte, des instructions système et des appels aux outils) restent inchangés et peuvent représenter une part significative du coût global, surtout lors de sessions longues ou avec de nombreux appels à des outils externes.
La science du silence
Jusqu'ici, on pourrait balayer Caveman comme un petit truc sympa, l'un de ces micro-projets qui tournent sur GitHub pendant quelques jours puis disparaissent. Ce qui le rend intéressant d'un point de vue plus large, c'est sa connexion avec une littérature scientifique émergente qui étudie le rapport entre la brièveté et les performances des modèles linguistiques, et les résultats de cette littérature sont, pour le dire avec mesure, contre-intuitifs.
Le papier de référence est "Brevity Constraints Reverse Performance Hierarchies in Language Models", publié le 11 mars 2026 par MD Azizul Hakim sur arXiv. L'étude part d'une observation anormale : sur un sous-ensemble égal à 7,7 % des problèmes évalués, répartis sur cinq jeux de données différents, les modèles linguistiques les plus grands obtiennent des résultats moins bons que les modèles plus petits de 28,4 points de pourcentage, alors qu'ils disposent d'un nombre de paramètres 10 à 100 fois supérieur.
Le mécanisme identifié comme cause est ce que le papier appelle la scale-dependent verbosity, une prolixité qui croît avec la taille du modèle. Les modèles les plus grands ont tendance à sur-élaborer les réponses, en ajoutant des étapes de raisonnement, des nuances et des digressions qui n'améliorent pas la réponse finale, et l'empirent souvent en introduisant des erreurs par excès d'élaboration. Imposer aux grands modèles de répondre de manière concise améliore leur précision de 26,3 points de pourcentage, réduisant l'écart avec les petits modèles de 67 %, tandis que les petits modèles, soumis à la même contrainte, subissent une baisse de seulement 3,1 points de pourcentage.
Le résultat le plus surprenant concerne des benchmarks spécifiques. Sur GSM8K, le jeu de données de raisonnement mathématique, et sur MMLU-STEM, celui des connaissances scientifiques, les contraintes de brièveté inversent complètement la hiérarchie des performances : les grands modèles, qui en temps normal se comportaient moins bien que les petits, arrivent à les dépasser de 7,7 à 15,9 points de pourcentage. En d'autres termes, la capacité supérieure était déjà là, mais elle était masquée par la tendance à raisonner à voix haute de manière excessive. La brièveté ne comprime pas le raisonnement, elle le libère de l'enveloppe verbeuse qui l'étouffe.
Il faut toutefois noter une mise en garde que l'étude elle-même introduit honnêtement : sur BoolQ, le jeu de données qui nécessite l'intégration d'informations réparties sur plusieurs phrases, les contraintes de brièveté augmentent légèrement l'écart au lieu de le réduire, passant de 23,5 % à 24,3 %. Sur ce type de problèmes, l'élaboration étendue est fonctionnelle, et non excessive : l'écourter dégrade le résultat. Il ne s'agit pas d'un résultat universel, mais dépendant du contexte, et cette nuance est cruciale pour ne pas mal interpréter ce que le papier démontre.
L'hypothèse proposée par les auteurs pour expliquer la tendance à la prolixité des grands modèles est que le processus d'alignement par retour humain (RLHF) a par inadvertance entraîné ces modèles à sur-élaborer, car les évaluateurs humains ont tendance à récompenser les réponses longues et apparemment complètes, créant un biais systématique qui croît avec la taille du modèle. C'est une explication plausible et cohérente avec d'autres phénomènes connus dans l'entraînement des modèles, même si elle reste une hypothèse interprétative à vérifier davantage.
Le mammouth dans la pièce
Données en main, Caveman fonctionne, du moins dans certains contextes. L'économie déclarée est réelle et mesurable, la base scientifique existe et n'est pas triviale, le mécanisme technique est transparent et vérifiable par n'importe qui. Mais une analyse honnête exige de mettre aussi sur la table les réserves, et il y en a plusieurs.
La première réserve concerne la qualité des réponses sur des tâches complexes. Une réponse plus courte est-elle toujours une meilleure réponse ? Le papier de Hakim dit explicitement non pour certains types de problèmes, et l'intuition est vérifiable dans la pratique quotidienne. Quand on travaille sur un bug obscur, sur un problème d'architecture avec de nombreuses variables, sur du code legacy mal documenté, une réponse qui explique le raisonnement étape par étape a une valeur qui dépasse la quantité d'information strictement nécessaire : elle aide à comprendre, à vérifier, à construire un modèle mental. Couper cette explication au nom de l'efficacité peut obliger à plus d'itérations, à plus de questions de clarification, à plus de temps perdu, annulant l'économie initiale.
Cela mène à la deuxième réserve, celle relative à l'expérience utilisateur différenciée. Pour un développeur senior qui utilise un agent comme accélérateur, qui connaît le code sur lequel il travaille et a besoin de confirmations rapides plutôt que d'explications, Caveman est probablement un gain net. Pour un junior qui utilise l'assistant aussi pour apprendre, pour quelqu'un qui affronte un nouveau domaine technique, ou pour ceux qui utilisent des agents dans des contextes qui sortent du pur codage (comme l'écriture technique, l'analyse de sécurité, l'aide aux décisions architecturales), la synthèse excessive peut augmenter la charge cognitive et générer plus de confusion que de clarté.
Enfin, il convient de rappeler que les preuves scientifiques disponibles soutiennent le principe de la brièveté comme contrainte utile, mais ne valident pas spécifiquement Caveman en tant qu'implémentation. Le papier de Hakim a été publié sur arXiv, encore en phase de pré-print au moment de l'écriture de cet article, et n'a pas encore reçu de révision formelle de la part de la communauté académique. L'outil de Brussee a attiré l'attention de la communauté tech avec 33,5k étoiles sur GitHub en quelques jours, et cela ne peut être sous-estimé, mais il n'a pas fait l'objet d'une évaluation indépendante et systématique par des tiers. Ce sont des signes d'intérêt sincère, pas une validation certifiée.
Clé de voûte ou météore ?
La question la plus intéressante que Caveman pose n'est pas technique, elle est méthodologique. Si les modèles linguistiques les plus puissants ont structurellement tendance à répondre de manière plus prolixe, et si cette prolixité est souvent nuisible tant pour les coûts que, étonnamment, pour la qualité des réponses sur certains types de problèmes, alors le problème n'est pas celui de Caveman : c'est celui de la manière dont ces modèles sont entraînés et évalués.
Le papier de Hakim propose une approche qu'il appelle problem-aware routing : utiliser des petits modèles pour les tâches où ils excellent naturellement ou là où les contraintes de brièveté n'aident pas les grands modèles, et utiliser des grands modèles avec des contraintes de brièveté pour les tâches où ils possèdent des capacités latentes supérieures mais sont enclins à la sur-élaboration. Cette approche, disent les auteurs, peut améliorer simultanément la précision et les coûts. Ce n'est pas de la science-fiction : c'est une forme de prompt engineering consciente de l'échelle du modèle, une idée qui pourrait devenir une pratique courante dans les flux de travail agentiques professionnels.
En ce sens, Caveman n'est pas simplement une astuce pour économiser quelques centimes sur l'API. C'est une démonstration pratique d'un principe que la recherche commence à formaliser : les instructions système ne sont pas décoratives, la manière dont un modèle est interrogé change non seulement la forme mais aussi la qualité de la réponse, et optimiser l'interface homme-machine a des conséquences mesurables sur les performances du système global.
Des questions légitimes restent ouvertes. Le pattern se transfère-t-il vraiment à tous les types de tâches ou seulement à celles, structurées, du codage ? Comment mesure-t-on le ROI net quand on inclut dans le calcul le coût des itérations supplémentaires qu'une réponse trop synthétique peut générer ? À quel point la familiarité de l'utilisateur avec le domaine technique joue-t-elle dans le fait de déterminer si la brièveté est un avantage ou un inconvénient ? Et, pour en revenir à la grande question de fond : si la brièveté améliore les performances, pourquoi les modèles ne sont-ils pas entraînés nativement à répondre de manière plus concise ?
Cette dernière question est peut-être la plus importante, et la réponse implicite dans le papier de Hakim est dérangeante : parce que le retour humain sur lequel se base l'alignement de ces modèles préfère souvent la longueur à la précision, la politesse à la densité informative. C'est nous, en tant qu'évaluateurs, en tant qu'utilisateurs, en tant que clients, qui avons entraîné les modèles à la prolixité. Caveman est, au fond, un correctif artisanal à un problème systémique qui naît bien plus en amont.
Fred Caillou avait probablement déjà tout compris. Petite grotte, outils essentiels, grand résultat. Le reste n'est que de la pierre en trop à traîner.