pkm/20-areas/pro/seenaps/2026-05-09 - CR retro IA et organisation projets.md

type	date	role	tags
compte-rendu	2026-05-09	Seenaps	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 ?