OpenClaw

Publier des Comptes Rendus avec OpenClaw : Cas Réel DevOps

Shinpei transformait ses réunions Google Meet en notes éparses. Aujourd’hui : sync GitHub, scan toutes les 5 min, suppression auto. Setup OpenClaw + analyse critique.

La Pince

24 mai 2026 — 5 min de lecture

Bon dimanche ! ☕

Aujourd'hui, on regarde un cas très concret de knowledge ops : transformer des réunions Google Meet en comptes rendus publics, versionnés et surveillés. Ce n'est pas le cas le plus spectaculaire visuellement, mais il est intéressant parce qu'il touche à un vrai problème d'équipe : garder une trace utile sans exposer ce qui doit rester privé.

🎯 Le Cas : Comptes Rendus GitHub Automatisés

Auteur : shinogw
Contexte : mainteneur d'un dépôt public de comptes rendus générés automatiquement par un système OpenClaw, avec synchronisation depuis un workspace privé.
Objectif : publier des notes de réunion exploitables sur GitHub tout en filtrant les informations personnelles, financières ou stratégiques avant exposition publique.

📖 L'Histoire

Le problème de départ est familier : les réunions produisent beaucoup de signal, mais ce signal disparaît vite. Les transcriptions Google Meet existent, les notes Gemini peuvent structurer une discussion, et GitHub est pratique pour conserver un historique. Mais entre ces trois briques, il reste une zone dangereuse : copier-coller à la main, oublier une réunion, ou publier trop vite une information qui n'aurait jamais dû sortir.

Le dépôt openclaw-meeting-minutes montre une réponse assez directe. Le README décrit une chaîne automatisée : fin de réunion Google Meet, sauvegarde de la transcription dans Google Drive, surveillance par Google Apps Script toutes les 5 minutes, webhook vers un traitement Gemini, puis sauvegarde GitHub et intégration mémoire. Le dépôt public ne contient donc pas seulement des notes : il documente aussi la mécanique de publication.

Ce qui rend le cas intéressant, c'est l'itération visible autour de la sécurité. Les scripts ne se contentent pas de synchroniser des fichiers. Ils ajoutent un filtre de confidentialité, un moniteur Python, des suppressions d'urgence et un log JSON. On voit même, dans monitor-log.json, un scan du 23 mai 2026 qui détecte 7 fichiers, classe plusieurs éléments en risque critique, et supprime automatiquement 6 fichiers. C'est un résultat mesurable, mais aussi un avertissement : automatiser la publication de comptes rendus sans garde-fous est risqué.

La solution finale ressemble donc à un pipeline de publication avec ceinture et bretelles. OpenClaw orchestre le système de notes et de mémoire ; les scripts locaux font le tri opérationnel ; GitHub sert de journal public. Le compromis est clair : accepter une complexité DevOps supplémentaire pour ne pas transformer une automatisation utile en fuite d'information.

🔧 Le Setup Technique

Architecture Agent

Schéma conceptuel :

Google Meet
  └─ transcription sauvegardée dans Google Drive
      └─ Google Apps Script surveille toutes les 5 minutes
          └─ webhook vers traitement Gemini / OpenClaw
              └─ workspace privé company-knowledge
                  └─ sync contrôlée vers dépôt public GitHub
                      ├─ filtre shell de confidentialité
                      ├─ masking des noms, montants, lieux, actifs
                      ├─ monitor Python + alertes Discord optionnelles
                      └─ commit/push automatique si le contenu est publiable

Le point important : le dépôt public n'est pas la source de vérité brute. La source privée vit dans un workspace OpenClaw, puis une copie filtrée est publiée. Cette séparation est saine : elle permet de conserver la mémoire complète côté privé, tout en n'exposant que des extraits assumés.

Fichiers Clés

README.md

## 自動化システム
1. Google Meet会議終了
2. Google Drive文字起こし自動保存
3. Google Apps Script 5分間隔監視
4. Webhook → Gemini構造化
5. GitHub自動保存・Memory格納

auto-sync-cron.sh

python3 confidential-monitor.py scan
rsync -av --exclude="archive/" \
  /Users/.../.openclaw/workspace/company-knowledge/Operations/meetings/daily/ \
  ./daily/

find ./daily -name "*.md" -type f -newer .last-sync | while read file; do
  if ! ./confidential-filter.sh "$file"; then
    rm -f "$file"
    continue
  fi
  # masking puis git commit/push
done

confidential-filter.sh

CONFIDENTIAL_PATTERNS=(
  "人事.*再編"
  "関係解消"
  "手切れ金"
  "退職金"
  "戦略会議"
  "機密情報注意"
)

confidential-monitor.py

self.confidential_patterns = {
    "names": [...],
    "financial": [r"\\d+万円", r"\\d+億円", ...],
    "strategic": [r"関係解消", r"人事再編", ...],
    "dates": [r"meeting_2026-03-09", r"2026-03-09"]
}

Étapes de Mise en Place

Créer deux espaces distincts : un dépôt privé pour les transcriptions complètes, un dépôt public pour les notes filtrées.

mkdir -p company-knowledge/Operations/meetings/daily
mkdir -p openclaw-public-meetings/daily

Connecter Google Meet et Google Drive pour produire automatiquement les transcriptions, puis déclencher un webhook de structuration via Google Apps Script.

Meet terminé → transcript Drive → Apps Script polling 5 min → webhook agent

Demander à l'agent OpenClaw de structurer chaque réunion dans un format Markdown stable.

Structure cette transcription en compte rendu public :
- décisions
- actions à suivre
- risques
- contexte technique
N'inclus aucune donnée personnelle, financière ou contractuelle.

Synchroniser uniquement les fichiers récents depuis le workspace privé vers le dépôt public.

rsync -av --exclude="archive/" "$PRIVATE_PATH/daily/" "$PUBLIC_PATH/daily/"

Exécuter le filtre de confidentialité avant tout commit.

./confidential-filter.sh daily/meeting_2026-03-08.md
python3 confidential-monitor.py scan

Publier seulement si le dépôt contient des changements propres.

git status --porcelain
git add .
git commit -m "meeting minutes auto update"
git push origin main

📊 Les Résultats

Gains mesurés :

Surveillance annoncée toutes les 5 minutes via Google Apps Script, puis scan local dans le pipeline.
7 fichiers détectés dans un scan du 23 mai 2026 ; 6 fichiers supprimés automatiquement car classés critiques dans monitor-log.json.
Un dépôt public GitHub maintenu comme archive versionnée, avec README, scripts de sync, filtre, moniteur et log d'audit.
Une chaîne complète documentée : Google Meet, Drive, Apps Script, Gemini, OpenClaw memory, GitHub.

Limites rencontrées :

Le dépôt public montre surtout la couche de publication ; le prompt OpenClaw exact et le Google Apps Script ne sont pas publiés.
Les règles de masking sont très spécifiques au contexte japonais du dépôt et doivent être adaptées avant réutilisation.
La présence de suppressions automatiques montre que la première version du pipeline a laissé passer des fichiers sensibles : le garde-fou a été ajouté parce que le risque était réel.

🧐 Analyse Critique

✅ Ce qui est bien fait

La séparation privé/public est le bon réflexe. Le dépôt public n'essaie pas d'être la mémoire complète de l'organisation. Il devient une projection filtrée, ce qui limite les dégâts en cas d'erreur.
Le pipeline est observable. Les fichiers monitor-log.json et deletion-log.txt transforment la sécurité en artefact auditable, pas en promesse vague.
Les critères de suppression sont explicites. Les mots-clés sensibles, catégories de risque et actions automatiques sont lisibles dans les scripts. Un lecteur peut les critiquer, les étendre ou les remplacer.

⚠️ Points d'attention

Le masking par regex reste fragile. Il couvre les motifs connus, mais rate facilement les formulations nouvelles, les initiales, les captures d'écran ou les données structurées mal nommées.
La suppression après coup n'annule pas une exposition publique. Si un fichier sensible est poussé sur GitHub, il peut rester dans l'historique, les clones, les caches ou les notifications.
Le système mélange publication et remédiation. Idéalement, le scan bloque avant commit. Ici, certains scripts suppriment et poussent après détection, ce qui est utile en urgence mais moins propre qu'une porte de validation stricte.

💡 Améliorations possibles

Ajouter un mode quarantine : tout fichier nouveau passe d'abord dans pending/, puis seulement les fichiers validés arrivent dans daily/.
Remplacer une partie des regex par une étape de classification structurée : public, internal, confidential, avec justification et score.
Ajouter un test CI qui échoue si un fichier Markdown contient un motif sensible avant merge ou push public.
Versionner un template de prompt OpenClaw dédié aux comptes rendus publics, avec interdiction explicite de publier noms, montants, décisions RH et détails contractuels.

🎓 Ce qu'on en retient

Leçons clés :

Publier automatiquement des comptes rendus n'est pas un problème de résumé : c'est un problème de gouvernance de l'information.
Un agent utile doit produire des fichiers, mais aussi des logs, des critères d'arrêt et des preuves de filtrage.
Pour les workflows OpenClaw exposés publiquement, la meilleure architecture commence par une frontière nette entre mémoire privée et projection publique.

Pour aller plus loin :

À dimanche prochain pour un nouveau cas ! 🦞