GrowFast avait besoin de gérer un accélérateur — programmes, événements, offres d'emploi et paiements — sans assembler cinq outils différents. Ils voulaient une plateforme unique où les startups s'inscrivent aux programmes, les participants s'enregistrent aux événements, les candidats postulent à des offres, le tout connecté à une infrastructure de paiement réelle. Stripe pour les transactions internationales. Alipay pour le marché chinois.
Douze mois, quatre personnes, et un développement from scratch plus tard, la plateforme était en production. C'est notre projet le plus long et le plus complexe à ce jour.
Pourquoi ils n'ont pas acheté
La première question qu'on a posée — comme toujours — était s'ils devaient construire du tout. Des outils de gestion d'accélérateur existent. Eventbrite gère les événements. Les job boards sont commoditisés.
Le problème était les connexions entre ces éléments. Une startup inscrite à un programme devrait automatiquement accéder aux événements du programme. Un participant à un événement qui est aussi membre d'un programme devrait voir un profil unifié. Les candidatures devraient être visibles par les mentors. La réconciliation des paiements Stripe et Alipay devait atterrir dans un seul tableau de bord.
Aucune combinaison d'outils existants ne pouvait livrer ça sans une couche d'intégration qui serait elle-même un projet logiciel. Alors on a tout construit.
L'architecture
Laravel était le socle — gérant programmes, événements, emplois, utilisateurs, rôles, paiements, notifications et le tableau de bord admin. Pour une plateforme de cette taille, l'approche convention-over-configuration de Laravel était essentielle. Avec quatre développeurs en parallèle, chacun devait savoir où tout se trouve sans demander.
La couche de paiement était la pièce architecturalement la plus significative. Stripe et Alipay ont des modèles d'intégration fondamentalement différents. On a construit un service de paiement unifié qui abstrait les deux derrière une interface unique — le reste de l'application ne sait pas quelle passerelle a traité une transaction.
L'idempotence des webhooks était critique. Les deux passerelles peuvent envoyer le même événement plusieurs fois. Sans gardes d'idempotence, un paiement unique pourrait être enregistré deux fois.
Les problèmes les plus difficiles
Réconciliation des paiements multi-passerelles
Les règlements Stripe arrivent en lots, pas en transactions individuelles. Alipay a son propre cycle de règlement avec conversion de devise. On a construit un moteur de réconciliation qui fait correspondre les enregistrements de la plateforme avec les rapports des passerelles.
Des jobs de réconciliation nocturnes signalaient automatiquement les écarts. Le premier mois après le lancement, ça a détecté trois anomalies de règlement.
Contrôle d'accès par rôles entre modules interconnectés
Un accélérateur a beaucoup de types d'utilisateurs : gestionnaires de programmes, mentors, fondateurs de startups, organisateurs d'événements, recruteurs, candidats, participants et admins. Chacun voit des données différentes et a des permissions différentes.
On a implémenté un RBAC granulaire avec des Policies Laravel, des permissions scopées par module. Le panneau admin permet à l'équipe GrowFast de créer des rôles personnalisés sans intervention développeur.
Délivrabilité des emails à l'échelle
Une plateforme d'accélérateur envoie beaucoup d'emails. On a implémenté l'authentification de domaine (SPF, DKIM, DMARC), la mise en file d'attente avec logique de retry, et la gestion des bounces. Les templates email sont des objets configurables dans l'admin.
Ce qu'on a livré
Inscription et suivi de startups : Programmes avec formulaires de candidature, workflows de revue, et suivi de jalons.
Événements : Création, billetterie, inscription, paiement et suivi de présence. Les événements peuvent être liés aux programmes.
Emplois : Publication d'offres, candidatures, gestion de candidats, et intégration avec l'écosystème des programmes.
Paiements : Stripe et Alipay avec webhooks vérifiés, reçus automatiques, gestion des remboursements, et réconciliation nocturne.
Tableau de bord admin : Dashboards opérationnels, gestion de rôles, analytics et exports CSV.
Douze mois : comment on l'a structuré
Un projet d'un an nécessite une discipline différente d'un sprint de trois mois :
Mois 1 : Discovery. Interviews parties prenantes, baseline des exigences. On n'a pas écrit de code — on a écrit des documents. La phase de cadrage sur un projet de cette taille fait la différence entre un build contrôlé et un budget qui dérape.
Mois 2-3 : Scope et contrats. Modélisation du domaine, contrats API, flux UX, design des chemins de paiement.
Mois 4-10 : Build. Modules centraux d'abord, puis paiements, puis événements et emplois, puis notifications et reporting. Démos bi-hebdomadaires tout du long.
Mois 11 : Hardening. Infrastructure de production, tests de charge, audit de sécurité, migration de données.
Mois 12 : Lancement et transmission. Mise en production, runbooks, formation de l'équipe.
Ce qu'on a appris
Designer les flux de paiement tôt, avec des chemins de fallback clairs. On a conçu l'architecture de paiement au mois 2, pas au mois 6.
Utiliser des APIs versionnées et des DTOs pour des intégrations stables. Quand Stripe ou Alipay change son API, on met à jour un fichier de mapping, pas la logique métier.
L'observabilité et les runbooks réduisent la charge opérationnelle. Quand la plateforme a été lancée, l'équipe opérationnelle avait des runbooks pour chaque alerte.
Garder l'admin simple ; optimiser là où le staff passe son temps. On a initialement sur-ingénié l'interface admin. Dans la seconde moitié du build, on a observé quelles tâches admin étaient les plus fréquentes et optimisé ces flux spécifiquement.
Les tests automatisés autour de la facturation préviennent les régressions. Le code de paiement est le plus dangereux à casser.
Le résultat
GrowFast a lancé une plateforme unifiée couvrant programmes startups, événements, emplois, et paiements intégrés Stripe et Alipay.
Pour tous les détails, lisez l'étude de cas complète GrowFast.
Vous planifiez quelque chose de cette ampleur ?
Un build de 12 mois à quatre personnes est un investissement sérieux. Si vous envisagez une plateforme de ce scope, commencez par un brief solide, comprenez ce qui drive les délais, et sachez quoi demander avant de signer.
Vous avez un projet de plateforme en tête ? Cadrons-le ensemble →