Ce weekend, Andrej Karpathy, ancien directeur de l’IA chez Tesla et membre fondateur d’OpenAI, a décidé de lire un livre. Mais il ne voulait pas le lire seul. Il voulait le lire accompagné d’un comité d’intelligences artificielles, chacune offrant sa propre perspective, critiquant les autres, et finalement synthétisant une réponse finale sous la direction d’un « Président ».
Pour réaliser cela, Karpathy a écrit ce qu’il appelait un « projet de code de vibe » – un logiciel écrit rapidement, en grande partie par des assistants IA, destiné à s’amuser plutôt qu’à fonctionner. Il a publié le résultat, un référentiel appelé « LLM Council », sur GitHub avec un avertissement sévère : « Je ne vais pas le soutenir de quelque manière que ce soit… Le code est éphémère maintenant et les bibliothèques sont obsolètes. »
Pourtant, pour les décideurs techniques à travers le paysage de l’entreprise, regarder au-delà de l’avertissement occasionnel révèle quelque chose de beaucoup plus significatif qu’un jouet de week-end. En quelques centaines de lignes de Python et de JavaScript, Karpathy a esquissé une architecture de référence pour la couche la plus critique et indéfinie de la pile logicielle moderne : le middleware d’orchestration assis entre les applications d’entreprise et le marché volatile des modèles d’IA.
Alors que les entreprises finalisent leurs investissements en plateforme pour 2026, LLM Council offre un aperçu épuré de la réalité « construire vs acheter » de l’infrastructure IA. Il démontre que si la logique de routage et d’agrégation des modèles d’IA est étonnamment simple, l’enveloppe opérationnelle nécessaire pour la rendre prête pour l’entreprise est là où réside la véritable complexité.
Comment fonctionne le LLM Council : Quatre modèles d’IA débattent, critiquent et synthétisent des réponses
Pour l’observateur occasionnel, l’application web LLM Council ressemble presque à ChatGPT. Un utilisateur tape une requête dans une boîte de chat. Mais en coulisses, l’application déclenche un flux de travail sophistiqué en trois étapes qui reflète le fonctionnement des organes de décision humaine.
Tout d’abord, le système envoie la requête de l’utilisateur à un panel de modèles de pointe. Dans la configuration par défaut de Karpathy, cela inclut le GPT-5.1 d’OpenAI, le Gemini 3.0 Pro de Google, le Claude Sonnet 4.5 d’Anthropic et le Grok 4 de xAI. Ces modèles génèrent leurs réponses initiales en parallèle.
Dans la deuxième étape, le logiciel effectue une évaluation par les pairs. Chaque modèle reçoit les réponses anonymisées de ses homologues et est invité à les évaluer en fonction de l’exactitude et de l’insight. Cette étape transforme l’IA d’un générateur en un critique, imposant une couche de contrôle de qualité rare dans les interactions standard avec les chatbots.
Enfin, un « Président LLM » désigné – actuellement configuré comme le Gemini 3 de Google – reçoit la requête initiale, les réponses individuelles et les classements par les pairs. Il synthétise cette masse de contexte en une seule réponse autoritaire pour l’utilisateur.
Karpathy a noté que les résultats étaient souvent surprenants. « Très souvent, les modèles sont étonnamment prêts à sélectionner la réponse d’un autre LLM comme supérieure à la leur », a-t-il écrit sur X (anciennement Twitter). Il a décrit l’utilisation de l’outil pour lire des chapitres de livre, observant que les modèles louaient systématiquement le GPT-5.1 comme le plus perspicace tout en donnant une note plus basse à Claude. Cependant, l’évaluation qualitative de Karpathy divergeait de son conseil numérique ; il a trouvé le GPT-5.1 « trop verbeux » et préférait la sortie « condensée et traitée » de Gemini.
FastAPI, OpenRouter et le cas de traitement des modèles de pointe comme composants interchangeables
Pour les DSI et les architectes de plateforme, la valeur de LLM Council ne réside pas dans sa critique littéraire, mais dans sa construction. Le référentiel sert de document principal montrant exactement à quoi ressemble une pile IA moderne et minimale à la fin de 2025.
L’application repose sur une architecture « mince ». Le backend utilise FastAPI, un framework Python moderne, tandis que le frontend est une application React standard construite avec Vite. Le stockage des données n’est pas géré par une base de données complexe, mais par des fichiers JSON simples écrits sur le disque local.
Le pivot de l’ensemble de l’opération est OpenRouter, un agrégateur d’API qui normalise les différences entre les différents fournisseurs de modèles. En routant les demandes par le biais de ce courtier unique, Karpathy a évité d’écrire un code d’intégration séparé pour OpenAI, Google et Anthropic. L’application ne sait pas et ne se soucie pas de quelle entreprise fournit l’intelligence ; elle envoie simplement une incitation et attend une réponse.
Ce choix de conception met en lumière une tendance croissante dans l’architecture d’entreprise : la marchandisation de la couche modèle. En traitant les modèles de pointe comme des composants interchangeables qui peuvent être remplacés en éditant une seule ligne dans un fichier de configuration – spécifiquement la liste COUNCIL_MODELS dans le code backend – l’architecture protège l’application contre l’enfermement par un fournisseur. Si un nouveau modèle de Meta ou de Mistral occupe les premières places la semaine prochaine, il peut être ajouté au conseil en quelques secondes.
Ce qui manque du prototype à la production : Authentification, redaction de PII, et conformité
Alors que la logique de base de LLM Council est élégante, elle sert également d’illustration frappante de l’écart entre un « piratage de week-end » et un système de production. Pour une équipe de plateforme d’entreprise, cloner le référentiel de Karpathy n’est que la première étape d’un marathon.
Un audit technique du code révèle l’infrastructure « ennuyeuse » manquante que les fournisseurs commerciaux vendent à prix premium. Le système manque d’authentification ; toute personne ayant accès à l’interface web peut interroger les modèles. Il n’y a pas de concept de rôles d’utilisateur, ce qui signifie qu’un développeur junior a les mêmes droits d’accès que le DSI.
De plus, la couche de gouvernance est inexistante. Dans un environnement d’entreprise, l’envoi de données à quatre fournisseurs d’IA externes différents déclenche immédiatement des préoccupations en matière de conformité. Il n’y a aucun mécanisme ici pour redacter les informations personnellement identifiables (PII) avant qu’elles ne quittent le réseau local, et il n’y a pas de journal d’audit pour suivre qui a demandé quoi.
La fiabilité est une autre question ouverte. Le système suppose que l’API OpenRouter est toujours opérationnelle et que les modèles répondront en temps opportun. Il manque les disjoncteurs, les stratégies de secours et la logique de réessai qui permettent aux applications critiques pour l’entreprise de fonctionner lorsque qu’un fournisseur subit une panne.
Ces absences ne sont pas des défauts dans le code de Karpathy – il a explicitement déclaré qu’il n’avait pas l’intention de soutenir ou d’améliorer le projet – mais ils définissent la proposition de valeur pour le marché commercial de l’infrastructure IA.
Des entreprises comme LangChain, AWS Bedrock et diverses startups de passerelle IA vendent essentiellement le « durcissement » autour de la logique de base que Karpathy a démontrée. Ils fournissent les enveloppes de sécurité, d’observabilité et de conformité qui transforment un script d’orchestration brut en une plateforme d’entreprise viable.
Pourquoi Karpathy croit que le code est maintenant « éphémère » et que les bibliothèques logicielles traditionnelles sont obsolètes
Peut-être l’aspect le plus provocateur du projet est la philosophie sous laquelle il a été construit. Karpathy a décrit le processus de développement comme « codé à 99% de vibe », impliquant qu’il s’est beaucoup appuyé sur des assistants IA pour générer le code plutôt que de l’écrire ligne par ligne lui-même.
« Le code est éphémère maintenant et les bibliothèques sont obsolètes, demandez à votre LLM de le modifier de la manière qui vous convient », a-t-il écrit dans la documentation du référentiel.
Cette déclaration marque un changement radical dans la capacité d’ingénierie logicielle. Traditionnellement, les entreprises construisent des bibliothèques internes et des abstractions pour gérer la complexité, les maintenant pendant des années. Karpathy suggère un avenir où le code est traité comme un « échafaudage promptable » – jetable, facilement réécrit par l’IA, et pas destiné à durer.
Pour les décideurs d’entreprise, cela pose une question stratégique difficile. Si les outils internes peuvent être « codés en vibe » en un week-end, est-il logique d’acheter des suites logicielles coûteuses et rigides pour des workflows internes ? Ou les équipes de plateforme doivent-elles permettre à leurs ingénieurs de générer des outils personnalisés et jetables qui répondent exactement à leurs besoins pour une fraction du coût ?
Lorsque les modèles IA jugent l’IA : Le dangereux écart entre les préférences des machines et les besoins humains
Au-delà de l’architecture, le projet LLM Council met involontairement en lumière un risque spécifique dans le déploiement automatisé de l’IA : la divergence entre le jugement humain et machine.
L’observation de Karpathy selon laquelle ses modèles préféraient GPT-5.1, tandis qu’il préférait Gemini, suggère que les modèles IA peuvent avoir des biais partagés. Ils pourraient favoriser la verbosité, un formatage spécifique, ou une confiance rhétorique qui ne correspond pas nécessairement aux besoins humains en matière de concision et de précision.
Alors que les entreprises s’appuient de plus en plus sur des systèmes « LLM-comme-juge » pour évaluer la qualité de leurs bots en contact avec les clients, cette divergence est importante. Si l’évaluateur automatisé récompense systématiquement des réponses « verbeuses et étalées » alors que les clients humains veulent des solutions concises, les métriques montreront le succès tandis que la satisfaction client chutera. L’expérience de Karpathy suggère que se fier uniquement à l’IA pour évaluer l’IA est une stratégie sujette à des problèmes d’alignement cachés.
Ce que les équipes de plateforme d’entreprise peuvent apprendre d’un piratage de week-end avant de construire leur pile 2026
Au final, LLM Council agit comme un test de Rorschach pour l’industrie de l’IA. Pour l’amateur, c’est une façon amusante de lire des livres. Pour le fournisseur, c’est une menace, prouvant que la fonctionnalité de base de leurs produits peut être reproduite en quelques centaines de lignes de code.
Mais pour le leader technologique de l’entreprise, c’est une architecture de référence. Il démystifie la couche d’orchestration, montrant que le défi technique ne réside pas dans le routage des incitations, mais dans la gouvernance des données.
Alors que les équipes de plateforme se dirigent vers 2026, beaucoup se retrouveront probablement à regarder le code de Karpathy, non pas pour le déployer, mais pour le comprendre. Il prouve qu’une stratégie multi-modèles n’est pas techniquement hors de portée. La question reste de savoir si les entreprises construiront elles-mêmes la couche de gouvernance ou paieront quelqu’un d’autre pour envelopper le « code de vibe » dans une armure de qualité entreprise.