Claude Code gratuit : ce qu'un essai sans budget prouve

Le scénario revient souvent. Quelqu'un dans l'équipe veut savoir si ces agents de code valent le budget qu'il faudrait demander, alors il essaie ce qui ne coûte rien, un vendredi en fin d'après-midi, sur la première tâche qui lui tombe sous la main. Le lundi, le verdict est déjà tombé, et il est négatif.

On peut évaluer sérieusement un agent de code sans dépenser un centime, à condition de le faire sur une vraie tâche de votre arriéré et sur un dépôt dont la mémoire a été écrite au préalable. Sans cette préparation, vous ne mesurez pas l'outil : vous mesurez le silence de votre projet, et dans ce cas le résultat est connu d'avance.

Un essai improvisé mesure votre dépôt, pas l'outil

Ouvrez Claude Code sur un dépôt qui ne contient aucune indication à son intention. L'agent ne sait pas où vivent les tests, ni comment vous nommez vos fichiers, ni quelle bibliothèque a été abandonnée l'an dernier pour une raison précise. Il fait donc ce que ferait n'importe qui à sa place : il pose des questions, puis, faute de réponse, tranche seul en appliquant les conventions les plus répandues du métier. Le code qui en sort est générique, et un développeur expérimenté le voit en trois secondes. Son verdict est exact : ça ne ressemble pas au code de la maison. Mais il porte sur l'expérience, pas sur l'outil, exactement comme juger un nouvel arrivant sur sa première journée, sans documentation ni accompagnement.

Le problème de ce protocole n'est pas qu'il soit sévère, c'est qu'il ne contient aucune information. Il rendra le même verdict quel que soit l'agent testé, aujourd'hui ou dans six mois, parce que ce qui détermine le résultat n'est pas la qualité du modèle mais l'absence de contexte. C'est un biais discret et coûteux, parce que personne ne ment dans l'histoire : celui qui a mené l'essai rapporte fidèlement ce qu'il a vu, son équipe le croit sur parole et elle a raison de le croire. La conclusion a toutes les apparences de l'expérience de terrain, et beaucoup d'équipes s'en sont servies pour décider que l'IA plafonnait, alors qu'elles avaient mesuré leur propre dépôt.

Un essai mal préparé rend toujours le même verdict, quel que soit l'outil. Une mesure dont le résultat ne dépend pas de l'objet mesuré ne mesure rien.

Choisir la tâche : ni vitrine, ni cauchemar

Deux choix de tâche ruinent l'essai avant qu'il ne commence. Le premier est la démonstration : une page web partie de zéro, un petit utilitaire autonome, le genre d'exercice où il n'y a aucun code existant à respecter et donc rien de ce qui fait la difficulté du métier. Ça marche toujours, ça n'engage rien, et personne dans l'équipe ne sera convaincu. Le second est le cauchemar : le bug que personne n'a résolu depuis trois mois, celui sur lequel on lâche l'outil pour voir. Il échoue, mais un bon développeur senior échouerait aussi dans les mêmes conditions, donc l'échec ne dit rien non plus. Entre les deux, il y a tout votre arriéré.

Prenez une tâche que vous auriez de toute façon confiée cette semaine. Assez grosse pour que la boucle complète compte : plusieurs fichiers touchés, un test à écrire ou à faire passer, un passage en revue à la fin. Si la tâche se fait à la main en vingt minutes, vous ne mesurerez qu'une vitesse de frappe. Et choisissez-la avant d'ouvrir l'outil, par écrit, idéalement avec quelqu'un qui ne mènera pas le test. Sans cette précaution, la tâche dérive insensiblement vers ce que l'outil fait bien ou mal, selon ce que la personne qui tient le clavier a envie de démontrer, et tout le monde a déjà un avis à ce stade.

La demi-journée de préparation qui rend le test honnête

C'est la partie que tout le monde veut sauter, et c'est elle qui décide de la valeur du résultat. Rien de lourd : une demi-journée suffit, et ce que vous écrivez là ne servira pas qu'au test, puisque le prochain développeur qui rejoindra le projet en profitera exactement de la même façon. L'idée tient en une phrase. Un agent travaille à partir de ce que le projet dit de lui-même, donc tant que le projet ne dit rien, il devine, et il devine avec l'aplomb d'un consultant qui débarque. Votre préparation consiste à remplacer ces devinettes par des faits, et quatre points suffisent à couvrir l'essentiel.

1

Écrire la mémoire du projet

Une page, pas un wiki. Ce que fait le projet, où se trouvent les choses, les conventions de nommage, la commande qui lance les tests, et surtout les interdits avec leur motif. Reprenez ce que vous expliquez à l'oral au dernier arrivé pendant son premier mois : c'est plus court qu'on ne croit, et ce n'est écrit nulle part.

2

Rédiger la tâche comme un cadrage, pas comme un titre

« Ajouter l'export des factures » n'est pas une tâche, c'est une étiquette. Écrivez le contexte métier, les contraintes, les cas limites connus et ce qu'il ne faut surtout pas toucher. Puis demandez à l'agent de contester ce cadrage avant d'écrire la moindre ligne : ses questions désignent les trous de votre spécification.

3

Prévoir la vérification avant de lancer

Décidez d'avance qui relit, avec quelle grille, et comment vous saurez que ça marche : les tests qui passent, le scénario à rejouer à la main, la personne qui devra maintenir ce code dans six mois. Une relecture improvisée après coup se transforme toujours en discussion d'opinion sur le style.

4

Fixer le critère de sortie par écrit

À quelle condition direz-vous oui, à quelle condition direz-vous non ? Notez-le avant de commencer. Un critère posé après coup se plie sans effort à ce qu'on avait envie de conclure, et c'est la façon la plus courante de rendre un essai inexploitable sans s'en apercevoir.

Cette préparation donne souvent l'impression de tricher, comme si l'on aidait l'outil à réussir. C'est l'inverse. Elle n'est pas une faveur faite au test, elle est la description fidèle de ce à quoi ressemble l'usage quotidien : la préparation est devenue le vrai travail, et l'exécution n'en est que la conséquence. Si vous refusez de la faire pour l'essai, vous avez en réalité posé une autre question, celle de savoir si un agent produit du bon travail sans aucun investissement de votre part. La réponse est non, elle est stable depuis le début, et elle n'aide à décider de rien.

Lire le résultat : le coût de relecture, pas la beauté du diff

Le réflexe est de regarder le code produit et de se demander s'il est bon. C'est le mauvais indicateur, parce qu'un code peut être élégant et faux, moche et juste. Regardez plutôt trois choses. Combien d'allers-retours pour obtenir quelque chose d'acceptable, car c'est la boucle que vous vivrez tous les jours. Où l'agent a hésité, car ces endroits désignent précisément les trous de votre documentation, et cette information vous reste quel que soit le verdict. Et le temps que la relecture a pris, rapporté à celui qu'il vous aurait fallu pour écrire la chose vous-même : ce rapport est le seul chiffre qui compte vraiment, et une seule tâche suffit à l'obtenir.

Le piège symétrique existe aussi, et je le rencontre autant que l'autre. Un résultat qui impressionne, du code qui compile, des tests qui passent, et la conclusion tombe dans l'autre sens : c'est magique, on y va. Or des tests qui passent ne prouvent pas que le comportement est le bon, surtout quand c'est l'agent qui a écrit les tests en même temps que le code. Faites relire par celui qui devra maintenir, et exécutez le scénario réel plutôt que la suite automatisée. Un essai enthousiaste et un essai qui rejette souffrent du même défaut quand personne n'a vérifié dans le détail : ils rapportent une impression, pas une mesure.

Les trois choses qu'un essai gratuit ne vous dira jamais

Il faut être clair sur la portée de l'exercice, sinon il sera cité comme preuve de choses qu'il n'a pas mesurées. Une tâche menée dans de bonnes conditions ne dit rien du comportement en charge : ce qui se passe quand les demandes s'enchaînent sur un sprint entier, ou quand le dépôt bouge sous l'agent pendant qu'il travaille. Elle ne dit rien du coût réel à l'usage, parce qu'un essai est l'usage le plus soigneux que vous aurez jamais : une personne attentive, une tâche choisie, aucune urgence. Elle ne dit rien, enfin, du travail à plusieurs sur le même dépôt : les conflits, la file d'attente qui se forme à la relecture, et la question de savoir qui répond de ce qu'un agent a produit. Ces trois sujets ne se découvrent qu'à l'échelle d'une équipe.

En revanche, l'essai répond à trois questions qu'on n'attendait pas de lui. Combien de temps prend la préparation chez vous, avec votre dépôt et vos conventions, ce qui est une donnée d'entrée de n'importe quelle décision ultérieure. Si votre projet est documentable du tout, car certains ne le sont pas sans un travail préalable qui dépasse de loin le cadre d'un test. Et qui, dans l'équipe, va s'en servir sérieusement, parce que l'adoption se joue sur deux ou trois volontaires bien plus que sur une décision de direction. Ces trois réponses valent plus cher que le verdict sur l'outil, et elles survivront à la prochaine génération de modèles.

Ce qui reste d'un essai bien mené, c'est rarement la conclusion. C'est la page de mémoire du projet écrite pour l'occasion, le cadrage de tâche formulé correctement pour une fois, et la liste des endroits où l'agent a buté faute de règle écrite. Une équipe qui conclut « pas maintenant » mais garde ces trois artefacts est en bien meilleure position six mois plus tard que celle qui a signé un abonnement sans rien préparer. Reste à ne pas confondre les questions : un essai gratuit répond à « est-ce que ça mérite qu'on s'y penche sérieusement », pas à « est-ce qu'on déploie ». Le guide de l'IA agentique en entreprise décrit la suite, et c'est souvent par ce protocole que commence un accompagnement, avant toute décision de budget.