Activité du Site

Interrogez, analysez et résumez les logs d'activité du site Webflow pour les sites d'entreprise. Permet l'interrogation en langage naturel des modifications récentes, des résumés filtrés par type d'événement ou utilisateur, et des rapports formatés à partager avec l'équipe.

Note Importante

UTILISEZ TOUJOURS les outils Webflow MCP pour toutes les opérations :

Utilisez data_sites_tool de Webflow MCP avec l'action list_sites pour lister les sites disponibles
Utilisez data_sites_tool de Webflow MCP avec l'action get_site pour les informations détaillées du site
Utilisez data_enterprise_tool de Webflow MCP avec l'action list_site_activity_logs pour récupérer les événements du log d'activité
Utilisez webflow_guide_tool pour connaître les bonnes pratiques avant de commencer
NE UTILISEZ PAS d'autres outils ou méthodes pour les opérations Webflow
Tous les appels d'outils doivent inclure le paramètre context requis (15-25 mots, perspective à la troisième personne)

Entreprise uniquement : Les logs d'activité ne sont disponibles que pour les sites sur les plans d'hébergement Entreprise. Si l'outil retourne une erreur, informez l'utilisateur que cette fonctionnalité nécessite un plan Entreprise.

Paramètres de l'outil pour list_site_activity_logs :

site_id (requis) : L'identifiant unique du site
limit (optionnel) : Nombre maximum d'enregistrements à retourner (max 100)
offset (optionnel) : Décalage de pagination pour récupérer au-delà de la première page

Instructions

Phase 1 : Sélection du Site et Contexte

Identifier le site cible : Si l'utilisateur ne fournit pas d'ID de site, utilisez data_sites_tool avec l'action list_sites. Chaque site dans la réponse contient displayName, lastPublished, et lastUpdated.

Ordre de tri :
1. ⚠️ sites (changements non publiés) avant ✅ sites (à jour)
2. Dans chaque groupe, les plus récemment mis à jour en premier (par lastUpdated décroissant)
Troncature : Afficher les 10 premiers sites uniquement. S'il y a plus de 10 sites au total, ajouter une ligne …et N autres sites. Répondez « afficher tout » pour voir le reste. sous la liste. Quand l'utilisateur répond « afficher tout » (ou similaire), réafficher la liste complète dans le même format.

Présenter la liste dans ce format exact :
```
 📋 Activité du Site — Sélection du Site

 Sites Entreprise Disponibles :

 1. <Nom du Site> ⚠️  — dernière publication <date courte>, mise à jour <date courte> (<N> jours non publiés)
 2. <Nom du Site> ✅  — publié et mis à jour <date courte>
 3. <Nom du Site> ⚠️  — jamais publié, mise à jour <date courte>

 …et 4 autres sites. Répondez « afficher tout » pour voir le reste.

 Quel site souhaitez-vous examiner ?
```
Règles de formatage :
- Dates : abrégées (« 6 mar », « 14 avr »). Ajouter l'année uniquement si ce n'est pas l'année en cours.
- Utiliser ⚠️ quand lastUpdated > lastPublished OU lastPublished est null ; ✅ quand lastUpdated <= lastPublished.
- Quand lastPublished == lastUpdated, réduire le côté droit à « publié et mis à jour <date> ».
- Omettre la ligne « …et N autres sites » quand l'espace de travail a 10 sites ou moins.
- Ne pas omettre le drapeau de statut ou les dates — ils sont requis pour chaque site.
Récupérer les détails du site sélectionné : Après que l'utilisateur sélectionne un site (ou quand un ID de site a été fourni d'emblée), appelez data_sites_tool avec l'action get_site une seule fois, pour le site sélectionné uniquement, pour récupérer les champs non retournés par list_sites — en particulier :
- Domaines personnalisés
- Paramètres de localisation / localisation
- Toutes les métadonnées du site supplémentaires nécessaires pour l'analyse
lastPublished et lastUpdated sont déjà connus à partir de l'étape 1 (ou de get_site si l'utilisateur a fourni un ID de site directement). Garder ces informations en mémoire pour le filtre de pré-publication dans la Phase 3.
Déduire l'intention du message (ne pas poser de question de suivi si le message est clair). Mapper la demande à l'une des catégories suivantes :
- Résumé de l'activité récente (« qu'est-ce qui a changé cette semaine ? »)
- Activité d'un utilisateur spécifique (« qu'a changé Sarah ? »)
- Type d'activité spécifique (« des modifications CMS récemment ? »)
- Examen de pré-publication (« qu'est-ce qui a changé depuis la dernière publication ? »)
- Vue d'ensemble générale (par défaut quand le message est ambigu)
Ne poser une question de clarification que si la demande est véritablement ambiguë (par exemple, « affiche-moi l'activité » sans fenêtre de temps, utilisateur ou contexte de type d'événement).

Phase 2 : Récupération des Logs d'Activité

Récupérer les logs d'activité : Utilisez list_site_activity_logs avec l'ID du site
- Par défaut limit: 100 (maximum par requête) pour des résultats complets
- L'API retourne les événements dans l'ordre antéchronologique (plus récents en premier)
Gérer la pagination : Si l'utilisateur a besoin d'une activité plus ancienne ou si les résultats suggèrent l'existence de plus de données :
- Utiliser le paramètre offset pour récupérer des pages supplémentaires
- Combiner les résultats entre les pages pour l'analyse
- Avertir l'utilisateur si on remonte plus loin que les données disponibles

Phase 3 : Analyse et Résumé

Analyser chaque entrée de log d'activité : Chaque événement contient :
- id : Identifiant unique de l'événement
- createdOn : Horodatage (ISO 8601)
- lastUpdated : Horodatage de la dernière mise à jour
- event : Chaîne de type d'événement (voir Types d'Événements ci-dessous)
- user : Objet avec id et displayName (absent pour les événements système comme les sauvegardes)
- resourceOperation : L'opération effectuée (CREATED, MODIFIED, DELETED)
- resourceId : ID de la ressource affectée (le cas échéant)
- resourceName : Nom lisible de la ressource affectée
- payload : Détails supplémentaires spécifiques à l'événement (voir Détails du Payload ci-dessous)
Catégoriser les événements en groupes lisibles (41 types d'événements) :

Modifications de Pages :
- page_dom_modified — Modifications de structure/éléments de page
- page_created — Création de nouvelle page
- page_deleted — Suppression de page
- page_duplicated — Duplication de page
- page_renamed — Renommage de page
- page_settings_modified — Mises à jour des paramètres de page (SEO, slug, etc.)
- page_custom_code_modified — Modifications du code personnalisé au niveau de la page
- page_settings_custom_code_modified — Modifications du code personnalisé des paramètres de page
Modifications de Styles et Variables :
- styles_modified — Modifications de styles/classes
- variable_modified — Changement d'une seule variable
- variables_modified — Changements de plusieurs variables
Modifications de Composants :
- symbols_modified — Composant/symbole créé, modifié ou supprimé
Interactions :
- ix2_modified_on_page — Changements d'interaction sur une page
- ix2_modified_on_component — Changements d'interaction sur un composant
- ix2_modified_on_class — Changements d'interaction sur une classe
Modifications CMS :
- cms_item — Élément de collection créé, modifié ou supprimé
- cms_collection — Schéma de collection créé, modifié ou supprimé
Gestion du Site :
- site_published — Site publié
- site_unpublished — Site non publié
- site_custom_code_modified — Modifications du code personnalisé au niveau du site
- backup_created — Sauvegarde automatique ou manuelle
- backup_restored — Sauvegarde restaurée
Localisation :
- secondary_locale_page_content_modified — Contenu de page localisé modifié
- locale_added — Nouvelle locale ajoutée
- locale_removed — Locale supprimée
- locale_enabled — Locale activée
- locale_disabled — Locale désactivée
- locale_display_name_updated — Nom d'affichage de locale modifié
- locale_subdirectory_updated — Sous-répertoire de locale modifié
- locale_tag_updated — Balise de locale modifiée
Branches :
- branch_created — Branche créée
- branch_merged — Branche fusionnée
- branch_deleted — Branche supprimée
- branch_review_created — Examen de branche demandé
- branch_review_approved — Examen de branche approuvé
- branch_review_canceled — Examen de branche annulé
Bibliothèque :
- library_shared — Bibliothèque partagée avec d'autres sites
- library_unshared — Bibliothèque non partagée
- library_installed — Bibliothèque installée depuis un autre site
- library_uninstalled — Bibliothèque désinstallée
- library_update_shared — Mise à jour de bibliothèque publiée
- library_update_accepted — Mise à jour de bibliothèque acceptée
Remarque : Si un type d'événement non listé ci-dessus apparaît, le catégoriser comme « Autre » et afficher la chaîne event brute.
Appliquer des filtres basés sur la demande de l'utilisateur :
- Par catégorie d'événement (par exemple, uniquement les modifications CMS)
- Par utilisateur (correspondance sur user.displayName)
- Par fenêtre de temps (filtrer les horodatages createdOn côté client)
- Par ressource (correspondance sur resourceName)
- Examen de pré-publication : Quand l'utilisateur veut voir les modifications depuis la dernière publication, utiliser l'horodatage lastPublished du site (de la Phase 1) et filtrer aux événements où createdOn > lastPublished. Si lastPublished est null (jamais publié), tous les événements se qualifient comme non publiés.
Générer des insights (à inclure dans la section Highlights du rapport) :
- Utilisateur le plus actif pendant la période
- Distribution des types d'événements (quelle catégorie a dominé)
- Jour ou heure la plus occupée
- Concentration d'un seul utilisateur (signaler quand une personne a fait 40 %+ des changements)
- Modifications non publiées (décompte des événements où createdOn > lastPublished)

Phase 4 : Rapportage

Générer un rapport récapitulatif avec ces sections :
- Plage de temps couverte et décompte total des événements
- Répartition par type d'activité
- Répartition par utilisateur
- Highlights — mettre en avant les motifs tels que les changements haute fréquence d'une seule page/collection, plusieurs utilisateurs éditant la même ressource, modifications non publiées (depuis la dernière publication), et événements système vs. modifications initiées par l'utilisateur
Répondre à la question spécifique de l'utilisateur : Si l'utilisateur a demandé quelque chose de spécifique, commencer par la réponse directe avant le rapport structuré.
Choisir le niveau de détail à partir du message :
- « comptages uniquement » / « combien » / « juste les chiffres » → Résumé rapide (comptages par catégorie uniquement)
- par défaut → Rapport standard (événements catégorisés avec attribution utilisateur — voir Exemple 1)
- « explique-moi » / « affiche chaque modification » / « chronologie » → Rapport détaillé (vue chronologique par événement avec payload)
- « partage » / « exporte » / « pour mon équipe » / « résumé à envoyer » → Rapport partageable/Export (voir Exemple 3)
Le commutateur de niveau de détail est toujours présenté comme l'une des options de suivi à l'étape 13 pour que l'utilisateur puisse demander un niveau différent.
Toujours terminer chaque rapport avec une section d'options de suivi. C'est obligatoire, pas optionnel. Utiliser le format exact ci-dessous, en adaptant les options numérotées à ce qui est pertinent pour la requête qui vient d'être traitée :
```
---

Souhaitez-vous :
1. Filtrer par un utilisateur spécifique
2. Filtrer par type d'activité
3. Récupérer une activité plus ancienne (pagination)
4. Basculer vers un résumé rapide (comptages uniquement) ou une vue détaillée (payloads par événement)
5. Exporter en markdown ou JSON
```
Si le rapport était dans un format partageable/export (par exemple, « résumé que je peux partager »), placer ce bloc en dehors du contenu partageable pour que l'utilisateur puisse copier le rapport proprement sans le menu de suivi dedans.

Détails du Payload d'Événement

Différents types d'événements incluent différents champs de payload :

page_dom_modified :

pageTitle : Nom de la page modifiée
pageId : ID de la page modifiée
count : Nombre de modifications dans ce lot
branchId/branchName : Contexte de branche (null si principal)

cms_item :

cmsCollectionId : ID de la collection parente
cmsCollectionName : Nom de la collection parente
count : Nombre d'éléments affectés
name : Nom de locale (par exemple, « English », « Spanish »)

styles_modified :

selector : Sélecteur CSS (le cas échéant)
variant : Chaîne de variante de point d'arrêt/pseudo-classe
parentChain : Tableau des noms de styles parents (chaîne de classe combo)
type : Type de style (par exemple, « class »)
branchId/branchName : Contexte de branche

symbols_modified :

branchId/branchName : Contexte de branche

page_settings_modified :

pageTitle : Nom de la page modifiée
branchId/branchName : Contexte de branche

backup_created :

Aucun payload ; resourceName indique le type de sauvegarde (par exemple, « Automatic backup », « Maintenance backup »)
Aucun champ user (système initié)

Exemples

Message de l'utilisateur :

Que s'est-il passé sur mon site cette semaine ?

Étape 1 : Sélection du Site

📋 Activité du Site — Sélection du Site

Sites Entreprise Disponibles :

1. Site Web Acme Corp ⚠️  — dernière publication 14 avr, mise à jour 16 avr (2 jours non publiés)
2. Blog Acme ✅  — publié et mis à jour 10 avr

Quel site souhaitez-vous examiner ?

Étape 2 : Résumé d'Activité

📋 Activité du Site : Site Web Acme Corp
   10-16 avril 2026 (93 événements)

**93 événements cette semaine de 3 membres de l'équipe. 28 ne sont pas publiés depuis la dernière publication le 14 avr.**

---

## Répartition d'Activité

📄 Modifications de pages       34 événements
🎨 Modifications de classes     22 événements
📝 Mises à jour CMS             18 événements
🧩 Modifications de composants   8 événements
🔤 Modifications de variables    5 événements
🚀 Publications                  3 événements
💾 Sauvegardes                   2 événements
🌿 Activité de branche           1 événement

---

## Activité par Utilisateur

**Sarah Chen** — 42 événements
└── Modifications de pages (18), Modifications de classes (15), Mises à jour CMS (9)

**Alex Kim** — 31 événements
└── Mises à jour CMS (9), Modifications de pages (12), Modifications de composants (8), Variables (2)

**Jordan Lee** — 17 événements
└── Modifications de classes (7), Modifications de pages (4), Publications (3), Sauvegardes (2), Branche (1)

**Système** — 3 événements
└── Sauvegardes (auto)

---

## Highlights

- ⚠️ **Modifications non publiées** : 28 événements depuis la dernière publication (14 avr)
- 📊 **Jour le plus occupé** : 15 avril (41 événements)
- 👤 **Plus actif** : Sarah Chen (45 % de toute l'activité)
- 🧩 8 modifications de composants par Alex Kim — pourraient affecter plusieurs pages

---

Souhaitez-vous :
1. Filtrer par un utilisateur spécifique
2. Filtrer par type d'activité
3. Voir les détails des modifications non publiées uniquement
4. Basculer vers un résumé rapide (comptages uniquement) ou une vue détaillée (payloads par événement)
5. Récupérer une activité plus ancienne

Message de l'utilisateur :

Affiche-moi les modifications CMS sur le site 6924868ede9d3fbbc3195eb0

Réponse :

📋 Activité CMS : Site Web Acme Corp
   10-16 avril 2026 (18 événements CMS)

**18 événements CMS de 2 utilisateurs sur 5 jours. 3 modifications ne sont pas publiées.**

---

## Répartition CMS

📝 Éléments modifiés       11 événements
➕ Éléments créés           5 événements
📚 Modifications de collections 2 événements

---

## Activité par Utilisateur

**Sarah Chen** — 10 événements
└── 2 éléments créés, 7 éléments modifiés, 1 collection modifiée

**Alex Kim** — 8 événements
└── 3 éléments créés, 4 éléments modifiés, 1 publication en masse

---

## Highlights

- ⚠️ **Non publiés** : 3 modifications CMS depuis la dernière publication (14 avr)
- 📊 **Jour le plus occupé** : 15 avril (8 événements)
- 📚 **Modifications de schéma** : 2 éditions de collection cette semaine (examiner attentivement avant publication)

---

Souhaitez-vous :
1. Filtrer à une collection spécifique
2. Filtrer par utilisateur (Sarah ou Alex)
3. Voir uniquement les modifications CMS non publiées
4. Basculer vers une vue chronologique (par événement) ou comptages uniquement
5. Récupérer une activité CMS plus ancienne

Message de l'utilisateur :

Donne-moi un résumé hebdomadaire que je peux partager avec mon équipe pour le Site Web Acme Corp

(Nommer le site en ligne saute l'étape 1 de la Phase 1. Si l'utilisateur ne nomme pas de site, lancer la liste de sélection du site avant de produire ce rapport.)

Réponse :

📋 Rapport d'Activité du Site Hebdomadaire
   Site Web Acme Corp — Semaine du 10-16 avril 2026

---

### Vue d'ensemble
- **93 changements au total** entre 3 membres de l'équipe
- **3 publications** (10 avr, 12 avr, 14 avr)
- **28 modifications non publiées** en attente d'examen
- **Dernière publication :** 14 avril à 18:30 UTC

### Qu'est-ce qui a changé
- 34 modifications de pages sur 8 pages
- 22 mises à jour de classes/styles
- 18 modifications de contenu CMS (5 nouveaux éléments, 11 modifications, 2 modifications de schéma)
- 8 mises à jour de composants
- 5 modifications de variables

### Activité de l'Équipe
| Membre de l'Équipe | Modifications | Activité Principale              |
|-----------|---|-----|
| Sarah Chen  | 42      | Éditions de pages, mises à jour de styles     |
| Alex Kim    | 31      | Contenu CMS, composants       |
| Jordan Lee  | 17      | Styles, publications, sauvegardes   |

### Actions à Prendre
- ⚠️ 28 modifications ne sont pas publiées — envisager d'examiner et de publier
- 🧩 8 modifications de composants pourraient affecter les mises en page partagées — vérifier avant publication
- 💾 Dernière sauvegarde : 14 avril — envisager une nouvelle sauvegarde

---
Généré à partir du Log d'Activité du Site Webflow

Souhaitez-vous :

Filtrer les modifications d'un utilisateur spécifique
Détailler les modifications non publiées
Régénérer avec une plage de dates différente
Basculer vers un résumé rapide (comptages uniquement) ou une vue détaillée par événement
Exporter en JSON au lieu de markdown

Directives

Accès Entreprise Uniquement

Exigence de Plan :

list_site_activity_logs est disponible uniquement sur les plans d'hébergement Entreprise

Si l'API retourne une erreur de permissions, informez clairement l'utilisateur :

⚠️ Les Logs d'Activité du Site nécessitent un plan d'hébergement Entreprise.
Ce site n'a pas accès à l'Entreprise.

Ne pas réessayer sur les erreurs de permissions — le problème est au niveau du plan, pas transitoire

Contraintes de l'API

Pagination :

Maximum 100 événements par requête
Utiliser offset pour paginer : premier appel offset=0, deuxième appel offset=100, etc.
100 événements couvrent généralement environ une semaine pour un site entreprise actif
Pas de filtrage natif par date — tous les filtres doivent être effectués côté client après la récupération

Quand paginer :

L'utilisateur demande plus d'une semaine d'activité
L'utilisateur a besoin d'une vue complète et la première page retourne exactement 100 événements
Toujours dire à l'utilisateur la quantité de données dont vous disposez : « Affichage des 93 derniers événements (10-16 avr) »

Conscience des taux :

Éviter les paginations inutiles — récupérer uniquement ce qui est nécessaire pour répondre à la question
Si l'utilisateur demande « des publications récemment ? » — 100 événements sont probablement suffisants
Si l'utilisateur demande « activité de tout un mois » — expliquer la limitation et paginer jusqu'à 300 événements maximum

Gestion des Erreurs

Erreurs courantes :

403 / Accès refusé : Plan Entreprise requis — informer l'utilisateur clairement
404 / Site non trouvé : Vérifier l'ID du site, proposer de lister les sites disponibles
Résultats vides : Le site peut n'avoir aucune activité récente — confirmer avec l'utilisateur et vérifier les détails du site

Dégradation Progressive :

Si la récupération des détails du site échoue, toujours tenter les logs d'activité
Si la pagination échoue en chemin, signaler ce qui a été récupéré avec succès
Toujours afficher les résultats partiels plutôt que rien

webflow-mcp:site-activity

Activité du Site

Note Importante

Instructions

Phase 1 : Sélection du Site et Contexte

Phase 2 : Récupération des Logs d'Activité

Phase 3 : Analyse et Résumé

Phase 4 : Rapportage

Détails du Payload d'Événement

Exemples

Directives

Accès Entreprise Uniquement

Contraintes de l'API

Gestion des Erreurs

Skills similaires