Auditer une codebase générée par IA : les 3 signaux qu'on regarde en premier

Auditer une codebase générée par IA, ce n'est pas chercher des bugs. C'est chercher les endroits où le code marche aujourd'hui et coûtera cher demain. Trois signaux reviennent dans presque tous les repos qu'on ouvre : les patterns React trop malins, le métier mélangé à l'interface, et les controllers qui font tout. Aucun des trois ne fait planter l'application. C'est précisément ce qui les rend dangereux.

On ouvre plusieurs repos par semaine dans le cadre du Bunker Test, notre audit gratuit. Voici ce qu'on regarde, dans quel ordre, et pourquoi.

1. Les patterns React trop malins

Une IA à qui vous demandez un composant vous donne rarement le composant le plus simple. Elle vous donne le plus impressionnant. Des useEffect en cascade qui se déclenchent les uns les autres. Un contexte global pour une valeur utilisée à deux endroits. Un hook custom qui enveloppe un hook custom qui enveloppe un useState.

Ce qu'on cherche concrètement : les useEffect qui ont un autre state du même composant dans leurs dépendances (une cascade cachée), les providers de contexte empilés dans le layout racine, et les fichiers de plus de 300 lignes qui ne contiennent qu'un seul composant.

Le test qu'on applique : est-ce qu'un développeur qui découvre le fichier peut dire ce qu'il fait en une minute ? Si la réponse est non, ce n'est pas un problème de niveau du développeur. C'est un problème de lisibilité, et la lisibilité est la seule chose qui rend une codebase modifiable dans six mois.

La règle de notre style guide, celle qui compte le plus depuis l'arrivée de l'IA : la solution la plus simple qui marche, pas la plus élégante. Le code généré part par défaut vers l'inverse.

2. Le métier mélangé à l'interface

Le deuxième signal est le plus coûteux à long terme. La règle de calcul du prix se retrouve au milieu d'un composant. Les conditions d'éligibilité d'un utilisateur sont écrites dans le JSX. La logique de facturation vit dans le handler du bouton.

Tant que la règle ne change pas, tout va bien. Le jour où elle change, et elle change toujours, vous ouvrez douze fichiers. Vous en corrigez onze. Le douzième continue d'appliquer l'ancien tarif pendant trois semaines avant que quelqu'un s'en aperçoive.

Ce qu'on cherche : les nombres en dur dans les composants (taux, seuils, durées), les conditions métier dupliquées à plusieurs endroits avec de légères variations, et l'absence d'un dossier qui centralise ces règles. Dans un repo sain, on doit pouvoir répondre à « où vit la règle de prix ? » en pointant un seul fichier.

La correction est rarement un gros refactor. On extrait la règle dans une fonction pure, on la teste une fois, et les douze composants l'appellent. C'est le genre de fix qu'on livre en une journée et qui change le coût de toutes les features suivantes.

3. Les controllers qui font tout

Côté serveur, le pattern est encore plus net. Une route qui valide les entrées, calcule le résultat, envoie l'email de confirmation, écrit en base et retourne la réponse. Cent cinquante lignes dans un seul handler.

Quatre responsabilités, donc quatre raisons de casser. Et zéro endroit où poser un test, parce que tester le calcul vous oblige à mocker l'envoi d'email et la base de données.

Ce qu'on cherche : les handlers de plus de 50 lignes, les appels à un service externe (email, paiement, IA) directement dans une route, et les requêtes en base écrites à l'intérieur du controller plutôt que dans une couche dédiée.

La séparation est classique : le controller valide et orchestre, les services font le travail. Ce n'est pas de l'architecture pour l'architecture. C'est ce qui vous permet de changer de fournisseur d'email sans toucher à votre logique de commande.

Le point commun des trois

Rien ne casse. Tout marche en démo. Vos utilisateurs ne voient rien.

C'est ce qui rend ces problèmes si particuliers aux codebases générées par IA. Le code produit par un développeur pressé casse vite et se signale. Le code produit par une IA compétente marche, passe la démo, et accumule une dette invisible. Le symptôme n'apparaît que plus tard, sous une forme que les founders décrivent tous de la même façon : « chaque nouvelle feature me prend plus de temps que la précédente. »

Ce n'est pas une impression. C'est la structure qui s'érode.

Ce qu'on protège en priorité

Un audit ne sert à rien s'il produit une liste de 80 remarques. On classe donc ce qu'on trouve selon ce qu'on appelle l'Expandable Core : le modèle de données, la couche d'authentification, les contrats d'API, les points d'intégration et les chemins de déploiement.

Le code de feature peut être imparfait. Il sera remplacé. Le code du core ne peut pas l'être, parce que tout ce que vous écrirez ensuite s'appuiera dessus. Un audit utile dit lesquels de vos trois signaux touchent le core, et lesquels peuvent attendre.

En pratique, sur la plupart des repos qu'on ouvre, le point 2 (métier dans l'interface) est celui qui touche le core le plus souvent, et c'est aussi le moins cher à corriger tôt.

Faire l'audit vous-même

Si vous voulez une première passe sans nous, trois questions suffisent à couvrir l'essentiel :

1. Combien de fichiers dois-je ouvrir pour changer une règle de prix ?
2. Est-ce que je peux tester mon calcul principal sans lancer la base de données ?
3. Est-ce qu'un développeur extérieur comprend mon composant le plus gros en une minute ?

Trois « non » ne veulent pas dire que votre produit est en danger. Ils veulent dire que votre prochaine feature coûtera plus cher que la dernière, et celle d'après encore davantage.

---

Le Bunker Test, gratuit. Vous nous donnez un accès en lecture seule à votre repo. On revient sous 5 jours ouvrés avec un score de Solidité et de Structure sur 100, vos 3 risques principaux et un correctif que vous pouvez livrer le jour même. Walkthrough de 15 minutes inclus, aucun engagement.

Demander votre Bunker Test →