Perplexity contre Counsel

À quoi ressemble un écart d'architecture sur une même décision de stratégie IA

Si vous vous êtes déjà demandé s'il ne suffirait pas de poser la question à ChatGPT ou à Perplexity plutôt que de payer Counsel, ce billet est pour vous. J'ai fait l'expérience.

Même texte de décision. Deux outils. Aucune astuce de prompt. Les réponses sont revenues fondamentalement différentes — non parce que l'une était « mieux écrite » ou avait un « meilleur prompt », mais parce que les deux outils ont des architectures différentes.

Le protocole

J'ai soumis aux deux outils le même texte de décision, mot pour mot. Le voici :

Mettre en place des flux de travail assistés par IA pour permettre aux développeurs comme aux non-développeurs (produit, expérience utilisateur) de contribuer à une base de code SaaS, tout en maintenant une qualité de code élevée, en garantissant la compréhension des modifications et en limitant la charge pour les développeurs.

Contraintes : petite équipe ; besoin de guides de contribution et de conventions clairs ; les non-développeurs demandent une attention particulière sur les modifications de code ; outils existants VS Code, GitHub, Claude ; interdiction de livrer en production sans compréhension complète de l'implémentation et de ses conséquences ; le temps des développeurs ne doit pas être trop consommé par le processus.

Puis j'ai demandé : « Pouvez-vous me donner des éléments étayés pour décider ? »

Mêmes mots. Deux outils. Ce qui revient dit quelque chose de l'architecture qui se trouve dessous.

La réponse de Perplexity

Perplexity a rendu une réponse sensée et bien structurée. La recommandation était juste, dans les limites de ce qu'elle couvrait : « adopter des flux assistés par IA, mais uniquement avec un modèle opérant contraint et fortement adossé à la revue ».

La structure était propre :

• Cinq critères de décision — compréhensibilité avant fusion, différentiels petits et bornés, chemin de fusion protégé, propriété explicite, faible charge pour les développeurs.
• Un modèle opérant en cinq étapes — les non-développeurs écrivent l'intention ; Claude propose l'implémentation ; un développeur relit l'architecture et les conséquences ; la protection de branche bloque la fusion directe ; les non-développeurs ne touchent que des zones autorisées.
• Une liste de ce qu'il faut mettre dans le guide de contribution.
• Des signaux d'alerte à surveiller.
• Une recommandation concrète — adopter l'IA pour l'interface, les textes, les tests, la documentation et les chemins de code isolés ; garder la propriété développeur sur la logique centrale, le modèle de données, les intégrations et l'irréversible.

Huit citations. Et c'est là que l'architecture commence à se voir.

Trois des huit citations pointent vers des pages de docs.github.com sur la protection de branche. Deux autres vers des pages de support d'éditeur — code.claude.com et support.claude.com. Une vers anthropic.com. Deux vers des billets sur dev.to. La dernière vers un billet du blog cloud.google.com.

Regardez ce qui manque : aucun signal récent du terrain. Aucun directeur technique racontant ce qui s'est réellement passé quand son équipe a adopté des flux de codage assistés. Aucun article de 2026 mesurant le taux de réécriture du code face aux gains de productivité. Aucun retour d'expérience sur un arbitrage construire-ou-acheter. Perplexity a puisé dans la documentation d'éditeurs et quelques billets intemporels, puis a écrit une synthèse autour.

Il a conclu par : « Souhaitez-vous que j'en fasse une matrice de décision ? »

Verdict. Voilà ce que produit une architecture qui génère puis lie. Le modèle a écrit la synthèse depuis sa mémoire d'entraînement, plus une récupération de fragments web en temps réel. Puis un appariement de citations après coup a accroché des sources d'apparence plausible. Les citations ne portent rien ; elles décorent. Ouvrez docs.github.com/branch-protection et vous n'y trouverez aucune recommandation sur les flux assistés par IA — parce que ce document ne parle pas de ça. Le lien est accroché parce que la synthèse mentionnait la protection de branche, que le système a trouvé une page sur la protection de branche, et que les deux étaient assez proches pour être affichés ensemble. La vérification s'arrête là.

La réponse de Counsel

Counsel est bâti autour de trois choses persistantes que vous lui donnez : les décisions que vous pesez activement (par exemple devons-nous standardiser un flux de codage assisté par Claude dans toute l'équipe ?), les questions sur lesquelles vous voulez l'état des preuves du terrain (quel est le gain net réel de productivité du codage agentique en 2026 ?), et les sujets surveillés que vous voulez suivre dans la durée (la feuille de route des modèles de codage d'Anthropic). Chaque nouvelle génération réexamine chaque nouvel article contre ces trois listes, fait remonter ce qui porte le plus sur chacune, et nomme les listes restées sans signal. Cet état persistant, un agent conversationnel n'en a aucune version.

Sur la même décision de flux assistés par IA, Counsel a produit un document daté, avec une accroche, cinq enseignements, une réserve « pour aller plus loin dans vos domaines », et un bloc de changements depuis la génération précédente.

L'accroche : « Cette semaine : établir des références de productivité réalistes — les développeurs produisent 30 à 40 % de code en plus avec l'IA, mais 15 à 25 % de cette production demande une réécriture ou une suppression. »

Les statistiques de couverture : 269 candidats sémantiques examinés → 160 dans le vivier final après déduplication et filtrage du juge → 11 articles cités. Article le plus récent : 1 jour. Médiane : 43 jours.

Les cinq enseignements :

1. Établir des références de productivité réalistes — conférence InfoQ sur les copilotes, 43 jours. Correspondance adjacente, promue depuis la réserve du passage précédent.
2. Aligner avant de générer du code — conférence de Maggie Appleton pour GitHub sur l'ingénierie collaborative assistée, 26 jours. Correspondance adjacente, promue depuis la réserve.
3. Adopter le développement piloté par la spécification — O'Reilly Radar, 63 jours. Correspondance directe, reconduite.
4. Formaliser l'intention en artefacts lisibles par la machine — O'Reilly Radar, 44 jours. Correspondance directe, reconduite.
5. Imposer des demandes de fusion petites et vérifiables — billet Medium, 72 jours. Correspondance directe, reconduite.

Chaque enseignement est structuré : un type (règle, constat, flux de travail, principe), un énoncé d'une phrase, trois points concrets, une clause « s'applique quand », et surtout un champ « pour votre situation » qui nomme vos contraintes réelles. Celui de l'enseignement 1 se lit ainsi :

« Compte tenu de votre objectif d'ouvrir la contribution aux développeurs comme aux non-développeurs, attendez-vous à un gain net de 15 à 20 % pour votre équipe d'ingénierie, tout en tirant parti d'outils tout-en-un pour débloquer des capacités entièrement nouvelles chez vos contributeurs produit et expérience utilisateur. »

Chaque enseignement porte aussi une citation de preuve — la phrase littérale de la source — et une cible de lien profond (identifiant et titre de section) pour sauter directement au paragraphe. Celle de l'enseignement 1 : « Ils estimaient le gain net de productivité des ingénieurs logiciels à environ 15 à 20 % grâce à l'IA. »

Les cinq enseignements de ce passage sont revenus ancrés : vrai, sans affirmation non étayée. Ce n'est pas toujours le cas. Lors d'une génération précédente de cette même décision, la vérification d'ancrage de Counsel a signalé sa propre paraphrase « pile Claude » comme non étayée — la vidéo source disait seulement « standardiser sur une seule plateforme », et Counsel a refusé d'ancrer la formulation plus précise qu'il avait écrite. Counsel fait remonter sa propre incertitude dans le document lui-même. Peu d'agents conversationnels ont cette fonction.

Puis vient le reste du document :

• Un bloc de changements comparant ce passage au précédent : « 2 promus — le développement assisté par IA est désormais actif. » Comptes : 0 nouveau, 3 reconduits, 2 promus, 1 abandonné. L'article abandonné est conservé en entier pour que vous puissiez voir ce qui a été rétrogradé, et pourquoi.
• La dynamique des zones calmes. Au passage précédent, les flux de contribution des non-développeurs et le développement assisté par IA étaient tous deux signalés calmes, sans signal depuis plus de 90 jours. Ce passage-ci, du matériel frais a réactivé le second — Counsel rapporte explicitement la transition, pour que vous sachiez ce qui vient de se réveiller et ce qui est resté silencieux.
• Cinq articles supplémentaires en réserve, avec leurs enseignements complets — dont une conférence GitHub de Maggie Appleton et un article arXiv sur la qualité des demandes de fusion générées par IA.

Verdict. Voilà ce que produit une architecture qui extrait puis synthétise. Counsel a sélectionné des articles dans un corpus IA sélectionné, noté chacun contre le texte réel de la décision avec un juge, synthétisé uniquement depuis les passages extraits, puis exécuté une passe de vérification d'ancrage avant publication — en faisant remonter la dynamique (ce qui est nouveau, ce qui est silencieux, ce qui vient de se réveiller) qu'on ne peut construire que sur un état persistant.

Les douze différences, côte à côte

Lisez le tableau de près et vous remarquerez que les lignes 3, 5, 7, 8, 9 et 10 ne sont pas des fonctions que Perplexity aurait oubliées en version 1.0 et livrerait en 2.0. Ce sont des fonctions qui exigent une architecture que Perplexity n'a pas.

Pourquoi un meilleur prompt ne comble pas l'écart

Si vous avez déjà tenté de combler ce genre d'écart par l'ingénierie de prompt, vous en connaissez les limites.

Un prompt ne peut pas créer d'état. Quelle que soit l'habileté de votre requête, l'outil n'a aucune mémoire de vos décisions, aucune liste de ce que vous avez ignoré la semaine dernière, aucun journal de ce que vous avez jugé utile, aucun moyen de comparer le résultat d'aujourd'hui à celui d'hier. Chaque requête part de zéro. C'est la vérité architecturale derrière « Counsel travaille quand vous ne demandez rien » : sans état, l'outil ne peut que réagir à votre question du moment.

Un prompt ne peut pas créer de détection d'absence. Pour vous dire « cadriciel d'agents : aucun signal depuis 41 jours », l'outil doit savoir ce que vous suivez et l'avoir suivi. Cela fait deux morceaux d'état, et aucun ne tient dans un prompt.

Un prompt ne peut pas créer de boucle d'apprentissage. Le système à six couches de Counsel — similarité sémantique par adresse, agrégation au niveau des concepts, goût collectif entre utilisateurs, engagement par les clics, décalage d'embedding côté requête, et calibrage du juge sur vos propres exemples positifs et négatifs — se cumule sur des semaines et des mois. Un prompt opère à l'intérieur d'un seul appel. Quand l'appel se termine, l'apprentissage n'a nulle part où vivre.

Un prompt ne peut pas rendre « extraire puis synthétiser » architectural. Même en demandant à ChatGPT ou à Perplexity de « ne synthétiser qu'à partir des passages récupérés, sans rien inventer », vous demandez à un système dont la chaîne est générer puis accrocher des citations de se comporter comme un système dont la chaîne est extraire d'abord, puis synthétiser depuis la structure extraite. La première fait confiance au modèle pour ne pas puiser dans sa mémoire d'entraînement ; la seconde ne lui donne pas accès à cette mémoire.

Ce ne sont pas des points négociables par le prompt. Ce sont des propriétés du système autour du modèle.

Ce que Perplexity fait réellement mieux

Soyons honnêtes : la question symétrique compte aussi. Où Perplexity l'emporte-t-il ?

• L'étendue des sujets. Perplexity fonctionne sur n'importe quel domaine. Counsel travaille sur des décisions de stratégie IA. Pour la politique douanière européenne ou la chimie d'une nouvelle technologie de batterie, adressez-vous à Perplexity.
• La vitesse sur une question isolée. Counsel met 30 à 60 secondes à générer un document neuf avec vérification, jugement et extraction structurée. Perplexity donne une réponse exploitable en 5 à 15 secondes.
• L'absence de configuration. Perplexity fonctionne dès l'inscription. Counsel demande de nommer vos décisions, vos contraintes et vos sujets surveillés — c'est le prix d'entrée de ce que l'architecture apporte, mais c'est un prix que vous ne payez pas avec Perplexity.
• La fraîcheur du web ouvert. Perplexity ira chercher un communiqué publié ce matin. Counsel lit un corpus rafraîchi à son propre rythme, de l'heure à la journée selon le palier de la source.

Rien de cela ne change l'écart sur les décisions de stratégie IA. Cela situe simplement chaque outil.

Ce qu'il faut en retenir, honnêtement

Si rien de réel ne dépend de la réponse — aucune décision en jeu, aucun mois de reprise en cas d'erreur — utilisez Perplexity ou Claude. Ils répondront.

Si vous avez 1 à 3 décisions de stratégie IA actives sur votre table — de celles où une mauvaise décision coûte trois à six mois d'ingénierie, ou dont l'angle mort concurrentiel devient le conseil où votre dirigeant l'a su avant vous — et que vous voulez un outil qui suit ces décisions pour vous, nomme celles devenues silencieuses et réexamine chaque nouvel article contre elles, alors l'écart d'architecture compte.

C'est le problème pour lequel Counsel a été construit.

Tarifs et mise en route

• Gratuit — Brief quotidien. 7 articles frais à fort signal chaque matin, classés par palier de source, intention et profondeur. Filtrage par rôle, sujets et format. Lu en 5 minutes.
• 99 €/mois en Solo (ou 79 €/mois en facturation annuelle) — le Brief quotidien, plus Counsel sur toutes les décisions que vous apportez. Sans quota, sans calcul.

Passez-le en note de frais. Aucun processus d'achat. Inscrivez-vous sur aissential.tech →

L'architecture, pas le prompt.