Dayflow : journal de travail automatique sur macOS, et ce que coûte vraiment l'analyse locale
The automatic work journal/time tracker. Privately turns your screen into a timeline of what you actually accomplished. Open-source and local-first.
En bref
- De quoi s’agit-il ?
- Dayflow transforme l'activité écran d'un Mac en une chronologie de travail. Le README décrit une application Swift local-first, sous licence MIT, qui laisse le choix entre modèles locaux et fournisseurs cloud. Voici ce que la documentation permet de vérifier, et ce qu'elle laisse en suspens.
- À qui s’adresse-t-il ?
- Dayflow convient aux développeurs et indépendants sous macOS 14 ou plus récent qui acceptent de stocker un historique d'écran sur leur disque et d'administrer eux-mêmes Ollama, LM Studio ou une clé API. Ceux qui ne peuvent pas accorder la permission Screen & System Audio Recording, ou qui ne veulent aucune analyse d'image, doivent passer leur chemin.
- Puis-je l’utiliser commercialement ?
- Oui. MIT est une licence permissive : vous pouvez utiliser, modifier et vendre un logiciel qui en dépend, à condition de conserver les mentions de droit d’auteur et de licence.
- Est-il encore maintenu ?
- Oui. Les derniers commits datent d’il y a 4 jours.
- En quel langage est-il écrit ?
- Principalement Swift, d’après les statistiques de langage de GitHub.
Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 15 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.
ANALYSE OPEN SOURCE APPROFONDIE
Le problème : deux heures dans Cursor ne disent pas ce que vous avez fait
Les traqueurs de temps classiques enregistrent l'application au premier plan. Le README de Dayflow formule la limite en une phrase : Cursor pendant deux heures peut signifier livrer une fonctionnalité, déboguer l'authentification, relire une pull request ou se perdre dans la configuration. Le projet vise donc un public précis : développeurs, indépendants et petites équipes sur Mac qui doivent reconstituer leur journée sans avoir lancé de minuteur. Le README promet une chronologie, un résumé de standup, une revue hebdomadaire et un export Markdown. Cette ambition a un coût : Dayflow ne peut pas fonctionner sans la permission macOS Screen & System Audio Recording, donc sans accepter que l'application voie l'écran.
Capture d'abord, analyse ensuite : la chaîne décrite dans le README
Le mécanisme tient en trois étapes. Dayflow capture des segments d'écran légers, les fait analyser par le fournisseur d'IA choisi, puis convertit le résultat en cartes d'activité regroupées chronologiquement. La base, les enregistrements et la chronologie restent sur le Mac, dans ~/Library/Application Support/Dayflow/. Le README est explicite sur le point de fuite : si vous choisissez un fournisseur cloud, les données d'activité nécessaires à l'analyse lui sont envoyées. Le choix du backend n'est donc pas un détail de configuration, c'est la frontière de confidentialité du produit. Quatre options sont listées : Ollama, LM Studio, Gemini avec votre propre clé, ou ChatGPT et Claude via leurs outils CLI locaux. Le README ne donne aucune mesure de qualité comparée entre ces backends, et c'est une réserve à garder en tête : la promesse de contexte utile dépend entièrement du modèle que vous branchez.
Installation : DMG, Homebrew, ou compilation dans Xcode
Trois chemins sont documentés. Le premier passe par le fichier Dayflow.dmg publié dans les releases GitHub : on ouvre l'image, on glisse l'application dans Applications, puis on accorde la permission d'enregistrement d'écran. Le second tient en une commande : brew install --cask dayflow. Le troisième s'adresse à ceux qui veulent lire le code avant de l'exécuter :
git clone https://github.com/JerryZLiu/Dayflow.git cd Dayflow open Dayflow/Dayflow.xcodeproj
Il faut alors sélectionner le scheme Dayflow dans Xcode et lancer. Les prérequis annoncés sont macOS 14 ou plus récent, la permission Screen & System Audio Recording, et, selon le backend retenu, une clé API Gemini, Ollama, LM Studio, Codex CLI ou Claude Code. Aucune de ces dépendances n'est optionnelle si vous voulez des résumés : sans fournisseur configuré, la capture seule ne produit pas la chronologie décrite.
Le local-first a une limite que le README ne chiffre pas
Le stockage local est présenté comme un avantage, et il l'est sur le plan du contrôle : vous pouvez supprimer l'historique quand vous voulez. Mais un journal d'écran grossit vite, et le README ne publie aucune estimation de taille par heure ou par jour. Il mentionne une purge automatique avec des limites de stockage configurables, sans nommer la clé de configuration correspondante. C'est la zone la plus floue de la documentation, et elle compte : sur un Mac avec un SSD de 256 Go, la différence entre une semaine et un an de rétention n'est pas anodine. Autre angle mort : le README ne décrit ni la fréquence de capture, ni la résolution des segments, ni ce qui se passe quand la permission est révoquée en cours de journée. Un lecteur qui a besoin de ces chiffres devra les chercher dans le code Swift, pas dans la page d'accueil du dépôt.
Face à un traqueur d'applications classique, la différence est le contenu de l'image
Un outil comme Timing ou RescueTime s'appuie sur l'application active, le titre de fenêtre et l'URL. Dayflow ajoute une couche d'interprétation visuelle : le README insiste sur le fait qu'il regarde ce qui est à l'écran, pas seulement quelle application est au premier plan. La différence est concrète. Un traqueur par application classera deux heures de navigateur comme « navigation », alors que Dayflow vise à distinguer une session de documentation d'une session YouTube. En contrepartie, cette approche exige une permission plus intrusive et un backend d'IA, donc un coût CPU ou monétaire que les traqueurs par titres de fenêtres n'ont pas. Ce n'est pas une amélioration gratuite, c'est un échange : plus de contexte contre plus de ressources et une surface de confidentialité plus large.
Licence MIT et rythme de publication : ce que cela implique pour la maintenance
La licence MIT autorise la modification, la redistribution et l'usage commercial, sans garantie. Concrètement, vous pouvez forker Dayflow et retirer le backend cloud, ou l'intégrer à un outil interne. En contrepartie, aucun mainteneur n'est engagé à corriger quoi que ce soit, et le README ne décrit ni politique de support ni canal de sécurité. Le rythme des versions récentes est serré : v2.2.0 le 3 septembre 2026, v2.4.0 le 7 septembre, v2.4.2 le 9 septembre. Cette cadence suggère un projet actif, mais elle implique aussi des mises à jour fréquentes à suivre si vous compilez depuis les sources, et un risque de dérive entre votre fork et la branche main. Le coût réel de possession n'est pas la licence, il est le temps passé à maintenir un backend d'IA et à surveiller l'espace disque. Pour une contribution plus large, le README demande d'ouvrir une issue avant, afin de cadrer le périmètre.
Quand Dayflow n'est pas le bon outil
Si vous travaillez sur Linux ou Windows, le projet ne s'applique pas : le code est en Swift et la cible est macOS 14 minimum. Si votre employeur interdit l'enregistrement d'écran, la question est réglée avant même l'installation. Et si vous cherchez un décompte facturable à la minute pour de la facturation client, Dayflow n'est pas conçu pour cela : le README parle de chronologie, de revue hebdomadaire et d'export Markdown, pas de taux horaires ni de factures. Enfin, un utilisateur qui refuse toute analyse par un modèle, local ou distant, n'obtiendra qu'une pile de captures sans les cartes d'activité qui font l'intérêt du produit. Le chat sur le journal et le résumé de standup, eux, dépendent d'un backend configuré : sans lui, ces deux fonctions restent hors d'atteinte.
Conclusion éditoriale
Dayflow convient aux développeurs et indépendants sous macOS 14 ou plus récent qui acceptent de stocker un historique d'écran sur leur disque et d'administrer eux-mêmes Ollama, LM Studio ou une clé API. Ceux qui ne peuvent pas accorder la permission Screen & System Audio Recording, ou qui ne veulent aucune analyse d'image, doivent passer leur chemin. Avant d'adopter, vérifiez la taille réelle de ~/Library/Application Support/Dayflow/ et les limites de purge automatique, puis ouvrez une issue sur le dépôt pour les questions de rétention que le README ne tranche pas.
Notes de la communauté