On connaît tous cette galère : un projet qui grossit, le code qui s'accumule, et la dette technique qui s'installe insidieusement. Refactoring, optimisation, chasse aux bugs, sécurité… Les tâches s'entassent et on n'a jamais le temps de tout faire. Et si on pouvait déléguer l'audit de ce joyeux bazar et même la planification des améliorations à une IA ? C'est exactement ce que propose shadcn/improve, un outil qui promet de rendre notre code plus propre, sans que l'on ait à lever le petit doigt (enfin, presque).
Le défi de la dette technique et l'aide des agents IA
La dette technique, c'est un peu le monstre sous le lit du développeur : on sait qu'il est là, on préférerait ne pas le regarder en face, mais tôt ou tard, il va falloir s'en occuper. Coûts de maintenance qui explosent, déploiements à risque, nouveaux développeurs qui fuient… Les conséquences sont bien réelles. Alors, quand j'ai découvert l'approche de shadcn (oui, le même shadcn derrière l'incroyable shadcn/ui), je me suis dit qu'il y avait peut-être de l'espoir.
Son idée ? Utiliser la puissance des agents IA pour faire le sale boulot : auditer, analyser, et surtout, planifier. L'humain garde le contrôle sur l'exécution, ou la délègue à des agents moins gourmands en ressources. C'est une vision séduisante, surtout quand on pense aux heures passées à débusquer les points faibles d'un vieux codebase.
Présentation de shadcn/improve : Audit intelligent et exécution optimisée
shadcn/improve n'est pas un outil de refactoring magique qui va réécrire votre code en un clin d'œil. Non, sa vocation est bien plus stratégique : c'est une Agent Skill. Concrètement, c'est une compétence que vous donnez à votre agent IA préféré (comme Claude Code ou Cursor) pour qu'il puisse auditer n'importe quel codebase et générer des plans d'implémentation ultra-détaillés. L'objectif est clair : utiliser un modèle d'IA très performant pour la compréhension et le jugement (l'audit), et des modèles moins coûteux pour l'exécution des tâches (la mise en œuvre des plans).
Le point crucial à retenir : shadcn/improve ne modifie jamais le code source directement. Son produit final, c'est un plan d'action. C'est un peu comme avoir un architecte IA qui vous dit exactement où casser des murs et où en reconstruire, mais sans jamais tenir le marteau.
Comment ça marche ? L'approche 'modèle capable pour l'audit, modèle simple pour l'exécution'
L'intelligence de shadcn/improve réside dans sa philosophie : séparer la réflexion coûteuse de l'exécution bon marché. Un modèle d'IA de pointe (le modèle le plus performant dont on dispose) va analyser le projet, identifier les problèmes prioritaires et préparer des instructions suffisamment précises pour qu'un agent moins sophistiqué puisse effectuer les modifications sans avoir à tout redécouvrir.
L'intérêt est avant tout économique. Habituellement, un agent doit comprendre le contexte, identifier les fichiers concernés, choisir une solution, écrire le code et vérifier son travail. Autant d'opérations qui consomment des tokens, notamment avec les modèles haut de gamme.
Avec shadcn/improve, on sépare deux responsabilités :
- La réflexion : un modèle puissant comprend les problèmes, évalue leur importance et prépare les interventions.
- L'exécution : un modèle moins coûteux applique les changements à partir d'instructions détaillées.
L'idée est simple : pourquoi mobiliser un modèle extrêmement performant pour modifier trois fonctions lorsque les choix techniques ont déjà été faits ? À condition que le plan soit suffisamment précis, un modèle plus léger peut parfaitement réaliser ce travail.
Du diagnostic aux plans d'implémentation
Contrairement à un simple prompt demandant « trouve les problèmes de mon code », shadcn/improve suit une méthode structurée. Il explore l'organisation du dépôt, ses conventions, ses dépendances et ses tests, puis recherche des améliorations dans plusieurs domaines : fiabilité, sécurité, performances, maintenabilité ou encore couverture des tests.
Les problèmes identifiés sont classés selon leur impact, leur coût de correction et le niveau de confiance associé. On peut ainsi distinguer les interventions réellement utiles des simples suggestions de confort.
Mais le plus intéressant arrive ensuite : pour chaque amélioration sélectionnée, l'outil génère un plan d'implémentation autonome sous forme de fichier Markdown dans un répertoire plans/.
Par exemple :
plans/001-fix-n-plus-one.mdCe document contient le contexte du problème, les fichiers concernés, les modifications attendues, les contraintes à respecter et les commandes permettant de vérifier le résultat.
Chaque plan est conçu pour être transmis à un autre agent sans dépendre de la conversation initiale. Il conserve également une référence au commit Git utilisé lors de sa création, afin de repérer les évolutions du code susceptibles de rendre certaines instructions obsolètes.
On obtient finalement quelque chose qui ressemble davantage à une spécification technique exploitable qu'à une vague recommandation générée par une IA.
Installation et utilisation
Pas besoin d'installer un nouveau serveur ou une infrastructure Docker. shadcn/improve utilise le format Agent Skills et fonctionne avec les assistants compatibles, notamment Claude Code et Cursor.
L'installation se fait avec :
npx skills add shadcn/improveUne fois la compétence disponible, on peut la lancer directement depuis son assistant :
/improvePlusieurs modes permettent d'adapter son utilisation :
/improve quick: recherche rapide des améliorations prioritaires./improve deep: exploration approfondie du projet./improve security: recherche ciblée sur la sécurité./improve perf: identification des problèmes de performances./improve branch: analyse des changements de la branche courante./improve next: propositions d'évolutions fonctionnelles./improve plan <description>: préparation d'un plan pour une modification précise./improve review-plan <fichier>: vérification et amélioration d'un plan existant.
Pour une première utilisation, /improve quick me paraît être le choix le plus raisonnable. Il permet de se faire une idée de la pertinence des résultats sans consommer immédiatement des quantités importantes de tokens.
L'exécution par des agents moins coûteux
C'est ici que le concept prend tout son sens. Une fois un plan généré, on peut demander son exécution :
/improve execute 001Lorsque l'environnement le permet, un agent utilisant un modèle moins coûteux est chargé de réaliser les modifications. Il travaille dans un Git worktree isolé, sans perturber la branche courante du développeur.
À la fin de son intervention, le modèle superviseur examine les différences et vérifie que le résultat correspond aux instructions. Si nécessaire, il demande des corrections, avec jusqu'à deux cycles de révision.
La fusion finale reste une décision humaine. L'outil ne modifie donc pas silencieusement la branche principale.
Cette séparation des responsabilités est particulièrement intéressante pour les modèles locaux. Un modèle hébergé sur un serveur GPU n'a pas forcément les capacités de raisonnement d'un modèle commercial haut de gamme, mais il peut être tout à fait suffisant pour appliquer des modifications correctement spécifiées.
Il faut toutefois que l'environnement utilisé permette de lancer ces agents dans des espaces de travail isolés. Dans le cas contraire, rien n'empêche de transmettre manuellement les plans à un autre assistant.
Un suivi des améliorations dans le temps
Autre fonctionnalité intéressante, la commande :
/improve reconcileElle permet de réexaminer les plans existants pour déterminer lesquels ont été réalisés, lesquels restent pertinents et lesquels sont devenus obsolètes après des modifications du projet.
C'est une manière de maintenir un backlog technique sans repartir systématiquement de zéro.
La compétence propose également une intégration avec les issues GitHub via l'option --issues. Les plans peuvent ainsi être publiés dans le système de suivi du dépôt.
Il reste évidemment préférable de relire les documents avant leur publication, particulièrement lorsqu'ils décrivent des failles de sécurité ou des composants sensibles.
Ce que j'aimerais en faire avec mes projets PHP et Symfony
Personnellement, je vois plusieurs applications intéressantes, notamment sur les projets qui accumulent les années de maintenance.
Sur une application Symfony, cela pourrait permettre de préparer des interventions ciblées : simplifier des services devenus trop complexes, corriger des requêtes Doctrine inefficaces, améliorer les tests ou préparer une migration technique.
Sur du PHP historique, l'intérêt serait encore différent. Certaines applications fonctionnent depuis quinze ans avec des fichiers de plusieurs milliers de lignes, très peu de tests et des dépendances difficiles à faire évoluer.
Dans ces conditions, demander à une IA de tout refactoriser serait probablement une très mauvaise idée. En revanche, lui faire préparer des interventions limitées et progressives me semble beaucoup plus réaliste.
Par exemple, on pourrait commencer par sécuriser quelques points d'entrée, ajouter des tests de non-régression, puis isoler progressivement certaines parties du code avant d'envisager une migration plus importante.
J'aimerais également expérimenter une organisation hybride : un modèle puissant pour les décisions architecturales, et un modèle local servi par vLLM pour exécuter les changements répétitifs.
L'objectif serait de profiter de la qualité des meilleurs modèles sans payer leur tarif pour chaque modification de code. Reste à vérifier si les modèles locaux sont suffisamment fiables pour suivre les instructions, utiliser les outils et corriger leurs propres erreurs.
Et pourquoi ne pas l'intégrer à GitLab et SonarQube ?
Une autre piste serait de combiner cette approche avec les outils de qualité déjà présents dans nos environnements de développement.
SonarQube sait détecter de nombreux problèmes de maintenabilité, de fiabilité et de sécurité. PHPStan peut identifier des incohérences de typage et des erreurs potentielles. Les pipelines GitLab permettent quant à eux d'automatiser les vérifications et les tests.
Il serait donc intéressant de faire travailler ces outils ensemble plutôt que de demander à un LLM de réinventer ce qu'ils savent déjà faire.
On pourrait imaginer le fonctionnement suivant :
- Un pipeline GitLab exécute les tests et les analyseurs statiques.
- Un agent récupère les problèmes détectés et les replace dans leur contexte technique.
- Il prépare des plans de correction pour les interventions jugées pertinentes.
- Des agents exécutent les modifications dans des branches isolées.
- Une nouvelle pipeline vérifie le résultat avant la création d'une merge request.
- Un développeur examine les modifications et décide de leur intégration.
Il ne s'agit pas d'une intégration GitLab native de shadcn/improve, mais d'une automatisation qu'il serait possible de construire autour des fichiers Markdown produits par la compétence.
Et c'est justement leur avantage : ils restent simples à lire, à versionner et à exploiter depuis différents outils.
Les limites à garder en tête
Malgré son intérêt, cette approche ne dispense pas de certaines précautions.
D'abord, un agent IA ne connaît pas nécessairement toutes les contraintes métier. Une portion de code qui semble inutile ou mal conçue peut répondre à une nécessité historique parfaitement légitime.
Ensuite, la qualité de l'exécution dépend directement du modèle utilisé et de la précision des instructions. Un petit modèle ne deviendra pas miraculeusement capable de réaliser n'importe quelle modification parce qu'un modèle plus performant lui a préparé un plan.
Les tests automatisés restent donc essentiels, tout comme les revues humaines. Sur une application ancienne dépourvue de tests, le risque de régression demeure important.
Enfin, il faut surveiller la consommation de tokens. Une exploration approfondie impliquant plusieurs sous-agents peut devenir coûteuse. L'économie réalisée pendant l'exécution doit compenser le coût de la préparation.
Il faut aussi tenir compte de la confidentialité du code lorsque l'analyse est effectuée par un modèle hébergé chez un fournisseur externe.
Conclusion : une autre manière de travailler avec les agents IA
Ce que je retiens surtout de shadcn/improve, c'est sa philosophie : ne pas demander au même agent de tout comprendre, de tout décider et de tout exécuter.
En séparant les décisions techniques des tâches de développement, on peut utiliser différents modèles selon leurs capacités, mieux maîtriser les coûts et conserver une trace exploitable des interventions prévues.
Cette approche me semble plus réaliste que la promesse d'une IA qui prendrait un dépôt complet pour le transformer automatiquement en code parfait.
Elle ouvre aussi des perspectives intéressantes pour les infrastructures auto-hébergées, notamment lorsqu'on dispose déjà de modèles locaux, de pipelines CI/CD et d'outils de contrôle qualité.
Je ne m'attends pas à ce que shadcn/improve fasse disparaître la dette technique. Mais s'il permet de préparer des corrections cohérentes, de les déléguer intelligemment et de progresser sans multiplier les interventions manuelles, ce sera déjà une belle avancée.
Le projet est open source, sous licence MIT, et disponible ici : github.com/shadcn/improve.
Reste maintenant à le confronter à un vrai projet, avec ses quinze années de rustines, ses dépendances oubliées et ses quelques milliers de lignes de PHP historique. C'est probablement là qu'on verra si cet architecte IA tient réellement ses promesses !