88 lines
3.5 KiB
Markdown
88 lines
3.5 KiB
Markdown
---
|
|
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 -->
|