🔔

🛠 Roadmap MCP : tools manquants detectes par le LLM router

Quand le LLM router identifie qu un tool MCP serait utile mais n existe pas encore, il est ajoute ici. Pour chaque gap : ✅ Confirmer (valide pour dev) · ❌ Pas interesse (cache, rejete) · 🤖 Brief Claude (copie un prompt pret a coller pour confier le dev a Claude). Tries par frequence × statut.

53
Gaps total
69
Demandes cumulees
37
A trier
0
Valides dev
0
En cours
5
Resolus
11
Rejetes
Filtre : ⏳ A trier37 ✅ Valides dev0 🚧 En cours0 ✓ Resolus5 👎 Rejetes11 🗂 Tous53 Tri : smart · valeur · demandes
Brief auto-suffisant : stack technique + architecture BDD + pattern de code + APIs (plugin Redirection, Rank Math) + sécurité + observabilité + détail de chaque gap. Tu colles dans Claude → Claude code tout d'un coup.
×1 seo_wp_find_post_by_url rejected 1ere demande 2026-05-04 · derniere 2026-05-04 14:59
Devrait faire : Resout une URL WordPress vers son post_id (et post_type) afin de pouvoir appliquer set_robots, set_canonical, etc. sans connaitre l ID a l avance.
Pourquoi les tools existants ne suffisent pas : seo_autopilot_set_robots requiert post_id mais on n a souvent que l URL. Il faut donc une etape manuelle de lookup. seo_wp_find_media existe pour les images mais pas pour les posts/pages.
Signature suggeree :
{"url": "https://transicio.com/old-intermediate-page", "site": "transicio"}
Notes triage : [2026-05-04 18:12 · ui] 👎 Rejete
Tasks qui ont demande ce tool :
#3 Désindexation URLs intermédiaires + soumission URLs finales
🎯 Analyse opportunite (generee 2026-05-04 par le LLM router)
Valeur metier : 0.78 Faisabilite : easy WordPress REST API expose plusieurs mecanismes natifs : (a) endpoint /wp-json/wp/v2/search?search=<slug> qui retourne id+type, (b) la fonction url_to_postid() de WP core est exposable via un mu-plugin trivial, (c) requete directe sur /wp-json/wp/v2/pages?slug=xxx et /posts?slug=xxx. Le slug s'extrai... Effort dev : S 1-3h Pourquoi cette valeur : Tool d'infrastructure qui debloque l'usage en chaine de toute la famille seo_autopilot_* (set_robots, set_canonical, etc.) en mode batch et agentique. Sans lui, le LLM doit demander a l'user de fournir les post_id, ce qui casse l'automatisation. Avec lui, on passe d'un workflow semi-manuel a un workflow 100% automatisable a partir d'une simple liste d'URLs (qui est le format natif de toutes les sources SEO : GSC, sitemap, crawls). Effet de levier x5 immediat sur le portfolio + condition sine qua non pour servir des clients e-commerce/B2B volumineux ou personne ne raisonne en post_id. Cout dev derisoire (S, ~2h, infra WP REST deja en place). Ratio valeur/effort excellent. Pas 0.9+ car ce n'est pas un tool 'visible' qui produit de la valeur seul, c'est un enabler. Cas d usage ideaux : 1) Audit SEO post-migration sur transicio (~158 pages) : on recoit une liste d'URLs a deindexer/canonicaliser depuis GSC ou Screaming Frog, on veut appliquer set_robots/set_canonical en batch sans lookup manuel. 2) Workflows de nettoyage : LLM recoit 'cette URL doit etre noindex' et peut agir directement. 3) Cross-site batch : appliquer une regle SEO sur 5 sites a partir d'une liste d'URLs exportees. 4) Futurs clients e-commerce 10k+ pages : indispensable car aucun humain ne connait les post_id, tout vient d'URLs (GSC, crawls, sitemaps). 5) Resolution d'URLs depuis rapports DataForSEO/GSC qui retournent toujours des URLs, jamais des IDs. 6) Gestion des redirections : verifier qu'une URL existe encore comme post avant d'agir. Contexte requis : Utile des le portfolio actuel (5 sites) car toute donnee SEO externe (GSC, Ahrefs, crawls) parle en URL et non en post_id. Devient critique sur tout site >500 pages ou pour clients e-commerce/B2B 10k+ pages ou le lookup manuel est impossible. Si rejete, reconsiderer si : N/A (score >= 0.5)
🟢 Forte opportunite + faisabilite OK : a developper en priorite
🔍 Tools existants modestement similaires (max similarite = 0.618)

Probablement different mais a verifier. Lis les docstrings ci-dessous pour confirmer que ce gap apporte vraiment une fonctionnalite nouvelle.

seo_maillage_backfill_wp_ids 0.618 seo_action
[ACTION] Pre-resoud les wp_post_id manquants (paginated WP REST + redirect-follow). Use when: avant un batch de write maillage, pour reduire les fails 'wp_post_id introuvable'.
seo_autopilot_purge_wp_rocket_cache 0.576 seo_action
[ACTION] Purge cache WP Rocket : full domain, ou per-post, ou per-url. Args: post_id : si fourni, purge cache de ce post uniquement url : si fourni, purge de cette URL specifique Sinon :
seo_autopilot_wp_update_excerpt 0.575 seo_action
[WORKFLOW] Set l extrait (excerpt) d un post WP. Use when: tu veux modifier l extrait utilise dans les listings/cards/RSS, et en fallback pour og:description si pas de meta_description Rank Math.
×1 seo_url_inspection_schedule rejected 1ere demande 2026-05-04 · derniere 2026-05-04 15:00
Devrait faire : Planifie une URL Inspection GSC recurrente (hebdo/mensuelle) sur un set d URLs et historise les resultats pour detection de regression (changement coverageState, lastCrawlTime, indexingState).
Pourquoi les tools existants ne suffisent pas : seo_page_google_view fait une inspection ponctuelle sans scheduling ni historisation comparative automatisee.
Signature suggeree :
{"site": "transicio", "urls": ["..."], "frequency": "weekly", "alert_on_regression": true}
Notes triage : [2026-05-04 18:15 · ui] 👎 Rejete
Tasks qui ont demande ce tool :
#4 Configuration monitoring post-correction
🎯 Analyse opportunite (generee 2026-05-04 par le LLM router)
Valeur metier : 0.62 Faisabilite : easy Google Search Console URL Inspection API est officielle, stable, deja utilisee par seo_page_google_view. Le scheduling peut etre delegue a un cron externe (GitHub Actions, cron systeme) qui appelle le tool, ou via une table 'scheduled_jobs' + worker. L'historisation est trivial (table SQLite/JSON av... Effort dev : M ~1 jour Pourquoi cette valeur : Valeur reelle en mutualisation portfolio : monitorer 50 URLs critiques x 5 sites = 250 URLs auditees automatiquement chaque semaine, ce qui est impossible manuellement. Detection de regression d'indexation = signal SEO precoce a haute valeur (perte d'indexation = perte de trafic direct). Effet d'agregation fort : un seul tool sert les 5 sites + scalable pour clients futurs. Cependant, sur des sites B2B 50-500 pages avec contenu stable, les regressions d'indexation sont rares — le tool brille surtout en contexte e-commerce/gros volumes ou apres deploiements. Score moyen-haut car infra reutilisable (le store + scheduler peut servir a d'autres tools de monitoring). Cas d usage ideaux : 1) Monitoring de regression d'indexation sur les pages strategiques des 5 sites (homepages, pages services, articles piliers transicio ~30-50 URLs critiques). 2) Detection precoce de desindexation silencieuse apres deploiement WordPress (changement de theme, plugin SEO, refonte URL). 3) Surveillance du lastCrawlTime pour detecter les pages 'oubliees' par Googlebot (signal de qualite degradee). 4) Pour futurs clients e-commerce 10k+ : monitoring de l'indexation des top categories/produits revenue-driver (echantillon 200-500 URLs prioritaires). 5) Reporting client mensuel automatise : 'X% de vos pages cles sont indexees, Y ont regresse ce mois'. 6) Validation post-migration : verifier que les URLs critiques restent indexees apres changement structurel. Contexte requis : Necessite GSC API connectee sur chaque site (deja prerequis pour seo_page_google_view). Valeur croissante a partir de 3+ sites monitores OU 1 site avec 100+ URLs critiques. Necessite un store persistent (DB/JSON) pour historisation. Quota GSC URL Inspection API : 2000 requetes/jour/site, 600/min — largement suffisant pour scheduling hebdo sur sets de <500 URLs. Si rejete, reconsiderer si : Score >0.5, donc a developper. Si rejete malgre tout, reconsiderer si : (a) signature d'un client e-commerce 5k+ pages, (b) incident de desindexation sur un site du portfolio qui aurait pu etre detecte plus tot, (c) besoin de reporting client recurrent automatise.
🟡 Opportunite moyenne : decision selon roadmap globale
🔍 Tools existants modestement similaires (max similarite = 0.648)

Probablement different mais a verifier. Lis les docstrings ci-dessous pour confirmer que ce gap apporte vraiment une fonctionnalite nouvelle.

seo_rotation_inspection_status 0.648 seo_read
[ANALYZE] Diagnostic rotation URL Inspection : pages PASS/FAIL/issues et reste a inspecter. Use when: tu veux savoir combien de pages ont ete inspectees recemment et leur statut (succes, echec, probl
seo_indexation_status_audit 0.631 seo_read
[ANALYZE] Distribution des pages par statut d'indexation Google (Submitted&indexed, Crawled-not-indexed, Discovered-not-indexed, Duplicate). Use when: tu veux comprendre pourquoi certaines pages ne s
seo_autopilot_submit_gsc_now 0.626 seo_action
[WORKFLOW] Drain IMMEDIAT de la queue gsc_index_queue : appelle directement Google Indexing API pour notifier Google sans attendre le cron daily de 02h00. Use when: tu viens de modifier ou publier de
×2 seo_redirect_chain_consolidator rejected 1ere demande 2026-05-04 · derniere 2026-05-14 23:21
Devrait faire : Detecte automatiquement toutes les chaines de redirections (A->B->C, A->B->C->D) sur un site et propose un plan de consolidation en 301 directes. Combine seo_redirect_map + analyse de chaines + generation de regles a appliquer.
Pourquoi les tools existants ne suffisent pas : seo_redirect_map liste les redirects mais ne detecte pas explicitement les chaines >=2 hops avec un plan de remediation.
Signature suggeree :
{"site": "transicio", "auto_apply": false, "min_chain_length": 2}
Notes triage : [2026-05-04 17:25 · ui] ✅ Confirme pour dev [2026-05-04 18:18 · ui] 👎 Rejete — Couvert par tool existant `seo_redirect_map` (similarite cosine 0.727)
Tasks qui ont demande ce tool :
#2 Réécriture fichier redirections (301 direct)
- #647 URGENCE TECH : Assainissement architecture + redirections (pré-requis SEO)
🎯 Analyse opportunite (generee 2026-05-04 par le LLM router)
Valeur metier : 0.55 Faisabilite : easy La detection est techniquement directe : crawler les URLs initiales, suivre chaque 301/302 jusqu au statut final, construire un graphe et detecter les chaines >=2 hops + boucles. Pas besoin d API tierce - juste HTTP HEAD requests + parsing des Location headers. Le tool seo_redirect_map existe deja e... Effort dev : S 1-3h Pourquoi cette valeur : Valeur reelle mais pas critique sur le portfolio actuel : sites B2B 50-500 pages ont rarement des chaines profondes (max 1-2 hops, gerable manuellement). Cependant : (1) effet mutualisation x5 sites pour audits trimestriels = gain de temps, (2) transicio 158 pages avec historique = candidat probable, (3) le tool devient TRES valuable pour ouverture clients e-commerce/B2B 10k+ ou les chaines sont systemiques et invisibles a l oeil nu. La detection de boucles seule justifie presque le dev (bug critique SEO souvent indetecte). Effort M raisonnable car reutilise seo_redirect_map. Score 0.55 = bon investissement preventif pour scale futur, pas urgence immediate. Cas d usage ideaux : 1) Post-migration de site (transicio, belformance ont probablement des chaines historiques accumulees au fil des refontes). 2) Audit SEO trimestriel sur les 5 sites du portfolio pour eliminer les chaines qui diluent le PageRank et ralentissent le crawl. 3) Consolidation apres changement de structure d URL (ex: passage HTTP->HTTPS + www->non-www + slug change = chaines de 3-4 hops). 4) Futur client e-commerce 10k+ pages ou les chaines explosent vite (produits discontinues redirigés vers categories elles-memes redirigees). 5) Client B2B avec multiples acquisitions/fusions de sites historiques. 6) Detection de boucles de redirection (cas critique souvent invisible). 7) Generation automatique de regles .htaccess/nginx/WordPress consolidees. Contexte requis : Site avec historique de migrations OU volume >2k pages OU portfolio multisite (effet mutualisation). Necessite acces aux fichiers .htaccess/config serveur OU aux plugins de redirection WordPress (Redirection, Rank Math) via REST API. Le crawl seul detecte les chaines mais l application auto necessite acces ecriture aux regles. Si rejete, reconsiderer si : N/A - score >= 0.5, le dev est justifie. Si on voulait reporter : reconsiderer immediatement des qu un client e-commerce >5k pages arrive, ou des qu une migration majeure est planifiee sur un site du portfolio, ou si un audit manuel revele des chaines >=3 hops sur transicio.
🟡 Opportunite moyenne : decision selon roadmap globale
⚠️ Tools existants TRES similaires (max similarite = 0.727)

Verifie soigneusement si l un d eux convient — il y a un risque eleve de doublon. Top 3 par similarite cosine.

seo_redirect_map 0.727 seo_read
[ANALYZE] Liste toutes les redirections 301/302 d un site avec leur cible et detecte les chaines de redirection. Use when: tu veux auditer les redirections existantes, identifier les chaines (2+ hops
seo_maillage_break_cycle 0.612 seo_action
[ACTION] Casse un cycle de redirects (A->B->A) en disable/delete.
seo_internal_link_optimizer 0.595 seo_read
[ANALYZE] Propose des liens internes optimaux entre articles orphelins et pages piliers. Use when: tu veux identifier les opportunites de maillage interne (articles sans lien vers pilier, piliers ave
×1 docs_publish_to_notion rejected 1ere demande 2026-05-04 · derniere 2026-05-04 15:01
Devrait faire : Cree ou met a jour une page Notion (ou Confluence) avec contenu Markdown structure (mapping tables, code blocks curl, checklists), dans un workspace/parent specifie, et retourne l URL partagable. Doit supporter les blocs Notion natifs (table, toggle, code, checkbox) et le tagging (equipe, projet).
Pourquoi les tools existants ne suffisent pas : seo_rag_store stocke en interne TF-IDF (non partageable hors-systeme), cockpit_propose_node cree des taches de suivi, seo_save_analysis sauvegarde des findings JSON. Aucun tool ne pousse vers Notion/Confluence avec mise en forme riche destinee a une equipe externe.
Signature suggeree :
{"tags": ["seo", "redirections", "dev-workflow"], "title": "Redirections 301 - Procedure et checklist prevention chaines", "workspace": "transicio-dev", "share_with": ["team-dev@transicio.com"], "parent_page": "SEO Procedures", "content_markdown": "# Mapping ancien -> final\n| Old URL | Final URL |..."}
Notes triage : [2026-05-04 18:15 · ui] 👎 Rejete
Tasks qui ont demande ce tool :
#5 Documentation technique + checklist future
🎯 Analyse opportunite (generee 2026-05-04 par le LLM router)
Valeur metier : 0.55 Faisabilite : easy Notion API officielle est mature, bien documentee, gratuite (rate limit 3 req/s). Endpoints stables : POST /v1/pages (create), PATCH /v1/blocks/{id}/children (append), GET /v1/search (find parent). Markdown -> Notion blocks : librairies existantes solides (martian, notion-md, py md2notion). Auth via... Effort dev : M ~1 jour Pourquoi cette valeur : Valeur reelle mais pas critique en l etat actuel du portfolio. Sur les 5 sites actuels (B2B petits volumes, gestion solo/quasi-solo), l utilite est limitee : un seo_save_analysis JSON + lecture directe suffit pour usage interne. Le tool prend de la valeur sur 2 axes : (a) ouverture clients = livrable professionnel directement dans leur outil, ce qui est un differentiateur commercial concret et evite l export manuel chronophage ; (b) mutualisation knowledge base cross-sites pour capitaliser les apprentissages. Effort M raisonnable et faisabilite easy rendent le ROI positif des qu il y a 1-2 clients externes. Aujourd hui : nice-to-have. Dans 6 mois avec premiers clients : tres utile. Cas d usage ideaux : 1) Documentation des procedures SEO recurrentes (redirections 301, audits techniques, checklists migration) partagee avec equipes dev/marketing externes sur transicio. 2) Livrables clients pour futurs comptes B2B/e-commerce : rapports d audit SEO mensuels, roadmaps techniques, mapping de redirections post-migration directement publies dans le Notion du client. 3) Knowledge base mutualisee cross-portfolio : centraliser les apprentissages des 5 sites (patterns qui marchent sur yuzko vs belformance) dans un Notion maitre. 4) Handover dev : quand un findings SEO necessite implementation cote dev (schema.org, hreflang, perf), pousser une page Notion structuree avec code blocks curl + checklist au lieu d un export manuel. 5) Reporting executif : transformer un seo_save_analysis JSON en page Notion lisible pour decideurs non-techniques. Contexte requis : Workspace Notion (ou Confluence) actif cote user OU cote client. Pertinent des qu il y a >=1 collaborateur externe (dev, client, manager) qui ne va pas lire un JSON. Devient indispensable a partir de 2-3 clients externes ou d une equipe dev dediee. Si rejete, reconsiderer si : Reconsiderer immediatement si : (1) signature d un premier client externe necessitant des livrables recurrents (audits mensuels, rapports SEO) ; (2) constitution d une equipe (dev, redacteur) qui consomme les findings SEO ; (3) volume de procedures documentees > 20 (besoin d une vraie base structuree partagee) ; (4) demande explicite d un prospect pour livraison Notion/Confluence. Tant que l usage reste solo sur 5 sites B2B, JSON + markdown local suffisent.
🟡 Opportunite moyenne : decision selon roadmap globale
✓ Aucun tool similaire detecte (max similarite = 0.478)

Le top match (seo_brief_publish_to_wp) n est qu a sim 0.478. Probablement un vrai nouveau besoin, mais tu peux toujours verifier.

seo_brief_publish_to_wp 0.478 seo_action
[ACTION] Publie l article d un brief sur WP (immediat ou planifie). Workflow : 1. Si pas de wp_post_id : cree draft (seo_autopilot_create_post_draft) 2. Update status : 'publish' (immediat) o
seo_charter_publish_topic 0.452 seo_action
[ACTION] Promote un topic en brief (genere via Claude si demande). Use when: passer un topic 'planned' a 'briefed' avec brief auto-genere. Si generate_brief=False : juste change le status (brief manu
seo_autopilot_create_post_draft 0.441 seo_action
[WORKFLOW] Cree un brouillon WordPress (status=draft) via WP REST API, jamais en publication directe. Use when: tu as redige un article complet et veux le pousser dans WordPress comme brouillon pour
×1 seo_alert_email_configure rejected 1ere demande 2026-05-04 · derniere 2026-05-04 15:00
Devrait faire : Configure une alerte email ciblee sur evenements precis (nouvelles erreurs 4XX/5XX detectees sur un set d URLs ou un pattern d URL) avec destinataires et seuil de declenchement.
Pourquoi les tools existants ne suffisent pas : seo_set_alert est generique (condition/threshold) et channel='email' mais sans precisions sur le pattern URL ni la nature exacte de l evenement HTTP.
Signature suggeree :
{"site": "transicio", "event_type": "new_http_error", "recipients": ["seo@transicio.com"], "url_pattern": "/cas/*", "status_codes": ["4xx", "5xx"]}
Notes triage : [2026-05-04 18:15 · ui] 👎 Rejete
Tasks qui ont demande ce tool :
#4 Configuration monitoring post-correction
🎯 Analyse opportunite (generee 2026-05-04 par le LLM router)
Valeur metier : 0.55 Faisabilite : medium Faisabilite moyenne car necessite: (1) un systeme de crawl recurrent qui stocke un etat (snapshot precedent des status codes) pour detecter le 'NEW' dans 'new_http_error' - cela implique une DB/store. (2) Un scheduler (cron, Celery, ou equivalent). (3) Integration SMTP/SendGrid/Resend pour l'envoi e... Effort dev : M ~1 jour Pourquoi cette valeur : Valeur reelle mais pas critique sur le portfolio actuel: les 5 sites font 50-500 pages, un crawl manuel mensuel ou un check GSC hebdo couvre 90% du besoin. Cependant, mutualise sur 5 sites + ouverture clients, le tool devient interessant: (a) il transforme une tache reactive (decouvrir une 404 quand un client se plaint) en proactive, (b) il differencie l'offre commerciale ('monitoring SEO temps-reel par section'), (c) effort M raisonnable si seo_set_alert pose deja les fondations. Le score n'est pas plus haut car: sur 50-500 pages, la frequence de nouvelles erreurs est faible, et des outils externes (UptimeRobot, Sitebulb, Oncrawl) couvrent deja ce besoin pour les futurs clients qui voudraient du serieux. Cas d usage ideaux : 1) Monitoring proactif des sections critiques de transicio (ex: /cas/* qui sont les pages clients references B2B - une 404 sur ces URLs = perte de credibilite immediate). 2) Surveillance des landing pages payantes / campagnes (yuzko, belformance) ou un 5XX silencieux pendant 48h = budget Ads gaspille. 3) Pour belkis-chayeb et pierre-alexandre-mas (sites personal branding/portfolio): alerter sur 4XX des pages /portfolio/* ou /references/*. 4) Cas e-commerce futur: alerte instantanee sur 4XX/5XX des URLs /product/* ou /category/* (perte de CA directe). 5) Client B2B 10k+ pages: surveillance ciblee par pattern (/blog/* vs /solutions/*) avec destinataires differents (SEO vs DevOps). 6) Detection regression post-deploiement: alerte si nouvelle vague de 4XX apparait apres une mise en prod WordPress. Contexte requis : Necessite un crawler/monitoring HTTP qui tourne en continu ou planifie (daily). Utile des qu'un site a >100 pages indexees ou des URLs critiques business. Valeur maximale sur portfolio multisite (mutualisation infra de monitoring) ou client e-commerce/B2B avec impact CA direct. Si rejete, reconsiderer si : N/A - score >= 0.5, dev justifie surtout si l'infra seo_set_alert + crawler recurrent existe deja (effort tombe a S). Sinon, reconsiderer absolument si: (1) signature d'un client e-commerce 5k+ SKU, (2) client B2B avec SLA contractuel sur disponibilite SEO, (3) incident reel sur transicio/cas client ou une 404 non detectee a coute une opportunite commerciale.
🟡 Opportunite moyenne : decision selon roadmap globale
⚠️ Tools existants TRES similaires (max similarite = 0.718)

Verifie soigneusement si l un d eux convient — il y a un risque eleve de doublon. Top 3 par similarite cosine.

seo_set_alert 0.718 seo_read
[ADMIN] Cree une alerte SEO personnalisee declenchee quand une condition atteint un seuil. Use when: tu veux etre notifie automatiquement si clicks chutent de X%, impressions passent sous Y, ou CTR d
seo_alerts_list 0.585 seo_read
[READ] Liste les alertes decisionnelles DFS (volume_spike, volume_drop, position_lost, new_competitor_top3). Use when: tu veux voir les alertes SEO recentes pour reagir aux changements critiques dete
seo_alert_ack 0.554 seo_read
[WRITE] Acquitte une alerte DFS en marquant acknowledged_at = NOW. Use when: tu veux signaler qu une alerte a ete vue/traitee pour ne plus la voir dans les alertes actives. DO NOT use: - pour liste
×1 docs_export_curl_runbook rejected 1ere demande 2026-05-04 · derniere 2026-05-04 15:01
Devrait faire : Genere automatiquement un runbook Markdown contenant les commandes curl de validation pour une liste d URLs (avec headers attendus, codes 301/200, Location finale) — utile pour produire la section 'Procedure testee' de la doc.
Pourquoi les tools existants ne suffisent pas : seo_redirect_verify verifie une redirection mais ne genere pas de runbook documentaire reutilisable. Il faudrait scripter manuellement la generation de la doc curl.
Signature suggeree :
{"site": "transicio", "urls": ["https://...", "..."], "format": "markdown", "expected_codes": [301, 200]}
Notes triage : [2026-05-04 18:17 · ui] 👎 Rejete
Tasks qui ont demande ce tool :
#5 Documentation technique + checklist future
🎯 Analyse opportunite (generee 2026-05-04 par le LLM router)
Valeur metier : 0.45 Faisabilite : easy Aucune API externe requise. Le tool est purement un generateur de texte : prend une liste d URLs + codes attendus, formate des blocs curl Markdown avec assertions (curl -I -L, grep sur Location, check status). Optionnellement execute les curls reellement pour pre-remplir les valeurs observees (reque... Effort dev : S 1-3h Pourquoi cette valeur : Valeur reelle mais limitee : (+) Effort tres faible (S, 2-3h), reutilise du code existant, produit un livrable tangible et professionnel utile en B2B/consulting. (+) Forte valeur pour ouverture clients - un runbook curl bien formate est un asset de credibilite technique. (-) Use case principal (post-migration) est ponctuel, pas recurrent. (-) Sur les 5 sites actuels (petits B2B), la valeur est marginale apres la migration initiale de transicio. (-) Peut etre remplace par un prompt one-shot a Claude qui genere le meme markdown a partir d une liste d URLs. Le ROI depend fortement de la frequence des migrations et de l acquisition clients. A faire si effort confirme S, sinon reporter. Cas d usage ideaux : 1) Documentation post-migration : apres une refonte de site (ex: transicio recemment migre), generer en 1 commande le runbook curl prouvant que les 50-200 redirections 301 fonctionnent (Location header, code final 200). 2) Livrable client B2B : pour un futur client e-commerce 10k+ qui migre, livrer un PDF/MD 'Procedure testee de validation' avec toutes les commandes curl reproductibles - asset commercial fort. 3) Audit recurrent multisite : sur les 5 sites, generer mensuellement un runbook de validation des URLs critiques (homepage, money pages, redirects historiques) pour detecter regressions. 4) Handover technique : quand un dev externe intervient sur un site, lui fournir le runbook curl pour valider son deploiement avant mise en prod. 5) Documentation HTTPS/HSTS/canonical : verifier headers de securite et SEO sur pages cles. Contexte requis : Pertinent surtout en contexte migration/refonte (one-shot intense) OU livrable client. Faible valeur en run quotidien sur petit site stable. Sweet spot : portfolio avec 1-2 migrations/an + ouverture clients e-commerce. Si rejete, reconsiderer si : Reconsiderer si : 1) Acquisition d un client avec migration majeure (e-commerce 10k+ ou refonte B2B) ou le runbook devient un livrable contractuel. 2) Mise en place d un process recurrent de validation multisite (audit trimestriel des 5 sites). 3) Apparition de regressions repetees sur redirects/headers necessitant un outil de doc reproductible pour les devs externes.
🟡 Opportunite moyenne : decision selon roadmap globale
✓ Aucun tool similaire detecte (max similarite = 0.455)

Le top match (seo_briefs_generator_run) n est qu a sim 0.455. Probablement un vrai nouveau besoin, mais tu peux toujours verifier.

seo_briefs_generator_run 0.455 seo_read
[BATCH] Job batch : genere des briefs SEO pour tous les keywords de la watchlist active ayant opportunity_score >= seuil. Use when: tu veux lancer la generation automatique de briefs en masse pour le
seo_playbook 0.455 seo_read
[STRATEGIC] Execute un playbook SEO complet orchestrant plusieurs analyses en un seul appel. Use when: tu veux lancer un workflow pre-configure (weekly_review, monthly_report, content_gap_analysis, t
seo_seed_playbooks_for_all_sites 0.439 seo_read
[ADMIN] Pre-genere les 30 playbooks SEO standards pour tous les sites suivis en une seule operation. Use when: initialisation du systeme ou ajout massif de sites necessitant la structure de playbooks
×3 seo_gsc_removals_request rejected 1ere demande 2026-05-04 · derniere 2026-05-04 17:07
Devrait faire : Soumet une demande de suppression temporaire ou definitive d URL via l outil Removals de Google Search Console (API ou bridge). Permet de masquer rapidement des URLs des SERP en attendant que noindex soit recrawle.
Pourquoi les tools existants ne suffisent pas : Aucun tool actuel n expose la GSC Removals API. seo_autopilot_set_robots applique noindex mais le delai de prise en compte par Google peut etre long (semaines), alors que Removals masque sous 24h.
Signature suggeree :
{"site": "transicio", "urls": ["https://transicio.com/old-intermediate-page"], "removal_type": "temporary"}
Notes triage : [2026-05-04 17:24 · ui] ✅ Confirme pour dev [2026-05-04 18:00 · ui] 🚧 En cours dev [2026-05-04 18:01 · ui] ✅ Confirme pour dev [2026-05-04 18:19 · ui] 👎 Rejete
Tasks qui ont demande ce tool :
#3 Désindexation URLs intermédiaires + soumission URLs finales
- #3 Désindexation URLs intermédiaires + soumission URLs finales
- #3 Désindexation URLs intermédiaires + soumission URLs finales
🎯 Analyse opportunite (generee 2026-05-04 par le LLM router)
Valeur metier : 0.35 Faisabilite : hard L'API officielle Google Search Console NE SUPPORTE PAS l'endpoint Removals - c'est une limitation connue et documentee de Google. Les options sont : (a) automation navigateur via Playwright/Puppeteer sur l'UI GSC (fragile, casse a chaque changement UI Google, gestion 2FA/cookies complexe), (b) exten... Effort dev : L ~3 jours Pourquoi cette valeur : Le besoin reel est rare sur un portfolio B2B de 5 sites a 50-500 pages : les cas d'usage urgents (leak RGPD, page diffamatoire, staging indexe) arrivent peut-etre 1-2 fois par an au total. Pour ces cas exceptionnels, la soumission manuelle via l'UI GSC prend 2 minutes - automatiser n'apporte pas de gain de temps significatif. Le score est plombe par : (1) absence d'API officielle = solution fragile a maintenir, (2) frequence d'usage trop faible pour justifier le cout de maintenance, (3) seo_autopilot_set_robots + sitemap ping couvrent deja 95% des besoins en quelques jours. Cependant la valeur monte serieusement pour un client e-commerce 10k+ pages ou un client subissant une crise (RGPD/reputation) - d'ou pas un 0.2. Cas d usage ideaux : 1) Suppression urgente de pages legales/RGPD exposees par erreur (mentions, CGV obsoletes avec donnees clients) sur les 5 sites B2B. 2) Retrait rapide de pages de staging/preprod indexees par accident (cas frequent sur WordPress mal configure - transicio, yuzko). 3) Masquage immediat lors d'un rebranding/refonte d'URLs sur belformance/belkis-chayeb/pierre-alexandre-mas en attendant que les 301 + noindex soient pris en compte. 4) Crise reputation : retrait d'une page contenant une info erronee/diffamatoire sous 24h au lieu d'attendre le recrawl (semaines). 5) Pour futurs clients e-commerce 10k+ pages : suppression massive de fiches produits supprimees, pages de filtres a facettes mal gerees, anciennes pages promo. 6) Pour clients B2B avec leaks accidentels (PDF internes indexes, urls /admin, /test). Contexte requis : Acces GSC valide (OAuth ou service account) sur chaque propriete. Utile des qu'un site a >100 pages avec rotation de contenu OU contexte sensible (donnees personnelles, refonte). Valeur croissante avec le nombre de sites geres (mutualisation) et critique pour clients e-commerce 5k+ pages ou agences gerant des sites a contenu sensible. Si rejete, reconsiderer si : Reconsiderer si : (1) signature d'un client e-commerce 10k+ pages avec rotation produits frequente, (2) signature d'un client a contexte sensible (sante, juridique, finance) ou les leaks RGPD doivent etre corriges sous 24h contractuellement, (3) incident reel sur un site du portfolio ou le delai de Google a coute cher, (4) Google publie enfin l'endpoint Removals dans l'API officielle GSC (passerait alors a effort S et score 0.6+), (5) volume de removals depasse 10/mois (seuil ou la manuelle devient penible).
🔴 Faible opportunite ou bloquant technique : envisager le rejet
🔍 Tools existants modestement similaires (max similarite = 0.623)

Probablement different mais a verifier. Lis les docstrings ci-dessous pour confirmer que ce gap apporte vraiment une fonctionnalite nouvelle.

seo_autopilot_submit_gsc 0.623 seo_action
[WORKFLOW] Soumet une URL a Google Search Console via la queue d'indexation gsc_index_queue. Use when: tu veux demander a Google de re-crawler une page apres modification ou publication. DO NOT use:
seo_autopilot_submit_gsc_now 0.598 seo_action
[WORKFLOW] Drain IMMEDIAT de la queue gsc_index_queue : appelle directement Google Indexing API pour notifier Google sans attendre le cron daily de 02h00. Use when: tu viens de modifier ou publier de
seo_indexation_queue_add 0.527 seo_read
[WORKFLOW] Ajoute des URLs a la queue d'indexation interne pour soumission automatique via Google Indexing API. Use when: tu veux demander l'indexation de pages nouvelles ou modifiees (apres publicat
×2 seo_crawl_budget_baseline rejected 1ere demande 2026-05-04 · derniere 2026-05-04 17:37
Devrait faire : Capture un snapshot des Crawl Stats GSC (requetes/jour, response codes distribution, file types, Googlebot type) a un instant T, le stocke comme baseline nommee, et permet une comparaison automatique a J+N (delta requetes 3XX, delta erreurs, evolution moyenne quotidienne).
Pourquoi les tools existants ne suffisent pas : Aucun tool actuel ne lit/snapshot les Crawl Stats GSC ni ne gere la comparaison temporelle baseline vs T+N.
Signature suggeree :
{"site": "transicio", "baseline_name": "post_correction_oct2025", "compare_at_days": 30}
Notes triage : [2026-05-04 17:53 · ui] 👎 Rejete — Pas d API officielle Google Crawl Stats (scraper fragile / parser logs serveur = 1j de dev par site). Volumes Transicio (158 pages) trop petits pour saturer le crawl budget. Couvert partiellement par seo_indexation_velocity + seo_crawl_errors. A reconsiderer si refonte URL majeure ou client e-commerce 50k+ pages. [2026-05-04 17:54 · ui] 👎 Rejete [2026-05-04 17:56 · ui] ↺ Re-ouvert — Re-evaluation : portfolio multisite (5 sites actifs + futurs clients) justifie un baseline standardise. Effet daggregation + dashboard consolide + onboarding clients automatise. Bloquant API GSC contournable via parsing logs serveur (dev mutualise sur 5+ sites). A reconsiderer pour validation. [2026-05-04 18:16 · ui] 👎 Rejete
Tasks qui ont demande ce tool :
#4 Configuration monitoring post-correction
- #4 Configuration monitoring post-correction
🎯 Analyse opportunite (generee 2026-05-04 par le LLM router)
Valeur metier : 0.25 Faisabilite : hard Probleme connu : l'API Google Search Console publique (Search Analytics API + URL Inspection API) NE FOURNIT PAS les donnees du rapport Crawl Stats (Settings > Crawl stats). Ces donnees ne sont accessibles que via l'UI GSC. Donc trois options : (a) scraping authentifie de l'UI GSC = fragile, casse a... Effort dev : L ~3 jours Pourquoi cette valeur : Sur le portfolio actuel, AUCUN site n'a un volume justifiant un suivi crawl budget : 50-500 pages signifie que Googlebot crawle l'integralite du site largement dans son budget, les variations Crawl Stats sont du bruit statistique. Meme transicio a 158 pages. La valeur theorique pour des futurs clients e-commerce existe, mais elle est plombee par la faisabilite : pas d'API GSC officielle pour Crawl Stats = soit scraping fragile (dette technique permanente), soit pivot vers log file analysis (autre produit, autre scope). En l'etat le ratio effort/valeur est mauvais : L de dev pour un tool fragile sur un besoin qui n'existe pas encore dans le portfolio. Cas d usage ideaux : 1) Post-migration ou refonte sur transicio (~158 pages corrigees recemment) : capturer une baseline avant correction massive de redirects/404 puis mesurer a J+30 si Googlebot voit moins de 3XX/4XX et si le crawl rate remonte. 2) Validation d'un nettoyage de chaines de redirects via le plugin Redirection : prouver via Crawl Stats GSC que Googlebot consomme moins de 3XX apres coup. 3) Detection d'une chute de crawl budget anormale sur un site (pic 5XX serveur OVH, WP Rocket mal configure, sitemap Rank Math casse) en comparant snapshot courant vs baseline saine. 4) Reporting client recurrent sur futurs clients e-commerce 10k+ ou B2B catalog : 'avant/apres' chiffre de l'optimisation crawl budget, livrable a forte valeur percue. 5) Mutualisation portfolio : dashboard cross-site qui flag les sites dont le crawl rate moyen a baisse >X% vs baseline, sans avoir a ouvrir 5 GSC manuellement. Contexte requis : Faible valeur sur sites <500 pages (transicio, yuzko, belformance, belkis-chayeb, pierre-alexandre-mas) ou le crawl budget n'est PAS un facteur limitant. Devient pertinent si: site >5k-10k pages, OU e-commerce avec facettes/parametres, OU post-incident technique majeur (migration, panne serveur, explosion 404), OU besoin de reporting client recurrent sur 5+ proprietes GSC. Si rejete, reconsiderer si : Reconsiderer si: (1) signature d'un client e-commerce ou catalog B2B >10k pages ou le crawl budget devient un vrai levier SEO ; (2) Google ouvre une API officielle pour Crawl Stats (a surveiller) ; (3) pivot du scope vers 'log file analyzer Googlebot' en exploitant l'acces SSH OVH + logs Apache, ce qui donnerait des donnees plus riches que GSC et serait techniquement propre - dans ce cas c'est un nouveau tool a re-scoper, pas celui-ci.
🔴 Faible opportunite ou bloquant technique : envisager le rejet
🔍 Tools existants modestement similaires (max similarite = 0.603)

Probablement different mais a verifier. Lis les docstrings ci-dessous pour confirmer que ce gap apporte vraiment une fonctionnalite nouvelle.

seo_indexation_velocity 0.603 seo_read
[ANALYZE] Mesure le delai entre publication (first_seen) et premier crawl Google. Use when: tu veux evaluer la vitesse de decouverte/indexation de nouvelles pages par Googlebot. DO NOT use: - pour
seo_top_keywords 0.598 seo_read
[READ] Top requetes Google d un site avec clics, impressions et position moyenne. Use when: tu veux lister les mots-cles qui generent du trafic organique sur un site, tries par performance. DO NOT us
seo_indexation_status_audit 0.592 seo_read
[ANALYZE] Distribution des pages par statut d'indexation Google (Submitted&indexed, Crawled-not-indexed, Discovered-not-indexed, Duplicate). Use when: tu veux comprendre pourquoi certaines pages ne s
×1 seo_server_redirect_rewrite rejected 1ere demande 2026-05-04 · derniere 2026-05-04 15:01
Devrait faire : Edite le fichier .htaccess (Apache) ou nginx.conf du serveur pour remplacer des chaines de redirections (A->B->C) par des redirections directes (A->C). Doit faire un backup horodatte du fichier avant modif, valider la syntaxe, recharger le serveur (apachectl graceful / nginx -s reload), puis tester chaque URL via curl -I pour confirmer 1 seul 301 puis 200. Reversible via restore du backup.
Pourquoi les tools existants ne suffisent pas : Tous les tools redirect actuels passent par Rank Math REST API (BDD WordPress). Aucun n a d acces SSH/filesystem pour editer .htaccess ou nginx.conf, ni pour faire un reload du serveur web.
Signature suggeree :
{"site": "transicio", "backup": true, "dry_run": true, "rewrites": [{"to": "https://www.transicio.com/cas-clients/missions-management-de-transition/audit-si-urgence-plan-transformation/", "from": "/audit-si-urgence-plan-transformation"}], "verify_after": true}
Notes triage : [2026-05-04 18:16 · ui] 👎 Rejete
Tasks qui ont demande ce tool :
#2 Réécriture fichier redirections (301 direct)
🎯 Analyse opportunite (generee 2026-05-04 par le LLM router)
Valeur metier : 0.15 Faisabilite : medium Techniquement faisable: SSH dispo sur OVH dedie, Apache present, parsing .htaccess est du regex sur RewriteRule/Redirect, backup horodatte trivial, apachectl configtest + graceful reload standard, verification via curl -I scriptable. Risques non triviaux: (1) parsing robuste de .htaccess (ordre des ... Effort dev : M ~1 jour Pourquoi cette valeur : Score tres bas car le tool est mal aligne avec le stack reel du portfolio. Les 5 sites en production gerent TOUS leurs redirects SEO via le plugin Redirection (BDD WP), pas via .htaccess - c'est explicite dans le contexte. Editer .htaccess pour ces redirects serait soit redondant soit dangereux (double redirect, conflit avec le plugin). L'argument 'mutualisation 5 sites' ne tient pas: 0 site sur 5 a ce besoin. La valeur potentielle existe uniquement pour des clients futurs hypothetiques avec stack non-WP ou redirects legacy infra. Risque additionnel: encourager l'user a contourner le plugin Redirection (single source of truth) cree de la dette technique. Un tool 'redirect_chain_collapse' operant via l'API du plugin Redirection apporterait 90% de la valeur sur 100% du portfolio actuel. Cas d usage ideaux : Cas tres limites compte tenu du stack: (1) Migration d'un site herite arrivant chez l'user avec des redirects historiques deja en .htaccess (avant migration vers plugin Redirection). (2) Optimisation de chaines de redirects au niveau serveur sur un futur client non-WordPress (Apache/nginx static, headless, ou stack custom). (3) Redirects techniques niveau infra (force HTTPS, www/non-www, trailing slash) qui ne devraient PAS etre dans le plugin WP. (4) Client e-commerce gros volume (Magento/Shopware self-hosted) avec milliers de redirects ou la perf .htaccess devient un sujet vs BDD. Sur les 5 sites actuels (transicio, yuzko, etc.) le cas d'usage est quasi-nul puisque tous les redirects SEO passent par le plugin Redirection (BDD WP), et un tool dedie existe deja pour ca. Contexte requis : Client/site non-WordPress OU site WordPress avec redirects legacy en .htaccess non migres vers le plugin. Acces SSH au serveur (OVH dedie OK). Volume justifiant l'optim chain-collapse: >500 redirects ou chaines >2 hops detectees. Aucun des 5 sites actuels ne remplit ce contexte. Si rejete, reconsiderer si : Reconsiderer si: (1) l'user prend un client non-WordPress (Magento, site statique, headless) avec >1000 redirects en .htaccess/nginx.conf, (2) migration d'un gros site historique e-commerce avec redirects legacy infra non migrables vers un plugin, (3) besoin de redirects niveau infra (HTTPS/www/geoIP) qui doivent rester hors WP, (4) audit revele que des chaines de redirects existent reellement au niveau serveur sur un site du portfolio (a verifier via crawl Screaming Frog / curl). Tant qu'on reste sur du WP avec plugin Redirection, ce tool est hors-scope.
🔴 Faible opportunite ou bloquant technique : envisager le rejet
🔍 Tools existants modestement similaires (max similarite = 0.588)

Probablement different mais a verifier. Lis les docstrings ci-dessous pour confirmer que ce gap apporte vraiment une fonctionnalite nouvelle.

seo_maillage_break_cycle 0.588 seo_action
[ACTION] Casse un cycle de redirects (A->B->A) en disable/delete.
seo_redirect_map 0.567 seo_read
[ANALYZE] Liste toutes les redirections 301/302 d un site avec leur cible et detecte les chaines de redirection. Use when: tu veux auditer les redirections existantes, identifier les chaines (2+ hops
seo_redirect_verify 0.532 seo_read
[WORKFLOW] Verifie qu'un redirect 301/302 est bien en place via HTTP HEAD request. Use when: apres avoir cree une redirection (seo_autopilot_create_301), tu veux confirmer qu'elle est effectivement s
×2 seo_url_watchlist_create rejected 1ere demande 2026-05-04 · derniere 2026-05-04 17:37
Devrait faire : Cree une watchlist persistante d URLs a surveiller avec : (a) check periodique du statut indexation GSC (Coverage), (b) monitoring HTTP status (detection 4XX/5XX), (c) capture baseline crawl stats J0 + comparaison J+N, (d) alerte email/notification configurable sur changement de statut. Le tool genere aussi un dashboard agrege consultable via seo_url_watchlist_report.
Pourquoi les tools existants ne suffisent pas : seo_set_alert prend une condition+threshold globale au site, pas une liste d URLs ciblees avec codes HTTP specifiques. seo_indexation_check est one-shot. seo_crawl_errors liste les erreurs existantes sans creer un suivi nomme avec baseline figee. Aucun tool ne capture une baseline crawl budget pour comparaison differee.
Signature suggeree :
{"name": "post_correction_redirects_oct2025", "site": "transicio", "urls": ["https://transicio.com/cas/url1", "..."], "checks": ["gsc_coverage", "http_status", "url_inspection"], "alert_on": ["4xx", "5xx", "deindexed"], "alert_channel": "email", "baseline_capture": true, "inspection_frequency": "weekly", "comparison_horizon_days": 30}
Notes triage : [2026-05-04 17:55 · ui] 👎 Rejete
Tasks qui ont demande ce tool :
#4 Configuration monitoring post-correction
- #4 Configuration monitoring post-correction
🎯 Analyse opportunite : non encore generee

Ce gap n a pas ete analyse (cree avant l ajout de cette fonctionnalite). Lancer l analyse maintenant (cout : ~$0.04, latence ~5s).

🔍 Tools existants modestement similaires (max similarite = 0.612)

Probablement different mais a verifier. Lis les docstrings ci-dessous pour confirmer que ce gap apporte vraiment une fonctionnalite nouvelle.

seo_autopilot_submit_gsc_now 0.612 seo_action
[WORKFLOW] Drain IMMEDIAT de la queue gsc_index_queue : appelle directement Google Indexing API pour notifier Google sans attendre le cron daily de 02h00. Use when: tu viens de modifier ou publier de
seo_set_alert 0.596 seo_read
[ADMIN] Cree une alerte SEO personnalisee declenchee quand une condition atteint un seuil. Use when: tu veux etre notifie automatiquement si clicks chutent de X%, impressions passent sous Y, ou CTR d
seo_watchlist_add 0.592 seo_read
[WRITE] Ajoute un keyword a la watchlist SEO pour suivi hebdomadaire DFS. Use when: tu veux tracker un mot-cle strategique et recevoir des donnees DFS regulieres. DO NOT use: - pour analyser les ke
×1 seo_gsc_dashboard_custom rejected 1ere demande 2026-05-04 · derniere 2026-05-04 17:37
Devrait faire : Genere un dashboard GSC custom (HTML ou URL partageable) scope sur une liste d URLs avec Coverage Report, Crawl Stats et URL Inspection automatique sur un echantillon. Refresh hebdomadaire automatique.
Pourquoi les tools existants ne suffisent pas : seo_generate_pdf_report_html genere un rapport global, pas un dashboard scope sur URLs custom avec refresh recurrent.
Signature suggeree :
{"site": "transicio", "urls": [], "cadence": "weekly", "widgets": ["coverage", "crawl_stats", "url_inspection_sample"], "sample_size": 3}
Notes triage : [2026-05-04 17:55 · ui] 👎 Rejete
Tasks qui ont demande ce tool :
#4 Configuration monitoring post-correction
🎯 Analyse opportunite : non encore generee

Ce gap n a pas ete analyse (cree avant l ajout de cette fonctionnalite). Lancer l analyse maintenant (cout : ~$0.04, latence ~5s).

🔍 Tools existants modestement similaires (max similarite = 0.615)

Probablement different mais a verifier. Lis les docstrings ci-dessous pour confirmer que ce gap apporte vraiment une fonctionnalite nouvelle.

seo_autopilot_submit_gsc_now 0.615 seo_action
[WORKFLOW] Drain IMMEDIAT de la queue gsc_index_queue : appelle directement Google Indexing API pour notifier Google sans attendre le cron daily de 02h00. Use when: tu viens de modifier ou publier de
seo_indexation_status_audit 0.584 seo_read
[ANALYZE] Distribution des pages par statut d'indexation Google (Submitted&indexed, Crawled-not-indexed, Discovered-not-indexed, Duplicate). Use when: tu veux comprendre pourquoi certaines pages ne s
seo_autopilot_submit_gsc 0.579 seo_action
[WORKFLOW] Soumet une URL a Google Search Console via la queue d'indexation gsc_index_queue. Use when: tu veux demander a Google de re-crawler une page apres modification ou publication. DO NOT use: