Nettoyer les feature flags obsolètes

Cette skill vous guide dans la recherche de feature flags qui ne servent plus à rien et leur suppression sécurisée.

Quand utiliser cette skill

• L'utilisateur demande de nettoyer, auditer ou examiner ses feature flags
• L'utilisateur veut trouver des flags obsolètes, inutilisés ou entièrement déployés
• L'utilisateur demande « quels feature flags puis-je supprimer ? » ou similaire
• L'utilisateur veut réduire la dette technique des anciens feature flags

Ce qui rend un flag obsolète

Un feature flag est considéré comme obsolète quand il ne fait plus de travail utile. PostHog détecte cela avec deux signaux :

1. Obsolescence basée sur l'utilisation : Le flag a des données last_called_at, mais n'a pas été évalué depuis 30+ jours. C'est le signal le plus fort — les SDKs ne vérifient plus ce flag.
2. Obsolescence basée sur la configuration : Le flag n'a pas de données d'utilisation (last_called_at est null), a plus de 30 jours, et est déployé à 100% (booléen à 100% sans filtres de propriété, ou un flag multivarié avec une variante à 100%). Un flag entièrement déployé sans conditions équivaut à une valeur en dur — il peut être remplacé en supprimant la vérification du flag du code.

Les flags désactivés (active: false) ne sont pas considérés comme obsolètes — ils ont été intentionnellement arrêtés et peuvent être conservés pour une réactivation.

Flux de travail

1. Lister les flags obsolètes

Appelez posthog:feature-flag-get-all avec active: "STALE". Cela retourne tous les flags obsolètes en une seule requête — PostHog gère la détection de l'obsolescence côté serveur selon les critères décrits ci-dessus.

2. Évaluer chaque candidat

Pour chaque flag obsolète, rassemblez le contexte avant de recommander une action :

Vérifiez s'il est lié à une expérience :

L'outil posthog:feature-flag-get-definition retourne un champ experiment_set. S'il n'est pas vide, le flag est utilisé par une expérience — vérifiez le statut de l'expérience avant de le toucher.

Vérifiez si d'autres flags en dépendent :

Les feature flags peuvent avoir des dépendances (le flag B s'évalue uniquement si le flag A est vrai). La définition du flag inclut les informations de dépendance dans ses filters. Cherchez les références flag_key dans les groupes de filtres d'autres flags.

Vérifiez quand il a été modifié pour la dernière fois :

Un flag mis à jour il y a des années sans appels récents est un meilleur candidat à la suppression qu'un flag modifié le mois dernier sans appels (il pourrait être nouvellement déployé et en attente d'une version).

Résumé pour l'utilisateur :

Pour chaque flag obsolète, présentez :

• Clé du flag et description
• Pourquoi il est considéré comme obsolète (pas d'appels depuis N jours, ou entièrement déployé depuis N jours)
• S'il est lié à des expériences
• Quand il a été créé et modifié pour la dernière fois
• Une action recommandée (nettoyer du code et désactiver, ou conserver avec explication)

3. Générer les instructions de nettoyage du code

Générez un prompt de nettoyage que l'utilisateur peut exécuter dans son éditeur de code ou agent de codage. Les instructions de nettoyage doivent être adaptées à l'état de déploiement de chaque flag, car cet état détermine quel chemin de code conserver. Cette liste sert aussi de checklist d'approbation — si l'utilisateur dit que son code est déjà nettoyé, il le vérifie et confirme quels flags désactiver.

Classifiez chaque flag dans l'un de ces trois états de déploiement selon sa définition :

• fully_rolled_out : Un flag booléen avec une condition de release à 100% sans filtres de propriété, ou un flag multivarié où une variante est à 100%. Enregistrez quelle variante était active (pour les flags multivariés).
• not_rolled_out : Toutes les conditions de release sont à 0%, ou le flag n'a aucune condition de release.
• partial : Tout le reste — le flag avait du targeting mais n'était pas entièrement déployé ou entièrement arrêté.

Puis générez les instructions en suivant cette structure :

Pour les flags booléens entièrement déployés — supprimez la vérification du flag mais gardez le chemin de code activé :

Cherchez : isFeatureEnabled, useFeatureFlag, getFeatureFlag, posthog.isFeatureEnabled, posthog.getFeatureFlag

Pour le flag « example-flag » :
- Supprimez la vérification if, gardez le corps
- S'il y a une branche else, supprimez-la entièrement

Pour les flags multivariés entièrement déployés — gardez uniquement le code de la variante gagnante :

Pour le flag « example-flag » (garder variante : « winning-variant ») :
- Pour les chaînes if/else : gardez uniquement la branche correspondant à « winning-variant », supprimez la vérification du flag
- Pour les switch : gardez uniquement le cas de la variante gagnante, supprimez le switch

Pour les flags non déployés — supprimez la vérification entière du flag ET le chemin de code activé :

Pour le flag « example-flag » :
- Supprimez la vérification if ET son corps (la fonctionnalité n'a jamais été active)
- S'il y a une branche else, gardez uniquement le corps else

Pour les flags partiellement déployés — signalez-les pour examen manuel :

Pour le flag « example-flag » :
- Ce flag avait un déploiement partiel — vérifiez l'intention du flag pour déterminer quel chemin de code garder
- Puis supprimez la vérification du flag

Terminez les instructions par : « Après le nettoyage, supprimez les branches de code mort et les imports inutilisés. »

Présentez le prompt de nettoyage complet dans un format copiable pour que l'utilisateur puisse le coller directement dans Claude Code, Cursor, Copilot ou tout autre éditeur de code IA.

4. Désactiver les flags après le déploiement des modifications de code

Ne désactivez jamais les flags avant que les modifications de code ne soient déployées. Désactiver un flag entièrement déployé pendant que du code le vérifie causera l'arrêt de ce chemin de code — une régression en production.

Ne désactivez jamais les flags sans approbation explicite de l'utilisateur. Présentez toujours la liste et les recommandations d'abord, puis demandez quels flags traiter.

Présentez à l'utilisateur les deux options et leurs compromis :

• Désactiver (active: false) via posthog:update-feature-flag : Le flag arrête d'être évalué mais la configuration est préservée. Si quelque chose était manqué dans le nettoyage du code, la réactivation est instantanée. Recommandé par défaut.
• Supprimer via posthog:delete-feature-flag : Une suppression logicielle — le flag est marqué comme supprimé mais pas physiquement retiré. Garde la liste des flags propre, mais la réactivation nécessite de recréer le flag. Mieux pour les flags dont l'utilisateur est certain de ne jamais avoir besoin.

Une fois que l'utilisateur a choisi et confirme que ses modifications de code sont déployées, appliquez l'action choisie un flag à la fois. Confirmez chaque action pour qu'il soit facile d'arrêter si quelque chose ne va pas.

Exemple d'interaction

Utilisateur : « Pouvez-vous m'aider à nettoyer nos feature flags obsolètes ? »

Étapes de l'agent :
- Appelez posthog:feature-flag-get-all avec active: "STALE" pour obtenir tous les flags obsolètes en une requête
- Pour chaque flag obsolète, appelez posthog:feature-flag-get-definition pour vérifier experiment_set et les dépendances
- Présentez les résultats :

   « J'ai trouvé 7 feature flags obsolètes dans votre projet :

   | Flag | Dernier appel | Raison | Recommandation |
   |------|-------------|--------|----------------|
   | old-checkout-flow | Il y a 45 jours | Pas d'évaluation depuis 45 jours | Nettoyer et désactiver |
   | beta-dashboard-v2 | Jamais | 100% déployé, créé il y a 3 mois | Nettoyer et désactiver |
   | holiday-promo-2024 | Il y a 90 jours | Pas d'évaluation depuis 90 jours | Nettoyer et désactiver |
   | new-pricing-page | Il y a 60 jours | Pas d'évaluation depuis 60 jours, lié à l'expérience #42 | Vérifier d'abord l'expérience |
   ...

   Voulez-vous que je génère des instructions de nettoyage pour certains d'entre eux ? Je recommande
   de commencer par old-checkout-flow et beta-dashboard-v2 car ils n'ont pas de dépendances. »

- L'utilisateur confirme : « Oui, fais old-checkout-flow et beta-dashboard-v2 »
- Classifiez les états de déploiement à partir des définitions des flags :
   - old-checkout-flow: fully_rolled_out (booléen, 100% déployé, pas de conditions)
   - beta-dashboard-v2: fully_rolled_out (booléen, 100% déployé, pas de conditions)
- Générez et présentez le prompt de nettoyage :

   « Voici un prompt de nettoyage que vous pouvez coller dans votre éditeur de code :

   ---
   Trouvez et supprimez toutes les références à ces feature flags du code source.
   Pour chaque flag, recherchez tous les usages : isFeatureEnabled, useFeatureFlag,
   getFeatureFlag, posthog.isFeatureEnabled, posthog.getFeatureFlag, etc.

   ## Flags qui ont été déployés à 100%
   Ces flags ont été entièrement déployés. Supprimez la vérification du flag mais GARDEZ le chemin de code activé.

   Flags booléens (supprimez la vérification if, gardez le corps) :
   - old-checkout-flow
   - beta-dashboard-v2

   S'il y a une branche else, supprimez-la entièrement.
   Après le nettoyage, supprimez les branches de code mort et les imports inutilisés.
   ---

   Une fois que vous avez nettoyé votre code et déployé, faites-le moi savoir.
   Voulez-vous désactiver ou supprimer ces flags ?
   - Désactiver (recommandé) : garde la config, la réactivation est instantanée
   - Supprimer : supprime de la liste, mais vous devriez recréer si nécessaire »

- L'utilisateur confirme : « Désactive-les, le code est déployé »
- Désactivez chaque flag en utilisant posthog:update-feature-flag (active: false)
- Confirmez : « Les deux flags sont maintenant désactivés dans PostHog. »

Notes importantes

• Code d'abord, puis désactiver. Désactiver un flag pendant que du code le référence cause l'arrêt silencieux du chemin de code activé. Toujours nettoyer le code et déployer avant de désactiver.
• Préférez désactiver à supprimer. Désactiver est instantanément réversible. La suppression ne l'est pas — la réactivation nécessite de recréer le flag. Toujours présenter les deux options avec compromis et laisser l'utilisateur choisir.
• Toujours confirmer avant d'agir. Cette skill implique de désactiver des flags, ce qui peut affecter le comportement en production. Ne jamais désactiver sans approbation explicite de l'utilisateur.
• Les flags désactivés ne sont pas obsolètes. Ne recommandez pas de désactiver les flags déjà intentionnellement désactivés — ils peuvent être conservés pour une réactivation d'urgence.
• Les flags d'expérience nécessitent une attention particulière. Si un flag est lié à une expérience active ou récemment terminée, l'utilisateur veut probablement le garder jusqu'à avoir analysé les résultats.
• Les flags saisonniers peuvent réapparaître. Des flags comme « black-friday-sale » peuvent sembler obsolètes mais sont intentionnellement réutilisés. Demandez à l'utilisateur avant de les supprimer.
• Le nettoyage du code est la vraie victoire. Supprimer le flag de PostHog est la partie facile. La valeur vient de la suppression des chemins de code mort.

Outils connexes

• posthog:feature-flag-get-all : Lister et chercher des feature flags (supporte le filtre active: "STALE")
• posthog:feature-flag-get-definition : Obtenir les détails complets du flag incluant les associations d'expériences
• posthog:feature-flags-status-retrieve : Obtenir le statut et la raison d'un flag unique
• posthog:update-feature-flag : Désactiver un flag en définissant active: false
• posthog:delete-feature-flag : Suppression logicielle d'un flag