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 vrai journal de croissance extrait le schéma pour 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 tout 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-fichier, nouvelle fonctionnalité, changement d'architecture)
- Après un échec, une erreur, ou un moment "c'était plus difficile que prévu"
- Lorsque vous souhaitez revoir ce que vous avez appris sur une période
Quand NE PAS activer : Modifications triviales (corrections de fautes de frappe, ajustements d'une ligne, changements de valeur de configuration sans débogage). Le seuil : cette tâche impliquait-elle du débogage, des refontes, des rollbacks ou une décision non évidente ? Si oui → écrivez 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 seul bug ayant nécessité 2 heures pour être trouvé enseigne 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+. Schéma : toujours définir explicitement SameSite=None; Secure en cas de cross-origin. Signal à reconnaître : l'authentification se brise après une mise à jour du navigateur ou lors du franchissement des 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() compte comme valides. Schéma : toujours df.dropna(how='all', inplace=True) avant la validation du nombre de lignes."
Règle 2 : Le Principe Bole (伯乐原则)
Avant d'écrire une nouvelle entrée, demandez : "C'est fondamentalement la même chose que quelque chose que j'ai déjà enregistré ?"
Même cause profonde, symptôme différent → fusionnez, ne dupliquez pas. Nouvelle cause profonde → nouvelle entrée.
Comment vérifier : Recherchez dans les entrées existantes des mots-clés de votre cause profonde 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 avoir créé un fichier" et "Oubli de mettre à jour les évaluations de compétence après une tâche" — même cause profonde (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 serai dans une situation similaire, que ferai-je différemment ?"
Si vous ne pouvez pas écrire cette phrase, vous n'avez pas encore extrait le schéma.
Comment extraire un schéma 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 profonde (généralement 3 à 5 pourquoi)
- Généralisez : "À quelle classe de problème cela appartient-il ?" (pas "bug Chrome 128" mais "changement de paramètre par défaut du navigateur cassant un comportement existant")
- Formulez comme : "La prochaine fois que je vois [signal], je vais [action]."
- Nommez le signal : quel observable spécifique vous indique que ce schéma est actif ?
Modèle d'Entrée
Portée : Une entrée par cause profonde distincte. Longueur typique : 4 à 8 phrases. Si cela prend >2 minutes à écrire, vous racontez des événements. Si cela prend <30 secondes, vous n'êtes pas allé assez profond.
## [Titre : le schéma, pas l'événement]
### Contexte
- Que tentais-je de faire ?
- Qu'est-ce qui a mal fonctionné / qu'est-ce qui a fonctionné étonnamment bien ?
### Cause Profonde / Aperçu Central
- Le mécanisme sous-jacent, pas seulement le symptôme
### Le Schéma (transférable)
- La prochaine fois [situation similaire], je vais [action spécifique].
- Signal à reconnaître : [quel observable m'indique que ce schéma est actif ?]
### Lié
- [nom-de-l'entrée](../chemin/vers/entree-liee.md)
Types d'Entrées
Les quatre types utilisent le modèle ci-dessus. Le type détermine les sections qui portent 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 reprise | Cause Profonde | "L'héritage de configuration ≠ l'héritage de comportement entre sessions" |
| Méthodologie | Un processus reproductible a émergé du travail | Contexte / Schéma | "PPT → guide d'étude pour examen à livre ouvert : structure à trois couches" |
| Découverte de Schéma | Un aperçu réutilisable sur les outils, systèmes ou la réflexion | Section Schéma | "Modèle de description de PR : décrire l'écart, pas la fonctionnalité" |
| Changement de Capacité | Une amélioration mesurable d'une compétence | Contexte (avant vs après) | "Git : de clone/push à une PR indépendante avec 12 commits" |
Liste de Vérification Qualité
Avant de finaliser une entrée de journal de croissance :
- Le titre nomme-t-il le schéma, pas l'événement ?
- Y a-t-il une phrase "La prochaine fois je vais..." ?
- Le "Signal à reconnaître" est-il suffisamment spécifique pour déclencher le schéma la prochaine fois ?
- Ai-je recherché les entrées existantes pour les doublons avant d'écrire ? (Principe Bole)
- La cause profonde est-elle distinguée du symptôme ?
- Les mémoires associées sont-elles liées par des liens croisés ?
- L'entrée fait-elle 4 à 8 phrases ? Plus court = trop superficiel ; plus long = raconter des événements.
Anti-Schémas
- Évitez : "Bug corrigé dans le module de paiement" (événement, pas schéma)
- Évitez : Copier textuellement le message de commit git (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 schéma é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 schéma sous différents titres (viole le principe Bole — recherchez avant d'écrire)
Stockage
Stockez les entrées là où vous conservez vos notes. Schémas courants :
- Fichiers Markdown dans un répertoire
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 Stop hook 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 que delivery-gate vérifie contienne réellement des schémas 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'avez-vous appris ?"
→ Frais (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.