---
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 -->
