Dans l’éditeur SaaS en cybersécurité où je travaille, toute l’équipe tech, soit 10 à 20 personnes, développe avec un même flow Claude Code. Je l’ai conçu et je le maintiens.
Depuis, le rythme de livraison a profondément changé. Tout n’est pas réglé pour autant : des incompréhensions subsistent, la revue devient un goulot et les quotas d’usage se consomment vite. Et l’expertise technique reste sollicitée à chaque étape, parce que le code que l’agent écrit reste le nôtre.
Pourquoi une base commune plutôt que chacun son agent
Au départ, l’usage de l’IA variait beaucoup d’une personne à l’autre. Tout le monde n’avait pas le même niveau en développement agentique, ni la même pratique de Claude Code.
J’utilisais déjà Claude Code avec un harnais construit pour mon propre travail. La direction technique m’a poussé à le retravailler pour le diffuser dans l’équipe. La base commune qui en est née existe depuis moins d’un an.
Le choix de Claude Code tient d’abord à une préférence personnelle, que j’assume (la transparence d’Anthropic dans sa communication, son éthique et la qualité de ses modèles). À mes yeux, Anthropic a souvent ouvert la voie à des standards que d’autres ont suivis, comme MCP ou le format des skills. Ses outils sont pensés pour un usage sérieux et professionnel, et les mécanismes de partage de Claude Code se prêtaient bien à une base d’équipe. Des solutions concurrentes existent et sont, elles aussi, d’un très bon niveau. Ma préférence va pourtant toujours à Anthropic.
L’objectif était de prendre le virage ensemble. Le flow devait accélérer nettement nos développements, qu’il s’agisse de livrer des fonctionnalités, de mener des migrations, d’assurer la maintenance ou de corriger des vulnérabilités. Il devait aussi garantir une forme d’égalité dans les outils. Il ne serait pas normal que quelques personnes livrent très vite en laissant leurs collègues sur le côté.
La base est vivement recommandée, pas imposée. Ceux qui veulent aller plus loin peuvent l’améliorer ou l’utiliser autrement, et tester d’autres approches reste bénéfique tant que cela ne perturbe pas le flow de l’équipe.
Ce que contient la base, et comment elle arrive chez chacun
La base vit à deux endroits. Un plugin Claude Code, diffusé par une marketplace, regroupe les skills communs. Les rules et les settings, eux, sont dans les dépôts, à côté du code qu’ils concernent.
Un plugin est l’unité que Claude Code installe et charge d’un bloc : skills, sous-agents, hooks, serveurs MCP. Une marketplace est un catalogue, un dépôt qui liste des plugins et qui peut rester privé (documentation des plugins). Pour une équipe, une évolution du flow devient simplement une nouvelle version du plugin, que chacun reçoit depuis la marketplace.
Les skills communs couvrent notamment le développement, la revue et le débogage. Selon la situation, c’est le développeur qui les appelle ou le flow lui-même.
Des serveurs MCP relient l’agent aux outils de l’équipe. Certains sont des serveurs existants pour des outils du marché, d’autres ont été écrits en interne. C’est par eux que l’agent va chercher le PRD (le document qui décrit le besoin produit) et les informations dont il a besoin, là où elles sont écrites. Le flow de débogage, par exemple, s’appuie sur un serveur MCP interne développé par notre équipe DevOps : il va chercher les logs de l’environnement SaaS où le bug se produit.
La base est commune, mais l’expérience reste personnelle. La mémoire de Claude Code est propre à chacun et retient ses préférences et ses corrections. Même en passant par le même flow, chacun garde ainsi une expérience plus personnelle.
J’ai conçu cette base seul et j’en assure l’essentiel de la maintenance, à partir des retours de mes collègues, des nouveautés de l’outil et de ma propre pratique.
Pour un sujet donné, le parcours est le suivant :
- Un développeur lance l’agent sur un PRD écrit par le produit.
- L’agent récupère le PRD et le contexte utile via MCP, puis propose un plan.
- Le développeur juge si ce plan est prêt à être présenté.
- Le produit, la QA et la tech valident le plan ensemble, et le plan est rattaché au PRD.
- L’agent implémente et vérifie son travail de bout en bout, sous la supervision du développeur.
- Le développeur teste lui-même le résultat, puis demande une revue humaine de la PR.
Le plan, dernière validation humaine avant l’autonomie
Le plan est la dernière étape où un humain valide avant que Claude parte davantage en autonomie. Il passe par deux filtres.
Le premier est technique. Le développeur qui a lancé l’agent lit le plan et décide s’il est assez solide pour être présenté au produit et à la QA. Le second est collectif : le produit, la QA et la tech le valident d’un commun accord. Le plan reste dans la session de l’agent, et il est aussi rattaché au PRD dans l’outil où celui-ci est écrit. L’objectif est de lever les inconnues et les incompréhensions avant l’implémentation.
Quand un PRD engage un changement d’architecture ou des questions d’infrastructure, il peut être mis en attente. Un ADR est alors mené d’abord, lui aussi en flow agentique, pour échanger et travailler ce sujet en amont.
La pratique qu’Anthropic décrit dans son cours sur le cycle de développement est plus légère. L’ingénieur valide son plan, et seul un changement jugé plus risqué remonte à un tech lead ou à un architecte (Claude Academy). L’écart tient à notre organisation, où le produit est très présent et joue un rôle important. Avec l’IA, la frontière entre produit et développement est plus perméable qu’avant, mais les responsabilités restent.
Cette validation n’élimine pas les incompréhensions. Il en reste, et c’est toute la difficulté. Ce problème n’est pas propre à l’IA : les entreprises le rencontrent depuis des décennies.
Laisser l’agent travailler seul, sans lui laisser tout faire
Une fois le plan validé, l’agent implémente et vérifie lui-même son travail, en local. Il lance les tests automatisés, démarre l’application pour contrôler le comportement dans un navigateur, et un sous-agent relit ce qui a été produit.
L’agent revient vers un humain dans quatre cas :
- Quand l’implémentation l’oblige à sortir du plan validé
- Quand la vérification échoue plusieurs fois de suite
- Quand une décision sort de son périmètre, qu’elle touche au produit, à l’architecture ou à la sécurité
- Quand une action dont il a besoin est bloquée
Autonome ne veut pas dire sans surveillance. Le développeur suit ce que fait l’agent, vérifie de temps en temps où il en est, et teste lui-même la fonctionnalité et son rendu avant de demander la moindre revue.
Reste la question des limites. Dans notre flow, l’agent est cadré par des consignes : les rules des dépôts et les instructions des skills. La documentation de Claude Code est claire sur leur nature. Ces fichiers sont chargés comme du contexte, pas comme une configuration appliquée (documentation de la mémoire). Une consigne oriente l’agent, elle ne l’empêche de rien.
Les limites réelles sont donc posées dans les outils. Les comptes utilisés à travers les serveurs MCP n’ont que des droits restreints, et seules certaines actions MCP sont autorisées. Ce qui doit rester hors de portée de l’agent est bloqué par l’outil lui-même, pas par ses instructions.
Ce que le flow a changé, et ce qui coince encore
La vitesse a complètement changé. À mon estimation, une personne livre aujourd’hui seule, en quelques jours, une fonctionnalité qui demandait plusieurs semaines à une équipe. C’est une tendance que j’observe, pas une mesure.
Les pratiques sont devenues assez homogènes pour que je ne repère pas d’écart de flow ou de retard entre les personnes. La montée en compétence est réelle dans l’ensemble, même si chacun garde ses appétences et sa façon d’aborder l’IA.
Le premier point dur est la revue. L’agent produit plus vite que l’équipe ne relit, et la revue devient un goulot. Le problème est en partie traité, pas encore totalement. Des pistes sont à l’étude, comme un outil de revue externe tel que CodeRabbit ou un usage de l’API Claude. Avec les progrès des modèles et l’amélioration continue du flow, je constate de moins en moins d’erreurs, ce qui limite le risque d’une revue humaine allégée. Anthropic fait le même constat pour sa propre équipe Claude Code : une fois l’écriture du code accélérée, la vérification, la revue et la sécurité sont devenues les nouveaux goulots (Running an AI-native engineering org).
Le second point dur est la consommation. À mes yeux, un siège professionnel est rentabilisé tout de suite pour l’entreprise. Mais l’usage de chaque siège est limité sur une fenêtre glissante de cinq heures et sur une fenêtre hebdomadaire, et selon les modèles et les moments, ces quotas se consomment vite. Le travail consiste alors à ajuster le flow pour choisir, tâche par tâche, le modèle et le niveau d’effort adaptés, ce que les progrès des modèles rendent de plus en plus possible.
Faire évoluer le flow au rythme de l’outil
Claude Code évolue très vite, et une base d’équipe doit suivre sans casser le travail de chacun. J’utilise l’outil en permanence, au travail comme sur mes projets personnels, et ma veille est très active. En plus de la documentation officielle, je suis notamment Boris Cherny, Thariq Shihipar et Lydia Hallie, de l’équipe Claude Code, Alex Albert, chez Anthropic, et le compte ClaudeDevs.
Suivre les annonces est facile. Reconnaître celles qui n’apportent rien l’est moins : beaucoup de contenus présentent comme une découverte un flow qui n’en est pas une, ou font du bruit sur un faux sujet. Avant qu’une nouveauté entre dans le flow, je me pose quatre questions :
- L’ai-je essayée sur un vrai cas, plutôt que de croire ce qu’on en dit ?
- Que dit la documentation ou le changelog officiel de ce qu’elle fait vraiment ?
- Qui en parle : quelqu’un qui montre un usage réel, ou quelqu’un qui vend un flow miracle ?
- Quel problème réel de l’équipe règle-t-elle ?
Une nouveauté qui passe ces questions est d’abord testée de mon côté. Les retours de mes collègues déclenchent aussi des ajustements. Quand un changement est prêt, il part dans une nouvelle version du plugin, que l’équipe reçoit par la marketplace.
Rester responsable du code que l’agent écrit
Ce flow est pensé pour mon entreprise. Il pourrait être très différent ailleurs sans que ce soit un problème. Travailler en flow agentique est un équilibre permanent, et cet équilibre n’est pas le même d’une entreprise à l’autre.
La parallélisation en est un bon exemple. Un agent permet de mener plusieurs tâches de front. Mais plus on parallélise, plus l’organisation doit être solide et la maturité élevée pour se permettre de lâcher prise sur ce qui est produit. Chaque entreprise, avec sa façon de fonctionner, doit trouver sa meilleure manière de travailler avec un agent.
Un point, en revanche, ne dépend pas de l’organisation. Le métier de développeur évolue, et un agent donne une vue plus macro de ce qu’on construit. C’est là que le passage en flow agentique devient critique : cette vue plus large ne doit surtout pas faire baisser l’attention.
L’expertise technique doit rester sollicitée à chaque étape, pour juger le plan, suivre l’implémentation, tester ce qui a été construit et relire. Si on cesse de l’exercer, on perd la main sur ce qu’on produit. On n’apporte plus de valeur ajoutée, et on finit par perdre pied face à ce qui est produit.
Même quand Claude, ou une autre IA, écrit le code, c’est toujours notre code, et on en reste responsable.