Boostadopt


July 5, 2015 - retour d'experience -


logo AdopteUnMec Tout ce projet est visible sur GitHub

Pendant de nombreuses années et depuis l’ouverture de ce site de rencontre j’ai été utilisateur du site AdopteUnMec.com (ce n’est plus le cas maintenant ;-) ). Ce site a un concept assez particulier lui ayant permis de se démarquer : les hommes possèdent un nombre de charmes limité (un charme est semblable à un poke sur Facebook), la personne recevant un charme d’un autre utilisateur est notifiée de ce charme. Elle peut ensuite autoriser ou non, l’émetteur du charme à lui écrire des messages. Suite à cela conversation peut s’engager.

Le site AdopteUnMec a eu un business model assez mouvant depuis sa création puisqu’à l’origine gratuit il est devenu de plus en plus payant.

Je ne souhaitais pas payer pour avoir accès à ce site et j’ai eu la chance d’avoir crée un compte dès le lancement du site. J’ai donc pu avoir un accès gratuit à certaines fonctionnalités.

Un jour (en 2010) je me suis rendu compte par un test tout simple (création d’un profil “femmes”) que les profils d’hommes ayant un compte gratuit remontaient beaucoup moins dans les résultats de recherches. Je n’ai toutefois pas réussi à déterminer l’algorithme en place derrière. Afin d’optmiser mes chances sur ce site j’ai élaboré une autre théorie : si je visite 100 profils et que ma fiche est intéressante alors un pourcentage (15% - ) va venir la lire, et parmis ces 15% une faible proportion va m’autoriser à lui écrire. Au final sur 100 filles, 3 ou 4 vont m’autoriser à leur écrire. Très intéressé par les études et les statistiques je souhaitais mettre en place un système d’analyse et de remontée de ces stats mais je n’en ai pas eu le temps.

Une autre idée m’est venue en tête : au lieu de visiter manuellement ces profils (ce qui est une tâche rébarbative et longue), si je réalisais un programme faisant le travail à ma place ? Je me suis donc lancé dans la réalisation d’un script visitant automatiquement en peu de temps des profils définis selon plusieurs paramètres.

Initialement mon script faisait un travail classique : il simulait une connexion via le formulaire HTMl puis visitait les profils en chargeant les pages HTML des profils. Après un temps d’utilisation je me suis rendu compte de plusieurs choses : *les profils HTML étaient longs à charger. Normal c’est une page HTML donc plusieurs centaines de KiloOctet à chaque fois. *l’accès au site AdopteUnMec à travers la version “desktop” était restreinte entre 18h et 1h du matin, cela réduisait le temps d’utilisation potentiel du script.

Suite à cela je me suis rendu compte que l’application Android d’AdopteUnMec ne subissait pas de blocage entre 18h et 1H du matin (toujours pour le même compte bloqué sur la version “desktop” du site). La conclusion est simple : si l’application Android arrive à visiter cela alors mon script pourra le faire.

J’ai alors ouvert Wireshark qui est un utilitaire qui permet de capturer les packets passant sur le réseau. Pour vulgariser : ce logiciel permet de voir en partie les données transitant entre les ordinateurs du réseau observé. Pendant ce temps j’ai utilisé l’application Android sur tous les cas possibles : connexion, déconnexion, recherches, visites, charmes, envois de messages. Le but était d’obtenir toutes les urls appelées et les paramètres (les données que l’on donne à ces urls afin d’obtenir ce que l’on souhaite : l’identifiant du profil, les paramètres de recherches , etc).

Une fois toutes ces informations récupérées j’ai pris le temps de reconstruire tout mon script autour de cette API : au final les requêtes sont devenues plus rapides. En effet l’API retourne du JSON qui est donc rapidement exploitable par le serveur PHP alors qu’auparavant il fallait parser du HTML.

Une fois cela effectué tout était presque réglé : il y avait seulement des améliorations visant à ne pas être blacklisté par AdopteUnMec. Initialement cela était basé sur la fréquence des visites (si le temps était inférieur à 2 ou 3 secondes le compte pouvait être bloqué).

Puis vint un jour où j’ai voulu réaliser et monétiser une webapp à destination de tous les utilisateurs d’AdopteunMec. Le but de cette application était d’avoir une interface propre et épurée permettant de lancer automatiquement des visites sur un type de profil déterminé par la recherche. J’ai nommé le fait de visiter rapidement plusieurs dizaines de profils déterminés “Booster”. Suite à cela j’ai appelé mon application “BoostAdopt.com”. Ma recherche de nom de domaine a été très rapide mais une fois effectuée je me suis aperçu qu’existait déjà le nom de domaine “boostAdopte.com”. Ce dernier avait été désactivé avant d’acheter le nom que j’avais choisis.

Architecture du projet

Avant de foncer tête baissée j’ai réfléchi à toutes les problématiques que j’aurai à affronter sur ce projet.

Le premier problème fut le suivant : alors que j’enregistrais automatiquement les profils visités au bout de 100 000 hits (visites) l’IP du serveur appelant a été blacklistée. En clair mon serveur n’avait plus accès aux serveurs d’AdopteUnMec. même si un utilisateur n’allait pas faire 100 000 visites d’un coup , admettons que 1000 utilisateurs fassent 100 visites chacun et le service était bloqué. Sur le papier il devint donc dur de proposer un service qui pourrait s’arrêter du jour au lendemain. Une solution aurait pu être de changer d’IP une fois chacune d’entre elle blacklistée mais cela aurait été coûteux et aurait rendu le site peu fiable qualitativement parlant. L’expérience utilisateur pour ceux qui se retrouvent bloqués le temps du changement d’IP aurait été peu appréciée. Imaginez qu’un utilisateur paie, lance le booster et se retrouve bloqué car le serveur vient d’être blacklisté : çela aurait été très problèmatique.

Pour schématiser l’architecture précédemment citée : les utilisateurs exécutaient du PHP sur mon serveur, ce dernier appelait les serveurs d’AdopteUnMec. C’est une seule IP, celle du serveur (ou à la rigueur quelques IPs si plusieurs serveurs).

Quelques jours plus tard me vint une idée un peu plus folle: que ça soit l’IP propre à chaque utilisateur qui appelle le serveur AdopteUnMec. Cela a beaucoup d’avantages : je n’ai pas de changement d’IP à faire et le service reste fiable. L’inconvénient majeur est qu’il faut donner le code “métier” du côté du navigateur donc facilement imitable et donc le business deviendrait réduit ou inopérant. En effet n’importe qui pourrait réutiliser le code et le mettre à disposition gratuitement d’autres utilisateurs.

L’idée finale concernant l’architecture de boostAdopt fut donc de créer une extension Chrome, une application côté serveur et un client Front. Ici l’extension Chrome est utilisée car elle permet au navigateur de contacter directement les serveurs d’AdopteUnMec sans passer par un serveur intermédiaire. Normalement faire cela à travers le navigateur provoquerait une erreur de type “Cross-Origin” (le serveur xxx.com ne peut pas être appelé par la page yyy.com, il faut qu’xxx.com autorise cela spécifiquement). Il suffit de spécifier les bons attributs dans le manifest de l’extension afin de permettre cela. Le point négatif de cette architecture est la restriction sur le navigateur (utilisation obligatoire de Chrome), ainsi que l’installation de l’extension. Ce sont autant d’actions qui peuvent rebuter le futur utilisateur.

La propriété “Permissions” qui permet à l’extension de contacter les serveurs d’AdopteUnMec sans générer d’erreur “Cross-Origin” :

Afin de minimiser les actions “utilisateur” j’ai crée un compte développeur “Chrome” (et en payant) afin de publier l’extension officiellement dans le catalogue officiel Chrome. En quelques clics l’extension pouvait désormais être opérationnelle dans le navigateur de l’utilisateur.

Business model

Le business model de boostAdopt est assez simple : l’application utilisait un système de crédits. Un crédit = une visite d’un profil. Lors de l’inscription de l’utilisateur son compte était crédité de 500 unités. Cela permet à l’utilisateur de tester le service le temps nécessaire afin de se faire son opinion. Ensuite plusieurs forfaits de crédits étaient proposés avec des prix dégressifs. J’utilisais payPal et son API afin de gérer les transactions.

Communication

Ca ne sert à rien de développer un projet si personne ne l’utilise faute de communication il fallait donc communiquer sur le projet. Contrairement à de gros projets, ici le budget “Communication” était très faible. La communication autour du projet s’est faite grâce à plusieurs leviers : - l’utilisateur avait la possibilité de parrainer des contacts en leur fournissant un code de parrainage. A chaque contact inscrit il recevait une centaine de crédits. C’est un moyen peu onéreux de communiquer sur le projet, une sorte de bouche à oreille monétisé. - un compte Twitter et une page Facebook afin de parler du projet. - la réalisation de robots automatiques qui se connectaient à AdopteUnMec avec un profil féminin puis envoyait un message simulant un être humain en proposant de se connecter à boostAdopt.

Ce dernier point avait toutefois quelques points noir vis à vis de l’expérience utilisateur. - la messagerie d’AdopteUnMec à ce moment ne permettait pas de publier des liens cliquables, c’était donc un frein à l’action puisque l’utilisateur devait faire un copier/coller de l’URL. - même avec quelques adaptations un robot ne remplace pas l’Homme, mes comptes étaient blacklistés au bout de quelques messages. Il fallait donc en recréer.

Concernant la messagerie : AdopteUnMec propose une messagerie classique mais aussi une messagerie instantanée. En décembre 2013 après quelques tests rapides je me suis aperçu que les liens cliquables étaient autorisés dans cette messagerie instantanée. Pire : il y avait même une belle faille XSS permettant d’injecter du Javascript. Pour mon usage cela m’aurait permis de rediriger automatiquement les utilisateurs vers boostAdopt. Pour des esprits malveillants ça aurait pu permettre de propager du code malicieux et de récupèrer les identifiants bancaires puisque ceux-ci apparaissaient sur le site. Lors du lancement de boostAdopt ce gros problème de sécurité était résolu.

Après discussion avec d’éventuels utilisateurs ces derniers m’ont fait part de craintes vis à vis de l’application BoostAdopt.com. En effet, mon application aurait pu être un simple phishing ayant pour but de voler les identifiants. Afin de diminuer ces craintes j’ai réalisé une vidéo expliquant le fonctionnant de boostAdopt.com

PS : désolé pour l’effet “ressort” dans la vidéo, le logiciel n’était pas des plus puissants.

Internationalisation

Après des recherches un peu plus poussées je me suis rendu compte que le site AdopteUnMec était ou allait être disponible dans de nombreux pays (Angleterre, Allemagne, Italie, Espagne, Mexique, etc etc). Quitte à faire une application autant maximiser les cibles. Après quelques tests je me suis aperçu que tout mon code était fonctionnel sur ces versions étrangères, seules les URLs étaient différentes. J’ai donc pris quelques heures afin d’adapter et d’ouvrir l’application à tous les pays où se trouve AdopteUnMec.

Post Mortem - Fin du projet.

AdopteUnMec a amélioré énormément son protocole de sécurité en blacklistant les comptes “spammeurs” mais aussi en bloquant les IPs de connexion. Si mon compte X se retrouve bloqué, son IP “X” l’est aussi. Si je tente de me connecter ou bien même de m’inscrire avec un nouveau compte ce dernier se retrouvait automatiquement blacklisté. Cette mesure m’a obligé à réduire la communication à travers ces robots “spammeurs”.

Enfin j’ai reçu une lettre de mise en demeure du service juridique d’AdopteUnMec. Bien que j’estimais très peu de points fondés, diverses raisons associées à la lourdeur administrative m’ont fait arrêter ce projet.

Si vous avez bien lu vous avez dû voir qu’à un moment j’enregistrais automatiquement les profils. Ceci est un autre projet “map.boostadopt.com” qui fera l’objet d’un autre billet. Au programme : de la cartographie et des “datas” (sans parler de “big data”).

comments powered by Disqus