 Je travaille pour 180. J'ai commencé avec les autres comme développeurs front-end. Je suis en train de passer à Product Manager. Je vais vous parler un peu, c'est quoi 180? Je présente un peu nos défis qu'on a rencontrés. Je présente un peu la stack technologique, sans trop rentrer dans le détail. Après ça, on va passer à autre chose. Donc, qu'est-ce que le Peer Learning? C'est un peu une démocratisation de l'apprentissage. C'est mon learning for everyone pour tout le monde et sur à peu près n'importe quoi. Ce que ça permet de faire, c'est d'avoir une expérience individualisée par rapport à l'apprentissage. On passe dans un cadre académique où on a un prof versus une classe. Là, c'est vraiment du 1 à 1. Le contenu est adapté lorsqu'on rencontre un individu. C'est très empowering parce que tout le monde peut devenir un professeur ou enseigner quelque chose soit par son expérience dans le passé, sa carrière ou peu importe parce que la personne connaît des bonnes recettes. Une statistique intéressante, je vais la laisser pour la diapositive pour plus tard. 180 comme plateforme, c'est une plateforme qui permet aux utilisateurs de présenter des offres sur le savoir qu'ils connaissent dans le but de pouvoir le partager à d'autres individus. Aussi, il y a la possibilité de créer des demandes pour pouvoir approfondir son savoir dans un certain champ d'expertise ou un domaine quelconque. La plateforme permet de faire un matchmaking ou de faciliter la rencontre entre ces différents individus. C'est ce qu'on appelle nous un brain date. 180, ça fait trois ans que ça existe. La première version était très axée sur les features. Donc, qu'est-ce que ça prend pour avoir une plateforme pour que les gens se rencontrent? Ça prend tel feature, tel feature, tel feature. Pour la version numéro 2, ils se sont reculés un peu des features pour plus penser au niveau du user experience. Qu'est-ce qui fait en sorte que les gens voudraient se rencontrer? Qu'est-ce qui fait en sorte que les gens sont actifs sur cette plateforme? Par la suite, il y a eu des contrats qui ont été faits pour, notamment, le C2 Montréal de la conférence, une plateforme de matchmaking pour les trois jours de la conférence. Il y avait souvent des périodes à dédié pour que les gens puissent faire du business development ou échanger des connaissances ou échanger sur la créativité en général. Donc, ça a été une plateforme qui a été customisée, surtout au niveau du user experience, pour vraiment venir rencontrer les besoins de cette conférence-là en particulier. Ce qui a donné suite à d'autres conférences, notamment do-a-goals où, bon, un nouveau UI a été développé, du UX a été adapté pour eux autres. Une application mobile a été prototypée dans ses débuts. Avec tout ça, dans une petite période de temps, l'équipe s'est rendu compte que, bon, ils avaient accumulé une dette technologique un peu en force de faire des produits adaptés, faire beaucoup de customisation pour chacun des clients. Et après ça, l'histoire se répète par des conférences supplémentaires qui s'ajoutent au nombre de choses que la compagnie a. Donc, des grandes leçons qu'on a appris, c'est que le cycle de déploiement de nouvelles, de new release, était beaucoup trop long. La dette technologique était difficile à faire descendre. Ça s'accumulait plus que ça descendait. La customisation pour chacun des clients, ça fait en sorte qu'à la maintenant, c'est hyper difficile. Toute nouvelle conférence, toute nouvelle demande de conférence gérer les attentes des clients, gérer la réception des contenus, la mise en page, ça prenait tout le temps de l'équipe. Puis, ils sont rendus compte qu'il faut convertir un intérêt pour la plateforme versus quelqu'un qui participe activement à la plateforme. Ça prend plus que de la technologie. Donc, la nouvelle stratégie, c'était d'avoir un court base qui est partagé à travers toutes les instances, donc plus de codes custom pour un client versus un autre. Essayer d'automatiser la customisation, donc offrir des carcans bien définis aux clients puis de l'exprimer clairement que c'est là-dedans que tu peux jouer, mais that's it. Avoir du versioning sur l'appli, surtout lorsqu'on arrive pour développer les produits web versus l'application mobile. Toujours améliorer nos processus agile, nos processus lean, s'assurer qu'on a une meilleure assurance qualité au niveau du code, donc instaurer du code review, essayer à tout prix d'avoir de la dette technologique, prendre plus son temps avant de déployer des features ou promettre des features à des clients et la synergie de nos produits. Petite parenthèse, c'est la synergie de produits. Un exemple concret, c'est si on développe un feature pour le produit de conférence ou pour les conférences, on devrait pouvoir facilement le transférer vers la plateforme publique et vice-versa, ce qui fait en sorte qu'on maximise les énergies qui sont mis à développer des nouvelles features en pensant qu'elle doit ou elle devrait fonctionner sur tous nos différents produits puis ça nous permet de garder un momentum pour relancer les produits ou s'assurer que nos produits sont à jour. Ce qui s'en vient dans les prochains mois, je dirais 3 à 4 prochains mois, c'est une nouvelle version de notre plateforme publique qui présentement a la V3, donc nouveau code qui est en ligne, une nouvelle expérience aussi. On veut continuer d'améliorer sa plateforme. Le produit de conférence qui va être lancé insécemment, après, on a le concept de groupe privé pour des entités. Après ça, un dashboard pour faire le monitoring, pour faire la gestion des utilisateurs, pour voir nos statistiques, l'application mobile finale, non le prototype serait lancé. Et après ça, on a le concept d'espace affilier ou ce serait des espaces, commandes-t-il pour créer des... ou recevoir des rencontres 180 ou des endroits propices à créer des rencontres 180. Voilà, en parlant un peu de la technologie qu'on a en arrière chez le 180, la dernière qu'on a, note à préciser, je ne suis pas un développeur piton, donc je vais faire mon possible pour vous la présenter. La dernière fois que j'ai fait du piton, c'est en plombes 2.1, ce qui est à peu près circa 2005-2006. Donc ça date un peu. Donc si je commence par le backend, on a Django 1.6, une base donnée en progrès SQL. On utilise Django REST Framework pour la pays, très utile. Après ça, on a l'elastic search d'Amazon, celerie pour le tasking, j'adore le nom, je ne sais pas trop ce que ça fait par contre. Century Pure Event pour le monitoring, donc dès qu'il y a des erreurs 500 au niveau serveur ou des erreurs 404 ou des bugs côté front-end, nous on reçoit ces informations-là sous forme d'alerte. Pour notre système d'emailing, automatisé, basé sur des événements si je ne me trompe pas. Au niveau du front-end, coffee script, pour accélérer notre développement de JavaScript, il nous assurait un peu une meilleure qualité de notre code. WeCore IGS pour gérer nos différentes dépendances sur nos vues, nos packages. Marionette, qui est une saveur de backbone, on utilise Compas et CSS pour compléter nos CSS de façon plus programmatique, calmant. BoostShot pour gérer notre UI, P-grunt pour compiler le tout. Au niveau d'infrastructure, on déploie avec Fabrik, on a du Unicorn and GenX, on est hosté chez Amazon et notre user generated content et nos fichiers statiques, le front-end est hosté chez Amazon via le CloudFront. C'est tout, mais un 180 aimerait vous connaître. Donc, si ça vous tente, joignez la plateforme, participez, donnez-nous votre feedback, il y a moyen de le faire via la section support. Si ça vous tente, venez nous voir avec l'équipe à n'importe quel moment, ou tantôt au Benelux. Sinon, il y a le startup open-house le 30 octobre, participez. On regarde toujours du talent pour venir travailler avec nous et sur ce, merci beaucoup.