mercredi 26 décembre 2018

Test A/B & P-hacking

Préambule : Voilà à quoi ressemblerait la pratique des tests statistiques dans le web si c'était une moto  : une moto c'est pour transporter un ou deux adultes, munis de casques... Et voici comment comment cette "moto" est utilisée dans le marketing...

Je trouve ce parallèle intéressant car dans les deux cas la pratique se justifie par la nécessité et l'absence d'autres solutions réellement applicables.
Alors à défaut de faire parfaitement, et selon les règles, on essaye de faire au mieux, en essayant de minimiser les risques. Dans cet article je vais détailler, en restant à un niveau intuitif, la nature et l'importance des erreurs commises, et les précautions que l'ont peut prendre.

mots clés : P-hacking, test A/B, test statistique, statistique fréquentiste , statistique bayésienne.

Introduction : Il y a un vent d'inquiétude dans les sciences appliquées utilisant les tests statistique. Les tests statistiques sont des algorithmes (basés sur de formules statistiques) qui utilisent des données d'expériences et qui vont servir à décider si une expérience est significative ou non. Des  scientifiques ont remarqué que de nombreuses expériences en sciences humaine (et marketing) n'était pas reproductibles, plus exactement la reproduction de beaucoup d'expériences n'arrivent pas au même résultat! Pourtant les tests statistiques qui ont été utilisés pour valider ces résultats initiaux indiquaient qu'ils étaient significatif...

Cette même constatation s'opère dans le domaine du marketing, en particulier là où l'expérimentation est aisée : le web. Cette pratique s'appelle le test A/B et consiste à mesurer l'effet d'une modification d'un site web sur des indices business (nombre d'achats, valeur de panier moyen, etc...).

Le terme p-hacking est devenu le terme qui résume ce problème scientifique. je vais essayer de vous le faire comprendre, mais surtout d'y voir un peu plus clair pour mieux mesurer l'ampleur réelle du problème. Je ne parlerai que de la partie marketing, mais vous aller comprendre que le problème est fondamentalement le même que pour les sciences humaines en général.

Le P-hacking fait référence à un concept central dans tests statistique : la 'p-value' ou 'p-valeur' en français. Elle sert à qualifier l'incertitude d'une mesure quand celle-ci est en partie aléatoire. C'est un concept central de la notion de test.

La pratique du test A/B exige le respect d'un protocole assez strict pour l'obtention d'une P-value valide, or malheureusement ce protocole n'est pas toujours respecté. Je mets de coté le cas de la pratique malhonnête, pour me concentrer sur les cas où l'expérimentateur n'a pas conscience de son erreur. Je préciserai que souvent le praticien sait qu'il n'est pas dans le respect strict du test statistique, mais bien souvent il ne sait pas l'ampleur du risque qu'il prend...

Le 'p-hacking' c'est quoi ?

La vidéo ci-dessous est une illustration intuitive du phénomène. La première impression que donne cette vidéo est que le lanceur est terriblement doué. Puis une question s'impose : combien de tentatives ont été nécessaire pour créer cette vidéo ? On se dit alors qu'on ne voit que la vidéo de la réussite, et que s'il y a eu 1000 tentatives, alors on se dit que, tout cela n'est que de la chance bien présentée.
En résumé le P-hacking peut se traduire par : "plus je fais de tentatives, plus j'ai de chances de réussir".

Les libertés prises avec les règles d'application du test statistique peuvent amener les praticiens (souvent inconsciemment) à l'erreur.


Le principe du test statistique intègre cette intuition en exigeant qu'on ne fasse l'expérience qu'une seule fois. Mais même si les praticiens connaissent cette règle elle est difficilement applicable en pratique pour plusieurs raisons :

  • Dans le test A/B on fixe une durée pour exposer les variations et collecter les données. À l'issue du test on peut voir que la différence entre A & B est trop petite pour pouvoir être qualifiée, alors on laisse l'expérience collecter un peu plus de données. En pratique il s'agit là déjà d'une seconde tentative, et par conséquent on n'est plus dans la pratique stricte du test statistique.
    Poussée à l'extrême cette pratique qui consiste à laisser se dérouler une expérience jusqu'au moment où la P-value passe le seuil de significativité est appelé l'"early stopping". C'est la source la plus grave d'erreur, car c'est la plus fréquente, et c'est celle qui va générer le plus grand nombre d'erreurs.
  • Quand on essaye une variation B il y a un coût, celui d'envoyer la moitié de son trafic vers une variation qui marche moins bien que l'original. Par conséquent, la peur de faire des changements risqués se traduit par ne faire que des modifications mineures dans la variation B. Des modifications si mineures qu'elle n'auront vraisemblablement aucun impact, et le fait de répéter de telles expériences revient à faire plusieurs fois le même test, ce qui n'est pas prévu par les tests statistiques.
  • Comme son nom l'indique le test A/B expose un original : A, et une variation : B. Car les tests statistiques classiques ne considèrent que ce cas. Mais comme il faut aussi tester les variations simultanément pour tenir compte des variations saisonnières, il est commun de tester plusieurs variations et donc faire du test A/B/C/D... Cela aussi est une entorse aux règles d'application des tests statistiques. On appelle cela le problème des test multiples.
  • Les bonnes pratiques exigent aussi d'avoir une hypothèse. Cela veux dire qu'on a des raisons, avant même l'expérience, de penser que B est meilleur que A. Or cela peut être bafoué par la pratique du test multivarié où l'on génère un grand nombre de variations combinant toutes les possibilités d'une liste de caractéristiques. De plus dans ce cas beaucoup de variation sont très proches les unes des autres car ne varient que d'un détail. Clairement le test multivarié est la pratique aujourd'hui la plus risquée. Car elle cumule plusieurs sources d'erreur.
Ces erreurs peuvent être faites par simple ignorance, car les formations marketing (ou en sciences humaines) n'insistent pas forcément sur les compétences en statistique. Donc une bonne formation est évidement un facteur de succès, mais l'environnement de la pratique des test A/B a aussi son importance. En sciences humaines, comme ailleurs, il y a l'incitation "publish or perish" qui incite donc a absolument avoir une expérience "significative". Ce qui amène, consciemment ou non, à faire une ou plusieurs des erreurs citées ci-dessus. En marketing le problème peut être du même ordre, les objectifs de l'équipe d'optimisation marketing peuvent pousser les employés à ne pas respecter à la lettre les règles d'usage des tests statistiques, et donc d'en subir les conséquences en terme d'erreur...

Comment éviter le 'P-hacking' ?

Le respect du protocole est bien évidement à la base, ainsi qu'éviter les erreur explicitée ci-dessus, mais j'ajouterai certains points, moins souvent exposés.

Éviter les tests inutiles

Il existe des formules qui permettent d'avoir un ordre d'idée du volume nécessaire de visiteurs à tester pour espérer détecter un gain. Exploitant cette même idée on peut voir le problème dans l'autre sens, ce qui est plus logique pour la pratique du test A/B sur le web : calculer la taille minimale du gain qu'on peut mesurer en fonction du trafic disponible.
Ainsi il n'y a aucun intérêt à tester un changement mineur (par exemple un changement de couleur) si il y a peu de trafic sur la page en question. Car le gain (positif ou négatif) sera certainement trop faible pour pouvoir être qualifié.

Ne pas utiliser la 'P-value' !!

Les tests fréquentistes ne sont pas adapté à la pratique du web...  Ce titre est volontairement accrocheur, mais c'est ce n'est pas trompeur. Les tests statistique fréquentistes ne fournissent qu'une seule information, la fameuse P-value. Fondamentalement c'est insuffisant pour prendre une décision, car toute décision se base sur deux axes :

  • ce qu'on espère gagner en remplaçant A par B 
  • le risque qu'on prend à remplacer  A par B

Et il est impossible de répondre à ces 2 questions par une seule valeur.
Au mieux la P-value permet de se faire une idée du risque, mais ne fournit pas d'information, sur ce qu'on espère gagner. Ce qui force plus ou moins à prendre des risques inutiles, car parfois le gain ne vaut pas le risque pris.

Les statistiques bayésiennes à la rescousse...

Les statistiques bayésiennes sont bien plus adaptées à la pratique du test A/B pour le web.
Déjà parce qu'elles sont moins sensibles au fait de prolonger une expérience, comme cela est expliqué dans cet article.
Mais, selon moi, l'apport principal est de fournir plus d'informations au sujet du gain espéré, ce qui permet de faire un meilleur choix lors de l'analyse d'une expérience.
Prenons un exemple : à la fin d'une expérience, la variation A a un taux de clic mesuré à 3% et B à 3.05%.

  • Le calcul de la P-value amène à un taux de confiance à 95%, c'est le seuil conventionnel d'acceptation, donc on valide B...
  • L'analyse bayésienne vous dit que le gain relatif apporté par la variation B se situe entre 1% et 3% (donc que si le taux de clic de A est à 3%, alors celui de B se situe entre 3.01% et 3.09%).On peut se dire que gagner +0.01% en absolu ne vaut pas le risque de se tromper, et peut être même que le simple coût du changement peut ne pas être amorti par le gain réel qu'apportera B...

On voit alors que si on se base uniquement sur la fameuse P-value, sans regarder l'analyse bayésiennes, cela peut nous mener à faire de mauvais choix.

La plupart des logiciels de test A/B utilisent maintenant un test bayésien, mais il en reste encore qui restent accrochés à l'utilisation de la P-value. Probablement car c'est plus facile à calculer et à expliquer.

Le fond du problème est de vouloir choisir avec uniquement la P-value comme critère de choix.  On ne peut pas résumer le choix de remplacer une page par une autre avec une seule et unique valeur. La P-value ne donne d'informations que sur l'existence, ou l'absence, d'une différence entre deux variations, mais elle ne qualifie pas la taille de cette différence. Or en pratique, pour faire ce genre de choix on veut finalement mesurer deux choses :

  1. l'apport espéré du changement
  2. le risque de se tromper

Dans l'exemple précédent le risque ne vaut pas la chandelle, mais seul l'analyse bayésienne permet de le voir.

Conclusion 

Mes conseils pour limiter le risque de se tromper en pratiquant le test A/B, sont :

  • Utilisez un test Bayésien qui donne un intervalle de confiance autour de la mesure du gain.
  • Ayez une vraie hypothèse, ne pas tester des choses "à peine visibles".
  • Restez raisonnable sur le nombre de variations testées.
Il y a des solutions de 'correction' des p-values comme les procedures de Bonferroni ou Holm-Bonferroni, qui limitent le risque de découverte erroné. Malheureusement elles limitent aussi très fortement la capacité de détecter de vrais gagnants... Et de plus elles ne permettent pas de calculer ni de corriger les intervalles de confiances du gain. Or, comme on l'a vu, l'intervalle de confiance du gain est le seul outil permettant de mesurer le compromis entre l'espoir de gain et le risque, ce qui est le vrai axe de décision.

vendredi 30 novembre 2018

Cette fonctionnalité est-elle vraiment utile ?

"Il y a des choses qui sont prévues pour être utilisées et d'autres pour être achetées... il n'y a pas forcément une correspondance parfaite entre les deux..." (moi)

Dans le secteur de l'édition de logiciel on arrive souvent à discuter de l'intérêt de créer ou garder certaines fonctionnalités. En effet accumuler des fonctionnalités peut être un problème pour plein de raisons :
  • coût du développement de ces nouvelles fonctionnalités
  • plus de bugs potentiels
  • augmentation du périmètre de maintenance
  • complexité accrue pour l'utilisateur
Il y a même des entreprises qui font du test A/B pour évaluer l'intérêt de garder une nouvelle fonctionnalité. Chez Booking par exemple, ils font des tests A/B pour s'assurer qu'une fonctionnalité leur rapporte de l'argent. Si ce n'est pas le cas, la fonctionnalité est supprimée.

Cependant, toutes ces approches négligent un aspect important de la raison d'exister d'une fonctionnalité.

« Il y a des choses qui sont prévues pour être utilisées et d'autres pour être achetées... il n'y a pas forcément une correspondance parfaite entre les deux... »

Certaines fonctionnalités sont prévues pour "faire vendre" mais ne seront pas utilisées. Cela peut paraître étrange, mais c'est une réalité. Pour vous en convaincre demandez vous combien d'acheteurs de véhicules 4x4 utilisent réellement la "fonctionnalité 4x4" ? Très peu, d'autant plus que ce type de véhicule sont souvent populaires en région très urbaine. On peut se dire que c'est le look du 4x4 qui fait vendre, et dans ce cas ça peut être vu comme une "fonctionnalité" utilisée... Mais dans ce cas on pourrait aussi se dire que les constructeurs pourraient simplement créer des véhicules ayant le look 4x4, mais pas le poids (et la consommation), ni la puissance moteur et encore moins le complexes système de transmission 4x4... Pour autant (et à ma connaissance) ce type de véhicule n'existe pas vraiment, peut être justement parce que l'acheteur veut réellement un 4x4, même s'il sait qu'il n'utilisera pas la fonctionnalité spécifique du 4x4.


Certaines fonctionnalités font vendre, mais ne seront pas utilisées par les acheteurs!

On peut croire que ce mode de choix un peu schizophrénique, est uniquement présent en B2C, là où le choix ne dépend et n'impacte qu'une seule personne. Cela illustrant parfaitement l'achat plaisir, qui par définition n'est pas rationnel. Mais cela arrive pourtant aussi en B2B!

Cette irrationalité est même facilement mesurable quand on vend un service en SaaS, puisqu'on peut facilement tracker l'utilisation de chaque fonctionnalité.

Cette irrationalité peut s'expliquer par la méthodologie des choix de services en entreprise.

Voici comment ça marche. Une personne est mandatée pour choisir un service parmi une longue liste. Cette personne n'est malheureusement pas la personne qui utilisera le service en question, car souvent considéré comme simple exécutant, l'entreprise lui préférera un cadre ayant une approximative expertise dans un domaine connexe. Puisqu'on parle se logiciel, assez naturellement c'est souvent un directeur informatique qui sera choisi. Comme il n'a pas d'expertise dans le domaine d'application du service en question, il va  essayer de rationaliser son choix en faisant une feuille de tableur. Une ligne pour chaque service, et une colonne pour chaque fonctionnalité du produit. Il va alors balayer toutes la documentation disponible et remplir le tableau avec des oui/non qui résumeront la présence ou non de chaque fonctionnalité pour chaque service. A la fin il donnera une note pour chaque service, simplement en comptabilisant les oui/non de chaque service. Et souvent sans pondération, toutes les fonctionnalité ayant le même poids, simplement par ce qu'il n'est pas celui qui utilisera le service et que fondamentalement il ne comprend pas ce qu'il y a derrière le nom de chaque fonctionnalité.

On arrive alors à la situation où les éditeur logiciels sont condamnés à proposer certaines fonctionnalités, même si celles-ci ne seront pas utilisées. À partir du moment où suffisamment de concurrents la proposent, alors il faut l'avoir pour avoir une chance dans les appels d'offres.

Donc, réfléchissez y a deux fois avant de dire qu'une fonctionnalité est inutile. ;)
Je conclu en citant Jérôme Bonaldi  :

« C'est totalement inutile et donc rigoureusement indispensable ! »

Et en remerciant Rémi Aubert (CEO et fondateur d'AB Tasty) qui m'a fait comprendre ce mécanisme.

mardi 2 octobre 2018

livre sur l'e-commerce

Le 24 octobre 2018 paraîtra un livre sur l'e-commerce, dans lequel j'ai (modestement) participé.
Ma contribution est sur les outils de type Intelligence Artificielle (IA) qui participent à la gestion marketing des sites e-commerce.



Pour plus d'info sur les autres auteurs, ainsi que des chapitres gratuits, allez directement sur le site d'auteur principal : Jean-Eric Pelet.

Et pour l'acheter c'est ici. 

mercredi 5 septembre 2018

How does a machine learn?


How does a machine learn?
Preamble : This article is a article aimed to explain “Machine Learning” basics in a intuitive fashion for developers.

Introduction

Today there is a huge hype about “Artificial Intelligence”, more especially about “machine learning”. This programming paradigm is very different from the classic old one. The origin of programming is based on the algorithm principle which is a formal description sequence of unitary operations to be made in order to perform the desired task. On the other side “Machine Learning” (ML) is about using examples of solved task to train a “model”, like a teacher showing examples to his students. This is considéred as a more powerful programming paradigm since a lot of tasks cannot be described as a formal sequence of unitary operations. Think about recognising a familiar face, identifying the voice of someone, extracting the sentiment from a text, detecting trolls on a forum, etc… All these tasks can be described with examples but not with a formal sequence of unitary operations.
This covers why machine learning is so interesting. However it does not explain how machines learn...  
Spoiler!: The trick to machine learning is to transform a learning problem into an optimization problem (which is something engineers easily deal with). This is explained in the rest of this article while explaining what is a “example”, a “model”, a “training”, and why does all this sometimes fail.

Ok, this introduction already yields some questions.

What do you mean by  “example“?

It’s a pair of (input,output) information, the input side is the information your have about the task, for instance a person’s picture for an identification task. The output is the solution of that given task (ie. the name of the person on the picture). These informations are transformed into numbers in order to be fed into a “model”. Typically a picture is a set of pixel which are numerical values. On the other hand the expected output in this example is a name, which is not numerical. Thus, it must be transformed into a number, in this case index of a list of all names. This list is necessary in order to be able to show a human readable answer at the end of the process.
Generally, when training a model, a training database is used: a large number of (input, output) pairs, enough to obtain a viable model for the targeted task.
Since input & output may have more than one dimension we often refer them as input & output vector. But for the sake of simplicity let’s consider them as one dimensional values (scalars), which allow an interesting graphical representation: Laying the input on the x axis, and the output on the y axis, shows the training database as a point cloud.

So what is exactly a “model”?

Considering the above figure, the “model” is a curve that fit to the point could. Specifically it’s a “class of curves”, since there is not a unique solution. Consider the model as a type of curve that has the ability to fit the point cloud with given properties.
One can see the machine learning paradigm as a interpolation problem : with a new input value (X) what would be a credible (Y) value ?
A model can be seen as an “empty brain”. Since input & output of the task are seen as numbers, one can see the model as a mathematical formula. This curve is in fact a mathematical function, a parametric function. The parameter are values that can be estimated in order to fit the point cloud, but they are not set for the moment (we will see that later).

modelparameters(input) = output


This mathematical function is where the magic happens. It transforms the input number into a numerical output (the result) that will, in a later stage, be transformed back into a usable information (for instance an index, that will be transformed back into a name from a list). At this stage the model is still “empty” so the answer is random (or undefined). A model needs to be “trained” in order to provide meaningful answers.
There is a lot of different models ((deep) neural networks, linear regression, etc…). All are mathematical functions with different properties more or less suited to different kind of tasks.

What does it mean to “to train a model with examples” ?

Training a model means finding parameters of the underlying formula in order to produce correct answers for given inputs. The output of a model is numerical and known (remember: the example task is already solved outside of the model), this means we can express the error a model makes as a numerical value. We are then facing a “classic” equation resolution problem:
modelparameters(input) = output
At the beginning, model parameters are unknown and usually initialised at random, hence producing an irrelevant output at this stage.  We can measure the error of the model as:
Error = modelparameters(input) - expected output
In practise, we use more complex error formula, but the main idea remains. When the error is minimized, the learning is done.
The error is basically the distance between the point cloud and the curve. The learning process is a step by step optimisation of the parameter of the model, in order to fit the point cloud. 




The same process can be viewed as this block diagram :


The learning problem becomes an optimization problem!
Optimization is an old mathematical field, well known by engineers. Given an input/output dataset and a model (with unknown parameters), the optimization process outputs model parameter values.
Common optimization strategies are: stochastic gradient descent, Monte Carlo Markov Chain, BFGS, …
This process can be quite long and heavy depending on the model complexity and the learning database size (with far more than 3 learning steps).
When a model, its parameters and input are known, one can easily compute the output from new and previously unseen input data : it’s just evaluating a function.
This phase is very fast (regarding to the learning phase).


And sometimes it fails !
One important thing the point cloud analogy help to understand, is that there is more than one solution, because more than one curve can fit a point set. The less training point one have, the more different solutions are possible. That’s why ML need a lot of data to produce accurate results. As a consequence GAFAM, that hold most of the internet data, have a great advantage. 
And sometimes, the learning procedure can still fail, even when the measured error is very small. This graph shows how a model can fit data with a very low error, but can still be totally wrong when tested on new data.


What is the main difference with classical programming?
  • ML gives the ability to a programmer to train a model on a task that he is unable to do by himself (assuming he can obtain a training dataset for that task)!
A classical developer can only make program that automates things he could do by himself. It’s even more powerful that human learning: a teacher can’t teach you something he doesn’t know! A ML practitioner trains a computer to do something he can’t do by himself. This is a real shift in human potential.
For instance I built DNA analysis softwares while lacking any biology degree.
  • Algorithm used in classical programming are often mathematically proved. This means that they are more reliable. Most of the times the bugs comes from error in the implementation (ie. the translation of the algorithm principles into a programming language).
ML programs cannot be proved to be 100% accurate, but they tackle problems that cannot be solved at all with classical programming. One still has to handle the fact that there will be errors. Good ML practitioners are able to measure the validity of their models, and know how to handle risks and consequences of errors.
(One third of introductory course on ML are about evaluating a model.)
  • The model and the optimisation phase still use classical programs, hence why ML practitioners are mainly computer scientists... with a slightly different profile. They are more math friendly people than typical developers. These kind of profile is quite rare, regarding to the high number of developers. This means that they are highly demanded. ML is not new, but it gained popularity quite recently, with the shift of all sort of business activities (e-commerce, advertisement, ...) toward the web where data collection is cheap & easy.

jeudi 24 août 2017

Minimum Detectable Effect calculator


MDE calculator

This form calculates the Minimum Detectable Effect for an AB test.
Enter the number of visitors you have and the conversion rate of the page you want to test, then clic on the run button...
You will get the size of the Minimum Detectable Effect of your experiment.

Total number of visitors :
Initial conversion rate : %

Minimal Detectable Effect :


Feel free to ask questions in the comment section or via twitter (@hwassner).

Go to the AB Tasty website for a nicer interface of that tool.

lundi 21 août 2017

Minimum Detectable Effect

La fin du "sample size calculator"


Dans la pratique du test A/B, il est recommandé de prévoir la taille de l'échantillon de visiteurs que l'on va tester. Ce conseil provient de la pratique industrielle, pour laquelle la taille de l'échantillon est importante, car elle définira le coût de l'expérience. L'objectif est de maintenir ce coût le plus bas possible.
C'est à cela que les "sample size calculator" servent. Ils demandent le taux de réussite actuel (taux de conversion) ainsi que la taille de l'effet minimum que l'on cherche à mesurer. Le résultat du calcul est la taille de l'échantillon nécessaire pour que l'on puisse conclure d'une telle expérience.

Cela se transpose mal dans le monde du web car la situation est différente :
  • Mesurer les conversions ne coûte rien (contrairement à l'industrie)
  • Le nombre de visiteurs est une donnée du problème (pas la réponse)
  • L'effet de la variation est difficilement prévisible.
    (en pratique c'est même précisément la question qu'on se pose!)
Cela rend très difficile l'usage des calculatrices de taille d'échantillon.

Pour autant, être capable de savoir ce que l'on peut vraiment mesurer est très important.

Pour le web il faut une formule qui marche dans l'autre sens.

On spécifie :
  • Le taux de conversion actuel 
  • Le trafic de la page à tester
 Et la formule donne la taille minimale de l'effet induit par la variation qu'on sera capable de détecter :le MDE (Minimal Detectable Effect).

J'ai développé une telle calculatrice, vous pouvez y accéder ici, dites moi ce que vous en pensez.

mardi 31 janvier 2017

Régulation des algorithmes (suite)

Hier soir j'étais à une réunion de présentation à CAP Digital,sur le sujet de la "régulation des algorithmes"... (vous pouvez lire l'article précédent sur ce sujet ici.)

Je suis plutôt content car les gens qui on présenté le problème semblent bien avoir compris quelques subtilités du problème comme :
  • Surveiller à la fois les algorithmes mais aussi les données utilisées pour les paramétrer. Dans le domaine du "machine learning", on parle de données d'entraînement. Ces données , plus que l'algorithme lui-même, décide du comportement prédictif. 
  • Certains algorithmes sont, par constitution, non-analysable, non-explicable. On parle de boite noire, mais pas par volonté de cacher les chose, mais fonctionnement de base.
  • L'INRIA, partenaire scientifique, ne se positionne que comme centre de ressources de solution scientifique/technique de mesure.
Bref, ils ont comprit qu'il s'agit d'un problème fondamentalement complexe pour lequel il n'existe pas de solution technique aujourd'hui. C'est rassurant.

Ce qui l'est moins :
  • Aucune start-up du domaine ne fait partie des rapporteurs.
  • Personne n'a soulevé le risque de créer une régulation qui serait dangereuse pour les entreprises françaises travaillant dans le "machine learning". En effet, imposer une régulation implique avoir un levier d'action envers les contrevenants, or aujourd'hui les GAFA (Google, facebook, Amazon, etc...) sont totalement intouchables (elles ne payent même pas les impôts sur le bénéfice fait sur le sol français). Une régulation franco-française ne ferait donc que les avantager encore plus par rapport aux start-up française.
    L'effet de la régulation serait alors inverse à l'objectif, car ces algorithmes seraient alors totalement pilotés par des entreprises étrangères non soumis à la réglementation, et donc totalement hors de contrôle.
    Sans parler de la destruction d'emploi et la perte de revenu fiscal.
Bref, tous les acteurs ont bien identifiés qu'on est incapable aujourd'hui de faire quelque action censée que ce soit dans ce domaine. Mais je crois que c'était a peu près la même situation pour HADOPI : personne ne croyait vraiment pouvoir endiguer la copie illégale par manque de solution technique. Pourtant HADOPI a bien été crée, et a gaspiller beaucoup d'argent pour rien.
J'espère juste que ce cela ne se reproduira pas.

Je ne vois donc pas de risque imminent, mais c'est tout de même un sujet à "surveiller".