Et si le problème n'était pas le modèle, mais le fait de n'en consulter qu'un seul ?
Perplexity vient d'étendre son Model Council à sa plateforme cloud Computer, permettant désormais de soumettre une question à jusqu'à 8 modèles d'IA simultanément. Ces modèles traitent le problème de manière indépendante, puis un rapport de synthèse met en lumière leurs convergences et divergences. La promesse : mieux qu'une réponse unique, une cartographie des perspectives.
Cette approche baptisée tokenmaxxing — consommer délibérément plus de tokens pour obtenir une analyse plus robuste — mérite qu'on s'y attarde sérieusement, notamment dans un contexte de projets web critiques où une mauvaise décision architecturale peut coûter cher.
Le problème réel : la fausse certitude d'un LLM seul
Tout développeur ayant utilisé un LLM en production connaît ce moment inconfortable : le modèle répond avec aplomb, de façon cohérente et bien formulée… et se trompe. Les hallucinations ne sont pas rares, mais ce qui est plus insidieux, c'est la confiance apparente avec laquelle un modèle peut défendre une mauvaise décision.
Interroger un seul modèle sur un sujet ambigu — une architecture à choisir, une stratégie de migration, une règle métier complexe — c'est un peu comme demander l'avis d'un seul consultant sans second regard. Même les meilleurs ont des angles morts.
Le Model Council de Perplexity formalise ce que certaines équipes font déjà manuellement : croiser les réponses de GPT-4, Claude et Gemini pour identifier ce qui fait consensus. La plateforme automatise ce workflow et en produit un rapport structuré.
Ce que l'approche multi-modèles change concrètement
Détecter les zones de désaccord comme signal d'alerte
Lorsque trois modèles s'accordent et qu'un quatrième diverge, ce n'est pas nécessairement que le quatrième a tort. C'est un signal que la question touche une zone d'incertitude réelle. Dans un contexte de décision technique — choisir entre une architecture événementielle et un CRUD classique, évaluer la pertinence d'un ORM pour un cas d'usage spécifique — ce désaccord est une information précieuse.
En PHP/Symfony, on retrouve ce principe dans la revue de code à plusieurs : ce n'est pas que les relecteurs se contredisent qui est gênant, c'est de ne pas savoir qu'ils auraient des avis différents.
Réduire le biais de formulation
Un même problème formulé différemment donne parfois des réponses radicalement différentes selon le modèle. En soumettant le même prompt à plusieurs LLM simultanément, on neutralise en partie ce biais. Les conclusions qui émergent malgré des styles d'inférence distincts sont plus robustes.
C'est particulièrement utile pour des questions à fort enjeu comme :
- L'évaluation de risques de sécurité sur une fonctionnalité
- La pertinence d'une règle métier dans un domaine complexe
- Le choix d'une stratégie d'indexation sur une base de données à fort volume
Un cas d'usage concret : l'audit de prompt engineering
Imaginez que vous développez un assistant IA embarqué dans une application Symfony. Vous avez rédigé un prompt système pour guider le comportement du modèle. Soumettre ce prompt à un Model Council — en demandant à chaque modèle d'identifier les ambiguïtés, les failles de sécurité potentielles ou les comportements indésirables — donne une grille de lecture bien plus complète qu'un seul retour.
Le revers de la médaille : les coûts et la latence
Le tokenmaxxing n'est pas gratuit, c'est même l'euphémisme de l'article source du Register. Multiplier les appels par 8 multiplie mécaniquement les coûts d'inférence et la latence globale. Ce type d'approche n'est pas adapté à tous les contextes.
Des questions à poser avant d'adopter une stratégie multi-modèles :
- La décision justifie-t-elle le surcoût ? Pour un contenu généré en masse, non. Pour une décision architecturale engageant 6 mois de développement, probablement oui.
- Le workflow est-il asynchrone ? La latence devient acceptable si le rapport arrive dans les minutes qui suivent plutôt qu'en temps réel.
- Peut-on réduire le périmètre ? Plutôt que 8 modèles sur tout, 3 modèles bien choisis sur les questions vraiment ambiguës.
Dans une architecture Symfony, ce type de consultation multi-modèles s'intègre naturellement dans un workflow asynchrone avec Messenger : on pousse la demande en queue, chaque modèle est interrogé en parallèle via des workers, et un service d'agrégation produit la synthèse.
Vers une IA de conseil, pas de remplacement
Ce que Perplexity démontre avec le Model Council, c'est un changement de paradigme dans l'usage des LLM : passer de "l'IA qui répond" à "l'IA qui délibère". C'est une distinction importante pour les équipes qui intègrent l'IA dans des processus métier sensibles.
Cette approche s'inscrit dans une tendance plus large vers les systèmes agentiques où plusieurs modèles, éventuellement spécialisés, collaborent plutôt que d'opérer en silo. Les patterns d'orchestration d'agents (débat entre agents, validation croisée, juré/arbitre) explorent le même territoire.
Pour les développeurs PHP/Symfony qui construisent des fonctionnalités IA, c'est un signal clair : la qualité de vos intégrations LLM ne dépend pas uniquement du modèle choisi, mais de votre capacité à structurer l'incertitude et à en faire une donnée exploitable plutôt qu'un angle mort.
Conclusion
Le Model Council de Perplexity n'est pas qu'un gadget marketing. Il formalise une bonne pratique que les équipes les plus matures appliquent déjà manuellement : croiser les points de vue pour révéler les zones d'incertitude réelle. Le coût en tokens est réel, mais pour les décisions qui comptent — architecturales, sécuritaires, stratégiques — c'est un investissement qui peut éviter des erreurs bien plus coûteuses.
La vraie question n'est pas "quel modèle choisir", mais "quand mérite-t-il d'en consulter plusieurs".
Source : The Register — Perplexity's tokenmaxxing Model Council gives you multiple bot perspectives
