Méthode
Une équipe d’agents,un seul interlocuteur.
J’orchestre plusieurs agents en parallèle avec Claude Code, CMUX et d’autres outils IA, le tout piloté par un système que j’ai construit et rendu public : il audite le projet en continu, note l’avancement, liste ce qui bloque, et m’indique la prochaine action à mener. Vous gardez un interlocuteur unique ; moi, une équipe.
- Agents
- En parallèle
- Modèle
- Opus
- Mémoire
- Persistante
- Livraison
- Sous preuve
Un cadre qui sait ce qui manque à votre produit.
Au cœur de ma méthode, il y a un cadre que j’ai construit et qui veille sur chaque projet. À tout moment, il en connaît l’état réel : ce qui tient déjà, ce qui manque encore, et la prochaine chose à régler.
Ce cadre connaît les exigences d’un produit sérieux, celles qu’une grande équipe tech prendrait en compte et qu’on oublie quand on va vite : sécurité, fiabilité, performance, conformité, protection de vos données. Il y pense à ma place et traduit chaque étape en langage clair. Votre projet avance dans le bon ordre, sans angle mort.
Et je ne me contente pas de l’utiliser : je le construis et l’affine depuis six mois, et je l’ai rendu public. Il s’appelle ORCA, son code est ouvert sur GitHub, et vous pouvez l’inspecter de bout en bout. Rien de ce que je décris ici n’est une promesse en l’air, c’est du code que vous pouvez lire.
Audit
Il scanne l’état réel du projet, ce qui existe vraiment, pas ce qu’on croit avoir fait.
Verdict
Une note d’avancement, et la liste des points qui bloquent encore.
Cap
Une seule action, la plus utile, expliquée simplement pour décider vite.
ORCA, c’est l’architecte permanent que j’ai construit pour mes projets, le même qui veille sur le vôtre. Voici, dans les grandes lignes, ce qu’il sait faire :
Scanne le projet en quelques secondes, note l’avancement sur 10, isole les trois points qui bloquent vraiment, et propose une seule action à valider.
La porte de livraison : QA, tests de bout en bout et preuves réelles avant tout « c’est livré », pour un verdict net, on livre ou on ne livre pas.
Le board produit : les fonctionnalités à plus fort levier d’abord, et un verdict franc sur la vraie question, « est-ce que c’est fini ».
- Licence
- Open source (MIT)
- Code
- TypeScript · Bun
- Dépendances
- Zéro
- Audit
- 18 critères pondérés
Règle de preuve
Trois preuves indirectes ne valent pas une preuve directe. La même exigence que je m’impose, écrite noir sur blanc dans le code.
Périmètre tenu
Chaque agent ne peut écrire que dans sa zone de travail, sans jamais déborder sur le reste de votre projet.
Main à l’humain
Dès que données privées, contenu non vérifié et action vers l’extérieur se croisent, le système s’arrête et me redonne la décision.
Plusieurs agents avancent en même temps.
Je ne confie pas tout à une seule IA. Je découpe le travail et je le répartis entre des agents spécialisés qui tournent en parallèle, chacun sur sa partie, tous sur Opus, le modèle le plus puissant du moment. Pendant que l’un cherche, un autre conçoit, un troisième écrit et un quatrième vérifie.
CMUX me sert de poste de pilotage : il fait tourner ces sessions Claude Code côte à côte, isolées les unes des autres, et je garde la main à chaque relais. Là où un prestataire seul traite les tâches en file, j’avance sur plusieurs fronts à la fois, plus vite, sans perdre le fil.
Recherche
Explore le besoin, le terrain et l’existant.
Conception
Pose l’architecture et le plan d’attaque.
Exécution
Écrit le code et construit l’interface.
Vérification
Teste en conditions réelles, écran après écran.
Le système s’améliore à chaque session.
Mon environnement n’attend pas qu’on lui signale un problème. En continu, des agents restent en veille et traquent ce qui pourrait être mieux, dans le produit comme dans ma façon de travailler.
Chaque retour que vous me faites est consigné une fois pour toutes, puis réappliqué automatiquement : la même remarque ne revient jamais deux fois. Mes agents lisent au démarrage tout ce qui a déjà été décidé et écrivent en fin de session ce qu’ils ont appris. Le système ne repart jamais de zéro, et plus on travaille ensemble, mieux il connaît vos attentes.
En veille
Des agents tournent en fond et repèrent ce qu’on peut encore améliorer.
Consigné
Chaque décision et chaque retour sont enregistrés, datés et gardés une fois pour toutes.
Réappliqué
Au démarrage suivant, tout est relu et appliqué sans qu’on ait à le redemander.
Un build qui compile ne prouve rien.
Je ne déclare jamais quelque chose « fonctionnel » sur la foi d’un voyant vert. Un site qui se lance et une fonctionnalité qui marche sont deux choses différentes, et seule la seconde compte. Alors je teste chaque livrable dans son vrai contexte d’usage.
Interface
J’ouvre le navigateur et je clique, exactement comme le ferait votre client. Capture d’écran à l’appui.
API
Je l’appelle avec de vraies données, puis je vérifie ce qui a réellement été enregistré derrière.
Mobile
Je pilote le simulateur et je déroule le parcours sur l’appareil, écran après écran.
Et quand je n’ai pas pu vérifier quelque chose, je vous le dis au lieu de bluffer. Cette page, par exemple, a été ouverte et testée sur écran et sur mobile avant que vous ne la lisiez.
Cette méthode, sur votre projet.
La meilleure façon de juger une méthode, c’est de la voir produire. Parlons de votre idée, et voyons ce qu’elle donne une fois passée dans cet atelier.