Aller au contenu

ADR-035 — Cadrer les évolutions structurantes avec le produit et la tech avant l'implémentation
Statut Accepted
Date 04/08/2026 (S32, première application du nouveau fonctionnement)
Décideurs Romain BAZIL, Jérôme Barthès, Dimitri Hertz
Origine Weekly Analyse du 04/08/2026
Voir aussi ADR-029, ADR-031

Contexte

Les rôles produit, métier et technique sont désormais davantage séparés. Le modèle précédent permettait à une même personne de cadrer, écrire les tickets et implémenter.

La refonte de la classification documentaire a montré la limite de ce modèle : certaines demandes étaient décrites avant confrontation avec le fonctionnement réel du système. Le contexte technique arrivait alors trop tard, avec un risque de reprise pendant l’implémentation.

Décision

Toute évolution structurante est cadrée conjointement par le produit et la tech avant l'écriture finale des tickets et avant l'implémentation.

Le cycle cible est :

  1. qualifier le problème utilisateur et le résultat attendu ;
  2. réunir Jérôme, Dimitri et Romain lorsque le sujet touche plusieurs couches ou engage l'architecture ;
  3. modéliser le flux et confronter les options produit / techniques ;
  4. fixer le périmètre, l'appétit et la définition de fin ;
  5. écrire ou ajuster les tickets ;
  6. implémenter, tester puis mesurer.

Ce cadrage n'est pas obligatoire pour un correctif local dont la cause, la solution et l'impact sont déjà compris. Il s'applique aux nouvelles fonctionnalités importantes, aux évolutions d'agents et aux changements d'architecture ou de flux.

Rationale

  • Éviter le handoff tardif : la technique ne doit pas reconstruire après coup le besoin, les contraintes et les décisions implicites.
  • Détecter les incohérences avant de coder : la confrontation produit / tech révèle plus tôt les demandes incompatibles avec le fonctionnement réel.
  • Améliorer les choix d'architecture : l'expertise technique intervient avant que la solution ne soit figée dans un ticket.
  • Donner un périmètre fini : l'appétit et la définition de fin limitent les chantiers tentaculaires.
  • Construire une vraie squad : la séparation des rôles ne doit pas devenir une chaîne de transmission où chacun intervient uniquement à son étape.

Conséquences

Ce qui change

  1. Une demande importante n’est plus transformée en solution détaillée par un seul rôle avant le cadrage croisé.
  2. Dimitri participe aux ateliers de cadrage qui touchent les agents, la donnée, l'orchestration ou la persistance.
  3. Romain intervient sur le cap, les arbitrages transverses et les interfaces entre services, sans redevenir l'implémenteur par défaut.
  4. Les tickets deviennent la trace d'un alignement, pas le point de départ automatique de la réflexion.
  5. Une évolution structurante peut être mise en pause si le trio n'est pas aligné sur le problème ou l'approche — cas de la convergence au 04/08.

Ce qu'il faut faire

  • Décrire d'abord le problème utilisateur, l'impact attendu et les contraintes connues.
  • Préparer un schéma simple du flux lorsque plusieurs services ou personas sont concernés.
  • Expliciter l'appétit : temps que la squad accepte d'investir avant de réévaluer.
  • Finir chaque cadrage par une définition de fin observable et un owner.
  • Conserver un chemin court pour les correctifs locaux et urgents.

Ce qu'il faut éviter

  • Écrire une solution technique détaillée dans Linear puis demander à Dimitri de l'exécuter sans cadrage.
  • Inviter la tech uniquement lorsque l'implémentation est bloquée.
  • Transformer ce cycle en comité lourd pour chaque petit correctif.
  • Commencer à coder pour « avancer » alors que le trio ne partage pas l'objectif ou l'architecture cible.

Alternatives écartées

  • Produit cadre et écrit les tickets seul, puis handoff à la tech : plus rapide en apparence, mais le coût est déplacé dans la reprise de contexte, les objections tardives et les solutions à refaire.
  • La technique décide seule dès qu’un sujet touche Python : cohérence locale, mais séparation du problème utilisateur et création d’un silo.
  • Conserver le modèle product builder de bout en bout : adapté au 0→1 et à une personne omnisciente, mais incompatible avec la construction d'une squad où les responsabilités et expertises sont distribuées.
  • Imposer un atelier à chaque ticket : écarté comme trop lourd ; les correctifs locaux, bien compris et à faible rayon d'impact gardent un chemin court.

Verbatims

« Faire ça en amont avant même de faire les tickets pour qu'ensemble, on schématise le besoin. Moi, ça me permet de rapidement identifier les problèmes techniques. » — Dimitri Hertz

« Il faut qu'on adopte un vrai cycle produit classique […] et que dès le cadrage, tu sois impliqué, Dimitri. » — Romain BAZIL

« Si tu développes un truc qui sert à rien, on rajoute du process, mais en même temps […] » — Romain BAZIL

« N'hésite vraiment pas à plus m'intégrer sur les parties produits, que je comprenne aussi l'objectif. » — Dimitri Hertz

Voir aussi

Sources