Réalisations / UpGreg · upgreg.ai ↗
Étude de cas
Quatre modules, une passerelle, aucune réécriture.
Comment une plateforme métier a été découpée pour qu'aucun de ses morceaux ne puisse plus jamais bloquer les autres — et pourquoi ce découpage a fait gagner trois mois sur le projet suivant.
Le problème
Un produit qui devait grossir sans qu'on sache par où
Le besoin de départ était clair : des comptes utilisateurs, des notifications, un back-office. Ce qui l'était moins, c'était la suite. Un produit jeune change d'avis — sur son modèle, sur ses utilisateurs, parfois sur son métier.
Le piège classique, à ce stade, est l'application monolithique : tout va vite pendant trois mois, puis chaque évolution touche tout, chaque déploiement devient risqué, et la moindre panne arrête l'ensemble. Le piège inverse — une constellation de microservices — coûte, pour une équipe réduite, plus cher que ce qu'il rapporte.
La question posée au cadrage n'était donc pas « quelle technologie ? » mais « quelle est la plus petite frontière qui permette de remplacer un morceau sans rouvrir les autres ? »
Ce qu'on a fait
Quatre décisions, écrites avant la première ligne de code, et tenues depuis.
Des modules autonomes derrière une passerelle unique
Chaque domaine — comptes, notifications, administration — est un service à part, avec son port, son état de santé et son manifeste. Aucun module n'appelle directement un autre : tout passe par la passerelle ou par un bus d'événements. Conséquence pratique : on remplace un module sans toucher au reste, et un module en panne n'emporte pas le produit.
Une seule base de données, des migrations numérotées
Une base par module aurait été doctrinalement propre et opérationnellement ruineuse à cette taille. Une base, donc, mais un schéma discipliné et des migrations numérotées, idempotentes, référencées dans le script de déploiement. Une migration qui n'y figure pas n'est jamais jouée : c'est la panne de production la plus fréquente du métier, et elle est évitée par une vérification automatique avant chaque déploiement.
Un déploiement reproductible, et une seule machine habilitée
Conteneurs, routage et certificats automatiques, variables d'environnement issues d'un modèle versionné. Le déploiement est un script, pas une suite de gestes : il s'exécute depuis une seule machine, journalise ce qu'il fait, et sait revenir en arrière.
De l'observabilité dès le premier lot
État de santé par module, journaux structurés, remontée d'erreurs, métriques d'usage : posés au premier lot, pas après la première panne. C'est ce qui permet de dire ce qui s'est passé, plutôt que de le supposer.
Résultat
Ce que ça a changé, concrètement
- Première version utile en ligne six semaines après le cadrage, puis livraisons par lots.
- Aucune réécriture depuis la mise en production : les frontières ont tenu.
- Les modules de comptes et de notifications ont été repris tels quels sur un autre produit.
- Une panne d'un module n'a jamais arrêté l'ensemble de la plateforme.
- L'exploitation est assurée par la même maison que le développement : pas de renvoi de responsabilité.
Franchise
Ce qu'on referait autrement
- Les routes de santé déclarées trop tard. Placées après les routes dynamiques, elles se faisaient capturer par celles-ci. Une heure perdue, et depuis une règle écrite : les routes statiques d'abord, toujours.
- Un cache introduit trop tôt. Il masquait un vrai problème de requête. Retiré, la requête corrigée, le cache remis pour de bonnes raisons.
- Le premier back-office trop générique. Écrit pour couvrir des besoins hypothétiques ; la moitié n'a jamais servi. Depuis : on n'écrit un écran d'administration qu'après avoir vu le geste métier qu'il remplace.
Un socle à poser, ou un existant à découper ?
Le cadrage est un lot court et facturé. Il se conclut par un plan chiffré — et parfois par « gardez votre existant, corrigez trois choses ».