Claude Code : à quoi ça sert vraiment en équipe

Depuis un an, c'est l'outil dont parlent toutes les équipes techniques que je croise. La question qu'on me pose n'est pourtant presque jamais « comment ça s'installe » : c'est « est-ce que ça va vraiment changer quelque chose chez nous ». La documentation d'Anthropic répond très bien à la première. Sur la seconde, elle ne peut rien faire, parce que la réponse dépend davantage de votre organisation que du produit.

Claude Code est un agent de développement qui travaille directement dans votre dépôt, depuis le terminal : il lit le code, lance des commandes, modifie des fichiers et se corrige en boucle, sous votre validation. Dans une équipe, son effet réel n'est pas d'écrire du code plus vite : il déplace le travail du développeur vers le cadrage et la relecture, et il révèle sans ménagement si votre projet possède une mémoire écrite ou non.

Ce qu'il déplace, c'est le goulot d'étranglement

Le premier contresens consiste à y voir un accélérateur de frappe. Taper du code n'a jamais été le coût dominant du développement logiciel : comprendre ce qu'il faut faire, décider comment, et vérifier que le résultat tient, voilà où partent les journées. Un agent qui travaille dans le dépôt ne supprime pas ces trois coûts, il en change la répartition. La production de code devient abondante et peu chère ; comprendre et vérifier deviennent, mécaniquement, la majorité du travail. Un développeur qui passait sa journée à écrire passe désormais une bonne part de son temps à formuler une intention précise, puis à relire ce qui est revenu. C'est un métier proche, pas le même, et c'est la raison pour laquelle deux heures de préparation produisent parfois trois jours d'exécution.

Cette bascule n'est pas confortable pour tout le monde, et je trouve sain qu'elle ne le soit pas. Relire du code qu'on n'a pas écrit demande un effort supérieur à l'écrire soi-même : c'est un fait connu bien avant l'IA, et c'est exactement le muscle que l'outil sollicite en permanence. Les développeurs les plus expérimentés sont souvent les plus réticents, non par conservatisme mais parce qu'ils mesurent très bien ce que coûte une relecture sérieuse, et ce que coûte une relecture bâclée six mois plus tard. J'ai détaillé ailleurs pourquoi ce rejet des profils seniors mérite d'être écouté plutôt que contourné par une directive descendante.

Il ne fonctionne bien que sur un projet qui a de la mémoire

Voilà l'exigence que personne n'annonce au moment de la décision. Un agent arrive sans antériorité à chaque session : il ne sait pas pourquoi vous avez écarté telle base de données l'an dernier, quelle convention de nommage vous tenez, quel module est fragile et pour quelle raison. Si cette connaissance vit uniquement dans la tête de trois personnes, l'agent repose les mêmes questions, propose les mêmes solutions déjà écartées, et chaque développeur réexplique le contexte de son côté. L'outil n'est alors pas mauvais : il est aveugle. La contrepartie, c'est que ce travail d'écriture profite d'abord aux humains. Un nouvel arrivant qui lit les conventions et les décisions d'architecture du projet gagne exactement ce que l'agent gagne.

Il ne règle aucun de vos problèmes de process

C'est la position que je défends depuis le début, et elle n'a pas bougé : le process compte plus que l'outil. Une équipe qui sait découper une fonctionnalité, écrire une story sans ambiguïté et tenir une définition de « terminé » ira plus loin avec un outil moyen qu'une équipe sans méthode avec le meilleur agent du marché. La raison est simple : un agent amplifie ce qu'on lui donne. Une spécification floue produit du code générique, livré vite, qu'il faudra jeter. Le flou devient plus coûteux qu'avant, parce qu'il se matérialise en quelques minutes au lieu de quelques jours, et qu'il a l'apparence du travail fini.

Dit autrement : l'outil vous rendra plus rapides sur ce que vous savez déjà formuler, et plus rapidement perdus sur le reste. C'est pour ça que les déploiements que je vois réussir commencent rarement par l'installation. Ils commencent par un mois de mise au propre : ce qu'on documente, qui relit quoi, ce qu'un agent a le droit de toucher et ce qu'il n'a pas le droit de toucher. Le reste suit sans difficulté, parce que l'outillage est devenu la partie facile du problème.

Comment vous saurez si ça marche

Je me méfie beaucoup des impressions sur ce sujet : l'effet de nouveauté produit un enthousiasme réel pendant quelques semaines, puis une déception symétrique. La seule façon honnête de trancher consiste à fixer, avant de commencer, deux ou trois indicateurs que vous saviez déjà lire. Le délai entre le moment où une décision est prise et celui où elle est en production. La part du travail livré qui repart en correction dans les semaines suivantes. Le temps réellement consacré à la relecture, qui doit monter : s'il n'a pas bougé alors que le volume de code a doublé, vous avez un problème qui se révélera plus tard. Et la question qu'on oublie toujours : combien de fois par semaine quelqu'un réexplique à l'agent un contexte qui aurait dû être écrit.

Ce que je regarde avant d'équiper une équipe

Trois choses, dans cet ordre. D'abord l'existence de filets : des tests qui échouent quand quelque chose casse, une intégration continue qui tourne, une revue obligatoire avant fusion. Sans ça, vous n'augmentez pas la vitesse, vous augmentez la vitesse à laquelle vous introduisez des défauts que personne ne verra. Ensuite les droits : ce que l'agent peut lire, écrire, exécuter, et sur quels environnements, en partant du principe qu'il se tromperait. Enfin les gens : une équipe à qui on impose un outil trouve mille raisons de ne pas s'en servir, et elle a souvent au moins une bonne raison parmi elles. C'est le travail que je fais en accompagnement au déploiement de l'IA agentique, et quand le besoin est d'abord de monter le niveau collectif, une formation de deux ou trois jours suffit souvent à débloquer la suite.

Cet outil aura changé plusieurs fois d'ici un an, et la liste de ses fonctionnalités n'a donc pas grand intérêt. Ce qui restera vrai, c'est la mécanique : un agent transforme un contexte clair en travail exécuté, et ne compense jamais un contexte absent. Votre avantage ne viendra pas du fournisseur que vous choisissez, mais de la qualité de ce que vous êtes capables d'écrire sur votre propre projet, et de la discipline de relecture que vous tenez. Ces deux actifs se construisent lentement, ils ne se périment pas, et ils vous servent aussi le jour où vous changez d'outil. C'est tout le sujet de mon guide sur l'IA agentique, et la raison pour laquelle je commence toujours par le process.