Le problème de départ

Pendant des mois, j'ai appris à la volée : documentation, tutos, discussions avec d'autres développeurs, conversations avec Claude. Et rien à la sortie que des brouillons, des feuilles volantes. Rien d'écrit, rien de structuré.

Je comprenais toujours les bases globales d'un concept. Mais dès qu'il fallait creuser un peu plus, j'oubliais. C'est encore le cas aujourd'hui — le fait d'écrire ne me donne pas une mémoire parfaite, mais cela me permet de mieux retenir sur le moment, et de retrouver facilement ensuite.

Le vrai point faible : ce que j'avais creusé, justement, je m'en souvenais souvent moins bien que les bases. Les détails spécifiques disparaissaient en premier. Et sans trace, pas moyen de réactiver.

Cela ne posait pas de problème tant que je bossais sur du court terme. Dès que j'ai commencé à empiler des technos — Docker, Swarm, Terraform, Ansible, AWS — j'ai senti que je perdais le fil.

Le déclencheur

Deux choses en même temps : j'ai pris un abonnement Claude, et j'allais attaquer mon projet AWS + Terraform + Ansible. Un projet plus gros que tout ce que j'avais fait avant.

J'ai compris que si je démarrais sans rien pour poser les choses au fur et à mesure, j'allais finir avec des bouts de compréhension dispersés et aucune manière de les retrouver.

Avant d'installer quoi que ce soit, j'ai pris le temps de me documenter sur deux sujets :

  1. Comment mieux structurer ses notes et ses connaissances. C'est là que j'ai croisé le Zettelkasten (méthode de Niklas Luhmann basée sur des notes atomiques — une note = une idée — reliées entre elles par des liens bidirectionnels, plus un concept est relié, plus il devient central) et PARA de Tiago Forte (classement en Projects, Areas, Resources, Archives). J'ai pris ce qui me parlait dans chaque : l'atomicité et les liens du premier, le découpage par nature d'usage du second. Je n'applique ni l'un ni l'autre à la lettre.
  2. Comment mieux utiliser Claude pour apprendre. Anti-dépendance, ratio assistance/autonomie, prompts qui challengent plutôt que qui donnent la réponse directe.

Après ça seulement, j'ai installé Obsidian et créé un repo GitHub pour héberger tout.

Mise en place concrète

Il faut démystifier un truc : ce n'est pas "un vault Obsidian". C'est un repo GitHub qui sert de coffre-fort de savoir. Obsidian est juste l'outil qui permet de le visualiser, de chercher dedans, et de lier les fichiers entre eux. Les notes sont des fichiers markdown. Si demain Obsidian disparaît, le repo reste lisible avec n'importe quel éditeur de texte.

Mon repo est public sur GitHub. Si tu veux voir à quoi cela ressemble en vrai, clone-le : github.com/TuroTheReal/devops-cloud_vault.

Structure actuelle :

  • concepts/ — comment ça marche (Docker, Terraform, AWS, réseau, Linux)
  • cheatsheets/ — les commandes utiles par techno
  • projects/ — retours d'expérience par projet
  • MOCs/ — maps of content, points d'entrée par thème
  • troubleshooting/ — problèmes rencontrés et solutions vérifiées
  • meta/ — templates et guidelines

Dans Obsidian, deux choses font la différence par rapport à un dossier de markdown classique :

  • Les liens [[note]] — tu relies une fiche concept à un projet, un troubleshooting à un concept. L'outil reconstruit le graphe des relations automatiquement, et c'est grâce à cela qu'on peut visualiser ce fameux "réseau de neurones" très satisfaisant quand il commence à se densifier.
  • Les métadonnées YAML — tags, statut (status/learning, status/mastered), difficulté, date de création. Cela permet de filtrer et de requêter plus tard.

Mon workflow concret

1. Découverte et validation

Quand je tombe sur un nouveau concept, je commence par en discuter avec Claude pour poser les bases. Puis je valide en croisant avec la documentation officielle. C'est non-négociable.

Ma hiérarchie de sources est stricte :

  1. Documentation officielle — source de vérité absolue, sans discussion
  2. Blogs tech reconnus (AWS, CNCF, Hashicorp, etc.)
  3. Stack Overflow / discussions techniques pointues

Ce que je refuse : Reddit généraliste, blogs non-tech, contenus reformulés qui citent d'autres reformulations. Et dans mes guidelines Claude, c'est écrit noir sur blanc : l'IA doit traiter la doc officielle comme la source de vérité absolue. Pas d'approximation, pas de "j'ai lu quelque part que".

Pendant cette phase, je reformule ce que j'ai compris avec mes propres mots. Souvent j'essaie une analogie pour imager le concept. Si je ne peux pas le reformuler ou trouver une image, c'est que je ne l'ai pas compris — et je replonge dans la doc.

Pour les concepts que je connais déjà un peu, utiliser l'IA pour synthétiser est un vrai gain de temps. Mais dès qu'on passe à un problème précis appliqué à un besoin spécifique, il faut retourner à la doc officielle ou creuser dans le code source. L'IA sans contexte donne une réponse globale, pas précise. Si je veux du précis, je dois poser le contexte explicitement — sinon je perds plus de temps à vérifier sa réponse qu'à chercher moi-même.

2. Contextualisation avec Claude

Une fois que j'ai saisi l'idée générale, je crée un projet Claude dédié pour la techno ou le projet sur lequel je vais bosser. En plus de mes guidelines principales chargées globalement, ce projet contient :

  • La doc officielle que je veux que Claude ait en tête
  • Le contexte précis de ce que je vais faire
  • L'exercice ou le projet concret auquel je m'attaque
  • La discussion précédente aussi, pour valider, poser les bases, situer où j'en suis pour l'IA

C'est un gros travail de contextualisation à chaque fois. Mais c'est ce qui permet à Claude de vraiment m'aider plutôt que de me donner des réponses génériques. L'IA sans contexte = un moteur de recherche amélioré. L'IA avec mon contexte = un interlocuteur qui comprend ce que j'essaie de faire.

C'est d'ailleurs là que je commence à me concentrer de plus en plus : le contexte engineering plutôt que le prompt. Un bon prompt sans contexte vaut moins qu'un prompt moyen avec le bon contexte. C'est depuis que j'essaye de passer de prompt à context engineering avec l'IA.

3. Implémentation et notes en temps réel

Je passe au projet. Je tente, j'implémente, je casse. Je prends les notes au fur et à mesure, pas à la fin.

Ce point est important parce que j'ai fait l'erreur inverse au début : attendre la fin du projet pour tout documenter. Résultat, je zappais déjà des points, je ne me souvenais plus de mes premières galères, je ne retrouvais plus pourquoi j'avais fait tel choix à un moment donné. Aujourd'hui je capture à chaud — même en bazar, même incomplet. Le tri vient après.

4. Formatage avec mes templates (et une bonne dose d'itérations)

Une fois une étape importante atteinte, je décide si ce que j'ai appris mérite d'aller dans le repo. Si c'est un concept réutilisable, une techno nouvelle, un problème récurrent ou critique, ça y va.

Là Claude m'aide à mettre en forme. Je lui donne mes notes brutes + le template concerné, et je lui demande de structurer. La règle absolue : les concepts restent dans mes mots. Si je laisse Claude paraphraser à ma place, je perds la trace de ce que j'avais compris, et la fiche ne me parle plus à la relecture.

J'ai plusieurs templates — un pour les concepts, un pour les projets, un pour les cheatsheets, un pour les troubleshooting. Ils sont différents parce que les usages sont différents, mais j'essaie de maintenir une certaine cohérence dans la forme globale. En revanche, entre deux fiches concept (concept A, concept B, concept C), le template est toujours le même. Mêmes sections dans le même ordre. Certaines sections sont optionnelles selon le cas, mais la base reste identique. Cela me permet d'être familier avec la structure, de retrouver l'info au même endroit dans chaque fiche, sans avoir à réfléchir.

Mon template actuel est le résultat de beaucoup d'itérations. Au début il était trop long, trop complexe. Écrire prenait deux heures, relire deux mois plus tard ne me donnait rien de plus qu'une note courte. J'ai simplifié, puis re-simplifié. Aujourd'hui une fiche concept me prend 30-40 min à finaliser, et quand je la relis je retrouve ma réflexion, pas un résumé formaté par une IA.

5. Extraction des troubleshooting

Si j'ai vraiment galéré sur un problème pendant l'implémentation, j'en fais une fiche dans troubleshooting/. Pas juste la solution : le message d'erreur exact, les hypothèses testées, ce qui n'a pas marché et pourquoi, la solution finale, et comment l'éviter.

Dans mon repo j'en ai trois pour l'instant — deux sur Docker et une sur Grafana. C'est peu, mais ce n'est pas forcément l'objectif d'en avoir beaucoup ni de gagner du temps à la prochaine occurrence. Ces fiches couvrent surtout des problèmes assez critiques pour mériter une trace explicite, même si je ne retomberai pas forcément dessus avant des mois.

Les guidelines : le vrai levier du système

Le système ne tient pas sur Obsidian. Il tient sur les guidelines que je donne à Claude sur le contexte — ce qu'il doit savoir, comment il doit travailler avec moi, ce qu'il ne doit pas faire à ma place.

J'ai un CLAUDE.md global, chargé automatiquement à chaque conversation Claude Code. Dedans : mon contexte tech, ma stack prioritaire, ma pédagogie (explique avant d'implémenter, challenge-moi, ne fais pas à ma place), mon style de réponse, ma hiérarchie de sources, et mes règles de sécurité.

À minima, la hiérarchie de sources est ce qu'il doit absolument respecter : doc officielle d'abord, blogs tech reconnus ensuite, le reste seulement pour des discussions pointues. Pas d'approximation, pas de reformulation de reformulation. C'est la règle la plus importante du fichier — sans cela, tout le reste s'effondre.

Côté pédagogie, je lui demande d'expliquer avant de coder, de me challenger sur ce que je crois avoir compris, de ne jamais me donner une réponse toute faite quand je peux la chercher moi-même. Côté style, du français avec les termes techniques en anglais, du concret, pas de blabla. Côté contrôle, Claude ne touche jamais à Git tout seul, ne lance jamais de commande destructive sans validation explicite : il me montre, j'approuve, il exécute.

Et dans le repo, ma règle à moi est simple :

Mes mots doivent rester les miens.

Quand je relis une fiche, je veux retrouver ma voix, mes mots, ma façon de raisonner — pas une reformulation propre générée par une IA. Le jour où je ne me reconnais plus dans ce que je relis, c'est qu'à ce moment-là, c'est Claude qui aura appris à ma place, pas moi.

Mon usage réel de l'IA

Dans la pratique, je suis à environ 60% avec l'IA et 40% seul. Et l'usage est clair : c'est pour comprendre, pour m'approprier ce qu'elle me donne. Je discute beaucoup avec l'IA. Je lui demande d'expliquer, de challenger ma compréhension, de pointer ce que je rate.

Mon point de vue actuel : dans quelques temps, l'IA codera déjà mieux que nous sur beaucoup de tâches. Elle le fait déjà pour le boilerplate (le code répétitif qu'on réécrit à chaque nouveau projet sans vraie valeur : imports, config, structure de base), le refactor simple, la génération de fichiers de configuration. Ce qu'elle n'aura pas avant un bon moment, c'est le contexte complet d'un projet dans une vraie boîte — les 45 contraintes à prendre en compte, les décisions architecturales liées à des choix business, l'historique, les dépendances cachées entre équipes.

Donc ce sur quoi je dois absolument devenir solide, c'est comprendre ce que je fais et pourquoi. La nomenclature exacte d'une commande, la liste de flags d'un outil, la config précise d'un fichier — je ne me focus pas là-dessus, cela viendra avec le temps et la répétition. Ce qui compte maintenant, c'est le raisonnement derrière.

Le bilan honnête

Ce qui marche vraiment : pouvoir poser des notes en vrac, puis savoir où les retrouver. Point. Je tape Ctrl+O, un mot-clé, j'ai ma fiche. Je me souviens de ce que j'avais compris, avec mes mots, pas avec une reformulation générique.

Ce qui est joli mais pas essentiel : le graph view. Je l'ouvre de temps en temps. C'est un bonus — satisfaisant de voir l'évolution de mes connaissances prendre forme visuellement. Le graph me rappelle que cela progresse, mais ce n'est pas ce qui me fait retenir quoi que ce soit.

La maîtrise, pour moi, c'est être à l'aise avec un sujet, connaître les points primordiaux, et pouvoir s'approprier un code ou une architecture qu'on n'a pas écrit soi-même pour en faire quelque chose. C'est d'ailleurs pour cela que mes notes ont un statut : status/learning, status/practiced, status/mastered. Pas parce que "mastered" veut dire terminé — la tech bouge sans cesse, il y aura toujours du nouveau, des évolutions, des cas inédits. La maîtrise au sens strict est impossible. Mais une base solide, cela reste. Et le statut me dit où j'en suis dessus à un instant T.

Ce que je ne fais pas : les reviews espacées à J+7, J+30. C'est dans mes guidelines, je les ai écrites, je ne les suis pas. Je préfère réactiver par la pratique — si je retouche à Terraform dans 3 mois, je relis ma fiche Terraform à ce moment-là. Plus naturel que de forcer un rythme artificiel.

Évolution : vers du context engineering

Mon vault actuel est top pour le savoir : c'est là que je capitalise les concepts, les patterns, les retours d'expérience, par techno. Mais il a une limite — il sait ce qu'est Terraform, il ne sait pas comment Terraform s'articule avec le reste de la stack sur laquelle je bosse à un instant T. Il manque la vue projet.

Mon prochain step, c'est un deuxième repo, avec un but différent : avoir un contexte global, interconnecté, sur un projet ou un sujet. Pas du savoir générique, du contexte appliqué.

Chez Alan par exemple, c'est exactement ce qui me serait super pratique. La stack est énorme, les composants nombreux, les interactions partout. Si l'IA dispose d'un contexte global et interconnecté du projet — les services, les conventions, les liens entre les briques, ce qui dépend de quoi — elle peut comprendre et mapper ce sur quoi je travaille beaucoup mieux qu'avec une question isolée. Plus besoin de tout réexpliquer à chaque conversation. Le repo serait privé, évidemment, parce qu'il toucherait au contexte interne — mais j'extrairais quand même les patterns réutilisables pour les remettre dans mon vault public sous forme générique.

Dans un contexte perso, même logique. Mon Tech Radar par exemple : c'est un projet séparé du portfolio, avec son propre repo — mais les deux touchent au même site, partagent la même stack, interfèrent au déploiement. Avoir un contexte commun aux deux permettrait à l'IA de savoir ce qui dépend de quoi, sans que je doive lui réexpliquer la relation à chaque conversation.

C'est là que j'essaie de me concentrer maintenant : construire du contexte engineering solide, plutôt que peaufiner des prompts isolés. Un bon prompt sans contexte atteint vite sa limite. Un bon contexte rend même un prompt moyen utile.

À retenir

Obsidian n'est pas l'outil magique. Claude non plus (quoique ?). Ce qui marche, c'est la combinaison : un endroit où poser les choses dans mes mots, une IA qui m'aide à structurer sans dénaturer, et des guidelines claires pour que cette IA bosse avec moi et non à ma place.

Disclaimer : tout cela, c'est ma méthode. Pas une méthode universelle. Je l'ai construite en itérant, en simplifiant, en jetant ce qui ne servait pas. Elle marche pour moi aujourd'hui et elle bougera encore.

Si tu veux t'en inspirer, prends ce qui te parle, laisse le reste, et teste sur tes propres projets. C'est la seule façon de savoir ce qui te convient.