maj - avant intégration onenote
This commit is contained in:
Philippe
parent
92946d3203
commit
860ff2778d
28 changed files with 715134 additions and 0 deletions
86
.claude/commands/semaine-init.md
Normal file
86
.claude/commands/semaine-init.md
Normal file
|
|
@ -0,0 +1,86 @@
|
|||
Initialise la revue hebdomadaire de la semaine courante ou de la date passée en paramètre : `$ARGUMENTS`.
|
||||
|
||||
Objectif : créer une revue de semaine courte, actionnable et alignée avec Covey + OKR + rôles, sans surcharger la routine.
|
||||
|
||||
## 1. Résolution de la semaine
|
||||
|
||||
- Si `$ARGUMENTS` contient une date au format `YYYY-MM-DD`, utilise cette date comme référence.
|
||||
- Sinon, utilise la date du jour.
|
||||
- Calcule la semaine ISO correspondante, au format `YYYY-WXX`.
|
||||
- Calcule la période du lundi au dimanche, au format `YYYY-MM-DD -> YYYY-MM-DD`.
|
||||
- Le fichier cible est `05-revues/YYYY-WXX.md`.
|
||||
|
||||
Si le fichier existe déjà :
|
||||
- ne l'écrase jamais ;
|
||||
- ouvre-le, vérifie son état, puis propose uniquement les compléments utiles ;
|
||||
- si besoin, complète les sections vides sans modifier les notes déjà présentes.
|
||||
|
||||
Si le fichier n'existe pas :
|
||||
- crée-le à partir de `99-templates/preparation-semaine.md` ;
|
||||
- remplace `YYYY-WXX`, `YYYY-MM-DD -> YYYY-MM-DD`, `Semaine XX - YYYY` par les valeurs calculées ;
|
||||
- mets `statut: preparee`.
|
||||
|
||||
## 2. Lecture du contexte
|
||||
|
||||
Lis dans cet ordre :
|
||||
|
||||
1. `15-okr/` : les OKRs annuels et trimestriels pertinents pour la période courante.
|
||||
2. `10-projects/` : les projets actifs, en privilégiant les fichiers avec `statut: actif`.
|
||||
3. `20-areas/` : uniquement les notes récemment modifiées ou manifestement liées aux rôles actifs.
|
||||
4. `00-inbox/todo.md` et `next-actions.md` s'ils existent.
|
||||
5. La revue hebdomadaire précédente dans `05-revues/`, hors dossier `coaching/`.
|
||||
|
||||
Ne lis pas `80-sources/` sauf si un lien explicite depuis une note active le justifie.
|
||||
|
||||
## 3. Pré-remplissage
|
||||
|
||||
Pré-remplis uniquement ce qui est utile :
|
||||
|
||||
### Intention de la semaine
|
||||
|
||||
- Propose une intention en une phrase.
|
||||
- Elle doit arbitrer, pas simplement additionner les sujets.
|
||||
|
||||
### Priorités
|
||||
|
||||
- Propose au maximum 3 priorités.
|
||||
- Chaque priorité doit être formulée comme un résultat vérifiable.
|
||||
- Si plus de 3 priorités ressortent, challenge le surplus dans la réponse finale au lieu de tout mettre dans la note.
|
||||
|
||||
### Alignement rôles
|
||||
|
||||
- Remplis seulement les rôles qui ont un signal clair dans les notes.
|
||||
- Laisse vide les rôles sans signal plutôt que d'inventer une action.
|
||||
- Vérifie que les rôles perso ne disparaissent pas systématiquement.
|
||||
|
||||
### Projets actifs
|
||||
|
||||
- Ajoute uniquement les projets qui ont une action pertinente cette semaine.
|
||||
- Pour chaque projet, indique :
|
||||
- l'objectif semaine ;
|
||||
- la prochaine action ;
|
||||
- le risque principal ou vide si aucun risque clair.
|
||||
|
||||
### Focus du jour
|
||||
|
||||
- Remplis uniquement le jour courant avec 1 à 3 actions.
|
||||
- Les autres jours restent vides.
|
||||
|
||||
## 4. Contraintes
|
||||
|
||||
- Ne crée pas plus de 3 priorités de semaine.
|
||||
- Ne transforme pas la revue en backlog projet.
|
||||
- Ne duplique pas tout `todo.md`.
|
||||
- N'invente pas d'échéances, d'OKR ou de projets.
|
||||
- Si une information est incertaine, laisse vide ou note-la comme point à clarifier.
|
||||
- Garde un format Markdown simple, compatible Obsidian.
|
||||
|
||||
## 5. Réponse finale
|
||||
|
||||
Réponds avec :
|
||||
|
||||
- le chemin du fichier créé ou mis à jour ;
|
||||
- l'intention proposée ;
|
||||
- les 3 priorités retenues ;
|
||||
- les arbitrages ou incohérences détectés ;
|
||||
- les points laissés vides volontairement.
|
||||
85
.claude/commands/semaine-jour.md
Normal file
85
.claude/commands/semaine-jour.md
Normal file
|
|
@ -0,0 +1,85 @@
|
|||
Met à jour la revue hebdomadaire du jour pour la date courante ou la date passée en paramètre : `$ARGUMENTS`.
|
||||
|
||||
Objectif : faire un rituel quotidien court, centré sur l'exécution réelle, sans transformer la note hebdomadaire en journal lourd.
|
||||
|
||||
## 1. Résolution de la revue
|
||||
|
||||
- Si `$ARGUMENTS` contient une date au format `YYYY-MM-DD`, utilise cette date comme référence.
|
||||
- Sinon, utilise la date du jour.
|
||||
- Calcule la semaine ISO correspondante, au format `YYYY-WXX`.
|
||||
- Le fichier cible est `05-revues/YYYY-WXX.md`.
|
||||
|
||||
Si le fichier n'existe pas :
|
||||
- ne crée pas une revue complète depuis zéro dans cette commande ;
|
||||
- indique qu'il faut d'abord lancer `/semaine-init` ;
|
||||
- propose seulement les 1 à 3 focus du jour à titre temporaire.
|
||||
|
||||
Si le fichier existe :
|
||||
- ouvre-le ;
|
||||
- mets `statut: en-cours` si le statut est encore `preparee` ;
|
||||
- ne modifie jamais les notes déjà présentes sauf correction de mise en forme évidente.
|
||||
|
||||
## 2. Lecture du contexte court
|
||||
|
||||
Lis uniquement ce qui est nécessaire :
|
||||
|
||||
1. La revue hebdomadaire courante.
|
||||
2. `00-inbox/todo.md` et `next-actions.md` s'ils existent.
|
||||
3. Les fichiers de projets explicitement listés dans la section `## 4. Projets actifs`.
|
||||
4. Les notes récemment modifiées si elles éclairent le focus du jour.
|
||||
|
||||
Ne relis pas tout le vault. Cette commande doit rester légère.
|
||||
|
||||
## 3. Mise à jour du focus du jour
|
||||
|
||||
Dans `## 5. Focus du jour`, trouve la section correspondant au jour de référence :
|
||||
|
||||
- lundi -> `### Lundi`
|
||||
- mardi -> `### Mardi`
|
||||
- mercredi -> `### Mercredi`
|
||||
- jeudi -> `### Jeudi`
|
||||
- vendredi -> `### Vendredi`
|
||||
- samedi ou dimanche -> `### Week-end`
|
||||
|
||||
Ajoute ou remplace uniquement les cases vides de cette section avec 1 à 3 actions maximum.
|
||||
|
||||
Règles :
|
||||
|
||||
- Une action doit être concrète et vérifiable.
|
||||
- Privilégie ce qui débloque une priorité de semaine.
|
||||
- Évite les listes longues.
|
||||
- Si tout est flou, pose une seule question de clarification plutôt que d'inventer.
|
||||
|
||||
## 4. Mise à jour du journal rapide
|
||||
|
||||
Dans `## 6. Journal rapide`, trouve la section du jour.
|
||||
|
||||
Ajoute une entrée courte au format :
|
||||
|
||||
```md
|
||||
- HH:MM - Focus retenu : ...
|
||||
```
|
||||
|
||||
Si des éléments sont déjà notés pour ce jour :
|
||||
- ajoute l'entrée à la suite ;
|
||||
- ne réécris pas l'historique.
|
||||
|
||||
## 5. Contrôle de cohérence
|
||||
|
||||
Après la mise à jour, vérifie :
|
||||
|
||||
- que le focus du jour ne dépasse pas 3 actions ;
|
||||
- qu'au moins une action sert une priorité de semaine ;
|
||||
- que les actions ne sont pas seulement de l'administratif ;
|
||||
- qu'un rôle perso n'est pas systématiquement ignoré si la semaine est déjà déséquilibrée.
|
||||
|
||||
Si tu détectes un déséquilibre, signale-le dans la réponse finale, sans alourdir la note.
|
||||
|
||||
## 6. Réponse finale
|
||||
|
||||
Réponds avec :
|
||||
|
||||
- le chemin du fichier mis à jour ;
|
||||
- le focus du jour ;
|
||||
- le point de vigilance principal ;
|
||||
- éventuellement une question courte si un arbitrage utilisateur est nécessaire.
|
||||
17
00-inbox/seip.md
Normal file
17
00-inbox/seip.md
Normal file
|
|
@ -0,0 +1,17 @@
|
|||
# seip pt du 13/05/2026
|
||||
|
||||
- les raisons qui feront de ce test une réussite
|
||||
|
||||
## co-pilote
|
||||
- 1 animateur des réseaux : Frédéric
|
||||
- 1 adhérent :
|
||||
|
||||
|
||||
##
|
||||
-
|
||||
Est ce que c'est intuitif, ergonomique :
|
||||
Un outil qui facilite le travail,
|
||||
|
||||
Priorité : animation de réseau
|
||||
- Construire une animation de réseau qui nous facilite la vie
|
||||
|
||||
225
10-projects/ameno/ameno-ticket.md
Normal file
225
10-projects/ameno/ameno-ticket.md
Normal file
|
|
@ -0,0 +1,225 @@
|
|||
# Ameno - Gestion des Tickets
|
||||
|
||||
**Type** : Outil / Guide d'utilisation
|
||||
**Domaine** : Gestion de projet / Product Management
|
||||
**Outil** : Ameno
|
||||
**Date de capture** : 26 décembre 2025
|
||||
|
||||
---
|
||||
|
||||
## 🎯 À quoi sert cet outil
|
||||
|
||||
Ameno est l'outil de gestion de tickets/tâches utilisé pour organiser le travail de l'équipe.
|
||||
|
||||
**Cas d'usage principaux** :
|
||||
- Créer et suivre des tickets (bugs, features, tâches)
|
||||
- Organiser le backlog
|
||||
- Suivre l'avancement des sprints
|
||||
- Prioriser le travail
|
||||
|
||||
---
|
||||
|
||||
## 📋 Guide d'utilisation
|
||||
|
||||
### Créer un ticket
|
||||
|
||||
#### Informations obligatoires
|
||||
- **Titre** : Clair et descriptif
|
||||
- **Type** : Bug / Feature / Tâche / Amélioration
|
||||
- **Description** : Contexte, problème, résultat attendu
|
||||
- **Priorité** : Haute / Moyenne / Basse
|
||||
|
||||
#### Template de ticket
|
||||
|
||||
```markdown
|
||||
**Contexte**
|
||||
[Pourquoi ce ticket existe ?]
|
||||
|
||||
**Problème / Besoin**
|
||||
[Qu'est-ce qui doit être résolu/fait ?]
|
||||
|
||||
**Résultat attendu**
|
||||
[À quoi ressemble le succès ?]
|
||||
|
||||
**Critères d'acceptation**
|
||||
- [ ] Critère 1
|
||||
- [ ] Critère 2
|
||||
|
||||
**Notes techniques** (optionnel)
|
||||
[Informations pour les devs]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Workflow des tickets
|
||||
|
||||
```
|
||||
📝 À faire → 🔄 En cours → 👀 En review → ✅ Terminé
|
||||
↓
|
||||
⏸️ Bloqué
|
||||
```
|
||||
|
||||
#### Statuts
|
||||
- **À faire** : Ticket prêt à être pris
|
||||
- **En cours** : Quelqu'un travaille dessus
|
||||
- **Bloqué** : En attente d'une action externe
|
||||
- **En review** : Code/livrable en attente de validation
|
||||
- **Terminé** : Validé et déployé/livré
|
||||
|
||||
---
|
||||
|
||||
### Bonnes pratiques
|
||||
|
||||
#### 1. Titres de tickets
|
||||
❌ **Mauvais** : "Fix bug"
|
||||
✅ **Bon** : "Fix : L'export PDF plante avec plus de 100 pages"
|
||||
|
||||
❌ **Mauvais** : "Améliorer UX"
|
||||
✅ **Bon** : "UX : Ajouter feedback visuel lors du chargement des données"
|
||||
|
||||
#### 2. Description
|
||||
- **Toujours inclure le contexte** : Pourquoi ce ticket ?
|
||||
- **Être spécifique** : Éviter les ambiguïtés
|
||||
- **Critères d'acceptation mesurables**
|
||||
|
||||
#### 3. Priorisation
|
||||
- **Haute** : Bloquant, impact critique, deadline proche
|
||||
- **Moyenne** : Important mais non urgent
|
||||
- **Basse** : Nice to have, améliorations
|
||||
|
||||
#### 4. Taille des tickets
|
||||
- **Idéal** : Ticket complétable en 1-2 jours
|
||||
- **Si > 3 jours** : Découper en sous-tickets
|
||||
- **Si < 2h** : Peut-être trop granulaire (sauf bugs rapides)
|
||||
|
||||
---
|
||||
|
||||
## 🔗 Intégration avec le workflow
|
||||
|
||||
### Lien avec [[Trunk-Based-Development]]
|
||||
|
||||
Quand on utilise Trunk-Based Development :
|
||||
- **1 ticket = 1 branche courte** (< 24h)
|
||||
- Découper les gros tickets pour respecter cette contrainte
|
||||
- Utiliser les feature flags si le ticket nécessite plusieurs jours
|
||||
|
||||
### Lien avec les sprints
|
||||
|
||||
- **Sprint planning** : Sélectionner tickets du backlog
|
||||
- **Daily** : Mettre à jour statut des tickets
|
||||
- **Review** : Démo des tickets terminés
|
||||
- **Retro** : Analyser vélocité et process tickets
|
||||
|
||||
---
|
||||
|
||||
## ⚠️ Erreurs courantes
|
||||
|
||||
### Erreur 1 : Tickets trop vagues
|
||||
**Problème** : "Améliorer la performance"
|
||||
**Solution** :
|
||||
- Spécifier quelle métrique améliorer
|
||||
- Définir la cible (ex: "Réduire temps de chargement de 5s à 2s")
|
||||
|
||||
### Erreur 2 : Tickets zombies
|
||||
**Problème** : Tickets en "En cours" depuis des semaines
|
||||
**Solution** :
|
||||
- Review hebdomadaire des tickets en cours
|
||||
- Réassigner ou fermer si bloqué
|
||||
- Découper si trop gros
|
||||
|
||||
### Erreur 3 : Pas de critères d'acceptation
|
||||
**Problème** : Flou sur "c'est terminé quand ?"
|
||||
**Solution** :
|
||||
- Toujours définir 2-5 critères mesurables
|
||||
- Valider avec le demandeur avant de commencer
|
||||
|
||||
---
|
||||
|
||||
## 💡 Astuces avancées
|
||||
|
||||
### Labels / Tags utiles
|
||||
- `#tech-debt` : Dette technique
|
||||
- `#quick-win` : Gains rapides, faible effort
|
||||
- `#breaking-change` : Nécessite attention particulière
|
||||
- `#user-request` : Demande utilisateur directe
|
||||
|
||||
### Filtres pratiques
|
||||
- **Mes tickets en cours** : Assigné à moi + Statut "En cours"
|
||||
- **Tickets bloqués** : Statut "Bloqué" → à débloquer prioritairement
|
||||
- **Tickets sans assigné** : Pour sprint planning
|
||||
|
||||
### Automatisations possibles
|
||||
- Ticket créé depuis bug tracker automatiquement
|
||||
- Notification Slack quand ticket bloqué
|
||||
- Fermeture auto quand PR mergée
|
||||
|
||||
---
|
||||
|
||||
## 📊 Métriques à suivre
|
||||
|
||||
### Par sprint
|
||||
- **Vélocité** : Nombre de tickets terminés
|
||||
- **Taux de complétion** : % tickets planifiés vs terminés
|
||||
- **Temps moyen par ticket**
|
||||
|
||||
### Par type
|
||||
- **Ratio Feature/Bug/Tech Debt** : Équilibre du travail
|
||||
- **Tickets reportés** : Indicateur de sur-planification
|
||||
|
||||
### Qualité
|
||||
- **Tickets rouverts** : Indicateur de définition incomplète
|
||||
- **Temps en "Bloqué"** : À minimiser
|
||||
|
||||
---
|
||||
|
||||
## 🔧 Configuration recommandée
|
||||
|
||||
### Champs personnalisés utiles
|
||||
- **Points d'effort** : Estimation (Fibonacci : 1, 2, 3, 5, 8)
|
||||
- **Impact utilisateur** : Haute / Moyenne / Basse
|
||||
- **Équipe** : Quelle équipe prend le ticket
|
||||
- **Version cible** : Pour quelle release
|
||||
|
||||
### Vues recommandées
|
||||
1. **Kanban board** : Vision flux de travail
|
||||
2. **Backlog priorisé** : Liste ordonnée par priorité
|
||||
3. **Sprint actuel** : Focus sur le sprint en cours
|
||||
4. **Roadmap** : Vision long terme par épic
|
||||
|
||||
---
|
||||
|
||||
## 🔗 Ressources
|
||||
|
||||
### Documentation Ameno
|
||||
- [Lien vers doc]() - *À compléter*
|
||||
|
||||
### Process équipe
|
||||
- [[Projets/Seenaps/README|Workflow Seenaps]] - Process spécifique projet
|
||||
|
||||
### Concepts liés
|
||||
- [[Méthodes/Management/Agile-Scrum]] - Framework global
|
||||
- [[Trunk-Based-Development]] - Impact sur granularité tickets
|
||||
|
||||
---
|
||||
|
||||
## 🏷️ Tags
|
||||
|
||||
#outil #gestion-projet #product-management
|
||||
|
||||
---
|
||||
|
||||
## 📝 Notes
|
||||
|
||||
**Utilisation actuelle** :
|
||||
- Projet [[Projets/Seenaps/README|Seenaps]]
|
||||
|
||||
**Points d'amélioration identifiés** :
|
||||
- *À documenter au fur et à mesure*
|
||||
|
||||
**Intégrations actives** :
|
||||
- *À compléter*
|
||||
|
||||
---
|
||||
|
||||
*Dernière mise à jour : 26 décembre 2025*
|
||||
*Note créée avec template par Claude Code*
|
||||
54
20-areas/pro/codir/codir 2026-attentePA.md
Normal file
54
20-areas/pro/codir/codir 2026-attentePA.md
Normal file
|
|
@ -0,0 +1,54 @@
|
|||
1) Ma vision 2026 (3–5 lignes)
|
||||
En 2026, je veux que le Codir soit perçu comme l'orchestrateur d'une transformation technologique et humaine réussie, où l'IA s un "gadget" mais un levier de rentabilité et d'excellence opérationnelle, permettant à l'équipe de briller par sa valeur ajoutée plutôt que par son temps passé.
|
||||
|
||||
Résultat concret fin 2026 (2–3 effets visibles) :
|
||||
- Hausse du TJM moyen équipe de +50€ grâce aux gains de productivité IA.
|
||||
- Seenaps transformé (UX refondue + IA intégrée) avec une satisfaction utilisateur ≥ 7/10.
|
||||
- Une équipe (Ludovic, Emilien, Frederic) totalement autonome sur le delivery opérationnel.
|
||||
|
||||
2) Notre mission Codir 2026 (1 phrase + 3 engagements)
|
||||
Notre mission en 2026 : Réussir le virage de l'IA générative pour Seenaps et l'équipe afin de doubler notre impact tout en préservant un équilibre de vie durable.
|
||||
|
||||
Nos 3 engagements (max) :
|
||||
- Exécuter : Le déploiement des Personal AI Architectures (PAI) pour 100% de l'équipe et la réduction de 40% de la dette technique.
|
||||
- Accélérer : La refonte UX de Seenaps et l'adoption de la culture "data-driven" avec un dashboard de 12 métriques clés.
|
||||
- Protéger : Le temps stratégique du leadership et la santé mentale de l'équipe en limitant les réunions non-essentielles.
|
||||
|
||||
3) Mes 3 priorités personnelles (2026)
|
||||
Pour chacune : objectif + pourquoi + ce que je fais personnellement
|
||||
4. Priorité #1 : Maîtrise et ROI de l'IA (Target +50€ TJM).
|
||||
- Pourquoi c’est critique : C'est notre facteur de différenciation majeur et la clé de notre rentabilité future.
|
||||
- Ce que je prends en charge concrètement : Je pilote le framework PAI, je documente les use cases de référence et je négocie la valeur auprès des clients.
|
||||
2. Priorité #2 : Excellence Produit & Développeur (Seenaps UX/DX).
|
||||
- Pourquoi c’est critique : Sans un produit fluide et une stack moderne, nous perdrons nos utilisateurs et nos talents.
|
||||
- Ce que je prends en charge concrètement : Je supervise le plan de modernisation technique et l'instauration des pratiques état de l'art (TDD/Data-driven).
|
||||
3. Priorité #3 : Délégation et Leadership Development.
|
||||
- Pourquoi c’est critique : C'est la seule façon de passer de l'opérationnel au stratégique et d'éviter l'épuisement.
|
||||
- Ce que je prends en charge concrètement : Je coache Emilien, Frederic et Ludovic pour qu'ils reprennent 80% de mes tâches opérationnelles actuelles.
|
||||
|
||||
4) Mes “non négociables” (4 Max)
|
||||
- Maximum 5 heures de réunions par semaine.
|
||||
- 50% de mon temps alloué exclusivement à la stratégie et au coaching.
|
||||
- Revue hebdomadaire systématique des indicateurs (TJM / Adoption IA) dans le dashboard.
|
||||
- Focus time quotidien (matin) sanctuarisé pour le travail de fond, sans notifications.
|
||||
|
||||
5) Mon leadership attendu (posture)
|
||||
Ce que je dois renforcer en 2026 (2 axes max) :
|
||||
- Posture de Mentor/Coach : Passer du "faire" ou "faire faire" au "faire grandir".
|
||||
- Leadership par la Data : Ancrer chaque décision importante dans des métriques objectives.
|
||||
|
||||
Mes 2 comportements concrets :
|
||||
- Déléguer systématiquement toute tâche opérationnelle dès le 1er trimestre.
|
||||
- Dire "non" explicitement à 50% des sollicitations qui ne servent pas les 3 priorités annuelles.
|
||||
|
||||
6) Indicateurs de succès (5 KPI max)
|
||||
- Δ TJM moyen équipe (+50€ cible).
|
||||
- Taux d’adoption IA (80% des tâches taguées "🤖 IA").
|
||||
- Satisfaction utilisateur Seenaps (≥ 7/10).
|
||||
- % de temps stratégique personnel (cible 50%).
|
||||
- Score de confiance équipe (cible ≥ 8/10).
|
||||
|
||||
7) Ce dont j’ai besoin du Codir
|
||||
- 1 arbitrage : Budget et temps dédié pour la formation et les outils IA de l'équipe.
|
||||
- 1 moyen / ressource : Soutien pour le recrutement ou la montée en compétence sur l'UX design.
|
||||
- autre : Validation de ma trajectoire de retrait de l'opérationnel pour assumer mon rôle stratégique.
|
||||
|
|
@ -0,0 +1,47 @@
|
|||
Chef de projets IA & Expert Conseil IA / SI
|
||||
|
||||
**1. Objectif du poste**
|
||||
|
||||
Rattaché(e) au Directeur Technique de 6TM, vous êtes détaché(e) auprès de Goria, filiale dédiée à l'exploration et au développement des usages de l’intelligence artificielle.
|
||||
|
||||
Vous contribuez à la conduite de projets IA, à l’animation de démarches de conseil auprès de nos clients et partenaires, ainsi qu’au développement progressif de l’activité IA.
|
||||
|
||||
Ce poste est évolutif et pourra être réajusté en fonction de la structuration de Goria et de l’évolution des besoins du groupe.
|
||||
|
||||
Des déplacements ponctuels sont à prévoir sur les sites 6TM (Rennes, Angers, Brest, Paris), chez les clients, ou dans le cadre d'événements externes.
|
||||
|
||||
**2. Responsabilités clés**
|
||||
|
||||
Contribution aux projets IA
|
||||
|
||||
- Participer au cadrage, au suivi et à la mise en œuvre de projets intégrant des technologies IA.
|
||||
- Réaliser ou accompagner la réalisation de POC IA.
|
||||
- Contribuer à l’intégration des solutions IA dans les SI des clients.
|
||||
- Animer ou co-animer des ateliers autour des cas d’usage IA.
|
||||
|
||||
Conseil et sensibilisation
|
||||
|
||||
- Réaliser des audits IA pour les clients 6TM ou Goria.
|
||||
- Accompagner la transformation des organisations par des recommandations IA/SI.
|
||||
- Participer à des actions de sensibilisation et de formation internes ou externes.
|
||||
- Contribuer à des actions d’avant-vente (réponses aux appels d’offres, soutenances).
|
||||
|
||||
Veille et dynamique de structuration
|
||||
|
||||
- Participer à une veille sur les usages, tendances et enjeux éthiques de l’IA.
|
||||
- Contribuer à l’identification de cas d’usage pertinents.
|
||||
- Participer à la formalisation des retours d’expérience IA du groupe.
|
||||
|
||||
Équilibre entre les responsabilités
|
||||
|
||||
Le poste s’articule autour de missions opérationnelles (projets, ateliers), stratégiques (audit, conseil, accompagnement du changement) et de veille.
|
||||
|
||||
Cette répartition est définie en lien avec le Directeur Technique afin d’assurer une orientation prioritaire vers les actions à impact.
|
||||
|
||||
La veille, essentielle à la montée en compétence, doit s’inscrire dans une dynamique concrète de valorisation (projets, livrables, interventions).
|
||||
|
||||
**3. Modalités**
|
||||
|
||||
- Poste basé au sein de l’équipe de production 6TM, avec détachement sur Goria.
|
||||
- Déplacements ponctuels à prévoir (France / événements professionnels).
|
||||
- Périmètre d'intervention amené à évoluer en fonction de la structuration de Goria.
|
||||
72
20-areas/pro/management/1to1/emilien/OneToOne - Emilien.md
Normal file
72
20-areas/pro/management/1to1/emilien/OneToOne - Emilien.md
Normal file
|
|
@ -0,0 +1,72 @@
|
|||
### Actions en cours du dernier 1to1
|
||||
- [ ] Action 1 : Description | Échéance | Statut
|
||||
- [ ] Action 2 : Description | Échéance | Statut
|
||||
- [ ] Action 3 : Description | Échéance | Statut
|
||||
|
||||
### OKR possibles
|
||||
- [ ] Structurer l'activité IA
|
||||
- [ ] Cadrer et formaliser 2 audits IA
|
||||
- [ ]
|
||||
- [ ] Capitaliser sur la veille et les retours d'expérience
|
||||
- [ ] Former X collaborateurs aux enjeux IA
|
||||
- [ ] Formaliser 2 retours d'expérience projets IA
|
||||
**Objectif T4 2025 :**
|
||||
Réaliser un minimum de :
|
||||
· 2 cadrages de projets IA auprès de clients,
|
||||
· 1 POC supervisé ou livré,
|
||||
· 1 atelier d'acculturation interne,
|
||||
· 2 audits clients,
|
||||
· 1 proposition client.
|
||||
|
||||
### 2026-01-10
|
||||
-
|
||||
### 2025-13-10
|
||||
- Prévisionnel :
|
||||
- Dessiner un cadre avec le rôle de chacun :
|
||||
- Séminaire Polaria
|
||||
- Méthodologie de travail de Polaria => à adapter
|
||||
=> point de synchro à caler
|
||||
- Manque de méthodo sur les audits :
|
||||
- Pas de génération
|
||||
|
||||
### 2025-01-10
|
||||
- Maison Calliou ok,
|
||||
- Gama : compte payant
|
||||
- Brit - rapport à faire
|
||||
- BPI ok, profile linkedin
|
||||
- Komilfo : aide possible, rdv le 17
|
||||
- Refonte site Internet => à la voix, site internet + kpi
|
||||
- Retour séminaire : dense échange nécessitant d'être approfondi
|
||||
- Remorque center : proposition envoyée, chatbot rag sur base de connaissnace fixe
|
||||
- Programme Polaria => à distance
|
||||
|
||||
### 2025-09-15 :
|
||||
- Alignement Goria : réel expertise
|
||||
- + je travaille avec eux, + ils sont nulles en réalisation
|
||||
- Libérer sur Goria > à 50% au moins 1j de + - 2j Gryffondor, 3J Goria
|
||||
- Remorque Center => ? de 100 à 35 => Budget Prod
|
||||
- Imbretex : Devis
|
||||
- OneToOne : Fin de l'année : cadre de 2 audit IA, 1 Poc livré, 1 atelier d'aculturation interne
|
||||
|
||||
### 2025-01-09
|
||||
#### Collab
|
||||
Komilfo compliqué, avec Maxime : pt MF / ST
|
||||
Compliqué sur le suivi des projets Goria
|
||||
Rdv avec Marie : prospection / closing
|
||||
Septembre : Komilfo : 11/09-15/10-15/11 10j , Mep Tangy : 15/09 : 5j
|
||||
Montée en compétence Dorothée, pression Komilfo, difficile bonne recrue
|
||||
Goria : redémarrage de BritHotel : 1j - 2 à 3 jours - Audit BPI, rédaction du rapport : 4 à 5 j, estimation et chiffrage d'ici Fin Octobre
|
||||
Imbretex : 30j Goria et 6tm : 22 pour 6TM et 750 pour eux et 1250 pour nous
|
||||
Mi Octobre : manu, ines en dev sur le projet, php-Laravel - 7j
|
||||
Avant-vente : Marie - 2j
|
||||
Vidéo Goria : 1j,
|
||||
Plan de formation IA : 1,5j (0,5 de préparation : mardi 14 Octobre)
|
||||
Veille : 3h / semaine
|
||||
Cadiou : 3j d'accompagement Sept / Dec + 10j accompagnement Gemini + RAG et sereur MCP => accord de principe pas de signature
|
||||
|
||||
|
||||
|
||||
|
||||
#### Moi
|
||||
Veille : 1/2 actu, 1/2 contexte 6tm : projets, impact actus...
|
||||
|
||||
|
|
@ -37,6 +37,53 @@ rythme: hebdo
|
|||
|
||||
## 📖 Sessions
|
||||
|
||||
### 2026-05-12
|
||||
|
||||
Priorités de la semaine :
|
||||
- Visites
|
||||
- Bases de connaissances
|
||||
|
||||
*Préparation Ameno — semaine du 4 au 10 mai*
|
||||
|
||||
**Activité saisie : ~14.5h**
|
||||
- Seenaps Platform / KPI : 6h — Intégration contenu Manop Fabrique de Style
|
||||
- Seenaps Platform / POC : 2.5h — Base de connaissances réseau
|
||||
- 6TM DT / Leeloo : 2h — Fix test + changelog + déploiement
|
||||
- 6TM CSE : 1.5h — Délégation Valentin R.
|
||||
- 6TM DT / Accompagnement : 0.5h — Maxence, point form dyn traduisible
|
||||
- 6TM Pôle Walker : 1h — Rétro IA, prépa atelier Manop FDS
|
||||
- 1à1 PA-VR : 0.5h
|
||||
- Seenaps / Orga : 0.5h — Point Aurélie Manop présentation client
|
||||
|
||||
**Tickets en cours**
|
||||
- SEE-1060 — Prépa démo SEIP (`Development`, **HAUTE PRIORITÉ**, 0h/2h, échéance **demain 2026-05-13**) — créé aujourd'hui
|
||||
- SEE-1035 — Intégration Manop Fabrique de Style (`Development`, 13.5h/14h, RAF: 0.5h, éch. dépassée 2026-04-30)
|
||||
- SEE-1045 — Base de connaissances réseau - wiki (`Development`, 3.5h/9.5h, RAF: 6h, créé 2026-05-05)
|
||||
- SEE-0924 — Alimentation des KPIs en auto (`Internal Testing`, 18h/28h, RAF: 10h, éch. dépassée 2026-04-10)
|
||||
- SEE-1013 — Référentiel Alertes — indicateurs d'activité (`Internal Testing`, 12h réalisées / 7h estimées, RAF: 0h, éch. 2026-04-21)
|
||||
- DT-0143 — Script génération usage Leeloo lib (`À traiter`, 0h)
|
||||
- IA-0044 — HAL-IA Intégration langfuse (`Retours d'infos`, 13h, en attente depuis 2025-08-27)
|
||||
- DI-I-0002 — Fuseaux horaires Leeloo/API (`À traiter`, éch. 2024-02-16 — ticket zombi)
|
||||
|
||||
**Planification semaine suivante**
|
||||
- Seenaps Platform : 2h | DT : 1h | HTT : 1h | Jeudi Ascension (férié)
|
||||
|
||||
**Points d'attention**
|
||||
- SEE-1060 créé aujourd'hui avec échéance demain et 2h de RAF : démo SEIP c'est quoi exactement, c'est cadré ?
|
||||
- SEE-0924 en `Internal Testing` avec 10h de RAF et >1 mois de dépassement : qu'est-ce qui bloque concrètement ?
|
||||
- SEE-1013 : 12h réalisées pour 7h estimées, RAF 0h — à clôturer ou il reste quelque chose ?
|
||||
- IA-0044 toujours en attente depuis août 2025 — on le ferme ou on attend encore quoi ?
|
||||
- DI-I-0002 de 2024 — à fermer explicitement ou remettre en backlog ?
|
||||
|
||||
**Questions à creuser**
|
||||
- SEE-1060 : démo SEIP demain — tu as ce qu'il te faut, ou tu as besoin d'aide ?
|
||||
- SEE-0924 : concrètement, c'est quoi les 10h qui restent et ce qui bloque ?
|
||||
- Base de connaissances réseau (SEE-1045 + POC) : tu es satisfait de l'avancement du POC, prochaine étape ?
|
||||
- Semaine prochaine : Ascension jeudi — comment tu organises les 4 jours ?
|
||||
|
||||
*Notes de session*
|
||||
-
|
||||
|
||||
### 2026-05-05
|
||||
- usage de l'IA, fabrique de style => 150 articles
|
||||
-
|
||||
|
|
|
|||
8
20-areas/pro/seenaps/clients/clients.md
Normal file
8
20-areas/pro/seenaps/clients/clients.md
Normal file
|
|
@ -0,0 +1,8 @@
|
|||
## Maxiam
|
||||
44K
|
||||
|
||||
## Transak auto
|
||||
28K
|
||||
|
||||
## Or en cash
|
||||
22K
|
||||
|
|
@ -0,0 +1,56 @@
|
|||
## Cerca
|
||||
|
||||
Attention expire début 2026
|
||||
[Ateliers de travail _ Fonctionnalités Seenaps-20250909_150708-Enregistrement de la réunion.mp4](https://6tm-my.sharepoint.com/:v:/r/personal/pauline_lamour_6tm_com/Documents/Enregistrements/Ateliers%20de%20travail%20_%20Fonctionnalit%C3%A9s%20Seenaps-20250909_150708-Enregistrement%20de%20la%20r%C3%A9union.mp4?csf=1&web=1&e=n65iRO&nav=eyJyZWZlcnJhbEluZm8iOnsicmVmZXJyYWxBcHAiOiJTdHJlYW1XZWJBcHAiLCJyZWZlcnJhbFZpZXciOiJTaGFyZURpYWxvZy1MaW5rIiwicmVmZXJyYWxBcHBQbGF0Zm9ybSI6IldlYiIsInJlZmVycmFsTW9kZSI6InZpZXcifX0%3D)
|
||||
|
||||
Bonjour à tous,
|
||||
|
||||
Vous le savez, BCHEF part pour de nouvelles aventures avec Cerca. La bonne nouvelle dans tout ça : j'ai récupéré les accès de Maud. Je vous les partage mais je vous fais confiance pour **NE RIEN TOUCHER**, elle me fait confiance, je vous fait confiance... J'ai donc profité de tout cela pour réaliser une analyse globale (j'avoue je ne savais pas trop par où prendre le sujet). Je vous partage donc ici la démarche et les résultats, en espérant que cela pourra alimenter utilement nos réflexions à la rentrée.
|
||||
|
||||
Lien d'accès : [https://bchef.cerca.io/app](https://bchef.cerca.io/app)
|
||||
|
||||
ID : [maud.nicolas@bchef.fr](mailto:maud.nicolas@bchef.fr)
|
||||
|
||||
MDP : Bchefformation2024!*
|
||||
|
||||
**Méthodo & livrables**
|
||||
|
||||
- J’ai réalisé des vidéos de prise en main, que j’ai mises à dispo dans Loom : cela permet de naviguer en conditions réelles, module par module >> [https://www.loom.com/looms/videos/CERCA-2bd36d31c8d84f9a901c945feaa6c327](https://www.loom.com/looms/videos/CERCA-2bd36d31c8d84f9a901c945feaa6c327) Nos accès :
|
||||
|
||||
- ID : [seenaps-tech@hegyd.com](mailto:seenaps-tech@hegyd.com "mailto:seenaps-tech@hegyd.com")
|
||||
|
||||
- MDP : PSiSmY@6mr!)wV
|
||||
|
||||
- J’ai constitué une base de données fonctionnelle, structurée à la façon de nos propres modules Seenaps : chaque tableau reprend les axes clés (fonctionnalités, options, valeur pour l’utilisateur, limites, opportunités pour nous).
|
||||
|
||||
- J’ai également rassemblé un word avec des captures d’écran, des synthèses rapides et quelques opportunités intéressantes...
|
||||
|
||||
**Ce que j'en retire, après 1 jour & demi sur leur plateforme...**
|
||||
|
||||
- **CERCA va assez loin fonctionnellement** : quasiment chaque module propose des options avancées, parfois un peu brutes mais globalement efficaces. Leur force, c’est la cohérence et la simplicité d’accès : on retrouve presque partout la possibilité de segmenter (groupes, panels, droits, etc.), dupliquer, filtrer, paramétrer, ce qui fluidifie l’utilisation au quotidien.
|
||||
|
||||
- **Leur interface reste sobre et peu “waouh”** : on comprend vite comment ça marche, mais ce n’est pas très sexy ni valorisant. Leur dashboard est personnalisable mais on sent que c’est la fonctionnalité qui prime, pas l’expérience.
|
||||
|
||||
- **L’administration est claire et largement intégrée au front**, ce qui permet de tout gérer sans multiplier les outils ou les espaces cachés.
|
||||
|
||||
**Ce que j'ai identifié comme opportunité...**
|
||||
|
||||
Suite à cette analyse, je suis et reste convaincue que notre force, c’est de nous positionner comme **LE CRM** de la tête de réseau et l'intranet de leurs équipes, centré sur l’intelligence data : croiser toutes les infos, tous modules confondus, pour piloter vraiment la performance terrain et déclencher les plans d’action.
|
||||
|
||||
Quelques axes à pousser/accélérer selon moi :
|
||||
|
||||
- Renforcer le pilotage data (KPI, dashboards à tous niveaux, analyses croisées entre modules, etc.).
|
||||
|
||||
- Proposer un vrai “cockpit actions” : toutes les tâches, plans d’action et priorités réunies dès la page d’accueil, personnalisable selon le rôle.
|
||||
|
||||
- Intégrer davantage d’IA : aide au remplissage des audits, suggestions d’action selon l’historique, préparation automatique de visite…
|
||||
|
||||
- Retravailler notre gestion de projet (ouverture, remodelling, déploiement d’outils) : ce n’est pas traité chez CERCA, on a une carte à jouer sur le pilotage de projets réseau, pas seulement sur les audits/visites.
|
||||
|
||||
- Travailler la personnalisation et l’ergonomie : permettre à chaque réseau de créer ses propres entrées, ses vues, ses couleurs… pour faire de Seenaps “leur” intranet et booster l’adoption.
|
||||
|
||||
[Tout est à dispo ici](https://6tm.sharepoint.com/:f:/s/6tm-RseauetFranchise/Ek0fgoHsAKJChKfBADAXpAQBs_QPDoKi-IexdCfY5_-NkQ?e=Bp3Xmx). N’hésitez pas à me demander les accès ou à compléter la base si vous voulez creuser un module en particulier. Le travail n'est pas terminé et on a encore des choses à explorer. A noter que pour le moment je n'ai pas accès à leur module de développement, il arrive en septembre.
|
||||
|
||||
En tout cas, je comprends mieux cet effet waouh qu'on peut faire en R1 quand on est face à Cerca, mais quand les prospects creusent, Cerca semble plus "abouti", "moins approximatif". Cette exploration confirme l’importance de bien connaître notre environnement concurrentiel – d’autant que, très concrètement, CERCA reste LA référence du secteur : tous les prospects que j’ai croisés la connaissent et se réfèrent à eux. On ne peut donc pas passer à côté, ni sur le fond (fonctionnalité), ni sur la forme (notre pitch).
|
||||
|
||||
Bonne lecture, et à mon tour de prendre une pause ! 😉
|
||||
119
20-areas/pro/seenaps/north star metric.md
Normal file
119
20-areas/pro/seenaps/north star metric.md
Normal file
|
|
@ -0,0 +1,119 @@
|
|||
# North Star Metric — Seenaps
|
||||
|
||||
## Contexte
|
||||
|
||||
**Produit** : Plateforme SaaS pour réseaux d'enseignes (franchises, groupements, multi-sites)
|
||||
**Promesse centrale** : *"Redonner du temps aux équipes siège pour qu'elles se concentrent sur ce qui compte : accompagner et développer leur réseau."*
|
||||
|
||||
**Chaîne de valeur** :
|
||||
> Seenaps libère du temps → les animateurs coachent plus → les PDV progressent → le réseau performe
|
||||
|
||||
**3 personas** :
|
||||
- **Franchiseur** (tête de réseau) — l'acheteur, veut que son réseau croisse et performe
|
||||
- **Animateur** — l'utilisateur principal, veut coacher plus efficacement
|
||||
- **Franchisé (PDV)** — le bénéficiaire final, veut progresser
|
||||
|
||||
---
|
||||
|
||||
## La question clé
|
||||
|
||||
> Quelle est LA métrique unique qui capture le mieux la valeur que Seenaps crée pour ses clients ?
|
||||
|
||||
La valeur de Seenaps n'est **pas** dans le nombre de logins.
|
||||
La valeur de Seenaps est dans **l'animation qui se produit** — quand un animateur visite un PDV, crée un plan d'action, et que ce PDV progresse.
|
||||
|
||||
---
|
||||
|
||||
## Les 4 candidats NSM
|
||||
|
||||
### Candidat A — PDV actifs par mois
|
||||
> Nombre de points de vente ayant réalisé au moins une action significative sur la plateforme dans le mois
|
||||
|
||||
**Ce que ça capture** : l'adoption côté terrain (franchisés)
|
||||
**Forces** : simple, mesurable, reflète l'engagement du réseau entier
|
||||
**Limites** : un PDV peut être "actif" sans que l'animateur ait rien fait → pas de causalité directe avec la valeur
|
||||
|
||||
---
|
||||
|
||||
### Candidat B — Visites terrain complétées avec plan d'action
|
||||
> Nombre de visites terrain réalisées ET suivies d'un plan d'action dans le mois
|
||||
|
||||
**Ce que ça capture** : le workflow cœur de Seenaps (visite → action → suivi)
|
||||
**Forces** : correspond exactement au job de l'animateur, très actionnable, lié directement à la promesse
|
||||
**Limites** : dépend du nombre d'animateurs et de PDV dans le réseau → à normaliser (par réseau ou par animateur)
|
||||
|
||||
---
|
||||
|
||||
### Candidat C — Taux d'activation des PDV du réseau
|
||||
> % des PDV d'un réseau ayant eu au moins une interaction animateur dans le mois
|
||||
|
||||
**Ce que ça capture** : la couverture du réseau — est-ce que TOUS les PDV bénéficient de Seenaps ?
|
||||
**Forces** : parle directement au franchiseur (son enjeu = animer tout son réseau, pas juste une partie)
|
||||
**Limites** : un réseau avec 5 PDV et un avec 200 ne sont pas comparables directement
|
||||
|
||||
---
|
||||
|
||||
### Candidat D — Plans d'action clôturés dans les délais
|
||||
> Nombre ou % de plans d'action terminés dans les délais fixés
|
||||
|
||||
**Ce que ça capture** : l'impact réel sur le terrain, pas juste l'usage
|
||||
**Forces** : métrique de résultat, pas seulement d'activité → ROI prouvable
|
||||
**Limites** : lagging indicator (on le sait après coup), plus difficile à influencer à court terme
|
||||
|
||||
---
|
||||
|
||||
## Recommandation
|
||||
|
||||
### NSM proposée
|
||||
|
||||
> **"Nombre de PDV ayant eu une visite avec plan d'action actif dans le mois"**
|
||||
|
||||
C'est le **Candidat B**, mais formulé depuis la perspective du PDV plutôt que de l'animateur.
|
||||
|
||||
**Pourquoi ce choix** :
|
||||
|
||||
| Critère CLEAR | Validation |
|
||||
|---|---|
|
||||
| **Clair** | Compréhensible par toute l'équipe Seenaps |
|
||||
| **Leading** | Prédit la rétention (PDV coachés restent, progressent, renouvellent) |
|
||||
| **Mesurable** | Calculable chaque mois depuis la base de données |
|
||||
| **Actionnable** | L'équipe peut l'influencer : onboarding animateurs, templates de visites, rappels automatiques |
|
||||
| **Relevant** | Capture exactement la promesse : "accompagner et développer chaque PDV" |
|
||||
|
||||
**La logique** :
|
||||
- Si cette métrique monte → les animateurs utilisent Seenaps pour coacher → les PDV progressent → le franchiseur voit la valeur → il renouvelle et étend le réseau
|
||||
- Si cette métrique stagne → risque de churn → signal d'alerte
|
||||
|
||||
---
|
||||
|
||||
## Questions à trancher
|
||||
|
||||
Avant de valider, quelques questions à répondre :
|
||||
|
||||
- [ ] **Comment définir "plan d'action actif"** ? Au moins 1 action créée ? Au moins 1 action en cours ?
|
||||
- [ ] **Normaliser par réseau ou absolu ?** Le total de PDV coachés sur toute la base, ou le % moyen par réseau client ?
|
||||
- [ ] **Fréquence de visite attendue ?** Mensuelle, trimestrielle ? → détermine si "dans le mois" est le bon horizon
|
||||
- [ ] **Quel est le niveau actuel ?** Pour savoir si la NSM est réaliste et ambitieuse
|
||||
|
||||
---
|
||||
|
||||
## Métriques satellites (sous la NSM)
|
||||
|
||||
Une fois la NSM définie, ces métriques l'alimentent :
|
||||
|
||||
| Niveau | Métrique | Rôle |
|
||||
|---|---|---|
|
||||
| **Acquisition** | Nouveaux réseaux activés / mois | Croissance de la base |
|
||||
| **Activation** | % animateurs ayant créé leur 1ère visite < J+30 | Vitesse d'onboarding |
|
||||
| **Engagement** | Nb moyen de visites / animateur / mois | Intensité d'usage |
|
||||
| **Rétention** | % de PDV coachés le mois M encore actifs M+3 | Stickiness |
|
||||
| **Expansion** | % de réseaux utilisant 3 modules ou plus | Upsell |
|
||||
| **Revenus** | MRR, Churn MRR, NRR | Santé financière |
|
||||
|
||||
---
|
||||
|
||||
## Références
|
||||
|
||||
- [[North Star Metric]] — définition et framework CLEAR
|
||||
- [[metriques-revenus]] — ARR, MRR, Churn
|
||||
- [[metriques-engagement]] — Retention, DAU/MAU
|
||||
365
20-areas/pro/seenaps/promesse client.md
Normal file
365
20-areas/pro/seenaps/promesse client.md
Normal file
|
|
@ -0,0 +1,365 @@
|
|||
# Version de base – PL :
|
||||
|
||||
**Seenaps : animez et développez votre réseau dans une logique de performance partagée.**
|
||||
|
||||
Chez Seenaps, nous croyons que la réussite d’un réseau d’enseignes passe avant tout par l’accompagnement, la montée en compétence et la progression continue de chaque point de vente, et non par une simple logique de contrôle ou de reporting.
|
||||
|
||||
Notre solution est conçue pour :
|
||||
|
||||
· Donner aux animateurs et responsables de réseau les moyens de piloter, d’accompagner et de faire progresser chaque collaborateur, à son niveau, grâce à des outils digitaux concrets, pensés pour l’action terrain.
|
||||
|
||||
· Décharger les équipes d’animation d’un grand nombre de tâches administratives peu valorisantes pour qu’ils consacrent leur temps au coaching de leur réseau.
|
||||
|
||||
· Permettre à chaque point de vente de devenir acteur de sa propre performance, avec accès à ses indicateurs, plans d’action personnalisés, suivis et feedbacks, dans un cadre motivant, positif et orienté résultats.
|
||||
|
||||
· Fluidifier la communication, la formation et le partage de bonnes pratiques entre le siège, les animateurs et les équipes terrain, pour renforcer la cohésion et la dynamique collective du réseau.
|
||||
|
||||
· Centraliser tous les leviers de développement, d’animation et de pilotage sur une seule plateforme, pour gagner en efficacité, en visibilité et en réactivité, au service de la performance globale du réseau.[[MF1]](#_msocom_1)
|
||||
|
||||
Ce qui fait la différence chez Seenaps :
|
||||
|
||||
· Un accompagnement personnalisé : parce que chaque réseau a ses spécificités, nous vous accompagnons à chaque étape avec des équipes dédiées et à l’écoute. Vous bénéficiez d’un interlocuteur unique, d’un support proactif et de la co-construction continue des évolutions de Seenaps, pour faire de la plateforme un véritable levier de performance, parfaitement adapté à vos enjeux.
|
||||
|
||||
· Une plateforme tout-en-un, modulable selon la maturité et les besoins de votre réseau, de l’ouverture des premiers points de vente au pilotage multi-sites.
|
||||
|
||||
Seenaps est un vrai partenaire de la réussite de chaque membre de votre réseau.
|
||||
|
||||
**Notre engagement :**
|
||||
Vous permettre de piloter, animer et faire grandir votre réseau, en créant les conditions de la performance pour chaque point de vente, grâce à une plateforme unique et un accompagnement sur-mesure, pensé pour et avec les réseaux d’enseignes.
|
||||
|
||||
**Pour qui, pourquoi ?**
|
||||
|
||||
Seenaps s’adresse à tous les réseaux d’enseignes — franchises, groupements, coopératives, multi-sites — qui souhaitent :[[MF2]](#_msocom_2)
|
||||
|
||||
· Professionnaliser et structurer l’animation de leur réseau
|
||||
|
||||
· Mettre l’accent sur la progression des équipes terrain, plutôt que sur le contrôle
|
||||
|
||||
· Centraliser le pilotage du développement, de l’animation, de la formation et de la performance sur une seule plateforme
|
||||
|
||||
· Créer une dynamique d’accompagnement et de progrès partagé
|
||||
|
||||
_________________________________________________________________________________
|
||||
|
||||
# Vos suggestions :
|
||||
|
||||
Ici, chacun peut commenter, suggérer ou proposer sa propre version. Pensez à minima de mettre votre nom et prénom devant votre proposition.
|
||||
|
||||
**Suggestion Aurélie :**
|
||||
|
||||
### **Notre Culture Seenaps**
|
||||
|
||||
Seenaps doit rester en cohérence avec la culture du groupe 6TM tout en affirmant sa propre identité.
|
||||
|
||||
Pour définir et partager clairement notre promesse client, il est essentiel de nous interroger sur notre vision, notre mission, nos valeurs. Il faudra également vérifier notre alignement avec les facteurs clés de succès (KSF) sur notre marché afin de garantir notre compétitivité et donc notre promesse (et mettre en avant nos avantages compétitifs ou potentiels avantages compétitifs).
|
||||
|
||||
v **Notre Vision**
|
||||
|
||||
Je n’ai pas encore une vision claire de la ligne directrice de Seenaps. Toutefois, il me semble important de la formaliser (si ce n’est pas déjà le cas ou de la partager) pour renforcer la cohérence de notre discours et donner de la visibilité à nos équipes.
|
||||
|
||||
À titre de pistes de réflexion, notre vision pourrait s’articuler autour de propositions telles que :
|
||||
|
||||
_(1)_ _« Être le partenaire stratégique de confiance en solutions digitales pour réseaux d’enseignes. »_
|
||||
|
||||
_(2)_ _« Devenir une référence dans les solutions digitales pour réseaux d’enseignes, en alliant performance, simplicité et innovation. »_
|
||||
|
||||
|
||||
_(3)_ _« Nous positionner comme le partenaire le plus fiable en solutions digitales pour réseaux d’enseignes, en alliant performance, simplicité et innovation. »_
|
||||
|
||||
v **Notre Mission**
|
||||
|
||||
Pour bien définir notre mission, et donc comment nous allons atteindre notre vision, il est essentiel de partir des besoins et des objectifs spécifiques des entreprises en réseau. Cela implique de comprendre leurs enjeux stratégiques mais aussi leurs défis opérationnels.
|
||||
|
||||
· **Besoins communs des entreprises en réseau**
|
||||
|
||||
o Pilotage centralisé et visibilité
|
||||
|
||||
- Suivi en temps réel des performances des points de vente/membres.
|
||||
|
||||
- Accès à des données consolidées et fiables pour prendre des décisions rapides.
|
||||
|
||||
o Coordination et harmonisation
|
||||
|
||||
- Standardiser les process et les outils au sein du réseau.
|
||||
|
||||
- Garantir la cohérence de la marque, de la communication et des opérations.
|
||||
|
||||
o Communication efficace
|
||||
|
||||
- Fluidifier les échanges siège ↔ membres.
|
||||
|
||||
- Mettre à disposition des supports, actualités, ressources.
|
||||
|
||||
o Animation et engagement du réseau
|
||||
|
||||
- Motiver et fidéliser les membres.
|
||||
|
||||
- Partager les bonnes pratiques et favoriser l’émulation.
|
||||
|
||||
o Formation et montée en compétence
|
||||
|
||||
- Onboarding rapide des nouveaux entrants.
|
||||
|
||||
- Formation continue adaptée aux évolutions du marché.
|
||||
|
||||
o Support client interne
|
||||
|
||||
- Répondre rapidement aux demandes et incidents des membres.
|
||||
|
||||
- Faciliter l’adoption des outils et procédures.
|
||||
|
||||
o Croissance et développement
|
||||
|
||||
- Identifier de nouvelles opportunités (nouveaux points de vente, territoires).
|
||||
|
||||
- Faciliter l’intégration de nouveaux membres.
|
||||
|
||||
· **Objectifs stratégiques associés**
|
||||
|
||||
o Optimiser la performance globale du réseau par le partage et l’exploitation intelligente des données.
|
||||
|
||||
o Renforcer la cohésion et l’efficacité des interactions internes.
|
||||
|
||||
o Accélérer la croissance en réduisant les frictions d’intégration et d’expansion.
|
||||
|
||||
o Garantir la qualité et l’homogénéité de l’expérience client à travers tout le réseau.
|
||||
|
||||
o Accroître l’agilité face aux évolutions du marché et aux tendances digitales.
|
||||
|
||||
Notre mission doit donc s’articuler autour de la manière dont nous pouvons répondre aux attentes ci-dessus (développement, performance, cohérence de marque, pilotage multisites, communication fluide, formation homogène, engagement des équipes), en leur apportant des solutions digitales qui renforcent leur efficacité, simplifient leurs process et soutiennent leur croissance durable.
|
||||
|
||||
Ci-dessous une proposition de mission :
|
||||
|
||||
_(1)_ _Donner aux réseaux d’enseignes les moyens de grandir et de performer durablement grâce à une plateforme digitale intégrée en mode SaaS simple et évolutive, conçue dans un esprit de proximité, de confiance et de co-construction, où l’équipe Seenaps et ses clients avancent ensemble._
|
||||
|
||||
_Cette version :_
|
||||
|
||||
· _cible **les réseaux d’enseignes**,_
|
||||
|
||||
· _intègre **les axes stratégiques majeurs** des réseaux d’enseignes,_
|
||||
|
||||
· _précise le **comment** (plateforme intégrée, utilisation du SaaS, évolutive) et le **pourquoi** (performance, cohésion)._
|
||||
|
||||
**_-> Nous nous positionnons comme un partenaire stratégique de confiance_**
|
||||
|
||||
|
||||
|
||||
v **Nos Valeurs (basées sur celles de 6TM)**
|
||||
|
||||
Elles sont essentielles car ce sont elles qui vont définir notre image aux yeux des clients (et des collaborateurs).
|
||||
|
||||
o Proximité
|
||||
|
||||
- Être à l’écoute et au contact direct de nos clients.
|
||||
|
||||
- Comprendre leurs enjeux pour apporter des réponses concrètes et adaptées.
|
||||
|
||||
o Collectif
|
||||
|
||||
- Avancer ensemble : équipe Seenaps + client = un même objectif.
|
||||
|
||||
- Partager la réussite et impliquer chacun dans la création de valeur.
|
||||
|
||||
o Confiance
|
||||
|
||||
- Construire des relations solides, durables et transparentes.
|
||||
|
||||
- Respecter les engagements et assurer la fiabilité des solutions.
|
||||
|
||||
o Plaisir
|
||||
|
||||
- Travailler avec enthousiasme et transmettre une énergie positive.
|
||||
|
||||
- Faire du projet digital une expérience motivante pour toutes les parties.
|
||||
|
||||
o Ouverture & Challenge
|
||||
|
||||
- Oser remettre en question l’existant pour aller plus loin.
|
||||
|
||||
- Accompagner les clients à explorer de nouvelles idées et approches.
|
||||
|
||||
o Responsabilité & Sensibilité RSE
|
||||
|
||||
- Intégrer les enjeux environnementaux et sociétaux dans nos choix.
|
||||
|
||||
- Favoriser des pratiques responsables et durables, en interne et avec nos clients.
|
||||
|
||||
v **Notre promesse**
|
||||
|
||||
En reprenant la réflexion ci-dessus (à discuter), nous pouvons reprendre l’une de nos promesses déjà existantes sur nos sites.
|
||||
|
||||
**->** J’opte plutôt pour la proposition (1) ou (2) :
|
||||
|
||||
_(1) « L’intelligence digitale au service de votre réseau._
|
||||
_La seule solution pour les entreprises en réseau qui connecte vos équipes, personnalise vos outils et accélère votre croissance. »_
|
||||
|
||||
_(2) « La solution qui Simplifie & Amplifie votre réseau._
|
||||
_Pensée pour les réseaux commerciaux et les entreprises multisites. Seenaps est la solution alimentée par l’IA la plus complète, évolutive et innovante ! »_
|
||||
|
||||
(3) _« La plateforme 360° qui développe, forme, connecte, anime et pilote votre réseau d’enseigne._
|
||||
_Pensée avec vous pour amplifier les synergies de votre réseau : Franchise, Concession, Licence, Succursale, Coopérative, Fabricant… »_
|
||||
|
||||
|
||||
|
||||
· Comment honorer notre promesse ?
|
||||
|
||||
Via une plateforme SaaS qui centralise les opérations des têtes de réseaux dans 5 modules complémentaires, chacun répondant à un enjeu stratégique : recrutement, formation, communication, animation et pilotage.
|
||||
|
||||
Résultat : une gouvernance claire et sécurisé, et un réseau aligné et performant.
|
||||
|
||||
Reprendre le détail de la présentation PPT de Seenaps pour chaque module : [Seenaps Platform - Template - Présentation Générique et Propale.pptx](https://6tm.sharepoint.com/:p:/r/sites/6tm-spot/Documents%20partages/General/Mod%C3%A8les%20-%20Commerce/Template%20-%20Pr%C3%A9sentations/Seenaps/Seenaps%20Platform%20-%20Template%20-%20Pre%CC%81sentation%20Ge%CC%81ne%CC%81rique%20et%20Propale.pptx?d=w4f43b277fe1248cfa5769dcaae645f00&csf=1&web=1&e=DfLm4a)
|
||||
|
||||
· Comment attester de notre engagement ?
|
||||
|
||||
Notre enjeu est de respecter notre promesse et donc d’attester de sa crédibilité auprès de nos clients (prospects) par des preuves concrètes (usages, résultats, accompagnement, innovation) et par des engagements mesurables.
|
||||
|
||||
Ci-dessous plusieurs leviers à activer/affirmer/implémenter pour en attester :
|
||||
|
||||
- Par la preuve client (usage et résultats)
|
||||
|
||||
o Cas clients / témoignages : montrer concrètement comment Seenaps a simplifié la gestion ou accéléré la croissance de réseaux.
|
||||
|
||||
o Chiffres clés : taux d’adoption, temps gagné, amélioration de la communication interne, satisfaction utilisateurs.
|
||||
|
||||
o Success stories : avant / après l’implémentation de Seenaps
|
||||
|
||||
o …
|
||||
|
||||
- Par le produit (Fonctionnalités alignées à la promesse/KSF)
|
||||
|
||||
o interface intuitive, parcours utilisateurs fluides.
|
||||
|
||||
o modules d’IA, fonctionnalités évolutives
|
||||
|
||||
o outils collaboratifs
|
||||
|
||||
o …
|
||||
|
||||
- Par la relation et l’accompagnement
|
||||
|
||||
o CSM dédié : suivi personnalisé de chaque client (preuve d’engagement humain derrière la promesse digitale).
|
||||
|
||||
o Formation & onboarding : démontrer la simplicité d’adoption
|
||||
|
||||
o Support réactif : temps de réponse, satisfaction mesurée
|
||||
|
||||
o …
|
||||
|
||||
- Par notre communication
|
||||
|
||||
o Cohérence entre ce que l’on dit et ce que l’on montre.
|
||||
|
||||
o Transparence sur ce que Seenaps fait… et ne fait pas encore (transparence sur la roadmap).
|
||||
|
||||
o …
|
||||
|
||||
**Une promesse tenue est un client satisfait, confiant et donc fidèle (-> ambassadeur) !**
|
||||
|
||||
MF : je vous fais passer la vision que nous avions en 2023.
|
||||
|
||||
MF : (je ne pense pas que ce soit ici mais il faudrait en parler ) : je pense que nous devrions adapter une version pour des associations (on en a parlé avec Edouard). Peut-être plus orientée communication (ex : DCF) avec un modèle au user très accessible. On pourrait faire un essai de communication pour voir si ça intéresse dans un premier temps ?
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Est-ce qu’on doit restreindre la promesse ?
|
||||
|
||||
Engagement et formation >> Long à mettre le contenu. + l’animer.
|
||||
|
||||
Développement >>
|
||||
|
||||
Communication >> Problématique de contenu, tu peux partir de zéro.
|
||||
|
||||
L’animation >> Utilisation gestion de projet, formaliser les visites, mettre en place les CR de visite, en dégager des plans d’actions. >>
|
||||
|
||||
|
||||
Pilotage >>
|
||||
|
||||
Je développe,
|
||||
|
||||
J'embarque/j’engage/je partage >> Quels sont les basiques auxquels ?
|
||||
|
||||
J’anime et je pilote. >> Comment amener le client ? Pourquoi le resp. De réseau va utiliser Seenaps ? Pourquoi les animateurs vont utiliser Seenaps ?
|
||||
|
||||
|
||||
|
||||
|
||||
## **La promesse de Seenaps**
|
||||
|
||||
**“Redonner du temps aux équipes siège pour qu’elles se concentrent sur ce qui compte : accompagner et développer leur réseau.”**
|
||||
|
||||
· Aujourd’hui, le siège et les magasin sont saturés. Reporting, réunions, communications redondantes, de process lourds.
|
||||
|
||||
· Résultat : les animateurs, responsables de réseau, directions opérationnelles passent trop de temps à gérer, pas assez à animer et développer.
|
||||
|
||||
· **Seenaps libère ce temps** → en centralisant, en simplifiant, en automatisant.
|
||||
|
||||
Ça met en avant un bénéfice tangible et universel : **du temps gagné >> A quantifier.**
|
||||
Et derrière le temps gagné, c’est **plus de valeur sur le terrain**.
|
||||
|
||||
## **La logique d’offre**
|
||||
|
||||
Sortir du comparatif module par module avec Cerca → proposer une **offre par parcours de valeur**.
|
||||
|
||||
Pack Essentiel – Structurer ?
|
||||
|
||||
- CRM + module Visites & actions (le socle de base).
|
||||
|
||||
>> Pour les réseaux qui veulent sortir d’Excel et tracer.
|
||||
|
||||
Promesse : “Vous centralisez et structurez la vie de votre réseau.”
|
||||
|
||||
Pack Performance – Animer
|
||||
|
||||
CRM + Visites + Com interne + Formation.
|
||||
|
||||
Pour les réseaux qui veulent passer de la gestion à l’animation.
|
||||
|
||||
Promesse : “Vous professionnalisez vos animateurs, vous boostez la performance terrain.”
|
||||
|
||||
Pack Croissance – Développer
|
||||
|
||||
Tous les modules (CRM + visites + com + formation + performance + développement).
|
||||
|
||||
Pour les réseaux qui veulent scaler.
|
||||
|
||||
Promesse : “Vous développez votre réseau et augmentez son attractivité.”
|
||||
|
||||
Ce discours : “On ne vous vend pas un puzzle compliqué. On vous donne un socle clair, avec des briques utiles, et des modèles prêts à l’emploi.”
|
||||
|
||||
## **Le message clé différenciant**
|
||||
|
||||
· **Cerca = outil de gestion (pas cher)**.
|
||||
|
||||
· Yoobic
|
||||
|
||||
· Monday...
|
||||
|
||||
· Excel :
|
||||
|
||||
·
|
||||
|
||||
· Sharepoint/drive/
|
||||
|
||||
**>> Seenaps = plateforme de performance réseau (investissement stratégique)**.
|
||||
|
||||
## **Alléger la perception de lourdeur**
|
||||
|
||||
Pour éviter l’effet “grosse usine à gaz” :
|
||||
|
||||
· **Démarrage rapide** : en 4-6 semaines, un réseau peut déjà tracer ses visites et partager ses premiers reportings. >> On voit la vraie valeur.
|
||||
|
||||
· **Déploiement progressif** : vous commencez petit (structurer), puis ajoutez (animer, développer).
|
||||
|
||||
Traduction commerciale :
|
||||
Vous voyez des résultats immédiats, vous montez en puissance progressivement, et vous entrez dans une animation réseau performante.
|
||||
|
||||
>> Montrer concrètement, ce que Seenaps va apporter, concrètement comment ça se traduit, à travers le ROI. Questionnaire client ? Pour identifier le ROI chez eux ? Y en a t’il ?
|
||||
|
||||
---
|
||||
|
||||
[[MF1]](#_msoanchor_1)Je trouve cela bien mais très tourné persona «Animateur»
|
||||
|
||||
[[MF2]](#_msoanchor_2)Ajouter les réseaux de distribution
|
||||
3
20-areas/pro/seenaps/userResearch/noblessa.md
Normal file
3
20-areas/pro/seenaps/userResearch/noblessa.md
Normal file
|
|
@ -0,0 +1,3 @@
|
|||
**Noblessa** :
|
||||
Alexis LEBRETTON - Directeur Financier
|
||||
[alebretton@noblessa.fr](mailto:alebretton@noblessa.fr "mailto:alebretton@noblessa.fr")
|
||||
0
20-areas/pro/seenaps/userResearch/seip.md
Normal file
0
20-areas/pro/seenaps/userResearch/seip.md
Normal file
177
30-resources/a formaliser.md
Normal file
177
30-resources/a formaliser.md
Normal file
|
|
@ -0,0 +1,177 @@
|
|||
# Knowledge Base (KB)
|
||||
|
||||
> Base de connaissances personnelle - Concepts, méthodes, apprentissages
|
||||
|
||||
**Dernière mise à jour** : 26 décembre 2025
|
||||
|
||||
---
|
||||
|
||||
## 📚 Vue d'ensemble
|
||||
|
||||
Cette Knowledge Base centralise :
|
||||
- **Concepts** : Principes, théories, frameworks conceptuels
|
||||
- **Méthodes** : Processus étape par étape, pratiques applicables
|
||||
- **Outils** : Mode d'emploi des outils que j'utilise
|
||||
- **REX** : Retours d'expérience, apprentissages terrain
|
||||
- **Références** : Livres, articles, personnes ressources
|
||||
|
||||
---
|
||||
|
||||
## 🎯 Comment utiliser cette KB
|
||||
|
||||
### Capturer une nouvelle connaissance
|
||||
|
||||
1. **Identifier le type** : Concept / Méthode / REX / Outil
|
||||
2. **Utiliser le template** correspondant dans `Templates/`
|
||||
3. **Ranger dans la bonne catégorie**
|
||||
4. **Lier aux notes existantes** avec `[[liens]]`
|
||||
|
||||
### Retrouver une information
|
||||
|
||||
- **Par domaine** : Parcourir les dossiers thématiques
|
||||
- **Par recherche** : Utiliser la recherche Obsidian
|
||||
- **Par tags** : Filtrer par `#concept`, `#méthode`, `#rex`
|
||||
- **Par liens** : Suivre le graphe de connaissances
|
||||
|
||||
---
|
||||
|
||||
## 📁 Structure
|
||||
|
||||
```
|
||||
KB/
|
||||
├── Concepts/ → Principes & théories
|
||||
├── Méthodes/ → Frameworks & processus
|
||||
├── Outils/ → Guides d'utilisation
|
||||
├── Retours-Experience/ → REX & apprentissages
|
||||
├── References/ → Ressources externes
|
||||
└── Templates/ → Modèles pour capturer
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 📊 Statistiques
|
||||
|
||||
- **Concepts** : 1 ✅
|
||||
- **Méthodes** : 1 ✅
|
||||
- **Outils** : 1 ✅
|
||||
- **REX** : 0
|
||||
- **Templates** : 3 ✅
|
||||
- **Total notes** : 6
|
||||
|
||||
---
|
||||
|
||||
## 🔥 Notes récentes
|
||||
|
||||
### Concepts
|
||||
- [[Concepts/Innovation/Concept-Ford|Concept Ford - Limite de la demande exprimée]] - Innovation, Product, Vision produit
|
||||
- ✨ *Enrichi avec template le 26/12/2025*
|
||||
|
||||
### Méthodes
|
||||
- [[Méthodes/Développement/Trunk-Based-Development|Trunk-Based Development]] - Développement, DevOps, Continuous Delivery
|
||||
- ✨ *Enrichi avec template le 26/12/2025*
|
||||
|
||||
### Outils
|
||||
- [[Outils/Ameno-Tickets|Ameno - Gestion des Tickets]] - Gestion de projet, Product Management
|
||||
- ✨ *Créé le 26/12/2025*
|
||||
|
||||
---
|
||||
|
||||
## 🎓 Domaines couverts
|
||||
|
||||
### 🚀 Innovation & Product
|
||||
- [[Concepts/Innovation/Concept-Ford|Concept Ford]] - Comprendre les besoins profonds vs demandes exprimées
|
||||
- **Application** : Définition roadmap, interviews utilisateurs
|
||||
- **Liens** : Design Thinking, JTBD, Product-Market Fit
|
||||
|
||||
### 💻 Développement & DevOps
|
||||
- [[Méthodes/Développement/Trunk-Based-Development|Trunk-Based Development]] - Pratique de collaboration sur une branche unique
|
||||
- **Application** : Équipes dev, CI/CD, livraison continue
|
||||
- **Liens** : Continuous Integration, Feature Flags, DevOps
|
||||
|
||||
### 📋 Gestion de projet
|
||||
- [[Outils/Ameno-Tickets|Ameno Tickets]] - Gestion et suivi des tickets
|
||||
- **Application** : Sprints, backlog, priorisation
|
||||
- **Liens** : Agile, Scrum, Workflow équipe
|
||||
|
||||
### 👥 Leadership & Management
|
||||
*À venir - Opportunités identifiées :*
|
||||
- Leadership technique (référencé dans vos notes Ikigai)
|
||||
- OKR Framework (présent dans Perso/Okr/)
|
||||
- Management d'équipe (vos one-to-one)
|
||||
|
||||
---
|
||||
|
||||
## 💡 Parcours d'apprentissage suggérés
|
||||
|
||||
### 🎯 Pour devenir meilleur en Product Management
|
||||
1. **Comprendre les besoins** → [[Concepts/Innovation/Concept-Ford|Concept Ford]]
|
||||
2. **Gérer le backlog** → [[Outils/Ameno-Tickets|Ameno Tickets]]
|
||||
3. *Prochaines étapes :*
|
||||
- [ ] Capturer Jobs To Be Done
|
||||
- [ ] Documenter Design Thinking
|
||||
- [ ] Formaliser Product-Market Fit
|
||||
|
||||
### 💻 Pour améliorer mes pratiques de développement
|
||||
1. **Collaboration code** → [[Méthodes/Développement/Trunk-Based-Development|Trunk-Based Development]]
|
||||
2. *Prochaines étapes :*
|
||||
- [ ] Documenter Feature Flags
|
||||
- [ ] Capturer Continuous Integration
|
||||
- [ ] Formaliser TDD (Test-Driven Development)
|
||||
|
||||
### 👔 Pour développer mon leadership
|
||||
*Parcours à construire*
|
||||
- [ ] Formaliser Leadership Technique (déjà dans Perso/Ikigai/)
|
||||
- [ ] Documenter OKR Framework
|
||||
- [ ] Capturer pratiques de feedback
|
||||
|
||||
---
|
||||
|
||||
## 🔗 Liens utiles
|
||||
|
||||
### Templates disponibles
|
||||
- [[Templates/Template-Concept|Template Concept]] - Pour capturer un nouveau concept
|
||||
- [[Templates/Template-Méthode|Template Méthode]] - Pour documenter une méthode
|
||||
- [[Templates/Template-REX|Template REX]] - Pour écrire un retour d'expérience
|
||||
|
||||
### Projets liés
|
||||
- [[Projets/Seenaps/README|Seenaps]] - Application des concepts produit et méthodes dev
|
||||
|
||||
### Autres ressources PA
|
||||
- [[Perso/Ikigai/README|Framework Ikigai]] - Vision personnelle et professionnelle
|
||||
- [[Perso/Okr/README-OKR|Système OKR]] - Définition et suivi d'objectifs
|
||||
|
||||
---
|
||||
|
||||
## 🎯 Prochaines captures
|
||||
|
||||
*Idées de connaissances à formaliser*
|
||||
|
||||
- [ ] Design Thinking
|
||||
- [ ] Jobs To Be Done
|
||||
- [ ] OKR Framework
|
||||
- [ ] Continuous Delivery
|
||||
- [ ] Leadership situationnel
|
||||
|
||||
---
|
||||
|
||||
## 📝 Règles de contribution
|
||||
|
||||
### Nommage des fichiers
|
||||
- **Concepts** : `Concept-[Nom].md` ou `[Nom-du-Concept].md`
|
||||
- **Méthodes** : `Méthode-[Nom].md` ou `[Nom-Méthode].md`
|
||||
- **REX** : `[AAAA-MM]-[Titre].md`
|
||||
- **Outils** : `[Nom-Outil]-Guide.md`
|
||||
|
||||
### Tags obligatoires
|
||||
- Type : `#concept`, `#méthode`, `#rex`, `#outil`
|
||||
- Domaine : `#product`, `#tech`, `#leadership`, `#management`
|
||||
|
||||
### Qualité
|
||||
- ✅ Utiliser les templates
|
||||
- ✅ Créer des liens entre notes
|
||||
- ✅ Exemples concrets obligatoires
|
||||
- ✅ Mettre à jour la date de dernière modification
|
||||
|
||||
---
|
||||
|
||||
*Base de connaissance maintenue avec Claude Code*
|
||||
86
30-resources/management/organisation/inbox-para.md
Normal file
86
30-resources/management/organisation/inbox-para.md
Normal file
|
|
@ -0,0 +1,86 @@
|
|||
---
|
||||
type: livre | methode
|
||||
auteur: Tiago Forte
|
||||
source: Building a Second Brain
|
||||
date: 2026-05-13
|
||||
tags: [organisation, pkm, para, inbox, productivite]
|
||||
---
|
||||
|
||||
# Inbox + PARA
|
||||
|
||||
Méthode d'organisation personnelle issue de **PARA**, popularisée par Tiago Forte, souvent complétée par une **inbox** de capture.
|
||||
|
||||
## Principe
|
||||
|
||||
Organiser l'information selon son **degré d'actionnabilité**, plutôt que par thème abstrait.
|
||||
|
||||
```text
|
||||
Inbox -> Projects -> Areas -> Resources -> Archives
|
||||
```
|
||||
|
||||
## Les 5 espaces
|
||||
|
||||
### Inbox
|
||||
|
||||
Zone de capture brute.
|
||||
|
||||
- idées rapides
|
||||
- notes non triées
|
||||
- liens à relire
|
||||
- demandes entrantes
|
||||
|
||||
Règle : l'inbox sert à capturer, pas à stocker.
|
||||
|
||||
### Projects
|
||||
|
||||
Projets actifs avec un résultat attendu et une fin identifiable.
|
||||
|
||||
Exemples : préparer un Codir, lancer une fonctionnalité, finaliser une roadmap.
|
||||
|
||||
### Areas
|
||||
|
||||
Domaines de responsabilité continus, aussi appelés **casquettes**.
|
||||
|
||||
Exemples : CTO, Codir, Management, DSI, Parent, Conjoint, Santé.
|
||||
|
||||
Contrairement aux projets, une area n'a pas de date de fin naturelle.
|
||||
|
||||
### Resources
|
||||
|
||||
Connaissances utiles par sujet.
|
||||
|
||||
Exemples : architecture, leadership, IA, produit, finance startup.
|
||||
|
||||
### Archives
|
||||
|
||||
Éléments inactifs, terminés ou conservés pour mémoire.
|
||||
|
||||
## Application dans ce vault
|
||||
|
||||
```text
|
||||
00-inbox/ -> capture brute
|
||||
10-projects/ -> projets actifs
|
||||
20-areas/ -> rôles / casquettes
|
||||
30-resources/ -> connaissances réutilisables
|
||||
90-archives/ -> éléments inactifs
|
||||
```
|
||||
|
||||
## Bonnes pratiques
|
||||
|
||||
- Vider régulièrement `00-inbox/`.
|
||||
- Ne créer un projet que s'il y a plusieurs actions et un résultat clair.
|
||||
- Ranger les responsabilités continues dans `20-areas/`, pas dans les projets.
|
||||
- Mettre les connaissances durables dans `30-resources/`.
|
||||
- Archiver sans hésiter ce qui n'est plus actif.
|
||||
|
||||
## Point de vigilance
|
||||
|
||||
PARA est simple, mais peut devenir flou si la différence entre **projet**, **area** et **ressource** n'est pas respectée.
|
||||
|
||||
La question clé :
|
||||
|
||||
> Est-ce une action à finir, une responsabilité à maintenir, une connaissance à réutiliser, ou un élément à conserver ?
|
||||
|
||||
## Liens avec d'autres notes
|
||||
|
||||
- [[one-to-one]]
|
||||
69
30-resources/produit/alex-hormozi.md
Normal file
69
30-resources/produit/alex-hormozi.md
Normal file
|
|
@ -0,0 +1,69 @@
|
|||
---
|
||||
type: video | livre | entrepreneur
|
||||
auteur: Alex Hormozi
|
||||
source: Acquisition.com, $100M Offers, $100M Leads
|
||||
date: 2026-05-13
|
||||
tags: [business, growth, sales, offre, acquisition]
|
||||
---
|
||||
|
||||
# Alex Hormozi
|
||||
|
||||
Alex Hormozi est un entrepreneur et investisseur américain, connu pour ses frameworks très opérationnels sur les offres, l'acquisition client, la vente et la croissance d'entreprises.
|
||||
|
||||
Son intérêt principal pour un contexte startup / produit : il force à penser en termes de **valeur perçue**, **canal d'acquisition**, **unit economics** et **capacité à vendre avant de scaler**.
|
||||
|
||||
## Idées clés
|
||||
|
||||
- Une bonne offre ne vend pas seulement un produit : elle vend un résultat désiré, avec le moins de friction et de risque perçu possible.
|
||||
- Le problème n'est pas toujours le marketing ; c'est souvent que l'offre est trop faible, trop vague ou insuffisamment différenciante.
|
||||
- La valeur perçue augmente quand le client croit davantage au résultat, le désire fortement, l'obtient vite et avec peu d'effort.
|
||||
- Le prix doit refléter la valeur créée, pas seulement le coût de production.
|
||||
- La croissance vient d'un système : offre forte, acquisition répétable, conversion, rétention, marge.
|
||||
- Un business fragile compense souvent une mauvaise offre par plus de prospection, plus de publicité ou plus de pression commerciale.
|
||||
|
||||
## Framework : équation de valeur
|
||||
|
||||
Hormozi résume la valeur perçue ainsi :
|
||||
|
||||
```text
|
||||
Valeur = (Résultat désiré x Probabilité perçue de réussite) / (Délai x Effort & sacrifice)
|
||||
```
|
||||
|
||||
Pour améliorer une offre :
|
||||
|
||||
- augmenter la clarté du résultat promis
|
||||
- augmenter la preuve que ce résultat est atteignable
|
||||
- réduire le délai avant le premier bénéfice visible
|
||||
- réduire l'effort, la complexité ou le risque côté client
|
||||
|
||||
## Application produit / Seenaps
|
||||
|
||||
Questions utiles à appliquer à une offre SaaS ou produit :
|
||||
|
||||
- Quel résultat concret le client achète-t-il vraiment ?
|
||||
- Le bénéfice est-il formulé en langage client ou en langage interne ?
|
||||
- Quelle preuve donne-t-on que le produit fonctionne ?
|
||||
- Quel est le délai avant que l'utilisateur perçoive une première valeur ?
|
||||
- Qu'est-ce qui rend l'achat ou l'usage risqué, flou ou coûteux mentalement ?
|
||||
- Le pricing capture-t-il une partie raisonnable de la valeur créée ?
|
||||
|
||||
## Points de vigilance
|
||||
|
||||
- Son approche est très orientée business, vente et exécution ; elle peut sous-estimer les dimensions produit long terme, marque, éthique ou complexité organisationnelle.
|
||||
- Les frameworks sont utiles pour challenger une offre, mais ne remplacent pas la recherche utilisateur ni la compréhension fine du marché.
|
||||
- Le style peut pousser à l'optimisation agressive de la conversion ; à manier avec discernement dans un contexte B2B durable.
|
||||
|
||||
## Ce que je peux appliquer
|
||||
|
||||
- Reprendre une offre ou une page de vente avec l'équation de valeur.
|
||||
- Identifier les promesses trop floues ou trop centrées fonctionnalités.
|
||||
- Mesurer le délai jusqu'au premier moment de valeur dans le produit.
|
||||
- Challenger le pricing au regard de la valeur réellement créée.
|
||||
- Vérifier si l'acquisition compense artificiellement une offre insuffisamment forte.
|
||||
|
||||
## Liens avec d'autres notes
|
||||
|
||||
- [[croissance-growth]]
|
||||
- [[product-market-fit]]
|
||||
- [[metriques-revenus]]
|
||||
- [[finance-startup]]
|
||||
191
30-resources/produit/concept-ford.md
Normal file
191
30-resources/produit/concept-ford.md
Normal file
|
|
@ -0,0 +1,191 @@
|
|||
# Concept Ford - Limite de la demande exprimée
|
||||
|
||||
**Type** : Concept
|
||||
**Domaine** : Innovation / Product / Vision produit
|
||||
**Source** : Henry Ford
|
||||
**Date de capture** : 26 décembre 2025
|
||||
|
||||
---
|
||||
|
||||
## 🎯 Définition en une phrase
|
||||
|
||||
L'innovation véritable consiste à répondre au besoin fondamental du client (le "why") plutôt qu'à ses solutions suggérées (le "how").
|
||||
|
||||
---
|
||||
|
||||
## 📖 Explication détaillée
|
||||
|
||||
### Citation originale
|
||||
|
||||
> « Si j'avais demandé aux gens ce qu'ils voulaient, ils m'auraient répondu : des chevaux plus rapides. »
|
||||
> — Henry Ford
|
||||
|
||||
### Le sens profond
|
||||
|
||||
Ford ne critique pas les clients : il souligne une **limite de la demande exprimée**.
|
||||
Les gens décrivent souvent **leurs besoins en fonction de ce qu'ils connaissent déjà**, pas de ce qui pourrait exister.
|
||||
|
||||
➡️ **Autrement dit** :
|
||||
|
||||
Les utilisateurs expriment un **symptôme** (ils veulent aller plus vite), mais l'entreprise visionnaire identifie le **besoin fondamental** (le besoin de se déplacer plus efficacement).
|
||||
|
||||
### Formalisation du concept
|
||||
|
||||
**Concept de l'innovation par la compréhension des besoins profonds :**
|
||||
|
||||
> L'innovation véritable consiste à répondre au besoin fondamental du client (le "why") plutôt qu'à ses solutions suggérées (le "how").
|
||||
|
||||
### Application en conception produit
|
||||
|
||||
| Niveau | Ce que le client dit | Ce qu'il veut vraiment |
|
||||
|---|---|---|
|
||||
| **Besoin exprimé** | « Je veux un cheval plus rapide » | (solution basée sur l'existant) |
|
||||
| **Besoin réel** | → | « Je veux me déplacer plus vite, plus loin, plus confortablement » |
|
||||
| **Solution innovante** | → | **La voiture** |
|
||||
|
||||
**👉 L'entrepreneur ou le designer doit traduire les désirs exprimés en besoins essentiels, puis imaginer une solution nouvelle pour y répondre.**
|
||||
|
||||
### Exemple concret
|
||||
|
||||
Quand Apple a créé l'iPhone :
|
||||
- **Ce que les gens demandaient** : Un meilleur clavier physique pour leur téléphone
|
||||
- **Le besoin profond** : Communiquer, s'informer, se divertir facilement en mobilité
|
||||
- **La solution innovante** : Interface tactile révolutionnaire sans clavier physique
|
||||
|
||||
---
|
||||
|
||||
## 🧩 Liens avec d'autres concepts
|
||||
|
||||
### Concepts liés
|
||||
|
||||
- **Product-Market Fit** : Ford ne part pas du marché tel qu'il est, mais du besoin latent du marché
|
||||
- **Design Thinking** : On cherche à comprendre l'**intention profonde de l'utilisateur** avant de concevoir une solution
|
||||
- **Innovation de rupture (Disruptive Innovation)** : Répondre à un besoin existant avec une **approche radicalement différente**
|
||||
- **Jobs To Be Done (JTBD)** : Framework qui formalise cette approche (comprendre le "job" que le client veut accomplir)
|
||||
|
||||
### Frameworks associés
|
||||
|
||||
- Design Thinking - Phase "Empathize" et "Define"
|
||||
- Lean Startup - Validation du problème avant la solution
|
||||
- Value Proposition Canvas
|
||||
|
||||
---
|
||||
|
||||
## 💡 Applications pratiques
|
||||
|
||||
### Dans mon contexte
|
||||
|
||||
**Chez [[Projets/Seenaps/README|Seenaps]]** :
|
||||
- Ne pas demander aux utilisateurs "quelles features voulez-vous ?"
|
||||
- Mais comprendre : "Quel problème rencontrez-vous dans votre gestion de projet ?"
|
||||
- Identifier le besoin profond avant de proposer une solution
|
||||
|
||||
### Cas d'usage
|
||||
|
||||
#### 1. Définition de roadmap produit
|
||||
**Situation** : Les clients demandent une feature très spécifique
|
||||
**Application du concept** :
|
||||
- Ne pas implémenter directement la feature demandée
|
||||
- Creuser le "pourquoi" avec 5 Why
|
||||
- Identifier le besoin sous-jacent
|
||||
- Proposer une solution potentiellement différente qui répond mieux au besoin réel
|
||||
|
||||
**Résultat** : Solution plus innovante et différenciante
|
||||
|
||||
#### 2. Interviews utilisateurs
|
||||
**Situation** : User research pour nouveau produit
|
||||
**Application** :
|
||||
- Poser des questions ouvertes sur les problèmes rencontrés
|
||||
- Éviter : "Voudriez-vous cette feature ?"
|
||||
- Préférer : "Comment faites-vous aujourd'hui pour [tâche] ?"
|
||||
|
||||
**Résultat** : Insights plus profonds, opportunités d'innovation identifiées
|
||||
|
||||
---
|
||||
|
||||
## ⚠️ Pièges & Limites
|
||||
|
||||
### Pièges courants
|
||||
|
||||
- **Piège 1 : Ignorer complètement le feedback utilisateur**
|
||||
- Le concept n'est pas "ne pas écouter les clients"
|
||||
- C'est "comprendre au-delà de ce qu'ils disent"
|
||||
|
||||
- **Piège 2 : Sur-innovation**
|
||||
- Parfois, une amélioration incrémentale est la bonne réponse
|
||||
- Toutes les innovations ne doivent pas être disruptives
|
||||
|
||||
- **Piège 3 : Arrogance du "je sais mieux"**
|
||||
- Attention à ne pas tomber dans l'excès inverse
|
||||
- Valider les hypothèses avec des prototypes et tests utilisateurs
|
||||
|
||||
### Limites du concept
|
||||
|
||||
- **Quand ne pas l'appliquer** :
|
||||
- Marchés très matures où l'innovation incrémentale est attendue
|
||||
- Besoins réglementaires ou techniques très spécifiques
|
||||
- Optimisations où le besoin est clairement exprimé et validé
|
||||
|
||||
- **Ce concept ne remplace pas** :
|
||||
- La validation empirique
|
||||
- Les tests utilisateurs
|
||||
- Les métriques d'usage
|
||||
|
||||
---
|
||||
|
||||
## 📚 Pour aller plus loin
|
||||
|
||||
### Lectures recommandées
|
||||
|
||||
- **"The Innovator's Dilemma"** - Clayton Christensen
|
||||
- Approfondit l'innovation de rupture vs incrémentale
|
||||
|
||||
- **"Competing Against Luck"** - Clayton Christensen
|
||||
- Formalise le framework Jobs To Be Done
|
||||
|
||||
- **"The Mom Test"** - Rob Fitzpatrick
|
||||
- Comment poser les bonnes questions aux utilisateurs
|
||||
|
||||
### Articles
|
||||
|
||||
- "How to Ask Better Questions in User Research"
|
||||
- "The Art of Asking Why"
|
||||
|
||||
### Concepts à explorer ensuite
|
||||
|
||||
- [ ] Jobs To Be Done (JTBD)
|
||||
- [ ] Design Thinking
|
||||
- [ ] Innovation de rupture
|
||||
- [ ] Value Proposition Canvas
|
||||
|
||||
---
|
||||
|
||||
## 🏷️ Tags
|
||||
|
||||
#concept #innovation #product #vision-produit
|
||||
|
||||
---
|
||||
|
||||
## 📝 Historique d'utilisation
|
||||
|
||||
**Dernière utilisation** : Projet Seenaps - Définition de la proposition de valeur
|
||||
|
||||
**Contextes d'application** :
|
||||
- Définition roadmap produit
|
||||
- Interviews utilisateurs
|
||||
- Workshops innovation équipe
|
||||
|
||||
---
|
||||
|
||||
## 📊 Résumé exécutif
|
||||
|
||||
> 🔹 Les clients expriment leurs besoins à travers leurs repères actuels
|
||||
> 🔹 L'innovation consiste à **dépasser ces repères** pour imaginer une **solution qui répond mieux au besoin réel**
|
||||
> 🔹 Ce concept illustre la différence entre **écouter** ses clients et **comprendre** ses clients
|
||||
|
||||
**En pratique** : Toujours creuser le "pourquoi" derrière une demande avant d'implémenter une solution.
|
||||
|
||||
---
|
||||
|
||||
*Dernière mise à jour : 26 décembre 2025*
|
||||
*Note enrichie avec template par Claude Code*
|
||||
311
30-resources/tech/dev/trunk-base-developpement.md
Normal file
311
30-resources/tech/dev/trunk-base-developpement.md
Normal file
|
|
@ -0,0 +1,311 @@
|
|||
# Trunk-Based Development
|
||||
|
||||
**Type** : Méthode / Pratique de développement
|
||||
**Domaine** : Développement / DevOps / Continuous Delivery
|
||||
**Difficulté** : 🟡 Moyenne
|
||||
**Date de capture** : 26 décembre 2025
|
||||
|
||||
---
|
||||
|
||||
## 🎯 Objectif
|
||||
|
||||
Trunk-Based Development est une pratique de gestion de code source où les développeurs collaborent sur du code dans une seule branche appelée "trunk" (ou "main"), en évitant les branches de longue durée.
|
||||
|
||||
**Problème résolu** :
|
||||
- Réduire la complexité des merges
|
||||
- Accélérer les cycles de livraison
|
||||
- Améliorer la collaboration d'équipe
|
||||
- Réduire les risques d'intégration
|
||||
|
||||
---
|
||||
|
||||
## 📋 La méthode étape par étape
|
||||
|
||||
### Étape 1 : Configuration du repository
|
||||
|
||||
**Actions** :
|
||||
- Définir `main` ou `trunk` comme branche principale unique
|
||||
- Protéger la branche principale (require PR, CI passing)
|
||||
- Configurer le pipeline CI/CD pour déclencher sur chaque commit
|
||||
|
||||
**Outils nécessaires** :
|
||||
- Git / GitHub / GitLab
|
||||
- Pipeline CI (GitHub Actions, GitLab CI, Jenkins)
|
||||
|
||||
**Durée estimée** : 1-2h (setup initial)
|
||||
|
||||
---
|
||||
|
||||
### Étape 2 : Workflow quotidien des développeurs
|
||||
|
||||
**Actions** :
|
||||
1. **Pull** les derniers changements du trunk
|
||||
```bash
|
||||
git pull origin main
|
||||
```
|
||||
|
||||
2. **Créer une branche courte** (optionnel, pour PR)
|
||||
```bash
|
||||
git checkout -b feature/quick-fix
|
||||
```
|
||||
|
||||
3. **Développer en petits incréments** (max 1-2 jours)
|
||||
|
||||
4. **Commit fréquent** avec feature flags si nécessaire
|
||||
|
||||
5. **Merge rapide** vers trunk (< 24h de vie de la branche)
|
||||
|
||||
**Outils nécessaires** :
|
||||
- Feature flags (LaunchDarkly, Unleash, flags maison)
|
||||
- Tests automatisés
|
||||
|
||||
**Durée estimée** : Workflow continu
|
||||
|
||||
---
|
||||
|
||||
### Étape 3 : Intégration et livraison
|
||||
|
||||
**Actions** :
|
||||
- Le CI exécute les tests sur chaque commit
|
||||
- Deploy automatique vers environnements de staging
|
||||
- Feature flags pour activer/désactiver les features en production
|
||||
- Monitoring continu post-déploiement
|
||||
|
||||
**Outils nécessaires** :
|
||||
- CI/CD pipeline
|
||||
- Feature flags
|
||||
- Monitoring (Datadog, Sentry, etc.)
|
||||
|
||||
**Durée estimée** : Automatisé
|
||||
|
||||
---
|
||||
|
||||
## ✅ Checklist d'application
|
||||
|
||||
### Pré-requis
|
||||
- [ ] Suite de tests automatisés robuste (unitaires, intégration, E2E)
|
||||
- [ ] Pipeline CI/CD fonctionnel
|
||||
- [ ] Système de feature flags en place
|
||||
- [ ] Équipe alignée sur la pratique
|
||||
|
||||
### Pratiques quotidiennes
|
||||
- [ ] Pull du trunk au moins 1x par jour
|
||||
- [ ] Commit/Push au trunk au moins 1x par jour
|
||||
- [ ] Branches de feature < 24h de vie
|
||||
- [ ] Code review rapide (< 2h de délai)
|
||||
- [ ] Tests verts avant merge
|
||||
|
||||
### Validation finale
|
||||
- [ ] Pas de branches de longue durée (> 2 jours)
|
||||
- [ ] Deployment frequency augmentée
|
||||
- [ ] Lead time for changes réduit
|
||||
- [ ] Merge conflicts rares
|
||||
|
||||
---
|
||||
|
||||
## 💡 Exemple concret
|
||||
|
||||
### Contexte
|
||||
Équipe de développement [[Projets/Seenaps/README|Seenaps]] - 5 développeurs travaillant sur la même codebase.
|
||||
|
||||
**Avant Trunk-Based Dev** :
|
||||
- Branches de feature de 1-2 semaines
|
||||
- Merge complexes et conflictuels
|
||||
- Intégration tardive, bugs découverts tard
|
||||
|
||||
**Application Trunk-Based Dev** :
|
||||
|
||||
1. **Lundi matin** : Dev démarre nouvelle feature "Export PDF"
|
||||
- Pull du main
|
||||
- Crée branche `feature/pdf-export`
|
||||
|
||||
2. **Lundi après-midi** : Premier incrément
|
||||
- Implémente structure de base avec feature flag désactivé
|
||||
- Commit + Push
|
||||
- PR créée → Review → Merge en 1h
|
||||
- Feature déployée en prod mais invisible (flag off)
|
||||
|
||||
3. **Mardi** : Deuxième incrément
|
||||
- Pull du main (récupère changements des collègues)
|
||||
- Nouvelle branche courte
|
||||
- Ajoute génération PDF basique
|
||||
- Merge en fin de journée
|
||||
|
||||
4. **Mercredi** : Feature complète
|
||||
- Derniers ajustements
|
||||
- Active feature flag pour 10% des utilisateurs
|
||||
- Monitoring + feedback
|
||||
|
||||
**Résultat** :
|
||||
- Feature livrée en 3 jours vs 2 semaines
|
||||
- Zéro merge conflict majeur
|
||||
- Feedback utilisateur rapide
|
||||
- Rollback facile si problème (désactiver flag)
|
||||
|
||||
---
|
||||
|
||||
## 🧩 Concepts sous-jacents
|
||||
|
||||
- [[Continuous Integration]] - Trunk-Based Dev est une pratique clé du CI
|
||||
- [[Continuous Delivery]] - Permet des déploiements fréquents et fiables
|
||||
- [[DevOps Culture]] - Favorise la collaboration Dev/Ops
|
||||
- [[Shift-Left Testing]] - Tests précoces et fréquents
|
||||
|
||||
---
|
||||
|
||||
## ⚡ Variantes & Adaptations
|
||||
|
||||
### Variante 1 : Scaled Trunk-Based Development
|
||||
**Quand l'utiliser ?** Grandes équipes (> 10 devs)
|
||||
|
||||
**Modifications** :
|
||||
- Utilisation de "release branches" courtes pour stabilisation
|
||||
- Branches de feature ultra-courtes (quelques heures max)
|
||||
- Code review asynchrone mais très rapide
|
||||
|
||||
### Variante 2 : Direct-to-Trunk (sans branches)
|
||||
**Quand l'utiliser ?** Petites équipes très matures (< 5 devs)
|
||||
|
||||
**Modifications** :
|
||||
- Commit directement sur trunk (pas de branches)
|
||||
- Pair programming pour review en temps réel
|
||||
- Feature flags obligatoires pour tout
|
||||
|
||||
### Variante 3 : Trunk-Based avec Release Branches
|
||||
**Quand l'utiliser ?** Produits avec releases planifiées (mobile apps)
|
||||
|
||||
**Modifications** :
|
||||
- Développement sur trunk
|
||||
- Création de `release/X.Y` au moment de la release
|
||||
- Hotfixes sur release branch + cherry-pick vers trunk
|
||||
|
||||
---
|
||||
|
||||
## ⚠️ Erreurs courantes
|
||||
|
||||
| Erreur | Conséquence | Solution |
|
||||
|--------|-------------|----------|
|
||||
| **Branches trop longues** | Merge hell, intégration tardive | Limiter durée branche à < 24h, découper en plus petits incréments |
|
||||
| **Pas de feature flags** | Code incomplet merge sur trunk | Implémenter système de feature flags robuste |
|
||||
| **Tests insuffisants** | Bugs en production | Investir dans suite de tests automatisés complète |
|
||||
| **Code review lent** | Branches s'accumulent | SLA review < 2h, rotation des reviewers |
|
||||
| **Peur de casser le trunk** | Retour aux branches longues | Culture blameless, rollback facile, monitoring |
|
||||
|
||||
---
|
||||
|
||||
## 📊 Métriques de succès
|
||||
|
||||
**Comment savoir si la méthode fonctionne ?**
|
||||
|
||||
### Métriques DORA
|
||||
- **Deployment Frequency** : Augmente (idéal : plusieurs fois par jour)
|
||||
- **Lead Time for Changes** : Diminue (idéal : < 1 jour)
|
||||
- **Mean Time to Restore** : Diminue (rollback via feature flags)
|
||||
- **Change Failure Rate** : Stable ou diminue
|
||||
|
||||
### Métriques d'équipe
|
||||
- **Nombre de merge conflicts** : Diminue drastiquement
|
||||
- **Durée moyenne des branches** : < 24h
|
||||
- **Temps de code review** : < 2h
|
||||
- **Fréquence de commit par dev** : Au moins 1/jour
|
||||
|
||||
### Indicateurs qualitatifs
|
||||
- Moins de stress lors des merges
|
||||
- Meilleure visibilité sur le travail de l'équipe
|
||||
- Feedback utilisateur plus rapide
|
||||
|
||||
---
|
||||
|
||||
## 🔗 Ressources
|
||||
|
||||
### Documentation officielle
|
||||
- [trunkbaseddevelopment.com](https://trunkbaseddevelopment.com/) - Site de référence
|
||||
- [Google SRE Book](https://sre.google/books/) - Pratiques Google
|
||||
|
||||
### Articles recommandés
|
||||
- "Trunk-Based Development vs Git Flow" - Comparaison des approches
|
||||
- "Feature Flags: The Secret to Trunk-Based Development"
|
||||
|
||||
### Outils
|
||||
|
||||
| Outil | Usage | Lien |
|
||||
|-------|-------|------|
|
||||
| **LaunchDarkly** | Feature flags SaaS | [launchdarkly.com](https://launchdarkly.com) |
|
||||
| **Unleash** | Feature flags open-source | [getunleash.io](https://getunleash.io) |
|
||||
| **GitHub Actions** | CI/CD | [github.com/features/actions](https://github.com/features/actions) |
|
||||
| **Trunk** | CLI pour vérifier conformité | [trunk.io](https://trunk.io) |
|
||||
|
||||
---
|
||||
|
||||
## 🎓 Adoption progressive
|
||||
|
||||
### Phase 1 : Fondations (Semaine 1-2)
|
||||
- [ ] Mettre en place CI robuste
|
||||
- [ ] Former l'équipe aux concepts
|
||||
- [ ] Implémenter système de feature flags basique
|
||||
|
||||
### Phase 2 : Transition (Semaine 3-4)
|
||||
- [ ] Réduire durée des branches progressivement
|
||||
- [ ] Instaurer SLA review < 4h puis < 2h
|
||||
- [ ] Augmenter fréquence de commit
|
||||
|
||||
### Phase 3 : Maturité (Mois 2-3)
|
||||
- [ ] Branches < 24h systématiquement
|
||||
- [ ] Deploy daily ou plus
|
||||
- [ ] Feature flags pour toute nouvelle feature
|
||||
- [ ] Monitoring et rollback fluides
|
||||
|
||||
---
|
||||
|
||||
## 💬 Objections courantes
|
||||
|
||||
### "Si j'ai un bug urgent, est-ce que j'attends la prochaine livraison ?"
|
||||
|
||||
**Réponse** : Non, c'est justement l'avantage du Trunk-Based Dev !
|
||||
- Le trunk est toujours déployable
|
||||
- Fix le bug sur une branche ultra-courte
|
||||
- Merge + deploy en minutes (pas jours)
|
||||
- **Pourquoi n'utiliserais-tu pas le même processus pour les features ?**
|
||||
|
||||
### "On va casser la production tout le temps"
|
||||
|
||||
**Réponse** :
|
||||
- Feature flags permettent de déployer sans activer
|
||||
- Tests automatisés sont le filet de sécurité
|
||||
- Rollback instantané si problème
|
||||
- En pratique : moins de bugs que branches longues (intégration continue)
|
||||
|
||||
### "Notre équipe n'est pas assez mature"
|
||||
|
||||
**Réponse** :
|
||||
- Commencer petit : réduire durée branches de 2 semaines → 1 semaine
|
||||
- Investir dans les tests d'abord
|
||||
- Culture blameless : on apprend des erreurs
|
||||
- Les bénéfices motivent l'amélioration continue
|
||||
|
||||
---
|
||||
|
||||
## 🏷️ Tags
|
||||
|
||||
#méthode #développement #devops #continuous-delivery
|
||||
|
||||
---
|
||||
|
||||
## 📝 Notes d'expérience personnelle
|
||||
|
||||
**Contexte d'utilisation** : Équipe Seenaps
|
||||
|
||||
**Bénéfices observés** :
|
||||
- *À compléter après adoption*
|
||||
|
||||
**Défis rencontrés** :
|
||||
- *À documenter*
|
||||
|
||||
**Adaptations spécifiques** :
|
||||
- *À noter*
|
||||
|
||||
---
|
||||
|
||||
*Dernière mise à jour : 26 décembre 2025*
|
||||
*Note enrichie avec template par Claude Code*
|
||||
*Dernière utilisation : À venir*
|
||||
33479
80-sources/onenote/PA-Equipes.mht
Normal file
33479
80-sources/onenote/PA-Equipes.mht
Normal file
File diff suppressed because it is too large
Load diff
214184
80-sources/onenote/PA-Perso.mht
Normal file
214184
80-sources/onenote/PA-Perso.mht
Normal file
File diff suppressed because it is too large
Load diff
464964
80-sources/onenote/PA-Projets.mht
Normal file
464964
80-sources/onenote/PA-Projets.mht
Normal file
File diff suppressed because it is too large
Load diff
75
99-templates/historique/Template-Concept.md
Normal file
75
99-templates/historique/Template-Concept.md
Normal file
|
|
@ -0,0 +1,75 @@
|
|||
# [Nom du Concept]
|
||||
|
||||
**Type** : Concept / Principe / Théorie
|
||||
**Domaine** : [Innovation / Leadership / Product / Tech / Management]
|
||||
**Source** : [Auteur / Livre / Article]
|
||||
**Date de capture** : [Date]
|
||||
|
||||
---
|
||||
|
||||
## 🎯 Définition en une phrase
|
||||
|
||||
*Résumé ultra-concis du concept*
|
||||
|
||||
---
|
||||
|
||||
## 📖 Explication détaillée
|
||||
|
||||
### Contexte
|
||||
*D'où vient ce concept ? Quel problème résout-il ?*
|
||||
|
||||
### Le concept en détail
|
||||
*Explication approfondie*
|
||||
|
||||
### Exemple concret
|
||||
*Illustration pratique du concept*
|
||||
|
||||
---
|
||||
|
||||
## 🧩 Liens avec d'autres concepts
|
||||
|
||||
- [[Concept-A]] - *En quoi sont-ils liés ?*
|
||||
- [[Concept-B]] - *Similitudes / Différences*
|
||||
|
||||
**Frameworks associés** :
|
||||
- [[Méthode-X]]
|
||||
|
||||
---
|
||||
|
||||
## 💡 Applications pratiques
|
||||
|
||||
### Dans mon contexte
|
||||
*Comment j'utilise ce concept dans mon travail ?*
|
||||
|
||||
### Cas d'usage
|
||||
1. **Situation** : [Description]
|
||||
- **Application** : [Comment le concept s'applique]
|
||||
- **Résultat** : [Impact]
|
||||
|
||||
---
|
||||
|
||||
## ⚠️ Pièges & Limites
|
||||
|
||||
- **Piège 1** : [Description]
|
||||
- **Limite 1** : [Quand ce concept ne s'applique pas]
|
||||
|
||||
---
|
||||
|
||||
## 📚 Pour aller plus loin
|
||||
|
||||
**Lectures** :
|
||||
- [Titre du livre]() - Auteur
|
||||
- [Article]() - Source
|
||||
|
||||
**Vidéos / Podcasts** :
|
||||
- [Titre]() - Durée
|
||||
|
||||
---
|
||||
|
||||
## 🏷️ Tags
|
||||
|
||||
#concept #[domaine] #[sous-domaine]
|
||||
|
||||
---
|
||||
|
||||
*Dernière mise à jour : [Date]*
|
||||
125
99-templates/historique/Template-Méthode.md
Normal file
125
99-templates/historique/Template-Méthode.md
Normal file
|
|
@ -0,0 +1,125 @@
|
|||
# [Nom de la Méthode]
|
||||
|
||||
**Type** : Méthode / Framework / Processus
|
||||
**Domaine** : [Développement / Product / Management / Leadership]
|
||||
**Difficulté** : 🟢 Facile / 🟡 Moyenne / 🔴 Complexe
|
||||
**Date de capture** : [Date]
|
||||
|
||||
---
|
||||
|
||||
## 🎯 Objectif
|
||||
|
||||
*À quoi sert cette méthode ? Quel problème résout-elle ?*
|
||||
|
||||
---
|
||||
|
||||
## 📋 La méthode étape par étape
|
||||
|
||||
### Étape 1 : [Nom]
|
||||
**Actions** :
|
||||
- Action 1
|
||||
- Action 2
|
||||
|
||||
**Outils nécessaires** :
|
||||
- Outil 1
|
||||
|
||||
**Durée estimée** : [Temps]
|
||||
|
||||
---
|
||||
|
||||
### Étape 2 : [Nom]
|
||||
**Actions** :
|
||||
- Action 1
|
||||
|
||||
**Outils nécessaires** :
|
||||
-
|
||||
|
||||
**Durée estimée** : [Temps]
|
||||
|
||||
---
|
||||
|
||||
### Étape 3 : [Nom]
|
||||
**Actions** :
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## ✅ Checklist d'application
|
||||
|
||||
- [ ] Pré-requis 1
|
||||
- [ ] Pré-requis 2
|
||||
- [ ] Étape 1 complétée
|
||||
- [ ] Étape 2 complétée
|
||||
- [ ] Validation finale
|
||||
|
||||
---
|
||||
|
||||
## 💡 Exemple concret
|
||||
|
||||
### Contexte
|
||||
*Situation réelle où j'ai appliqué cette méthode*
|
||||
|
||||
### Application
|
||||
*Comment j'ai suivi les étapes*
|
||||
|
||||
### Résultat
|
||||
*Impact mesurable*
|
||||
|
||||
---
|
||||
|
||||
## 🧩 Concepts sous-jacents
|
||||
|
||||
- [[Concept-A]] - *Pourquoi cette méthode repose sur ce concept*
|
||||
|
||||
---
|
||||
|
||||
## ⚡ Variantes & Adaptations
|
||||
|
||||
### Variante 1 : [Nom]
|
||||
*Quand l'utiliser ?*
|
||||
- Modification :
|
||||
|
||||
### Variante 2 : [Nom]
|
||||
*Quand l'utiliser ?*
|
||||
- Modification :
|
||||
|
||||
---
|
||||
|
||||
## ⚠️ Erreurs courantes
|
||||
|
||||
| Erreur | Conséquence | Solution |
|
||||
|--------|-------------|----------|
|
||||
| [Erreur 1] | [Impact] | [Comment l'éviter] |
|
||||
|
||||
---
|
||||
|
||||
## 📊 Métriques de succès
|
||||
|
||||
*Comment savoir si la méthode fonctionne ?*
|
||||
|
||||
- **Indicateur 1** : [Métrique]
|
||||
- **Indicateur 2** : [Métrique]
|
||||
|
||||
---
|
||||
|
||||
## 🔗 Ressources
|
||||
|
||||
**Documentation officielle** :
|
||||
- [Lien]()
|
||||
|
||||
**Tutoriels** :
|
||||
- [Lien]()
|
||||
|
||||
**Outils** :
|
||||
- [Nom de l'outil]() - [Usage]
|
||||
|
||||
---
|
||||
|
||||
## 🏷️ Tags
|
||||
|
||||
#méthode #[domaine] #[sous-domaine]
|
||||
|
||||
---
|
||||
|
||||
*Dernière mise à jour : [Date]*
|
||||
*Dernière utilisation : [Date]*
|
||||
161
99-templates/historique/Template-REX.md
Normal file
161
99-templates/historique/Template-REX.md
Normal file
|
|
@ -0,0 +1,161 @@
|
|||
# REX - [Titre du projet/événement]
|
||||
|
||||
**Date** : [Date]
|
||||
**Projet** : [[Nom-du-Projet]]
|
||||
**Type** : 🎯 Succès / ⚠️ Échec / 💡 Apprentissage
|
||||
**Domaine** : [Tech / Product / Management / Leadership]
|
||||
|
||||
---
|
||||
|
||||
## 🎯 Contexte
|
||||
|
||||
### Situation initiale
|
||||
*Quel était le problème / l'objectif ?*
|
||||
|
||||
### Objectifs visés
|
||||
- Objectif 1
|
||||
- Objectif 2
|
||||
|
||||
### Contraintes
|
||||
- Contrainte 1 (temps, budget, ressources, etc.)
|
||||
|
||||
---
|
||||
|
||||
## 🛠️ Ce qui a été fait
|
||||
|
||||
### Actions menées
|
||||
1. Action 1 - *Description*
|
||||
2. Action 2 - *Description*
|
||||
|
||||
### Méthodes utilisées
|
||||
- [[Méthode-A]] - *Comment elle a été appliquée*
|
||||
- [[Méthode-B]]
|
||||
|
||||
### Équipe & Rôles
|
||||
- [Nom] - [Rôle]
|
||||
- [Nom] - [Rôle]
|
||||
|
||||
---
|
||||
|
||||
## 📊 Résultats
|
||||
|
||||
### Métriques
|
||||
| Indicateur | Cible | Atteint | Écart |
|
||||
|------------|-------|---------|-------|
|
||||
| [Métrique 1] | [X] | [Y] | [+/-Z%] |
|
||||
|
||||
### Résultats quantitatifs
|
||||
-
|
||||
|
||||
### Résultats qualitatifs
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## ✅ Ce qui a bien fonctionné
|
||||
|
||||
### Succès 1 : [Titre]
|
||||
**Pourquoi ça a marché** :
|
||||
-
|
||||
|
||||
**À reproduire** :
|
||||
- [ ] Action/pratique à systématiser
|
||||
|
||||
---
|
||||
|
||||
### Succès 2 : [Titre]
|
||||
**Pourquoi ça a marché** :
|
||||
-
|
||||
|
||||
**À reproduire** :
|
||||
- [ ]
|
||||
|
||||
---
|
||||
|
||||
## ❌ Ce qui n'a pas fonctionné
|
||||
|
||||
### Problème 1 : [Titre]
|
||||
**Ce qui s'est passé** :
|
||||
-
|
||||
|
||||
**Causes identifiées** :
|
||||
-
|
||||
|
||||
**Comment l'éviter à l'avenir** :
|
||||
- [ ] Action préventive
|
||||
|
||||
---
|
||||
|
||||
### Problème 2 : [Titre]
|
||||
**Ce qui s'est passé** :
|
||||
-
|
||||
|
||||
**Causes identifiées** :
|
||||
-
|
||||
|
||||
**Comment l'éviter à l'avenir** :
|
||||
- [ ]
|
||||
|
||||
---
|
||||
|
||||
## 💡 Apprentissages clés
|
||||
|
||||
### Apprentissage 1
|
||||
*Ce que j'ai compris / découvert*
|
||||
|
||||
**Impact sur ma pratique** :
|
||||
-
|
||||
|
||||
**Concept lié** : [[Nom-du-Concept]]
|
||||
|
||||
---
|
||||
|
||||
### Apprentissage 2
|
||||
*Ce que j'ai compris / découvert*
|
||||
|
||||
---
|
||||
|
||||
## 🔄 Actions à entreprendre
|
||||
|
||||
### Immédiatement
|
||||
- [ ] Action 1 - Responsable : [Nom] - Deadline : [Date]
|
||||
- [ ] Action 2
|
||||
|
||||
### Court terme (1-3 mois)
|
||||
- [ ] Action 1
|
||||
|
||||
### Long terme
|
||||
- [ ] Action 1
|
||||
|
||||
---
|
||||
|
||||
## 🧩 Liens & Références
|
||||
|
||||
**Projets liés** :
|
||||
- [[Projet-A]] - *Similitudes*
|
||||
|
||||
**Concepts utilisés** :
|
||||
- [[Concept-X]]
|
||||
|
||||
**Méthodes appliquées** :
|
||||
- [[Méthode-Y]]
|
||||
|
||||
**Documentation** :
|
||||
- [Lien vers document]()
|
||||
|
||||
---
|
||||
|
||||
## 📝 Notes additionnelles
|
||||
|
||||
*Réflexions, observations, contexte supplémentaire*
|
||||
|
||||
---
|
||||
|
||||
## 🏷️ Tags
|
||||
|
||||
#rex #[domaine] #[type: succès/échec/apprentissage]
|
||||
|
||||
---
|
||||
|
||||
*Rédigé le : [Date]*
|
||||
*Partagé avec : [Équipe / Personnes]*
|
||||
124
99-templates/preparation-semaine.md
Normal file
124
99-templates/preparation-semaine.md
Normal file
|
|
@ -0,0 +1,124 @@
|
|||
---
|
||||
type: revue-hebdo
|
||||
semaine: YYYY-WXX
|
||||
periode: YYYY-MM-DD -> YYYY-MM-DD
|
||||
statut: preparee | en-cours | revue
|
||||
---
|
||||
|
||||
# Semaine XX - YYYY
|
||||
|
||||
## 1. Intention de la semaine
|
||||
|
||||
> En une phrase : ce qui rendrait cette semaine réussie.
|
||||
|
||||
## 2. Priorités
|
||||
|
||||
### Top 3
|
||||
|
||||
- [ ]
|
||||
- [ ]
|
||||
- [ ]
|
||||
|
||||
### À ne pas oublier
|
||||
|
||||
- [ ]
|
||||
|
||||
## 3. Alignement rôles
|
||||
|
||||
| Rôle | Attention de la semaine | Action clé |
|
||||
|---|---|---|
|
||||
| CTO | | |
|
||||
| Codir | | |
|
||||
| Management | | |
|
||||
| DSI | | |
|
||||
| Seenaps | | |
|
||||
| Parent | | |
|
||||
| Conjoint | | |
|
||||
| Social | | |
|
||||
| Soi | | |
|
||||
|
||||
## 4. Projets actifs
|
||||
|
||||
| Projet | Objectif semaine | Prochaine action | Risque |
|
||||
|---|---|---|---|
|
||||
| | | | |
|
||||
|
||||
## 5. Focus du jour
|
||||
|
||||
### Lundi
|
||||
|
||||
- [ ]
|
||||
|
||||
### Mardi
|
||||
|
||||
- [ ]
|
||||
|
||||
### Mercredi
|
||||
|
||||
- [ ]
|
||||
|
||||
### Jeudi
|
||||
|
||||
- [ ]
|
||||
|
||||
### Vendredi
|
||||
|
||||
- [ ]
|
||||
|
||||
### Week-end
|
||||
|
||||
- [ ]
|
||||
|
||||
## 6. Journal rapide
|
||||
|
||||
### Lundi
|
||||
|
||||
-
|
||||
|
||||
### Mardi
|
||||
|
||||
-
|
||||
|
||||
### Mercredi
|
||||
|
||||
-
|
||||
|
||||
### Jeudi
|
||||
|
||||
-
|
||||
|
||||
### Vendredi
|
||||
|
||||
-
|
||||
|
||||
### Samedi / Dimanche
|
||||
|
||||
-
|
||||
|
||||
## 7. Revue de semaine - 20 min
|
||||
|
||||
### Ce qui a avancé
|
||||
|
||||
-
|
||||
|
||||
### Ce qui bloque
|
||||
|
||||
-
|
||||
|
||||
### Décisions prises
|
||||
|
||||
-
|
||||
|
||||
### Apprentissages
|
||||
|
||||
-
|
||||
|
||||
### À reporter / abandonner
|
||||
|
||||
-
|
||||
|
||||
### Priorités semaine prochaine
|
||||
|
||||
- [ ]
|
||||
- [ ]
|
||||
- [ ]
|
||||
|
|
@ -48,6 +48,8 @@ Ce PKM repose sur trois piliers complémentaires :
|
|||
## Commandes disponibles
|
||||
|
||||
- `/coaching` — génère une session de coaching (alignement + performance + équilibre)
|
||||
- `/semaine-init` — initialise la revue hebdomadaire courante à partir du template de préparation
|
||||
- `/semaine-jour` — met à jour le focus du jour et le journal rapide de la revue courante
|
||||
|
||||
## Préférences de collaboration
|
||||
|
||||
|
|
|
|||
|
|
@ -50,6 +50,8 @@ Ce PKM repose sur trois piliers complémentaires :
|
|||
## Commandes disponibles
|
||||
|
||||
- `/coaching` — génère une session de coaching (alignement + performance + équilibre)
|
||||
- `/semaine-init` — initialise la revue hebdomadaire courante à partir du template de préparation
|
||||
- `/semaine-jour` — met à jour le focus du jour et le journal rapide de la revue courante
|
||||
|
||||
## Préférences de collaboration
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Reference in a new issue