PostHog

PostHog expose un large éventail d'objets : événements, personnes, feature flags, expériences, sondages, enregistrements de sessions, cohortes et tableaux de bord. La grande majorité de ces données concerne le comportement des utilisateurs finaux — ce que les clients font dans le produit — et ne peut pas être attribuée à un membre de l'équipe interne spécifique. Cette intégration est limitée aux trois types d'objets pour lesquels une attribution individuelle existe : les feature flags, les expériences et les sondages. Quatre KPIs ont été retenus, sélectionnés selon les mêmes critères appliqués à toutes les intégrations : capacité d'attribution à un propriétaire, résistance au gaming et équilibre entre indicateurs avancés et retardés.

Livraison progressive et cadence d'expérimentation

Feature Flags Launched mesure le nombre de flags actifs et non supprimés qu'un membre de l'équipe a introduits. Experiments Started mesure le nombre d'expériences en cours qu'il a initiées. Experiments Completed mesure le nombre de ces expériences qui ont atteint une conclusion — complète ou arrêtée — plutôt que d'être laissées indéfiniment ouvertes. Ces trois indicateurs décrivent un cycle complet de développement piloté par la donnée : proposer un mécanisme de livraison sécurisé, formaliser une hypothèse et conduire cette hypothèse jusqu'à une décision.

La tension entre Experiments Started et Experiments Completed est structurellement importante. Un ingénieur qui lance régulièrement des expériences sans jamais les conclure accumule des hypothèses ouvertes sans produire de décisions. Lu isolément, un score élevé d'Experiments Started paraît favorable ; associé à un score faible d'Experiments Completed, il révèle un carnet d'expériences en souffrance et un échec à fermer la boucle d'apprentissage. Feature Flags Launched renforce cette lecture : un membre de l'équipe qui lance des flags sans les relier à des expériences livre peut-être de manière incrémentale, mais ne mesure pas les résultats. Les trois indicateurs ensemble distinguent l'adoption superficielle de l'outillage d'une véritable pratique pilotée par les hypothèses.

Collecte de retours utilisateurs

Surveys Launched mesure le nombre de sondages qu'un membre de l'équipe a activement déployés — en distinguant ceux créés mais non lancés, ou archivés. Lancer un sondage est un acte délibéré : il implique une question utilisateur définie, une décision de ciblage et un engagement à agir sur les réponses. Un chef de produit ou un ingénieur produit qui lance régulièrement des sondages ferme systématiquement la boucle de rétroaction entre les décisions produit et la réalité des utilisateurs. Ce KPI est moins fréquent que les indicateurs d'expérimentation — la plupart des membres de l'équipe lanceront un petit nombre de sondages par trimestre — mais sa présence garantit que l'activité de recherche utilisateur est visible aux côtés de la cadence de livraison et d'expérimentation.

Périmètre et limites de l'intégration

Les données principales de PostHog — volumes d'événements, taux de conversion de tunnels, courbes de rétention, enregistrements de sessions — ne sont pas incluses dans cette intégration. Ces métriques décrivent la performance produit au niveau de l'entreprise et ne peuvent pas être attribuées à un membre de l'équipe individuel via l'API. Les inclure nécessiterait un proxy (comme affecter une fonctionnalité à un propriétaire et lui attribuer les analyses en aval), ce qui introduit une chaîne d'attribution suffisamment longue pour perdre en fiabilité. L'intégration est délibérément étroite : elle mesure dans quelle mesure un membre de l'équipe utilise activement l'outillage propre de PostHog, et non ce que le produit accomplit en résultat.

L'attribution est également limitée au moment de la création. Le propriétaire d'un feature flag ou d'une expérience est la personne qui l'a créé ; si la propriété change informellement, PostHog n'enregistre pas ce changement. Un membre de l'équipe qui hérite d'un projet en cours ne recevra pas de crédit pour les expériences ou les flags qu'il n'a pas créés, même s'il a effectué l'essentiel du travail opérationnel. Comme pour toutes les intégrations, la fiabilité de ces KPIs dépend directement de la régularité avec laquelle l'équipe utilise PostHog : une équipe qui centralise les livraisons de fonctionnalités et les expériences via la plateforme génère un signal significatif ; une équipe qui l'utilise de manière sélective produit des données qui reflètent l'adoption de l'outil autant que la pratique réelle de développement.