Dépiler le backlog
front, et installer la méthode

Ce que j'ai compris

Le sujet n'est plus
d'y aller. C'est de tenir
les délais en y allant.

Tu écrivais le 1er septembre vouloir « voir comment Mickael pourrait nous aider dans le projet actuel d'avancer vers l'agentic coding ». L'échange avec Nicolas a montré que la décision, elle, est déjà prise, et bien mieux préparée que la plupart des entreprises qui s'y mettent.

Le compte Claude Team est ouvert, la charte d'usage est prête à signer, et l'intégration maison en webhooks arrive. Ce qui manque n'est donc ni l'outil, ni la conviction.

Ce qui manque, c'est de la capacité, tout de suite, sur un front Angular où les tickets clients et les retours de bêta s'empilent pendant que l'équipe est incomplète. Et une manière commune de travailler, dans une équipe dont les niveaux vont de ceux qui n'ont jamais ouvert Claude à ceux qui l'utilisent déjà chez eux, avec des habitudes qui n'ont jamais été confrontées à celles des autres.

Ces deux besoins se traitent bien mieux ensemble que séparément. Une formation théorique se démode en trois semaines. Une méthode apprise sur les vrais tickets, elle, reste.

La façon de travailler

Un ticket bien écrit
vaut mieux qu'un bon prompt.

Ce que j'apporte n'est pas Claude Code, vous l'avez déjà. C'est la chaîne qui va autour, et qui fait la différence entre un agent qui produit du code jetable et un agent qui livre du code que vous acceptez de merger.

Concrètement : un cadrage de l'intention avant d'écrire quoi que ce soit, une spécification qui sort de cette discussion, un ticket durci selon un gabarit qui dit ce qui est dans le périmètre et surtout ce qui n'y est pas, une implémentation isolée sur son propre worktree, une merge request, une première revue par l'agent, puis vos revues humaines et votre CI. Aucun merge tant qu'une porte est rouge.

Ce qui a été décidé pendant la construction d'une fonctionnalité est réécrit dans le dépôt au fur et à mesure, pas laissé dans l'historique d'une conversation. C'est ce qui fait qu'au bout de quelques semaines l'agent redemande de moins en moins de contexte, et que le développeur suivant en profite sans avoir participé.

J'ai construit et fait tourner cette chaîne sur mon propre produit, jusqu'à la migration complète d'une application en production. Elle a été mise au point sur des issues Linear ; elle se transpose sur vos issues GitLab sans changer un seul principe.

Périmètre

Ce sur quoi
j'interviens.

• 01Traitement des tickets de bugs remontés des bêta-tests
• 02Développement des demandes clients en attente sur le front
• 03Durcissement des issues avant implémentation, sur votre gabarit
• 04Travail en binôme avec les développeurs de l'îlot front
• 05Conventions d'agent versionnées dans les dépôts concernés
• 06Point de transfert écrit à la fin de la période d'amorçage

Ce qui reste hors de mon périmètre, pour que ce soit dit avant et pas après : les décisions d'architecture du produit, qui restent chez vous ; l'administration de votre Kubernetes et de vos environnements ; la seconde revue humaine avant merge, qui reste la vôtre et qui est précisément ce qui rend le dispositif sûr ; et Picobot, déjà couvert en interne.

Je ne forfaitise pas un backlog que je n'ai pas lu. Personne ne peut chiffrer au forfait des tickets dont ni vous ni moi ne connaissons le fond aujourd'hui. La régie est ici la formule honnête, et le cadrage ci-dessous est ce qui la borne.

Aperçu

À quoi ressemble
un ticket prêt pour l'agent.

La différence tient rarement au modèle utilisé. Elle tient à ce qui est écrit dans le ticket avant que l'agent ne commence.

Illustration de la méthode, pas un ticket de votre backlog. Le gabarit sera adapté à vos issues GitLab pendant la première semaine.

Déroulé

Quatre semaines
d'amorçage, puis
un rythme de croisière.

Le pic de charge est maintenant, pas dans deux mois. La mission épouse cette courbe au lieu de l'ignorer.

1. 01 Mise en routePoste fourni, accès VPN, dépôts et CI. Premiers tickets choisis à faible risque, pour valider la chaîne avant de l'appliquer à des sujets sensibles. Semaine 1
2. 02 Dépilage à pleine chargeTrois jours par semaine sur les bugs et les demandes clients, dont deux au bureau avec l'équipe. Le gabarit de ticket durci se construit sur vos vrais sujets, pas sur des exemples. Semaines 2 à 4
3. 03 Point d'étapeCe qui a été livré, ce que la chaîne a réellement changé, et le rythme retenu pour la suite. Décision commune, sans reconduction automatique. Fin de semaine 4
4. 04 Croisière et transfertLe rythme baisse, la part de binôme monte. L'objectif de sortie est que l'îlot front tienne la chaîne sans moi, puis que l'îlot back la reprenne. À partir de la semaine 5

Deux jours sur site, un jour à distance. Les deux jours au bureau sont ceux qui servent à quelque chose que le télétravail ne remplace pas : regarder un écran à deux, reprendre un ticket avec celui qui l'a écrit, corriger une habitude au moment où elle se prend. Ce sont les jours de binôme.

La troisième journée est délibérément la plus calme. Dépiler des tickets avec un agent demande de longues séquences ininterrompues : on cadre, on laisse tourner, on relit, on reprend. C'est le régime dans lequel cette méthode produit le plus. Je la place le mardi, jour où l'équipe des devs est elle-même en télétravail : vous ne perdez donc aucune heure de présence.

Budget

Un tarif unique,
un engagement borné.

Pas de forfait de formation facturé à part : l'accompagnement de l'équipe se fait pendant les jours de développement, il est compris dans le tarif.

L'amorçage est volontairement court et chiffré d'avance. Vous engagez 7 200 € HT, pas une mission ouverte : au bout de quatre semaines vous avez de quoi juger sur pièces, et la suite se décide à ce moment-là.

Avant de démarrer

Cinq points
à confirmer.

Aucun ne demande plus de quelques minutes, mais les deux premiers conditionnent la date de démarrage.

1. 01Le poste de travail et son délai de mise à dispositionMa machine personnelle ne fera pas tourner votre environnement. Nicolas a proposé un poste fourni et préinstallé : il me faut une date, sinon la première journée est perdue en installation.
2. 02Les accès : VPN, dépôts GitLab, CI, et la charte à signerAutant les regrouper le premier matin. La charte, je la signe comme le reste de l'équipe.
3. 03Les jours retenus et les horairesJe propose mercredi et jeudi au bureau, et mardi à distance, ce qui évite votre vendredi écourté. Côté horaires, j'ai une contrainte de garde : j'arrive à 9h, puisque je dépose mon fils à l'école à 8h30, et je repars à 17h15 pour le récupérer à 17h45 à la garderie.
4. 04La validation technique de MaximeLe dispositif ne fonctionne que s'il le veut. Trente minutes avec lui à son retour valent mieux qu'un démarrage décidé sans lui.
5. 05Qui priorise les tickets que je prendsUn interlocuteur unique côté front, et une file identifiée. Sans cela je choisis moi-même, et je choisirai mal.

Qui réalise

Mickael Bourgois

Pendant la mission

Joignable,
vraiment.

Deux jours par semaine, je suis dans la pièce : c'est le meilleur canal et il ne se remplace pas. Le reste du temps, deux façons de me joindre selon l'urgence, y compris le mardi où je suis à distance.