Documenter son travail avec l’IA, Markdown et Obsidian

 Tenir un journal de développement m’aurait autrefois semblé excessif. Entre le backlog, les commits et le code lui-même, pourquoi consacrer encore du temps à raconter ce que je venais de faire?

L’IA change mon point de vue. Puisqu’elle participe au travail, elle dispose déjà d’une partie du contexte nécessaire pour en préparer une synthèse. L’effort devient surtout une question de relecture : confirmer les faits, ajuster les nuances et préciser le temps consacré.

L’objectif est simple : garder une mémoire utile du projet sans alourdir le travail quotidien.

Une documentation qui reste avec le projet

L’historique est conservé en Markdown, dans le même dépôt Git que le projet. Il accompagne ainsi le code et peut être versionné et partagé avec lui.

Les fiches sont organisées par année, par mois et par jour :

Historique Réalisation/
└── 2026/
    └── 09/
        ├── 18.md
        ├── 19.md
        └── 22.md

Cette structure reste facile à parcourir à mesure que les journées s’accumulent. Le chemin du fichier donne la date complète, tandis que le nom de la note demeure court.

En ajoutant les fiches aux commits, on conserve aussi leurs modifications dans Git. Une personne qui reprend le dépôt peut retrouver le code, la documentation et le contexte des travaux au même endroit.

Obsidian pour consulter facilement l’historique

J’utilise Obsidian pour parcourir cette documentation. Le dossier de documentation du projet sert de coffre : les fichiers du dépôt sont directement les notes consultées dans Obsidian.

L’arborescence permet de naviguer rapidement entre les années, les mois et les journées. La recherche aide à retrouver un numéro de tâche, une correction ou une décision. Les liens vers Azure DevOps donnent accès au suivi détaillé.

L’intérêt est de disposer d’une interface agréable pour lire et naviguer, tout en conservant des fichiers Markdown accessibles depuis les autres outils du projet.

Obsidian facilite la consultation; Git conserve les versions de la documentation.

Une fiche courte à chaque journée de travail

Chaque fiche utilise trois sections.

Réalisations

Quelques lignes décrivent les travaux effectués et leur résultat concret : correction d’un bogue, préparation d’une migration, amélioration d’un formulaire ou clarification d’une convention.

Chaque tâche mentionnée comporte un lien vers le backlog.

Bilan

Un court paragraphe résume l’avancement réel et les points à reprendre. Il permet de comprendre rapidement où le travail s’est arrêté.

Temps passé

Une durée totale donne un ordre de grandeur de l’effort consacré à la journée. Elle peut être approximative : le but est de conserver un repère utile, sans imposer un chronométrage détaillé.

Lorsqu’elle est inconnue, elle reste explicitement non renseignée.

Une consigne simple : « compile histo »

Pour que cette pratique reste légère, j’ai défini une consigne dans les instructions du projet : « compile histo ».

Elle demande à l’IA de créer ou de compléter la fiche du jour à partir des travaux en cours et des traces disponibles. Je peux ajouter du contexte, par exemple :

Compile histo, on est en train de travailler sur la tâche 167.

L’IA prépare alors une synthèse en respectant le format établi. Si une fiche existe déjà, elle la complète en préservant les éléments précédents et en évitant les répétitions.

Je relis ensuite le résultat pour vérifier qu’il correspond bien au travail accompli.

Décrire honnêtement l’avancement

La qualité du journal dépend de la précision de ses formulations. Une solution discutée, du code écrit et une correction validée représentent des étapes différentes.

État	Signification
Analysé	Le problème a été étudié et des pistes ont été identifiées.
Préparé	Une solution existe, mais son intégration ou son exécution reste à faire.
Réalisé	La modification a été effectuée.
Validé	Des vérifications confirment le comportement attendu.
Déployé	La modification a été mise à disposition dans l’environnement visé.

Une migration peut ainsi être préparée sans avoir été exécutée. Une protection contre un bogue intermittent peut être ajoutée sans que son efficacité soit encore confirmée à l’usage.

Ces nuances rendent le journal utile lorsqu’on reprend un sujet après plusieurs jours ou plusieurs semaines.

Quelques propriétés pour faciliter l’exploitation

Chaque fiche commence par un petit en-tête YAML :

---
date: 2026-09-22
time_spent_hours: 0.50
time_spent_estimated: true
---

Ces informations apparaissent dans les propriétés de la note dans Obsidian. Elles pourront aussi servir à une exploitation ultérieure avec un script, Excel ou Power Query.

La durée est exprimée en heures décimales :

• 0.50 pour 30 minutes;
• 2.00 pour 2 heures;
• 2.50 pour 2 heures 30 minutes;
• null lorsque la durée est inconnue.

La propriété time_spent_estimated précise si la durée est approximative ou mesurée. Une formulation lisible reste également présente dans la section « Temps passé ».

Plus tard, une synthèse au rythme du projet

Pour l’instant, les fiches quotidiennes constituent la base de cette démarche. Elles suffisent pour conserver le contexte et reprendre le travail.

Une synthèse périodique pourrait devenir intéressante lorsque l’historique sera plus étoffé. Sa fréquence devrait suivre le rythme du projet :

• Par sprint, dans une équipe qui travaille avec cette cadence.
• Par mois, dans mon cas, pour prendre du recul sur plusieurs séances de travail.
• À une étape importante, comme une livraison ou la fin d’une fonctionnalité.

Cette synthèse pourrait regrouper les résultats obtenus, les travaux encore en cours, les décisions importantes et le temps renseigné. Elle renverrait aux fiches quotidiennes pour consulter le détail.

L’idée reste une possibilité d’évolution, à adopter si elle apporte une réelle valeur.

Une mémoire utile, avec un effort raisonnable

Le backlog décrit le travail à accomplir. Les commits conservent les changements apportés au code. Le journal explique ce qui a avancé, ce qui a été décidé et ce qui reste à confirmer.

L’IA facilite la rédaction, mais la validation humaine reste essentielle. Elle ne doit pas inventer une durée, présumer qu’un test a réussi ou présenter un travail en cours comme terminé.

Avec quelques lignes fiables par journée, on construit progressivement une mémoire du projet. Obsidian la rend agréable à consulter, et sa présence dans le même dépôt que le code lui donne une place naturelle dans le travail de développement.