Comment l'IA redéfinit les métiers de l'expérimentation, une étude de Speero

Étude réalisée à partir de 19 entretiens approfondis menés auprès de praticiens seniors de l’expérimentation afin d'explorer l'état actuel et les perspectives de l'expérimentation assistée par l'IA, à travers une nouvelle génération d'outils tels que PBX (Prompt-based Experimentation).

Par Jonny Longden, Chief Growth Officer chez Speero

Étude sponsorisée par Kameleoon 

Vous préférez le format vidéo ? Retrouvez la conversation de 40 minutes entre Jonny Longden et Katie Green (Kameleoon), dans laquelle ils reviennent sur les principaux enseignements de cette étude.

‍

Synthèse

La vraie question n'est plus de savoir si l'IA remplacera les développeurs.

La création de variations assistée par l'IA constitue sans doute l'évolution la plus marquante qu'aient connue les plateformes d'A/B testing au cours des dix dernières années. Dès les premières démonstrations, tous les experts interrogés ont eu la même réaction : voir une simple instruction en langage naturel se transformer instantanément en une modification appliquée sur une page réelle est particulièrement frappant.

Au départ, cette étude cherchait à répondre à une question simple : « l'IA peut-elle remplacer les développeurs dans l'A/B testing ? ».

Après dix-neuf entretiens approfondis, il s’est avéré que ce n'était pas la bonne question.

La vraie question est ailleurs : comment l'IA redéfinit-elle les profils capables de créer des expérimentations et comment transforme-t-elle le rôle de celles et ceux qui en avaient jusqu'ici la responsabilité ?

Les outils de génération de variations par IA élargissent concrètement le nombre de personnes capables de lancer des tests. Ils font disparaître un goulot d'étranglement historique : jusqu'à présent, seuls les projets disposant de ressources techniques suffisantes ou d'un fort soutien interne pouvaient être développés. Désormais, de nombreuses idées qui n'auraient jamais trouvé leur place dans une roadmap deviennent réalisables.

Dans le même temps, les développeurs peuvent se concentrer sur les sujets qui nécessitent réellement leur expertise. Les variations gagnantes sont ensuite déployées proprement en production grâce à des solutions comme PBX Ship de Kameleoon.

Au-delà de la technologie, cette évolution soulève une question fondamentale pour l'avenir de l'expérimentation : que deviennent les programmes d'expérimentation lorsque leur principal goulot d'étranglement disparaît ? Et surtout, qui peut désormais pratiquer cette discipline ?

‍

Ce que cette étude est… et ce qu'elle n'est pas

Dix-neuf praticiens seniors. Des premières impressions. Une mise en situation concrète et intensive.

La plupart des dix-neuf sessions avaient pour objectif de recueillir une première impression de PBX, plutôt que d'observer des utilisateurs déjà expérimentés. Chaque praticien a disposé de deux heures pour créer des variations sur son propre site, rédiger et affiner des prompts, évaluer les résultats obtenus, puis partager son retour d'expérience.

Un seul participant, Chris Strobl (Cedars-Sinai), est client Kameleoon et utilise PBX en production depuis sept à huit mois, y compris PBX 2.0. Lorsque ses observations reposent sur cette expérience de long terme plutôt que sur une première prise en main, cela est indiqué explicitement.

Kameleoon a lancé PBX 2.0 au cours de l'étude. Les praticiens comme moi-même avons principalement travaillé avec la version précédente. Le rapport précise donc systématiquement les points sur lesquels PBX 2.0 confirme, enrichit ou fait évoluer les constats présentés.

Transparence : une étude sponsorisée

Cette étude a été financée par Kameleoon, qui a également fourni l'accès à PBX. L'entreprise a demandé une évaluation indépendante et non un argumentaire commercial, sans intervenir dans les conclusions.

Lorsque le rapport décrit des fonctionnalités propres à PBX, cela est indiqué explicitement. À l'inverse, lorsque les observations portent sur les capacités générales des outils de génération de variations assistée par l'IA, elles concernent l'ensemble de cette nouvelle catégorie de solutions.

‍

Comment fonctionne PBX, concrètement

Une extension de navigateur qui agit directement sur votre site

PBX fonctionne comme une extension de navigateur. Il suffit d'ouvrir une page et de décrire la modification souhaitée en langage naturel. PBX analyse automatiquement son contexte (DOM, CSS, structure et captures d'écran), génère le JavaScript et le CSS nécessaires, affiche une prévisualisation directement sur la page en production, puis fournit le code correspondant.

Contrairement à un prototype créé dans un environnement distinct, la variation est construite directement sur la page en production. Elle peut ensuite être déployée telle quelle depuis la plateforme Kameleoon, avec le feature flagging, le ciblage d'audience et le suivi des événements.

À l'inverse, des outils généralistes comme Claude ou Lovable peuvent produire un prototype convaincant, mais celui-ci reste déconnecté du site. Il doit ensuite être recréé avant de pouvoir être testé en conditions réelles. C'est cette différence d'architecture qui distingue cette nouvelle catégorie d'outils.

De l'idée au test en ligne : des semaines deviennent des minutes.

Le processus est simple : vous décrivez la modification souhaitée (« Remplace le CTA par Trouver des vols »), PBX analyse la page, génère la variation et l'applique instantanément sur le site en production. Cette même variation devient ensuite le test, sans étape de reconstruction.

C'est là le changement fondamental. Avec PBX, la variation est déjà le test. Là où un prototype généré par un assistant IA généraliste doit encore être recréé avant d'être déployé, PBX transforme directement une idée en expérimentation exploitable, au sein d'un workflow continu.

‍

Les bénéfices auxquels les praticiens tiennent vraiment

Pas forcément ceux mis en avant par les éditeurs. Lors des entretiens, les bénéfices évoqués spontanément ne concernaient ni la vitesse d'exécution ni la réduction des coûts. Ces sujets ont bien été abordés, mais ils n'étaient jamais au cœur des échanges. Une autre notion revenait systématiquement : l’accès aux ressources nécessaires pour tester.

Le véritable goulot d'étranglement : le temps des développeurs

Tous les participants, y compris ceux travaillant au sein de grandes organisations dotées d'importantes équipes d'ingénierie, ont décrit le même constat : obtenir du temps de développement pour lancer un test est aujourd'hui plus difficile qu'il y a trois ans. La file d'attente ne s'est pas réduite ; elle s'est allongée. Le temps des développeurs est devenu une ressource rare.

« WGU est passée par un retour au présentiel obligatoire. Les ressources de développement sont devenues très rares. Faire passer un test dans la file d'attente dev prend un temps considérable. Dès que c'est possible, je construis moi-même ce que je peux. Si je dois passer par les devs, cela peut prendre jusqu'à huit semaines. »

‍Whitney Norton · Testing and Optimization Manager · Western Governors University

Quels tests finissent réellement par être lancés. Tous les responsables CRO interrogés disposaient d'un backlog d'idées prometteuses, mais insuffisamment prioritaires pour justifier un sprint de développement. Ces expérimentations restaient donc au stade de l'idée.

Les outils de création de variations par l'IA changent discrètement cette équation. Lorsque le coût de mise en œuvre devient suffisamment faible, une idée n'a plus besoin de convaincre toute une organisation avant d'être testée.

« J'ai eu beaucoup d'idées au fil des années qui n'enthousiasmaient personne. Avant, je devais d'abord gagner en crédibilité et instaurer un climat de confiance pour convaincre les parties prenantes de tenter ces approches un peu atypiques. Aujourd'hui, je peux réaliser une grande partie de ces tests moi-même. La moitié du temps, je n'ai même pas besoin de les pitcher. » 

‍Ben Young · CRO chez HubSpot

Réaffectation, pas remplacement.Ce changement ne remplace pas les développeurs ; il redistribue leur travail. Les ingénieurs peuvent désormais se concentrer sur les expérimentations les plus complexes, tandis que les équipes CRO prennent en charge une grande partie des variations plus simples.

« Avant, tout le code était écrit par l'équipe de développement. Aujourd'hui, grâce à l'IA, j'écris moi-même l'essentiel du code. Les développeurs ne prennent plus que les tests difficiles. » 

‍Ben Young · CRO chez HubSpot

Une meilleure adhésion des parties prenantes. Un autre bénéfice est revenu de façon récurrente : la possibilité de présenter une idée directement sur le site réel, pendant une réunion.

Au lieu de montrer une maquette statique ou un wireframe, les équipes présentent une version fonctionnelle avec laquelle les parties prenantes peuvent interagir. Surtout, cette démonstration constitue déjà la base du futur test : il ne s'agit pas d'un prototype qu'il faudra reconstruire par la suite.

« Pouvoir manipuler quelque chose en temps réel et dire : voilà, c'est un projet fonctionnel, c'est à peu près ce que nous avons en tête, quelque chose de réellement intégré au site plutôt qu'un bricolage assemblé à la va-vite. Je vois vraiment l'utilité de cela. » 

‍Faith Dallas · Digital Experimentation Manager · New Look

Ce qu’il faut retenir. Le principal goulot d'étranglement que ces outils éliminent n'est pas celui que l'on imagine. Les praticiens ont davantage parlé d'accès que de vitesse.

L'accélération de la création des variations n'est que la conséquence la plus visible. Le changement le plus profond est ailleurs : davantage d'idées franchissent enfin le cap de l'expérimentation et davantage de personnes au sein de l'organisation peuvent désormais contribuer à leur mise en œuvre.

‍

Ce qui rend cela possible : le contexte

Pourquoi les praticiens préfèrent PBX à un outil comme Claude Code 

Au fil des entretiens, une question est revenue à plusieurs reprises, explicitement ou non : pourquoi utiliser un outil spécialisé comme PBX lorsqu'on dispose déjà de Claude Code, Cursor ou GitHub Copilot ? La réponse qui s'est imposée est simple : le contexte.

« Ce que PBX cherche à faire, c'est précisément ce qui nous manquait avec les autres outils : le contexte. » 

‍Senior Optimisation Manager · Profil développeur · Grande compagnie aérienne

PBX 2.0 élargit considérablement le contexte disponible à l’IA

Au cours de l'étude, Kameleoon a lancé PBX 2.0. Cette nouvelle version enrichit encore le contexte mis à disposition de l'IA grâce à deux évolutions majeures : l'intégration des modes de design Figma de la marque et un Master Prompt administrable, dans lequel peuvent être définis le design system, les règles d'accessibilité, le tone of voice et les contraintes techniques propres au site.

L'outil ne se contente plus de générer du code plus rapidement : il sait déjà comment votre site est censé fonctionner et à quoi il doit ressembler.

Un utilisateur de PBX 2.0 en production décrit concrètement ce changement :

« Avec PBX 2.0, l'outil comprend une bien plus grande partie de votre site, pas seulement une page isolée. Si je veux lancer un test sur une douzaine de pages, il reconnaît qu'elles partagent le même template et me demande si je souhaite appliquer la variation à toutes. Je réponds simplement : oui. »

Chris Strobl · Cedars-Sinai · Sept à huit mois d'usage de PBX en production

La différence ne vient pas seulement du modèle. L'un des principaux enseignements de cette étude dépasse le cas de PBX.

La qualité des résultats ne dépend pas uniquement du modèle de langage utilisé. Elle repose avant tout sur le contexte auquel ce modèle a accès. Plus un outil connaît le site, son design system, sa charte de marque, ses règles d'accessibilité ou encore les enseignements des expérimentations précédentes, plus les variations qu'il génère sont pertinentes et directement exploitables.

‍

Limites assumées

Là où les praticiens ont exprimé des réserves

La confiance ne remplace pas la QA. Les praticiens sont unanimes : quel que soit son auteur, tout code destiné à être déployé sur du trafic réel doit être inspecté et validé.

PBX facilite cette étape en exposant le code généré, en proposant un mode Simulate et en permettant un déploiement progressif sur une faible part du trafic avant une ouverture complète. Autrement dit, l'IA accélère la phase de construction, mais elle ne remplace pas les processus de validation.

« Si l'outil produit le code, je le passerais probablement dans un environnement de préproduction avant de le mettre en production. Je voudrais vérifier que le code généré par l'IA n'a pas d'effets de bord, le genre de chose qu'un processus de QA plus poussé permet de détecter. » 

‍Holly Gleason · Digital Testing Manager · Distributeur alimentaire américain

Le cas des applications monopage (SPA). Dans la version évaluée par la majorité des participants, les frameworks SPA, notamment Angular, étaient identifiés comme un point de vigilance.

Depuis, Kameleoon indique que PBX s'appuie sur son API JavaScript, notamment runWhenElementPresent et enableDynamicRefresh, et que le Master Prompt permet de prendre en compte les spécificités du site, comme le Shadow DOM ou les composants personnalisés.

Cette évolution est cohérente avec le retour d'un utilisateur de longue date travaillant sur un site SPA :

« Cela fonctionne bien, presque étonnamment bien. Avec Target, il faut intégrer des mécanismes pour signaler qu'une page a changé. Avec Kameleoon, la détection automatique est excellente. »

Chris Strobl · Cedars-Sinai · Usage prolongé en production

Le dernier obstacle : la validation. Un data scientist ayant utilisé plusieurs plateformes d'expérimentation souligne qu'il existe une différence importante entre écrire un prompt et être capable, si nécessaire, de débugger le résultat obtenu.

Les fonctionnalités Configure et Simulate de PBX 2.0 répondent précisément à cet enjeu en permettant de vérifier le ciblage des variations ainsi que le déclenchement des événements avant toute mise en production.

‍

Un point de vigilance sur la rigueur

La rigueur ne vient pas de l'outil de création

Si le CRO et l'expérimentation se sont imposés comme des disciplines, c'est parce qu'ils apportent une méthode à des décisions qui seraient autrement guidées par l'intuition, les préférences individuelles ou la politique interne.

Cette rigueur ne réside pas dans la construction de la variation. Elle repose sur tout ce qui l'entoure : la formulation de l'hypothèse, la recherche préalable, la définition des critères de succès avant le lancement du test, le plan d'analyse, les seuils statistiques et l'interprétation des résultats.

L'outil de création de variations n'intervient qu'au milieu de cette chaîne. Il accélère une étape, mais ne remplace pas la méthode qui donne sa valeur à l'expérimentation.

« C'est le genre de chose dangereuse qui peut déraper si ce n'est pas réellement encadré. » 

‍Senior CRO Lead · Grand distributeur international

Réinvestir le temps gagné sans brûler les étapes. À mesure que l'IA prend en charge la création des variations, la valeur des équipes se déplace vers les étapes qu'elle n'automatise pas. 

Le temps gagné peut être réinvesti dans des hypothèses plus solides, une meilleure instrumentation, des plans d'analyse plus robustes et une interprétation plus fine des résultats. Autrement dit, l'IA accélère l'exécution ; elle ne garantit pas la qualité de la démarche.

La rigueur expérimentale, elle, reste une responsabilité humaine.

‍

Où va la technologie PBX?

Du prompt… jusqu'à la production

La génération de variations par prompt n'est que la première étape de cette évolution. Le véritable enjeu est ce qui se passe une fois le test terminé : comment une variation gagnante devient-elle une fonctionnalité en production ?

Avec PBX Ship, Kameleoon prolonge le workflow au-delà de l'expérimentation. Grâce à un serveur MCP, une variation validée peut être transmise directement dans l'environnement de développement de l'ingénieur, derrière un feature flag. La variation créée par prompt et la fonctionnalité finalement déployée deviennent ainsi deux étapes d'un même workflow.

Plus largement, toute cette catégorie d'outils semble évoluer vers une approche multi-agent, dans laquelle différents agents prennent en charge les différentes étapes de la boucle d'expérimentation tout en partageant un même contexte.

À terme, la capacité d'une plateforme à faire passer une variation jusqu'en production de manière fluide pourrait devenir son principal facteur de différenciation. Les outils qui s'imposeront seront ceux qui sauront refermer la boucle entre le prompt, l'expérimentation et le déploiement.

PBX Ship apporte déjà une réponse crédible à cette évolution.

‍

Alors, quelle est la réponse ?

Trois transformations majeures

La question n'est pas de savoir qui l'IA remplace, mais comment elle redistribue les responsabilités.

À travers l'ensemble des entretiens, un même constat s'impose : les outils comme PBX transforment principalement trois dimensions.

01 · Qui peut créer une expérimentation. Le praticien qui a une idée ne dépend plus systématiquement de la disponibilité des développeurs, des designers ou du soutien politique nécessaire pour convaincre que cette idée mérite d'être explorée. Davantage de profils peuvent désormais passer directement de l'idée à l'expérimentation.

02 · Quelles idées sont effectivement testées. Les idées qui restaient jusque-là dans le backlog ont désormais une chance d'être testées. Le coût d'un test est devenu suffisamment faible pour qu'une hypothèse puisse être expérimentée avant d'avoir à convaincre toute une organisation.

03 · Le rôle des spécialistes évolue. L'IA prend en charge une grande partie de la création des variations, une tâche qui ne nécessitait pas toujours une expertise d'ingénierie. Les développeurs peuvent ainsi se concentrer sur les expérimentations les plus complexes, tandis que les spécialistes de l'expérimentation consacrent davantage de temps à ce qui crée réellement de la valeur : identifier les bonnes opportunités, concevoir des hypothèses solides, interpréter les résultats et diffuser les apprentissages dans l'organisation.

« Pour la première fois en seize ans de métier, je serais à l'aise à l'idée qu'un profil plutôt marketing aille dans l'outil et rédige les prompts. » 

‍Chris Strobl · Cedars-Sinai · 16 ans d'expérience en expérimentation

La question de fond n'est donc plus de savoir si l'IA remplacera quelqu'un. Elle consiste à comprendre ce que les programmes d'expérimentation feront du goulot d'étranglement qui vient de disparaître, et comment ils ouvriront cette discipline à davantage de profils sans renoncer à la rigueur qui en fait toute la valeur.

‍

Et maintenant ?

La vraie question n'est plus de savoir si l'IA est capable de créer des variations

‍Elle est de savoir ce que les programmes d'expérimentation feront du goulot d'étranglement qui vient de disparaître.

L'article complet est également disponible sur LinkedIn, avec les biographies des praticiens et des éléments de contexte supplémentaires.

{{cta-block}}

‍