Si vous n’avez pas lu le début de notre aventure technique, je vous conseille de commencer par lire le premier et le deuxième article avant celui-ci.

Comme je le disais dans l’article précédent : Il est temps de rembourser notre dette technique.
Notre histoire continue donc avec une équipe technique solide et talentueuse prête à affronter des défis à sa hauteur.

La Conquête du Sommet

Notre team de super héros prête à tout pour gravir les sommets

À cette époque on récupère une solution HelloAsso vieillissante avec un objectif clair et simple :

• réduire notre dette technique

On commence par yoyoter pendant quelques semaines sur la question

Est-ce qu’on restart from scratch ?

On finit par aboutir sur un non.
5 ans plus tard, je dirai que c’était une mauvaise décision car la migration n’est pas 100% terminée et nous avons hérité de beaucoup de lourdeur du passé. Mais aurions-nous été meilleurs from scratch ? Je n’en suis pas sûr non plus !
Ce qui est important c’est que nous ayons fait ce choix par consensus.

On doit donc réfléchir à un plan pour améliorer notre solution.
On commence donc par s’enfermer pendant 3 jours pour mettre en place ce que l’on appellera HelloAsso.Core, il s’agit de notre framework interne gérant l’accès à la donnée (DAL) et ce que l’on peut qualifier de couche service.
On organise tout ça selon le pattern Command avec les fameuses CommandRequest et CommandResponse et on se pose des contraintes de qualités très importantes, grâce au test unitaire notamment. On  pense également à anticiper les évolutions futures :

• .Net Core en développant tout ça en .Net Standard
• L’utilisation d’une couche front et déployant une nouvelle API et en arrêtant l’utilisation de ASP.NET MVC

On est satisfait du résultat et en termes de retour d’expérience cette architecture ne sera pas remise en question, ça valait donc largement l’investissement.

Voilà pour la partie code, reste maintenant à mettre en place une structure solide pour délivrer de la feature.
On s’oriente tout naturellement vers la création de feature team en se basant sur le modèle proposé par spotify et ses fameuses squads.
Ce framework est pratique car il permet la subdivision de façon native et n’est donc pas une vision statique de l’organisation ce qui est assez pratique dans une start-up en hyper croissance. Je vous dévoile tout de suite l’ensemble de l’évolution jusqu’à aujourd’hui.

On voit très clairement les phases de développement, avec la multiplication des squads puis de rationalisation des périmètres avec des suppressions ou changement d’intitulé. Pour aboutir en 2023 sur une organisation par domaine, un domaine regroupant au minimum 2 squads. 2024 hérite des méthodes shape-up & safe mettant au centre des domaines des équipes “enablers” dont le but est d’aider les équipes à effectuer leurs missions dans les meilleures conditions.
Je ne vous cache pas qu’une telle organisation, même si elle est dans le modèle de ce qui se fait partout, prend beaucoup de temps à mettre en œuvre et réside surtout dans le juste dimensionnement et la bonne affectation des personnes et des périmètres.

Je vais prendre l’exemple de l’équipe Admin Sys -> DevOps -> Infra & Cloud mais c’est vrai pour l’ensemble des équipes étant maintenant enablers.
Lors de la mise en place des squads nous avons fait les bons élèves et mis l’ensemble des compétences dans les squads. Celà a eu un effet bénéfique sur l’alignement au début mais un autre très néfaste sur la stabilité de notre infra. On a donc pris la décision de mettre en place une équipe DevOps dédiée dans le but de se concentrer sur notre infra et de la stabiliser. 2 mois après les résultats étaient là. Aujourd’hui nous avons renommé cette équipe en Infra & Cloud pour porter un message fort : le DevOps est l’affaire de tous !
L’équipe est donc bien toujours à part et se focalise plus sur l’infra et à une rôle de formation de l’ensemble de l’équipe tech aux pratiques DevOps.

La Transformation

Avec une base de code et une organisation solide on ne pouvait que se mettre en position d’accélérer.

Comme les plus attentifs d’entre vous l’auront vu dès 2021 nous commençons à travailler sur notre établissement de paiement (EP). Seulement avec les personnes en place c’est très compliqué d’être partout.
Fin 2022 on boucle donc une nouvelle levée de fonds 15M et comme on le voit sur notre organisation c’est à partir de ce moment là que l’on met en place une stratégie par domaine car on a maintenant une équipe tech & produit de 60 personnes.

L’organisation et l’architecture sont donc à la hauteur de nos ambitions ce qui nous permet d’adresser des projets qui avant n’étaient tout simplement pas possible à adresser convenablement.
Je pense notamment à la mise en place d’une logique constante de réduction des coûts de notre infra et plus récemment à la mesure de notre bilan carbone et l’élaboration d’un schéma directeur du numérique responsable.

La Légende

Et maintenant de quoi sera fait l’avenir ?

Comme on l’a vu notre organisation est à l’épreuve du scale et ne devrait pas évoluer de façon très importante. L’architecture mise en place est fiable et permet d’intégrer de l’innovation facilement. Ce qui va changer principalement c’est la version des technologies utilisées et que l’on fait suivre en fonction de l’actualité.

Au niveau de l’infrastructure il y a aussi quelques transformations et migrations à terminer mais l’ensemble est là encore très stable. L’idée étant surtout de respecter ce que l’on a mis dans notre schéma directeur.
Si on parle de l’avenir on va donc plutôt parler de produits. Les deux principaux étant notre établissement de paiement et notre API.

Notre établissement de paiement est un choix stratégique depuis 2021 pour offrir à nos associations encore plus de facilité dans la réception de leur paiement.

Notre API est aujourd’hui utilisé dans beaucoup de cas d’utilisation mais on pense pouvoir aller beaucoup plus loin et offrir encore plus de fonctionnalités aux intégrateurs de nos solutions.

J’espère que cette suite d’articles vous a plu. N’hésitez pas à régir.

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.

J’ai eu la chance de rejoindre HelloAsso en 2013 quand il y avait encore tout à faire alors j’ai de quoi raconter !

Embarquons ensemble dans cette fantastique aventure en commençant par l’état actuel des choses.

Le 25/03/2023 à 11:08:04 HelloAsso atteignait le seuil du milliard d’euros collecté pour les associations, après 14 ans d’existence !

Au-delà des chiffres et des retombés de presse que cela a pu avoir, j’ai envie de vous raconter l’histoire de l’intérieur. Étant dans l’équipe technique, il y a fort à parier que mon histoire est un biais technique et plus particulièrement DevOps.

HelloAsso est la plateforme qui permet aux citoyens de participer aux activités d’une association près de chez eux. Nos services sont offerts aux responsables associatifs grâce aux contributions volontaires des citoyens. A l’aide de ces soutiens et de nos outils, les associations peuvent gérer leurs activités et collecter des paiements en ligne dont elles perçoivent 100% de chaque somme, sans frais ni commission.

Ce produit connaît une énorme croissance et nous avons de beaux chiffres (de juin 2023) si on veut en mettre plein les yeux:

• 150+ collaborateurs·rices
• 222 000+ associations
• 11 000 000+ d’utilisateurs
• 1 065 000 000+ euros collectés
• 20 000 000+ de paiement en base

On prend le temps de regarder les courbes, personnellement j’adore les tendances exponentielles !

Le tout supporté par une infrastructure au début très modeste et maintenant totalement sur le cloud, en réalisant l’exploit de ne pas avoir suivi les autres tendances.
Autant pour la croissance l’exponentielle c’est sympa, mais pour les dépenses on préfère une bonne fonction affine.

Maintenant que l’on sait ça, on peut voir que l’on est en pleine croissance. Cela étant dit, on n’en sait pas beaucoup plus sur la façon dont on en est arrivé là !
Je vous propose donc un voyage dans le temps pour comprendre nos difficultés et nos succès.

L’Étincelle Initiale

Nous sommes en 2013, après avoir testé beaucoup de choses, l’équipe initiale lance officiellement le site HelloAsso. Dans sa première version, il s’agit d’un site de collecte en ligne.

C’est un site très classique et dans les technos de l’époque :

• ASP.Net
• jQuery / vanilla js
• vanilla css
• SQL Serveur

Cette application est organisée avec le pattern trois tiers à notre sauce et c’est un beau monolith.

Côté infrastructure, le tout déployé sur un unique serveur Windows Server chez OVH.

Le pipeline CI/CD de l’époque ?
Click droit / Deploy to sur visual studio et surtout on croise les doigts pour ne pas perdre la connexion lors du déploiement !
Ça c’était avant de faire des zip que l’on décompresse sur le serveur.

Le monitoring et la maintenance du serveur de l’époque ?
Si ça fonctionne pourquoi se poser des questions

Ce site évolue tranquillement, les features s’ajoutent au fur et à mesure notamment les billetteries et les adhésions.

Le Rassemblement des Héros

Nous avons un site fonctionnel, une volumétrie correcte mais un CA ne permettant pas de payer les salaires. C’est d’ailleurs tout l’enjeu d’un business model basé sur la générosité : avec une masse critique ça fonctionne, sans ça et bien il faut attendre la croissance.

Alors en parallèle on lance une activité B2B. L’idée est vraiment très bonne, on a entre 20 000 et 50 000 associations en base de données, en face il y a des fondations d’entreprise qui lancent des appels à projet mais ne parviennent pas à obtenir beaucoup de participation.

On développe donc une solution d’appel à projet totalement configurable pour nous permettre de déployer un appel à projet en un temps record.
Bien évidemment ça c’est la théorie.

C’est une solution full js (chose assez novatrice à l’époque). Vuejs sortait en même temps dans sa première version, c’est-à-dire !

Techniquement c’est géré par deux tables en base de données, une API pour gérer l’interaction avec le front qui n’est rien d’autre qu’une page html remplie entièrement par du js.

Tu penses que la suite est un long fleuve tranquille ?

Qu’opérer un site et une activité B2B se passe sans aucune surprise ?
L’article suivant arrive très bientôt, il abordera les difficultés avant les périodes plus joyeuses.