Booking.com enveloppe chaque changement de produit dans un test A/B — plus de 1 000 en cours simultanément

À mesure que Booking.com devenait l'une des plus grandes places de marché du voyage, les équipes produit risquaient de décider des fonctionnalités par opinion. L'entreprise menait des expériences contrôlées en ligne depuis plus de dix ans et voulait que chacun, et pas seulement les chefs de produit, puisse valider des idées de manière peu coûteuse, sûre et avec des données fiables.

Faire de l'expérimentation le système de décision par défaut : chaque changement, même les corrections de bugs, est livré enveloppé dans un test A/B, et chacun peut lancer un test, consulter l'historique et arrêter les tests nuisibles.

Les ingénieurs ont construit une plateforme d'expérimentation interne avec un référentiel consultable de chaque succès et échec passé, des API génériques pour le recrutement, le suivi et les métriques, deux pipelines de surveillance indépendants, des pools de tests A/A, et des garde-fous tels que le préenregistrement et l'examen par les pairs des succès. Chaque département disposait de sa propre équipe de support dédiée afin que chacun puisse porter une expérience de bout en bout.

Plus de 1 000 expériences sont menées simultanément sur les applications mobiles, les outils pour hôteliers, les lignes téléphoniques du service client et les systèmes internes ; chaque refonte, changement d'infrastructure et correction de bug est enveloppé dans un test, de sorte que les décisions produit sont passées des opinions aux preuves et que les apprentissages sont réutilisés entre les équipes.

Chez Booking.com, l'expérimentation n'est pas un outil que certaines équipes utilisent — c'est ainsi que l'entreprise décide. Depuis plus de dix ans, la plateforme de voyage mène un développement produit fondé sur les preuves, et en 2017, ses départements menaient et analysaient plus d'un millier d'expériences simultanées un jour donné, sur les applications mobiles, les outils pour hôteliers, les lignes téléphoniques du service client et les systèmes internes.

Le choix délibéré était la démocratisation. La plateforme d'expérimentation sert de référentiel consultable de chaque succès et échec depuis la toute première expérience, afin que chacun puisse consulter l'historique et formuler de nouvelles hypothèses. Des API génériques abstraient le recrutement, la randomisation et le reporting, et chaque département dispose de sa propre équipe de support dédiée, de sorte que mener un test ne nécessite pas l'autorisation de la direction produit.

La confiance venait de la discipline d'ingénierie : deux pipelines maintenus séparément calculent les mêmes métriques et sont surveillés l'un par rapport à l'autre, un pool d'expériences A/A valide les statistiques, et des garde-fous tels que le préenregistrement et l'examen par les pairs des succès limitent le p-hacking. Chacun dans l'entreprise est habilité à arrêter lui-même une expérience nuisible.

Le résultat fut une entreprise où « chaque changement, des refontes complètes et changements d'infrastructure aux corrections de bugs, est enveloppé dans une expérience », comme l'ont écrit les ingénieurs dans un article de 2017 — transformant le développement produit en un flux de paris mesurés plutôt qu'en une série d'opinions.

La décentralisation des expériences a permis à des milliers de personnes de tester des idées au lieu d'attendre que les chefs de produit les priorisent.

Un historique consultable des succès et des échecs permet aux équipes de revisiter et de s'appuyer sur les apprentissages des autres.

Une infrastructure fiable (pipelines doubles, pools A/A, préenregistrement) a rendu les preuves acceptables comme arbitre des décisions.

Le maintien d'un couplage lâche entre la plateforme d'expérimentation et la logique métier a rendu la livraison d'un changement gagnant aussi simple que la suppression d'un appel API.

L'habilitation de chacun à arrêter une expérience nuisible a maintenu la sécurité compatible avec la vitesse.

Vous n'avez pas besoin d'un consensus sur une opinion si chacun peut mener une expérience peu coûteuse et sûre : l'infrastructure plus une culture de la preuve transforment les décisions en tests, et les échecs en apprentissages partagés et consultables.

Le framework interne, écrit par des ingénieurs d'Amsterdam au milieu des années 2000, a été étendu mais jamais réécrit ; en 2026, Silicon Canals a rapporté que Booking.com mène toujours plus de 1 000 tests simultanés sur la page de réservation en production et des dizaines de milliers d'expériences cumulées par an, où un décalage de conversion de 0,1 % représente une somme à huit chiffres. Le modèle s'est répandu dans l'industrie sous le nom de « culture de l'expérimentation » — les plateformes de fournisseurs, les playbooks publics et d'autres entreprises technologiques ont adopté le même modèle du test par défaut dont Booking.com avait été le pionnier.