Rapport de recherche interne du **12 août 2026** (format *What ? — So What ? — Now What ?*, enquête menée les 11-12 août) sur une question simple : les applications **desktop** de ChatGPT et de Claude sont-elles meilleures que leurs versions **web** ? La réponse est en deux temps. **(A) Un consensus qualitatif solide et sourcé existe.** Le point de départ est incontestable : desktop et web appellent exactement les mêmes modèles cloud, l'application n'étant qu'une interface du service — le gain se situe donc intégralement dans l'enveloppe applicative (latence d'accès, stabilité en session longue, empreinte mémoire, intégrations système, fluidité du workflow). Ce qui distingue réellement le desktop, confirmé : côté OpenAI, raccourci global (Option/Alt + Espace), *companion window* toujours au premier plan, captures d'écran natives, et depuis juillet 2026 l'agentique **Codex/Work** intégrée à l'app ; côté Anthropic, **Quick Entry** (macOS), **Desktop Extensions** (installer un serveur **MCP** local devient *« as simple as clicking a button »*), accès aux fichiers locaux, **Cowork** et **Computer Use** (permissions Accessibilité et enregistrement d'écran). Le web garde deux atouts confirmés : multi-onglets / multi-fils, et universalité sans client à installer. **(B) La quasi-totalité des chiffres qui circulent pour étayer ce consensus ne résiste pas à la vérification.** L'audit critique du rapport (§1.5) classe **non confirmées** sept affirmations chiffrées largement reprises : le *cold start* « 2-3 s vs 8-12 s » (seule trace, un *« loads in about 3 seconds »* anecdotique sur Substack) ; la RAM « 200-700 Mo vs 1,2-2 Go », attribuée à un « Alibaba Product Insights » dont les pages renvoient **404** ; un *glitch rate* et une rétention de session introuvables ; un « Claude +10-20 % end-to-end » attribué à **Skywork**, qui avait en réalité benchmarké son propre agent Windows et non Claude contre le web ; une source « Cosmo Edge » introuvable ; des citations Zenken AI non confirmées ; et deux posts X non authentifiés, sans URL. Le contre-signal est documenté avec la même rigueur : Yuri Dvoinos décrit une app Claude Desktop qui *« makes me want to throw my laptop out the window »* — 68 % de CPU, lag de saisie sur MacBook Pro —, et le rapport rappelle que les deux apps sont des constructions **Electron** avec couches natives. D'où sa formule : *l'avantage desktop est une promesse d'implémentation, pas une loi de la nature.* **Le « So What »** : puisque le modèle est devenu le point commun, l'interface devient le champ de bataille — la fusion **Codex + ChatGPT** du 9 juillet 2026 et le tandem Cowork / Computer Use racontent la même histoire, *« l'app desktop n'est plus un client de chat, c'est un runtime d'agents avec accès à la machine »*. Trois conséquences : le gain est un gain de **friction**, non de puissance ; pour une DSI, le desktop **déplace la frontière de confiance** — Computer Use exige des permissions système sensibles et la fusion Codex place exécution de code, navigateur et connecteurs dans *« one expanded trust boundary »*, là où le navigateur reste gouvernable par SSO, DLP et CASB ; et pour qui publie, la fragilité des chiffres est en elle-même l'information. **Le « Now What »** livre des critères de bascule individuels, une checklist DSI (inventorier les permissions, désactiver Computer Use et Cowork par défaut, cadrer les extensions MCP autorisées, organiser distribution et mises à jour — sur Linux, hors dépôt apt, Claude Desktop ne se met pas à jour seul) et une consigne éditoriale : ne citer que les verbatims et dates confirmés.
#ChatGPT Desktop#Claude Desktop#version web
**Deep Research Veille Interne** — rapport non signé · produit par une enquête sourcée menée les **11-12 août 2026** et rendu le 12.
Annonce **Google** du **6 août 2026** : Google rejoint comme **Core Maintainer** la spécification **Agent Plugins 1.0.0**, format d'empaquetage ouvert et *vendor-neutral* pour distribuer ensemble des **Agent Skills** et des **serveurs MCP**. La spécification a été publiée par un **TSC** dont les Core Maintainers viennent d'**Amazon, Cursor, Microsoft, OpenAI et Vercel** ; Google s'y ajoute, représenté par **Kevin Hou** (Senior Staff Engineer, Google DeepMind). Les deux briques empaquetées — Agent Skills et MCP — sont d'origine **Anthropic**, qui ne figure pas dans cette liste de mainteneurs. **Le diagnostic** tient en une phrase : *« The core problem isn't the components. It's the manifest. »* Une skill est portable, un serveur MCP est portable ; la boîte dans laquelle on les met ne l'est pas, et chaque client a dû l'inventer pour lui-même — d'où les forks, les copies de composants identiques et leur dérive. **Le format** tient en une contrainte : *« A plugin is a directory. That's the whole idea, and the restraint is the point. »* Un `plugin.json` à deux lignes utiles (`$schema` et `name`), des skills dans `skills/` au format Agent Skills, des serveurs déclarés dans `mcp.json` avec un **`type` explicite sur chaque entrée** (stdio, Streamable HTTP, ou HTTP+SSE historique) — plus de transport deviné à la forme de l'objet de configuration. La force du design est dans ce que le manifeste **ne peut pas** faire : ni déplacer les composants, ni les déclarer en ligne, donc aucun chemin de découverte à configurer et aucun ordre de précédence à apprendre. Corollaire opérationnel : les composants **échouent indépendamment** — un serveur `mcp.json` qui ne démarre pas n'emporte pas les skills du plugin, le client saute l'entrée, continue et signale l'échec. L'échappatoire assumée est le répertoire en **domaine inversé** (`com.example.client/`), espace d'extension appartenant entièrement à un client (hooks, agents, commandes) que les autres ignorent : *« le cœur portable reste petit parce que les parties non portables ont un endroit légitime où aller »*. Une section est consacrée aux cas où le format ne se justifie pas — *« Not every skill should be a Plugin »* : un seul serveur MCP vers un seul client, `mcp.json` suffit ; une seule skill, pas besoin de plugin. Ce que la v1 exclut explicitement, en *future considerations* : **aucun mécanisme d'installation, aucun protocole de distribution, aucun modèle de permissions, aucune exigence de bac à sable, aucune vérification de confiance ou de provenance, aucune UX**. Le tout s'insère dans une pile à quatre couches indépendamment adoptables — **trouver** (Agentic Resource Discovery), **décrire** (AI Catalog, qui enregistrerait le type `application/agent-plugins+json`), **empaqueter** (Agent Plugins), **exécuter** (MCP + Agent Skills). Deux produits Google livrent déjà : **Agents CLI** et **Data Agent Kit** (BigQuery, Spanner, Cloud SQL).
Page d'entrée de la **spécification officielle** de l'**Agent Client Protocol (ACP)** (`agentclientprotocol.com/get-started/introduction`), consultée le **2 août 2026**. Ce n'est pas un article daté mais un **artefact vivant** : la fiche est datée de son observation, pas d'une publication. **Énoncé de mission en une phrase** : *« The Agent Client Protocol (ACP) standardizes communication between code editors/IDEs and coding agents and is suitable for both local and remote scenarios. »* **Le problème posé** tient en trois lignes : agents de codage et éditeurs sont **étroitement couplés** et *« interoperability isn't the default »* — chaque éditeur doit construire une intégration sur mesure par agent, chaque agent doit implémenter des API spécifiques à chaque éditeur. Trois conséquences nommées : **integration overhead** (chaque paire agent-éditeur demande du travail sur mesure), **limited compatibility** (un agent ne touche qu'un sous-ensemble d'éditeurs), **developer lock-in** (*« choosing an agent often means accepting their available interfaces »*). **La solution est explicitement calquée sur LSP** — *« similar to how the Language Server Protocol (LSP) standardized language server integration »* — avec le bénéfice réciproque : un agent qui parle ACP fonctionne avec **tout** éditeur compatible, un éditeur qui supporte ACP gagne accès à **tout** l'écosystème d'agents ACP. **Deux modes de déploiement, et c'est le point le plus sous-estimé** : les agents **locaux** tournent en sous-processus de l'éditeur en **JSON-RPC sur stdio**, mais les agents **distants** sont prévus en **HTTP ou WebSocket** — support déclaré *« work in progress »*, avec une collaboration en cours avec des plateformes agentiques. **Filiation technique avec MCP, plus forte qu'une simple complémentarité** : ACP *« re-uses the JSON representations used in MCP where possible »*, en ajoutant des types propres aux besoins d'UX du codage agentique (l'affichage de **diffs** est l'exemple donné) ; le format par défaut du texte lisible est le **Markdown**, choisi pour ne pas exiger que l'éditeur sache rendre du HTML. **Deux constats de gouvernance et de versionnement** relevés sur la page et non dans le discours ambiant : la navigation expose **v1 (Latest)** et **v2 (Draft)** — et **non un « ACP 1.2 »** —, et la barre de navigation lie **Zed Industries *et* JetBrains** côte à côte, aux côtés d'un **ACP Registry**, de **RFDs**, d'une section **Community**, de **Publications**, d'**Updates** et d'une page **Brand**. Bibliothèques officielles annoncées : **Kotlin, Java, Python, Rust, TypeScript**, plus un volet communautaire.
#Agent Client Protocol#ACP#protocole ouvert
**Projet Agent Client Protocol** — spécification collective · sans signature individuelle sur cette page. La barre de navigation du site lie deux organisations au même niveau : **Zed Industries** (à l'origine du protocole) et **JetBrains**. La présence d'une section **RFDs** (*requests for discussion*) · d'une page **Community** et d'un **ACP Registry** indique une structure de gouvernance ouverte plutôt qu'une documentation produit.
Note de veille de **Didier Girard** datée du **2 août 2026**, partie d'une question de collègue (« c'est quoi ACP ? ») pour traiter un problème qui n'est pas terminologique mais **documentaire**. **Trois protocoles se disputent le sigle**, sans aucune intersection technique : **Agent Client Protocol** (client ↔ agent — Zed, août 2025, JSON-RPC 2.0 sur stdio, Apache-2.0, « ce que LSP a fait pour les langages »), **Agentic Commerce Protocol** (agent ↔ commerçant — OpenAI + Stripe, 29 sept. 2025, face à l'**UCP** de Google du 11 janv. 2026 adossé à **AP2**), et **Agent Communication Protocol** (agent ↔ agent — IBM Research / BeeAI, marginal mais polluant les recherches). **Le cœur de la note n'est pas le démêlage mais son échec constaté** : l'auteur cherche « ACP » dans sa base de connaissances de veille et obtient **douze résultats, tous sur le protocole de commerce, zéro sur celui de Zed** — *« nos agents de veille avaient indexé le sigle sans le désambiguïser »*. D'où une règle d'ingénierie de la connaissance : ***« on n'indexe jamais un sigle seul »*** — l'entité est « Agent Client Protocol », « ACP » n'est **qu'un alias**, porté par trois entités distinctes. Suit une clarification structurante (**MCP relie un agent à ses outils, ACP relie un client à un agent ; les deux s'empilent**) puis le cas d'école : **Buzz**, publié par **Block** le 21 juillet 2026 sous Apache-2.0 — espace de travail auto-hébergeable bâti sur **Nostr**, où chaque participant humain ou agent est une **paire de clés** et chaque message, étape de workflow ou push git un **événement signé** dans un journal append-only. Architecture entièrement protocolaire (`buzz-acp` harnais ACP sur stdio, `buzz-agent` agent ACP appelant un LLM, `buzz-dev-mcp` serveur MCP shell + édition), d'où l'agnosticisme d'agents : **Goose, Claude Code et Codex** se branchent par le même harnais, et **Hermes** (Nous Research) s'y est raccordé sans que Block écrive une ligne — *« N+M au lieu de N×M, tenue en production »*. La note se clôt sur la question de l'**abonnement Claude** face aux agents tiers, avec une chronologie 2026 en cinq temps et une **règle de conception** qui vaut au-delà du cas : la ligne n'est pas juridique mais **architecturale** — ***« qui consomme, et pour le compte de qui »*** (un agent `owner-only` consomme votre abonnement pour vous ; un agent `anyone` dans un canal partagé fait passer les requêtes de vos collègues par votre compte). **Vérification menée sur ce corpus** : la thèse tient, et plus durement que ce que la note affirme — non seulement « Agent Client Protocol » y est **totalement absent**, mais le sigle nu `ACP` **est déjà typé comme entité** dans deux fiches, et la page KB `Agentic-Commerce-Protocol` **attribue déjà le protocole à Google** alors qu'il est d'OpenAI + Stripe. La collision décrite n'est pas un risque à venir : elle a **déjà produit une erreur d'attribution** dans le graphe.
**Didier Girard** — auteur de la note. Écrit ici depuis la position de **praticien de la veille outillée** : le déclencheur est une question de collègue · le matériau principal est le comportement observé de sa propre base de connaissances · et la conclusion est une **règle de curation** adoptée en interne. Le texte alterne donc deux voix — l'explicateur de protocoles et l'ingénieur de la connaissance qui constate un défaut chez lui et en tire une norme.
Analyse de Janakiram MSV (The New Stack, 20 juillet 2026) sur la **convergence architecturale** des plateformes d'agents d'entreprise des trois hyperscalers : en neuf mois, **Amazon Bedrock AgentCore**, **Microsoft Foundry** et **Gemini Enterprise Agent Platform** ont fait émerger les **mêmes six primitives** — runtime, mémoire, tool gateway, identité, observabilité, gouvernance — sous des noms de marque différents. Ce qui était il y a 18 mois une collection fragmentée de librairies devient une **couche plateforme** distincte. La thèse : cette convergence rejoue l'inflexion **PaaS de 2011-2016**, où **Cloud Foundry** et **Heroku** ont unifié VM, load balancers, files et secret stores autour d'un **contrat applicatif** portable — sauf qu'ici **aucun contrat équivalent n'existe encore**, et **aucun projet open source ne l'a revendiqué**. Conséquence : une entreprise ne peut pas **déplacer un agent d'un cloud à l'autre** (état de session, traces, identité terminent tous chez un seul fournisseur ; migrer = tout reconstruire). L'auteur propose un **mapping ligne à ligne** du contrat Cloud Foundry vers les agents, décline trois principes de conception (packager l'agent en **une unité déployable**, **attacher** les capacités plutôt qu'embarquer les fournisseurs, intégrer l'**opérationnel** à l'abstraction), pointe ce que les protocoles ouverts (MCP, A2A, OpenTelemetry) laissent hors champ — le **cycle de vie** —, et livre trois questions de due diligence : **gouvernance** (fondation neutre vs vendor), **packaging** (même artefact sur deux clouds sans réécriture), **état** (mémoire exportable). Verdict : celui qui possèdera le **control plane agent** définira *ce qu'est un agent*.
Article du blog de **Pasquale Pillitteri** (ingénieur informatique, Palermo) publié le **29 mai 2026** (version FR), 18 min de lecture, rubrique *Claude Code & Anthropic*. **Thèse-pivot** : *« Claude Opus 4.8 est le modèle SEO le plus puissant de 2026, mais presque tout le monde l'utilise mal »* — non pas un problème de modèle mais de **système**. La règle d'or : ***« la stratégie est un tableau blanc, la production est une chaîne de montage »*** — il faut **scinder le SEO en deux phases distinctes**, et les mélanger est *« le moyen le plus rapide de gaspiller un modèle qui coûte cinq dollars par million de tokens en entrée et vingt-cinq en sortie »*. **Contexte modèle** : Opus 4.8 publié le **28 mai 2026** (41 jours après Opus 4.7), contexte **1M tokens**, **GraphWalks Long-Context F1 à 1M : 40,3 % → 68,1 %**, **SWE-bench Verified 88,6 %**, **USAMO 2026 96,7 %** (+27,4 pts), **HLE avec tool 57,9 %**, prix inchangé **5 $/25 $** par M tokens, **Fast Mode 2,5× à 10 $/50 $**, quatre **effort levels** (Low, High, Extra, Max). **L'anti-pattern central** = *« la conversation géante »* / **dérive du contexte** : mélanger stratégie, keyword research, analyse concurrentielle et rédaction dans un seul chat produit une *« bouillie d'intentions contradictoires »* → le modèle glisse vers les **best practices génériques** (« optimisation holistique », « approche stratégique ») au lieu d'un contenu ancré aux données. **Phase 1 — Stratégie (tableau blanc, UI visuelle, one-off)** : dashboard / Google Sheet / canvas Claude.ai pour décider en voyant les données ensemble. **3 plays** : (a) **keyword research classifiée** (tableau volume / difficulté 0-100 / intention / potentiel business / priorité = volume÷difficulté×poids business) ; (b) **analyse concurrentielle visuelle** (matrice de couverture thématique, gaps) ; (c) **roadmap par phases** (quick wins M1-2 / moyen terme M3-6 / pillar pages M7-12). Mode **Extra/Max** justifié ici (*« une décision stratégique juste vaut mille pages bien écrites sur des mots-clés erronés »*). 3 artefacts fermés sauvegardés sur Notion/Drive. **Phase 2 — Production (chaîne de montage, Opus 4.8 + MCP)** : le modèle passe de stratège à **machine d'exécution** ; chaque décision **ancrée à des données live** via **Model Context Protocol**. **Stack MCP minimum** : **GSC MCP** (AminForou/mcp-gsc, 500+ étoiles), **Ahrefs MCP officiel** (98 étoiles), **GA4 MCP** ; repo `modelcontextprotocol/servers` = **86 440 étoiles**, **10 000+ serveurs actifs**, 97M téléchargements SDK/mois. Setup ~35 min, refresh mensuel ~20 min. **Loop hebdomadaire** : un prompt unique tire les données live, construit le brief (top 10 SERP + GSC + Ahrefs), dérive H2/H3, écrit, contrôle densité, suggère titres → **+45 % productivité**, draft en **6-12 min** (référence explicite au **content engineering de Ryan Law / Ahrefs**, 23 skills). Mention des **Dynamic Workflows** Anthropic (jusqu'à 1 000 subagents). **4 erreurs courantes** : (1) ne pas vérifier les chiffres (spot-check obligatoire, *trust & verify*) ; (2) remplacer complètement Semrush/Ahrefs (le MCP est une **couche par-dessus**, pas un substitut) ; (3) ignorer le **content gap paid-organic** (cas client education : **2 742 termes gaspillés / 351 opportunités** identifiés en 90 s) ; (4) utiliser Opus 4.8 là où **Haiku 4.5** suffit (meta descriptions, alt text). **Coût** : 1-3 $/article de 2 500 mots. **Sonnet 4.6** suffit pour la production récurrente, Opus 4.8 réservé à la stratégie. Article SEO-optimisé et auto-référentiel (l'auteur écrit sur le SEO un contenu lui-même conçu pour se positionner sur « Opus 4.8 SEO »). Convergence directe avec **Ryan Law/Ahrefs** (cité), **systems around the model** (Dropbox/Okumura), **skills-over-prompts** (Lattice), routage modèle Haiku/Sonnet/Opus (Gupta token-to-outcome).
#Claude Opus 4.8#SEO IA#workflow en deux phases
**Pasquale Pillitteri** — Ingénieur informatique / développeur logiciel basé à **Palerme** (Italie) · certifié Innovation Manager UNI 11814:2021. Auteur d'un blog tech actif (rubrique *Claude Code & Anthropic*) · avec une newsletter hebdomadaire (~3,4k lecteurs). Article publié en version **FR** le **29 mai 2026** (lendemain de la sortie d'Opus 4.8).
Billet du **blog Ahrefs** publié le **28 avril 2026** par **Ryan Law** (Director of Content Marketing, Ahrefs) décrivant un système de **content engineering** maison construit autour de **Claude Code** : un pipeline éditorial qui produit des **drafts prêts à publier en 6 à 12 minutes**. **Thèse-pivot** : ***« AI content is not, by default, good. This process works well because it mirrors our existing human editorial process »*** — la qualité ne vient pas du modèle mais de la **reproduction fidèle d'un processus éditorial humain** éprouvé sur des décennies. Architecture : **~23 skill files** correspondant chacun à une étape éditoriale (keyword research, topic gap analysis, structural outlining, research compilation, draft generation, formatting), **orchestrés par un skill principal `blog-pipeline`** qui les enchaîne pour produire un article complet. **Sept principes de conception** : (1) **mimer les workflows humains** en chaînant des skills adaptés de la documentation éditoriale Ahrefs existante ; (2) **sortir chaque étape séparément** pour le troubleshooting (*« if you get an article at the end of a ten minute run, and it's bad, it's hard to diagnose precisely where and why the process went wrong »* → sauvegarder les outputs intermédiaires) ; (3) **créer des cas de test** via le skill `skill-creator` d'Anthropic pour évaluer et améliorer les guidances ; (4) **brancher des sources de données de qualité** — le **Ahrefs MCP** (keyword metrics, parent topic, long-tail themes, SERP overviews, analyse concurrentielle), l'analyse concurrentielle et la doc produit ; (5) **front-loader la direction humaine** via des paramètres de contexte permettant le guidage éditorial ; (6) **construire des previews interactives** au format HTML pour la revue avant publication ; (7) **permettre la personnalisation** (chaque membre de l'équipe peut forker et modifier le système). **Volumétrie** : ~**15 articles publiés** et ~**30 articles mis à jour** via ce workflow ; développement démarré en **février 2026** (le processus antérieur d'**août 2025** demandait plusieurs jours et de l'intervention manuelle). **Caveats explicites** (anti-survente) : *« experience matters »* — le processus reflète des décennies d'expertise éditoriale ; la sélection de sujets se concentre sur du **contenu SEO informationnel** que l'auteur maîtrise bien ; Ahrefs **n'a aucun plan de "scaler" massivement le contenu** mais maintient une **bibliothèque evergreen**. Philosophie : automatiser *« the formulaic parts of work »* pour éliminer la corvée et libérer du temps pour la recherche, le thought leadership, les webinars et l'optimisation du système — **pas** remplacer l'effort humain. Référence canonique citée par Pasquale Pillitteri (*Opus 4.8 SEO workflow*) comme preuve terrain du gain « 6-12 min/draft ». Convergence directe avec la doctrine **skills-over-prompts** (Lattice, PROJ-AI), **systems around the model** (Dropbox/Okumura), et l'usage **HTML comme artefact de revue** (Shihipar).
#content engineering#ingénierie de contenu#Claude Code
**Ryan Law** — Director of Content Marketing chez **Ahrefs**. Praticien senior du content marketing SEO ; le billet est un retour d'expérience personnel (*« How I do… »*) publié sur le **blog Ahrefs** (ahrefs.com/blog) le **28 avril 2026**.
Block/Goose — MCP-UI et le futur des interfaces agentiques : composants web interactifs dans les conversations d'agents IA via Model Context Protocol (block.github.io)
Relais Legal.io de l'étude MIT NANDA "The GenAI Divide: State of AI in Business 2025" : 95% des pilotes IA en entreprise n'apportent aucun ROI mesurable malgré $30-40 Mds investis. Concept de "GenAI Divide", "shadow AI economy", quatre facteurs structurels d'échec, recommandation back-office et build-to-buy. Justification empirique du basculement RH-organisationnel.
#MIT NANDA#GenAI Divide#95% pilotes échec
Legal.io (relais et synthèse) — étude MIT NANDA "The GenAI Divide: State of AI in Business 2025"