92946d3203
- Created a new tech and AI monitoring report template for weekly updates. - Added an employment and developer trends report template to analyze market conditions. - Updated CLAUDE.md to include new directories for sources and templates. - Introduced a detailed structure for capturing key signals, OKR alignment, and actionable insights.
156 lines
5.4 KiB
Markdown
156 lines
5.4 KiB
Markdown
---
|
|
type: compte-rendu
|
|
date: 2026-05-09
|
|
role: Seenaps
|
|
tags:
|
|
- seenaps
|
|
- ia
|
|
- retro
|
|
- organisation
|
|
---
|
|
|
|
# CR retro - Usage de l'IA et organisation projets
|
|
|
|
## Contexte
|
|
|
|
Retro d'equipe autour de deux sujets :
|
|
|
|
- usage de l'IA dans les pratiques de developpement ;
|
|
- organisation projets, rituels et priorites de delivery Seenaps.
|
|
|
|
## 1. Usage de l'IA
|
|
|
|
### Retours par personne
|
|
|
|
#### Maxence
|
|
|
|
- Utilisation de Tick6.
|
|
- Probleme rencontre sur les images en base64.
|
|
- Usage de `.github/skills` avec demande de reamelioration.
|
|
- Pas encore d'utilisation de sous-agents.
|
|
- Piste : knowledge graph pour simplifier la recherche dans le texte.
|
|
- Modele utilise : Sonnet 4.6.
|
|
|
|
#### Christophe
|
|
|
|
- Approche davantage basee sur les instructions.
|
|
- N'utilise pas Tick6 : projet juge trop ancien et moins adapte.
|
|
- Pas de difference significative constatee entre GitHub Copilot et Copilot selon le contexte actuel.
|
|
|
|
#### Valentin
|
|
|
|
- Retravail du ticket avec l'IA selon une approche plus gestion de projet : specifications plus detaillees.
|
|
- Avantage constate sur l'optimisation de Copilot : une seule source de contexte mieux structuree.
|
|
- Pas d'utilisation de Tick6 : moins pertinent pour les fonctionnalites a construire.
|
|
- Question ouverte : ou doit vivre ce contenu demain dans le projet ? Dans le ticket ? Dans le repo ? Dans une base de contexte partagee ?
|
|
|
|
#### Kevin
|
|
|
|
- Utilisation de Tick6.
|
|
- Completion du ticket avec reformulation en langage humain.
|
|
- Utilisation de skills pour creer le contexte d'un module dans un sous-dossier local.
|
|
- Contexte local par feature, avec description du contexte.
|
|
- Perspective : refactorer progressivement ce contexte en local.
|
|
- Notion de slice : livrable autonome.
|
|
- Limite identifiee : l'IA ne voit pas toujours les surcharges.
|
|
- MCP juge complementaire, exemple cite : Laravel Boost.
|
|
|
|
#### Lionel
|
|
|
|
- Utilisation d'Opus pour les grosses reviews.
|
|
- Meilleure prise en compte de l'ensemble des fichiers lors des revues larges.
|
|
|
|
## Constats
|
|
|
|
- Les usages IA progressent mais restent heterogenes selon les personnes, les outils et les projets.
|
|
- Le contexte devient le sujet central : instructions, tickets, prompts, documentation, historique et contexte local ne sont pas encore formalises de maniere commune.
|
|
- Tick6 est utile pour certains cas, mais moins pertinent sur des projets anciens ou sur des fonctionnalites a construire.
|
|
- Les skills et les instructions semblent etre les leviers les plus actionnables a court terme.
|
|
- Les MCP sont vus comme un complement utile, pas comme le socle principal.
|
|
- Les grosses reviews beneficient de modeles plus puissants, notamment pour absorber un grand nombre de fichiers.
|
|
|
|
## Points de vigilance
|
|
|
|
- Risque de dispersion si chaque personne construit son propre systeme de contexte sans convention commune.
|
|
- Risque de duplication entre ticket, prompt, documentation projet, instructions repo et historique.
|
|
- Risque de croire que l'IA compense un manque de specification : les retours montrent plutot que la qualite du ticket reste determinante.
|
|
- Il manque une regle claire sur ce qui doit etre partage, historise ou garde localement.
|
|
|
|
## Actions - V1 IA
|
|
|
|
- Formaliser un fichier `instruction.md` ou equivalent.
|
|
- Formaliser le fonctionnement des agents.
|
|
- Mettre en place des symlinks vers les instructions quand c'est pertinent.
|
|
- Formaliser les skills utiles et leur structure.
|
|
- Documenter les differentes facons de gerer le contexte :
|
|
- instructions ;
|
|
- ticket ;
|
|
- prompt ;
|
|
- contexte complementaire ;
|
|
- documentation projet ;
|
|
- historique.
|
|
- Definir les docs comme source de verite consolidee.
|
|
- Clarifier les regles de partage :
|
|
- ce qui doit etre partage dans l'equipe ;
|
|
- ce qui peut rester local ;
|
|
- ce qui doit etre historise ;
|
|
- la cible prochaine.
|
|
|
|
## Rituels IA
|
|
|
|
- Mettre en place un point de synchronisation toutes les deux semaines.
|
|
- Prevoir un deuxieme abonnement Claude.
|
|
|
|
## 2. Organisation projets
|
|
|
|
### Valeur et delivery
|
|
|
|
- Recentrer la discussion sur la valeur livree.
|
|
- Exemple cite par Kevin : assistance.
|
|
- Indicateur a suivre : a quelle vitesse delivre-t-on ?
|
|
- Exemple de mesure possible : nombre de tickets en tests.
|
|
- Monter en hauteur dans le pilotage, au-dela du suivi operationnel ticket par ticket.
|
|
|
|
### Demos
|
|
|
|
- Cible : demonstration de 30 minutes maximum.
|
|
- Preparation necessaire en amont.
|
|
- Jeux de tests prets avant la demo.
|
|
- Cible : une seule personne responsable de la demo.
|
|
|
|
### Experimentations
|
|
|
|
- Manop.
|
|
- Support : optimisation de la gestion des tickets.
|
|
|
|
## Priorites / cailloux
|
|
|
|
- MonoBase.
|
|
- CI et migrations.
|
|
- Tests.
|
|
- Suppressions Azure.
|
|
- Permissions / habilitations.
|
|
- UX / UI.
|
|
- En parallele : travail sur les skills.
|
|
|
|
## Gitflow
|
|
|
|
- Validation du gitflow.
|
|
- ADR a mettre a jour par Christophe.
|
|
|
|
## Decisions
|
|
|
|
- Mettre en place un rituel de synchronisation IA toutes les deux semaines.
|
|
- Structurer une V1 des instructions, agents et skills.
|
|
- Traiter la documentation comme source de verite consolidee.
|
|
- Limiter les demos a 30 minutes avec un responsable unique et des jeux de tests prets.
|
|
- Mettre a jour l'ADR gitflow.
|
|
|
|
## Questions ouvertes
|
|
|
|
- Ou doit vivre le contexte enrichi par l'IA : ticket, repo, documentation, ou combinaison explicite des trois ?
|
|
- Quelle frontiere entre contexte local utile a un developpeur et contexte partage obligatoire ?
|
|
- Quel format standard pour une slice livrable ?
|
|
- Quels criteres pour choisir entre Copilot, Claude, Opus, Tick6 et MCP selon le type de tache ?
|
|
- Quel indicateur de delivery retenir en premier : tickets en tests, lead time, cycle time, ou autre ?
|
|
|