Complement structure

This commit is contained in:
Philippe 2026-03-22 17:36:39 +01:00
parent 54523dc28e
commit 92dfd19b07
48 changed files with 1525 additions and 1 deletions

View file

@ -0,0 +1,28 @@
Génère une session de coaching personnalisée en lisant mon vault PKM.
Lis les fichiers suivants dans cet ordre :
1. `20-areas/perso/soi/ikigai.md` — ma boussole
2. Les 5 derniers fichiers `.md` dans `05-revues/` (hors dossier coaching) — mes revues hebdo récentes
3. Tous les `_index.md` dans `10-projects/` — mes projets en cours
4. Le dernier fichier dans `05-revues/coaching/` — la session précédente et ma réflexion
Ensuite génère une session de coaching structurée en 3 dimensions :
### 1. Alignement (Ikigai)
Observe si mes actions récentes sont cohérentes avec ma boussole.
→ Une observation factuelle + une question puissante
### 2. Performance (Projets / OKRs)
Observe l'avancement réel, les blocages, ce qui stagne.
→ Une observation factuelle + une question puissante
### 3. Équilibre (Rôles)
Observe quels rôles sont présents, absents, sous-investis dans mes revues.
→ Une observation factuelle + une question puissante
### Question centrale de la semaine
La question la plus importante — celle qui peut tout changer.
Style : direct, bienveillant, sans complaisance. Tutoie-moi. Pose des questions, ne donne pas de réponses.
Sauvegarde la session dans `05-revues/coaching/YYYY-MM-DD.md` (date du jour) avec le frontmatter approprié et une section "Ta réflexion" vide à la fin.

3
.gitignore vendored
View file

@ -5,3 +5,6 @@
.trash/ .trash/
*.tmp *.tmp
.DS_Store .DS_Store
_agents/.env
_agents/__pycache__/
_agents/.venv/

0
05-revues/.gitkeep Normal file
View file

View file

48
15-okr/6tm/2026-Q1.md Normal file
View file

@ -0,0 +1,48 @@
---
periode: 2026-Q1
type: okr
debut: 2026-01-01
fin: 2026-03-31
---
# OKRs — Q1 2026
> Référence : [[ikigai]] · [[2026-annuel]]
---
## Objectif 1 —
*Lien avec l'ikigai :*
| Key Result | Cible | Actuel | % |
|---|---|---|---|
| KR1 | | 0 | 0% |
| KR2 | | 0 | 0% |
**Rôle :**
**Projets liés :**
---
## Objectif 2 —
*Lien avec l'ikigai :*
| Key Result | Cible | Actuel | % |
|---|---|---|---|
| KR1 | | 0 | 0% |
| KR2 | | 0 | 0% |
**Rôle :**
**Projets liés :**
---
## Bilan Q1
<!-- À remplir fin mars 2026 -->
- Ce qui a bien marché :
- Ce qui a bloqué :
- À reporter sur Q2 :

101
15-okr/6tm/2026-annuel.md Normal file
View file

@ -0,0 +1,101 @@
---
periode: 2026-annuel
type: okr
organisation: 6TM
---
# OKRs 2026 — 6TM
---
## O1 — Accélérer la croissance verticalisée (Réseaux + Aménagement de la maison)
> Faire des verticales Réseaux et Aménagement de la maison le principal moteur de la croissance 2026, en remportant des comptes cibles grâce à une proposition de valeur verticale prouvée par des impacts business mesurables chez les clients.
| # | Key Result | Cible | Statut |
|---|---|---|---|
| KR1 | Part de CA verticalisé | 55 % au 31/12/2026 (50 % en 2025) | |
| KR2 | Démarche ABM sur 20 comptes cibles | 32 RDV décideurs / an (8 / trimestre) | |
| KR3 | Pipeline qualifié (référence T1) | X M€ — suivi mensuel taux de transfo | |
| KR4 | Nommer responsable verticalisation + tableau de bord CA / marge / pipeline | Avant fin T1 | |
| KR5 | CA nouveaux clients issus leads 2026 (verticales prioritaires) | 600 k€ | |
---
## O2 — Sécuriser la rentabilité et piloter l'activité avec des indicateurs fiables
> Passer d'un pilotage intuitif à un pilotage économique structuré, assumé par le CODIR.
| # | Key Result | Cible | Statut |
|---|---|---|---|
| KR1 | Nouveaux projets cadrés MVP → V1 → V2 | 100 % — revue direction obligatoire > 100 k€ | |
| KR2 | Suivi mensuel par verticale (CA, marge, TJ, non facturé) arbitré en CODIR | Dès T2 | |
| KR3 | Amélioration marge brute globale | +2 points fin 2026 | |
| KR4 | Taux de rendement Factory | > 12 % sur 2026 | |
| KR5 | Deals "à risque / toxiques" revus en CODIR avec décision explicite | 100 % | |
---
## O3 — Industrialiser l'IA : diffusion, qualité et maîtrise des risques
> Faire de l'IA un levier structurant de performance, sans dette technique ni risque opérationnel.
| # | Key Result | Cible | Statut |
|---|---|---|---|
| KR1 | Core Team IA + Lab IA + référents IA par tribu | Avant fin T1 | |
| KR2 | Amélioration TJ moyen via usage structuré IA | +10 % (référence T1, mesure T2T4) | |
| KR3 | Charte IA déployée (sécurité, conformité, éthique) | 0 incident majeur | |
| KR4 | IA évaluée sur 100 % des opportunités commerciales | Taux de rétention cible défini T1 | |
---
## O4 — Accélérer Seenaps : traction SaaS, roadmap claire, déploiements plus rapides
> Installer Seenaps comme un actif stratégique : produit SaaS, moteur de croissance et accélérateur Factory.
| # | Key Result | Cible | Statut |
|---|---|---|---|
| KR1 | MRR licences | 70 k€ au 31/12/2026 | |
| KR2 | Churn < X % rétention nette en valeur > Y % | Référence T1, cibles T2 | |
| KR3 | Équipe produit dédiée + roadmap 3 ans validée | Avant fin T1 | |
| KR4 | Réduction temps moyen de déploiement | -X % via intégration packagée (référence T1) | |
| KR5 | Contribution Seenaps au CA groupe | 1,2 M€ (700 k€ licences + 500 k€ projets Factory) | |
---
## O5 — Rendre la Factory scalable (standardisation sans bureaucratie)
> Industrialiser la production tout en préservant l'agilité et la culture 6TM.
| # | Key Result | Cible | Statut |
|---|---|---|---|
| KR1 | Tronc commun "basiques obligatoires" + zones de liberté par tribu | Avant fin T1 | |
| KR2 | 2 cycles d'audit léger (T2 et T4) | ≥ 80 % conformité aux basiques fin 2026 | |
| KR3 | Pilotage Factory (rituels + 6 indicateurs max) utilisé en CODIR | Dès T2 | |
---
## O6 — Transformer RH & Leadership pour soutenir le changement d'échelle
> Faire évoluer l'organisation, le management et les compétences pour rendre la croissance durable.
| # | Key Result | Cible | Statut |
|---|---|---|---|
| KR1 | Organisation cible clarifiée (RACI RH vs recrutement) | Avant fin T1 | |
| KR2 | Référentiel métiers & compétences v1 (IA, data, produit) | 100 % recrutements et staffing critique dès T2 | |
| KR3 | Chantiers structurants CODIR élargi réalisés | 100 % en 2026 | |
| KR4 | Réduction dépendance opérationnelle aux personnes clés | -X % — remplacement rôles critiques < 3 mois | |
---
## O7 — Construire une offre Data / BI crédible, vendable et scalable (complémentaire IA)
> Positionner le groupe sur la Data pour sécuriser la valeur IA et éviter toute désintermédiation.
| # | Key Result | Cible | Statut |
|---|---|---|---|
| KR1 | Offre Data / BI packagée (diagnostic → gouvernance → plateforme → delivery) + 3 cas d'usage verticaux | Avant fin T2 | |
| KR2 | Capacité Data opérationnelle (1 lead data + 2 ressources) | Avant fin T2 | |
| KR3 | Deals Data / BI signés dont ≥ 1 verticale prioritaire | 3 en 2026 | |
| KR4 | Offre Data / BI industrialisée sur ≥ 1 verticale avec 1 référence réplicable | 2026 | |
| KR5 | Volet Data intégré dans les audits IA | 100 % des audits | |

35
15-okr/perso/2026-Q1.md Normal file
View file

@ -0,0 +1,35 @@
---
periode: 2026-Q1
type: okr
perimetre: perso
debut: 2026-01-01
fin: 2026-03-31
---
# OKRs Perso — Q1 2026
> Référence : [[ikigai]] · [[2026-annuel]]
---
## Objectif 1 —
*Lien avec l'ikigai :*
| Key Result | Cible | Actuel | % |
|---|---|---|---|
| KR1 | | 0 | 0% |
| KR2 | | 0 | 0% |
**Rôle :**
**Projets liés :**
---
## Bilan Q1
<!-- À remplir fin mars 2026 -->
- Ce qui a bien marché :
- Ce qui a bloqué :
- À reporter sur Q2 :

View file

@ -0,0 +1,63 @@
---
periode: 2026-annuel
type: okr
---
# OKRs — 2026 (Annuel)
> Référence : [[ikigai]]
> Ces OKRs annuels se déclinent en OKRs trimestriels.
---
## Objectif 1 —
*Lien avec l'ikigai :*
| Key Result | Cible | Actuel | % |
|---|---|---|---|
| KR1 | | 0 | 0% |
| KR2 | | 0 | 0% |
| KR3 | | 0 | 0% |
**Rôle :**
**Projets liés :**
---
## Objectif 2 —
*Lien avec l'ikigai :*
| Key Result | Cible | Actuel | % |
|---|---|---|---|
| KR1 | | 0 | 0% |
| KR2 | | 0 | 0% |
**Rôle :**
**Projets liés :**
---
## Objectif 3 —
*Lien avec l'ikigai :*
| Key Result | Cible | Actuel | % |
|---|---|---|---|
| KR1 | | 0 | 0% |
| KR2 | | 0 | 0% |
**Rôle :**
**Projets liés :**
---
## Déclinaison trimestrielle
| Trimestre | Fichier | Focus |
|---|---|---|
| Q1 | [[2026-Q1]] | |
| Q2 | [[2026-Q2]] | |
| Q3 | [[2026-Q3]] | |
| Q4 | [[2026-Q4]] | |

View file

View file

View file

View file

View file

@ -0,0 +1,37 @@
---
type: reference
derniere-revision:
---
# Ikigai
> Mon ikigai est la zone d'intersection entre ce que j'aime, ce en quoi je suis bon, ce dont le monde a besoin, et ce pour quoi je peux être rémunéré.
## Ce que j'aime
-
## Ce en quoi je suis bon
-
## Ce dont le monde a besoin
-
## Ce pour quoi je peux être rémunéré
-
---
## Mon ikigai
> *La synthèse en une phrase ou un paragraphe.*
---
## Réflexions et évolutions
<!-- Dater chaque entrée pour voir l'évolution dans le temps -->

View file

View file

View file

View file

View file

@ -0,0 +1,36 @@
---
type: 1to1-trimestre
periode: 2026-Q1
collaborateur: Ludovic
---
# 1to1 — Ludovic · 2026-Q1
> Référence : [[_contexte]]
---
## 2026-03-22
**Humeur / énergie :** 🟢 🟡 🔴
**Points abordés :**
-
**Feedback donné :**
-
**Actions**
| Action | Responsable | Échéance |
|---|---|---|
| | | |
---
## Bilan du trimestre
**Progression sur les objectifs :**
-
**Feedback récurrent à reporter dans [[_contexte]] :**
-

View file

@ -0,0 +1,33 @@
---
type: 1to1-contexte
role:
anciennete:
---
# _contexte — Ludovic
## Profil
- **Rôle :**
- **Ancienneté :**
- **Mode de fonctionnement :**
## Forces
-
## Axes de développement
-
## Objectifs
| Objectif | Échéance | Statut |
|---|---|---|
| | | |
## Feedback récurrent
**Points positifs :**
-
**Points de vigilance :**
-
## Aspirations
-

View file

View file

0
30-resources/ia/.gitkeep Normal file
View file

View file

View file

@ -0,0 +1,69 @@
# Glossaire Product Management
Termes et concepts utilisés par les Product Managers.
---
## Fichiers par catégorie
### [[product-market-fit|Product-Market Fit]]
Le socle de tout produit. PMF, Insight, Aha Moment.
### [[metriques-revenus|Métriques Revenus (SaaS)]]
ARR, MRR, NRR, Churn, ACV, CAC, LTV
### [[metriques-engagement|Métriques Engagement & Croissance Virale]]
DAU/MAU, Retention, NPS, K-Factor
### [[croissance-growth|Croissance & Growth Strategy]]
PLG, Flywheel, Inbound vs Outbound
### [[frameworks-priorisation|Frameworks de Priorisation]]
Jobs-to-be-Done, RICE, ICE, Kano Model
### [[finance-startup|Finance Startup]]
Runway, Burn Rate, Fundraising, Cap Table
### [[process-produit|Process Produit]]
Discovery vs Delivery, Feature Flag, A/B Test, Roadmap, Sprint
---
## Index alphabétique
| Terme | Fichier |
|---|---|
| A/B Test | [[process-produit]] |
| ACV | [[metriques-revenus]] |
| Aha Moment | [[product-market-fit]] |
| ARR | [[metriques-revenus]] |
| Burn Rate | [[finance-startup]] |
| CAC | [[metriques-revenus]] |
| Cap Table | [[finance-startup]] |
| Churn | [[metriques-revenus]] |
| DAU / MAU | [[metriques-engagement]] |
| Discovery vs Delivery | [[process-produit]] |
| Feature Flag | [[process-produit]] |
| Flywheel | [[croissance-growth]] |
| Fundraising | [[finance-startup]] |
| ICE Scoring | [[frameworks-priorisation]] |
| Inbound vs Outbound | [[croissance-growth]] |
| Insight | [[product-market-fit]] |
| Jobs-to-be-Done (JTBD) | [[frameworks-priorisation]] |
| K-Factor | [[metriques-engagement]] |
| Kano Model | [[frameworks-priorisation]] |
| LTV | [[metriques-revenus]] |
| MRR | [[metriques-revenus]] |
| NPS | [[metriques-engagement]] |
| NRR | [[metriques-revenus]] |
| PLG | [[croissance-growth]] |
| Product-Market Fit | [[product-market-fit]] |
| Retention | [[metriques-engagement]] |
| RICE Scoring | [[frameworks-priorisation]] |
| Roadmap | [[process-produit]] |
| Runway | [[finance-startup]] |
| Sprint | [[process-produit]] |
---
**Tags** : #product #glossaire #pm #startup

View file

@ -0,0 +1,143 @@
# North Star Metric
## Définition
La **North Star Metric** est **LA métrique unique** qui :
- Capture le mieux la **valeur** que vous créez
- Guide **toutes les décisions** stratégiques
- Aligne **toute l'organisation** vers un objectif commun
- Prédit le **succès à long terme**
C'est votre "étoile polaire" : quand vous êtes perdus ou face à un choix difficile, vous regardez cette métrique pour savoir quelle direction prendre.
---
## 📊 Caractéristiques d'une bonne North Star
Une North Star efficace doit être **CLEAR** :
| Critère | Signification | Exemple : TJM +50€ |
|---------|---------------|-------------------|
| **C**lear (Claire) | Compréhensible par tous | ✅ "Augmenter le TJM de 50€" = simple et clair |
| **L**eading (Prédictive) | Prédit le succès futur | ✅ +50€ TJM = rentabilité, compétitivité, pérennité |
| **E**asily measured (Mesurable) | Calculable régulièrement | ✅ Revenus facturés / jours travaillés (mensuel) |
| **A**ctionable (Actionnable) | On peut l'influencer directement | ✅ Adoption IA → productivité → TJM |
| **R**elevant (Pertinente) | Reflète la vraie valeur créée | ✅ ROI concret de la transformation IA |
---
## 🎯 Pourquoi c'est puissant ?
### 1. Elle capture la VALEUR créée
- Pas juste une "vanity metric" (ex: "on utilise l'IA")
- Mais un impact business tangible (ex: "l'IA génère +50€/jour de valeur")
### 2. Elle aligne TOUS les efforts
- **Équipe tech** : adopter l'IA pour être plus productif
- **Management** : former et équiper l'équipe
- **Commercial** : valoriser les gains auprès des clients
- **Direction** : investir dans la transformation
### 3. Elle guide les DÉCISIONS
Exemples de décisions guidées par la North Star :
- "Doit-on investir 5k€ dans un outil ?" → Si ça augmente la North Star, OUI
- "Faut-il passer 2 semaines en formation ?" → Si ça booste la métrique, OUI
- "Doit-on documenter nos gains ?" → Si ça justifie une revalorisation (North Star up), OUI
### 4. Elle est MOTIVANTE
- Chiffre concret et compréhensible
- Impact partagé : toute l'équipe contribue et bénéficie
- Célébrations régulières possibles (jalons visibles)
---
## 🔄 North Star vs OKRs
| Concept | Définition | Exemple |
|---------|------------|---------|
| **North Star** | 1 métrique ultime qui guide tout | TJM +50€ |
| **OKRs** | Objectifs + Key Results détaillés | 3 objectifs, 16 KR au total |
| **Relation** | Les OKRs soutiennent la North Star | KR1.1 (PAI) + KR1.2 (adoption) → North Star |
**Analogie** :
- **North Star** = Le sommet de la montagne que vous voulez atteindre
- **OKRs** = Les différents chemins et étapes pour y arriver
- **KRs** = Les jalons mesurables sur chaque chemin
---
## 💡 Exemples de North Star célèbres
| Entreprise | North Star Metric | Pourquoi |
|------------|-------------------|----------|
| **Facebook** | Daily Active Users (DAU) | Plus d'utilisateurs actifs = plus de valeur réseau |
| **Airbnb** | Nights Booked | Capture la vraie valeur : des réservations effectives |
| **Slack** | Messages envoyés par utilisateur | Usage réel de la plateforme = engagement |
| **Netflix** | Watch time (heures visionnées) | Temps de visionnage = satisfaction client |
| **Spotify** | Time Listening | Écoute = valeur pour l'utilisateur |
| **Amazon** | Purchases per month | Achats = valeur créée pour clients |
---
## 🚀 North Star en action
### Scénario 1 : Décision d'investissement
**Question** : "Faut-il acheter des licences pour toute l'équipe (300€/mois) ?"
**Sans North Star** : Débat sans fin sur "est-ce utile ?", "on verra plus tard", etc.
**Avec North Star** :
- Si l'outil → gain 2h/semaine/personne
- 2h/semaine × 4 semaines = 8h/mois économisées
- 8h × valeur/heure = ROI > 300€
- **Décision** : OUI, on investit → ça contribue à la North Star
### Scénario 2 : Priorisation
**Question** : "Cette semaine, je me concentre sur quoi ?"
**Sans North Star** : Urgences du moment, dispersion
**Avec North Star** :
- Action A : Impact élevé sur North Star → HAUTE priorité
- Action B : Impact faible sur North Star → BASSE priorité
- **Décision** : Je fais A, je délègue ou annule B
### Scénario 3 : Mesure du succès
**Question** : "Est-ce que l'année est un succès ?"
**Sans North Star** : Vague sentiment "on a fait des trucs"
**Avec North Star** :
- North Star atteinte à 100% → ✅ SUCCÈS
- North Star atteinte à 60% → 🟡 Succès partiel
- **Résultat** : Clair, objectif, mesurable
---
## ✅ Résumé
> **La North Star transforme une vision floue en un objectif mesurable qui guide chaque décision.**
**Checklist pour votre North Star** :
- [ ] Une seule métrique (pas 3 ou 5)
- [ ] Compréhensible par tous
- [ ] Mesurable régulièrement (hebdo/mensuel)
- [ ] Actionnable (on peut l'influencer)
- [ ] Reflète la vraie valeur créée
- [ ] Prédit le succès à long terme
- [ ] Aligne toute l'organisation
---
## Références
- [Amplitude - What is a North Star Metric?](https://amplitude.com/north-star)
- [Product Plan - North Star Metric](https://www.productplan.com/glossary/north-star-metric/)
- Livre : *Lean Analytics* par Alistair Croll & Benjamin Yoskovitz
---
**Tags** : #product #metrics #strategy #okr #kpi

View file

@ -0,0 +1,69 @@
# Croissance & Growth Strategy
Les modèles et stratégies qui expliquent comment une startup croît.
---
### PLG
Le **PLG** (Product-Led Growth) est une stratégie de croissance où **le produit lui-même est le principal vecteur d'acquisition, de rétention et d'expansion**.
**Principe** : laisse les utilisateurs expérimenter le produit avant d'acheter (freemium, free trial) → le produit convainc à la place des sales.
**Exemples emblématiques** : Slack, Notion, Figma, Dropbox, Calendly
**PLG vs SLG (Sales-Led Growth)** :
| | PLG | SLG |
|---|---|---|
| Premier contact | Le produit | Un commercial |
| Décision d'achat | L'utilisateur | Le décideur |
| CAC | Faible | Élevé |
| Cycle de vente | Court | Long |
| Idéal pour | SMB, outils dev, B2C | Enterprise, deals complexes |
> Le PLG nécessite un onboarding irréprochable : l'utilisateur doit atteindre le "aha moment" seul.
---
### Flywheel
Le **Flywheel** (volant d'inertie) est un modèle de croissance où **chaque élément du système alimente le suivant**, créant une boucle vertueuse auto-entretenue.
**Concept popularisé par** Jeff Bezos pour Amazon :
> Plus de clients → plus de vendeurs → meilleure sélection → expérience améliorée → plus de clients
**Différence avec le funnel** :
- **Funnel** : linéaire, le client "sort" au bout
- **Flywheel** : circulaire, les clients satisfaits réalimentent la croissance
**Exemple Airbnb** :
> Plus d'hôtes → plus de choix → plus de voyageurs → plus de revenus pour les hôtes → plus d'hôtes
---
### Inbound vs Outbound
**Deux approches** pour trouver des clients :
**Inbound** : les clients viennent à toi
- SEO, content marketing, bouche-à-oreille, communauté
- Coût faible à long terme
- Signal PMF fort : si les gens viennent sans qu'on les pousse, le produit répond à un besoin réel
**Outbound** : tu vas chercher les clients
- Cold email, cold calling, LinkedIn outreach, publicité payante
- Résultats plus immédiats, coût plus élevé
- Signal PMF faible si c'est le seul levier
| | Inbound | Outbound |
|---|---|---|
| Qui initie ? | Le client | Toi |
| Exemples | SEO, content, bouche-à-oreille | Cold email, ads, prospection |
| Coût | Faible à long terme | Élevé, résultats immédiats |
| Signal PMF | Fort | Faible |
> En early-stage startup, si tu dois faire beaucoup d'outbound pour avoir des clients, c'est souvent un signal que le Product-Market Fit n'est pas encore atteint.
---
**Tags** : #product #growth #plg #flywheel #acquisition #strategy

View file

@ -0,0 +1,60 @@
# Finance Startup
Les concepts financiers essentiels pour comprendre la santé et la survie d'une startup.
---
### Runway
Le **Runway** est le **nombre de mois avant que la startup manque de cash** si elle ne lève pas de fonds ou ne devient pas rentable.
**Calcul** :
> Runway = Cash disponible / Burn rate mensuel
**Exemple** :
- 500 000€ en banque
- Burn rate de 50 000€/mois → **10 mois de runway**
**Règles de survie** :
- Commencer à lever des fonds quand il reste **6-9 mois** de runway
- En dessous de **3 mois** → urgence absolue
- Objectif sain : maintenir **12-18 mois** de runway
---
### Burn Rate
Le **Burn Rate** est la **vitesse à laquelle une startup dépense son cash**.
**Deux versions** :
- **Gross Burn** : total des dépenses mensuelles
- **Net Burn** : dépenses - revenus = cash effectivement perdu chaque mois
**Exemple** :
- Dépenses : 80 000€/mois
- Revenus : 30 000€/mois
- **Net Burn = 50 000€/mois**
> Un burn rate élevé n'est pas forcément mauvais s'il finance une croissance rapide. Le problème, c'est brûler du cash sans croître.
---
### Fundraising (levée de fonds)
Les **rounds de financement** suivent une progression standard :
| Round | Stade | Montant typique | Investisseurs |
|---|---|---|---|
| **Pre-seed** | Idée / MVP | 50k - 500k€ | Business angels, famille |
| **Seed** | PMF en cours | 500k - 3M€ | Angels, early-stage VCs |
| **Series A** | PMF prouvé, scale | 3M - 15M€ | VCs |
| **Series B** | Croissance accélérée | 15M - 50M€ | VCs, growth funds |
| **Series C+** | Expansion internationale | 50M€+ | Late-stage VCs, PE |
**Cap Table** (Capitalization Table) : tableau qui liste tous les actionnaires et leur % de participation dans la startup.
**Dilution** : à chaque levée, les fondateurs cèdent des parts → leur % diminue, mais la valeur absolue de leurs parts augmente si la valorisation monte.
---
**Tags** : #product #finance #startup #runway #burnrate #fundraising

View file

@ -0,0 +1,76 @@
# Frameworks de Priorisation PM
Les outils utilisés par les Product Managers pour décider quoi construire, dans quel ordre, et pourquoi.
---
### Jobs-to-be-Done (JTBD)
Le **Jobs-to-be-Done** est un framework qui part du principe que **les gens "embauchent" un produit pour accomplir une tâche dans leur vie**, pas pour ses fonctionnalités.
**Formulation** :
> "Quand [situation], je veux [motivation], pour que [résultat attendu]."
**Exemple** :
- ❌ "L'utilisateur veut une perceuse de 10mm"
- ✅ "Quand je dois accrocher un tableau, je veux faire un trou rapidement, pour que ma maison soit décorée sans effort"
**Usage PM** : identifier les vrais jobs aide à prioriser les features qui ont un impact réel plutôt que celles qui semblent logiques sur le papier.
---
### RICE Scoring
Le **RICE** est un framework de **priorisation des features** qui évalue chaque initiative sur 4 critères.
**Formule** :
> Score RICE = (Reach × Impact × Confidence) / Effort
| Critère | Définition | Exemple |
|---|---|---|
| **R**each | Combien d'utilisateurs touchés ? | 500 users/mois |
| **I**mpact | Quel impact sur l'objectif ? (0.25 / 0.5 / 1 / 2 / 3) | 2 = fort |
| **C**onfidence | Degré de certitude % | 80% |
| **E**ffort | Jours-personne nécessaires | 5 jours |
> Score = (500 × 2 × 0.8) / 5 = **160**
Plus le score est élevé, plus la feature est prioritaire. Permet de dépolitiser la priorisation.
---
### ICE Scoring
L'**ICE** est une version simplifiée du RICE, souvent utilisée en early-stage.
**Formule** :
> Score ICE = Impact × Confidence × Ease (facilité)
Chaque critère noté de 1 à 10 :
- **Impact** : quel effet sur la métrique clé ?
- **Confidence** : à quel point es-tu sûr de cet impact ?
- **Ease** : à quel point c'est facile à implémenter ?
> Rapide à calculer, moins précis que RICE, idéal pour des backlogs courts.
---
### Kano Model
Le **modèle de Kano** est un framework qui classe les features selon leur **impact sur la satisfaction client**.
**5 catégories** :
| Catégorie | Définition | Exemple |
|---|---|---|
| **Basic needs** (must-have) | Attendu, son absence = insatisfaction | Login sécurisé |
| **Performance** (linear) | Plus c'est bien fait, plus c'est apprécié | Vitesse de chargement |
| **Delighters** (wow) | Inattendu, crée de l'enthousiasme | Animation surprise |
| **Indifferent** | Ni satisfait ni insatisfait | Couleur du footer |
| **Reverse** | Certains aiment, d'autres détestent | Mode sombre |
**Usage PM** : ne pas passer du temps sur les "indifferent", s'assurer que les "must-have" sont irréprochables, ajouter des "delighters" pour se différencier.
---
**Tags** : #product #frameworks #prioritization #jtbd #rice #kano #backlog

View file

@ -0,0 +1,86 @@
# Métriques Engagement & Croissance Virale
Les métriques qui mesurent comment les utilisateurs interagissent avec le produit et le propagent.
---
### DAU / MAU
**DAU** (Daily Active Users) et **MAU** (Monthly Active Users) mesurent **l'engagement réel** de tes utilisateurs.
- **DAU** : nombre d'utilisateurs uniques actifs sur 1 jour
- **MAU** : nombre d'utilisateurs uniques actifs sur 30 jours
**Le ratio DAU/MAU** = stickiness (adhérence du produit)
> DAU/MAU × 100 = % des utilisateurs mensuels qui reviennent chaque jour
**Benchmarks** :
- < 10% : produit peu engageant
- 20% : correct
- > 50% : produit très addictif (Facebook ~65%, WhatsApp ~85%)
> "Active" doit être défini précisément : ouvrir l'app ne suffit pas, il faut une action à valeur.
---
### Retention
La **Retention** (rétention) mesure **la proportion d'utilisateurs qui reviennent** utiliser ton produit après leur première visite.
**Courbe de rétention** : on trace le % d'utilisateurs encore actifs à J+1, J+7, J+30, J+90...
**Trois types** :
- **D1 retention** : % qui revient le lendemain (onboarding)
- **D7 retention** : % encore actif après 1 semaine (habitude naissante)
- **D30 retention** : % encore actif après 1 mois (rétention long terme)
**Signal PMF via la rétention** :
- Courbe qui s'aplatit (plateau) → tu as un core d'utilisateurs fidèles → signal PMF
- Courbe qui tombe à zéro → pas de PMF
---
### NPS
Le **NPS** (Net Promoter Score) mesure **la probabilité que tes clients te recommandent** à quelqu'un d'autre.
**Question unique** : "Sur une échelle de 0 à 10, quelle est la probabilité que vous recommandiez [produit] à un ami ou collègue ?"
**Calcul** :
- 9-10 → **Promoteurs**
- 7-8 → Passifs (neutres)
- 0-6 → **Détracteurs**
> NPS = % Promoteurs - % Détracteurs (score entre -100 et +100)
**Benchmarks** :
- < 0 : problème sérieux
- 0-30 : correct
- 30-70 : bon
- > 70 : excellent (Apple, Tesla gravitent autour de 70+)
> Un NPS élevé est souvent corrélé à un fort bouche-à-oreille et un churn faible.
---
### K-Factor (Viral Coefficient)
Le **K-Factor** mesure **le coefficient de viralité d'un produit** : combien de nouveaux utilisateurs chaque utilisateur existant génère.
**Calcul** :
> K = nombre d'invitations envoyées × taux de conversion des invitations
**Exemple** :
- Chaque utilisateur invite en moyenne 5 personnes
- 20% des invités s'inscrivent
- **K = 5 × 0.2 = 1.0**
**Lecture** :
- K < 1 : croissance organique possible mais limitée
- K = 1 : chaque user en recrute un → croissance linéaire
- K > 1 : croissance exponentielle (viralité) → rare et précieux
> Dropbox (referral +500MB de stockage) a atteint K > 1, multipliant sa base par 60 en 15 mois.
---
**Tags** : #product #metrics #engagement #retention #nps #growth #viral

View file

@ -0,0 +1,131 @@
# Métriques Revenus (SaaS)
Les métriques financières fondamentales des startups à modèle récurrent (SaaS).
---
### ARR
L'**ARR** (Annual Recurring Revenue) est le **revenu récurrent annualisé**. C'est la métrique fondamentale des startups SaaS (Software as a Service).
**Calcul simple** :
> ARR = MRR × 12
> (MRR = Monthly Recurring Revenue = revenu mensuel récurrent)
**Exemple** :
- 50 clients × 100€/mois = 5 000€ MRR → **60 000€ ARR**
**Pourquoi c'est important** :
- Prévisibilité des revenus (pas de one-shot)
- Valorisation de la startup (multiple de l'ARR)
- Benchmark de croissance : doubler son ARR chaque année = bonne trajectoire
---
### MRR
Le **MRR** (Monthly Recurring Revenue) est le **revenu récurrent mensuel**. C'est le pouls financier d'une startup SaaS — tu le regardes chaque mois comme un médecin regarde le rythme cardiaque.
**Calcul** : `MRR = nombre de clients × prix mensuel moyen`
**Les 4 composantes du MRR** :
- **New MRR** : revenus des nouveaux clients ce mois
- **Expansion MRR** : upsells/upgrades des clients existants
- **Churned MRR** : revenus perdus (clients partis ou downgradés)
- **Net New MRR** = New MRR + Expansion MRR - Churned MRR
> Un MRR en croissance = bonne santé. Un MRR stagnant malgré de nouveaux clients = churn qui ronge la croissance.
---
### NRR
Le **NRR** (Net Revenue Retention) mesure **si tes clients existants dépensent plus ou moins avec le temps**, sans compter les nouveaux clients.
**Calcul** :
> NRR = (MRR début de période + Expansion - Churn) / MRR début de période × 100
**Lecture** :
- **NRR > 100%** : tes clients existants dépensent plus → croissance même sans nouveaux clients (Saint Graal)
- **NRR = 100%** : stable, les expansions compensent exactement le churn
- **NRR < 100%** : tu perds de la valeur sur ta base existante → problème de rétention
**Benchmarks startup SaaS** :
- Bon : > 110%
- Excellent : > 120% (Snowflake, Datadog tournent à 130%+)
---
### Churn
Le **Churn** (ou taux d'attrition) mesure **ce que tu perds** : clients ou revenus.
**Deux types** :
- **Customer Churn** : % de clients qui partent sur une période
> 10 clients perdus / 100 clients au début du mois = 10% de churn mensuel
- **Revenue Churn** : % du MRR perdu (plus précis car pondéré par la valeur)
**Pourquoi c'est critique** :
- 5% de churn mensuel = ~46% de ta base perdue en 1 an
- Le churn détruit la croissance silencieusement ("leaky bucket")
**Churn acceptable** (mensuel) :
- Early-stage : < 5%
- Growth-stage : < 2%
- Enterprise SaaS : < 1%
> Le churn est souvent le symptôme d'un PMF raté ou d'un onboarding défaillant.
---
### ACV
L'**ACV** (Annual Contract Value) est la **valeur annuelle d'un contrat client**, en excluant les frais one-shot (setup, formation, etc.).
**Différence ACV vs ARR** :
- **ACV** = valeur d'un contrat client individuel
- **ARR** = somme de tous les ACV actifs
**Usage** : L'ACV guide la stratégie commerciale.
- ACV < 5 000 self-service, sales automatisé
- ACV 5 000-50 000€ → inside sales (téléphone, demo)
- ACV > 50 000€ → enterprise sales (cycle long, contrats négociés)
---
### CAC
Le **CAC** (Customer Acquisition Cost) est le **coût total pour acquérir un nouveau client**.
**Calcul** :
> CAC = total dépenses sales & marketing / nombre de nouveaux clients acquis
**Exemple** :
- 50 000€ dépensés en sales + marketing ce trimestre
- 25 nouveaux clients → **CAC = 2 000€**
**Le ratio magique : LTV/CAC**
- < 1 : tu perds de l'argent sur chaque client insoutenable
- = 3 : équilibre sain (règle d'or en SaaS)
- > 5 : tu sous-investis en acquisition, tu pourrais croître plus vite
---
### LTV
Le **LTV** (Lifetime Value, ou Customer Lifetime Value / CLV) est la **valeur totale qu'un client génère sur toute sa durée de vie** chez toi.
**Calcul simplifié** :
> LTV = MRR moyen par client / taux de churn mensuel
**Exemple** :
- Client paie 200€/mois, churn mensuel de 2%
- LTV = 200 / 0,02 = **10 000€**
**Usage** :
- Combiné au CAC : si LTV = 10 000€ et CAC = 2 000€ → ratio LTV/CAC = 5 → très bon
- Guide les décisions d'investissement en acquisition et rétention
---
**Tags** : #product #metrics #saas #revenue #arr #mrr #churn #cac #ltv

View file

@ -0,0 +1,91 @@
# Process Produit
Les méthodes et pratiques opérationnelles du quotidien d'une équipe produit.
---
### Discovery vs Delivery
**Deux phases distinctes** du travail d'un PM :
**Product Discovery** (trouver quoi construire) :
- Comprendre les besoins utilisateurs
- Tester des hypothèses rapidement (prototypes, interviews)
- Valider avant de coder
- Outils : user interviews, prototypes, A/B tests, smoke tests
**Product Delivery** (construire ce qu'on a validé) :
- Développer les features validées
- Gérer le sprint, les specs, les tickets
- Livrer en production
- Outils : sprints agiles, roadmap, backlog
> L'erreur classique : aller directement en Delivery sans Discovery → construire des features que personne ne veut.
---
### Feature Flag
Un **Feature Flag** (ou feature toggle) est un mécanisme technique qui permet d'**activer ou désactiver une feature sans déployer de nouveau code**.
**Usages** :
- **Rollout progressif** : activer la feature pour 1% des users, puis 10%, puis 100%
- **A/B testing** : groupe A voit la feature, groupe B non
- **Kill switch** : désactiver immédiatement si bug critique en prod
- **Beta users** : donner accès à certains clients avant tout le monde
> Permet de découpler le déploiement technique de la mise en production commerciale.
---
### A/B Test
Un **A/B test** est une **expérience contrôlée** où deux versions d'une même chose sont comparées auprès d'utilisateurs réels pour déterminer laquelle performe mieux.
**Principe** :
- Groupe A (contrôle) : version actuelle
- Groupe B (variante) : version modifiée
- On mesure une métrique clé sur les deux groupes
**Exemple** :
- A : bouton "S'inscrire" en gris
- B : bouton "S'inscrire" en vert
- Résultat : B convertit 15% de plus → on déploie B
**Règles d'or** :
- Tester **une seule variable à la fois**
- Attendre la **significativité statistique** (ne pas arrêter trop tôt)
- Définir la métrique de succès **avant** de lancer le test
---
### Roadmap
La **Roadmap produit** est la **représentation visuelle du plan à moyen terme** : ce qui sera construit, dans quel ordre, et pourquoi.
**Deux types** :
- **Timeline roadmap** : features associées à des dates (risqué, souvent inexact)
- **Now / Next / Later** : horizon temporel souple, plus honnête sur l'incertitude
**Ce que la roadmap n'est PAS** :
- Un contrat → les priorités changent
- Une liste exhaustive de tout ce qu'on va faire
- Un backlog détaillé de tickets
> La roadmap répond à "où allons-nous et pourquoi", pas à "comment on y va".
---
### Sprint
Un **Sprint** est une **période de travail courte et fixe** (généralement 1 à 2 semaines) durant laquelle l'équipe s'engage à livrer un ensemble défini de fonctionnalités.
**Cérémonies classiques** (méthode Scrum) :
- **Sprint Planning** : choisir ce qu'on fait ce sprint
- **Daily Standup** : point quotidien de 15 min (blocages, avancement)
- **Sprint Review** : démo de ce qui a été fait
- **Retrospective** : améliorer le process de l'équipe
---
**Tags** : #product #process #agile #discovery #delivery #roadmap #sprint

View file

@ -0,0 +1,73 @@
# Product-Market Fit
Le socle fondateur de n'importe quel produit.
---
### Product-Market Fit
Le **Product-Market Fit** désigne le moment où **un produit répond parfaitement à un besoin réel et important sur un marché donné**.
Tu as atteint le Product-Market Fit quand :
- Ton produit **résout un problème concret** pour tes clients.
- Les utilisateurs **l'adoptent naturellement**, sans trop d'efforts marketing.
- Les ventes ou l'usage **croissent rapidement**.
- Les retours clients sont **majoritairement positifs**.
**Comment le mesurer** :
- La rétention s'aplatit (courbe plateau) → voir [[metriques-engagement]]
- Le NPS est élevé (> 40-50)
- L'acquisition est majoritairement inbound → voir [[croissance-growth]]
- Sean Ellis Test : "Seriez-vous très déçu si ce produit disparaissait ?" → > 40% de "oui" = signal PMF
---
### Insight
**Un insight est une observation ou une compréhension profonde et subtile d'un sujet ou d'une situation.**
En contexte produit, l'insight est ce que tu as compris que peu de gens ont vu — sur un problème utilisateur, un marché, un comportement.
**Structure d'un bon insight produit** :
> "Quels problèmes ton produit résout, pourquoi il y a une opportunité, et qu'est-ce que tu as compris que peu de gens ont vus ?"
**Exemple** :
- ❌ Observation : "Les gens utilisent des tableurs pour gérer leurs projets"
- ✅ Insight : "Les gens utilisent des tableurs pour gérer leurs projets parce qu'ils veulent de la flexibilité totale, pas parce qu'ils aiment les tableurs — ils acceptent la friction faute de mieux"
---
### Aha Moment
L'**Aha Moment** est l'**instant précis où un utilisateur comprend et ressent la valeur réelle de ton produit** pour la première fois.
**Exemples** :
- Facebook : "Wow, j'ai retrouvé des gens que je ne voyais plus depuis des années"
- Dropbox : première fois qu'un fichier apparaît synchronisé sur deux appareils
- Slack : quand toute l'équipe répond dans un channel en temps réel
**Pourquoi c'est critique** : les utilisateurs qui atteignent l'aha moment restent. Les autres partent.
> Le job du PM en onboarding : **minimiser le temps jusqu'à l'aha moment**.
---
### Avant et après le PMF
| Avant PMF | Après PMF |
|---|---|
| Ventes difficiles, beaucoup d'outbound | Les clients viennent d'eux-mêmes (inbound) |
| Rétention faible, churn élevé | Courbe de rétention qui s'aplatit |
| Feedback contradictoire | Feedback convergent sur les mêmes valeurs |
| Croissance en dents de scie | Croissance régulière et prévisible |
| L'équipe doute du produit | L'équipe sait pourquoi les clients restent |
---
**Voir aussi** :
- [[metriques-engagement]] — Retention, NPS, DAU/MAU
- [[metriques-revenus]] — ARR, MRR, Churn
- [[croissance-growth]] — Inbound/Outbound, PLG
- [[frameworks-priorisation]] — Jobs-to-be-Done
**Tags** : #product #pmf #strategy #foundation

View file

View file

View file

View file

View file

View file

@ -0,0 +1,35 @@
---
type: 1to1-contexte
role:
anciennete:
---
# _contexte — {{Prénom Nom}}
## Profil
- **Rôle :**
- **Ancienneté :**
- **Mode de fonctionnement :** <!-- motivations, style de communication, ce qui le/la bloque -->
## Forces
-
## Axes de développement
-
## Objectifs
<!-- Mis à jour chaque trimestre -->
| Objectif | Échéance | Statut |
|---|---|---|
| | | |
## Feedback récurrent
**Points positifs :**
-
**Points de vigilance :**
-
## Aspirations
<!-- Où veut-il/elle aller à moyen terme ? -->
-

View file

@ -0,0 +1,53 @@
---
type: 1to1-trimestre
periode:
collaborateur:
---
# 1to1 — {{Prénom}} · {{YYYY-QN}}
> Référence : [[_contexte]]
---
## {{YYYY-MM-DD}}
**Humeur / énergie :** 🟢 🟡 🔴
**Points abordés :**
-
**Feedback donné :**
-
**Actions**
| Action | Responsable | Échéance |
|---|---|---|
| | | |
---
## {{YYYY-MM-DD}}
**Humeur / énergie :** 🟢 🟡 🔴
**Points abordés :**
-
**Feedback donné :**
-
**Actions**
| Action | Responsable | Échéance |
|---|---|---|
| | | |
---
## Bilan du trimestre
**Progression sur les objectifs :**
-
**Feedback récurrent à reporter dans [[_contexte]] :**
-

47
99-templates/okr.md Normal file
View file

@ -0,0 +1,47 @@
---
periode: YYYY-QN | YYYY-annuel
type: okr
---
# OKRs — {{periode}}
> Référence : [[ikigai]]
---
## Objectif 1 — {{titre inspirant}}
*Pourquoi c'est important (lien avec l'ikigai ou le rôle)*
| Key Result | Cible | Actuel | % |
|---|---|---|---|
| KR1 | | 0 | 0% |
| KR2 | | 0 | 0% |
| KR3 | | 0 | 0% |
**Rôle :** <!-- cto / codir / parent / soi... -->
**Projets liés :** <!-- [[projet-x]] -->
---
## Objectif 2 — {{titre inspirant}}
*Pourquoi c'est important*
| Key Result | Cible | Actuel | % |
|---|---|---|---|
| KR1 | | 0 | 0% |
| KR2 | | 0 | 0% |
**Rôle :**
**Projets liés :**
---
## Bilan de période
<!-- À remplir en fin de période -->
- Ce qui a bien marché :
- Ce qui a bloqué :
- À reporter sur la prochaine période :

29
99-templates/projet.md Normal file
View file

@ -0,0 +1,29 @@
---
statut: actif | en-attente | idée | terminé
role: cto | codir | management | dsi | seenaps | parent | conjoint | ami | soi
objectif:
echeance:
okr:
---
# {{Nom du projet}}
## Résultat attendu
> *En une phrase : à quoi ressemble le succès de ce projet ?*
## Pourquoi ce projet
> *Lien avec mon ikigai ou mon rôle*
## Prochaine action
-
## Notes et avancement
<!-- Dater chaque entrée -->
## Ressources liées
-

View file

@ -0,0 +1,50 @@
---
date:
semaine:
---
# Revue hebdomadaire — {{date}}
## Phase 1 — Fermer la semaine (5 min)
**Ce qui s'est bien passé :**
-
**Ce que j'aurais fait différemment :**
-
**Inbox vidée ?** ☐
---
## Phase 2 — Préparer la semaine (10 min)
> Une seule chose importante par rôle
| Rôle | Mon engagement cette semaine |
|------|------------------------------|
| Parent | |
| Conjoint | |
| Social | |
| Soi | |
| CTO | |
| Codir | |
| Management | |
| DSI | |
| Seenaps | |
---
## Phase 3 — Intention (5 min)
**Mes 3 priorités :**
1.
2.
3.
**Est-ce que cette semaine me rapproche de qui je veux être ?**
---
*Prochaine revue : dimanche {{semaine+1}}*

22
99-templates/synthese.md Normal file
View file

@ -0,0 +1,22 @@
---
type: livre | article | podcast | video
auteur:
source:
date:
tags: []
---
# Titre
## Idées clés
-
## Synthèse personnelle
## Citations / extraits
## Ce que je vais appliquer
## Liens avec d'autres notes

58
CLAUDE.md Normal file
View file

@ -0,0 +1,58 @@
# Contexte PKM — Philippe Aulnette
## Profil
CTO, membre du Codir, DSI, Management d'équipe et CTPO de la solution Seenaps. Basé en France, interface en français.
## Méthode
Ce PKM repose sur trois piliers complémentaires :
- **Covey** ("Priorités aux priorités") — organisation par rôles, revue hebdomadaire
- **Ikigai** — boussole de purpose, révisée périodiquement
- **OKRs** — objectifs annuels déclinés en trimestriels, liés aux projets
## Rôles
**Perso :** Parent · Conjoint · Social · Soi
**Pro :** CTO · Codir · Management · DSI · Seenaps
## Structure du vault
```
00-inbox/ Capture brute — traiter lors de la revue
05-revues/ Revues hebdomadaires (dimanche soir, 20 min)
└── coaching/ Sessions de coaching générées par /coaching
10-projects/ Projets actifs (flat, frontmatter statut/rôle)
15-okr/ OKRs annuels et trimestriels
20-areas/ Rôles de vie
├── perso/ parent / conjoint / social / soi
└── pro/ cto / codir / management / dsi / seenaps
30-resources/ Knowledge base par domaine (format = métadonnée)
├── tech/ architecture / securite / data / dev
├── management/ leadership / equipe / organisation
├── strategie/ innovation / product
├── ia/
├── produit/
└── affuter-la-scie/
90-archives/ Éléments complétés ou dépréciés
99-templates/ synthese · revue-hebdo · projet · okr
```
## Templates disponibles
- `99-templates/synthese.md` — note de ressource avec frontmatter type/auteur
- `99-templates/revue-hebdo.md` — revue du dimanche soir (3 phases, 20 min)
- `99-templates/projet.md` — fiche projet avec frontmatter statut/rôle/OKR
- `99-templates/okr.md` — OKR trimestriel ou annuel
## Commandes disponibles
- `/coaching` — génère une session de coaching (alignement + performance + équilibre)
## Préférences de collaboration
- Réponses en français, concises et directes
- Proposer avant d'agir sur des changements de structure
- Le coaching pose des questions, ne donne pas de réponses
- Revue hebdo = 3 phases max, 20 min — ne pas surcharger
- Être critique et challenger les idées — ne pas valider systématiquement, signaler les incohérences, les angles morts et les mauvaises décisions

48
README.md Normal file
View file

@ -0,0 +1,48 @@
# PKM Perso — Personal Knowledge Management
Système de gestion des connaissances personnelles basé sur [Obsidian](https://obsidian.md/), versionné avec Git.
## Structure
```
pkm-perso/
├── 00-inbox/ # Zone de capture — nouvelles idées, tâches, notes brutes
├── 05-revues/ # Revues hebdomadaires (dimanche soir)
├── 10-projects/ # Projets actifs avec objectifs et échéances
├── 15-okr/ # OKRs annuels et trimestriels
├── 20-areas/ # Rôles de vie (inspiré Covey — "Priorités aux priorités")
│ ├── perso/ # parent / conjoint / social / soi
│ └── pro/ # cto / codir / management / dsi / seenaps
├── 30-resources/ # Knowledge base par domaine (format = métadonnée)
│ ├── tech/ # architecture / securite / data / dev
│ ├── management/ # leadership / equipe / organisation
│ ├── strategie/ # innovation / product
│ ├── ia/
│ ├── produit/
│ └── affuter-la-scie/
│ └── perso-dev/
├── 90-archives/ # Éléments complétés ou dépréciés
└── 99-templates/ # Modèles de notes réutilisables
```
## Flux de travail
1. **Capturer** → tout va dans `00-inbox/` sans tri
2. **Traiter** → déplacer vers le bon dossier lors des sessions de révision
3. **Organiser**`10-projects` pour les objectifs actifs, `20-areas` pour les domaines durables, `30-resources` pour les références
4. **Archiver**`90-archives` quand c'est terminé ou obsolète
## Conventions
- **Préfixes numériques** : les dossiers sont triés par ordre d'activation (00 = plus actif, 99 = utilitaire)
- **Format Markdown** : toutes les notes sont en `.md`
- **Liens internes** : utiliser la syntaxe Obsidian `[[note]]` pour relier les notes entre elles
## Outils
- **Obsidian** — éditeur principal (plugins : obsidian-git)
- **Git + GitHub** — versioning et sauvegarde du vault
## Inspiration
Structure inspirée de la méthode [PARA](https://fortelabs.com/blog/para/) (Projects, Areas, Resources, Archives) de Tiago Forte.