Fallow mesure, l'IA bâtit

Les agents IA écrivent désormais une large part du code de mes projets. Ils livrent vite et bien, avec une tendance constante à enrichir l'existant plutôt qu'à créer un nouveau concept. Au fil des demandes, une fonction de 20 lignes en compte 100, un fichier de 100 lignes en compte 500, et les noms ne décrivent plus qu'une partie de ce qu'ils contiennent.

Fallow corrige cette dérive avec une efficacité redoutable. Avant chaque commit, mon agent exécute Fallow pour mesurer les fonctions et les fichiers du projet. Tant que le verdict n'est pas vert, il découpe. Cette procédure garantit un code composé de petites fonctions, rangées dans des fichiers à responsabilité unique, dont le nom dit exactement ce qu'ils font.

Fallow en bref

Fallow est un analyseur statique open source pour TypeScript et JavaScript, distribué sous licence MIT sous la forme d'un binaire Rust unique. Il construit un graphe complet du dépôt (modules, exports, dépendances, fonctions) et en tire quatre familles d'analyses :

• Complexité : Mesure de la complexité cyclomatique et cognitive de chaque fonction, score de maintenabilité de chaque fichier et note de santé du projet sur 100.
• Code mort : Détection des fichiers, exports, types et dépendances que plus rien n'utilise.
• Duplication : Repérage des blocs copiés d'un fichier à l'autre, dans le code TypeScript et JavaScript comme dans les feuilles de style et les composants d'interface.
• Architecture : Contrôle du découpage des imports (interface, métier, données) et détection des dépendances circulaires.

L'analyseur n'embarque aucun modèle de langage : la même entrée produit toujours le même résultat. Il s'exécute seul, sans compilateur TypeScript ni runtime Node.js. Selon les mesures publiées par le projet, il est capable d'analyser un dépôt aussi volumineux que le monorepo de Next.js (20 558 fichiers) en moins de 3 secondes.

Ce déterminisme en fait le bon partenaire d'un agent IA : l'agent propose, Fallow mesure.

Un arbitre dans la boucle de l'agent

Au rythme des agents, je ne relis plus chaque ligne une à une. Demander à un agent « d'écrire du code simple » ne permet pas de s'assurer que la contrainte est respectée.

Fallow devient le garde-fou de chaque commit. Le schéma ci-dessous montre la boucle que suit l'agent pour chaque tâche :

Le découpage s'opère à deux échelles :

• Fonction : Seuils par défaut de 20 en complexité cyclomatique, 15 en complexité cognitive et 60 lignes par fonction, que je conserve tels quels.
• Fichier : Score de maintenabilité calculé à partir de la taille, de la densité de complexité, du code mort et des dépendances, et recommandations classées par priorité, comme « scinder un fichier dont trop d'autres dépendent » ou « extraire la fonction parseRow d'un fichier de 520 lignes ».

Fallow ne dit pas comment corriger : il désigne ce qui est trop long, trop imbriqué, trop central ou répété, et laisse à l'agent le soin de découper et ranger.

Retour d'expérience

J'ai codé un petit bot en TypeScript qui réserve automatiquement mes séances de sport, dont les places partent en quelques minutes. Une fois stabilisé, j'ai confié le projet à un agent IA pour qu'il l'intègre à Home Assistant, avec une interface graphique, des réservations pilotables et des notifications sur le téléphone.

L'agent a livré rapidement un projet fonctionnel, mais chaque évolution s'était greffée sur le code existant. Une seule fonction contenait la connexion à l'API, la récupération du planning, le choix du créneau puis la réservation, et toute l'interface tenait dans un seul fichier.

Une fois Fallow branché, l'agent a isolé chaque étape métier dans une fonction dédiée, avec un nom qui dit ce qu'elle fait. Il a ensuite appliqué le même découpage par responsabilité à l'échelle des fichiers.

Le résultat se mesure sur trois parties du projet :

• Réservation : La fonction principale passe de 88 à 28 lignes et délègue la connexion, le planning, le choix du créneau et la réservation à 4 fonctions nommées d'après leur étape.
• Interface : Le fichier App.tsx passe de 501 à 116 lignes, réparti en 7 composants réutilisables, un fichier de types partagés et un hook dédié.
• Notifications : L'envoi des notifications, écrit 3 fois, n'existe plus qu'à un seul endroit sous le nom notifyBookingSuccess.

Une source de vérité pour cadrer l'agent

Un agent IA intervient sur un projet comme le ferait un développeur. Il cherche le bon fichier, lit ce qui l'entoure et modifie ce qu'il comprend. Un projet généré prompt après prompt, sans jamais être refactoré, accumule dès les premières demandes les traits d'un code spaghetti : fichiers aux responsabilités mêlées, noms approximatifs, logique dupliquée. Dans ce contexte, trouver le bon fichier oblige l'agent à en lire davantage, et modifier ce qu'il comprend ne suffit plus, car les effets de bord se multiplient.

Fallow inverse cette pente sans exiger une expertise en architecture logicielle. Les règles de découpage, de nommage et de rangement sont mesurées et le verdict s'impose à l'agent, sans qu'il faille les détailler dans chaque prompt ni les contrôler à la relecture. Le bénéfice se lit sur trois plans :

• Moins de régressionsDes fonctions courtes et des fichiers à responsabilité unique, où chaque modification reste circonscrite à la partie concernée.
• Moins de jetonsUne navigation guidée par des noms explicites, sans relecture de fichiers entiers pour trouver la bonne ligne.
• Plus de maîtriseUn critère objectif et reproductible pour valider le travail de l'agent, là où une consigne en langage naturel reste invérifiable.

Confiez Fallow à votre agent. À chaque commit, il découpe, nomme et range le code sans que vous ayez à lui dicter chaque règle. Vous gardez un projet lisible, moins coûteux à faire évoluer, et chaque nouvelle demande part d'une base saine. La qualité ne se décrète plus, elle se vérifie.

• Fallow sur GitHub
• Documentation