Mon journal de bord se remplit tout seul à chaque commit
J'ai ajouté un endpoint à l'API DockSky qui crée automatiquement une entrée dans le journal de bord à chaque commit git. Un hook de cinq lignes, et le journal s'écrit tout seul pendant que je travaille.
Mon journal de bord se remplit tout seul à chaque commit
J'ai un journal de bord dans TDA Assistant. Je le lis rarement. Pas parce qu'il n'est pas utile, mais parce que l'écrire à la main me coûte de l'énergie à un moment où j'ai déjà la tête dans autre chose. Résultat : soit il est vide, soit il est rempli trois jours après avec des souvenirs approximatifs.
La solution n'était pas de me forcer à écrire. C'était de rendre l'écriture automatique.
---
L'idée
Chaque commit git, c'est déjà un résumé de ce que j'ai fait. Le message du commit, la date, le repo, le hash. Tout ce dont j'ai besoin pour une entrée de journal est là, dans l'historique git. Il me manquait juste un pont entre les deux.
J'ai construit ce pont sous la forme d'un endpoint API.
---
Comment ça marche
L'endpoint POST /tda/journal/git-commit prend en entrée :
- le projet TDA concerné
- le message du commit
- la référence (le hash)
- la date du commit
- le nom du repo (optionnel)
Il crée une entrée dans le journal avec ce format :
🔧 [docksky-api@c330602] Fix: enum journal_source manquait git-commit (23/05/2026 05:42)Source git-commit, tags ["git", "commit"] automatiquement. Distingué des entrées manuelles et IA dans l'interface.
---
Le hook en cinq lignes
Un hook git post-commit s'exécute après chaque commit local. Il suffit de créer le fichier .git/hooks/post-commit, de le rendre exécutable, et d'y mettre :
#!/usr/bin/env bash
TOKEN=$(curl -s -X POST https://api.docksky.fr/auth/login -d "username=robert" -d "password=XXX" | grep -o '"access_token":"[^"]*"' | cut -d'"' -f4)
[ -z "$TOKEN" ] && exit 0
curl -s -X POST https://api.docksky.fr/tda/journal/git-commit -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" -d "{\"project_id\":79,\"message\":\"$(git log -1 --pretty=%s)\",\"commit_ref\":\"$(git rev-parse HEAD)\",\"commit_date\":\"$(git log -1 --pretty=%cI)\",\"repo\":\"$(basename $(git rev-parse --show-toplevel))\"}" > /dev/null
exit 0Le exit 0 final est non négociable. Si le réseau est absent ou l'API indisponible, le commit se fait normalement. Le hook ne bloque jamais le travail.
---
Ce que ça change concrètement
Avant : je finissais une session de dev, je fermais l'ordi, le journal restait vide.
Après : chaque commit alimente le journal. En fin de journée, j'ai un historique lisible de ce que j'ai fait, dans quel repo, à quelle heure. Sans aucune action de ma part.
Pour un cerveau TDA, c'est exactement le bon niveau d'automatisation : zéro friction, zero décision. Ça se fait pendant que je fais autre chose.
---
Le bug qui a failli tout bloquer
En première mise en ligne, l'endpoint retournait une erreur 500. La cause : la colonne source dans MySQL est un ENUM typé. J'avais oublié d'y ajouter git-commit.
La migration Alembic a failli échouer pour une autre raison : mon identifiant de révision faisait 35 caractères, la colonne alembic_version en accepte 32. J'ai raccourci l'ID, inséré la version manuellement en base, et tout s'est remis en ordre.
Ce genre de bug est exactement ce qui rend le build in public intéressant. Il n'y a rien de propre là-dedans. C'est juste de la vraie construction.
---
Et l'IA dans tout ça
La documentation de cet endpoint a été créée automatiquement dans les facettes de contexte TDA Assistant via le MCP. L'IA qui m'aide sur ce projet sait maintenant que l'endpoint existe, comment il fonctionne, et quel hook utiliser. Sans que j'aie à le lui ré-expliquer à chaque session.
C'est la boucle complète : je construis un outil, l'outil documente son propre usage, l'IA le sait pour la prochaine fois.