Complement structure
This commit is contained in:
parent
54523dc28e
commit
92dfd19b07
48 changed files with 1525 additions and 1 deletions
28
.claude/commands/coaching.md
Normal file
28
.claude/commands/coaching.md
Normal 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
3
.gitignore
vendored
|
|
@ -5,3 +5,6 @@
|
|||
.trash/
|
||||
*.tmp
|
||||
.DS_Store
|
||||
_agents/.env
|
||||
_agents/__pycache__/
|
||||
_agents/.venv/
|
||||
|
|
|
|||
0
05-revues/.gitkeep
Normal file
0
05-revues/.gitkeep
Normal file
0
05-revues/coaching/.gitkeep
Normal file
0
05-revues/coaching/.gitkeep
Normal file
48
15-okr/6tm/2026-Q1.md
Normal file
48
15-okr/6tm/2026-Q1.md
Normal 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
101
15-okr/6tm/2026-annuel.md
Normal 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 T2–T4) | |
|
||||
| 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
35
15-okr/perso/2026-Q1.md
Normal 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 :
|
||||
63
15-okr/perso/2026-annuel.md
Normal file
63
15-okr/perso/2026-annuel.md
Normal 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]] | |
|
||||
0
20-areas/perso/conjoint/.gitkeep
Normal file
0
20-areas/perso/conjoint/.gitkeep
Normal file
0
20-areas/perso/parent/.gitkeep
Normal file
0
20-areas/perso/parent/.gitkeep
Normal file
0
20-areas/perso/social/.gitkeep
Normal file
0
20-areas/perso/social/.gitkeep
Normal file
0
20-areas/perso/soi/.gitkeep
Normal file
0
20-areas/perso/soi/.gitkeep
Normal file
37
20-areas/perso/soi/ikigai.md
Normal file
37
20-areas/perso/soi/ikigai.md
Normal 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 -->
|
||||
|
||||
0
20-areas/pro/codir/.gitkeep
Normal file
0
20-areas/pro/codir/.gitkeep
Normal file
0
20-areas/pro/cto/.gitkeep
Normal file
0
20-areas/pro/cto/.gitkeep
Normal file
0
20-areas/pro/dsi/.gitkeep
Normal file
0
20-areas/pro/dsi/.gitkeep
Normal file
0
20-areas/pro/management/.gitkeep
Normal file
0
20-areas/pro/management/.gitkeep
Normal file
36
20-areas/pro/management/1to1/ludovic/2026-Q1.md
Normal file
36
20-areas/pro/management/1to1/ludovic/2026-Q1.md
Normal 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]] :**
|
||||
-
|
||||
33
20-areas/pro/management/1to1/ludovic/_contexte.md
Normal file
33
20-areas/pro/management/1to1/ludovic/_contexte.md
Normal 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
|
||||
-
|
||||
0
20-areas/pro/seenaps/.gitkeep
Normal file
0
20-areas/pro/seenaps/.gitkeep
Normal file
0
30-resources/affuter-la-scie/.gitkeep
Normal file
0
30-resources/affuter-la-scie/.gitkeep
Normal file
0
30-resources/ia/.gitkeep
Normal file
0
30-resources/ia/.gitkeep
Normal file
0
30-resources/management/equipe/.gitkeep
Normal file
0
30-resources/management/equipe/.gitkeep
Normal file
0
30-resources/management/leadership/.gitkeep
Normal file
0
30-resources/management/leadership/.gitkeep
Normal file
0
30-resources/management/organisation/.gitkeep
Normal file
0
30-resources/management/organisation/.gitkeep
Normal file
69
30-resources/produit/INDEX.md
Normal file
69
30-resources/produit/INDEX.md
Normal 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
|
||||
143
30-resources/produit/North Star Metric.md
Normal file
143
30-resources/produit/North Star Metric.md
Normal 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
|
||||
69
30-resources/produit/croissance-growth.md
Normal file
69
30-resources/produit/croissance-growth.md
Normal 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
|
||||
60
30-resources/produit/finance-startup.md
Normal file
60
30-resources/produit/finance-startup.md
Normal 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
|
||||
76
30-resources/produit/frameworks-priorisation.md
Normal file
76
30-resources/produit/frameworks-priorisation.md
Normal 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
|
||||
86
30-resources/produit/metriques-engagement.md
Normal file
86
30-resources/produit/metriques-engagement.md
Normal 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
|
||||
131
30-resources/produit/metriques-revenus.md
Normal file
131
30-resources/produit/metriques-revenus.md
Normal 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
|
||||
91
30-resources/produit/process-produit.md
Normal file
91
30-resources/produit/process-produit.md
Normal 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
|
||||
73
30-resources/produit/product-market-fit.md
Normal file
73
30-resources/produit/product-market-fit.md
Normal 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
|
||||
0
30-resources/strategie/innovation/.gitkeep
Normal file
0
30-resources/strategie/innovation/.gitkeep
Normal file
0
30-resources/strategie/product/.gitkeep
Normal file
0
30-resources/strategie/product/.gitkeep
Normal file
0
30-resources/tech/architecture/.gitkeep
Normal file
0
30-resources/tech/architecture/.gitkeep
Normal file
0
30-resources/tech/data/.gitkeep
Normal file
0
30-resources/tech/data/.gitkeep
Normal file
0
30-resources/tech/dev/.gitkeep
Normal file
0
30-resources/tech/dev/.gitkeep
Normal file
0
30-resources/tech/securite/.gitkeep
Normal file
0
30-resources/tech/securite/.gitkeep
Normal file
35
99-templates/1to1-contexte.md
Normal file
35
99-templates/1to1-contexte.md
Normal 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 ? -->
|
||||
-
|
||||
53
99-templates/1to1-trimestre.md
Normal file
53
99-templates/1to1-trimestre.md
Normal 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
47
99-templates/okr.md
Normal 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
29
99-templates/projet.md
Normal 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
|
||||
|
||||
-
|
||||
50
99-templates/revue-hebdo.md
Normal file
50
99-templates/revue-hebdo.md
Normal 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
22
99-templates/synthese.md
Normal 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
58
CLAUDE.md
Normal 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
48
README.md
Normal 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.
|
||||
Loading…
Add table
Reference in a new issue