Compétence Journal de Croissance
Le problème : La plupart des gens écrivent « correction d'un bug dans X » comme journal d'apprentissage. C'est une entrée de journal intime, pas un artefact d'apprentissage. Un véritable journal de croissance extrait le motif pour pouvoir le reconnaître la prochaine fois.
Cette compétence enseigne : Comment rédiger des entrées d'apprentissage qui s'accumulent entre les sessions. Fonctionne avec n'importe quel système de prise de notes — fichiers Markdown, Notion, Obsidian, texte brut. Les modèles sont génériques ; adaptez-les à votre configuration.
Quand Activer
- Après avoir terminé une tâche complexe (multi-fichiers, nouvelle fonctionnalité, changement d'architecture)
- Après un échec, une erreur, ou un moment « c'était plus dur que prévu »
- Lorsque vous souhaitez revoir ce que vous avez appris sur une période
Quand NE PAS activer : Changements triviaux (corrections de fautes de frappe, ajustements d'une ligne, modifications de valeur de configuration sans débogage). Le seuil : cette tâche a-t-elle impliqué du débogage, une refonte, un rollback ou une décision non évidente ? Si oui → rédigez une entrée. Si non → passez.
Les Trois Règles
Règle 1 : Les Échecs > Les Réussites
Un échec est nutritionnellement plus dense qu'un succès. Un bogue qui a pris 2 heures à trouver en apprend plus que 3 fonctionnalités qui ont fonctionné du premier coup.
Mauvais : « Implémentation réussie du flux de connexion. »
Bon (développement web) : « Flux de connexion : le jeton de session ne persistait pas car le cookie SameSite par défaut était Lax dans Chrome 128+. Motif : toujours définir explicitement SameSite=None; Secure en cas d'origine croisée. Signal à reconnaître : l'authentification se casse après une mise à jour du navigateur ou lors du franchissement de limites d'origine. »
Bon (pipeline de données) : « L'import CSV a échoué silencieusement sur les lignes vides car pandas.read_csv(dropna=False) conserve les lignes de largeur nulle que len() considère comme valides. Motif : toujours df.dropna(how='all', inplace=True) avant la validation du nombre de lignes. »
Règle 2 : Le Principe de Bole (伯乐原则)
Avant d'écrire une nouvelle entrée, demandez : « Cela est-il fondamentalement identique à quelque chose que j'ai déjà enregistré ? »
Même cause racine, symptôme différent → fusionnez, ne dupliquez pas. Nouvelle cause racine → nouvelle entrée.
Comment vérifier : Recherchez dans les entrées existantes des mots-clés de votre cause racine avant d'écrire. Si vous trouvez une correspondance, ajoutez votre nouveau symptôme comme exemple supplémentaire sous l'entrée existante plutôt que de créer un doublon.
Exemple : « Oubli de mettre à jour l'index de sortie après création d'un fichier » et « Oubli de mettre à jour les évaluations de compétence après une tâche » — même cause racine (pas de déclencheur de capture automatique). Fusionnez en une seule entrée sur les « lacunes de capture post-tâche. »
Règle 3 : Doit Être Transférable
Chaque entrée doit répondre à : « La prochaine fois que je ferai face à une situation similaire, que ferai-je différemment ? »
Si vous ne pouvez pas écrire cette phrase, vous n'avez pas encore extrait le motif.
Comment extraire un motif d'un événement concret :
- Énoncez ce qui s'est passé en une phrase
- Demandez « pourquoi ? » de manière itérative jusqu'à atteindre la cause racine (généralement 3 à 5 pourquoi)
- Généralisez : « De quelle classe de problème s'agit-il ? » (pas « bogue Chrome 128 » mais « changement de valeur par défaut du navigateur cassant un comportement existant »)
- Formulez comme : « La prochaine fois que je vois [signal], je [action]. »
- Nommez le signal : quel observable spécifique vous indique que ce motif est actif ?
Modèle d'Entrée
Portée : Une entrée par cause racine distincte. Longueur typique : 4 à 8 phrases. Si cela prend >2 minutes à écrire, vous narrez des événements. Si <30 secondes, vous n'êtes pas allé assez profond.
## [Titre : le motif, pas l'événement]
### Contexte
- Qu'essayais-je de faire ?
- Qu'est-ce qui a mal tourné / qu'est-ce qui a fonctionné étonnamment bien ?
### Cause Racine / Aperçu Fondamental
- Le mécanisme sous-jacent, pas seulement le symptôme
### Le Motif (transférable)
- La prochaine fois [situation similaire], je [action spécifique].
- Signal à reconnaître : [quel observable m'indique que ce motif est actif ?]
### Lié
- [nom-entrée](../chemin/vers/entree-liee.md)
Types d'Entrées
Les quatre types utilisent le modèle ci-dessus. Le type détermine quelles sections ont le plus de poids :
| Type | Quand l'Utiliser | Accent | Exemple de Titre |
|---|---|---|---|
| Échec | Quelque chose s'est cassé, a nécessité du débogage ou une refonte | Cause Racine | « L'héritage de configuration ≠ l'héritage de comportement entre sessions » |
| Méthodologie | Un processus reproductible a émergé du travail | Contexte / Motif | « PPT → guide d'étude pour examen à livre ouvert : structure à trois couches » |
| Découverte de Motif | Un aperçu réutilisable sur les outils, systèmes ou la pensée | Section Motif | « Modèle de description de PR : décrivez le fossé, pas la fonctionnalité » |
| Changement de Capacité | Une amélioration mesurable d'une compétence | Contexte (avant vs après) | « Git : de clone/push à PR indépendant avec 12 commits » |
Checklist de Qualité
Avant de finaliser une entrée de journal de croissance :
- Le titre nomme-t-il le motif, pas l'événement ?
- Y a-t-il une phrase « La prochaine fois, je vais... » ?
- Le « Signal à reconnaître » est-il assez spécifique pour déclencher le motif la prochaine fois ?
- Ai-je cherché dans les entrées existantes des doublons avant d'écrire ? (Principe de Bole)
- La cause racine est-elle distinguée du symptôme ?
- Les souvenirs connexes sont-ils liés par des liens croisés ?
- L'entrée fait-elle 4 à 8 phrases ? Plus court = trop superficiel ; plus long = narration d'événements.
Anti-Patrons
- Évitez : « Correction d'un bogue dans le module de paiement » (événement, pas motif)
- Évitez : Copier le message de commit git textuellement (les commits décrivent ce qui a changé ; les journaux extraient pourquoi c'est important)
- Évitez : Écrire une entrée pour chaque commit (seulement quand un motif émerge)
- Évitez : Sauter la phrase transférable (sans elle, c'est juste un journal intime — ce n'est pas négociable)
- Évitez : Dupliquer le même motif sous différents titres (viole le Principe de Bole — cherchez avant d'écrire)
Stockage
Stockez les entrées là où vous gardez vos notes. Schémas courants :
- Fichiers Markdown dans un dossier
growth-log/(un fichier par jour :YYYY-MM-DD.md) - Une section dédiée dans Notion, Obsidian ou votre application de prise de notes
- Fichiers texte brut avec une convention de nommage cohérente
Choisissez une convention et tenez-vous-y. La capacité de recherche importe plus que le format.
Si Vous Utilisez Delivery Gate
Le hook d'arrêt delivery-gate vérifie que les fichiers d'apprentissage ont été modifiés aujourd'hui via les horodatages du système de fichiers. Cette compétence enseigne quoi écrire — afin que le fichier vérifié par delivery-gate contienne réellement des motifs utiles, pas des horodatages vides.
Tâche terminée → delivery-gate vérifie : le fichier d'apprentissage a-t-il été touché aujourd'hui ?
→ Obsolète (aucun fichier modifié) : bloquer — « qu'as-tu appris ? »
→ Récent (fichier touché) : passer — cette compétence garantit que le contenu est utile
Avoir une application sans méthodologie → des entrées vides. Avoir une méthodologie sans application → des captures oubliées. Chacun est utile indépendamment ; ensemble, ils bouclent la boucle.