De 1 million à 1 milliard : Les principes clés pour gérer la croissance sereinement — partie 2

Cet article est la suite de ma série d’articles sur l’épopée technique de HelloAsso.

Si vous n’avez pas lu le premier c’est peut-être bien de commencer par ça !

Comme je le spoile à la fin du premier article, le développement du B2B à eu plusieurs effets négatifs, le principal étant l’impossibilité de rester focus sur notre produit principal. Voyons plus en détail ce qu’il s’est passé.

Premiers Pas et Premiers Obstacles

Ce chapitre pourrait aussi être intitulé la traversée du désert de la tech 🏜️

Revenons sur notre outil d’appel à projets.
Celui-ci rencontre un franc succès et notre commercial s’en donne à cœur joie.
Je vous rappelle que de façon synthétique il s’agit d’un seul script js de 5000 lignes. Un seul et unique script et en face 10 clients avec des spécificités.

is_required() the delicious way

Je vous laisse imaginer les régressions à chaque mise en prod.

Au final on corrige vite est-ce donc si grave ?
Au final c’est du temporaire est-ce donc si grave ?
C’est assez découplé de la solution principale, est-ce donc si grave ?

Rétrospectivement je dirais que ce n’était pas si grave et la période était totalement excitante. On faisait des choses sympas avec des technos hype, l’équipe était hyper soudée même si on travaillait tous beaucoup trop !

C’est d’autant moins grave, car nous étions conscients de l’état de notre tech et c’est l’époque où notre CTO s’est mis à parler d’un sujet qui lui tenait à cœur : la dette technique.
Car oui à cette époque le site HelloAsso est mis de côté et on fait seulement passer des correctifs prioritaires qu’il faut traiter dans un temps record.

Et attention je ne parle pas de petit correctif d’orthographe.

Quand tu organises un appel à projets avec campagne de vote, que les emails sont envoyés de façon synchrone par ton site et que le jour de la finale tu te retrouves à envoyer 100 000 mails en quelques heures, tu apprends très rapidement l’intérêt d’une architecture orientée service et tu livres en prod le service de mail le soir même.

Si on résume, on a donc toujours :

• le site HelloAsso (avec une belle surcouche js)
• un service qui gère les paiements récurrents
• un service email qui dépile une file d’attente
• un service qui gère les versements mensuels (exécuté sur le poste d’un dev)

C’est bon on a cassé le monolithe, plus de refonte avant 10 ans !

Arrive ensuite l’époque où l’on intègre l’ère (de l’AdminSys) du DevOps en recrutant notre premier AdminSys.
Il a fallu beaucoup de batailles pour justifier d’un tel poste, surtout avec un parc informatique de dix personnes, un seul serveur et des pipelines CI/CD à leur balbutiement.
C’est d’ailleurs souvent le cas pour les nouveaux postes. Il est toujours difficile d’arriver à estimer que l’on a besoin d’un temps plein. Si je peux vous donner un conseil c’est intéressant de commencer par de la prestation pour se donner une meilleure idée et surtout des chiffres pour justifier. C’est d’ailleurs la méthode que j’ai employée quand il a fallu recruter un DBA.
Bref revenons à notre sujet, l’équipe technique c’est maintenant 2 devs .net, un AdminSys et le CTO !

Cette période marque un tournant historique, car c’est à ce moment-là qu’on prend le virage du cloud, on est en 2015.

Et encore une fois c’est un virage que l’on prend un peu dans la douleur !
L’élément déclencheur ? Juste le crash du disque dur de notre serveur qui était up depuis 5 ans !
On galère pas mal avec le support pour au final obtenir notre serveur fonctionnel, mais avec un disque tout neuf et bien sûr à l’époque, la configuration du backup était dans la colonne “do it tomorrow”.

Concrètement on a tout perdu, game over

Alors on fait quoi ?
On se dit qu’on est probablement les plus chanceux !

• Notre admin sys venait de faire un backup de la base et des contenus utilisateurs 30 minutes avant.
• On était en cours de POC pour migrer sur le cloud

C’est donc là qu’intervient ce fameux virage dans la douleur.

Ce que j’en retiens:

• Un environnement cloud n’est pas un serveur, revoir l’ensemble de ta gestion de fichier utilisateur pour passer d’un système de fichier à un storage en une journée est un très beau défi (surtout quand cette gestion n’est pas centralisée).
• De même pour la migration d’un service Windows en service cloud.
• Les estimations c’est useless, on a fait en moins de 48h ce que l’on avait chiffré à 3 mois.

La leçon la plus importante d’entre toutes et qui s’est vérifiée lors de chaque migration : quand tu prévois une migration quelconque, il y a de fortes chances que tu te retrouves à la faire dans l’urgence, n’attends donc pas le dernier moment pour la tester.

Toujours est-il que nous voilà maintenant sur le cloud !

une infra cloud des plus modestes

Bon maintenant on travaille sur HelloAsso ou on s’éparpille encore ?

La Croisée des Chemins

Ne me demandez pas comment, mais on saisit deux opportunités énormes pour l’époque.

Tout d’abord en 2016 un partenariat avec Orange consistant à développer une plateforme de collecte en Côte d’Ivoire.
Pour le coup on développe une solution from scratch, le métier étant très différent de ce que l’on fait.
C’est une expérience hyper enrichissante qui nous a permis de découvrir qu’on pouvait faire des paiements en low tech, l’ensemble des transactions étant basé sur USSD.

En 2017 on développe une marque blanche pour la banque postale : rue des associations.
Le projet étant globalement la modification de l’ensemble du style de notre site, le recrutement d’un intégrateur web designer n’était encore une fois pas une bêtise.

Notre codebase commence à devenir assez importante d’autant que nous avons eu la bonne idée de faire un fork pour la marque blanche !
L’exploitation des différents sites devient donc aussi très chronophage.

Bien évidemment nous n’allions pas rester indéfiniment dans cet état végétatif d’un côté et hyperactif de l’autre.

Pour se refocaliser sur HelloAsso, on réalise une levée de fond de 6 millions d’euros qui nous permet de muscler les équipes dans le but de reprendre le contrôle de notre solution.

Nous sommes en 2018, l’équipe technique c’est : 2 dev / 1 admin sys et 1 intégrateur / web designer et le CTO

On se muscle côté support tech, on lance le développement de notre application mobile et surtout on intègre deux devs back C# senior.
L’objectif est clair :

Il est temps de commencer à rembourser notre dette technique

La suite de cette série arrive très prochainement. Ce sera l’article le plus dense, car je parlerais de l’architecture choisie et qui tient depuis 4 ans, de la façon dont on a résolu nos problématiques de fiabilité côté infra et les enjeux auxquels nous sommes confrontés actuellement.