SimplyJury : de l'audit aux lots réguliers

Sommaire · 6 sections

Le problème

SimplyJury avait déjà un produit. Un autre prestataire l’avait développé, il tournait en démo, et les premières personnes qui l’avaient vu avaient dit que l’idée tenait. Le budget du premier MVP était engagé, le calendrier de lancement aussi.

Repartir de zéro aurait jeté des mois de travail qui fonctionnaient déjà en grande partie. J’ai pris l’autre chemin : lire l’existant avant de décider quoi que ce soit, puis livrer par lots.

L’approche

Une plateforme de mise en relation entre des centres de formation, CFA, organismes, écoles, et des jurys professionnels qualifiés pour leurs certifications. Les centres y trouvent rapidement des jurys disponibles, les jurys y gagnent la visibilité qui leur manquait, et tout le parcours est couvert, des profils au paiement. Elle est en production aujourd’hui, avec près de 500 jurys inscrits (chiffre 2026). C’est la reprise que j’ai menée pour SimplyJury à partir d’avril 2026, sur un MVP livré par un autre prestataire, trop avancé pour repartir de zéro.

L’audit, pour décider avant de coder

Avant d’ajouter quoi que ce soit, j’ai réalisé un audit technique de l’existant, offert. Ce qui compte, c’est ce qu’il a permis de décider : quel périmètre était sain et pouvait être gardé tel quel, quel périmètre demandait des correctifs, et dans quel ordre les livrer. Le résultat tient dans un backlog de mise en production, découpé en sprints, chacun tracé par sa plage de commits et son statut. Le premier a été livré dès la fin avril 2026.

Correctifs ciblés, recette, mise en ligne

Chaque sprint a été livré, puis validé par une recette manuelle avant de passer au suivant, avec une checklist de bout en bout écrite pour le lancement. La mise en production elle-même a suivi un runbook, lot par lot, avec des contrôles SQL avant et après chaque étape ; l’état de prod y est mesuré au 27 août 2026. Un exemple de correctif représentatif : la fiabilisation des emails transactionnels, avec un expéditeur décidé à un seul endroit du code et un domaine dédié imposé par une garde à l’exécution.

Des lots chiffrés, isolés, réversibles

Après la mise en ligne, chaque évolution est arrivée par lot : un périmètre clair, un prix connu avant de s’engager, et des options explicitement séparées que le client peut retirer sans incidence sur le reste. Les alertes jury, le dépôt de session côté centre avec son tableau de bord, la connexion à double vérification par code, les statistiques d’administration, la fiabilisation des emails par type de compte : chacun de ces lots a été livré indépendamment, avec sa propre recette.

Un partenariat qui continue

Le vrai sujet n’a jamais été une livraison unique. Le dépôt montre un rythme mensuel de livraisons depuis avril 2026, avec un pic en août, le mois de la mise en production, et le fondateur commite aussi dans le dépôt. Le suivi post-lancement a son propre backlog, alimenté par ce que le terrain remonte, et c’est ce backlog qui décide des lots suivants.

Stack et choix techniques

Sur une reprise de MVP, je ne change pas la stack pour le plaisir : je garde ce qui tient et je fais évoluer ce qui doit l’être. Ici, la base est Next.js 15 sur Vercel, région cdg1 à Paris, avec Supabase pour la base de données et l’authentification, Stripe pour le paiement et Resend pour les emails. TypeScript en mode strict sur l’ensemble du dépôt.

Le choix structurant a été de ramener l’accès aux données sur Drizzle, table par table, à mesure que les lots le demandaient : tableaux de bord du centre, sessions et leurs notes, statistiques du jury, export RGPD. Chaque requête est ainsi écrite, typée et relue dans le dépôt. Le schéma compte 28 tables et 50 migrations SQL versionnées ; un workflow GitHub dédié les applique, et le script vercel-build les exécute en production avant chaque next build, ce qui évite qu’une version déployée tourne sur un schéma en retard.

Les droits d’accès aux données sont portés par PostgreSQL, avec 86 politiques RLS déclarées dans les migrations. Le webhook Stripe tourne avec maxDuration à 30 secondes, et la connexion est vérifiée par code OTP avec plafonnement des tentatives.

Résultat

Le chiffre qui compte pour une place de marché, c’est le vivier : sans jurys disponibles, aucun centre de formation n’a de raison de revenir. Ce résultat appartient au client, c’est son marché, son réseau, son travail commercial. Ma part, c’est que la plateforme n’ait jamais été le facteur limitant, qu’elle tienne quand l’audience arrive et qu’elle évolue au rythme de ce que le terrain remonte.

Questions fréquentes

Qu’a demandé SimplyJury en premier, avant la moindre ligne de code ?

Un audit de l’existant. Il a séparé le périmètre sain, gardé tel quel, de celui qui demandait des correctifs, et fixé l’ordre de livraison. Le résultat tient dans un backlog de mise en production découpé en sprints, dont le premier a été livré à la fin avril 2026.

Comment s’est passée la mise en production ?

Lot par lot, selon un runbook, avec des contrôles SQL avant et après chaque étape. Chaque sprint avait été validé par une recette manuelle avant de passer au suivant, et une checklist de bout en bout a été écrite pour le lancement.

Pourquoi avoir gardé la stack de SimplyJury ?

Parce que je ne change pas la stack pour le plaisir : je garde ce qui tient et je fais évoluer ce qui doit l’être. Next.js sur Vercel, Supabase, Stripe et Resend sont restés ; seul l’accès aux données a été ramené sur Drizzle, table par table, à mesure que les lots le demandaient.

Comment les évolutions sont-elles livrées depuis la mise en ligne ?

Par lots : un périmètre clair, un prix connu avant de s’engager, et des options séparées que le client peut retirer sans incidence sur le reste. Le backlog post-lancement est alimenté par ce que le terrain remonte, et c’est lui qui décide des lots suivants.

Si tu portes un MVP que tu n’as pas développé toi-même et que tu hésites entre le lancer et tout refaire, mieux vaut bien choisir ses prestataires dès le départ — mais quand ce n’est plus possible, la reprise de MVP commence par cet audit. Pour la suite, une fois le produit en ligne, c’est le partenariat technique en lots réguliers qui prend le relais.