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