Stimuler l’agilité d’une agence avec une startup à l’interne

On a bien beau parler d’innovation et de l’importance de rester à jour en tant qu’entreprise, mais c’est parfois plus facile à dire qu’à faire. Lors du Agile Tour qui se tenait récemment à Québec, mon collègue Francis Côté et moi avons expliqué comment la création de startups chez Spektrum a permis à l’agence de devenir plus agile technologiquement.

Quitter son emploi, rester au bureau

D’abord, nos interlocuteurs sont toujours surpris d’apprendre que chez Spektrum, c’est possible de quitter son emploi pour développer un produit, tout en étant supporté par l’entreprise. Dans l’idée que les aspirations des humains ne cessent d’évoluer, les co-fondateurs de l’agence ne voulaient pas enfermer leurs employés dans des boites. C’est ainsi que sont nés Signsquid, Snipcart et Userboat, un logiciel de gestion de membres sur lequel j’ai travaillé lors de la dernière année. Ces initiatives sont à l’origine de ce qui est devenu le volet « intrapreneuriat » de notre programme de startups Apollo13.   

Pas d’expérimentation sur le dos du client

En utilisant des pratiques émergentes, chaque projet a bonifié le savoir-faire technologique de Spektrum. Au-delà de l'aspect financier, c’est le meilleur retour sur investissement que nous aurions pu espérer. L’équipe en est même venue à changer son approche de développement de projets en mode service. La nuance est importante : dans un contexte d’agence, l’expérimentation dans le but d’innover ne doit pas se faire sur un budget client. C’est malsain et irrespectueux. Généralement, un client paie l’agence pour son expertise, bref, pour qu’elle fasse ce qu’elle connait le mieux (à moins d'être en R&D). Développer des produits à l’interne et être notre propre client, avec notre propre budget et échéancier, c’est beaucoup plus propice à l’évaluation et à l’essai de nouvelles méthodologies.

Impact techno : parlons geek

Attention : avec ce passage, je mettrai probablement dans le jus notre aspirante geek avec ses chroniques de vulgarisation! Notre approche produit nous a permis de pivoter en très peu de temps du monde traditionnel de l'application multipage et du site vitrine supporté par un CMS et des serveurs dédiés, vers une approche d'application web monopage (single-page application) connecté par API directement servi dans le cloud. Nous avons pu intégrer à notre quotidien des technologies telles que le Vue.js et l’architecture serverless. Aussi, nous avons accru notre connaissance de Microsoft Azure et d’Amazon Web Services, des services ayant une valeur inestimable en raison de la qualité qu’ils permettent d’atteindre et de leur coût d’opération minime.

Prendre les moyens

Comment avons-nous concrétisé notre volonté de développer des produits à l’interne? D’abord, il faut pouvoir se dédier totalement au projet. Pour Userboat, mon horaire a été déchargé de tous les clients de l’agence. Plusieurs mandats ont été repoussés ou mis sur la glace afin de rendre l’opération possible. Nous avons également convaincu un client de sauter dans l’aventure avec nous, puisque notre idée répondait exactement à son besoin. Moyennant des frais beaucoup moins élevés que ceux qui auraient été engendrés par la création d’un système sur mesure, il a pu se doter d’une plateforme adaptée à ses besoins, en plus d’obtenir l’accès au service à la clientèle à vie. Dans l’éventualité où Userboat fermait ses portes, c’est alors à Spektrum que la tâche de maintenance reviendrait.

La règle des quatre R

Nous pouvons résumer notre processus décisionnel avec les quatre R des bons choix techno : répertorier, rationaliser, roder et répandre. Ce système encadre le processus d’actualisation technologique pour s’assurer de faire les bons choix dans différents contextes.

1) Répertorier : connaitre ses options

Tout commence par la définition claire de nos besoins. Étant donné que nous étions dans un contexte de MVP (Minimum Viable Product) ou  « produit minimum viable », c’est-à-dire la plus petite chose que l’on peut développer qui amènera de la valeur au client, il fallait livrer la plate-forme le plus rapidement possible en réduisant au minimum les coûts. Dans un tel contexte, plusieurs incertitudes sont apparues, que l’on pense à :

• La mise en place de fonctionnalités semblables à l’offre d’un gros joueur comme Mailchimp;
• Un schéma de données extrêmement variables selon la réalité du client (à la Salesforce);
• La possibilité d’offrir une performance significative, peu importe le client, c’est-à-dire qu’un seul et unique client puisse envoyer des campagnes courriel à 1 million de personnes s’il le désire.  

Pour développer un tel outil, nous avions donc besoin d’une solution malléable que nous pourrions utiliser facilement. Et comme Mailchimp ne se remplace pas en claquant des doigts, il nous fallait une stratégie fiable pour répondre à différents enjeux comme la gestion de campagnes courriel, des envois en évitant d’avoir à gérer les serveurs nous-mêmes, des bounces, de la désinscription et des notifications de spams, en plus d’intégrer la solution dans le tableau de bord de la plateforme de façon fluide.

Quelques options se présentaient pour remplir ces conditions. Évidemment, nous ne pouvions développer tout ça de A à Z. Lors de nos recherches, nous avons ciblé deux outils intéressants : Sendy et MoonMail.

Alerte #geektalk ici aussi. Le choix du système de gestion de base de données est toujours source d’argumentation. L’éternel débat entre le stockage de données structurées (SQL) et non structurées (NoSQL) soulève les passions et malheureusement, faire le mauvais choix peut entraîner de lourdes conséquences. Notre besoin était peu standard, soit un hybride entre structuré et non structuré. Alors, comment faire? Deux bases de données pour une même application? Tout stocker sous forme relationnelle et vivre avec les conséquences? Les variantes d’implémentation étaient multiples et les outils potentiels l’étaient encore plus (SQL Server, PostgreSQL, RavenDB ou MongoDb).

Bref, répertorier, c’est connaitre nos options. Pour ce faire, il faut rester à l’affût des nouveautés et comprendre leur valeur ajoutée. Idéalement, répertorier, c’est une action continue. Comme ça, lorsqu’un nouveau besoin se pointe le nez, on a en tête un catalogue d’outils à notre portée.

2) Rationaliser : le moment charnière

Une fois que nous connaissons les solutions disponibles pour répondre à nos problématiques, c’est le moment de peser le pour et le contre. Attention de ne pas tomber dans le panneau du buzzword-driven development, où l’on détermine qu’il faut automatiquement utiliser un outil parce qu’il est qualifié d’incontournable dans un article. Voici quelques questions à se poser avant de faire ces choix.   

• C’est un no brainer pour beaucoup de gens, mais la première question à se poser, c’est  : Est-ce que cet outil adresse mon problème? Est-il fait pour répondre à mon besoin? Trop souvent, on utilise quelque chose uniquement parce que « tout le monde l’utilise ».
• Le code source de cet outil est-il ouvert (open source)? Évidemment, c’est toujours un plus, car pouvoir compter sur une communauté de développeurs forte et vivante est toujours bénéfique.
• Y a-t-il une suite de tests unitaires bien pensés couvrant la majorité du code source? Si la réponse est négative, évitez d’utiliser l’outil à tout prix.
• Finalement, lorsqu’une solution tourne autour d’un logiciel payant (SAAS), est-ce qu’il est plus avantageux financièrement de la coder nous-mêmes ou de l’acheter? Lorsqu’un service offre un large éventail de fonctionnalités, est-ce que ça vaut la peine de payer pour utiliser seulement ce dont on a besoin?

Après avoir évalué la possibilité de développer nous-mêmes la chose (trop long, trop coûteux et difficile à mettre en place) et de se connecter à un logiciel comme Sendy (aucun tests unitaires et impossibilité à court terme d’intégrer l’outil à notre tableau de bord existant), nous avons conclu que Moonmail était la solution parfaite, puisqu’elle propose la majorité des fonctionnalités nécessaires et est disponible sous forme d’API.  

Quant à la base de données, le choix n’a pas été difficile. Nous avons opté pour PostgreSQL parce qu’elle permet de stocker et d’interroger l’information sous un format non prédéfini. Notre outil habituellement utilisé à l’agence, SQL Server, force les données à respecter un certain « moule », ce qui l’élimine de facto de la liste des finalistes. Finalement, puisque MongoDB nous a joué quelques tours avec d’anciens projets et qu’elle ne permet pas de croiser efficacement des résultats, cette option a vite été écartée.

L’étape de rationalisation est le moment où, d’un point de vue financier, il est crucial de faire les bons choix et de s’arrêter si on a un doute. Il se peut que le choix techno n’en soit pas un bon. Jusque là, le temps investi n’aura été qu’en recherche. Ce n’est donc rien de trop coûteux. Si un mauvais choix se rend plus loin dans le processus, c’est là que ça coûtera cher.

3) Roder : l’heure de vérité

Une fois que la solution est mise en place et se trouve en production, il faut se poser les questions nécessaires pour recommander son utilisation. En premier lieu :

• Le logiciel remplit-il la tâche pour laquelle il a été mis en place initialement?
• Les efforts nécessaires à l’implantation de la solution sont-ils justifiés par rapport à la valeur qu’elle amène?
• Est-ce que la composante interagit correctement avec le reste de la solution?
• L’ajout de fonctionnalités et l’introduction de nouveaux membres à l’équipe se passent-ils sans embûches?

Si ces énoncés sont majoritairement positifs, il est important de poursuivre le rodage en surveillant le comportement du logiciel de manière accrue, notamment en matière de sécurité, de stabilité et de résistance à la charge.

Si la solution n’est pas optimale et ne remplit pas convenablement les besoins, il faut se résoudre à évaluer l’effort requis pour reprendre le tout à zéro avec une nouvelle solution.

4) Répandre : favoriser l’adhésion

La dernière étape, c’est de répandre la bonne nouvelle. Lorsque nous sommes en mode startup, l’action de répandre les choix technologiques à l’ensemble des membres concernés se fait simplement. Puisque tout le monde est dans la même équipe et utilise le même répertoire de code, il suffit de pointer vers l’implémentation et sa documentation pour que tout le monde soit au courant.

Dans un contexte de consultation, devoir établir la nouvelle norme technologique requiert un effort de communication plus significatif. La cohésion d’équipe est habituellement moins forte : il y a très rarement plus de deux personnes sur le même projet. La maintenance de ces nouvelles normes nécessite un effort supplémentaire, puisque les projets ne partagent pas le même code.

Transmettre l’information peut se faire par divers moyens :

• Réunion d’équipe
• Plateforme de communication (Slack, HipChat, etc.)
• Courriels
• Revue de code
• Création de projets préfabriqués (templates ou boilerplates)

Dans un environnement qui évolue très rapidement, placer le développement dans un cadre rigide peut sembler contre-intuitif. Cependant il est primordial de le faire dans une certaine mesure, comme lorsque l’équipe atteint une taille considérable et surtout quand de nouveaux projets démarrent régulièrement.

Récapitulatif

Le processus de sélection de nouvelles technologies dans une organisation se fait en quatre étapes bien distinctes.

Dans le cas d’une agence, se donner accès à une porte de sortie à la deuxième étape est primordial, car le rodage de nouvelles technologies peut entrainer le gaspillage d’une partie importante du budget.

Innover : un processus itératif

Pour se maintenir à jour en tant qu’organisation, ces quatre étapes forment un cycle à répéter assez souvent, mais pas trop. Il ne faut pas s'essouffler. Prenez le temps de vous camper les pieds un instant et d’atteindre un rythme de croisière intéressant dans le développement des solutions. Quand on sent que la maintenance dans ce contexte pourrait devenir un problème, quand un nouvelle techno est réellement incontournable (révolutionnaire), ou quand un outil est abandonné pour diverses raisons, il est sans doute temps pour un nouveau tour de roue.

Faire avancer le volet technologique d’une agence n’est pas nécessairement chose aisée. L’important, c’est de demeurer honnête envers le client et envers soi-même. Même que la plupart du temps, rester à ce que l’on connaît le mieux s’avère être la stratégie la plus efficace. C’est ainsi que l’on construit des projets fructueux et rentables autant pour le client que pour l’agence.

Et vous, comment ça se passe de votre côté? Avez-vous déjà mis en place une initiative à l’interne comparable?