CRA freelance : un agent IA remplit le mois à ma place

Quand on est freelance et qu’on facture à la journée, chaque fin de mois ramène le même document à produire : le compte rendu d’activité, le CRA, qui liste les jours travaillés. La plupart des outils de suivi du temps sont pensés pour des équipes, avec licences par utilisateur, managers et circuits de validation. Moi, il me faut juste ce CRA mensuel, en PDF, à joindre à la facture.

Presto sert à ça. Je présente ici Presto 2, une réécriture complète : ce qu’il sait faire, comment un agent IA peut remplir le mois à ma place, et comment l’installer.

Toutes les données dans un seul fichier SQLite

Presto 2 se passe de comptes utilisateur, de connexion, de cloud et de télémétrie. Toutes les données tiennent dans un seul fichier SQLite, que je copie, déplace et sauvegarde comme je l’entends. Aucun serveur de base de données à faire tourner, rien à configurer non plus : chaque réglage a une valeur par défaut, et l’application démarre même sans fichier .env.

Le modèle tient en quatre notions. La société est la structure qui facture, et dont le nom figure sur le PDF. Le client a une devise de facturation et un pays, qui fixe ses jours fériés. Une mission est un travail réalisé pour un client à un taux journalier, et un compte rendu couvre une mission sur un mois.

Un mois se remplit au clic

L’éditeur se présente comme un calendrier. Chaque clic fait passer un jour de vide à demi-journée, puis à journée complète. Les demi-journées sont coupées en diagonale, si bien que l’allure du mois se lit d’un coup d’œil, sans un seul chiffre.

L’essentiel se fait avec deux boutons. « Remplir les jours ouvrés » coche tous les jours du lundi au vendredi, sauf les jours fériés du client. « Copier le mois dernier » reprend le rythme, pas les dates : si j’ai travaillé du lundi au jeudi en mars, tous les lundis, mardis, mercredis et jeudis d’avril sont cochés, jours fériés d’avril exceptés.

Les jours fériés dépendent du pays du client, via la bibliothèque date-holidays, et Presto me demande confirmation avant que j’en facture un. Au clavier, les flèches passent d’un jour à l’autre, Espace change la valeur du jour et N ouvre sa note.

Une fois le mois bouclé, je valide le compte rendu, qui passe alors en lecture seule. On peut toujours le repasser en brouillon, après confirmation, puisque le client a peut-être déjà reçu le PDF.

Chaque compte rendu porte deux notes, bien séparées à l’écran. La note client est imprimée sur le PDF. La note privée, elle, reste dans la base et n’apparaît ni dans le PDF, ni dans aucun export destiné au client.

Le PDF que reçoit le client

Le PDF est généré côté serveur avec React PDF, une page par mois, en français ou en anglais. On y trouve ma société et son identifiant d’entreprise, le client et le sien, la mission, chaque jour avec ses notes, les jours fériés avec leur nom et le total des jours.

Presto refuse d’exporter un brouillon, car exporter un mois à moitié rempli est presque toujours une erreur, et le valider ne coûte qu’un clic.

Un bilan annuel par devise, sans conversion

Le bilan de l’année affiche les jours facturés, le chiffre d’affaires, le taux journalier moyen et le taux d’occupation (rapporté aux jours ouvrés de l’année), ventilés par client et par société.

Pour l’année en cours, la comparaison se fait avec les mêmes mois de l’année précédente, pas avec douze mois pleins. Huit mois d’activité ne doivent pas passer pour une baisse d’un tiers.

Presto 1 convertissait toutes les devises avec des taux de change en temps réel. Presto 2 ne convertit plus rien, et regroupe les montants par devise, tels qu’ils ont été facturés. Le montant de chaque compte rendu est arrondi au centime le plus proche, le demi-centime vers le haut, si bien que 16,5 jours à 660,25 donnent 10 894,13.

L’année s’exporte en CSV pour l’expert-comptable, et la base entière en JSON, lisible sans SQLite. Pour les partages d’écran, un bouton floute tous les montants ; les jours et l’allure des graphiques restent visibles.

Confier la fin de mois à un agent IA

Presto implémente le Model Context Protocol (MCP), et Claude, Cursor, Codex, VS Code ou tout autre client MCP peut donc le piloter. La fin de mois tient alors en une phrase :

Remplis mai pour Globex, j’étais absent le 14 et je n’ai travaillé que le matin du 22. Ensuite valide-le et enregistre le PDF en français dans ~/Documents/CRA.

L’agent commence par lire les sociétés, les clients, les missions et les comptes rendus, ce qui me permet de lui parler de clients et de mois, jamais d’identifiants techniques. Dès la connexion, il reçoit les règles métier : combien peut valoir un jour, qu’un compte rendu validé est figé, que la note client va sur le PDF et la note privée jamais. Il a aussi pour consigne de me demander confirmation avant de facturer un jour férié ou de supprimer quoi que ce soit.

On peut aussi bien l’interroger que lui donner des ordres :

• « Est-ce que j’ai facturé un jour férié ou un week-end cette année ? »
• « Quelles missions n’ont pas encore de compte rendu ce mois-ci ? »
• « Combien j’ai facturé par client, et quel est mon taux journalier moyen ? »
• « Coche ces jours sur le compte rendu de mars », suivi d’une feuille de temps copiée d’un e-mail du client.

Ses 17 outils couvrent tout ce que permet l’interface web : comptes rendus, clients, missions, sociétés, bilan annuel, exports PDF, CSV et JSON. Chacun passe par la même API REST que le navigateur, dans le même processus, donc les règles ne sont écrites qu’à un seul endroit. Impossible de modifier un compte rendu validé sans le repasser en brouillon, d’exporter un brouillon en PDF, ou de supprimer un client encore rattaché à une mission.

Chaque outil indique au client MCP s’il lit, écrit ou supprime, et seul delete est destructeur. Le client peut donc exiger ma confirmation à chaque suppression tout en laissant l’agent lire et remplir les comptes rendus librement. Les exports peuvent écrire directement sur le disque, mais uniquement sur le serveur local, et sans jamais écraser un fichier existant.

En local, le client lance lui-même le serveur MCP de Presto en sous-processus et dialogue avec lui en stdio. Le serveur ouvre alors directement le fichier de la base, n’écoute sur aucun port et n’a besoin d’aucun jeton.

claude mcp add presto -- bun /path/to/presto/src/server/stdio.ts

Sur un serveur, Presto expose son serveur MCP en HTTP sur /mcp. Si la variable PRESTO_TOKEN est définie, chaque requête sur cet endpoint doit présenter le jeton, et les appels lancés depuis la page web d’un autre site sont refusés, si bien qu’une page ouverte dans mon navigateur ne peut pas piloter un Presto sur localhost. Le jeton ne protège que /mcp, pas l’interface web.

Deux limites, toutefois. Les applications de chat hébergées comme claude.ai et ChatGPT n’acceptent que des serveurs compatibles OAuth, ce que Presto n’est pas. Il fonctionne donc avec les applications de bureau et les agents de développement. Par ailleurs, Presto n’envoie rien nulle part, mais un modèle hébergé dans le cloud voit tout ce que lisent les outils de Presto, note privée comprise. Le guide des agents (en anglais) détaille la configuration de chaque client et la liste complète des outils.

Un seul conteneur suffit

docker run -d --name presto \
  -p 127.0.0.1:8080:8080 \
  -v presto-data:/data \
  ghcr.io/tux86/presto:latest

Presto n’a pas d’authentification, et quiconque accède au port peut tout lire et tout modifier. Gardez-le sur localhost, comme ci-dessus, ou derrière un VPN ou un reverse proxy qui contrôle l’accès.

Un conteneur et un volume suffisent. L’image est publiée pour linux/amd64 et linux/arm64 et tourne sous un utilisateur non root. Le serveur est empaqueté en un seul fichier, ce qui évite d’embarquer un dossier node_modules dans l’image. Sans Docker, il suffit d’un bun install puis d’un bun start dans un clone du dépôt, avec Bun pour seul prérequis.

bun run backup produit une copie cohérente de la base grâce au VACUUM INTO de SQLite, ce que ne garantit pas un simple cp d’une base en cours d’utilisation en mode WAL.

Chez moi, Presto tourne dans mon homelab (article en anglais), à côté des autres applications que j’auto-héberge.

Sous le capot

• Runtime : Bun, qui exécute directement le TypeScript
• Serveur : Hono, du SQL brut sur bun:sqlite, sans ORM
• Interface : React 19, Vite, Tailwind CSS 4, Recharts
• PDF : React PDF, généré côté serveur
• MCP : écrit à la main, environ 400 lignes sans SDK ; uniquement des outils, sans état, du JSON en entrée comme en sortie
• Tests : environ 190, sans serveur de base de données

Toute la logique susceptible de fausser une facture (calendriers, jours fériés, totaux, cumul annuel, CSV) est regroupée dans un dossier qui n’importe rien de la base, du serveur ni de l’interface. C’est ce qui permet de la tester isolément, et presque tous les tests portent sur elle.

Un serveur empaqueté en un seul fichier, sans node_modules, peut casser d’une manière que les tests ne détectent pas, puisqu’ils tournent sur les sources. C’est arrivé : après une mise à jour de dépendance, la bibliothèque PDF s’est mise à charger ses polices à l’exécution, et deux versions sont sorties avec une image qui plantait au démarrage alors que tous les tests passaient. Désormais, la chaîne de publication démarre l’image construite et lui fait générer un PDF dans les deux langues avant de publier quoi que ce soit.

À qui s’adresse Presto

Presto convient au freelance ou au consultant qui facture à la journée, envoie un compte rendu d’activité chaque mois et sait lancer un conteneur ou une application Bun. Il ne gère ni comptes utilisateur, ni équipes, ni facturation, et les pull requests qui voudraient les ajouter sont refusées.

Le code est sur GitHub sous licence MIT, et l’image sur le GitHub Container Registry.