Ou presque sans filtre.

Depuis quelques mois, avec Victor Serain on bosse sur le backoffice de Punchliner : une application web Node.js / TypeScript / MongoDB pour gérer les punchlines et construire une base de données complète sur le rap français, sous le regard très éclairé de Karim Hammou.

Je suis PO, Victor est le développeur. On avance au rythme de ses disponibilités. Pas de pression, c’est un side project.

Et puis le jeu mobile sort en première version de test. Une soixantaine de testeurs. Des retours encourageants. Mais le cœur du jeu repose sur la qualité de notre base de données et donc, les besoins grandissent.

Si vous voulez tester le jeu.

L’expérience : faire coder Claude sous ma supervision en PO

Un jour je me lance. Je ne peux pas ne pas tester l’IA. Je refais un petit projet perso que j’avais déjà codé il y a quelques années. Je suis plutôt bluffé par la vitesse à laquelle je sors quelque chose en prod. Pour information, je suis sur la version claude sonnet 4.6 sur ce projet.

Du coup, pourquoi ne pas faire la même chose sur Punchliner ?

Au bout d’un mois et demi, je fais une démo à Victor et Karim. J’en ai tombé, des User Stories. La vitesse est là, indéniable.

Puis vient la vraie question : quelle est la qualité du code produit ? Quel est le niveau de dette technique ? Est-on en train de bâtir un château de cartes ?

L’audit de Victor

Victor prend le temps de lire les branches produites avec Claude. Voilà ce qu’on en tire.

Les problèmes faciles à corriger :

• Pas d’index dans certains objets en base de données, des string là où il faudrait des ObjectId, une gestion des dates incohérente (parfois des strings au lieu de l’objet Date)
• Du TypeScript utilisé… sans typage. Beaucoup de any, des casts dans le corps des fonctions au lieu de typer les paramètres
• Peu de factorisation, par exemple la même REGEX répétée 8 fois dans le même fichier
• Des imports posés au milieu d’un fichier plutôt qu’en en-tête

Les problèmes plus préoccupants sur le long terme :

L’architecture du projet est une architecture oignon ‘séparation claire entre la couche HTTP, la couche métier et la couche données). Pourtant, au bout d’un mois et demi, des accès données contournent la couche dédiée. Une des forces de cette architecture, c’est de pouvoir changer de base de données rapidement. En l’état, ce n’est plus possible.

L’autre problème, plus insidieux : Claude livre toujours la feature demandée. Il n’évalue jamais le coût. Ni le coût de développement, ni les contraintes techniques que la fonctionnalité va imposer pour la suite. La complexité accumulée peut devenir un vrai frein aux prochaines évolutions.

Ce qu’on a perdu par rapport à une équipe de dev

Parce que oui, tomber des fonctionnalités avec Claude sur un side project, c’est pratique et peu coûteux. Mais si on veut construire quelque chose de pérenne, il faut nommer ce qu’on a perdu.

La concertation sur les choix techniques. Dans une équipe, la recherche de la solution la moins coûteuse passe par une construction partagée. On cherche ce qui permet de continuer à bâtir sans tout casser à chaque itération. Claude, lui, optimise pour répondre à la demande immédiate.

La relecture croisée. La revue de code entre développeurs préserve la connaissance collective. Là, relire certaines portions de code, on ne sait plus si c’est une fonctionnalité intentionnelle ou une implémentation approximative. La connaissance du code est dans ma tête de PO, pas partagée avec Victor.

La remise en question des fonctionnalités. En équipe, discuter de la faisabilité d’une feature impose de se demander si elle est vraiment utile. Claude ne pose jamais cette question. Il construit ce qu’on lui demande. Résultat : un risque de plat de spaghetti : dans le code, dans la base de données, dans le parcours utilisateur.

Ce qu’on en retient

Claude, c’est redoutable pour construire un outil à façon pour soi, rapidement. Mais si on construit quelque chose pour d’autres, les choix trop personnels du PO, non soumis à la discussion, finissent par s’accumuler. Et on risque de ne faire un outil adapté que au PO.

J’ai un passé de développeur. Mais je n’ai pas pris le temps de relire chaque proposition. Au début un peu, puis petit à petit je me suis dit : je peux lui faire confiance (et la flemme aussi, et le fait de lui faire coder des trucs pendant que je fais autre chose aussi). Et dans tous les cas je n’aurai pas eu l’œil attentif de Victor.

La conclusion qu’on en tire : la revue de code reste indispensable. Les commits incrémentaux aussi. Et le jugement du développeur, pour évaluer coût, risque, et cohérence architecturale, reste le vrai garant de la qualité. La vitesse de Claude n’est un avantage que si quelqu’un de compétent maintient ce regard.

Ce n’est pas parce que Claude produit vite qu’il faut tout sacrifier pour la vitesse.

Views: 2