Accélérer votre programme d’expérimentation avec PBX en 2026 : méthodes et retours terrain
Cette interview s’inscrit dans la série Expert FAQs de Kameleoon, dédiée aux leaders de l’optimisation CX et de l’expérimentation. Alexandre Suon est Head of Experimentation chez Accor et Managing Partner d’Henkan & Partners et co-auteur d’une étude indépendante du cabinet intitulée : « Mesurer l'impact de l'expérimentation avec PBX ».
Qu’est-ce que PBX et comment l’utilisez-vous au quotidien ?
PBX, (la Prompt-Based Experimentation), est une nouvelle fonctionnalité de Kameleoon qui permet de décrire ce qu’on veut créer en langage naturel, directement sur son site web. L'IA génère une variation complète de votre site et, en quelques clics, vous pouvez la tester. Dès juillet, nous avons fait partie des beta testeurs de la feature qui est sortie début septembre 2025.
Nous sommes une grande organisation. Nous menons des centaines de tests par an, majoritairement basés sur du JavaScript injecté. Nous sommes convaincus de la valeur ajoutée de PBX et nous avançons progressivement vers une adoption à grande échelle. Elle implique des changements de processus, de gouvernance et de rôles et nous sommes donc actuellement dans une phase de transformation pour :
- Identifier les cas d’usage PBX les plus rapides et les plus rentables.
- Adapter nos workflows internes.
- Anticiper les compétences nécessaires d’ici un à deux ans.
Nous évoluons vers des profils “couteau suisse”, capables de relier expérimentation, QA, prompting et logique produit. PBX n’est pas un outil. C’est un véritable changement de notre modèle opérationnel.
Pouvez-vous nous en dire plus sur cette nouvelle façon de créer des tests ?
Aujourd’hui, mon constat, c’est qu’on n’automatise plus des tâches, on automatise une intention. Concrètement, avant, pour lancer un test, il fallait écrire du code, configurer des règles, utiliser des outils… Désormais, il suffit de décrire ce qu’on veut tester, en langage naturel.
Avec PBX, la limite n’est plus la technique et la complexité de la tâche, mais bien la précision humaine. Plus l’intention est claire, plus l’IA performe. Plus elle est floue, plus l’automatisation se dégrade. L’expérimentateur n’“utilise” plus un outil. Il co-construit avec l’IA. PBX crée une forme d’automatisation hybride, ni totalement manuelle, ni totalement autonome. Ce système exige un nouveau paradigme : la collaboration, plus que la simple exécution.
En pratique, cela change profondément le rôle de l’expérimentateur. Il ne s’agit plus seulement de lancer des tests, mais de bien formaliser une intention exploitable par l’IA. C’est pourquoi le prompting devient une compétence centrale. Un véritable levier stratégique.
Comment PBX transforme le rôle de ceux qui pratiquent l’expérimentation ?
Je distingue deux types de rôles clés dans l’expérimentation : les “enablers”, ceux qui permettent, et les “doers”, ceux qui font. PBX les impacte très différemment.
Les “enablers”
Les “enablers” développent la culture de l’expérimentation. Ils structurent les frameworks, alignent les parties prenantes et garantissent la rigueur. Leur rôle reste profondément humain. Même avec l’IA, nous continuons d’avoir besoin de gens qui posent les bonnes questions, challengent les hypothèses, alignent les équipes et sont garants de la rigueur scientifique de la méthode employée. PBX ne remplace pas ce rôle. Il le renforce.
Les “doers”
Pour les “doers”, PBX crée une rupture. Des tâches qui prenaient des jours prennent désormais seulement quelques heures voire minutes. L’analytics et l’expérimentation changent d’échelle. Les entreprises gagnent en vélocité d’expérimentation d’une façon inédite. Celles qui n’adopteront pas ces capacités prendront du retard.
Le rôle du “doer” évolue avec moins d’exécutions manuelles, mais plus de décisions à prendre, d’orchestration entre les parties prenantes et l’accompagnement d’une croissance et d’une nouvelle façon d’expérimenter qui peut bouleverser l’ordre établi.
Quel est le rôle du développeur avec PBX ?
Nous n’avons pas encore d’équipe dédiée à l’utilisation de PBX. Nous sommes encore dans une phase de test pour trouver la bonne organisation.
Toutefois, PBX crée de nouvelles exigences. Elle génère du code de qualité mais quelqu’un doit le valider. Le besoin de QA s’intensifie.. Nous assistons à l’émergence d’un nouveau rôle hybride, capable, à la fois, de prompter des tests, valider les outputs et garantir la qualité avant mise en production.
PBX ne supprime absolument pas le rôle des développeurs. Elle redessine les flux. Les équipes techniques sont toujours chargées de poser les fondations systèmes et il est indispensable de maintenir un dialogue avec elles pour les garder dans la boucle de l’expérimentation.
Quels garde-fous utilisez-vous pour garantir la qualité des tests lancés avec PBX ?
PBX accélère la création, mais il renforce aussi le besoin de validation humaine. Comme je l’ai expliqué dans ma réponse à la question précédente, nous comptons sur une équipe de QA formée, responsabilisée et outillée.
Elle est chargée d’assurer :
- Le respect de la charte graphique et du Design System.
- La cohérence UX/UI.
- L’identification des effets de bord.
- Le maintien des règles business et brand.
PBX accélère l’exécution. L’humain s’assure de la qualité et protège la marque.
Pour aller plus loin, n’hésitez pas à parcourir l’étude d’Henkan & Partners sur les performances de PBX, à demander une démo pour voir PBX en action ou à vous rapprocher de votre CSM pour plus d’informations.
