diff --git a/05-revues/coaching/2026-05-30.md b/05-revues/coaching/2026-05-30.md
new file mode 100644
index 0000000..d1c8c83
--- /dev/null
+++ b/05-revues/coaching/2026-05-30.md
@@ -0,0 +1,88 @@
+---
+type: coaching
+date: 2026-05-30
+session: 6
+---
+
+# Session de coaching — 30 mai 2026
+
+---
+
+## Sujet central
+
+Mise en place de la PAI dev comme point de passage du Q2 entre clarification et exécution réelle.
+
+---
+
+## 1. Alignement
+
+**Observation :** Les deux dernières semaines ont combiné deux mouvements : un temps famille significatif et de qualité, et un travail d'affinage des OKRs du second quadrimestre. L'alignement progresse, mais l'avancement OKR reste encore principalement au niveau du cadre : définition et précision des résultats attendus.
+
+**Question :** Qu'est-ce qui prouvera, dans les prochaines semaines, que les OKRs Q2 ne sont plus seulement clarifiés mais réellement mis en mouvement ?
+
+---
+
+## 2. Performance — PAI dev
+
+**Observation :** Le point de réel identifié est la mise en place de la PAI. Le blocage principal n'est pas technique : les façons de travailler sont très différentes selon les individus. L'intention n'est pas d'uniformiser toute l'équipe, mais de poser un standard minimum, appuyé sur les meilleures pratiques existantes.
+
+Antoine est identifié comme référence partielle sur la gestion de projet, même si ce modèle reste perfectible.
+
+Le standard minimum envisagé :
+
+- utilisation systématique de l'IA ;
+- travail explicite sur le contexte ;
+- passage systématique par les agents ;
+- agents mobilisés à chaque étape du processus ;
+- humain en rôle de challenge, d'affinage et de décision.
+
+Les étapes à couvrir dans le standard PAI :
+
+- spécification sous forme d'Epic / Feature / Ticket ;
+- implémentation ;
+- tests ;
+- revue de code.
+
+**Question :** Quelles pratiques actuelles ne seront plus acceptables une fois ce standard minimum posé ?
+
+---
+
+## 3. Pilote Seenaps
+
+**Observation :** Seenaps est retenu comme terrain pilote, car l'équipe est plus grosse et le test sera donc plus représentatif qu'Ameno. Le sujet pilote identifié est le module redevance.
+
+Le critère de succès du pilote n'est pas seulement la livraison du module, mais la preuve que la PAI est réellement intégrée au workflow.
+
+Preuve d'usage retenue :
+
+- les fichiers Markdown Feature sont à jour avec les tickets réalisés ;
+- cette mise à jour est portée par le dev ;
+- l'agent peut aider, mais la responsabilité reste humaine.
+
+**Question :** A quel moment précis du workflow cette mise à jour documentaire devient-elle obligatoire : après chaque ticket, avant chaque PR, avant revue de code, ou avant merge ?
+
+---
+
+## Question centrale
+
+Tu as clarifié le standard PAI, le terrain pilote et une preuve documentaire observable. Le prochain risque n'est plus l'ambiguïté du cadre, mais le fait de laisser cette exigence documentaire rester optionnelle.
+
+**Question :** Quel verrou concret vas-tu poser dans le workflow Seenaps pour que la documentation Feature à jour devienne une condition de progression, et non une tâche de rattrapage ?
+
+---
+
+## Décisions / éléments à retenir
+
+- Le sujet clé Q2 est la mise en place de la PAI dev.
+- Le standard minimum s'appuie sur les meilleures pratiques, sans chercher l'uniformisation complète.
+- L'agent doit intervenir à chaque étape du processus.
+- L'humain garde la responsabilité de challenger, affiner et décider.
+- Le pilote se fait sur Seenaps, module redevance.
+- La preuve d'adoption est la mise à jour des fichiers Markdown Feature avec les tickets réalisés.
+- Le dev est responsable de cette mise à jour.
+
+---
+
+## Ta réflexion
+
+<!-- Espace libre — réponds à ce qui résonne, pas à tout -->