Feature flagging : Datadog s’adapte à la génération de code par l'IA
À peine neuf mois après le rachat d’Eppo, Datadog lance la disponibilité générale de sa fonction de feature flagging. Un mouvement qui s’explique par la consolidation du marché de l’observabilité et la résurgence de cette méthode d’A/B Testing, à l’ère du développement propulsé à l’IA générative.
Datadog a annoncé la semaine dernière la disponibilité générale de sa fonctionnalité de feature flagging intégrée à ses outils APM (Application Performance Monitoring) et RUM (Real User Monitoring).
Pour rappel, le feature flagging consiste à baliser une nouvelle fonctionnalité afin de la proposer à une portion des usagers d’une application (A/B test), de suivre son comportement et éventuellement de l’étendre si elle fonctionne ou de la désactiver en cas de problème.
Il y a six ans, les fonctions de feature flagging étaient intégrées par les éditeurs d’outils CI/CD, dans des outils spécifiques ou des suites d’A/B Testing.
Le feature flagging transite des pipelines CI/CD aux plateformes d’observabilité
Or, selon Datadog, cela crée de la friction, car les outils dédiés ne servent qu’à suivre et à activer les balises. La télémétrie peut résider dans plusieurs outils (Monitoring, APM, RUM) si les DevOps n’ont pas recours à une plateforme d’observabilité unifiée.
« Cette fragmentation n’est pas seulement ennuyeuse. Elle est dangereuse », argue Jonathan Fulton, ingénieur logiciel en chef chez Datadog, dans un billet de blog publié sur médium. « Elle ralentit la réponse aux incidents, augmente le temps moyen de résolution et conduit à des mises à jour trop prudentes (lentes) ou pas assez prudentes (risquées) ».
Cette capacité à « lier étroitement les balises aux données de télémétrie » découle du rachat d’Eppo en mai 2025. Fondé en 2021, Eppo a bâti une solution « composable », à partir d’un SDK qui permet de collecter et d’analyser les données à travers les entrepôts de données du marché (Snowflake, BigQuery, Databricks, Redshift). Son interface fait le lien entre une UI de configuration (au besoin), un CDN (Fastly) et une base de code.
Habituellement, Datadog infuse, voire refactorise les briques qu’elle rachète, à la manière de ServiceNow. Ici, son implémentation se rapproche de ce que proposait déjà Eppo. Simplement la configuration du CDN (toujours Fastly) n’est plus nécessaire et les DevOps obtiennent directement des tableaux de bord de données en temps réel. Les métriques telles que les taux d’erreur et les temps de chargement de page sont affichées depuis Datadog, mais il est possible de poursuivre l’analyse sur les DataWarehouse Cloud évoqués plus haut. Les erreurs détectées en temps réel peuvent déclencher des alertes qu’un ingénieur traitera pour savoir s’il faut désactiver la « feature » le temps de réparer le problème. Il est également possible d’établir des seuils qui enclencheront automatiquement l’arrêt de l’A/B test.
L’interface utilisateur de configuration (placement des balises, activation ou désactivation des features flags) ressemble comme deux gouttes d’eau à celle d’Eppo. Il n’est plus nécessaire d’y intégrer les données de télémétrie, Datadog gère cette partie de manière automatique.
Le SDK est décliné dans une version côté client et autre côté serveur. Côté client, il est compatible avec Android, Android TV, iOS, JavaScript, React et tvOS. Côté serveur, la fonctionnalité de Datadog prend en charge .NET, Go, Java, Node.js, Python et Ruby.
Corrélation des données APM et RUM, rollbacks et rollouts automatisés, livraisons progressives, canary testing, garde-fous sont les fonctionnalités principales. Datadog a eu la bonne idée d’ajouter une intégration avec son agent IA avec Bits AI et son serveur MCP afin de laisser les LLM identifier les balises inutilisées – donc des potentielles portions de code mort – et créer les pull requests pour les supprimer. « Tout ingénieur connaît la douleur d’hériter d’une base de code contenant 200 fonctionnalités, dont la moitié n’a pas été touchée depuis deux ans », justifie Jonathan Fulton.
La consolidation du marché et l’IA générative provoquent la résurgence du feature flagging
Datadog n’est pas le seul à prendre cette voie. En janvier, Dynatrace a annoncé le rachat de DevCycle, un spécialiste du feature flagging. Comme Eppo, DevCycle s’appuie sur le projet open source OpenFeature, initié par Dynatrace. À gros traits, il s’agit d’un équivalent à OpenTelemetry pour le feature flagging. « Cela signifie que vous n’êtes pas limité à des API propriétaires – vous pouvez créer des indicateurs avec n’importe quel type de données (booléen, chaîne de caractères, nombre, JSON) et configurer des règles de ciblage à travers différents environnements », explique Jonathan Fulton. Rien de très « flashy », mais une capacité nécessaire pour éviter de créer inutilement de la dette technique.
« Chaque nouvelle variante, indicateur ou chemin de code peut affecter la fiabilité, accroître la complexité et ralentir la livraison si ces éléments ne sont pas correctement gérés ».
Porte-paroleDatadog
Si Datadog et Dynatrace continuent d’étendre leurs fonctionnalités à coup de consolidation, la résurgence du feature flagging correspond au recours de plus en plus fréquent (voire systématique) à des outils d’IA de génération de code.
« Le développement basé sur l’intelligence artificielle a considérablement augmenté le volume et la fréquence des modifications de code qui atteignent la production », affirment les porte-parole de Datadog. « Les équipes déploient désormais davantage de fonctionnalités sur un plus grand nombre de services qu’auparavant. Cette rapidité favorise l’innovation, mais elle engendre également des risques cachés », poursuivent-ils. « Chaque nouvelle variante, indicateur ou chemin de code peut affecter la fiabilité, accroître la complexité et ralentir la livraison si ces éléments ne sont pas correctement gérés ».
Datadog et Dynatrace ne sont pas les seuls à s’être équipés. LaunchDarkly, Amplitude, Harness ou encore Vercel proposent également des fonctions de feature flagging. De son côté, OpenAI a acquis Statsig essentiellement pour couvrir ses besoins internes de développement.
Avant le rachat, Vijaye Raji, cofondateur et CEO de Statsig, considérait que l’ensemble des solutions modernes sur le marché simplifiait grandement un exercice jusqu’alors réservé aux géants comme Netflix, Google ou Meta. Le post publié en réaction du rachat d’Eppo laisse transparaître les raisons qui ont poussé Statsig à accepter l’offre d’OpenAI. Malgré sa réputation d’être cher, Datadog dispose de forces commerciales et de support adaptés aux enjeux des grands comptes. Toutefois, les acteurs comme Databricks, Uber ou Glovo rappellent que le feature flagging demeure une discipline à maîtriser.
