maj avant migration
This commit is contained in:
Philippe
parent
4e8f2320bf
commit
31d50bfcfe
34 changed files with 2335 additions and 34 deletions
4
.obsidian/appearance.json
vendored
4
.obsidian/appearance.json
vendored
|
|
@ -1 +1,3 @@
|
|||
{}
|
||||
{
|
||||
"cssTheme": "Things"
|
||||
}
|
||||
53
00-inbox/6nergy-2026-05.md
Normal file
53
00-inbox/6nergy-2026-05.md
Normal file
|
|
@ -0,0 +1,53 @@
|
|||
# 6nergy
|
||||
|
||||
## météo :
|
||||
- PA : dispersion
|
||||
- ST : globalement ça va, on voudrait que ca aille plus vite, pas battu pendant 25 ans pour arriver à 0
|
||||
- LR : météo perso pas top : flux tendu, tendu avec Benjamin, Anne rdv avec Fraterie décaler, job : ras le bol sur la tréso, des signaux qu'on peut y arriver : croissance à + 5, scmidt - lapeyre : cuisines à domicile, ia.
|
||||
|
||||
## 6mic
|
||||
- Angers 3,52
|
||||
- 6tmic 3,95% - 1 - emprunt sur 15 ans
|
||||
- Travaux : De Septembre à Juin
|
||||
- Angle mort : défaillance d'un locataire et pas de nouveau
|
||||
- Cible de valo à 5M€
|
||||
|
||||
## Wipoz
|
||||
- Négociation lancée pour une sortie complète
|
||||
- Sortie à 3M€ : 6nergy : 570K€, HBO : 170K, La palmeraie
|
||||
- Probable à 1,5M€ avec remboursement emprunt : 6nergy 422K, HBO : 109K
|
||||
- Crash : 6nergy 207, HBO : 60
|
||||
- Costrat le 17/06
|
||||
=> potentiellement argent en Octobre, LR ok à partir de 250 sur 6nergy
|
||||
|
||||
## Fcr
|
||||
- cible 18 franchisés france -> une dizaine de départ
|
||||
- manque 250k pour l'été
|
||||
|
||||
|
||||
## Sens & Co
|
||||
- Cession en cours
|
||||
- Yann démission
|
||||
- Cédant pour 150K€
|
||||
- Dette RH : 60K TTC
|
||||
=> Xavier 85K + 50K
|
||||
|
||||
## YWH
|
||||
- 6nergy à 44%
|
||||
- Todo : échéancier de réglement à finaliser
|
||||
|
||||
## 6nergy
|
||||
- Dettes au 30/06 722K
|
||||
|
||||
## Valorisation 6nergy au 19/05/2026
|
||||
- Valo : 5,2 => Mickaël, Antoine, Xavier : rentrer à 8
|
||||
|
||||
- RH | 4 | 1,6 => baisse de 5,5 à 4, des investisseurs à 4,3
|
||||
- 6tm Group | |
|
||||
|
||||
## Besoin de Financement 2026
|
||||
- Réalisé sur RH 300K
|
||||
-
|
||||
## Plan d'actions
|
||||
- mise en place d'un copil LR - PA - ST
|
||||
- réfléchir à ouverture 6nergy
|
||||
10
00-inbox/ip-seenaps.md
Normal file
10
00-inbox/ip-seenaps.md
Normal file
|
|
@ -0,0 +1,10 @@
|
|||
# Ip seenaps
|
||||
DRI :
|
||||
176.31.218.36
|
||||
176.31.218.53
|
||||
176.31.218.37
|
||||
Google :
|
||||
35.210.201.248 cockpitfrprod
|
||||
34.78.83.123 preprod2
|
||||
35.210.52.114 ia.6tm.com
|
||||
35.210.206.76
|
||||
|
|
@ -3,7 +3,6 @@ type: exercice
|
|||
debut: 2026-04-05
|
||||
fin: 2026-04-12
|
||||
---
|
||||
|
||||
# Micro-moments — 7 jours
|
||||
|
||||
> Chaque soir, une seule phrase : "Aujourd'hui, le moment où j'étais le plus présent / vivant / léger, c'était quand..."
|
||||
|
|
|
|||
|
|
@ -1,3 +1,4 @@
|
|||
|
||||
[ ] - Facture HPA
|
||||
[ ] - Vérifier Charte IA
|
||||
- [ ] - Facture HPA
|
||||
- [ ] - Vérifier Charte IA
|
||||
|
||||
|
|
|
|||
45
05-revues/coaching/2026-05-17.md
Normal file
45
05-revues/coaching/2026-05-17.md
Normal file
|
|
@ -0,0 +1,45 @@
|
|||
---
|
||||
type: coaching
|
||||
date: 2026-05-17
|
||||
session: 5
|
||||
---
|
||||
|
||||
# Session de coaching — 17 mai 2026
|
||||
|
||||
---
|
||||
|
||||
## 1. Alignement (Ikigai)
|
||||
|
||||
**Observation :** Ton cadre est de plus en plus clair : tu veux construire utile, clarifier le chaos, faire grandir, sans sacrifier le vivant. Pourtant, dès qu'il s'agit de regarder la semaine réelle, le risque revient : tu peux très bien être cohérent dans le discours et beaucoup moins dans l'agenda. Le sujet n'est probablement plus de savoir ce qui compte, mais de voir si ce que tu protèges concrètement ressemble vraiment à ce que tu déclares prioritaire.
|
||||
|
||||
**Question :** Cette semaine, quel moment ou quelle décision a réellement incarné ton ikigai, et où ton agenda a-t-il au contraire contredit ce que tu dis vouloir protéger ?
|
||||
|
||||
---
|
||||
|
||||
## 2. Performance (Projets / OKRs)
|
||||
|
||||
**Observation :** Tu as une vraie force de structuration : tu sais poser des systèmes, clarifier des process, organiser des idées. Mais cette force peut aussi devenir un refuge. Tu peux produire une sensation de maîtrise en améliorant le cadre, alors que les KRs, eux, n'avancent que si un livrable concret bouge. Le point de vigilance est là : ne pas confondre qualité du système et preuve d'exécution.
|
||||
|
||||
**Question :** Si tu devais choisir un seul livrable visible à faire avancer cette semaine, lequel serait-il, et quelle activité "utile en apparence" acceptes-tu de laisser de côté pour qu'il bouge vraiment ?
|
||||
|
||||
---
|
||||
|
||||
## 3. Équilibre (Rôles)
|
||||
|
||||
**Observation :** L'équilibre ne se mesure pas à l'intention, mais au temps réellement alloué. Si un rôle important n'apparaît pas dans le calendrier, il reste un sujet moral ou mental, pas une priorité vécue. Le risque, pour toi, est de reconnaître lucidement qu'un rôle est sous-investi sans transformer cette lucidité en arbitrage concret.
|
||||
|
||||
**Question :** Quel rôle est objectivement sous-investi aujourd'hui, et quel engagement précis vas-tu bloquer cette semaine pour lui redonner une place réelle ?
|
||||
|
||||
---
|
||||
|
||||
## Question centrale de la semaine
|
||||
|
||||
**Observation :** Ton agenda dit souvent la vérité plus clairement que tes intentions. S'il était le seul document disponible pour comprendre tes priorités, il montrerait sans doute davantage ce que tu entretiens que ce que tu veux vraiment transformer. C'est là que se joue la semaine : non pas dans une meilleure formulation, mais dans un arbitrage visible.
|
||||
|
||||
**Question :** Si ton agenda était audité comme seul reflet de tes priorités, quel verdict rendrait-il aujourd'hui, et qu'est-ce que tu changes dès demain pour que ce verdict soit différent dans 7 jours ?
|
||||
|
||||
---
|
||||
|
||||
## Ta réflexion
|
||||
|
||||
<!-- Espace libre — réponds à ce qui résonne, pas à tout -->
|
||||
6
05-revues/weekly/s21-2026-05-18.md
Normal file
6
05-revues/weekly/s21-2026-05-18.md
Normal file
|
|
@ -0,0 +1,6 @@
|
|||
## Mes 4 priorités
|
||||
- [ ] Seenaps - module redevance fiche article
|
||||
- [ ] Gestéos - démarrage facturation électronique
|
||||
- [ ] 6nergy - projection 2026
|
||||
- [ ] Perso - plan d'implémentation pkm défini
|
||||
|
||||
240
10-projects/pkm/ADR-001-Mise en place d’un serveur personnel.md
Normal file
240
10-projects/pkm/ADR-001-Mise en place d’un serveur personnel.md
Normal file
|
|
@ -0,0 +1,240 @@
|
|||
# ADR-001 — Mise en place d’un serveur personnel
|
||||
|
||||
- **Statut** : En réflexion
|
||||
- **Date** : 2026-05-16
|
||||
- **Décideur** : Philippe A.
|
||||
- **Contexte** : Infrastructure personnelle / PKM / IA / automatisation
|
||||
|
||||
---
|
||||
|
||||
# Contexte
|
||||
|
||||
Les usages numériques personnels et professionnels reposent aujourd’hui sur de nombreux services distribués :
|
||||
|
||||
- stockage cloud,
|
||||
- outils collaboratifs,
|
||||
- mails,
|
||||
- PKM,
|
||||
- IA génératives,
|
||||
- automatisations,
|
||||
- outils de développement,
|
||||
- workflows documentaires.
|
||||
|
||||
Cette fragmentation limite :
|
||||
|
||||
- la centralisation des connaissances,
|
||||
- l’automatisation continue,
|
||||
- la souveraineté des données,
|
||||
- la capitalisation long terme,
|
||||
- l’exécution persistante des traitements.
|
||||
|
||||
Certaines limitations actuelles ont été identifiées :
|
||||
|
||||
- impossibilité de lancer ou poursuivre des tâches lorsque le poste principal est éteint ;
|
||||
- dépendance des automatisations à la disponibilité de la machine utilisateur ;
|
||||
- difficulté à exécuter des workflows continus ou longue durée ;
|
||||
- absence de point central pour l’orchestration des outils et agents IA.
|
||||
|
||||
---
|
||||
|
||||
# Décision
|
||||
|
||||
Mettre en place un serveur personnel hébergé sur un VPS OVH, servant d'abord de socle minimal, sécurisé et maintenable pour :
|
||||
|
||||
- l’hébergement des services personnels ;
|
||||
- l’automatisation des workflows ;
|
||||
- la centralisation documentaire ;
|
||||
- l’exécution continue des traitements ;
|
||||
- l’exécution contrôlée d’agents de code ;
|
||||
- la capitalisation des connaissances.
|
||||
|
||||
Le choix d'un VPS OVH est retenu pour éviter les contraintes d'un hébergement à domicile :
|
||||
|
||||
- disponibilité dépendante de la box Internet ;
|
||||
- gestion de l'électricité et du matériel ;
|
||||
- exposition réseau résidentielle ;
|
||||
- maintenance physique ;
|
||||
- accès distant moins stable.
|
||||
|
||||
Le serveur devra pouvoir devenir progressivement une base de :
|
||||
|
||||
- PKM augmenté ;
|
||||
- infrastructure IA personnelle (PAI) ;
|
||||
- orchestration documentaire ;
|
||||
- mémoire numérique persistante.
|
||||
|
||||
Cette évolution reste conditionnée à la validation préalable du socle : accès, sécurité, sauvegardes, supervision et restauration.
|
||||
|
||||
---
|
||||
|
||||
# Non-objectifs initiaux
|
||||
|
||||
Les éléments suivants sont explicitement hors périmètre de la première mise en place :
|
||||
|
||||
- hébergement à domicile ;
|
||||
- haute disponibilité ou cluster ;
|
||||
- IA locale lourde nécessitant GPU ou ressources dédiées ;
|
||||
- migration complète du PKM dès la phase 1 ;
|
||||
- exposition publique large des services ;
|
||||
- accès distant dépendant de VS Code Server / `code tunnel` ;
|
||||
- agents IA autonomes avec droits système étendus.
|
||||
|
||||
---
|
||||
|
||||
# Objectifs
|
||||
|
||||
## Centralisation
|
||||
|
||||
Créer un point unique pour :
|
||||
|
||||
- documents,
|
||||
- notes,
|
||||
- sauvegardes,
|
||||
- workflows,
|
||||
- outils,
|
||||
- connaissances,
|
||||
- automatisations.
|
||||
|
||||
---
|
||||
|
||||
## Souveraineté numérique
|
||||
|
||||
Conserver la maîtrise :
|
||||
|
||||
- des données,
|
||||
- des accès,
|
||||
- des sauvegardes,
|
||||
- des traitements IA,
|
||||
- de l’hébergement.
|
||||
|
||||
---
|
||||
|
||||
## Exécution continue
|
||||
|
||||
Permettre :
|
||||
|
||||
- l’exécution de tâches en continu ;
|
||||
- les traitements planifiés ;
|
||||
- les workflows persistants ;
|
||||
- les agents IA encadrés ;
|
||||
- la reprise automatique des traitements.
|
||||
|
||||
---
|
||||
|
||||
## Infrastructure IA personnelle
|
||||
|
||||
Héberger progressivement :
|
||||
|
||||
- bases vectorielles,
|
||||
- moteurs RAG,
|
||||
- serveurs MCP,
|
||||
- pipelines documentaires,
|
||||
- agents IA,
|
||||
- workflows automatisés.
|
||||
|
||||
---
|
||||
|
||||
## Capitalisation de la connaissance
|
||||
|
||||
Structurer durablement :
|
||||
|
||||
- ADR,
|
||||
- documentation,
|
||||
- comptes-rendus,
|
||||
- tickets,
|
||||
- playbooks,
|
||||
- veille,
|
||||
- décisions techniques.
|
||||
|
||||
---
|
||||
|
||||
# Conséquences attendues
|
||||
|
||||
## Positives
|
||||
|
||||
- centralisation des services ;
|
||||
- meilleure maîtrise des données ;
|
||||
- automatisation avancée ;
|
||||
- exécution continue indépendante du poste utilisateur ;
|
||||
- création d’une mémoire numérique durable ;
|
||||
- socle technique pour les expérimentations IA.
|
||||
|
||||
---
|
||||
|
||||
## Négatives / contraintes
|
||||
|
||||
- maintenance supplémentaire ;
|
||||
- supervision nécessaire ;
|
||||
- gestion de la sécurité ;
|
||||
- sauvegardes obligatoires ;
|
||||
- augmentation progressive de la complexité ;
|
||||
- responsabilité d’exploitation.
|
||||
|
||||
---
|
||||
|
||||
# Périmètre technique envisagé
|
||||
|
||||
## Infrastructure
|
||||
|
||||
- VPS OVH
|
||||
- Ubuntu Server 24.04 LTS (sans interface graphique)
|
||||
- Docker / Docker Compose
|
||||
- Devcontainers (environnements de développement isolés)
|
||||
- SSH durci — accès distant de référence pour administration et agents de code
|
||||
- Reverse proxy : Traefik (Let's Encrypt natif, auto-découverte Docker)
|
||||
- Restriction d'accès par IP fixe (UFW + middleware IPAllowList Traefik)
|
||||
|
||||
VS Code Server / `code tunnel` est volontairement exclu du périmètre initial. Il pourra être réévalué comme outil de confort pour l'édition distante, mais ne doit pas devenir une dépendance structurante de l'administration du serveur ni de l'exécution des agents.
|
||||
|
||||
---
|
||||
|
||||
## Données
|
||||
|
||||
- PostgreSQL
|
||||
- stockage documentaire
|
||||
- indexation full-text
|
||||
- base vectorielle
|
||||
|
||||
---
|
||||
|
||||
## Environnements de développement
|
||||
|
||||
- Devcontainers Docker (un par projet / agent)
|
||||
- Accès SSH / Remote SSH pour ouvrir et piloter les environnements distants
|
||||
- Isolation par namespace ou Docker Compose par projet
|
||||
- Volumes persistants pour l'état des projets
|
||||
|
||||
---
|
||||
|
||||
## IA / Automatisation
|
||||
|
||||
- moteurs RAG
|
||||
- agents IA
|
||||
- MCP servers
|
||||
- workflows automatisés
|
||||
- synchronisation documentaire
|
||||
|
||||
---
|
||||
|
||||
# Évolution envisagée
|
||||
|
||||
## Phase 1
|
||||
|
||||
- infrastructure de base ;
|
||||
- sauvegardes ;
|
||||
- hébergement applicatif ;
|
||||
- centralisation documentaire.
|
||||
|
||||
## Phase 2
|
||||
|
||||
- PKM augmenté ;
|
||||
- automatisation ;
|
||||
- indexation documentaire ;
|
||||
- recherche avancée.
|
||||
|
||||
## Phase 3
|
||||
|
||||
- infrastructure IA personnelle ;
|
||||
- mémoire augmentée ;
|
||||
- agents spécialisés ;
|
||||
- orchestration avancée.
|
||||
137
10-projects/pkm/ipcra.md
Normal file
137
10-projects/pkm/ipcra.md
Normal file
|
|
@ -0,0 +1,137 @@
|
|||
# Approche IPCRA
|
||||
|
||||
## Intention
|
||||
IPCRA est une adaptation personnelle de PARA pour classer rapidement chaque information et reduire la friction de tri.
|
||||
|
||||
IPCRA = Inbox, Projets, Casquettes, Ressources, Archives.
|
||||
|
||||
References:
|
||||
- Tiago Forte: PARA.
|
||||
- David Allen: Getting Things Done.
|
||||
|
||||
## Definitions
|
||||
|
||||
### 0. Inbox
|
||||
Statut tampon. L'information est capturee, mais pas encore qualifiee.
|
||||
|
||||
Critere:
|
||||
- Tu n'as pas le temps de traiter maintenant.
|
||||
|
||||
### 1. Projets
|
||||
Element lie a un resultat avec une fin explicite (livrable, echeance, definition de fini).
|
||||
|
||||
Critere:
|
||||
- Cette information fait avancer un projet actif.
|
||||
|
||||
### 2. Casquettes
|
||||
Element rattache a un role permanent de vie ou de travail (responsabilite continue).
|
||||
|
||||
Critere:
|
||||
- Le sujet n'a pas de fin nette et releve d'une responsabilite durable.
|
||||
|
||||
### 3. Ressources
|
||||
Connaissance de reference utile dans le futur, sans action immediate.
|
||||
|
||||
Critere:
|
||||
- Le contenu peut servir plus tard, meme s'il ne declenche rien maintenant.
|
||||
|
||||
### 4. Archives
|
||||
Element clos, obsolete ou a faible valeur d'usage, conserve pour trace.
|
||||
|
||||
Critere:
|
||||
- Le contenu n'alimente plus ni projet actif, ni role, ni base de reference vivante.
|
||||
|
||||
## Arbre de decision
|
||||
|
||||
1. Je n'ai pas le temps de traiter maintenant.
|
||||
-> Inbox.
|
||||
|
||||
2. J'ai le temps de qualifier.
|
||||
-> Est-ce que cela fait avancer un projet actif ?
|
||||
Oui -> Projets.
|
||||
Non -> question suivante.
|
||||
|
||||
3. Est-ce lie a une responsabilite permanente (casquette) ?
|
||||
Oui -> Casquettes.
|
||||
Non -> question suivante.
|
||||
|
||||
4. Est-ce utile comme reference future ?
|
||||
Oui -> Ressources.
|
||||
Non -> Archives.
|
||||
|
||||
## Regles d'application
|
||||
|
||||
- Une note appartient a une categorie principale a un instant donne.
|
||||
- Inbox est transitoire: chaque element doit etre traite en revue.
|
||||
- Si un sujet change de nature, la note est deplacee (ex: projet termine -> Archives).
|
||||
- Eviter les doublons: preferer un lien vers une note source plutot qu'une copie.
|
||||
|
||||
## Rituels recommandes
|
||||
|
||||
- Quotidien: capturer rapidement en Inbox sans sur-trier.
|
||||
- Hebdomadaire: vider Inbox et requalifier les notes ambiguës.
|
||||
- Mensuel: archiver les projets clos et nettoyer les ressources peu utiles.
|
||||
|
||||
## Test de qualite
|
||||
|
||||
La methode est bien appliquee si:
|
||||
- Inbox reste legere et temporaire.
|
||||
- Chaque projet actif a un perimetre net et une fin definie.
|
||||
- Les casquettes restent stables et non polluees par du temporaire.
|
||||
- Les ressources sont retrouvables et utiles en pratique.
|
||||
- Les archives n'encombrent pas les zones actives.
|
||||
|
||||
## Ce qu'on garde de l'approche d'Eliott Meunier (Second Cerveau)
|
||||
|
||||
## Clarification du repertoire Garden
|
||||
|
||||
Definition:
|
||||
- Garden est un espace de maturation des idees (notes en cours), pas une categorie de tri IPCRA.
|
||||
|
||||
Role dans la methode:
|
||||
- IPCRA repond a la question: ou classer une note ?
|
||||
- Garden repond a la question: a quel niveau de maturite est la note ?
|
||||
|
||||
Ce qui va dans Garden:
|
||||
- Brouillons d'idees, hypotheses, notes en construction.
|
||||
- Notes qui demandent encore validation, liens et reformulation.
|
||||
|
||||
Ce qui ne va pas dans Garden:
|
||||
- Notes finalisees et stables (a classer en Projets, Casquettes ou Ressources selon leur nature).
|
||||
- Notes sans valeur conservee (a archiver).
|
||||
|
||||
Regle d'entree / sortie:
|
||||
- Entree: la note est utile mais incomplete.
|
||||
- Sortie: la note devient actionnable (Projets), de reference (Ressources), de responsabilite continue (Casquettes), ou obsolete (Archives).
|
||||
|
||||
Decision pratique:
|
||||
- Conserver IPCRA comme taxonomie principale.
|
||||
- Utiliser Garden comme statut de travail temporaire pour eviter de melanger tri et maturite.
|
||||
|
||||
Constat issu des contenus publics consultes (archive/videos):
|
||||
- Le second cerveau sert d'abord a externaliser le chaos mental.
|
||||
- La promesse centrale est de centraliser ce que tu lis, vois et entends.
|
||||
- L'objectif n'est pas d'accumuler des notes mais d'augmenter l'action (projets, apprentissage, organisation).
|
||||
- Version recente: ajout d'une couche IA pour exploiter plus vite la base de connaissances.
|
||||
|
||||
Traduction concrete dans IPCRA:
|
||||
- Garder IPCRA comme structure de tri (ou va l'information).
|
||||
- Utiliser le second cerveau comme systeme d'exploitation (comment l'information est capturee, reliee, reutilisee).
|
||||
- Exiger un output par note utile: decision, action, livrable ou apprentissage explicite.
|
||||
- Prioriser la recuperation: une note est valide seulement si elle est retrouvable et reutilisable en moins de 2 minutes.
|
||||
|
||||
Regles de mise en oeuvre (pragmatiques):
|
||||
- Capture rapide en Inbox, sans mise en forme prematuree.
|
||||
- Qualification hebdo stricte vers Projets, Casquettes, Ressources ou Archives.
|
||||
- Liaison minimale obligatoire: chaque note Ressource pointe vers au moins un Projet ou une Casquette.
|
||||
- Revue mensuelle: supprimer/archiver ce qui n'a cree aucune valeur concrete.
|
||||
|
||||
Points de vigilance:
|
||||
- Eviter l'effet collection (beaucoup de notes, peu de decisions).
|
||||
- Eviter l'effet outil (changer de stack au lieu d'executer).
|
||||
- L'IA est un accelerateur, pas une methode: la qualite depend de la structure IPCRA et des revues.
|
||||
|
||||
References consultees:
|
||||
- https://archive.eliottmeunier.com/immersion-dans-mon-second-cerveau/
|
||||
- https://archive.eliottmeunier.com/un-second-cerveau-sur-mon-ordinateur/
|
||||
- https://archive.eliottmeunier.com/comment-creer-un-second-cerveau-en-2024-ma-methode-complete/
|
||||
79
10-projects/pkm/pkm.md
Normal file
79
10-projects/pkm/pkm.md
Normal file
|
|
@ -0,0 +1,79 @@
|
|||
# Projet PKM - Plan d'implementation
|
||||
|
||||
## Objectif
|
||||
Mettre en place un serveur personnel pour heberger et automatiser l'ecosysteme PKM, avec une base technique simple, maintenable et evolutive.
|
||||
|
||||
## Decisions d'architecture
|
||||
|
||||
### 1) Nom de domaine
|
||||
- Action: reserver un nom de domaine dedie au serveur personnel.
|
||||
- Decision attendue: registrar choisi + nom retenu + duree de reservation.
|
||||
- Livrable: domaine actif et configurable (DNS accessible).
|
||||
|
||||
### 2) Serveur personnel
|
||||
- OS: Linux Ubuntu (LTS).
|
||||
- Reverse proxy: Traefik.
|
||||
- Forge logicielle: Forgejo.
|
||||
- Automatisation: n8n.
|
||||
- Environnement de developpement: Docker (stack dev).
|
||||
|
||||
## Plan d'implementation
|
||||
|
||||
### Phase 1 - Fondations
|
||||
- Reserver le nom de domaine.
|
||||
- Provisionner le serveur (VPS ou machine dediee).
|
||||
- Installer Ubuntu LTS et appliquer la securisation de base (SSH, firewall, MAJ).
|
||||
- Configurer DNS du domaine vers le serveur.
|
||||
|
||||
Critere de sortie:
|
||||
- Serveur joignable de facon securisee.
|
||||
- Domaine resolu correctement vers l'IP cible.
|
||||
|
||||
### Phase 2 - Couche d'entree (Traefik)
|
||||
- Installer Docker et Docker Compose.
|
||||
- Deployer Traefik en point d'entree unique.
|
||||
- Configurer HTTPS automatique (Let's Encrypt) et routage par sous-domaines.
|
||||
|
||||
Critere de sortie:
|
||||
- Acces HTTPS operationnel.
|
||||
- Routage valide pour au moins un service test.
|
||||
|
||||
### Phase 3 - Services coeur
|
||||
- Deployer Forgejo (ex: git.aulnette.eu).
|
||||
- Deployer n8n (ex: n8n.aulnette.eu).
|
||||
- Definir les volumes persistants et la strategie de sauvegarde.
|
||||
|
||||
Critere de sortie:
|
||||
- Forgejo et n8n accessibles, authentification active, donnees persistantes.
|
||||
|
||||
### Phase 4 - Stack Docker de dev
|
||||
- Creer une stack dev standard (compose) pour experimentation locale/serveur.
|
||||
- Definir conventions minimales: nommage, reseaux, secrets, logs.
|
||||
- Documenter le process de deploiement et de rollback.
|
||||
|
||||
Critere de sortie:
|
||||
- Une stack dev de reference deployee et reproductible.
|
||||
|
||||
## Process d'exploitation (version initiale)
|
||||
|
||||
### Daily
|
||||
- Preparation de la journee.
|
||||
|
||||
### Weekly
|
||||
- Preparation de la semaine.
|
||||
- Revue technique: etat services, sauvegardes, securite.
|
||||
|
||||
### Monthly
|
||||
- Revue infra: couts, capacite, incidents, ameliorations.
|
||||
|
||||
### On trigger
|
||||
- Preparation one-to-one.
|
||||
- Incident production (procedure de reprise).
|
||||
- Ajout d'un nouveau service (checklist de deploiement).
|
||||
|
||||
## Backlog immediat (prochaines actions)
|
||||
- Choisir et reserver le nom de domaine.
|
||||
- Choisir l'hebergement serveur (provider + sizing).
|
||||
- Ecrire le premier docker-compose avec Traefik + service test.
|
||||
- Ajouter Forgejo puis n8n dans la stack.
|
||||
- Completer le point manquant de la liste initiale (element a preciser).
|
||||
908
10-projects/pkm/process/setup-serveur.md
Normal file
908
10-projects/pkm/process/setup-serveur.md
Normal file
|
|
@ -0,0 +1,908 @@
|
|||
# Setup — Serveur personnel
|
||||
|
||||
Référence : [[ADR-001-Mise en place d'un serveur personnel]]
|
||||
|
||||
**Stack décidée :** Ubuntu Server 24.04 LTS · SSH durci · Docker · Devcontainers · Traefik + Let's Encrypt · UFW + IPAllowList
|
||||
|
||||
---
|
||||
name : vps-6f98b55e.vps.ovh.net
|
||||
os : ubuntu 25.04
|
||||
Adresse IPv4 : 51.77.147.135
|
||||
Adresse IPv6 : 2001:41d0:404:200::53e0
|
||||
|
||||
## Phase 1 — Infrastructure de base
|
||||
|
||||
### 1.1 Installation Ubuntu Server 25.04 LTS
|
||||
|
||||
- [x] VPS installé par OVH
|
||||
|
||||
### 1.2 Configuration post-installation
|
||||
sudo adduser paulnette
|
||||
sudo usermod -aG sudo paulnette
|
||||
sudo mkdir -p /home/paulnette/.ssh
|
||||
sudo cp /home/ubuntu/.ssh/authorized_keys /home/paulnette/.ssh/
|
||||
sudo chown -R paulnette:paulnette /home/paulnette/.ssh
|
||||
sudo chmod 700 /home/paulnette/.ssh
|
||||
sudo chmod 600 /home/paulnette/.ssh/authorized_keys
|
||||
|
||||
|
||||
- [x] Mettre à jour le système : `sudo apt update && sudo apt upgrade -y`
|
||||
- [ ] Désactiver le login root SSH (`PermitRootLogin no` dans `/etc/ssh/sshd_config`)
|
||||
- [ ] Activer l'authentification par clé SSH uniquement (`PasswordAuthentication no`)
|
||||
- [x] Configurer le hostname : `sudo hostnamectl set-hostname <nom-serveur>`
|
||||
- [x] Configurer le fuseau horaire : `sudo timedatectl set-timezone Europe/Paris`
|
||||
- [ ] Activer les mises à jour de sécurité automatiques : `sudo apt install unattended-upgrades`
|
||||
|
||||
### 1.3 Pare-feu UFW
|
||||
|
||||
- [x] sudo apt install fail2ban
|
||||
|
||||
|
||||
> ⚠️ **Ordre impératif** : définir toutes les règles AVANT `ufw enable`.
|
||||
> `ufw default deny incoming` ne coupe rien tant que UFW n'est pas activé.
|
||||
> Si tu fais `ufw enable` sans avoir ajouté la règle SSH, tu perds l'accès distant — accès physique requis.
|
||||
|
||||
- [x] Installer UFW : `sudo apt install ufw`
|
||||
- [x] Définir les politiques par défaut (UFW inactif à ce stade) :
|
||||
```bash
|
||||
sudo ufw default deny incoming
|
||||
sudo ufw default allow outgoing
|
||||
```
|
||||
- [x] Autoriser SSH depuis les IPs fixes uniquement (**faire ceci avant `ufw enable`**) :
|
||||
```bash
|
||||
sudo ufw allow from 80.11.215.231 to any port 22 Rennes
|
||||
sudo ufw allow from 82.66.18.183 to any port 22 Chateaugiron
|
||||
```
|
||||
- [x] Autoriser HTTP/HTTPS (pour Traefik / Let's Encrypt) :
|
||||
```bash
|
||||
sudo ufw allow 80/tcp
|
||||
sudo ufw allow 443/tcp
|
||||
```
|
||||
- [x] Vérifier les règles avant activation : `sudo ufw show added`
|
||||
- [x] Activer UFW (seulement après vérification) : `sudo ufw enable`
|
||||
- [x] Vérifier l'état final : `sudo ufw status verbose`
|
||||
|
||||
### 1.4 Installation Docker
|
||||
|
||||
- [x] Installer Docker Engine (méthode officielle) :
|
||||
```bash
|
||||
curl -fsSL https://get.docker.com | sudo sh
|
||||
sudo usermod -aG docker $USER
|
||||
```
|
||||
- [x] Installer Docker Compose plugin :
|
||||
```bash
|
||||
sudo apt install docker-compose-plugin
|
||||
```
|
||||
- [x] Vérifier : `docker version` et `docker compose version`
|
||||
- [x] Activer Docker au démarrage : `sudo systemctl enable docker`
|
||||
|
||||
---
|
||||
|
||||
## Phase 2 — Traefik + Let's Encrypt
|
||||
|
||||
> Décision : utiliser le challenge Let's Encrypt HTTP-01.
|
||||
> Les ports `80/443` seront donc ouverts publiquement dans UFW.
|
||||
> Les services sensibles resteront filtrés côté Traefik avec `IPAllowList`.
|
||||
|
||||
### 2.1 Préparation DNS et pare-feu
|
||||
|
||||
- [ ] Choisir le nom DNS du dashboard Traefik : `traefik.aulnette.eu`
|
||||
|
||||
### 2.2 Structure de fichiers
|
||||
|
||||
```
|
||||
~/traefik/
|
||||
├── docker-compose.yml
|
||||
├── traefik.yml # config statique
|
||||
├── conf/
|
||||
│ └── dynamic.yml # config dynamique (middlewares, etc.)
|
||||
└── letsencrypt/
|
||||
└── acme.json # certificats (chmod 600 obligatoire)
|
||||
```
|
||||
|
||||
### 2.3 Création des fichiers
|
||||
|
||||
- [ ] Créer l'arborescence Traefik :
|
||||
```bash
|
||||
mkdir -p ~/traefik/conf ~/traefik/letsencrypt
|
||||
cd ~/traefik
|
||||
```
|
||||
- [x] Créer le fichier de stockage des certificats et verrouiller ses permissions :
|
||||
```bash
|
||||
touch letsencrypt/acme.json
|
||||
chmod 600 letsencrypt/acme.json
|
||||
```
|
||||
- [x] Créer le réseau Docker partagé :
|
||||
```bash
|
||||
docker network create traefik-public
|
||||
```
|
||||
|
||||
### 2.4 Configuration statique Traefik
|
||||
|
||||
- [x] Créer `~/traefik/traefik.yml` :
|
||||
```bash
|
||||
cd ~/traefik
|
||||
nano traefik.yml
|
||||
```
|
||||
Coller le contenu ci-dessous, puis enregistrer avec `Ctrl+O`, `Entrée`, `Ctrl+X`.
|
||||
|
||||
```yaml
|
||||
api:
|
||||
dashboard: true
|
||||
insecure: false
|
||||
|
||||
log:
|
||||
level: INFO
|
||||
|
||||
accessLog: {}
|
||||
|
||||
entryPoints:
|
||||
web:
|
||||
address: ":80"
|
||||
http:
|
||||
redirections:
|
||||
entryPoint:
|
||||
to: websecure
|
||||
scheme: https
|
||||
websecure:
|
||||
address: ":443"
|
||||
|
||||
providers:
|
||||
docker:
|
||||
endpoint: "unix:///var/run/docker.sock"
|
||||
network: traefik-public
|
||||
exposedByDefault: false
|
||||
file:
|
||||
directory: /conf
|
||||
watch: true
|
||||
|
||||
certificatesResolvers:
|
||||
letsencrypt:
|
||||
acme:
|
||||
email: philippe.aulnette@6tm.com
|
||||
storage: /letsencrypt/acme.json
|
||||
httpChallenge:
|
||||
entryPoint: web
|
||||
```
|
||||
|
||||
### 2.5 Middleware IPAllowList
|
||||
|
||||
- [ ] Créer `~/traefik/conf/dynamic.yml` :
|
||||
```bash
|
||||
cd ~/traefik
|
||||
nano conf/dynamic.yml
|
||||
```
|
||||
Coller le contenu ci-dessous, puis enregistrer avec `Ctrl+O`, `Entrée`, `Ctrl+X`.
|
||||
|
||||
```yaml
|
||||
http:
|
||||
middlewares:
|
||||
ip-allowlist:
|
||||
ipAllowList:
|
||||
sourceRange:
|
||||
- "80.11.215.231/32"
|
||||
- "82.66.18.183/32"
|
||||
```
|
||||
|
||||
### 2.6 Docker Compose Traefik
|
||||
|
||||
- [ ] Créer `~/traefik/docker-compose.yml` :
|
||||
```bash
|
||||
cd ~/traefik
|
||||
nano docker-compose.yml
|
||||
```
|
||||
Coller le contenu ci-dessous, puis enregistrer avec `Ctrl+O`, `Entrée`, `Ctrl+X`.
|
||||
|
||||
```yaml
|
||||
services:
|
||||
traefik:
|
||||
image: traefik:v3.6.16
|
||||
container_name: traefik
|
||||
restart: unless-stopped
|
||||
|
||||
ports:
|
||||
- "80:80"
|
||||
- "443:443"
|
||||
|
||||
networks:
|
||||
- traefik-public
|
||||
|
||||
volumes:
|
||||
- /var/run/docker.sock:/var/run/docker.sock:ro
|
||||
- ./traefik.yml:/etc/traefik/traefik.yml:ro
|
||||
- ./conf:/conf:ro
|
||||
- ./letsencrypt:/letsencrypt
|
||||
|
||||
labels:
|
||||
- "traefik.enable=true"
|
||||
- "traefik.http.routers.traefik.rule=Host(`traefik.aulnette.eu`)"
|
||||
- "traefik.http.routers.traefik.entrypoints=websecure"
|
||||
- "traefik.http.routers.traefik.tls=true"
|
||||
- "traefik.http.routers.traefik.tls.certresolver=letsencrypt"
|
||||
- "traefik.http.routers.traefik.service=api@internal"
|
||||
- "traefik.http.routers.traefik.middlewares=ip-allowlist@file"
|
||||
|
||||
networks:
|
||||
traefik-public:
|
||||
external: true
|
||||
```
|
||||
|
||||
### 2.7 Démarrage et vérification
|
||||
|
||||
- [x] Valider la configuration Docker Compose :
|
||||
```bash
|
||||
cd ~/traefik
|
||||
docker compose config
|
||||
```
|
||||
- [x] Démarrer Traefik :
|
||||
```bash
|
||||
docker compose up -d
|
||||
```
|
||||
- [x] Vérifier que le container tourne :
|
||||
```bash
|
||||
docker compose ps
|
||||
```
|
||||
- [x] Suivre les logs jusqu'à génération du certificat :
|
||||
```bash
|
||||
docker compose logs -f traefik
|
||||
```
|
||||
- [x] Vérifier l'accès HTTPS depuis une IP autorisée :
|
||||
```bash
|
||||
curl -I https://traefik.aulnette.eu
|
||||
```
|
||||
- [x] Vérifier que le dashboard est accessible uniquement depuis les IPs autorisées :
|
||||
```text
|
||||
https://traefik.<domaine>
|
||||
```
|
||||
- [ ] Vérifier que `acme.json` contient un certificat :
|
||||
```bash
|
||||
sudo ls -l ~/traefik/letsencrypt/acme.json
|
||||
sudo wc -c ~/traefik/letsencrypt/acme.json
|
||||
```
|
||||
|
||||
### 2.8 Garde-fous
|
||||
|
||||
- [ ] Ne pas activer `api.insecure: true`
|
||||
- [ ] Ne pas exposer un service sans label explicite `traefik.enable=true`
|
||||
- [ ] Garder le socket Docker en lecture seule : `/var/run/docker.sock:/var/run/docker.sock:ro`
|
||||
- [ ] Appliquer `ip-allowlist@file` à tous les services d'administration
|
||||
- [ ] Documenter tout nouveau service exposé dans ce fichier avant mise en ligne
|
||||
|
||||
---
|
||||
|
||||
## Phase 3 — Services cœur (Forgejo + n8n)
|
||||
|
||||
> Objectif : déployer Forgejo (forge Git) et n8n (automatisation), tous deux derrière Traefik, avec stockage persistant et stratégie de sauvegarde.
|
||||
>
|
||||
> **Critère de sortie** : Forgejo et n8n accessibles en HTTPS, authentification active, données persistantes survivant à un `docker compose down`.
|
||||
|
||||
### 3.1 Préparation DNS
|
||||
|
||||
- [x] Créer les enregistrements DNS (A + AAAA) pointant vers le VPS :
|
||||
- `git.aulnette.eu` → `51.77.147.135` / `2001:41d0:404:200::53e0`
|
||||
- `flux.aulnette.eu` → `51.77.147.135` / `2001:41d0:404:200::53e0`
|
||||
- [x] Vérifier la propagation : `dig +short git.aulnette.eu` et `dig +short flux.aulnette.eu`
|
||||
|
||||
### 3.2 Convention de stockage persistant
|
||||
|
||||
Tous les volumes applicatifs sont regroupés sous `/srv/docker/<service>/` pour faciliter la sauvegarde.
|
||||
|
||||
```
|
||||
/srv/docker/
|
||||
├── forgejo/
|
||||
│ ├── data/ # dépôts Git, configuration, attachements
|
||||
│ └── db/ # base PostgreSQL Forgejo
|
||||
└── n8n/
|
||||
└── data/ # workflows, credentials, exécutions
|
||||
```
|
||||
|
||||
- [x] Créer l'arborescence :
|
||||
```bash
|
||||
sudo mkdir -p /srv/docker/forgejo/data /srv/docker/forgejo/db /srv/docker/n8n/data
|
||||
sudo chown -R 1000:1000 /srv/docker/forgejo /srv/docker/n8n
|
||||
```
|
||||
|
||||
> ⚠️ **Permissions importantes** : les containers Forgejo (user `git`) et n8n (user `node`) tournent en **uid 1000** par défaut. Sur ce VPS, l'utilisateur `paulnette` est en uid 1001 (l'uid 1000 est déjà pris par le user `ubuntu` créé par OVH). Il faut donc chown vers `1000:1000` (UID/GID *du container*), pas vers `$USER`. Sinon : `EACCES: permission denied, open '/home/node/.n8n/config'` au démarrage.
|
||||
>
|
||||
> Vérifier : `id paulnette` doit montrer `uid=1001`, et `ls -ln /srv/docker/n8n` doit montrer `1000 1000`.
|
||||
|
||||
### 3.3 Déploiement Forgejo
|
||||
|
||||
#### 3.3.1 Structure
|
||||
|
||||
```
|
||||
~/forgejo/
|
||||
└── docker-compose.yml
|
||||
```
|
||||
|
||||
- [x] Créer le répertoire :
|
||||
```bash
|
||||
mkdir -p ~/forgejo
|
||||
cd ~/forgejo
|
||||
```
|
||||
|
||||
#### 3.3.2 Docker Compose
|
||||
|
||||
- [ ] Créer `~/forgejo/docker-compose.yml` :
|
||||
```bash
|
||||
cd ~/forgejo
|
||||
nano docker-compose.yml
|
||||
```
|
||||
Coller le contenu ci-dessous, puis enregistrer avec `Ctrl+O`, `Entrée`, `Ctrl+X`.
|
||||
|
||||
```yaml
|
||||
services:
|
||||
forgejo:
|
||||
image: codeberg.org/forgejo/forgejo:10
|
||||
container_name: forgejo
|
||||
restart: unless-stopped
|
||||
depends_on:
|
||||
- forgejo-db
|
||||
environment:
|
||||
- USER_UID=1000
|
||||
- USER_GID=1000
|
||||
- FORGEJO__database__DB_TYPE=postgres
|
||||
- FORGEJO__database__HOST=forgejo-db:5432
|
||||
- FORGEJO__database__NAME=forgejo
|
||||
- FORGEJO__database__USER=forgejo
|
||||
- FORGEJO__database__PASSWD=${FORGEJO_DB_PASSWORD}
|
||||
- FORGEJO__server__DOMAIN=git.aulnette.eu
|
||||
- FORGEJO__server__ROOT_URL=https://git.aulnette.eu/
|
||||
- FORGEJO__server__SSH_DOMAIN=git.aulnette.eu
|
||||
- FORGEJO__service__DISABLE_REGISTRATION=true
|
||||
- FORGEJO__security__INSTALL_LOCK=true
|
||||
volumes:
|
||||
- /srv/docker/forgejo/data:/var/lib/gitea
|
||||
- /etc/timezone:/etc/timezone:ro
|
||||
- /etc/localtime:/etc/localtime:ro
|
||||
networks:
|
||||
- traefik-public
|
||||
- forgejo-internal
|
||||
labels:
|
||||
- "traefik.enable=true"
|
||||
- "traefik.http.routers.forgejo.rule=Host(`git.aulnette.eu`)"
|
||||
- "traefik.http.routers.forgejo.entrypoints=websecure"
|
||||
- "traefik.http.routers.forgejo.tls=true"
|
||||
- "traefik.http.routers.forgejo.tls.certresolver=letsencrypt"
|
||||
- "traefik.http.routers.forgejo.middlewares=ip-allowlist@file"
|
||||
- "traefik.http.services.forgejo.loadbalancer.server.port=3000"
|
||||
- "traefik.docker.network=traefik-public"
|
||||
|
||||
forgejo-db:
|
||||
image: postgres:16-alpine
|
||||
container_name: forgejo-db
|
||||
restart: unless-stopped
|
||||
environment:
|
||||
- POSTGRES_USER=forgejo
|
||||
- POSTGRES_PASSWORD=${FORGEJO_DB_PASSWORD}
|
||||
- POSTGRES_DB=forgejo
|
||||
volumes:
|
||||
- /srv/docker/forgejo/db:/var/lib/postgresql/data
|
||||
networks:
|
||||
- forgejo-internal
|
||||
|
||||
networks:
|
||||
traefik-public:
|
||||
external: true
|
||||
forgejo-internal:
|
||||
driver: bridge
|
||||
```
|
||||
|
||||
#### 3.3.3 Secrets et démarrage
|
||||
|
||||
- [x] Créer `~/forgejo/.env` (ne jamais commiter) :
|
||||
```bash
|
||||
cd ~/forgejo
|
||||
echo "FORGEJO_DB_PASSWORD=$(openssl rand -base64 32)" > .env
|
||||
chmod 600 .env
|
||||
```
|
||||
- [x] Démarrer Forgejo :
|
||||
```bash
|
||||
docker compose up -d
|
||||
docker compose logs -f forgejo
|
||||
```
|
||||
- [x] Vérifier l'accès : `curl -I https://git.aulnette.eu`
|
||||
- [x] Créer le premier utilisateur administrateur (registration désactivée — passer par la CLI) :
|
||||
```bash
|
||||
docker compose exec -u git forgejo forgejo admin user create \
|
||||
--username paulnette --admin \
|
||||
--email philippe.aulnette@6tm.com \
|
||||
--random-password
|
||||
```
|
||||
|
||||
> ⚠️ Le flag `-u git` est obligatoire. Sans lui, `docker compose exec` lance la commande en root et Forgejo refuse de démarrer (`Forgejo is not supposed to be run as root`).
|
||||
|
||||
- [x] Se connecter à `https://git.aulnette.eu`, changer le mot de passe, ajouter sa clé SSH
|
||||
|
||||
> **Garde-fou** : Forgejo est protégé par `ip-allowlist@file`. L'accès web ET les opérations Git via HTTPS (clone/push/pull) ne fonctionnent que depuis les IPs autorisées dans `~/traefik/conf/dynamic.yml`. Toute nouvelle IP (déplacement, partage avec un tiers) doit être ajoutée à l'allowlist.
|
||||
|
||||
> **Note SSH Forgejo** : le port SSH 22 du serveur est déjà occupé par OpenSSH. Pour activer le clone Git par SSH, exposer le SSH Forgejo sur un port alternatif (ex: 2222) et l'autoriser dans UFW depuis les mêmes IPs fixes. À défaut, utiliser HTTPS uniquement dans un premier temps.
|
||||
|
||||
### 3.4 Déploiement n8n
|
||||
|
||||
#### 3.4.1 Structure
|
||||
|
||||
```
|
||||
~/n8n/
|
||||
└── docker-compose.yml
|
||||
```
|
||||
|
||||
- [x] Créer le répertoire :
|
||||
```bash
|
||||
mkdir -p ~/n8n
|
||||
cd ~/n8n
|
||||
```
|
||||
|
||||
#### 3.4.2 Docker Compose
|
||||
|
||||
- [x] Créer `~/n8n/docker-compose.yml` :
|
||||
```bash
|
||||
cd ~/n8n
|
||||
nano docker-compose.yml
|
||||
```
|
||||
Coller le contenu ci-dessous, puis enregistrer avec `Ctrl+O`, `Entrée`, `Ctrl+X`.
|
||||
|
||||
```yaml
|
||||
services:
|
||||
n8n:
|
||||
image: n8nio/n8n:latest
|
||||
container_name: n8n
|
||||
restart: unless-stopped
|
||||
environment:
|
||||
- N8N_HOST=flux.aulnette.eu
|
||||
- N8N_PORT=5678
|
||||
- N8N_PROTOCOL=https
|
||||
- WEBHOOK_URL=https://flux.aulnette.eu/
|
||||
- GENERIC_TIMEZONE=Europe/Paris
|
||||
- TZ=Europe/Paris
|
||||
- N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}
|
||||
- N8N_BLOCK_ENV_ACCESS_IN_NODE=true
|
||||
- N8N_RUNNERS_DISABLE_PYTHON=true
|
||||
volumes:
|
||||
- /srv/docker/n8n/data:/home/node/.n8n
|
||||
networks:
|
||||
- traefik-public
|
||||
labels:
|
||||
- "traefik.enable=true"
|
||||
- "traefik.http.routers.n8n.rule=Host(`flux.aulnette.eu`)"
|
||||
- "traefik.http.routers.n8n.entrypoints=websecure"
|
||||
- "traefik.http.routers.n8n.tls=true"
|
||||
- "traefik.http.routers.n8n.tls.certresolver=letsencrypt"
|
||||
- "traefik.http.routers.n8n.middlewares=ip-allowlist@file"
|
||||
- "traefik.http.services.n8n.loadbalancer.server.port=5678"
|
||||
- "traefik.docker.network=traefik-public"
|
||||
|
||||
networks:
|
||||
traefik-public:
|
||||
external: true
|
||||
```
|
||||
|
||||
> ⚠️ `N8N_ENCRYPTION_KEY` chiffre les credentials stockés. La perdre = perdre l'accès à tous les credentials configurés. La sauvegarder hors-serveur.
|
||||
|
||||
> **Notes sur les variables d'environnement n8n** :
|
||||
> - `N8N_RUNNERS_ENABLED` n'est plus nécessaire (activé par défaut depuis n8n récent) — la mettre génère un warning de dépréciation.
|
||||
> - `N8N_RUNNERS_DISABLE_PYTHON=true` supprime le warning au démarrage signalant l'absence de Python 3 dans l'image. **Choix retenu** : on ignore Python — les Code nodes seront écrits uniquement en JavaScript. Si un jour un besoin réel de Python émerge, il faudra construire une image custom basée sur `n8nio/n8n:latest` avec `apk add python3 py3-pip`.
|
||||
|
||||
#### 3.4.3 Secrets et démarrage
|
||||
|
||||
- [x] Créer `~/n8n/.env` :
|
||||
```bash
|
||||
cd ~/n8n
|
||||
echo "N8N_ENCRYPTION_KEY=$(openssl rand -hex 32)" > .env
|
||||
chmod 600 .env
|
||||
```
|
||||
- [x] **Sauvegarder la clé `N8N_ENCRYPTION_KEY` dans un gestionnaire de mots de passe externe** (Bitwarden / 1Password / KeePass)
|
||||
- [ ] Démarrer n8n :
|
||||
```bash
|
||||
docker compose up -d
|
||||
docker compose logs -f n8n
|
||||
```
|
||||
- [ ] Vérifier l'accès : `curl -I https://flux.aulnette.eu`
|
||||
- [ ] Se connecter à `https://flux.aulnette.eu`, créer le compte propriétaire (premier utilisateur = owner)
|
||||
|
||||
> **Garde-fou** : n8n est protégé par `ip-allowlist@file` car il manipule des credentials sensibles et peut exécuter du code arbitraire. Aucun accès depuis l'extérieur des IPs autorisées.
|
||||
|
||||
### 3.5 Stratégie de sauvegarde
|
||||
|
||||
Approche : **dump applicatif + snapshot fichiers**, déposés dans `/srv/backups/` puis envoyés vers un stockage distant.
|
||||
|
||||
#### 3.5.1 Préparation
|
||||
|
||||
- [ ] Créer le répertoire local de sauvegarde :
|
||||
```bash
|
||||
sudo mkdir -p /srv/backups/forgejo /srv/backups/n8n
|
||||
sudo chown -R $USER:$USER /srv/backups
|
||||
```
|
||||
- [ ] Installer les outils nécessaires :
|
||||
```bash
|
||||
sudo apt install -y restic
|
||||
```
|
||||
|
||||
#### 3.5.2 Script de sauvegarde quotidien
|
||||
|
||||
- [ ] Créer `/usr/local/bin/backup-services.sh` :
|
||||
```bash
|
||||
sudo nano /usr/local/bin/backup-services.sh
|
||||
```
|
||||
Coller le contenu ci-dessous :
|
||||
|
||||
```bash
|
||||
#!/usr/bin/env bash
|
||||
set -euo pipefail
|
||||
|
||||
DATE=$(date +%Y%m%d-%H%M%S)
|
||||
BACKUP_DIR=/srv/backups
|
||||
|
||||
# --- Forgejo ---
|
||||
# 1. Dump PostgreSQL
|
||||
docker exec forgejo-db pg_dump -U forgejo forgejo \
|
||||
| gzip > "${BACKUP_DIR}/forgejo/db-${DATE}.sql.gz"
|
||||
|
||||
# 2. Dump applicatif Forgejo (dépôts + config)
|
||||
docker exec forgejo forgejo dump --type tar.gz --file /tmp/forgejo-dump.tar.gz
|
||||
docker cp forgejo:/tmp/forgejo-dump.tar.gz "${BACKUP_DIR}/forgejo/dump-${DATE}.tar.gz"
|
||||
docker exec forgejo rm /tmp/forgejo-dump.tar.gz
|
||||
|
||||
# --- n8n ---
|
||||
# Arrêt court pour cohérence du SQLite interne
|
||||
docker compose -f /home/paulnette/n8n/docker-compose.yml stop n8n
|
||||
tar czf "${BACKUP_DIR}/n8n/data-${DATE}.tar.gz" -C /srv/docker/n8n data
|
||||
docker compose -f /home/paulnette/n8n/docker-compose.yml start n8n
|
||||
|
||||
# --- Rotation locale (garder 7 jours) ---
|
||||
find "${BACKUP_DIR}" -type f -name "*.gz" -mtime +7 -delete
|
||||
```
|
||||
|
||||
- [ ] Rendre exécutable :
|
||||
```bash
|
||||
sudo chmod +x /usr/local/bin/backup-services.sh
|
||||
```
|
||||
- [ ] Tester manuellement :
|
||||
```bash
|
||||
sudo /usr/local/bin/backup-services.sh
|
||||
ls -lh /srv/backups/forgejo /srv/backups/n8n
|
||||
```
|
||||
|
||||
#### 3.5.3 Planification (cron)
|
||||
|
||||
- [ ] Ajouter au crontab root (sauvegarde quotidienne à 03:30) :
|
||||
```bash
|
||||
sudo crontab -e
|
||||
```
|
||||
Ajouter la ligne :
|
||||
```
|
||||
30 3 * * * /usr/local/bin/backup-services.sh >> /var/log/backup-services.log 2>&1
|
||||
```
|
||||
|
||||
#### 3.5.4 Externalisation (restic)
|
||||
|
||||
> Sans copie hors serveur, une sauvegarde locale ne protège ni d'une corruption du disque, ni d'une perte du VPS.
|
||||
|
||||
- [ ] Choisir une destination : OVH Object Storage (S3), Backblaze B2, ou autre VPS
|
||||
- [ ] Initialiser le dépôt restic (exemple S3) :
|
||||
```bash
|
||||
export RESTIC_REPOSITORY=s3:s3.gra.io.cloud.ovh.net/backup-vps-paulnette
|
||||
export RESTIC_PASSWORD=<phrase-secrete-forte>
|
||||
export AWS_ACCESS_KEY_ID=...
|
||||
export AWS_SECRET_ACCESS_KEY=...
|
||||
restic init
|
||||
```
|
||||
- [ ] **Sauvegarder `RESTIC_PASSWORD` dans le gestionnaire de mots de passe externe** (sans elle, restauration impossible)
|
||||
- [ ] Ajouter un second cron (après la sauvegarde locale, 04:00) qui pousse `/srv/backups` vers restic et applique une rétention (par exemple 7 quotidiennes + 4 hebdomadaires + 6 mensuelles)
|
||||
|
||||
#### 3.5.5 Test de restauration
|
||||
|
||||
> Une sauvegarde non testée n'est pas une sauvegarde.
|
||||
|
||||
- [ ] Restaurer un dump Forgejo dans un container jetable et vérifier l'intégrité d'au moins un dépôt
|
||||
- [ ] Restaurer le volume n8n dans un répertoire temporaire et vérifier la présence des workflows
|
||||
- [ ] Documenter la procédure de restauration dans ce fichier (à compléter après le premier test réussi)
|
||||
|
||||
### 3.6 Critères de sortie Phase 3
|
||||
|
||||
- [ ] `https://git.aulnette.eu` accessible depuis IPs autorisées uniquement, certificat valide, login admin fonctionnel
|
||||
- [ ] `https://flux.aulnette.eu` accessible depuis IPs autorisées uniquement, certificat valide, compte owner créé
|
||||
- [ ] `docker compose down && docker compose up -d` sur chaque service ne fait perdre aucune donnée
|
||||
- [ ] Script de sauvegarde exécuté avec succès au moins une fois, fichiers présents dans `/srv/backups/`
|
||||
- [ ] Cron quotidien actif et journalisé dans `/var/log/backup-services.log`
|
||||
- [ ] Sauvegarde externalisée vers stockage distant opérationnelle
|
||||
- [ ] Au moins une restauration test effectuée et documentée
|
||||
- [ ] `N8N_ENCRYPTION_KEY` et `RESTIC_PASSWORD` stockés hors serveur
|
||||
|
||||
---
|
||||
|
||||
## Phase 4 - Environnements de dev avec Codex
|
||||
|
||||
> Objectif : preparer un environnement de developpement distant utilisable par Codex, isole du compte d'administration principal, avec un utilisateur systeme dedie : `merlin`.
|
||||
>
|
||||
> Decision : `merlin` represente l'agent IA. Il doit pouvoir travailler sur des depots et lancer des environnements de dev, mais ne doit pas devenir un compte d'administration generaliste sans controle.
|
||||
|
||||
### 4.1 Principes de securite
|
||||
|
||||
- [ ] Creer un utilisateur Linux dedie `merlin`
|
||||
- [ ] Ne pas donner `sudo` par defaut a `merlin`
|
||||
- [ ] Authentification SSH par cle uniquement
|
||||
- [ ] Acces SSH limite aux IPs autorisees par UFW
|
||||
- [ ] Depots de travail sous `/home/merlin/workspaces/`
|
||||
- [ ] Secrets jamais stockes en clair dans les depots
|
||||
- [ ] Utiliser des `.env` locaux non commites pour les credentials de dev
|
||||
|
||||
### 4.2 Creation de l'utilisateur `merlin`
|
||||
|
||||
- [ ] Creer l'utilisateur :
|
||||
```bash
|
||||
sudo adduser merlin
|
||||
```
|
||||
- [ ] Creer le dossier SSH :
|
||||
```bash
|
||||
sudo mkdir -p /home/merlin/.ssh
|
||||
sudo nano /home/merlin/.ssh/authorized_keys
|
||||
sudo chown -R merlin:merlin /home/merlin/.ssh
|
||||
sudo chmod 700 /home/merlin/.ssh
|
||||
sudo chmod 600 /home/merlin/.ssh/authorized_keys
|
||||
```
|
||||
- [ ] Tester la connexion SSH :
|
||||
```bash
|
||||
ssh merlin@vps-6f98b55e.vps.ovh.net
|
||||
```
|
||||
|
||||
> Point d'attention : ne pas reutiliser la cle SSH personnelle d'administration si l'objectif est d'isoler les usages. Creer une cle specifique `merlin` cote poste local.
|
||||
|
||||
### 4.3 Arborescence de travail
|
||||
|
||||
```text
|
||||
/home/merlin/workspaces/
|
||||
+-- pkm-perso/
|
||||
+-- seenaps/
|
||||
+-- sandbox/
|
||||
```
|
||||
|
||||
- [ ] Creer le dossier standard :
|
||||
```bash
|
||||
sudo mkdir -p /home/merlin/workspaces
|
||||
sudo chown -R merlin:merlin /home/merlin/workspaces
|
||||
```
|
||||
|
||||
> Choix initial : `/home/merlin/workspaces/`. C'est plus simple et suffisant tant qu'il n'y a pas plusieurs agents ou plusieurs utilisateurs.
|
||||
|
||||
### 4.4 Acces Git et Forgejo
|
||||
|
||||
- [ ] Creer une cle SSH Git pour `merlin` :
|
||||
```bash
|
||||
sudo -u merlin ssh-keygen -t ed25519 -C "merlin@vps-codex" -f /home/merlin/.ssh/id_ed25519
|
||||
```
|
||||
- [ ] Ajouter la cle publique dans Forgejo :
|
||||
```bash
|
||||
sudo cat /home/merlin/.ssh/id_ed25519.pub
|
||||
```
|
||||
- [ ] Configurer l'identite Git :
|
||||
```bash
|
||||
sudo -u merlin git config --global user.name "Merlin"
|
||||
sudo -u merlin git config --global user.email "pa.ia@6tm.com"
|
||||
```
|
||||
- [ ] Tester un clone depuis Forgejo :
|
||||
```bash
|
||||
sudo -u merlin git clone <url-du-repo> /home/merlin/workspaces/<repo>
|
||||
```
|
||||
|
||||
> Convention : les commits produits par l'agent IA utilisent l'identite `Merlin <pa.ia@6tm.com>` pour rester auditables.
|
||||
|
||||
### 4.5 Outillage de base dev
|
||||
|
||||
- [ ] Installer les outils socle :
|
||||
```bash
|
||||
sudo apt install -y git curl unzip build-essential
|
||||
```
|
||||
- [ ] Installer Node.js via une methode stable, par exemple `nvm` pour l'utilisateur `merlin`
|
||||
- [ ] Installer Python et venv si necessaire :
|
||||
```bash
|
||||
sudo apt install -y python3 python3-venv python3-pip
|
||||
```
|
||||
- [ ] Verifier les versions :
|
||||
```bash
|
||||
git --version
|
||||
node --version
|
||||
npm --version
|
||||
python3 --version
|
||||
```
|
||||
|
||||
### 4.6 Devcontainers et Docker
|
||||
|
||||
Deux options :
|
||||
|
||||
1. **Mode prudent** : `merlin` ne fait pas partie du groupe `docker`. Les builds Docker sont lances manuellement par `paulnette`.
|
||||
2. **Mode autonome** : `merlin` est ajoute au groupe `docker`, ce qui donne un pouvoir quasi-root via Docker.
|
||||
|
||||
- [ ] Choisir explicitement le mode
|
||||
- [ ] Si mode autonome, ajouter `merlin` au groupe Docker :
|
||||
```bash
|
||||
sudo usermod -aG docker merlin
|
||||
```
|
||||
- [ ] Documenter le choix de securite retenu
|
||||
|
||||
> Position initiale : commencer en mode prudent. Ajouter `merlin` au groupe `docker` seulement si le besoin de devcontainers autonomes est reel.
|
||||
|
||||
### 4.7 Codex CLI / agent IA
|
||||
|
||||
- [ ] Definir le mode d'installation de Codex pour `merlin`
|
||||
- [ ] Installer Codex dans l'environnement utilisateur `merlin`
|
||||
- [ ] Creer un dossier de configuration :
|
||||
```bash
|
||||
sudo -u merlin mkdir -p /home/merlin/.codex
|
||||
```
|
||||
- [ ] Stocker les credentials Codex selon le mecanisme officiel choisi, jamais dans un repo
|
||||
- [ ] Tester une session Codex dans un repo de test
|
||||
|
||||
> Garde-fou : `merlin` doit etre capable de modifier un workspace, mais pas de reconfigurer le serveur, Traefik, Forgejo, n8n ou les sauvegardes sans intervention humaine.
|
||||
|
||||
### 4.8 Criteres de sortie Phase 4
|
||||
|
||||
- [ ] Connexion SSH `merlin` fonctionnelle par cle uniquement
|
||||
- [ ] `merlin` n'a pas `sudo` par defaut
|
||||
- [ ] Workspace standard cree et documente
|
||||
- [ ] Identite Git `Merlin <pa.ia@6tm.com>` configuree
|
||||
- [ ] Clone/pull/push testes sur un repo non critique
|
||||
- [ ] Mode Docker/devcontainer choisi et documente
|
||||
- [ ] Codex installe et teste dans un repo de test
|
||||
- [ ] Aucun secret Codex, Git, n8n ou serveur stocke en clair dans un depot
|
||||
|
||||
---
|
||||
|
||||
## Phase 5 - Environnement de developpement Codex sous `paulnette`
|
||||
|
||||
> Objectif : tester rapidement Codex sur le serveur avec le compte existant `paulnette`, avant de decider si l'isolation par l'utilisateur `merlin` est necessaire.
|
||||
>
|
||||
> Decision temporaire : `paulnette` peut servir au premier essai, mais uniquement dans un workspace dedie. Ne pas lancer Codex dans les repertoires d'administration serveur.
|
||||
|
||||
### 5.1 Garde-fous
|
||||
|
||||
- [ ] Utiliser uniquement `~/workspaces/` pour les tests Codex
|
||||
- [ ] Ne pas lancer Codex dans `~/traefik`, `~/forgejo`, `~/n8n`, `/srv/docker`, `/etc` ou `/usr/local/bin`
|
||||
- [ ] Ne pas stocker de secrets dans les repos
|
||||
- [ ] Verifier systematiquement `git status` et `git diff` avant tout commit
|
||||
- [ ] Garder `merlin` comme cible d'isolation future si l'usage Codex devient regulier
|
||||
|
||||
### 5.2 Preparation du workspace
|
||||
|
||||
- [ ] Creer l'arborescence de travail :
|
||||
```bash
|
||||
mkdir -p ~/workspaces/sandbox
|
||||
mkdir -p ~/workspaces/repos
|
||||
```
|
||||
- [ ] Creer un repo de test :
|
||||
```bash
|
||||
mkdir -p ~/workspaces/sandbox/codex-test
|
||||
cd ~/workspaces/sandbox/codex-test
|
||||
git init
|
||||
echo "# Codex test" > README.md
|
||||
git add README.md
|
||||
git commit -m "Initial commit"
|
||||
```
|
||||
|
||||
### 5.3 Outillage de base
|
||||
|
||||
- [ ] Verifier les outils installes :
|
||||
```bash
|
||||
git --version
|
||||
node --version
|
||||
npm --version
|
||||
python3 --version
|
||||
```
|
||||
- [ ] Installer les outils manquants :
|
||||
```bash
|
||||
sudo apt update
|
||||
sudo apt install -y git curl unzip build-essential python3 python3-venv python3-pip
|
||||
```
|
||||
|
||||
> Garde-fou maintenance : pour toute mise a jour systeme lancee en SSH, utiliser `tmux` afin de pouvoir reprendre la session en cas de coupure.
|
||||
|
||||
```bash
|
||||
tmux new -s maintenance
|
||||
sudo apt update
|
||||
sudo apt upgrade
|
||||
```
|
||||
|
||||
Reprendre la session :
|
||||
|
||||
```bash
|
||||
tmux attach -t maintenance
|
||||
```
|
||||
|
||||
### 5.4 Node.js
|
||||
|
||||
- [ ] Si Node.js n'est pas disponible, installer `nvm` pour `paulnette` :
|
||||
```bash
|
||||
curl -fsSL https://raw.githubusercontent.com/nvm-sh/nvm/master/install.sh | bash
|
||||
```
|
||||
- [ ] Recharger le shell :
|
||||
```bash
|
||||
source ~/.bashrc
|
||||
```
|
||||
- [ ] Installer Node.js LTS :
|
||||
```bash
|
||||
nvm install --lts
|
||||
nvm use --lts
|
||||
```
|
||||
- [ ] Verifier :
|
||||
```bash
|
||||
node --version
|
||||
npm --version
|
||||
```
|
||||
|
||||
### 5.5 Git
|
||||
|
||||
- [ ] Configurer l'identite Git de `paulnette` si necessaire :
|
||||
```bash
|
||||
git config --global user.name "Philippe Aulnette"
|
||||
git config --global user.email "philippe.aulnette@6tm.com"
|
||||
```
|
||||
- [ ] Verifier la configuration :
|
||||
```bash
|
||||
git config --global --list
|
||||
```
|
||||
|
||||
### 5.6 Codex CLI
|
||||
|
||||
- [ ] Installer Codex CLI selon la methode officielle retenue
|
||||
- [ ] Verifier l'installation :
|
||||
```bash
|
||||
codex --version
|
||||
```
|
||||
- [ ] Authentifier Codex :
|
||||
```bash
|
||||
codex login
|
||||
```
|
||||
|
||||
> Point d'attention : ne pas placer de cle API en clair dans `.bashrc` ou dans un fichier versionne. Preferer le mecanisme d'authentification officiel ou un stockage de secret adapte.
|
||||
|
||||
### 5.7 Premier test Codex
|
||||
|
||||
- [ ] Lancer Codex dans le repo de test :
|
||||
```bash
|
||||
cd ~/workspaces/sandbox/codex-test
|
||||
codex
|
||||
```
|
||||
- [ ] Demander un changement simple :
|
||||
```text
|
||||
Ajoute un fichier notes.md avec une checklist de test Codex.
|
||||
```
|
||||
- [ ] Verifier les modifications :
|
||||
```bash
|
||||
git status
|
||||
git diff
|
||||
```
|
||||
- [ ] Committer si le resultat est correct :
|
||||
```bash
|
||||
git add .
|
||||
git commit -m "Test Codex workspace"
|
||||
```
|
||||
|
||||
### 5.8 Contributions a d'autres depots
|
||||
|
||||
- [ ] Cloner les repos externes sous `~/workspaces/repos/`
|
||||
- [ ] Configurer une identite Git par repo si besoin :
|
||||
```bash
|
||||
git config user.name "Philippe Aulnette"
|
||||
git config user.email "philippe.aulnette@6tm.com"
|
||||
```
|
||||
- [ ] Utiliser des branches dediees pour les contributions :
|
||||
```bash
|
||||
git checkout -b feat/<sujet>
|
||||
```
|
||||
- [ ] Relire chaque diff avant push :
|
||||
```bash
|
||||
git status
|
||||
git diff
|
||||
```
|
||||
|
||||
### 5.9 Criteres de sortie Phase 5
|
||||
|
||||
- [ ] Workspace `~/workspaces/` cree
|
||||
- [ ] Repo `codex-test` initialise
|
||||
- [ ] Outils de base verifies
|
||||
- [ ] Codex installe et authentifie
|
||||
- [ ] Premier changement Codex teste dans un repo non critique
|
||||
- [ ] Workflow `git status` / `git diff` / commit valide
|
||||
- [ ] Decision prise : rester temporairement sur `paulnette` ou basculer vers `merlin`
|
||||
|
||||
---
|
||||
14
10-projects/pkm/process/template.md
Normal file
14
10-projects/pkm/process/template.md
Normal file
|
|
@ -0,0 +1,14 @@
|
|||
Nom : process-weekly
|
||||
Description :
|
||||
Fréquence :
|
||||
Déclencheur :
|
||||
## Input
|
||||
- Mon planning
|
||||
- Mes derniers mails
|
||||
## Etapes
|
||||
1. Récupère mon planning via le serveur MCP
|
||||
2.
|
||||
|
||||
## Méthodes
|
||||
|
||||
## Output
|
||||
10
10-projects/pkm/process/weekly.md
Normal file
10
10-projects/pkm/process/weekly.md
Normal file
|
|
@ -0,0 +1,10 @@
|
|||
Nom :
|
||||
Fréquence :
|
||||
Déclencheur :
|
||||
## Input
|
||||
|
||||
## Etapes
|
||||
|
||||
## Méthodes
|
||||
|
||||
## Output
|
||||
|
|
@ -1,16 +0,0 @@
|
|||
0 Inbox : Je ne sais pas encore
|
||||
1 Projets : ça à une fin
|
||||
2 Casquettes : c'est permanent
|
||||
3 Ressources : c'est une référence
|
||||
4 Archives :
|
||||
|
||||
Diago Forte : Para
|
||||
David Hallen : get things done
|
||||
|
||||
Arbre de décision :
|
||||
- je n'ai pas le temps de la traiter => inbox
|
||||
- si oui
|
||||
- si ca me fait avancer sur un projet : => projet
|
||||
- si c'est lié à une étiquette => areas
|
||||
- sinon est ce que ca peut être utile : ressources
|
||||
- sinon archives
|
||||
68
20-areas/pro/hpa/6nergy/laurent-raison.md
Normal file
68
20-areas/pro/hpa/6nergy/laurent-raison.md
Normal file
|
|
@ -0,0 +1,68 @@
|
|||
## 2024-05
|
||||
![[Pasted image 20260515124623.png]]
|
||||
![[Pasted image 20260515124743.png]]
|
||||
## 2023-05
|
||||
- yume > 2000 par mois
|
||||
|
||||
## 2022-09
|
||||
Bilan 6nergy :
|
||||
|
||||
- Ventes de participation
|
||||
|
||||
- ArchiReport 12500 fois 2
|
||||
- 3Vern : 130K
|
||||
- % 6tm - salariés
|
||||
|
||||
- Achat de participation
|
||||
|
||||
- RaisonHome 50K
|
||||
- YesWeHome 76K
|
||||
- Nooty 20K
|
||||
- Cebavest 2K
|
||||
|
||||
- 6nergy entre 600K et 1 000K => octobre 2023
|
||||
|
||||
- Bamboo : 223K,
|
||||
## 2022-04
|
||||
- Pilotage
|
||||
|
||||
- Dividendes, progression de valeur, point clé
|
||||
|
||||
- Projets sympa
|
||||
|
||||
- Hors service
|
||||
- Potentiel
|
||||
|
||||
Antoine :
|
||||
|
||||
- Nous aurons réussi 2022 si :
|
||||
|
||||
- Comptes mensuel, tréso, modèle éco => ambition derrière
|
||||
- Liste de basique :
|
||||
- Gouvernance
|
||||
- Carto des risques
|
||||
|
||||
Nous aurons réussi 2022 si :
|
||||
|
||||
- On a un vrai cockpit / pilotage :
|
||||
|
||||
- Réussi à se projeter sur un projet commun
|
||||
|
||||
Mickaël :
|
||||
|
||||
- s
|
||||
|
||||
- Nobilia
|
||||
|
||||
- Améliorer la qualité des poses : 3800, le nombre de retour SAV
|
||||
|
||||
- Groupe :
|
||||
|
||||
- Temps long
|
||||
- Ne pas être actionnaire dormant - mais actif : 15 à 20j par an, 1200j / an
|
||||
- Patrimonial :
|
||||
- Y passer du temps :
|
||||
|
||||
- Mickaël :
|
||||
|
||||
- Faire un * 3, 4
|
||||
155
20-areas/pro/hpa/6nergy/mail avril 2024.md
Normal file
155
20-areas/pro/hpa/6nergy/mail avril 2024.md
Normal file
|
|
@ -0,0 +1,155 @@
|
|||
Hello,
|
||||
|
||||
Je te rassure la référence Madoff n’était pas sur la partie escroc et honnêteté, mais sur la complexité du système et le fait que l’argent qui arrive finance les pertes du passé.
|
||||
|
||||
Sur les 29K ils sont fait pour accompagner cette phase difficile et donc à garder c’est mon rôle d’actionnaire. Ce que je déplore :
|
||||
|
||||
- C’est de ne pas pouvoir faire plus ! Le problème c’est que ça représente déjà 29K de plus que ce que j’ai dégagé de 6nergy ces 13 dernières années.
|
||||
- Que ce ne soit pas assortie d’une projection
|
||||
- Que ça finance le passé et des investissements que si j’avais eu 29K à mettre ce n’est pas là que je les aurais mis.
|
||||
|
||||
Là ou je pense que tu te trompes, c’est la partie chronophage des chiffres, c’est justement parce qu’on a cette complexité et pas ces chiffres et les décisions liées que c’est chronophage.
|
||||
|
||||
Donc pas de souci sur la confiance, on voit bien que chacun fait de son mieux. Pas de pb sur le côté entrepreneur. Le sujet c’est le résultat.
|
||||
|
||||
- Les résultats positifs servent à combler les pertes
|
||||
- En 13 ans j’aurai dégagé 5K et réinvestit 50K (les 29K et les 20 de frais divers sur les dernières opérations).
|
||||
- On a l’impression que le salut est lié à un coup de dé sur Gestéos
|
||||
- Au quotidien ce n’est pas l’éclate, voir fatigant de travailler avec certains profils
|
||||
- On peut imaginer continuer comme ça sur les 10 prochaines années avec le même résultat.
|
||||
|
||||
Clairement on se serait projeté comme ça en 2011 je n’aurai pas suivi
|
||||
|
||||
Perso je ne bosse pas 60H par semaine depuis 25 ans pour ce résultat. Donc je me fixe une step à fin d’année avec mes 50 ans, une vue sur 6mic, est-ce qu’on a un plan clair sur 6nergy, est ce que les 3 prochaines années m’intéressent ou pas.
|
||||
|
||||
Et en fonction je prendrais les décisions qui s’imposent, Une de mes lignes rouges va être que sur une sortie 6mic on ne soit pas obligé de réinvestir cette argent.
|
||||
|
||||
On peut s’appeler vers 18H, ou ce week-end
|
||||
|
||||
De : Laurent RAISON <[laurent.raison@raisonhome.com](mailto:laurent.raison@raisonhome.com)>
|
||||
|
||||
Envoyé : vendredi 5 avril 2024 10:27
|
||||
|
||||
À : Philippe Aulnette <[philippe.aulnette@6tm.com](mailto:philippe.aulnette@6tm.com)>
|
||||
|
||||
Cc : Stéphane Trémier <[stephane.tremier@6tm.com](mailto:stephane.tremier@6tm.com)>
|
||||
|
||||
Objet : Re: Finance
|
||||
|
||||
Bonjour Philippe,
|
||||
|
||||
Je ne sais pas quoi te dire...
|
||||
|
||||
- Tout d'abord merci pour les 29K€, c'est vraiment appréciable et utile
|
||||
- Je comprends aussi que cela ne t'aille pas et que tu sois lassé du temps mis à sortir de ce marasme
|
||||
- Enfin, je prends en pleine gueule la violence des propos avec la tirade sur Madoff... (qui a parlé de ça ? cautionnes-tu ces propos pour les écrire même avec des pincettes ? c'est me comparer avec un truand, c'est dingue...)
|
||||
|
||||
A vrai dire, je ne sais même plus si je dois te rendre tes 29K€ où les garder avec le poids supplémentaire sur les épaules...
|
||||
|
||||
Alors oui, nous sommes en fâcheuse posture sur Raison Home, nous avons perdu environ 500k sur l'année passée (rappel : nous avons levé 400K€ en augmentation de capital pour les compenser avec une option de 500K€ sur 2024). Par ailleurs, nous n'avons pas fait l'opération de vente des titres Gesteos pour étanchéifier les choses et avoir des pertes proches de "0". Outre ces pertes, la tréso est tendue (nous avons bouffé 750k avec Raison Contract) et le marché est très dur (même les allemands ont perdu de l'argent). Bref, je suis Président de cette boite mais je ne l'ai pas bien pilotée visiblement (DAF sorti trop tardivement, DG dont je ne sais pas s'il faut le garder, dépenses mal contrôlées...).
|
||||
|
||||
Qu'ai-je essayé de faire sur ces 2 dernières années ?
|
||||
|
||||
Sur 6nergy, renforcer les choses avec un costrat et des séminaires très réguliers, ceux-ci contenant la fourniture permanente de chiffres et des décisions prises. L'objectif sur ces 2 ans est bien exprimé et a été validé ensemble (je déroule le plan avec plus ou moins de bonheur dans un contexte marché délicat). Parmi les objectifs, nous avons notamment : étanchéifié les choses, simplifier l'organigramme et cela a, je crois, vraiment avancé même si cela n'est pas terminé :
|
||||
|
||||
- Les boites ont des comptes de résultats mensuels (6nergy d'ailleurs aussi) y compris les petites boites ce que nous n'avions pas chez 6TM lorsque nous faisions moins de 3M€
|
||||
- Un état des comptes courants et des factures clients-fournisseurs entre-nous a été présenté
|
||||
- Le dernier fichier Excel sur le financement où j'attends d'ailleurs des réponses (il y a maintenant un pacte d'actionnaires et un costrat engageant)
|
||||
- Gesteos est encore une filiale de Raison Home (même si je souhaite en sortir comme je le fais depuis quelques années. Cette année, je compte vraiment réaliser cette opération)
|
||||
- L'endettement de Gesteos a diminué par rapport à Juin 2022 où j'ai repris la présidence et devrait diminuer cette année avec la génération de cash par sa propre activité,
|
||||
- Wipoz a été sécurisé (au moins pour un temps) sauf à ce que Nobilia dise l'inverse de ce qu'ils nous ont proposé en mars.
|
||||
- RH belgique est maintenant suffisamment solide pour avoir son propre financement et rapporter beaucoup à sa maison mère (+ de 200K€)
|
||||
- Nootty et Me & My Boss sont suffisamment petites et maintenant ne consomment plus de cash
|
||||
|
||||
Retards de tréso :
|
||||
|
||||
- CBN12, j'ai délégué la gérance et la négo qui a été faite a décalé de 6 mois les paiements des 300 derniers K€ (au final : pour 6nergy c'est quand même + de 500K€ de plus values générées seul).
|
||||
- 6MIC, je confirme qu'il fallait vendre, le projet prend énormément de retard, horizon fin d'année maintenant (je suis aussi seul de 6nergy aux manettes) ==> plus value environ 1,2M€ pour nous 3. Je suis toujours preneur d'un coup de main dessus.
|
||||
- FRH, Contraction du marché (ventes et recrutement de franchisés) et des paiements de nos clients ==> impact 500K€ en tréso
|
||||
- J'ai de mon côté 500k€ de compte courant / rem non prises, je crois être loin d'un système madoff d'enrichissement personnel (j'ai couvert tout ce que j'ai pu)
|
||||
- Vente de Gesteos, d'un quasi-ok, nous avons pris au moins 3 mois de retard (nouvelle d'hier soir, ils envoient un canadien dans les 15 jours pour voir comment faire durablement l'inter-connexion avec Gesteos au coeur de leur plateforme et à priori sont prêts à la financer). Je crois donc qu'ils sont toujours accrochés même si c'est plus long (impact 2,7M€ en cash pour nous).
|
||||
- Wipoz : pas de cession à priori cette année mais nous faisons le forcing pour avoir une valorisation plancher. Je suis aussi bien sûr en train de parler de vendre avec un prix moindre (c'est aussi un des buts de la discussion du 16 Avril avec eux). Je vous envoie un mail à suivre qu'on compte leur envoyer lundi 8 pour se mettre en bonne position pour la négo.
|
||||
|
||||
Pour ce qui est des personnes incompétentes, as-tu une solution pour moi ? s'il s'agit d'Estelle uniquement, nous sommes en phase de vente donc impossible à changer mais l'horizon dans ce cas est clair. S'il y a d'autres personnes, merci d'avance de me dire de qui il s'agit pour traiter le sujet. En ce moment, je gère ce type de sujets même s'il m'en coûte de me séparer de quelques personnes, il y a toujours des effets de bord.
|
||||
|
||||
Pour le dossier Coulidoor auquel tu fais référence je crois, je ne suis pas rentré du tout dedans. Pour les chiffres dans le cockpit, pour Venidom, cela devait être les chiffres de Raison Home attendus depuis longtemps donc normalement ok. (Note : J'ai pu échanger sur le KPI taux de transfo, c'est incroyable sur le marché, personne n'est d'accord. Je reviens vers toi d'ici la semaine prochaine à ce sujet.)
|
||||
|
||||
Pour ce qui est de prendre nos pertes, je crois qu'avec l'arrêt de Raison Contract, j'ai bien prouvé que je savais les prendre (cela me coûte assez cher).
|
||||
|
||||
Prendre nos pertes alors qu'elles ne sont pas avérées, n'aide pas à trouver des capitaux, c'est même l'inverse (l'exemple de la revente de Gesteos qui ne peut pas couvrir les pertes et donc c'est incroyablement plus dur à vendre quand tes fonds propres sont à zéro : j'ai d'ailleurs mis près de 2 mois à oser retourner chercher des capitaux).
|
||||
|
||||
Par ailleurs, je n'ai plus soutenu les petites boîtes non stratégiques et non viables. Nous sommes sortis de l'hôtel à côté avec une belle plus value de 100k€. Maintenant, je ne compte pas arrêter Raison Home et je me concentre sur cette société pour revenir dès cette année à la rentabilité.
|
||||
|
||||
Sur ta proposition "avoir une vue réelle du scénario tendu" => proposition du mail précédent, il faut qu’on arrive à se bloquer du temps avec Steph et Antoine peut être ? ==> C'est ce que je prévois de faire avec tous les associés je compte vous proposer mercredi après-midi (lundi j'ai une réunion préparatoire avec Antoine et le RAF pour cela avec un budget précis)
|
||||
|
||||
La question qui se pose pour moi est celle de la confiance, intrinsèque en l'homme car toujours amener des chiffres et des éléments mouvants cela n'est pas simple et surtout très chronophage. Je sais que tu me fais confiance et je t'en remercie, sache que je ne l'ai jamais trahie et que, si j'ai fait des erreurs, ce sont des erreurs d'entrepreneurs.
|
||||
|
||||
Dans tous les cas, rien n'est sûr ... nous sommes entrepreneurs et tant que nous n'avons pas un énorme matelas tout peut s'arrêter. Rien ne dit que demain, cela ne sera pas 6TM qui faisant face à la révolution de l'IA, ou à un évènement exogène fort, perdra des marchés et j'espère alors que 6nergy/Raison Home seront là pour l'accompagner. J'essaye de participer au développement de 6TM quand je peux et nous contribuons au CA depuis plusieurs années quand même.
|
||||
|
||||
Bref, comme tu le vois, tu as touché qqch de profond chez moi qui touche à ma valeur honnêteté. Je me retrouve à la relecture de ce mail en train de me justifier même si je crois que c'est surtout explicatif pour convaincre qu'on avance dans le bon sens. Je crois toujours dans le fond que tu me fais confiance, et je te laisse libre de me dire pour les 29K€ si je peux les garder et donc que j'ai ta confiance ou si je te les rends pour ne pas porter un différentiel plus important. Je me sentirais plus à l'aise si nous sommes alignés.
|
||||
|
||||
Nous pouvons nous appeler cet après-midi si tu le souhaites.
|
||||
|
||||
A bientôt
|
||||
|
||||
Laurent
|
||||
|
||||
Le jeu. 4 avr. 2024 à 19:30, Philippe Aulnette <[philippe.aulnette@6tm.com](mailto:philippe.aulnette@6tm.com)> a écrit :
|
||||
|
||||
Hello, je viens de virer 29K qui doivent être en instantané, au-dessus de 30 je devais me lancer dans un justificatif.
|
||||
|
||||
Je comprends la criticité et la difficulté, la charge sur tes épaules et la complexité de la situation.
|
||||
|
||||
Cependant le fonctionnement ne me va pas du tout,
|
||||
|
||||
Je suis à l’opposé de ce qu’on s’est partagé il y a 2 ans,
|
||||
|
||||
Je suis incapable de mesurer l’ampleur de problème, d’avoir confiance dans les chiffres, dans la pertinence de l’euro investit, de m’appuyer sur un business plan nous permettant de montrer des perspectives et de piloter la situation.
|
||||
|
||||
Les flux entre les boites rendent la situation inbitable à tel point qu’on commence à entendre parler de système Madoff….
|
||||
|
||||
Et pendant ce temps là on s’éparpille et je fais du pompier avec des personnes non compétentes sur des projets non rentables…. Chercher l’erreur.
|
||||
|
||||
En résumé, j’ai 50 ans à la fin de l’année, je ne continue pas dans ces conditions sur les 5 prochaines années.
|
||||
|
||||
Ma proposition :
|
||||
|
||||
- Avoir une vue réelle du scénario tendu => proposition du mail précédent, il faut qu’on arrive à se bloquer du temps avec Steph et Antoine peut être ?
|
||||
- Je pense qu’a un moment il faut qu’on acte les pertes de valeurs sur certaines boites pour aller chercher des capitaux
|
||||
- Ne peut-on pas vendre nos participations Wipoz avec une perte de valeur obligeant Nobilia à se positionner ?
|
||||
|
||||
A+
|
||||
|
||||
De : Laurent RAISON <[laurent.raison@raisonhome.com](mailto:laurent.raison@raisonhome.com)>
|
||||
|
||||
Envoyé : jeudi 4 avril 2024 16:13
|
||||
|
||||
À : Philippe Aulnette <[philippe.aulnette@6tm.com](mailto:philippe.aulnette@6tm.com)>
|
||||
|
||||
Objet : Re: Finance
|
||||
|
||||
Le plus long possible, c’est le mieux pour moi. Toutefois, si tu as une contrainte de très courte durée, on peut très bien se dire que au moment où je récupère les 300 000 € il y a les 30 000 qui te reviennent.
|
||||
|
||||
Le jeu. 4 avr. 2024 à 16:06, Philippe Aulnette <[philippe.aulnette@6tm.com](mailto:philippe.aulnette@6tm.com)> a écrit :
|
||||
|
||||
Une idée de la durée ?
|
||||
|
||||
De : Laurent RAISON <[laurent.raison@raisonhome.com](mailto:laurent.raison@raisonhome.com)>
|
||||
|
||||
Envoyé : jeudi 4 avril 2024 15:46
|
||||
|
||||
À : Philippe Aulnette <[philippe.aulnette@6tm.com](mailto:philippe.aulnette@6tm.com)>
|
||||
|
||||
Objet : Finance
|
||||
|
||||
Hello,
|
||||
|
||||
J'ai maintenant besoin du coup de main que j'ai sollicité auprès de toi (mais aussi de Xavier, Antoine...).
|
||||
|
||||
Peux-tu effectuer un versement sur 6nergy de 30K€ ASAP ? (RIB joint)
|
||||
|
||||
Je te remercie sincèrement.
|
||||
|
||||
Appelle-moi si besoin
|
||||
|
||||
Laurent
|
||||
4
20-areas/pro/hpa/raisonHome/raisonhome.md
Normal file
4
20-areas/pro/hpa/raisonHome/raisonhome.md
Normal file
|
|
@ -0,0 +1,4 @@
|
|||
# Raison Home
|
||||
|
||||
## Investissement
|
||||
- Actionnariat : Philippe Aulnette - 1,6%
|
||||
|
|
@ -43,6 +43,21 @@ rythme: hebdo
|
|||
## 📖 Sessions
|
||||
|
||||
|
||||
### 2026-05-18
|
||||
- pt Maison du monde :
|
||||
- utilisation des formulaires à partir des visites avec analyse de l'IA =>
|
||||
- échelle européenne ou transakauto
|
||||
=> 1 animation puis IA
|
||||
|
||||
- Sur le bilan support : tu en es où dans ta vision de ce que ça devrait être ?
|
||||
- Bien que Kevin prenne la main -> continnuer dans ce sens là
|
||||
- Ticket plus ou moins long : exemple Midas long sur le traitement
|
||||
|
||||
- Pt IA :
|
||||
- Identifier les 2 uses
|
||||
|
||||
---
|
||||
|
||||
### 2026-05-05
|
||||
- Action sur la finition
|
||||
- Copil : irritants client : Risque Vente, Risque Client
|
||||
|
|
|
|||
|
|
@ -42,6 +42,31 @@ rythme: hebdo
|
|||
|
||||
## 📖 Sessions
|
||||
|
||||
### 2026-05-18
|
||||
|
||||
*Préparation Ameno*
|
||||
- Impossible de récupérer les rapports d'activité Ameno pour Christophe Aubry depuis cet agent.
|
||||
- Une tentative avec le prénom seul remonte Jean-Christophe Greffier, ce qui indique une ambiguïté côté Ameno.
|
||||
- Une tentative avec le nom complet renvoie un refus d'accès sur Christophe Aubry.
|
||||
|
||||
*Tickets en cours*
|
||||
- Impossible de récupérer les tickets assignés Ameno pour Christophe Aubry depuis cet agent.
|
||||
|
||||
*Points d'attention*
|
||||
- Le stade n'est toujours pas renseigné dans la fiche, ce qui rend la posture de l'entretien moins explicite.
|
||||
- La dernière session exploitable du 2026-04-27 laissait trois fils ouverts : priorité entre Leeloo et Axone, debug bar, et capitalisation sur les vieux projets.
|
||||
- La session du 2026-05-11 liste plusieurs sujets (Kumulus, Axone Elastic, montée de version Leeloo, Julien, Seenaps) sans statut ni arbitrage explicite : risque de dispersion encore présent.
|
||||
- Écart outillage : Ameno ne permet pas ici de confirmer ou contredire les patterns et actions en cours pour Christophe Aubry.
|
||||
|
||||
*Questions à creuser*
|
||||
- Qu'est-ce qui a le plus avancé depuis le dernier 1:1 entre Leeloo, Axone et les sujets transverses ?
|
||||
- Parmi Kumulus, Axone Elastic, montée de version Leeloo et Seenaps, quel est le sujet prioritaire cette semaine, et qu'est-ce que tu mets explicitement de côté ?
|
||||
- Qu'est-ce qui te ralentit le plus en ce moment : arbitrages, dépendances externes ou changement de contexte ?
|
||||
- Où en est la capitalisation sur les vieux projets : docs, tests, ou rien n'a encore réellement démarré ?
|
||||
|
||||
*Notes de session*
|
||||
<!-- vide, à remplir à la main pendant l'échange -->
|
||||
|
||||
### 2026-05-11
|
||||
|
||||
*Préparation Ameno*
|
||||
|
|
|
|||
|
|
@ -39,6 +39,27 @@ rythme: hebdo
|
|||
|
||||
## 📖 Sessions
|
||||
|
||||
### 2026-05-18
|
||||
|
||||
*Préparation Ameno — semaine du 11 au 17 mai 2026*
|
||||
- **Congés/RTT** : 7h — semaine amputée
|
||||
- **Gesteos - Produit** : 5h gestion de projet + 4,5h direction produit → **9,5h** sur Gesteos
|
||||
- **6TM - Pôle AI** : 2h avant-vente ("Visio Burel Group — approche CPQ") + 2h revue de comptes + 1,5h durée hebdo → **5,5h** Pôle AI
|
||||
- **Orion (Cabinet Coudray)** : 2h GP Garantie ("COPIL Orion chez Coudray") — présence onsite
|
||||
- Planification semaine suivante : légère — 2,5h Gesteos + 0,5h Pôle AI + 2h sans projet
|
||||
|
||||
*Points d'attention*
|
||||
- Semaine courte (7h RTT/CP) : qu'a-t-il priorisé vs reporté ?
|
||||
- Avant-vente Burel Group (CPQ) : nouveau signal commercial — à qualifier et suivre.
|
||||
|
||||
*Questions à creuser*
|
||||
- COPIL Orion : qu'est-ce qui a été décidé ? Planning de la garantie, risques identifiés ?
|
||||
=> pb de path Sharepoint, demandes évolutions
|
||||
|
||||
*Notes de session*
|
||||
|
||||
→ Action :
|
||||
|
||||
### 2026-05-11
|
||||
|
||||
*Préparation Ameno — semaine du 04 au 10 mai 2026*
|
||||
|
|
|
|||
|
|
@ -6,6 +6,12 @@ source: OneNote PA-Equipes
|
|||
|
||||
## 2 juillet 2025
|
||||
|
||||
## 2026-05-19
|
||||
- appart ok sur Chartes, 1000€ / mois
|
||||
- Axone : Content qu'on délivre, profil thématique toujours chiant
|
||||
-
|
||||
|
||||
|
||||
## 2026-03-24
|
||||
|
||||
- Axone : vigilance sur le conso / TMA canalisé : 2,3j
|
||||
|
|
|
|||
|
|
@ -37,6 +37,12 @@ rythme: hebdo
|
|||
|
||||
## 📖 Sessions
|
||||
|
||||
### 2026-05-19
|
||||
- Bon points : chouette intégration avec Fabrique de Style, et potentiel des sujets avec l'IA
|
||||
- Biais : soupe de l'IA => PAI et base de connaissances réseau
|
||||
- Mode flex d'open AI : moins de prio = token < à 50 %
|
||||
|
||||
|
||||
### 2026-05-12
|
||||
|
||||
Priorités de la semaine :
|
||||
|
|
@ -52,7 +58,7 @@ Priorités de la semaine :
|
|||
- 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
|
||||
- 1 à 1 PA-VR : 0.5h
|
||||
- Seenaps / Orga : 0.5h — Point Aurélie Manop présentation client
|
||||
|
||||
**Tickets en cours**
|
||||
|
|
|
|||
81
20-areas/pro/management/equipe/christophe-sauve.md
Normal file
81
20-areas/pro/management/equipe/christophe-sauve.md
Normal file
|
|
@ -0,0 +1,81 @@
|
|||
De : Christophe Sauvé <christophe.sauve@6tm.com>
|
||||
|
||||
Date : jeudi, 15 mai 2025 à 15:31
|
||||
|
||||
À : Stéphane Trémier <stephane.tremier@6tm.com>
|
||||
|
||||
Objet : missions v2
|
||||
|
||||
1) Mettre en place l’offre d’hébergement & de sécurité de la tribu Symfony
|
||||
|
||||
--------------------------------------------------------------------------
|
||||
|
||||
Résultats attendus:
|
||||
|
||||
- L'entièreté des hébergements de la tribu sont recencés (hébergeur, caractéristiques, cout)
|
||||
|
||||
- Offre commerciale hébergement clarifiée: service (modèle DAT) et couts associés
|
||||
|
||||
- Un environnement de recette Kubernetes et/ou Docker est accessible pour la tribu
|
||||
|
||||
- Les couts de cet environnement de recette sont mesurés
|
||||
|
||||
- La tribu est autonome pour déployer une nouvelle application en recette
|
||||
|
||||
- Toutes les applications de la tribu ont été mises à niveau par rapport aux failles de sécurité critiques/importantes identifiées
|
||||
|
||||
- Une démarche d'amélioration continue en sécurité a été mise en place
|
||||
|
||||
Moyens à disposition:
|
||||
|
||||
- Accès admin OVH & Amen
|
||||
|
||||
- Budgets maintenance de fransat et de geflog
|
||||
|
||||
- Equipe Cousteau (dont un profil sécurité et un stagiaire devops)
|
||||
|
||||
- DSI
|
||||
|
||||
2) Développer les compétences de la tribu dans la mise en place de solutions exploitant les LLM
|
||||
|
||||
-----------------------------------------------------------------------------------------------
|
||||
|
||||
Résultats attendus:
|
||||
|
||||
- une application RAG fonctionnelle a été déployée chez un client (recette ou prod)
|
||||
|
||||
- un REX a été organisé auprès de la tribu
|
||||
|
||||
- un référent dans la tribu est capable de conseiller une application RAG : spécifications & chiffrage
|
||||
|
||||
- la tribu est capable de produire une application RAG : maitrise d'ouvrage + au moins 2 développeurs ont une expérience en dev RAG
|
||||
|
||||
Moyens à disposition:
|
||||
|
||||
- Accès aux apis LLM propriétaires ou ovh
|
||||
|
||||
- Equipe Cousteau
|
||||
|
||||
- Consultants Polaria
|
||||
|
||||
3) Mise en place de projets Seenaps business
|
||||
|
||||
--------------------------------------------
|
||||
|
||||
Résultats attendus:
|
||||
|
||||
- Au moins 1 projet client communique avec Seenaps platform: SSO + API
|
||||
|
||||
- Un des modules déployé via seenaps platform est maintenu par la tribu (exemple: e-learning)
|
||||
|
||||
- Un REX a été effectué à l'équipe commerciale et/ou au comex
|
||||
|
||||
- Un schéma/doc d'architecture technique est disponible
|
||||
|
||||
Moyens à disposition:
|
||||
|
||||
- Comex Seenaps, comex tribu
|
||||
|
||||
- budgets et equipes projets JAS, Mdm, Transakauto
|
||||
|
||||
- Equipe Seenaps platform
|
||||
|
|
@ -54,3 +54,6 @@ Quelques axes à pousser/accélérer selon moi :
|
|||
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 ! 😉
|
||||
|
||||
Notes liées
|
||||
[[cerca]]
|
||||
|
|
@ -11,7 +11,7 @@
|
|||
### Avant apport (jusqu'au 16/12/2025)
|
||||
|
||||
| Associé | Actions | % | Valeur (131,78 €/action) |
|
||||
|---|---:|---:|---:|
|
||||
| ---------------- | ---------: | --------: | -----------------------: |
|
||||
| Olivier Bajaluna | 14 569 | 63,99 % | 1 920 K€ |
|
||||
| Grégory Clément | 3 139 | 13,79 % | 414 K€ |
|
||||
| Mathieu Bajaluna | 2 277 | 10,00 % | 300 K€ |
|
||||
|
|
@ -153,3 +153,6 @@ Multiple revenus 1,5x → 2,0 M€
|
|||
- Liste enseignes clientes pour cartographier recouvrement vs Seenaps
|
||||
- Identifier Proximo SAS (associé à 1,21 %) et Louis Chevalier (1,00 %)
|
||||
- Comparaison fonctionnelle module à module
|
||||
|
||||
Notes liées
|
||||
[[cerca]]
|
||||
113
30-resources/produit/adr-nouveau-format-specs.md
Normal file
113
30-resources/produit/adr-nouveau-format-specs.md
Normal file
|
|
@ -0,0 +1,113 @@
|
|||
# ADR : Révision du format Epic/Feature/Ticket
|
||||
|
||||
## Contexte
|
||||
|
||||
À l’ère des agents IA, les spécifications produit doivent être :
|
||||
- **Lisibles par les humains et les agents** : pas d’ambiguïté qui bloque un assistant IA
|
||||
- **Traçables** : lier épics → features → tickets sans effort
|
||||
- **Testables automatiquement** : critères d’acceptation mesurables
|
||||
- **Flexibles** : pas de rigidité bureaucratique, juste assez de structure
|
||||
|
||||
Les anciens format spécifications Word, tickets non structurées rendaient les specs difficilement utilisable pour l’automatisation.
|
||||
|
||||
## Décision
|
||||
|
||||
Réorganiser les 3 niveaux de spécification :
|
||||
|
||||
### Epic
|
||||
**Résultat observable de haut niveau** : "Fiabiliser le traitement mensuel des redevances"
|
||||
|
||||
À compléter :
|
||||
- **Résultat attendu** : le résultat mesurable
|
||||
- **Population cible** : pour qui ?
|
||||
- **Problème concret** : quel pain point résout-on ?
|
||||
- **Mesures de succès** : comment vérifie-t-on ? (ex: "X réduction d’erreurs", "Y % de couverture")
|
||||
- **Périmetre** : inclus / hors périmetre
|
||||
- **Dépendances** : autres épics, équipes, systèmes externes impliqués
|
||||
- **Features rattachées** : quelles fonctionnalités décomposent cette epic ?
|
||||
- **Risques & questions ouvertes**
|
||||
|
||||
### Feature
|
||||
**Capacité produit concrète** qui contribue à une epic
|
||||
|
||||
À compléter :
|
||||
- **Objectif** : quelle capacité on livre et pourquoi
|
||||
- **Utilisateurs concernés** : qui bénéficie ?
|
||||
- **Périmetre** : inclus / hors périmetre **explicitement** (important pour les agents : dire ce qu’on NE fait PAS)
|
||||
- **Règles métier** : les logiques métier essentielles
|
||||
- **Tickets associés** : décomposition en unité atomique de travail pourvant être suivi
|
||||
|
||||
### Ticket
|
||||
**Unité atomique de travail** pour le suivi :
|
||||
|
||||
À compléter :
|
||||
- **Contexte & objectif** : qu’est-ce qu’on livre ?
|
||||
- **Valeur/raison** : pourquoi maintenant ?
|
||||
- **Périmetre** : inclus / exclus
|
||||
- **Scénarios couverts** : cas d’usage testables
|
||||
- **Plan d’implémentation** : étapes concrètes
|
||||
- **Critères d’acceptation** : "condition → résultat attendu" (ex: "Si input X → output Y")
|
||||
|
||||
## Pourquoi pas de User Story ?
|
||||
|
||||
Le format **User Story** est historiquement utilisé dans les démarches Agile pour exprimer un besoin utilisateur de manière simple.
|
||||
|
||||
Sa formulation classique est généralement la suivante :
|
||||
|
||||
> En tant que **[utilisateur]**, je veux **[action / besoin]**, afin de **[bénéfice attendu]**.
|
||||
|
||||
Ce format a longtemps été utile pour faciliter la discussion entre les équipes métier, produit et développement.
|
||||
|
||||
Cependant, dans un contexte où une partie croissante du travail est assistée par des **agents de codage IA**, ce format montre ses limites.
|
||||
1. Un format trop narratif
|
||||
La User Story permet d’exprimer une intention, mais elle reste souvent trop narrative.
|
||||
|
||||
Elle décrit généralement :
|
||||
|
||||
- qui est l’utilisateur ;
|
||||
- ce qu’il souhaite faire ;
|
||||
- pourquoi il veut le faire.
|
||||
|
||||
Mais elle ne donne pas toujours suffisamment d’éléments exploitables pour passer à l’implémentation.
|
||||
|
||||
Un agent de codage a besoin d’un contexte plus structuré que la simple intention utilisateur.
|
||||
|
||||
2. Un manque de contraintes opérationnelles
|
||||
|
||||
Pour produire un travail pertinent, un agent IA doit comprendre :
|
||||
|
||||
- le périmètre exact de la demande ;
|
||||
- les règles métier ;
|
||||
- les cas limites ;
|
||||
- les dépendances techniques ;
|
||||
- les impacts sur l’existant ;
|
||||
- les critères de validation ;
|
||||
- les tests attendus.
|
||||
|
||||
Or, ces éléments sont rarement portés naturellement par une User Story classique.
|
||||
|
||||
Le risque est donc de produire une formulation lisible pour un humain, mais insuffisante pour une IA chargée de proposer un plan d’implémentation ou de générer du code.
|
||||
|
||||
|
||||
**Décision** : garder Epic → Feature → Ticket. User Story disparaît au profit d’une Feature plus structurée.
|
||||
|
||||
## Pourquoi c’est important pour l’IA
|
||||
|
||||
1. **Les agents IA lisent mal l’implicite** : une section vague = pas utilisable
|
||||
- Exemple : "points d’attention" → trop vague pour un assistant
|
||||
- Solution : nommer explicitement "règles métier", "hors périmetre", etc.
|
||||
|
||||
2. **Traçabilité du graphe de features** : un agent doit pouvoir vérifier qu’une epic est complète
|
||||
- Les liens epic → feature → ticket doivent être explicites
|
||||
|
||||
3. **Critères testables** : un bot d’automatisation a besoin de savoir exactement quand un ticket est OK
|
||||
- "Condition X → résultat Y" est testable
|
||||
- "Coder proprement" ne l’est pas
|
||||
|
||||
4. **Flexibilité humaine** : les agents n’imposent pas de structure rigide, juste assez pour l’automatisation
|
||||
|
||||
## Impact
|
||||
|
||||
- Spécifications plus claires pour les humains
|
||||
- Agents IA peuvent aider à : valider la complétude, extraire les règles métier, vérifier les critères d’acceptation
|
||||
- Pas de bureaucratie supplémentaire : sections optionnelles remplies selon le besoin
|
||||
127
40-playbooks/assistant-po-specifications.md
Normal file
127
40-playbooks/assistant-po-specifications.md
Normal file
|
|
@ -0,0 +1,127 @@
|
|||
---
|
||||
type: playbook
|
||||
role: Seenaps
|
||||
agent: assistant-po
|
||||
statut: actif
|
||||
---
|
||||
|
||||
# Assistant PO - Specifications
|
||||
|
||||
## Mission
|
||||
|
||||
`assistant-po` aide à cadrer, challenger et rédiger des spécifications produit pour Seenaps.
|
||||
Il force la clarification, explicite les hypothèses, détecte les angles morts et produit une spécification exploitable.
|
||||
À terme, il synchronise les tickets PKM avec Ameno (création, statut, mise à jour du tableau).
|
||||
|
||||
## Niveaux de spécification
|
||||
|
||||
- **Epic** : résultat observable, population cible, mesures de succès → contient N features
|
||||
- **Feature** : capacité produit concrète, règles métier → contient N tickets
|
||||
- **Ticket** : unité atomique de travail (plan d'implémentation + critères d'acceptation)
|
||||
|
||||
Cf. [ADR : adr-nouveau-format-specs.md](../30-resources/produit/adr-nouveau-format-specs.md)
|
||||
|
||||
## Source de vérité
|
||||
|
||||
- **Avant création du ticket Ameno** : le PKM (Feature markdown) est la source de vérité
|
||||
- **Après création du ticket Ameno** : Ameno devient la source de vérité (statut, commentaires, assignation)
|
||||
- Le tableau de la Feature reflète l'état Ameno (sync descendante)
|
||||
|
||||
## Workflow
|
||||
|
||||
### Étape 1 — Classifier
|
||||
|
||||
**Première question à trancher : Epic, Feature ou Ticket ?**
|
||||
|
||||
| Niveau | Critères |
|
||||
|---|---|
|
||||
| **Epic** | Résultat business, plusieurs features, plusieurs quadrimestres possibles, transverse à plusieurs rôles |
|
||||
| **Feature** | Capacité produit unique, décomposable en plusieurs tickets, livrable d'un seul tenant |
|
||||
| **Ticket** | Unité atomique de travail, **max 7h de dev**, faisable par une personne |
|
||||
|
||||
**Si la demande ressemble à un Ticket → évaluer la complexité :**
|
||||
- < 7h : OK, c'est bien un ticket
|
||||
- 7h à 3 jours : c'est une Feature à décomposer
|
||||
- > 3 jours : c'est probablement une Epic
|
||||
|
||||
Si l'utilisateur insiste sur "c'est un ticket" mais la complexité dépasse 7h : **challenger** et proposer le découpage.
|
||||
|
||||
### Étape 2 — Clarifier
|
||||
|
||||
Identifier selon le niveau retenu :
|
||||
- objectif/résultat observable (Epic) ou capacité produit (Feature) ou objectif technique (Ticket)
|
||||
- population cible / utilisateurs concernés
|
||||
- problème concret à résoudre
|
||||
- contraintes et dépendances
|
||||
- périmètre inclus / **hors périmètre explicite**
|
||||
|
||||
Si élément bloquant : poser 3 questions max.
|
||||
|
||||
### Étape 3 — Challenger
|
||||
|
||||
Vérifier systématiquement :
|
||||
- valeur réelle pour l'utilisateur
|
||||
- lien avec OKRs/stratégie Seenaps
|
||||
- complexité cachée ou dépendances manquées
|
||||
- impacts (support, sécurité, données, droits)
|
||||
- risques de mauvaise interprétation
|
||||
- **Ticket : la charge dépasse-t-elle 7h ?**
|
||||
|
||||
Signaler incohérences et angles morts.
|
||||
|
||||
### Étape 4 — Structurer
|
||||
|
||||
**Pour une Epic** → utiliser `99-templates/assistant-po/epic.md`
|
||||
- Résultat attendu, Population cible, Problème, Mesures de succès
|
||||
- Périmètre inclus / exclus, Dépendances, Features rattachées
|
||||
|
||||
**Pour une Feature** → utiliser `99-templates/assistant-po/feature.md`
|
||||
- Objectif, Utilisateurs concernés
|
||||
- Périmètre inclus / hors périmètre, Règles métier
|
||||
- Tableau de tickets (avec statut, ID Ameno quand créé)
|
||||
|
||||
**Pour un Ticket** → utiliser `99-templates/assistant-po/ticket.md`
|
||||
- Contexte & objectif, Valeur/raison, Périmètre
|
||||
- Scénarios couverts, Plan d'implémentation
|
||||
- Critères d'acceptation (format : "Condition → résultat attendu")
|
||||
- **Estimation < 7h**
|
||||
|
||||
### Étape 5 — Synchroniser avec Ameno *(en cours d'implémentation)*
|
||||
|
||||
#### Cas 1 : Ticket pas encore créé dans Ameno
|
||||
1. Vérifier que `Plan d'implémentation` + `Critères d'acceptation` sont remplis dans la Feature
|
||||
2. Créer le ticket dans Ameno via MCP
|
||||
3. Mettre à jour le tableau de la Feature avec l'ID Ameno et le statut
|
||||
|
||||
#### Cas 2 : Ticket existe dans Ameno
|
||||
1. Récupérer le statut et les commentaires depuis Ameno (source de vérité)
|
||||
2. Synchroniser le tableau de la Feature
|
||||
3. Si écart entre le plan d'impl PKM et l'état Ameno → signaler
|
||||
|
||||
#### Tableau des tickets dans la Feature
|
||||
|
||||
```markdown
|
||||
| Ticket | Libellé | Statut | ID Ameno |
|
||||
|---|---|---|---|
|
||||
| A-001 | ... | En revue | ameno-id-xyz |
|
||||
```
|
||||
|
||||
Statuts : "À cadrer", "Prêt", "Créé", "En cours", "En revue", "À valider métier", "Terminé"
|
||||
|
||||
## Critères de succès de l'agent
|
||||
|
||||
Évaluer à 1 mois et 3 mois après usage réel :
|
||||
- **Opérationnel** : nb de Features passées en dev sans retour cadrage, % tickets acceptés sans modif majeure
|
||||
- **Qualitatif** : feedback dev sur clarté des specs, réduction des questions pendant le dev
|
||||
- **Signal d'échec** : l'agent est contourné (tickets écrits directement dans Ameno)
|
||||
|
||||
## Definition of Ready
|
||||
|
||||
Une spec est prête si :
|
||||
- utilisateur cible identifié
|
||||
- problème formé sans solution imposée
|
||||
- périmètre explicite (inclus ET exclus)
|
||||
- règles métier précises
|
||||
- critères d'acceptation testables
|
||||
- questions ouvertes isolées (pas bloquantes)
|
||||
|
||||
72
99-templates/assistant-po/epic.md
Normal file
72
99-templates/assistant-po/epic.md
Normal file
|
|
@ -0,0 +1,72 @@
|
|||
---
|
||||
type: epic
|
||||
statut: brouillon
|
||||
---
|
||||
|
||||
# Epic - {{titre}}
|
||||
|
||||
## Résultat attendu
|
||||
|
||||
Quel resultat observable veut-on obtenir ?
|
||||
|
||||
|
||||
## Population cible
|
||||
|
||||
Pour qui veut-on obtenir ce resultat ?
|
||||
|
||||
|
||||
## Probleme
|
||||
|
||||
Quel probleme concret cherche-t-on a resoudre ?
|
||||
|
||||
|
||||
## Mesures de succes
|
||||
|
||||
-
|
||||
-
|
||||
-
|
||||
|
||||
## Perimetre inclus
|
||||
|
||||
-
|
||||
-
|
||||
-
|
||||
|
||||
## Hors perimetre
|
||||
|
||||
-
|
||||
-
|
||||
-
|
||||
|
||||
## Feature Specs rattachees
|
||||
|
||||
-
|
||||
-
|
||||
-
|
||||
|
||||
## Dépendances
|
||||
|
||||
-
|
||||
-
|
||||
-
|
||||
|
||||
## Risques et angles morts
|
||||
|
||||
-
|
||||
-
|
||||
-
|
||||
|
||||
## Questions ouvertes
|
||||
|
||||
-
|
||||
-
|
||||
-
|
||||
|
||||
## Criteres de validation de l'Epic
|
||||
|
||||
- Le resultat attendu est observable.
|
||||
- La population cible est explicite.
|
||||
- Les mesures de succes sont verifiables.
|
||||
- Le perimetre inclus et le hors perimetre sont clairs.
|
||||
- Les Feature Specs rattachees sont identifiees.
|
||||
|
||||
47
99-templates/assistant-po/feature.md
Normal file
47
99-templates/assistant-po/feature.md
Normal file
|
|
@ -0,0 +1,47 @@
|
|||
---
|
||||
type: fonctionnalite
|
||||
statut: brouillon
|
||||
epic:
|
||||
---
|
||||
|
||||
# Fonctionnalite - {{titre}}
|
||||
|
||||
|
||||
## Objectif
|
||||
|
||||
Quelle capacite produit veut-on livrer, et pourquoi ?
|
||||
|
||||
|
||||
## Utilisateurs concernes
|
||||
|
||||
-
|
||||
|
||||
## Perimetre inclus
|
||||
|
||||
-
|
||||
|
||||
## Hors perimetre (explicitement non-couvert)
|
||||
|
||||
-
|
||||
|
||||
## Règles métier et points d'attention
|
||||
|
||||
-
|
||||
|
||||
## Tickets
|
||||
|
||||
| Ticket | Libellé | Statut |
|
||||
|---|---|---|
|
||||
| A-001 | | A créer |
|
||||
| A-002 | | A créer |
|
||||
| A-003 | | A créer |
|
||||
|
||||
|
||||
|
||||
## Validation de la fonctionnalite
|
||||
|
||||
-
|
||||
|
||||
## Questions ouvertes
|
||||
|
||||
-
|
||||
52
99-templates/assistant-po/ticket.md
Normal file
52
99-templates/assistant-po/ticket.md
Normal file
|
|
@ -0,0 +1,52 @@
|
|||
---
|
||||
type: ticket
|
||||
statut: a_cadrer
|
||||
fonctionnalite:
|
||||
estimation_h:
|
||||
ameno_id:
|
||||
---
|
||||
|
||||
# Ticket - {{titre}}
|
||||
|
||||
> ⚠️ Estimation max : **7h**. Au-delà, redécouper en plusieurs tickets ou requalifier en Feature.
|
||||
|
||||
## Contexte et Objectif
|
||||
|
||||
Que doit-on livrer avec ce ticket ?
|
||||
|
||||
|
||||
## Valeur / raison
|
||||
|
||||
Pourquoi ce ticket est-il utile maintenant ?
|
||||
|
||||
|
||||
## Perimetre
|
||||
|
||||
Inclus :
|
||||
-
|
||||
|
||||
Exclus :
|
||||
-
|
||||
|
||||
## Scenarios ou cas couverts
|
||||
|
||||
-
|
||||
-
|
||||
|
||||
## Regles et points d'attention
|
||||
|
||||
-
|
||||
-
|
||||
|
||||
|
||||
## Plan d'implementation
|
||||
|
||||
- [ ]
|
||||
- [ ]
|
||||
- [ ]
|
||||
|
||||
|
||||
## Critères d'acceptation
|
||||
|
||||
- [ ] Condition 1 → résultat attendu
|
||||
- [ ] Condition 2 → résultat attendu
|
||||
18
AGENTS.md
18
AGENTS.md
|
|
@ -44,17 +44,31 @@ Ce PKM repose sur trois piliers complémentaires :
|
|||
- `99-templates/revue-hebdo.md` — revue du dimanche soir (3 phases, 20 min)
|
||||
- `99-templates/projet.md` — fiche projet avec frontmatter statut/rôle/OKR
|
||||
- `99-templates/okr.md` — OKR trimestriel ou annuel
|
||||
- `99-templates/assistant-po/epic.md` — Epic (résultat observable, population cible, mesures de succès)
|
||||
- `99-templates/assistant-po/feature.md` — Feature (capacité produit, règles métier, tickets)
|
||||
- `99-templates/assistant-po/ticket.md` — Ticket (plan d'implémentation, critères d'acceptation)
|
||||
|
||||
## 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
|
||||
- `/assistant-po` — aide à cadrer, challenger et rédiger des spécifications produit (Epic/Feature/Ticket)
|
||||
- À terme : créer tickets dans Ameno, synchroniser statuts, mettre à jour tableaux
|
||||
|
||||
## Préférences de collaboration
|
||||
|
||||
### Communication
|
||||
- Réponses en français, concises et directes
|
||||
|
||||
### Processus
|
||||
- Proposer avant d'agir sur des changements de structure
|
||||
- Le coaching pose des questions, ne donne pas de réponses
|
||||
- Revue hebdo = 3 phases max, 20 min — ne pas surcharger
|
||||
|
||||
### Coaching
|
||||
- Le coaching ne propose pas de solutions, ne valide pas les choix, et ne formule pas de recommandations — il aide l'utilisateur à explorer sa propre réflexion par des questions ouvertes
|
||||
|
||||
### Revue hebdomadaire
|
||||
- 3 phases max, 20 min — ne pas surcharger
|
||||
|
||||
### Posture critique
|
||||
- Être critique et challenger les idées — ne pas valider systématiquement, signaler les incohérences, les angles morts et les mauvaises décisions
|
||||
|
|
|
|||
|
|
@ -52,6 +52,7 @@ Ce PKM repose sur trois piliers complémentaires :
|
|||
- `/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
|
||||
- `/assistant-po` — aide à cadrer, challenger et rédiger des spécifications produit avec `40-playbooks/assistant-po-specifications.md`
|
||||
|
||||
## Préférences de collaboration
|
||||
|
||||
|
|
|
|||
BIN
Pasted image 20260515124623.png
Normal file
BIN
Pasted image 20260515124623.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 234 KiB |
BIN
Pasted image 20260515124743.png
Normal file
BIN
Pasted image 20260515124743.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 311 KiB |
Loading…
Add table
Reference in a new issue