Les webinaires et autres conférences en ligne sont de plus en plus nombreux, particulièrement depuis le début du confinement. Généralement organisés sur des logiciels de visioconférences comme Zoom, nous souhaitions nous démarquer en proposant un format plus proche d’une conférence, un peu à la façon de TED (oui, sacrée ambition !) : un speaker mis en valeur, traité comme un invité de marque, dont la conférence pourrait être visionnée par plusieurs centaines de participants en même temps.

Cela écarte donc d’office tous les logiciels de visioconférences qui sont limités dans leur nombre de participants et ne mettent pas un participant particulièrement en valeur. Vers quoi se tourner alors ? Il se trouve qu’un secteur est particulièrement en avance sur ces questions de diffusion live : le jeu-vidéo. En effet, des plateformes comme Twitch accueillent chaque jour des millions de spectateurs, analysant et applaudissant les skills des joueurs les plus en vogue sur Fortnite, League of Legends ou encore Overwatch.

Face à ce marché en pleine expansion, de nombreuses entreprises se sont lancées sur ce créneau, proposant des technologies et logiciels très accessibles pour pouvoir lancer son propre stream de joueur. Une aubaine pour BeeMyDesk !

Plusieurs plateformes proposent aujourd’hui de diffuser de la vidéo en direct. Nous avons éliminé d’office Twitch, qui est orienté essentiellement vers le jeu-vidéo ainsi que Facebook et Instagram, pas suffisamment business. LinkedIn est actuellement en train de déployer sa solution petit à petit, mais nous n’avons pas encore la chance d’être sélectionnés.

Notre choix s’est donc naturellement porté sur YouTube : un acteur majeur, connu du grand public et qui ne nécessite pas de compte pour regarder les vidéos. De plus, il est possible de proposer les replays immédiatement après la fin de la diffusion, directement sur la chaine.

Une fois la plateforme sélectionnée, il faut ensuite s’intéresser au logiciel pour produire le contenu en lui-même. On parle d’encodeur logiciel. YouTube propose bien un outil intégré, mais il se cantonne à diffuser la webcam, ce qui est largement insuffisant pour notre besoin. La contrainte dans notre cas est qu’il nous fallait un logiciel capable d’intégrer un intervenant lui-même à distance.

On peut distinguer deux catégories de logiciels : les logiciels traditionnels à installer sur son ordinateur ou les services en ligne accessibles depuis le navigateur. La seconde catégorie est souvent plus moderne et plus accessible aux novices (ce que nous étions !), c’est pourquoi nous avons d’abord opté pour l’un de ces services en ligne.

Premières armes avec un service en ligne

Nous en avons essayé deux : Stage Ten et Lightstream Studio. Tous deux étaient effectivement très facile d’accès et nous ont permis de lancer un live très rapidement sur YouTube. Après plusieurs essais, nous avons finalement adopté Lightstream Studio, car il permettait plus simplement d’intégrer le partage d’écran, indispensable pour nos speakers qui souhaitent passer un slide pendant leur intervention.

Nous avons réalisé nos trois premiers talks à l’aide de Lightstream Studio. Malheureusement, à l’issue de ceux-ci, le bilan n’était pas satisfaisant :

Les essais que nous faisions avec nos intervenants prenaient beaucoup de temps, car nous rencontrions beaucoup de problèmes de compatibilité en fonction du navigateur, du système d’exploitation, qui étaient parfois difficiles à résoudre.

Pendant le live, nous devions faire très attention à ce que nous faisions, au risque de lancer un autre plan ou de casser quelque chose. Globalement, l’équilibre semblait fragile et le moindre faux pas pouvait tout faire s’écrouler.

Pendant notre premier talk, nous n’avons malheureusement pas pu avoir le retour caméra de Jean Pouly, alors que cela fonctionnait parfaitement pendant les tests.

Lors de notre troisième talk avec Jean-François Fontana, le logiciel refusait carrément de lancer le live sur YouTube. Nous avons dû nous résoudre à passer sur un live Facebook en dernière minute.

Au bout de trois talks, nous avons donc décidé que cette solution ne répondait pas à nos attentes en termes de qualité et de fiabilité.

Même si le bilan était un peu sombre, cela nous a tout de même permis de monter en compétences et d’avoir les idées plus claires sur notre organisation.

Premièrement, afin de ne pas perdre trop de temps en tests avec nos intervenants et limiter au maximum les problèmes techniques, il fallait que l’on puisse les contacter via des solutions connues de tous et éprouvées. En cherchant un peu, nous avons découvert l’existence de la technologie NDI. Pour simplifier, il s’agit d’un protocole de communication permettant de faire passer un flux audio/vidéo sur un réseau local. Et par chance, Skype est compatible NDI ; ce qui signifie qu’il offre un accès via ce protocole au flux vidéo d’un correspondant. Bien qu’un peu passé de mode face à Zoom ou Microsoft Teams, Skype reste un logiciel connu de tous et largement utilisé. Cela répondait donc à notre premier besoin. Premier critère donc : un encodeur logiciel compatible NDI.

La technique du NDI est la plus efficace pour intégrer un appel visioconférence dans un flux live. Si vous regardez l’émission de cuisine en direct de Cyril Lignac “Tous en cuisine” sur M6, vous remarquerez que les familles sont contactées via Skype 😉

Deuxièmement, nous avions besoin d’un logiciel robuste qui ne chamboule pas tout le live au moindre clic malheureux. Si en plus il permettait d’aller plus loin dans la mise en scène et les possibilités, c’était encore mieux.

Ces prérequis nous ont laissé trois choix : Open Broadcaster Software, XSplit Broadcaster et Wirecast. Utilisant un Mac, nous avons opté pour Wirecast.

Alors bien sûr, la prise en main a été un peu plus complexe mais, au bout de 25 talks, nous n’avons eu à subir aucun problème majeur. Les tests avec nos intervenants ont été réduits à moins de 5 minutes en moyenne avec une procédure simplissime : appelez-moi sur Skype. C’est tout.

La partie logicielle est essentielle, mais le matériel n’est pas à négliger. Il faut bien avoir en tête qu’encoder un flux vidéo en direct demande beaucoup de ressources. C’est pourquoi il est fortement recommandé d’avoir un ordinateur avec une carte graphique dédiée, qui est un composant conçu pour les tâches comme l’encodage vidéo. Sans cela, la vidéo risque d’être saccadée.

Deuxièmement, une connexion fibre (ou une très bonne VDSL) semble indispensable. Le problème de l’ADSL est que les vitesses en envoi de données (upload) sont extrêmement lentes. Or, ici, l’upload est essentiel puisque vous devez envoyer un flux vidéo en direct, dans une qualité correcte. Sans compter qu’il faut aussi prendre en compte la connexion Skype avec le speaker qui elle aussi va prendre sa part de bande passante.

Toujours concernant la connexion, privilégiez l’utilisation d’un câble Ethernet au lieu du Wi-Fi. Pourquoi ? Le Wi-Fi peut être perturbé par énormément de facteurs et votre débit peut varier considérablement d’un moment à l’autre. Si cela n’a pas d’incidence lors d’une utilisation internet “normale”, cela en a lors d’une diffusion live qui a besoin d’un lien stable. De plus, vous pourrez profiter de la véritable puissance de ce que votre connexion a à offrir. C’est particulièrement impressionnant sur une connexion fibre :

À ce sujet, veillez également à la catégorie de vos câbles Ethernet. En effet, cette catégorie indique le débit maximum que le câble est capable de supporter. Pour une connexion 1 Gigabit, il faut des câbles de catégorie 6 minimum (même si a priori, c’est devenu la norme).

Peut-être que cela va sembler évident, mais on ne le rappellera jamais assez : faites des tests !

Avant de lancer votre premier live, il est essentiel de bien tester votre logiciel, de voir l’effet de telle ou telle fonctionnalité. Mon conseil : avoir à côté de son ordinateur sa tablette ou son smartphone avec le live ouvert pour vérifier que le son et l’image fonctionnent correctement.

De la même manière, nous ne coupons jamais à un essai avec nos intervenants avant le jour de leur talk. Même si un appel Skype semble une formalité, l’expérience nous a montré que cela permet d’éviter beaucoup de problèmes le jour J (configuration du micro, positionnement dans la pièce, etc.). C’est encore plus vrai si l’intervenant souhaite partager son écran.

C’est là aussi que vous pourrez constater la qualité de connexion de votre interlocuteur et voir avec lui s’il est possible de l’améliorer si elle n’est pas satisfaisante : utilisation d’un câble (cf. le point précédent) ? Se rapprocher du Wi-Fi ? Utiliser une connexion 4G, parfois meilleure que de l’ADSL ?

Malgré le meilleur logiciel, le meilleur matériel et des tests exhaustifs, les professionnels du spectacle le savent : les problèmes arrivent. Vous rencontrerez forcément des problèmes à un moment ou un autre. Mais show must go on : soyez prêts à y faire face. C’est avec l’expérience que vous apprendrez à les gérer, mais voici quelques conseils tout de même :

Restez calme. C’est facile à dire quand 200 personnes vous regardent et que tout s’écroule, mais c’est en gardant les idées claires que vous trouverez des solutions.

Annoncez clairement à votre auditoire qu’il y a un problème. Inutile de cacher la vérité, les spectateurs ont probablement déjà remarqué que quelque chose cloche. D’une part, cela vous permettra de diminuer la pression et d’autre part cela rassurera le public que vous êtes conscient du problème et que vous allez faire quelque chose. Vous constaterez aussi que les gens sont extrêmement bienveillants et pardonneront ces problèmes techniques.

À l’issue du live, réalisez un post-mortem : comprenez le problème, les raisons de sa provenance et notez les étapes qui vous ont permis de le résoudre.

Malgré tout, il y aura peut-être des fois où vous ne serez pas en mesure d’assurer votre direct. Personne n’est à l’abri d’un technicien opérateur peu scrupuleux qui débranche votre arrivée fibre optique dans les sous-sols de votre immeuble (oui, c’est du vécu !). Dans ces cas-là, il est encore une fois essentiel de communiquer avec votre public pour expliquer le problème et annoncer l’annulation.

Voilà nos conseils pour mettre en place un live fonctionnel. Bien sûr, nous n’avons évoqué que la partie purement technique de l’opération. L’essentiel évidemment reste le contenu que vous allez proposer et le style que vous allez donner à votre émission. À vous de jouer !

Depuis un peu plus d'un mois, nous proposons les Talks par BeeMyDesk : un format de conférences en ligne qui permet à nos meilleurs experts de s'exprimer sur des thématiques ciblées pour les entrepreneurs. Comment avons-nous mis cela en place techniquement ? Quels logiciels, matériels utilisons-nous ? Nous vous proposons de le découvrir !

Mise en place d'un talk en live streaming

Nowadays, many solutions exist to help non-technical people automate those tasks like Zapier, Autopilot, and, of course, our friends at Webmecanik.

Sometimes however, you may need very specific integrations that are not possible to do with those all-in-one solutions. Here is where developers come! But, as you may know, developers are lazy... And spin-up a project, test it and deploy it in production is a large work for just doing some clever automations.

But hey, we are in 2020 ; and serverless functions are a thing!

Let's start with a funny tweet from @iamdevloper:

Surely you understood from this joke that serverless is a misleading term. There are servers that run the code, just as a standard web application. So, why do we call it like this? The main motivation behind serverless functions is to focus only on the code and don't a care a second about the deployment, server provisioning or configuration.

The execution environment is entirely managed by the cloud provider: Amazon Web Services Lambda, Google Cloud Functions or Azure Functions. Just upload your source code to them and they will handle the deployment, and scale automatically if the load increases.

The cherry on the cake is that you only pay for the time the functions are running. So, if your automation only runs for a few seconds each day, you'll pay almost nothing.

The downside is that, generally, the runtime environment is constrained by the cloud provider. For example, Google Cloud Functions only supports NodeJS, Python or Go programs. Besides, you won't be able to install more system packages than the ones that are already installed. If you rely on a specific package or language, serverless functions won't work for you (in that case, containers seem more appropriate).

Another issue is vendor lock-in: each cloud provider has its own way of implementing serverless functions, so a code that will work in AWS Lambda likely won't work in Google Cloud Functions without a few adjustments.

In the case of marketing automation though, this is OK: generally, it just involves to get data from one service and put it in another. Each function will consist of a few lines of code and HTTP requests!

Now, let's say we want to add a contact to a mailing list whenever we create a new deal in our CRM. Without webhooks, the logic of our automation would look like this:

Automation: Is there a new deal?
CRM: No.
[One minute later]
Automation: Is there a new deal?
CRM: No.
[One minute later]
Automation: Is there a new deal?
CRM: No.
[One minute later]
Automation: Is there a new deal?
CRM: Yes. The contact is Arthur Pendagron, its email is arthur@camelot.bt.
Automation: Ok. Hey, mailing list! Add Arthur Pendagron, its email is arthur@camelot.bt.
Mailing list: Ok, done.

As you see from this play, our automation would harass the CRM every minute to check if there is something new. Not very effective, and a total waste of resources.

Hopefully, we have something that could help: webhooks! They are a way of telling the service we want to get the data from to notify our automation when something happens. This way, our automation is only called when there is something to do. Let's see our new play with webhooks:

Automation: Hey, CRM! Tell me when a new deal is created.
CRM: Ok.
[One eternity later]
CRM: Hey, automation! A new deal was created. The contact is Arthur Pendagron, its email is arthur@camelot.bt.
Automation: Ok. Hey, mailing list! Add Arthur Pendagron, its email is arthur@camelot.bt.
Mailing list: Ok, done.

Far more efficient ⚡️ Funny things start when you trigger more events after reacting to other events. For example, we could set up a webhook that tell the email marketing service that a new contact was added in the mailing list, so that it could subscribe it to our e-mailing scenario!

Now, how does it look like as actual code? Let's see a short example with Google Cloud Functions. We assume we have pipedrive (CRM) and mailjet (mailing service) clients at hand to help us:

def pipedrive_to_mailjet(request: flask.Request) -> Tuple[str, int]:
    """Add new deals contacts to a Mailjet list."""
    webhook_meta = request.json["meta"]
    deal_id = webhook_meta["id"]
    deal = pipedrive.get_deal(deal_id)

    mailjet.add_contact(
        deal["person_id"]["email"][0]["value"],
        deal["person_id"]["name"],
        MAILJET_LIST_ID,
    )

    return ("", 201)

That's it! Get the data we were notified about, add it to another service. Deploy this code into production only requires one command:

gcloud functions deploy pipedrive_to_mailjet --runtime python37 --trigger-http --allow-unauthenticated

After a few minutes, your automation will be ready with a nice HTTP endpoint that webhooks can actually call.

You may have noticed the --trigger-http option. Actually, serverless functions can also be triggered by message queues. We'll talk about this in a future post.

Great! We've created a working automation: just a few lines of code, a simple deployment process, our dreams have come true. But remember: developers are super lazy.

If we have one automation, it's manageable. But usually, we have dozens of them. Each time we update the code, we would have to re-deploy them individually. That's boring. And error-prone!

The secret is to automate the deployments of our cloud functions. How? With Continuous Integration (CI)! This would require a dedicated article but, in a nutshell, those are technologies that provide an environment to script and execute actions whenever we add changes to the source code. Travis, GitLab CI or the youngest one, GitHub Actions, are some of them.

Generally, CI configuration files look like this:

name: Build

on: [push, pull_request]

jobs:

  deploy:
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/master'

    steps:
    - uses: actions/checkout@v1
    - name: Deploy pipedrive_to_mailjet
      uses: actions-hub/gcloud@275.0.0
      env:
        PROJECT_ID: ${{ secrets.GCLOUD_PROJECT_ID }}
        APPLICATION_CREDENTIALS: ${{ secrets.GOOGLE_APPLICATION_CREDENTIALS }}
      with:
        args: functions deploy pipedrive_to_mailjet --runtime python37 --trigger-http --allow-unauthenticated

You see that we have several steps, including one that execute the deploy command we saw earlier. If we have several automations to deploy, we just have to add it once in this configuration file. Now, each time we update the code, all automations will be automatically deployed.

It's key to understand that, while automations are useful to help grow the business, they are not a core part of it. Hence, they should be written and deployed quickly so that developers can focus on the product. We saw that serverless functions and CI can greatly help in that matter.

At BeeMyDesk, we rely on those technologies to automate our CRM pipelines and customer success actions. It's important to us to keep up with the latest technologies and select the ones that will maximize the impact of the developers time on the business growth.

Marketing automation is an essential field for startups that need to react fact and focus on one thing: bring value to their clients. Repetitive and time-consuming tasks should be automated.

Serverless functions for marketing automation

In recent months, other languages have started to catch up, implementing their own flavor of asynchronous style. Among them, of course, almighty Python (did I tell you I love Python?).

But before talking about the Python ecosystem, let's have a quick overview of how asynchronous programming actually works.

The main motivation behind asynchronous style can be summed up in one simple statement: I/O is painfully slow. Reading from disk, networks requests, are million times slower than reading from RAM and processing instructions. Traditionally, in a synchronous program, you would do things like this:

with open("file.txt") as f:
    data = f.read()
# The program will block here until the data has been read
print(data)

We see that the program will block until we retrieved the data from the disk ; and, as we said, this can be long. 99% percent of the execution time of the program is just to wait for the disk. It's usually not a big deal for simple scripts like this because you probably don't have to perform other operations meanwhile.

However, in more complex cases, this is a waste of resources that could have been used to perform other things. For example, think of a web server: if a first user makes a request that needs to block the program for 10 seconds, a second user making a request meanwhile would have to wait for the first one to finish before they get answered. We can simulate this behaviour quite easily with flask and gunicorn:

# app.py
import time
from flask import Flask, request

app = Flask(__name__)

@app.route("/slow")
def slow():
    time.sleep(10)
    return "That was slow!"

@app.route("/fast")
def fast():
    return "That was fast!"

If you hit the /slow endpoint and right after the the /fast endpoint, you'll see that you get the /fast response only when /slow has answered (after 10 seconds have passed).

To circumvent this, web servers usually spawn several threads (notice that we purposely started gunicorn with 1 worker) to be able to serve several users at a time, even if one request takes time to complete.

Solution adopted in asynchronous style doesn't involve threads, as they come with their own difficulties. Asynchronous frameworks implement a concept you probably have already heard of: event loops.

An event loop basically is the conductor of your program: at each iteration, it'll check for the completion of the tasks, yield the result if it's done, and go on to the next task. As a developer, your role is thus to send tasks to the event loop, knowing that you'll eventually get their result. Let's rebuild our previous example asynchronously with fastapi and uvicorn:

# app.py
import asyncio
from fastapi import FastAPI

app = FastAPI()

@app.get("/slow")
async def slow():
    await asyncio.sleep(10)
    return "That was slow!"

@app.get("/fast")
async def fast():
    return "That was fast!"

If you spawn the two requests at the same time like earlier, you'll see that /fast has answered immediately, not waiting for /slow to finish: the event loop put the /slow request in its queue, and moved on to the next one.

Notice that we traded time.sleep for asyncio.sleep. This is important because the event loop can only manage asynchronous tasks, that give back control to their caller. If you keep time.sleep, you'll experience the same behaviour as in the previous example: the thread will be blocked because it didn't yielded to the event loop.

Fine. But how does that solve our I/O problem? If we want to work with our event loop, I/O operations have to work asynchronously. To do this, we leverage an interesting feature of the operating systems: the select and poll calls (and derivatives). Those allow to ask the OS to ping us when something happened on a file or a socket (new data to read, ready to write data...). By using them, we allow the event loop to put the I/O calls in background and handle them once the OS notified us.

That was a very simplified overview of how asynchronous is implemented. If you wish to have a more complete and correct view of what is going on under the hood, be sure to check the references.

asyncio module is included since Python 3.4 (2014!), and the async/await syntax since Python 3.5. Both have been greatly refined in 3.6 and 3.7; making the use of async style very easy. Logically, the ecosystem has grown since: there are now solid libraries ready for production use. We will just cite a few of them:

Starlette, an impressively fast and clean framework to build web applications ;

Its offspring, FastAPI, which builds upon Starlette and Pydantic to propose a very efficient developer experience to build API ;

HTTPX, an async-compatible HTTP client with a requests-like API.

All those tools allow to build performant web services leveraging the power of the asynchronous paradigm.

Asynchronous programming is a very interesting pattern that can greatly improve performance in some contexts, especially in web servers. While it has been the privilege of NodeJS for quite some time, other languages are now catching up and it's great to see that Python community is becoming more and more involved in this trend.

At BeeMyDesk, we are currently building our platform using those technologies, especially FastAPI. We are glad to contribute to this ecosystem by releasing open-source libraries like FastAPI Users or HTTPX OAuth.

https://en.wikipedia.org/wiki/Asynchronous_I/O

https://en.wikipedia.org/wiki/Async/await

https://docs.python.org/3/library/selectors.html

https://trio.readthedocs.io/en/stable/tutorial.html

https://trio.readthedocs.io/en/stable/design.html

https://stackoverflow.com/questions/49005651/how-does-asyncio-actually-work

http://blog.mixu.net/2011/02/01/understanding-the-node-js-event-loop/

https://snarky.ca/how-the-heck-does-async-await-work-in-python-3-5/

https://jvns.ca/blog/2017/06/03/async-io-on-linux--select--poll--and-epoll/

Asynchronous programming have become very popular in the recent years, NodeJS being the locomotive of this trend, highly encouraging the async style and backed by impressive benchmarks.

Asynchronous programming is now a thing in Python

Blog : Technique

Mise en place d'un talk en live streaming

Serverless functions for marketing automation

Asynchronous programming is now a thing in Python