Claude Code est un agent qui travaille dans le terminal sur l'ensemble d'un dépôt : il lit le code existant, écrit les fichiers, lance les tests, ouvre les pull requests. Sur un périmètre cadré, il fait en une journée ce qui prenait une semaine.
Ce qui change n'est donc pas la façon d'écrire du code, mais l'arbitrage qu'une direction fait devant un besoin interne : recruter, sous-traiter, ou renoncer. Le troisième choix était le plus fréquent. Il n'a plus de raison d'être.
Ce qu'on ne confie pas à un agent
Claude Code écrit vite, y compris du code faux. Sans relecture, la dette technique s'accumule à la vitesse des fonctionnalités. On ne le laisse donc jamais décider d'une architecture, toucher à une migration de production sans revue, ou manipuler des données personnelles sans garde-fou.
Et on ne remplace pas une équipe produit : construire votre cœur de métier demande du contexte et de la mémoire longue. Ce qu'on remplace, c'est le recrutement qu'on fait par défaut pour l'outillage interne.
Par où commencer
Par le chantier que tout le monde repousse depuis un an, presque toujours un outil interne : un portail client, un back-office, un reporting encore fait à la main. Sept jours suffisent pour savoir si la méthode tient chez vous, et le coût d'essai est d'un sprint.
Ce qu'on livre en sept jours
Un périmètre volontairement petit, mais en production. Un back-office qui remplace un tableur partagé. Un portail où le client dépose ses pièces au lieu de les envoyer par mail. Un rapport hebdomadaire qui s'écrit tout seul. On ne livre pas une maquette : le premier sprint met quelque chose en ligne, sur vos comptes, que vos équipes utilisent la semaine suivante.
Ce rythme n'est pas un argument de vente, c'est une contrainte de méthode. Un sprint d'une semaine oblige à découper, et un découpage serré est ce qui empêche un projet interne de s'enliser six mois.
Ce qui se passe pour votre équipe technique
Rien de menaçant, et c'est le malentendu le plus courant. Vos développeurs gardent le cœur de métier, celui qui demande du contexte long et des arbitrages. Ce qu'on prend, c'est la file d'attente : les outils internes, les intégrations, les scripts qu'on repousse depuis un an faute de temps.
Sur les équipes qui n'ont pas de développeur, l'effet est différent : le sujet existe enfin. Les demandes qu'on classait dans « on verra plus tard » deviennent des sprints, et l'arbitrage entre recruter et renoncer disparaît.
Comment on garantit que le code tient
Revue humaine systématique, personne ne fusionne ce qu'il n'a pas lu. Tests sur les chemins qui comptent. Rien en production sans migration rejouable. Tout est versionné chez vous dès le premier commit, avec un accès de notre côté qu'on retire à la livraison. Si on part, vous ne perdez rien.






















Comment on travaille
Un sprint tous les 7 jours.
On fonctionne par cycles courts. À chaque sprint : un kick-off, une démo, une livraison. C'est ce rythme qui permet d'avancer vite sans rien lâcher sur la qualité, et d'empiler les livraisons semaine après semaine.
J0
Kick-off
J7
Call démo
J14
Call démo