Peter est né en novembre 2016. En mêlant l’intelligence artificielle et les compétences de professeurs sélectionnés, ce service sur mobile répond aux questions des élèves, de la 6ème à la terminale, et les aide dans leurs devoirs. Le succès a été fulgurant, posant de nombreux problèmes et nécessitant de revoir extrêmement rapidement l’architecture, dimensionnée pour beaucoup moins d’utilisateurs.

« Dès le lendemain de l’annonce de Messenger Platform, qui introduisait les bots dans Facebook Messenger, nous nous sommes demandé lequel nous ferait rêver. Très vite, l’idée d’un bot d’aide aux devoirs s’est imposée. Jean-Sébastien, Stephen et moi avons lancé un premier test en mai 2016. Suite à son accueil très positif, nous avons amélioré le service jusqu’à proposer de délivrer de vrais cours particuliers et nous avons cherché à augmenter le nombre d’utilisateurs. Mission accomplie grâce au soutien d’AWS. »

  • Des serveurs qui s’adaptent à la charge
  • Un support très disponible et réactif
  • Plus de 300 000 utilisateurs supplémentaires en une semaine

« Un mois et demi après avoir lancé Peter, nous avions environ 800 élèves et 300 professeurs inscrits. Au début des vacances de Noël, alors que l’activité de Peter était la plus faible, nous avons mis en place une technique de growth hacking par le biais d’une file d’attente : partager Peter et donc inciter ses amis à s’y inscrire permettait de remonter dans cette file d’attente afin d’essayer le service, rappelle Stephen Zambaux, founder & CTO de Peter. À ce moment-là, nous étions déjà clients d’AWS et avions une utilisation très simple de leurs services : un seul serveur, le t2.micro, compris dans l’offre gratuite. Je déposais mes sources sur cette instance, je lançais mon application à la main. À chaque mise à jour, j’allais chercher mes fichiers et je relançais mon application : rien n’était automatisé. »

Au premier jour du service, Peter a été visité par 16 utilisateurs, puis 64 le jour suivant, jusqu’à ce que le nombre d’inscrits explose : 40 000 en un jour. Le nombre d’utilisateurs en une journée est monté jusqu’à 90 000. « L’architecture n’était pas prévue pour un tel nombre et le serveur a lâché, en plein repas de Noël. C’était une catastrophe, raconte Stephen Zambaux. 300 000 utilisateurs tapaient à la porte et le service était arrêté. Il était capital pour nous de pouvoir remettre en place le service rapidement. Pour trouver une solution, nous nous sommes alors tournés vers AWS en espérant qu’ils puissent nous aider à régler notre problème. »

« Entre Noël et le 1er janvier, la semaine de l’année où trouver quelqu’un de disponible est le plus compliqué, j’ai pu échanger avec des ingénieurs très compétents d’AWS. Ils m’ont aidé à monter une architecture qui n’a pas bougé depuis, précise Stephen Zambaux. Avant même de la remettre en question, nous avons relancé le service au plus vite en dupliquant notre programme sur plusieurs serveurs plus conséquents. Cette solution a permis de répondre à l’urgence mais n’était pas viable sur le long terme, l’application nécessitant de véritables mises à jour. »

Toujours aidé d’AWS via son Business Support, Stephen Zambaux a ensuite analysé les raisons qui expliquaient les difficultés à gérer cette croissance. « Il s’est avéré que nos bases de données (BDD) étaient trop lentes car nous n’utilisions pas celles fournies par AWS. J’avais des BDD dans des conteneurs Dockers à l’intérieur de mon serveur. Comme sur ce même serveur se trouvait aussi l’application, nous manquions de processeurs pour répondre à la demande ». Après avoir augmenté le nombre de serveurs pour y répondre, le service a été complètement rétabli en deux jours.

Restait enfin un dernier problème lié aux API Facebook à résoudre : « Lorsqu’un service est indisponible, elles gardent toutes les actions des utilisateurs en mémoire. Lorsqu’il redémarre, elles renvoient ces actions. Plus le retard augmente, plus la masse à traiter sera conséquente au redémarrage avec le risque de faire tomber les serveurs à nouveau », ajoute Stephen Zambaux.

« Les échanges avec le support d’AWS ont représenté un gain de temps énorme. J’expliquais mon problème, l’ingénieur analysait mon besoin et revenait vers moi au bout de 30 mn avec la procédure à tester. Nous avons itéré ainsi dès que j’avais une problématique, explique Stephen Zambaux. La plus importante a été de savoir comment faire pour augmenter le nombre de Dockers en fonction de la demande : quels prérequis dans l’application, comment configurer le load balancer d’AWS, comment configurer les services dans Amazon ECS… Aujourd’hui, AWS CodeBuild fabrique mes images Dockers, installées dans ECS Registry. Nous y créons ensuite des services qui déploient les instances Dockers sur des instances Amazon EC2. »

Après avoir géré les urgences, Peter a mis en place une chaîne d'intégration continue pour intégrer régulièrement les modifications de code à un référentiel centralisé, entraînant automatiquement des opérations de création et test. « Je n’ai plus à me soucier de l’architecture. Je code, j’envoie et la mécanique d’AWS construit tout ce qu’il faut déployer sur les serveurs. En complément, le nombre d’instances Dockers est déployé en fonction de la charge », précise Stephen Zambaux.

Peter utilise également Amazon CloudWatch pour surveiller les ressources du cloud d’AWS et des applications exécutées sur AWS. « Nous avons 8 containers Dockers, chacun avec une problématique métier différente. CloudWatch nous facilite la vie en cas de problème. »

« La qualité et la rapidité de réponse d’AWS nous ont véritablement sauvé la mise, juge Jérémy Brunet. Sans eux nous n’aurions jamais pu réutiliser cette technique de growth hacking et accélérer ainsi notre croissance. Si nous n’avions pas réglé le problème, nous serions restés au même nombre d’utilisateurs qu’avant les vacances, sans compter leur mécontentement à gérer. Lorsque Facebook nous demandait des modifications sur l’application, il fallait être en mesure de la livrer corrigée dans l’heure. Tout ce qui a été mis en place avec AWS a permis d’être extrêmement réactif dans la réponse aux règles. »

La prochaine étape pour les équipes de Peter : mettre leur service à disposition de toutes les personnes inscrites sur liste d’attente. En 2017, ils souhaitent également couvrir le plus de matières scolaires possible et internationaliser leur service. Ils recrutent actuellement des milliers de tuteurs qualifiés. « Nous projetons également d’ouvrir Peter aux étudiants post-bac. Une levée de fonds est en cours afin de nous permettre de nous développer », conclut Jérémy Brunet.