Comment je travaille
Le process d’équipe est réduit au minimum : un daily hybride, une rétrospective toutes les six semaines, le reste en asynchrone (Looms, écrits, canaux dédiés). Le temps de réunion va à la livraison : la roadmap trimestrielle est régulièrement dépassée, et les sujets ajoutés en cours de route sont livrés eux aussi.
Des centaines de sujets passent chaque semaine : bugs, demandes, décisions, incidents. Chaque vendredi, un compte-rendu reconstitue ce que l’équipe a livré, généré par un système que j’ai construit moi-même : des agents Claude Code, un par étape du process produit (cadrage, idéation, spec, ticket, plan de tracking, revue de code), qui compilent nos conversations, nos tickets, notre code et les transcriptions de réunions en un document daté. Un sujet ouvert y revient de semaine en semaine, jusqu’à sa résolution. Les histoires de cette page sortent de là.
Ce qui est livré aux agents est documenté pour les agents : un inventaire des fonctionnalités du back-office, et une FAQ en vidéos courtes, classées par thème (bloquer un compte et tracer le motif, éditer un échange, gérer les coupons).
Les repos du back-office, de l’API et de la couche d’accès sont clonés en local. Avant de rédiger un ticket, je lis le code : chaque règle métier que j’annonce est vérifiée dans le source, et les tickets arrivent aux développeurs déjà cadrés, avec le suivi d’usage et les droits d’accès exigés dès la spécification. Sur les sujets incertains, je code d’abord un prototype branché sur des données réelles : le pré-remplissage d’annonce et la page de recherche ont existé en prototype avant d’être spécifiés.
Je teste chaque ticket livré sur l’environnement de test de sa branche, le ticket et le code ouverts à côté, et je décris les anomalies au timestamp près depuis un enregistrement d’écran. Pour les chiffres, je construis mes requêtes SQL sur les schémas réels des tables, et je ne retiens un résultat que quand deux sources concordent.
Les gains que j’annonce suivent la même discipline. Chaque chiffre porte son statut : mesuré (une sortie d’outil), modélisé (un volume mesuré multiplié par un temps unitaire), ou hypothèse posée pour être contestée. Et le bilan d’impact garde en face les contre-métriques à ne pas dégrader en automatisant, et les contre-exemples : les demandes encore ouvertes y figurent aussi.
Quand un geste revient trop souvent, j’en fais un outil :
- Créer un compte de test complet5 min → 15 s
- Collecter et suivre les retours des 200 agents, reliés aux tickets≈ 50 tickets traités
- Compiler le compte-rendu hebdomadaire10 sources → 1 document
- Prévenir les agents concernés par un changement, depuis les données d’usage1 commande
- Traiter en masse une liste de comptes frauduleuxutilisé pendant la vague de mai
- Chiffrer les gains d’une automatisation avant de la lancer (heures, euros, scénarios)1 page interactive
- Suivre en direct la satisfaction et les demandes des agents, branché sur Slack1 tableau de bord
- Déclencher une pull request automatique depuis un ticket étiqueté « ai-ready »du ticket à la PR
- Mesurer l’adoption des outils IA de l’équipe produit1 dashboard