Aller au contenu
Akram Moussaoui
CV PDF

Méthode

Comment je travaille avec des agents de code, ce que je leur confie et ce que je garde. Deux pratiques, des garde-fous écrits, et une validation humaine avant tout ce qui part.

Deux pratiques distinctes

Je n'utilise pas les agents de la même façon au travail et sur mes projets perso. Au travail, je garde la main à chaque étape du ticket. Sur mes projets perso, je confie l'exécution à une chaîne d'agents et je garde les décisions.

Au travail : un ticket, un plan, des tests d'abord

Chez Groupe La Centrale, l'agent m'accompagne sur un ticket Jira, du plan à la PR. Le code part des tests, deux modèles le relisent, puis je le relis et je le valide avant de le tester en environnement de dev ou en local.

  1. ticket Jira
  2. plan
  3. TDD
  4. code
  5. simplification
  6. revue Claude
  7. revue Copilot
  8. validation par moi, étape que je fais moi-même
  9. test en dev ou en local
  10. PR

Projets perso : la chaîne agentique

Sur mes projets perso, des agents spécialisés exécutent les tickets dans Multica, un tracker auto-hébergé. J'écris l'idée, je tranche la spec et les ADR, et rien n'est mergé sans une CI verte.

  1. idée, étape que je fais moi-même
  2. grill
  3. spec et ADR, étape que je fais moi-même
  4. design
  5. tickets
  6. agents spécialisés
  7. revue
  8. merge sur CI verte

en bleules étapes que je fais moi-même.

La chaîne, étape par étape

  1. Idée
    Une page qui décrit le besoin, écrite par moi.
  2. Étude de marché

    Faite seulement quand le projet vise d'autres utilisateurs que moi.

  3. Grill

    Un agent m'interroge en plusieurs rounds jusqu'à ce que les zones floues soient tranchées.

  4. Spec et ADR

    La spec et chaque décision difficile à défaire sont écrites avant le code.

  5. Design
    Design system et écrans, validés avant le premier ticket d'interface.
  6. Tickets

    Des tickets indépendants par étape de livraison, avec des critères d'acceptation vérifiables.

  7. Agents spécialisés

    Chaque ticket est confié à un agent spécialisé (back, front, revue, QA) dans Multica.

  8. Revue

    Un autre agent relit la PR, et les corrections repartent au développeur.

  9. Merge sur CI verte
    Une PR fusionne seulement si la revue, la QA et la CI sont au vert.

Garde-fous

Un agent de code va vite, y compris dans la mauvaise direction. Ces garde-fous sont écrits, et automatisés quand c'est possible, pour qu'aucun changement ne passe sur la seule parole d'un modèle.

  • Hooks pre-commit : build, types, tests, lint et CDK synth bloquent le code non conforme avant le commit.
  • Revue par deux modèles : Claude puis Copilot relisent chaque changement avant moi.
  • Validation humaine : aucune PR ne part sans que je l'aie relue et validée.
  • Agents de revue sans droit d'écriture git : seul l'orchestrateur publie, après ma validation.
  • Analyse d'impact : avant la synthèse d'une revue, l'agent mesure ce que le changement touche.

Ce que je décide, ce que les agents écrivent

La frontière tient en une règle : les agents écrivent, je décide de ce qui part.

Je décide

  • le besoin et le périmètre
  • les décisions d'architecture, écrites en ADR
  • ce qui est fusionné ou publié
  • les chiffres affichés, toujours sourcés

Les agents écrivent

  • le code et les tests, à partir des tickets
  • les premières versions des docs
  • les revues de PR, que je relis

Limites rencontrées

  • Un agent ne doit pas combler un manque d'information. Quand une donnée me revient, le ticket attend ma réponse plutôt qu'une estimation.
  • Une revue d'agent signale, elle ne corrige pas : un cas limite relevé dans la PR d'un collègue lui revient.
  • Le skill de revue n'est jamais fini. Je l'ajuste après chaque revue, à partir de ce qu'il a manqué.

Les projets livrés ainsi

Tous les projets