Comment nous avons utilisé l'IA pour nettoyer 200+ feature flags (et l'avons rendu open source)
Eliott Ardisson
Founder & CEO - Basalt Studio
Comment l'IA peut automatiser le nettoyage de vos feature flags obsolètes, réduire la dette technique et redonner de la vélocité à vos équipes de développement.
Points clés
- Les feature flags non supprimés s’accumulent en dette technique silencieuse : chaque flag obsolète multiplie les chemins conditionnels, complique les tests et ralentit le débogage.
- La plupart des équipes savent que leurs flags sont périmés mais ne les suppriment pas par crainte de casser quelque chose. Cette inaction a un coût réel sur la vélocité.
- L’IA peut automatiser la détection, le nettoyage du code et la création de pull requests pour chaque flag obsolète, y compris en parallèle sur plusieurs dépôts.
- Le processus repose sur quatre étapes : détection, validation des références, exécution par agents IA, et revue humaine des PRs générées.
- L’outil que nous avons développé pour ce cas précis a été rendu open source, avec les limitations et pièges que cela implique.
Le problème que personne ne veut toucher
Si vous avez plus d’une dizaine de développeurs et quelques années de codebase, vous avez probablement des feature flags qui n’auraient pas dû survivre à 2023. Certains sont à 100% depuis si longtemps que personne ne sait plus ce qu’ils contrôlaient. D’autres pointent vers des fonctionnalités supprimées depuis. Tout le monde le sait. Personne ne les touche.
Ce n’est pas de la négligence. C’est une décision rationnelle à court terme : le risque perçu de supprimer un flag est toujours supérieur au bénéfice immédiat visible. Résultat : la dette s’accumule jusqu’à ce qu’elle devienne un vrai problème opérationnel.
Un client avec lequel nous travaillions avait dépassé les 200 flags actifs dans sa codebase. Plusieurs dépôts concernés. Certains flags dataient de deux ans. Les incidents prenaient plus longtemps à diagnostiquer parce que les chemins conditionnels imbriqués rendaient la lecture du code difficile. Les nouveaux développeurs passaient un temps anormal à comprendre quels chemins s’appliquaient réellement en production.
C’est ce problème concret qui nous a conduits à construire un outil d’automatisation, puis à le rendre open source.
Ce qu’est réellement la dette des feature flags
Un feature flag est un mécanisme permettant d’activer ou désactiver une fonctionnalité sans déployer du nouveau code. Utile pour les rollouts progressifs, les tests A/B, les accès par segment utilisateur. Le problème n’est pas le flag en lui-même, c’est ce qu’il laisse derrière lui quand on ne le supprime pas.
Quand un flag reste dans le code après que la décision de déploiement est prise et stabilisée, il génère plusieurs types de charge :
- Charge cognitive : les développeurs doivent mentalement évaluer les branches actives quand ils lisent le code.
- Charge sur les tests : chaque flag représente théoriquement deux chemins à tester. Cent flags, c’est une explosion combinatoire.
- Charge sur le débogage : un incident en production peut impliquer une branche conditionnelle que personne n’a regardée depuis des mois.
- Risque de sécurité résiduel : les anciens chemins peuvent contenir des comportements qui ne correspondent plus aux pratiques actuelles.
La dette des feature flags est insidieuse parce qu’elle n’est pas visible dans les dashboards habituels. Elle ne déclenche pas d’alerte. Elle ralentit simplement tout, progressivement.
Pourquoi le nettoyage manuel ne se fait pas
La réponse évidente à ce problème est : supprimez les flags. La réalité, c’est que le nettoyage manuel d’un flag prend du temps et requiert une attention soutenue.
Pour chaque flag, il faut :
- Confirmer son état réel dans le service de feature management (est-il vraiment à 100% partout, depuis combien de temps ?).
- Chercher toutes ses références dans le code, y compris les indirectes.
- Décider quelle branche conserver.
- Supprimer les conditionnels, les imports inutilisés, les fichiers orphelins.
- S’assurer que les tests passent.
- Créer une PR lisible avec un contexte clair pour la revue.
Multiplié par cinquante ou deux cents flags, et distribué sur plusieurs dépôts, c’est plusieurs semaines de travail concentré que très peu d’équipes vont prioriser face aux demandes produit courantes.
L’approche par agents IA : comment ça fonctionne
L’idée centrale est de traiter chaque flag comme une unité de travail indépendante, que l’on peut confier à un agent IA dans un environnement isolé.
Étape 1 : Détection des flags candidats
L’agent se connecte à votre fournisseur de feature flags et identifie les flags qui répondent à des critères d’obsolescence configurables :
- Valeur stable à 0 % ou 100 % depuis plus de 30 jours
- Aucune modification de configuration récente
- Trafic d’évaluation négligeable ou nul
- Aucune règle de ciblage active
Cette liste est présentée pour validation avant que quoi que ce soit ne soit modifié dans le code.
Étape 2 : Cartographie des références
Le système scanne l’ensemble des dépôts cibles pour localiser chaque occurrence du flag. Cela inclut les références directes par nom de string, mais aussi les patterns d’utilisation indirects. Cette étape produit une carte des fichiers à modifier et permet d’estimer l’ampleur du travail.
Étape 3 : Exécution parallèle
Pour chaque flag validé, le système crée un worktree Git isolé et y déploie un agent spécialisé. Chaque agent travaille de manière indépendante sur sa propre branche pour :
- Supprimer les blocs conditionnels liés au flag
- Conserver le chemin d’exécution correct (celui qui correspond à l’état déployé)
- Nettoyer le code mort
- Supprimer les imports et constantes devenus inutiles
- Exécuter la suite de tests
Le parallélisme est ce qui rend l’approche viable à grande échelle. Là où un développeur traite un flag à la fois, le système peut en traiter plusieurs dizaines simultanément.
Étape 4 : Pull requests prêtes pour revue
Chaque agent crée une PR avec un message de commit descriptif, un résumé des changements effectués, et les résultats de l’exécution des tests. La revue humaine reste dans la boucle. L’automatisation prépare le travail ; les développeurs valident avant le merge.
Ce que l’IA gère bien, et ce qu’elle gère mal
Il serait malhonnête de présenter cette approche sans parler de ses limites réelles.
Ce que l’IA gère bien :
- Les suppressions de flags simples dans des fichiers peu couplés
- La suppression d’imports et de code mort évident
- La création de PRs avec un contexte lisible
- La volumétrie : traiter cinquante flags en parallèle sans fatigue
Ce que l’IA gère mal :
- Les flags référencés de manière dynamique via des variables ou des appels indirects. Ce type de référence peut être manqué si le scanning statique n’est pas assez profond.
- Les interdépendances entre flags. Quand flag A contrôle le comportement de flag B, l’ordre de traitement et la logique de décision deviennent complexes.
- La sémantique métier. L’IA peut supprimer le bon chemin de code si la documentation sur l’intention du flag est absente ou ambiguë.
- Les conflits de merge. Quand plusieurs agents modifient les mêmes fichiers en parallèle, des conflits peuvent surgir que le système doit détecter et remonter pour résolution manuelle.
Dans notre travail d’accompagnement des équipes techniques sur ce type de chantier, le point de friction le plus fréquent n’est pas technique. C’est l’absence de documentation sur l’intention des flags. Un flag nommé feature_new_checkout_v2 créé il y a dix-huit mois ne dit pas grand chose sur ce qu’il est censé activer réellement. L’agent peut supprimer le code, mais c’est un humain qui doit confirmer que c’est le bon chemin qui est conservé.
Les pièges à éviter
Nettoyer sans période d’observation
Supprimer un flag à 100% depuis deux semaines est risqué. Deux semaines peut être une période de stabilisation délibérée. La règle des 30 jours de stabilité est un minimum raisonnable, mais certains contextes (conformité, audits, saisonnalité) méritent une période plus longue.
Oublier les services qui dépendent du flag en dehors du dépôt
Un flag peut être référencé dans un service externe, une API publique, ou un outil de configuration que le scan de dépôts ne couvrira pas. Un audit préalable des dépendances externes est indispensable avant toute automatisation à large échelle.
Traiter l’automatisation comme infaillible
Les PRs générées par des agents IA doivent être relues sérieusement, pas juste validées mécaniquement. L’automatisation réduit le travail, elle ne le remplace pas entièrement. Les revues de PRs restent une étape de contrôle réelle.
Négliger la communication interne
Un nettoyage massif de feature flags peut surprendre des membres de l’équipe qui ne savent pas que le chantier est en cours. Des PRs qui touchent des fichiers critiques sans contexte peuvent créer de la friction. Notifier les équipes concernées avant le lancement est une bonne pratique simple.
Se limiter à l’environnement de production
Les flags doivent être nettoyés de manière cohérente dans tous les environnements. Laisser des flags dans staging alors qu’ils ont été supprimés en production crée des divergences qui compliquent les déploiements futurs.
Quand automatiser, quand faire manuellement
L’automatisation n’est pas toujours la bonne réponse. Elle devient pertinente quand la volumétrie dépasse ce que l’effort manuel peut absorber sans détourner l’équipe de son travail produit.
Un nettoyage manuel trimestriel est suffisant si :
- Votre équipe crée moins de cinq flags par mois
- Votre codebase compte moins de cinquante flags actifs
- Vous n’avez qu’un ou deux dépôts à gérer
L’automatisation devient intéressante quand :
- Vous avez plusieurs dizaines de flags actifs répartis sur plusieurs dépôts
- Votre cadence de création de flags est élevée et génère régulièrement de nouveaux candidats à la suppression
- Le temps développeur nécessaire pour un nettoyage manuel représente plusieurs sprints de travail
La décision n’est pas binaire. Une approche hybride fonctionne bien : automatiser la détection et la préparation des PRs, garder la validation et le merge sous contrôle humain.
Ce que nous avons rendu open source, et pourquoi
L’outil que nous avons développé pour ce chantier a été publié en open source parce que le problème est suffisamment répandu pour mériter une base commune plutôt que de forcer chaque équipe à repartir de zéro.
Il est conçu pour fonctionner avec les providers de feature flags les plus courants, s’intègre avec Git via des worktrees isolés, et génère des PRs formatées prêtes pour revue. Il s’appuie sur l’API Claude d’Anthropic pour les décisions de transformation de code, orchestré via n8n pour la gestion des flux et du parallélisme.
L’outil est utile tel quel pour des équipes avec une expertise technique interne suffisante pour l’adapter à leur contexte. Il n’est pas clé en main. Il faut le configurer, le connecter à vos outils, et probablement l’ajuster selon la structure de votre codebase.
Mesurer l’impact réel
Au-delà de compter les flags supprimés, les métriques qui valent vraiment la peine d’être suivies sont :
- Complexité cyclomatique moyenne par fichier : une métrique d’analyse statique qui devrait baisser significativement après un nettoyage sérieux.
- Temps moyen de résolution d’incident : un code plus linéaire est plus rapide à déboguer.
- Temps de build : moins de code à compiler et à analyser se traduit généralement par des builds plus rapides, particulièrement visible sur les grosses codebases.
- Couverture de tests effective : avec moins de branches mortes, la couverture réelle des chemins actifs augmente.
Ces métriques donnent une base objective pour évaluer si le nettoyage a eu l’effet attendu sur la santé du code.
Prochaine étape si vous reconnaissez ce problème
Commencez par un inventaire rapide : listez vos flags actifs, identifiez ceux qui sont stables depuis plus de trente jours, et estimez le temps qu’il faudrait pour les nettoyer manuellement. Ce chiffre seul est souvent suffisant pour justifier d’explorer une approche automatisée.
Si vous voulez aller plus loin, le dépôt open source est un bon point de départ pour les équipes avec la capacité technique de l’intégrer. Pour les équipes qui préfèrent ne pas investir ce temps en interne, une conversation avec nous peut clarifier ce qu’une implémentation accompagnée représente concrètement.
La dette des feature flags se règle. Elle demande juste une approche méthodique et les bons outils.
Si vous voulez discuter de votre situation spécifique et voir comment une approche automatisée pourrait s’appliquer à votre codebase, vous pouvez réserver un appel stratégie IA directement ici : https://cal.com/eliott-ardisson-kzq7zs/ai-strategy-call