Bonjour à tous,
J'inaugure ce sujet sur les logs d'action et sur la pertinence de ce type de système pour "lutter contre les multicomptes".
Je propose pour commencer à discuter de ce sujet de partir sur une petite réflexion personnelle. N'hésitez pas à l'enrichir, la critiquer, à apporter votre point de vue sur ce mode de détection.
Avant toute chose, il est important de préciser que tout ce qui suit provient de mon expérience d'administrateur et de développeur d'un jeu qui a comporté un bon millier de joueurs actifs au plus fort de son activité.
Cette approche est donc double : d'une part en tant que développeur je peux évaluer la charge de travail que représente la mise en place des systèmes de détection de multi-comptes et d'autre part en tant qu'administrateur je peux évaluer la pertinence des différents systèmes de détection.
Le système que j'avais mis en place au lancement de mon jeu (à l'orée 2008) reposait intégralement sur la détection par IP. Au fur et à mesure que les joueurs, et donc les "cas" de multicomptes supposés, augmentaient, je percevais les limites évidentes de ce système.
La première de ces limites est d'ordre technique : les nouveaux terminaux mobiles produisent un nombre conséquent de faux positifs (exemple : deux personnes de Free se connectant via le réseau 3G sur mon site pourront avoir la même IP, de même que deux personnes utilisant un même relais public).
La deuxième de ces limites est d'ordre conceptuel : une identification par IP tend à produire un univers où l'IP fait office de référence dans l'analyse. C'est à dire qu'il est difficile de bien garder à l'esprit qu'une adresse IP ne signifie pas forcément un terminal. Ca peut paraître évident comme ça en tant que développeur mais... c'est loin d'être aussi simple à concevoir dans les faits en tant qu'administrateur.
Dans les faits, on prend rapidement le parti de traiter tous les cas ambigus de connexion à partir d'une même IP comme étant des multi-comptes, tout simplement parce que c'est une solution de facilité (dans la nébuleuse c'est notre seul indice) et parce qu'il faut être efficace face aux nombres de cas qui peuvent exploser (je dirais qu'il y avait 10% des comptes du jeu qui était des multis). Le soupçon a tendance à l'emporter sur le doute, et ça, ça craint !
Pour être un peu plus clair, à chaque fois que je devais traiter des affaires de multi-comptes ou de partages de compte supposés je me sentais vraiment mal à l'aise à justifier nos sanctions par une connexion à partir d'une même connexion (même lorsque d'autres indices corroboraient un multi-compte). En ayant conscience des limites de l'interprétation des traçages d'IP, j'étais coincé entre les besoins de justice des joueurs ("ouais, machin c'est un multi-compte !") et le principe que le doute profite à l'accusé. En somme, en se basant sur l'IP comme preuve, on est jamais sûr à 100% qu'on prend une décision juste.
Voici ma petite conclusion concernant le traçage par IP : cette solution est probablement la moins fiable des techniques et elle a tendance à nous forcer à prendre une décision (qui peut être erronée !). S'affranchir de cette donnée est impossible totalement, mais selon moi elle ne doit intervenir QUE lors de la détection des cas à analyser et ne doit JAMAIS servir de preuve. Elle n'est et reste qu'un témoin vague d'une relation entre deux comptes (relation qui peut être fortuite comme volontaire et parfois même obligatoire).
A partir de ces différents constats, j'ai décidé de chercher un autre modèle de gestion des comptes de joueurs avec différents principes :
1. Il y a dans ce nouveau modèle une distinction claire et nette entre les arguments utiles à la détection des multi-comptes supposés et ceux utiles à leur évaluation.
2. Les arguments utiles à la détection de multi-compte peuvent être : l'adresse ip, le navigateur utilisé et sa version, la géolocalisation, le mot de passe, l'adresse email, ...
3. L'argument utile à l'évaluation des multi-compte peut être : les logs d'action des joueurs.
L'utilisation des logs d'action est une solution qui permet de s'affranchir du doute lié aux limites techniques d'internet. Par exemple, dire à un joueur "je te sanctionne car tu as donné la moitié de tes ressources à un autre joueur lié à ton compte, ce qui est formellement interdit par la charte", ça ne souffre d'aucune discussion, alors que dire "je te sanctionne car il y a eu plusieurs connexions te reliant avec un autre compte", c'est nettement plus discutable (ça peut être son frère, son meilleur pote, ils peuvent s'être connectés à l'école, ...).
Cette gestion des logs implique une structure solide que je n'aborderai pas ici mais qui vaut certainement la peine de s'y intéresser. L'idée est la suivante : archiver toutes les actions pertinentes des joueurs afin de discriminer tout comportement anormal au vu du règlement.
Il y a plusieurs approches par rapport aux logs d'action :
1. Comparaison macro-chronologique : on cherche à déterminer les habitudes des joueurs (certains font toujours les mêmes actions en se connectant ou se connectent aux mêmes heures (plage horaire de jeu)). Deux joueurs se connectant toujours aux mêmes heures sont, supposément, plus susceptibles d'être des multi-comptes que deux joueurs se connectant à des heures différentes.
2. Comparaison micro-chronologique : on cherche à déterminer sur un cours laps de temps les "switchs" entre deux comptes de jeu. Ce switch se fait à la seconde près. Selon moi, c'est l'arme la plus puissante pour déterminer un multi-compte. Ca permet par exemple de voir qu'un joueur met une offre sur le marché à 15:05:10 et qu'un autre joueur la prend à 15:05:15.
L'intérêt de ces comparaisons micro-chronologiques est de mettre au jour un switch clair et net entre les deux comptes. C'est à dire qu'à aucun moment les deux comptes n'auront une activité à la même seconde ou à une ou deux secondes près.
Un développement graphique peut être particulièrement intéressant dans ce cas-ci. Exemple (joueur 1 en vert, joueur 2 en rouge, chaque cran représente une seconde) :
![[Image: log.png]](https://dl.dropbox.com/u/3658389/jeuweb/log.png)
3. Comparaison contextualisée : là on s'intéresse véritablement aux actions entreprises par le joueur. Il s'agit d'analyser les relations entre les actions entreprises par deux joueurs. L'un attaque un joueur, l'autre suit à chaque fois.
Ces trois approches sont complémentaires évidemment, mais selon moi les deux dernières sont plus puissantes que la première. La deuxième est particulièrement incisive et met clairement au jour le "switch" du joueur entre ces deux comptes qu'il ne peut pas gérer de façon simultanée (à moins d'avoir deux ordis et de bouger les deux souris en même temps, mais personne ne joue comme ça...).
J'ai pas encore eu l'occasion d'expérimenter cette solution à grande échelle, en dehors de prototypes et de beta de certains jeux, mais je suis persuadé que c'est la meilleure solution qui existe avec les moyens dont nous disposons actuellement. Elle permet une approche pragmatique (elle repose sur des éléments factuels non discutables) et efficace (pas cent mille choses à mettre en place). Ca me semble être un bon compromis entre le temps qu'on doit investir pour ce genre de système et les bénéfices effectifs.
J'inaugure ce sujet sur les logs d'action et sur la pertinence de ce type de système pour "lutter contre les multicomptes".
Je propose pour commencer à discuter de ce sujet de partir sur une petite réflexion personnelle. N'hésitez pas à l'enrichir, la critiquer, à apporter votre point de vue sur ce mode de détection.
Avant toute chose, il est important de préciser que tout ce qui suit provient de mon expérience d'administrateur et de développeur d'un jeu qui a comporté un bon millier de joueurs actifs au plus fort de son activité.
Cette approche est donc double : d'une part en tant que développeur je peux évaluer la charge de travail que représente la mise en place des systèmes de détection de multi-comptes et d'autre part en tant qu'administrateur je peux évaluer la pertinence des différents systèmes de détection.
Le système que j'avais mis en place au lancement de mon jeu (à l'orée 2008) reposait intégralement sur la détection par IP. Au fur et à mesure que les joueurs, et donc les "cas" de multicomptes supposés, augmentaient, je percevais les limites évidentes de ce système.
La première de ces limites est d'ordre technique : les nouveaux terminaux mobiles produisent un nombre conséquent de faux positifs (exemple : deux personnes de Free se connectant via le réseau 3G sur mon site pourront avoir la même IP, de même que deux personnes utilisant un même relais public).
La deuxième de ces limites est d'ordre conceptuel : une identification par IP tend à produire un univers où l'IP fait office de référence dans l'analyse. C'est à dire qu'il est difficile de bien garder à l'esprit qu'une adresse IP ne signifie pas forcément un terminal. Ca peut paraître évident comme ça en tant que développeur mais... c'est loin d'être aussi simple à concevoir dans les faits en tant qu'administrateur.
Dans les faits, on prend rapidement le parti de traiter tous les cas ambigus de connexion à partir d'une même IP comme étant des multi-comptes, tout simplement parce que c'est une solution de facilité (dans la nébuleuse c'est notre seul indice) et parce qu'il faut être efficace face aux nombres de cas qui peuvent exploser (je dirais qu'il y avait 10% des comptes du jeu qui était des multis). Le soupçon a tendance à l'emporter sur le doute, et ça, ça craint !
Pour être un peu plus clair, à chaque fois que je devais traiter des affaires de multi-comptes ou de partages de compte supposés je me sentais vraiment mal à l'aise à justifier nos sanctions par une connexion à partir d'une même connexion (même lorsque d'autres indices corroboraient un multi-compte). En ayant conscience des limites de l'interprétation des traçages d'IP, j'étais coincé entre les besoins de justice des joueurs ("ouais, machin c'est un multi-compte !") et le principe que le doute profite à l'accusé. En somme, en se basant sur l'IP comme preuve, on est jamais sûr à 100% qu'on prend une décision juste.
Voici ma petite conclusion concernant le traçage par IP : cette solution est probablement la moins fiable des techniques et elle a tendance à nous forcer à prendre une décision (qui peut être erronée !). S'affranchir de cette donnée est impossible totalement, mais selon moi elle ne doit intervenir QUE lors de la détection des cas à analyser et ne doit JAMAIS servir de preuve. Elle n'est et reste qu'un témoin vague d'une relation entre deux comptes (relation qui peut être fortuite comme volontaire et parfois même obligatoire).
A partir de ces différents constats, j'ai décidé de chercher un autre modèle de gestion des comptes de joueurs avec différents principes :
1. Il y a dans ce nouveau modèle une distinction claire et nette entre les arguments utiles à la détection des multi-comptes supposés et ceux utiles à leur évaluation.
2. Les arguments utiles à la détection de multi-compte peuvent être : l'adresse ip, le navigateur utilisé et sa version, la géolocalisation, le mot de passe, l'adresse email, ...
3. L'argument utile à l'évaluation des multi-compte peut être : les logs d'action des joueurs.
L'utilisation des logs d'action est une solution qui permet de s'affranchir du doute lié aux limites techniques d'internet. Par exemple, dire à un joueur "je te sanctionne car tu as donné la moitié de tes ressources à un autre joueur lié à ton compte, ce qui est formellement interdit par la charte", ça ne souffre d'aucune discussion, alors que dire "je te sanctionne car il y a eu plusieurs connexions te reliant avec un autre compte", c'est nettement plus discutable (ça peut être son frère, son meilleur pote, ils peuvent s'être connectés à l'école, ...).
Cette gestion des logs implique une structure solide que je n'aborderai pas ici mais qui vaut certainement la peine de s'y intéresser. L'idée est la suivante : archiver toutes les actions pertinentes des joueurs afin de discriminer tout comportement anormal au vu du règlement.
Il y a plusieurs approches par rapport aux logs d'action :
1. Comparaison macro-chronologique : on cherche à déterminer les habitudes des joueurs (certains font toujours les mêmes actions en se connectant ou se connectent aux mêmes heures (plage horaire de jeu)). Deux joueurs se connectant toujours aux mêmes heures sont, supposément, plus susceptibles d'être des multi-comptes que deux joueurs se connectant à des heures différentes.
2. Comparaison micro-chronologique : on cherche à déterminer sur un cours laps de temps les "switchs" entre deux comptes de jeu. Ce switch se fait à la seconde près. Selon moi, c'est l'arme la plus puissante pour déterminer un multi-compte. Ca permet par exemple de voir qu'un joueur met une offre sur le marché à 15:05:10 et qu'un autre joueur la prend à 15:05:15.
L'intérêt de ces comparaisons micro-chronologiques est de mettre au jour un switch clair et net entre les deux comptes. C'est à dire qu'à aucun moment les deux comptes n'auront une activité à la même seconde ou à une ou deux secondes près.
Un développement graphique peut être particulièrement intéressant dans ce cas-ci. Exemple (joueur 1 en vert, joueur 2 en rouge, chaque cran représente une seconde) :
3. Comparaison contextualisée : là on s'intéresse véritablement aux actions entreprises par le joueur. Il s'agit d'analyser les relations entre les actions entreprises par deux joueurs. L'un attaque un joueur, l'autre suit à chaque fois.
Ces trois approches sont complémentaires évidemment, mais selon moi les deux dernières sont plus puissantes que la première. La deuxième est particulièrement incisive et met clairement au jour le "switch" du joueur entre ces deux comptes qu'il ne peut pas gérer de façon simultanée (à moins d'avoir deux ordis et de bouger les deux souris en même temps, mais personne ne joue comme ça...).
J'ai pas encore eu l'occasion d'expérimenter cette solution à grande échelle, en dehors de prototypes et de beta de certains jeux, mais je suis persuadé que c'est la meilleure solution qui existe avec les moyens dont nous disposons actuellement. Elle permet une approche pragmatique (elle repose sur des éléments factuels non discutables) et efficace (pas cent mille choses à mettre en place). Ca me semble être un bon compromis entre le temps qu'on doit investir pour ce genre de système et les bénéfices effectifs.
![[Image: banner.png]](http://www.laluciole.me/wp-content/uploads/2013/02/banner.png)
J'améliorerai la présentation à la fin du mois, quand j'aurai un maximum de retours et de contributions 
