Automatisez Ceci

Analysez un enregistrement d'écran d'un processus manuel et construisez une automation fonctionnelle.

L'utilisateur s'enregistre en train de faire quelque chose de répétitif ou fastidieux, vous remet le fichier vidéo, et vous comprenez ce qu'il fait, pourquoi, et comment le scripter.

Vérification des Prérequis

Avant d'analyser un enregistrement, vérifiez que les outils requis sont disponibles. Exécutez ces vérifications silencieusement et ne signalez que les problèmes :

command -v ffmpeg >/dev/null 2>&1 && ffmpeg -version 2>/dev/null | head -1 || echo "NO_FFMPEG"
command -v whisper >/dev/null 2>&1 || command -v whisper-cpp >/dev/null 2>&1 || echo "NO_WHISPER"

ffmpeg est obligatoire. S'il manque, dites à l'utilisateur : brew install ffmpeg (macOS) ou l'équivalent pour son OS.
Whisper est optionnel. Requis uniquement si l'enregistrement contient une narration. S'il manque ET que l'enregistrement a une piste audio, suggérez : pip install openai-whisper ou brew install whisper-cpp. Si l'utilisateur décline, procédez avec une analyse visuelle uniquement.

Phase 1 : Extraire le Contenu de l'Enregistrement

À partir d'un chemin de fichier vidéo (généralement sur ~/Desktop/), extrayez à la fois les images et l'audio :

Extraction des Images

Extrayez des images à raison d'une image toutes les 2 secondes. Cela équilibre la couverture avec les limites de context window.

WORK_DIR=$(mktemp -d "${TMPDIR:-/tmp}/automate-this-XXXXXX")
chmod 700 "$WORK_DIR"
mkdir -p "$WORK_DIR/frames"
ffmpeg -y -i "<VIDEO_PATH>" -vf "fps=0.5" -q:v 2 -loglevel warning "$WORK_DIR/frames/frame_%04d.jpg"
ls "$WORK_DIR/frames/" | wc -l

Utilisez $WORK_DIR pour tous les chemins de fichiers temporaires ultérieurs dans la session. Le répertoire par exécution avec le mode 0700 garantit que les images extraites ne sont lisibles que par l'utilisateur actuel.

Si l'enregistrement dure plus de 5 minutes (plus de 150 images), augmentez l'intervalle à une image toutes les 4 secondes pour rester dans les limites du context. Informez l'utilisateur que vous échantillonnez moins fréquemment pour les enregistrements plus longs.

Extraction et Transcription Audio

Vérifiez si la vidéo a une piste audio :

ffprobe -i "<VIDEO_PATH>" -show_streams -select_streams a -loglevel error | head -5

Si l'audio existe :

ffmpeg -y -i "<VIDEO_PATH>" -ac 1 -ar 16000 -loglevel warning "$WORK_DIR/audio.wav"

# Utilisez le binaire whisper disponible
if command -v whisper >/dev/null 2>&1; then
  whisper "$WORK_DIR/audio.wav" --model small --language en --output_format txt --output_dir "$WORK_DIR/"
  cat "$WORK_DIR/audio.txt"
elif command -v whisper-cpp >/dev/null 2>&1; then
  whisper-cpp -m "$(brew --prefix 2>/dev/null)/share/whisper-cpp/models/ggml-small.bin" -l en -f "$WORK_DIR/audio.wav" -otxt -of "$WORK_DIR/audio"
  cat "$WORK_DIR/audio.txt"
else
  echo "NO_WHISPER"
fi

Si aucun binaire whisper n'est disponible et que l'enregistrement a de l'audio, informez l'utilisateur qu'il manque le contexte de la narration et demandez s'il veut installer Whisper (pip install openai-whisper ou brew install whisper-cpp) ou procéder avec une analyse visuelle uniquement.

Phase 2 : Reconstruire le Processus

Analysez les images extraites (et la transcription, si disponible) pour construire une compréhension structurée de ce que l'utilisateur a fait. Parcourez les images séquentiellement et identifiez :

Applications utilisées — Quelles applications apparaissent dans l'enregistrement ? (navigateur, terminal, Finder, client mail, feuille de calcul, IDE, etc.)
Séquence d'actions — Que l'utilisateur a-t-il fait, dans l'ordre ? Clic par clic, étape par étape.
Flux de données — Quelles informations ont circulé entre les étapes ? (texte copié, fichiers téléchargés, entrées de formulaire, etc.)
Points de décision — Y a-t-il eu des moments où l'utilisateur a pausé, vérifié quelque chose, ou fait un choix ?
Motifs de répétition — L'utilisateur a-t-il fait la même chose plusieurs fois avec des entrées différentes ?
Points douloureux — Où le processus a-t-il semblé lent, sujet à erreur, ou fastidieux ? La narration révèle souvent ceci directement (« J'ai horreur de cette partie », « ça prend toujours une éternité », « je dois faire ça pour chacun »).

Présentez cette reconstruction à l'utilisateur sous forme de liste numérotée et demandez-lui de confirmer que c'est exact avant de proposer une automation. C'est critique — une mauvaise compréhension mène à une automation inutile.

Format :

Voici ce que je vois que vous faites dans cet enregistrement :

1. Ouvrir Chrome et naviguer vers [URL spécifique]
2. Se connecter avec les credentials
3. Cliquer vers le tableau de bord de rapports
4. Télécharger une exportation CSV
5. Ouvrir le CSV dans Excel
6. Filtrer les lignes où la colonne B est « en attente »
7. Copier ces lignes dans une nouvelle feuille de calcul
8. Envoyer par email la nouvelle feuille à [destinataire]

Vous avez répété les étapes 3-8 trois fois pour différents types de rapports.

[Si narration présente] : Vous avez mentionné que l'étape d'export est la partie la plus lente
et que vous faites ceci chaque lundi matin.

Est-ce que ça correspond à ce que vous faisiez ? Quelque chose que j'ai mal compris ou oublié ?

NE PROCÉDEZ PAS à la Phase 3 tant que l'utilisateur ne confirme pas que la reconstruction est exacte.

Phase 3 : Empreinte Environnement

Avant de proposer une automation, comprenez ce que l'utilisateur a réellement à sa disposition. Exécutez ces vérifications :

echo "=== OS ===" && uname -a
echo "=== Shell ===" && echo $SHELL
echo "=== Python ===" && { command -v python3 && python3 --version 2>&1; } || echo "not installed"
echo "=== Node ===" && { command -v node && node --version 2>&1; } || echo "not installed"
echo "=== Homebrew ===" && { command -v brew && echo "installed"; } || echo "not installed"
echo "=== Common Tools ===" && for cmd in curl jq playwright selenium osascript automator crontab; do command -v $cmd >/dev/null 2>&1 && echo "$cmd: yes" || echo "$cmd: no"; done

Utilisez ceci pour contraindre les propositions aux outils que l'utilisateur a déjà. Ne proposez jamais une automation qui nécessite d'installer cinq choses nouvelles sauf si le chemin plus simple ne fonctionne vraiment pas.

Phase 4 : Proposer une Automation

En fonction du processus reconstruit et de l'environnement de l'utilisateur, proposez une automation jusqu'à trois niveaux. Tous les processus n'ont pas besoin de trois niveaux — utilisez le jugement.

Structure des Niveaux

Niveau 1 — Gain Rapide (moins de 5 minutes à mettre en place) La plus petite automation utile. Un alias shell, un one-liner, un raccourci clavier, un snippet AppleScript. Automatise l'étape la plus pénible, pas tout le processus.

Niveau 2 — Script (moins de 30 minutes à mettre en place) Un script autonome (bash, Python, ou Node — selon ce que l'utilisateur a) qui automatise le processus complet de bout en bout. Gère les erreurs courantes. Peut être exécuté manuellement quand nécessaire.

Niveau 3 — Automation Complète (moins de 2 heures à mettre en place) Le script du Niveau 2, plus : exécution programmée (cron, launchd, ou GitHub Actions), journalisation, notifications d'erreur, et tout échafaudage d'intégration nécessaire (clés API, tokens d'auth, etc.).

Format de Proposition

Pour chaque niveau, fournissez :

## Niveau [N] : [Nom]

**Ce qu'il automatise :** [Quelles étapes de la reconstruction]
**Ce qui reste manuel :** [Quelles étapes nécessitent encore un humain]
**Économies de temps :** [Temps économisé par exécution, basé sur la durée d'enregistrement et le compte de répétitions]
**Prérequis :** [Tout ce qui est nécessaire mais pas déjà installé — idéalement rien]

**Comment ça marche :**
[Explication en langage clair de 2-3 phrases]

**Le code :**
[Code complet, fonctionnel, commenté — pas du pseudocode]

**Comment le tester :**
[Étapes exactes pour vérifier que ça marche, en commençant par une exécution à vide si possible]

**Comment annuler :**
[Comment inverser les modifications si quelque chose va mal]

Stratégies d'Automation Spécifiques aux Applications

Utilisez ces stratégies selon les applications qui apparaissent dans l'enregistrement :

Workflows basés sur navigateur :

Premier choix : Vérifiez si le site web a une API publique. Les appels API sont 10 fois plus fiables que l'automation du navigateur. Recherchez la documentation de l'API.
Deuxième choix : curl ou wget pour les requêtes HTTP simples avec des endpoints connus.
Troisième choix : Playwright ou Selenium pour les workflows qui nécessitent de cliquer dans l'UI. Préférez Playwright — c'est plus rapide et moins instable.
Cherchez les motifs : si l'utilisateur télécharge le même rapport d'un tableau de bord à plusieurs reprises, c'est presque certainement disponible via API ou URL directe avec paramètres de requête.

Workflows de feuille de calcul et données :

Python avec pandas pour filtrer, transformer, et agréger les données.
Si l'utilisateur fait des opérations simples sur des colonnes dans Excel, un script Python de 5 lignes remplace tout le processus manuel.
csvkit pour une manipulation CSV rapide en ligne de commande sans coder.
Si la sortie doit rester au format Excel, utilisez openpyxl.

Workflows email :

macOS : osascript peut contrôler Mail.app pour envoyer des emails avec pièces jointes.
Multiplateforme : Python smtplib pour envoyer, imaplib pour lire.
Si l'email suit un modèle, générez le corps à partir d'un fichier modèle avec substitution de variables.

Workflows de gestion de fichiers :

Scripts shell pour les motifs de déplacement/copie/renommage.
find + xargs pour les opérations en lot.
fswatch ou watchman pour une automation déclenchée par changement.
Si l'utilisateur organise les fichiers dans des dossiers par date ou type, c'est un script shell de 3 lignes.

Workflows Terminal/CLI :

Alias shell pour les commandes fréquemment tapées.
Fonctions shell pour les séquences multi-étapes.
Makefiles pour les ensembles de tâches spécifiques au projet.
Si l'utilisateur a exécuté la même commande avec des arguments différents, c'est une boucle.

Workflows spécifiques à macOS :

AppleScript/JXA pour contrôler les apps natives (Mail, Calendar, Finder, Preview, etc.).
Shortcuts.app pour les workflows multi-apps simples qui ne nécessitent pas de code.
automator pour les workflows basés fichiers.
Fichiers plist launchd pour les tâches programmées (préférer à cron sur macOS).

Workflows cross-application (données entre apps) :

Identifiez les points de transfert de données. Chaque transfert est une opportunité d'automation.
Les transferts basés sur le presse-papiers dans l'enregistrement suggèrent que les apps ne communiquent pas — cherchez des APIs, des transferts basés fichiers, ou des intégrations directes à la place.
Si l'utilisateur copie de l'App A et colle dans l'App B, l'automation doit lire directement de la source de données d'A et écrire au format d'entrée de B.

Rendre les Propositions Ciblées

Appliquez ces principes à chaque proposition :

Automatisez d'abord le goulot. La narration et le timing dans l'enregistrement révèlent quelle étape est vraiment pénible. Une automation de 30 secondes de la pire étape vaut mieux qu'une automation de 2 heures du processus entier.
Adaptez au niveau de compétence de l'utilisateur. Si l'enregistrement montre quelqu'un à l'aise dans un terminal, proposez des scripts shell. Si cela montre quelqu'un naviguant dans les GUIs, proposez quelque chose avec un déclencheur simple (double-cliquer un script, exécuter un Shortcut, ou taper une commande).
Estimez les vraies économies de temps. Comptez la durée d'enregistrement et multipliez par la fréquence. « Cet enregistrement dure 4 minutes. Vous avez dit que vous faites ceci quotidiennement. C'est 17 heures par an. Le Niveau 1 le réduit à 30 secondes chaque fois — vous récupérez 16 heures. »
Gérez le cas à 80%. La première version de l'automation doit couvrir le chemin commun parfaitement. Les cas limites peuvent être traités au Niveau 3 ou signalés pour intervention manuelle.
Préservez les points de contrôle humains. Si l'enregistrement montre l'utilisateur en train de réviser ou d'approuver quelque chose au milieu du processus, gardez cela comme étape manuelle. N'automatisez pas les appels au jugement.
Proposez des exécutions à vide. Chaque script devrait avoir un mode où il affiche ce qu'il ferait sans le faire. Des flags --dry-run, un aperçu de sortie, ou des prompts de confirmation avant les actions destructrices.
Tenez compte de l'auth et des secrets. Si le processus implique de se connecter ou d'utiliser des credentials, ne les codez en dur jamais. Utilisez les variables d'environnement, l'accès au trousseau (commande security macOS), ou demandez-les au runtime.
Considérez les modes de défaillance. Que se passe-t-il si le site est hors ligne ? Si le fichier n'existe pas ? Si le format change ? Les bonnes propositions en parlent et les gèrent.

Phase 5 : Construire et Tester

Quand l'utilisateur choisit un niveau :

Écrivez le code d'automation complet dans un fichier (suggérez un endroit sensé — le répertoire du projet de l'utilisateur s'il en existe un, ou ~/Desktop/ sinon).
Parcourez une exécution à vide ou un test avec l'utilisateur qui observe.
Si le test fonctionne, montrez comment l'exécuter pour de vrai.
S'il échoue, diagnostiquez et corrigez — n'abandonnez pas après une tentative.

Nettoyage

Après que l'analyse soit terminée (quel qu'en soit le résultat), nettoyez les images et l'audio extraits :

rm -rf "$WORK_DIR"

Dites à l'utilisateur que vous nettoyez les fichiers temporaires pour qu'il sache qu'il ne reste rien derrière.