“L’application fonctionne… pour l’instant”
Vous connaissez ce moment. Votre startup decolle. Les metriques montent. Les investisseurs sont contents. L’equipe commerciale signe plus vite que prevu. Et quelque part dans un coin de votre tete, une voix murmure : “la technique ne va pas suivre.”
Ce n’est pas de la paranoia. C’est de la lucidite.
C’est exactement la situation de Cajoo. Livraison de courses en moins de 15 minutes, croissance fulgurante, levee de fonds, expansion dans plusieurs villes. Et une stack technique qui tenait — mais qui n’avait pas ete pensee pour 10x le trafic.
Dans le quick commerce, le cout d’un incident n’est pas technique. Il est business. 5 minutes de panne = 5 minutes sans chiffre d’affaires. Des livreurs qui attendent sans commandes. Des clients qui partent chez Gorillas ou Flink — et ne reviennent pas. Et dans un marche ou plusieurs acteurs brulent du cash pour acquerir des parts, chaque incident est une opportunite offerte a la concurrence.
Le vrai probleme : 3 bombes a retardement
Le vrai probleme de Cajoo n’etait pas un bug visible. L’application fonctionnait. Les commandes passaient. Les livraisons arrivaient. Mais sous la surface, trois problemes structurels rendaient chaque pic de charge dangereux.
1. Pas de monitoring serieux
Les incidents etaient detectes quand les utilisateurs se plaignaient — c’est-a-dire trop tard. Le temps moyen de detection d’un probleme en production etait de l’ordre de 15 a 30 minutes. Dans le quick commerce, 30 minutes c’est une eternite.
Les recherches publiees dans Accelerate par Nicole Forsgren, Jez Humble et Gene Kim montrent que le temps de restauration du service (MTTR) est un des quatre indicateurs cles de la performance technique. Les equipes performantes restaurent le service en moins d’une heure. Les equipes peu performantes prennent entre une semaine et un mois. Cajoo etait quelque part entre les deux — et le marche ne pardonnait pas.
2. Des flux de donnees non unifies
Dark stores, livreurs, clients, back-office : chaque brique du systeme communiquait differemment. Certaines parties utilisaient du REST classique, d’autres des webhooks, d’autres du polling. Chaque integration etait un point de fragilite.
Le probleme n’etait pas que ca ne fonctionnait pas. Le probleme, c’est que chaque nouvelle fonctionnalite necessitait de gerer N integrations differentes, avec N formats differents, et N modes d’erreur differents. La complexite augmentait de maniere exponentielle, pas lineaire.
3. Une infra qui ne scalait pas
L’infrastructure avait ete concue pour la phase de lancement — pas pour la phase de croissance. Un pic de commandes le samedi matin, et c’etait la loterie : ralentissements, timeouts, commandes perdues dans les files d’attente. L’equipe technique passait ses week-ends a eteindre des incendies au lieu de construire le produit.
Si vous reconnaissez ces signaux dans votre propre stack, il est temps d’agir. Avant que ca casse.
L’approche : amelioration continue, pas big bang
Pourquoi on n’a pas fait de “grand projet a 6 mois”
La tentation, quand une startup en hypercroissance a des problemes techniques, c’est de proposer un grand projet de migration. Tout arreter pendant 6 mois, reecrire proprement, deployer le nouveau systeme.
C’est exactement ce qu’il ne fallait pas faire. Pour trois raisons :
- Le marche n’attend pas. 6 mois de gel technique dans le quick commerce, c’est 6 mois de retard sur les concurrents. Ca peut etre fatal.
- Les besoins changent toutes les semaines. Ce que vous specifiez en janvier n’est plus pertinent en mars. La startup pivote, itere, s’adapte. Un projet de migration a perimetre fixe est incompatible avec cette realite.
- Le risque de big bang est enorme. Comme l’ecrit Martin Fowler, les migrations “big bang” echouent parce qu’on decouvre les problemes trop tard — au moment du deploiement, quand il est trop tard pour corriger.
On est intervenus en continu, semaine apres semaine, avec une approche incrementale. Chaque amelioration etait deployee, mesuree, validee avant de passer a la suivante.
Les 4 chantiers prioritaires
Chantier 1 — GraphQL manage avec Hasura. On a unifie tous les echanges de donnees en un point d’entree unique. Fini les N integrations differentes : dark stores, livreurs, clients et back-office parlent tous le meme langage. Hasura fournit un schema GraphQL genere automatiquement a partir de la base de donnees, avec des subscriptions temps reel pour les mises a jour en direct.
Les benefices ont ete immediats :
- Une seule source de verite pour toutes les donnees
- Subscriptions temps reel — un livreur voit la commande apparaitre instantanement, sans polling
- Schema type — les erreurs d’integration sont detectees a la compilation, pas en production
- Permissions granulaires — chaque role (client, livreur, manager de dark store) ne voit que les donnees qui le concernent
Chantier 2 — Monitoring proactif. On a mis en place une observabilite complete : metriques applicatives, logs structures, alertes intelligentes. L’objectif : detecter les anomalies avant les utilisateurs — pas apres.
Le Google SRE Book appelle ca le “shift left on reliability” : plus on detecte un probleme tot dans la chaine, moins il coute cher. Une alerte sur un taux d’erreur qui monte, c’est 2 minutes pour reagir. Une alerte quand l’application ne repond plus, c’est 15 minutes de panne et des dizaines de commandes perdues.
Chantier 3 — Generation automatique de code client. Les schemas GraphQL permettent de generer automatiquement le code client (TypeScript) pour chaque application front-end. Plus de code d’integration ecrit a la main, plus de formats de donnees devines, plus de desynchronisation entre le back et le front.
C’est un des principes des auteurs de The Pragmatic Programmer : “Don’t Repeat Yourself.” Quand le meme contrat de donnees est defini une seule fois et genere automatiquement partout, les erreurs d’integration disparaissent.
Chantier 4 — Infrastructure serverless. Migration progressive vers une infrastructure qui scale automatiquement. Plus besoin de dimensionner les serveurs pour le pic du samedi matin — l’infrastructure s’adapte a la charge en temps reel et redescend quand le trafic baisse.
Le detail technique complet est dans l’article du blog technique.
Mesurer la performance : les metriques DORA appliquees
On a utilise les 4 metriques DORA (issues des recherches de Nicole Forsgren, Jez Humble et Gene Kim dans Accelerate) pour mesurer l’amelioration :
| Metrique DORA | Avant | Apres | Objectif “Elite” |
|---|---|---|---|
| Frequence de deploiement | 1-2x par semaine | Plusieurs fois/jour | A la demande |
| Delai de mise en production | 3-5 jours | < 1 heure | < 1 heure |
| Taux d’echec des changements | ~15% | < 5% | 0-15% |
| Temps de restauration du service | 30-60 min | < 10 min | < 1 heure |
En 3 mois, Cajoo est passe d’une equipe qui deployait une fois par semaine avec angoisse a une equipe qui deployait plusieurs fois par jour avec confiance. C’est le passage de ce que les auteurs d’Accelerate appellent un “low performer” a un “high performer.”
Le resultat : une equipe qui peut se concentrer sur le produit
L’equipe Cajoo a cesse d’eteindre des incendies. La technique suivait le rythme de la croissance. Pas de grosse migration risquee. Pas de refonte. Une amelioration continue, mesurable, chaque semaine.
Les resultats concrets :
- Zero temps d’arret pendant les pics de commandes du samedi matin
- Temps de detection des incidents passe de 30 minutes a moins de 2 minutes
- Nouvelles fonctionnalites livrees 3x plus vite grace a l’unification des APIs
- Equipe technique focalisee sur le produit au lieu de la maintenance
- Infrastructure qui scale automatiquement — plus de dimensionnement manuel
Les lecons pour votre startup
1. Structurez la technique AVANT la crise
Les startups qui investissent dans la fiabilite technique pendant la phase de croissance economisent en moyenne 3 a 6 mois de retard cumule sur les 2 ans suivants. C’est un constat empirique sur nos missions de scale-up. Investir tot coute toujours moins cher que reparer tard.
2. Unifiez vos flux de donnees
Si chaque partie de votre systeme communique avec les autres de maniere differente, chaque nouvelle fonctionnalite multiplie la complexite. Un point d’entree unique (GraphQL, API gateway) est l’investissement le plus rentable qu’une startup en croissance puisse faire sur sa stack.
3. Le monitoring n’est pas un luxe
Si vous detectez les incidents quand vos utilisateurs se plaignent, vous avez deja perdu. Le monitoring proactif est l’equivalent technique d’un tableau de bord financier : sans lui, vous pilotez a l’aveugle.
4. Preferez l’amelioration continue au grand projet
Pour une startup en croissance, un accompagnement continu est plus adapte qu’un gros projet ponctuel. Les besoins changent toutes les semaines — votre support technique doit suivre le meme rythme. C’est la philosophie Shape Up de Basecamp : des cycles courts, des resultats mesurables, une adaptation permanente.
5. Mesurez avec les metriques DORA
Quatre chiffres suffisent pour savoir si votre equipe technique est performante. Si vous ne les mesurez pas, vous ne pouvez pas ameliorer. Si vous les mesurez et qu’ils sont mauvais, au moins vous savez ou agir.
Le cout de ne pas structurer : les chiffres
Pour rendre le calcul concret, voici ce que coute un incident technique a une startup en hypercroissance :
| Impact | Estimation pour un quick commerce |
|---|---|
| 30 min de panne (commandes perdues) | 2 000 a 10 000 euros de CA perdu |
| 1 developpeur mobilise 4h en urgence | 500 euros (cout direct) |
| Impact reputation (avis negatifs, churn) | Difficilement quantifiable, mais reel |
| Retard sur la roadmap produit | 1-2 jours de retard par incident majeur |
| Frequence typique sans structuration | 2-4 incidents majeurs par mois |
Sur un an, ca represente 30 a 50 incidents, soit 60 000 a 200 000 euros de pertes cumulees — en comptant les couts directs et les retards sur le produit. C’est 3 a 10 fois le cout d’un accompagnement technique continu.
L’investissement dans la fiabilite technique n’est pas un cout. C’est une assurance — et comme toute assurance, elle est infiniment moins chere que le sinistre qu’elle previent.
Votre stack tient-elle la charge ?
Checklist d’auto-diagnostic :
- Vous deployez en production au moins une fois par semaine
- Un deploiement prend moins d’une heure du commit a la mise en ligne
- Vous detectez les incidents avant vos utilisateurs
- Vous pouvez restaurer le service en moins d’une heure
- Votre infrastructure scale automatiquement en cas de pic
- Chaque partie du systeme communique via un format standardise
Si vous cochez moins de 4 criteres, votre stack ne tiendra probablement pas un doublement du trafic.
Votre stack tient la charge aujourd’hui. Mais tiendra-t-elle demain ? Un audit de quelques jours suffit pour le savoir.