Vous avez construit la moitié d’un filet de sécurité et décrété que c’était terminé

Soyons honnêtes sur ce à quoi ressemblent vraiment la plupart des pipelines de code IA en ce moment.

Vous générez du code avec Cursor ou Claude Code. Vous exécutez tsc --noEmit parce que le mode strict de TypeScript détecte les incompatibilités de types. Vous exécutez ESLint parce que personne ne veut se disputer à propos des points-virgules dans une pull request. Peut-être exécutez-vous dependency-cruiser parce que les imports circulaires sont gênants. Vos tests passent. Vous livrez.

Et vous pensez que c’est un stack déterministe.

Ce n’en est pas un. C’est un stack type-et-style. Vous avez empêché les états invalides et appliqué les frontières d’import, ce qui est véritablement utile. Mais vous n’avez absolument rien fait concernant le fait que le LLM vient de générer une fonction de 180 lignes avec une complexité cyclomatique qui ferait pleurer un théoricien des graphes. Vous n’avez pas détecté que trois modules différents ont copié le même helper avec des noms de variables légèrement différents. Vous n’avez pas remarqué que la gestion des erreurs se résume à un unique catch (e) { console.log(e) } posé au bas d’une chaîne de promesses comme un videur fainéant.

Le code compile. L’architecture est propre. Le code reste objectivement terrible.

C’est là le fossé. Et c’est important parce que le code généré par IA a un talent particulier pour produire exactement ce genre d’ordures : structurellement valide, conforme sur le plan architectural, et en train de pourrir tranquillement de l’intérieur.

Ce qu’est réellement la couche manquante

Pensez à la différence entre un bâtiment qui passe l’inspection d’un ingénieur structurel et un bâtiment agréable à vivre. L’inspection structurelle vérifie si le bâtiment s’effondre. Elle ne vérifie pas si la douche se vide dans l’évier de cuisine. Les deux comptent. Ce sont des rôles différents.

Votre stack déterministe existant est l’ingénieur structurel. Il vérifie :

  • Types : Cette valeur peut-elle même exister sous cette forme ?
  • Linting : La syntaxe respecte-t-elle une hygiène de base ?
  • Règles d’architecture : Les imports respectent-ils les limites ?
  • Tests : Le scénario nominal s’exécute-t-il sans planter ?

Ce qu’il ne vérifie pas :

  • Complexité : Cette fonction comporte-t-elle tellement de branches qu’aucun humain ne pourra jamais la comprendre correctement ?
  • Duplication : Le LLM a-t-il généré la même logique en quatre endroits avec des variantes mineures ?
  • Nommage : data est-il un nom de variable significatif, ou est-ce l’équivalent programmatique d’un haussement d’épaules ?
  • Gestion des erreurs : Les erreurs sont-elles réellement traitées, ou simplement attrapées et ignorées ?
  • Structure : L’organisation des fichiers a-t-elle du sens, ou est-ce une décharge ?
  • Commentaires : Les parties délicates sont-elles expliquées, ou le prochain développeur va-t-il avoir besoin d’une séance de spiritisme ?
  • Taille : Ce fichier fait-il 400 lignes parce que c’est nécessaire, ou parce que personne n’a dit au modèle d’arrêter ?

Ce ne sont pas des préférences esthétiques. La complexité est corrélée à la densité de défauts. La duplication garantit que les modifications futures seront incohérentes. Un mauvais nommage augmente la charge cognitive pour chaque modification ultérieure. Une mauvaise gestion des erreurs signifie des pannes en production sans piste de diagnostic.

La recherche est sans ambiguïté à ce sujet. Notre propre analyse transdimensionnelle a montré que les architectures de fiabilité en couches ne fonctionnent que lorsque chaque couche attrape les défauts que les couches précédentes ont manqués. Si votre Couche 1 est la vérification de types et votre Couche 2 est les tests, mais que personne ne vérifie si le code est une catastrophe de maintenabilité, vous avez un trou dans votre stack. Et le code généré par IA adore tomber dans ce trou parce que les modèles sont très bons pour générer des implémentations à l’air plausible qui se révèlent être des cauchemars à vivre.

Entre en scène l’outil au nom grossier

Il existe un outil appelé fuck-u-code — oui, vraiment, c’est la commande — et il fait exactement une chose que rien d’autre dans votre pipeline ne fait. Il exécute une analyse de qualité de code déterministe basée sur l’AST, couvrant quatorze langages, et vous dit précisément à quel point votre code est mauvais, en utilisant des métriques qui sont réellement corrélées à des problèmes concrets.

Voici ce qu’il vérifie :

  • Complexité : Scores de complexité cyclomatique et cognitive. Si une fonction comporte dix-sept branches, il le signale.
  • Taille : Nombre de lignes par fichier et par fonction. Le LLM qui a généré une fonction de 250 lignes n’obtient pas de laisser-passer parce que les types sont corrects.
  • Commentaires : Densité et qualité des commentaires. Non pas parce que les commentaires sont vertueux, mais parce qu’une logique complexe sans explication est un piège de maintenance.
  • Gestion des erreurs : Si les erreurs sont attrapées, relancées, journalisées ou silencieusement avalées.
  • Nommage : Qualité des noms de variables et de fonctions. data, temp, handler et process ne passent pas.
  • Duplication : Blocs de code répétés entre les fichiers. Le truc préféré du LLM : copier-coller avec un chercher-remplacer.
  • Structure : Organisation des fichiers et cohésion des modules.

Il produit un score global de 0 à 100. Plus c’est élevé, mieux c’est. Il produit aussi un « shit-gas index » par fichier — plus c’est élevé, pire c’est — pour que vous sachiez exactement quels fichiers nécessitent une attention en priorité. L’analyse s’exécute entièrement hors ligne via l’analyse AST de tree-sitter. Votre code ne quitte jamais votre machine. Elle prend moins d’une seconde sur la plupart des projets.

Et voici la partie qui devrait vous énerver de ne pas l’utiliser déjà : il coûte zéro dollar.

L’outil incarne la philosophie

Ce qui rend fuck-u-code intéressant, ce n’est pas seulement ce qu’il vérifie. C’est la façon dont il est architecturé en interne, parce que l’outil lui-même est un microcosme parfait du pipeline auquel il appartient.

L’outil a deux commandes :

fuck-u-code analyze .          # Deterministic AST analysis. Offline. Fast. Free.
fuck-u-code ai-review . -m gpt-4o   # AI review of the worst-scoring files. API call. Costs tokens.

Remarquez l’ordre. Remarquez la valeur par défaut. L’analyse déterministe s’exécute d’abord, toujours, parce qu’elle ne nécessite pas de clé API, ne coûte pas d’argent et ne varie pas entre les exécutions. L’examen par IA est une deuxième étape optionnelle qui ne regarde que les N fichiers les plus mauvais.

C’est exactement l’architecture que votre pipeline devrait avoir.

Vous n’envoyez pas chaque pull request à Greptile ou Claude Code pour un examen sémantique complet. Ça coûte de l’argent, prend du temps, et — comme nous l’avons établi dans des articles précédents — produit une sortie probabiliste qui peut ou ne peut pas signaler les mêmes problèmes lors d’exécutions consécutives. Vous exécutez d’abord le contrôle déterministe. Vous filtrez les catastrophes structurelles gratuitement, en millisecondes, avec une reproductibilité parfaite. Ensuite, et seulement ensuite, vous envoyez les survivants à un examen par IA coûteux pour l’analyse sémantique, architecturale et comportementale que les outils déterministes ne peuvent pas faire.

fuck-u-code implémente littéralement cela en interne. La commande analyze est votre filtre qualité de Couche 1. La commande ai-review est votre analyse sémantique approfondie de Couche 2. L’outil est une démonstration du principe qu’il permet.

L’argument économique est presque offensant

Parlons d’argent un instant, parce que c’est là que l’état actuel de l’industrie devient véritablement irritant.

Les plateformes d’examen de code par IA facturent par pull request ou par ligne de code examinée. Le coût n’est pas énorme — peut-être un dollar ou deux par PR — mais il est non nul, et il évolue avec la vélocité de votre équipe. Si vous générez du code avec l’IA, votre vélocité est plus élevée qu’elle ne l’était, ce qui signifie que vos coûts d’examen sont aussi plus élevés qu’ils ne l’étaient.

Pendant ce temps, fuck-u-code analysera l’intégralité de votre codebase, couvrant quatorze langages, en moins d’une seconde, et ne vous facturera exactement rien. Il signalera les 20 % de fichiers qui sont véritablement problématiques. Il produira un rapport JSON ou Markdown que votre CI peut consommer. Il fera échouer le build si le score moyen descend en dessous d’un seuil que vous avez configuré.

Si vous exécutez un examen par IA sur chaque PR sans un contrôle qualité déterministe au préalable, vous payez des tokens d’API pour découvrir qu’une fonction est trop complexe. C’est comme embaucher un ingénieur structurel pour vous dire que votre maison est sale. L’ingénieur est qualifié pour le travail, mais vous gâchez son temps et votre argent.

Le pipeline économiquement rationnel est :

  1. L’IA génère du code
  2. Vérification de types, lint et règles d’architecture (votre stack existant)
  3. fuck-u-code analyze (le contrôle qualité manquant — 0 $, <1 s)
  4. Examen par IA (Greptile, etc. — mais seulement sur les fichiers qui ont survécu à l’étape 3, ou seulement lorsque l’étape 3 signale des patterns intéressants)

Ce n’est pas de la théorie. C’est de l’arithmétique. Le contrôle déterministe attrape la classe de problèmes pour laquelle les outils déterministes sont conçus. L’examen par IA attrape la classe de problèmes qui nécessite une compréhension sémantique. Chaque outil fait ce dans quoi il est bon. Personne ne gaspille de tokens pour l’hygiène structurelle.

Intégration MCP : conçu pour le workflow, pas rétroadapté

Il y a un détail de plus qui compte si vous êtes sérieux au sujet du développement assisté par IA.

fuck-u-code embarque un serveur MCP. Si vous utilisez Claude Code, Cursor, ou tout autre outil compatible MCP, vous pouvez invoquer fuck-u-code analyze directement depuis votre agent. L’agent n’a pas besoin de connaître l’analyse AST ou la complexité cyclomatique. Il appelle un outil. L’outil retourne un rapport structuré. L’agent agit en conséquence.

C’est important parce que cela ferme la boucle. La même IA qui a généré le code peut maintenant recevoir un retour déterministe sur la qualité de ce code, dans un format qu’elle peut comprendre et exploiter. L’agent peut voir que le shit-gas index de src/auth/login.ts est de 87 sur 100 et décider de refactor avant qu’un humain ne voie la PR.

Nous avons déjà écrit sur la façon dont la CI est la couche d’enforcement qui rend le développement piloté par spécifications concret. L’intégration MCP signifie que fuck-u-code n’est pas seulement un garde-fou CI. C’est un oracle de qualité accessible aux agents que le pipeline de génération peut consulter en temps réel.

À quoi ressemble réellement l’ajout de l’outil

Vous n’avez pas besoin de plan de migration. Vous avez besoin de cinq minutes.

npm install -g eff-u-code
fuck-u-code analyze .              # See your current scores
fuck-u-code config init            # Generate .fuckucoderc.json

Configurez vos seuils. Choisissez un score global minimum. Choisissez un shit-gas index maximum pour chaque fichier individuel. Ajoutez-le à vos hooks pre-commit :

# .husky/pre-commit
fuck-u-code analyze . --format json --output quality-report.json

Ou ajoutez-le à la CI :

# .github/workflows/quality.yml
- name: Code Quality Gate
  run: |
    npm install -g eff-u-code
    fuck-u-code analyze . --format markdown -o quality.md
    # Parse the JSON and fail if overall score < threshold

Les poids sont configurables. Si votre équipe se soucie plus de la complexité que des commentaires, ajustez les poids des métriques dans .fuckucoderc.json. Si vous voulez exclure les fichiers de test, utilisez --exclude. Si vous voulez voir les 20 fichiers les plus mauvais au lieu des 10 par défaut, utilisez -t 20.

Ensuite, une fois que vous avez filtré les catastrophes structurelles, envoyez les fichiers intéressants à l’examen par IA :

fuck-u-code ai-review . -m gpt-4o -t 5   # Review only the 5 worst files

C’est le pipeline. Générer. Vérifier les types. Contrôler la qualité. Examiner par IA les survivants. Livrer.

La conclusion honnête

Je ne vais pas prétendre que fuck-u-code va résoudre chaque problème de votre codebase. Il ne détectera pas une race condition. Il ne vous dira pas que votre logique d’authentification a une attaque par timing subtile. Il ne remplacera pas le property-based testing, le mutation testing, la vérification formelle ou aucune des autres couches dont nous avons parlé dans des articles précédents.

Ce qu’il fera, c’est détecter les problèmes ennuyeux, prévisibles et coûteux que personne ne détecte actuellement. Il vous dira que votre gestionnaire d’API généré par IA fait 300 lignes et n’a aucune gestion des erreurs. Il vous dira que trois services différents ont copié la même logique de validation. Il vous dira que la moitié de vos variables s’appellent data ou result et que vous devriez en avoir honte.

Ce ne sont pas des cas limites. Ce sont les sorties par défaut d’un pipeline de génération de code rapide qui n’a pas de boucle de retour qualité. Le LLM ne se fatigue pas, mais il ne rougit pas non plus. Il générera du mauvais code avec la même confiance qu’il génère du bon code, et votre stack déterministe actuel le laissera passer parce qu’il n’a pas été conçu pour vérifier la qualité. Il a été conçu pour vérifier la validité.

La validité et la qualité sont des choses différentes. Vous avez besoin des deux.

fuck-u-code n’est pas la réponse complète. C’est la réponse à la question spécifique : « Quel est le moyen le moins cher, le plus rapide et le plus déterministe d’empêcher les ordures structurelles générées par IA d’atteindre l’examen de code ? »

La réponse est : analyser l’AST, noter les métriques, faire échouer le build, et faire réessayer le modèle.

Ça ne coûte rien. Ça prend moins d’une seconde. Et ça bouche un trou dans votre stack de sécurité dont vous ne saviez probablement pas qu’il existait.