Comment nous livrons des fonctionnalités logicielles de niveau bancaire
en jours, pas en semaines.
Testé. Un code de niveau production qui vous laisse dormir tranquille.
Des fonctionnalités en jours, pas en semaines.
Des logiciels de niveau bancaire, correctement testés, prêts à livrer en moins d’une semaine. Releases hebdomadaires ou quotidiennes sur les produits matures.
Votre équipe réfléchit. La machine exécute.
L’implémentation et l’Agent QA sont automatisées. L’énergie de votre équipe se porte sur l’idéation et le time-to-market, pas sur l’exécution descendante.
Un code maintenable
Conventions appliquées. Skills maison. Documentation vivante. La deuxième année ne ralentit pas.
Architecturé, pas improvisé
D’abord les modules, ensuite le code. Des ingénieurs seniors définissent les frontières avant que l’IA n’écrive une ligne.
Testé, preuves à l’appui
Chaque critère d’acceptation vérifié dans un vrai navigateur. Régression de 47 scénarios. Échec = bloqué.
Des équipes seniors, pas du code IA bâclé
Chaque ligne relue par un ingénieur qui a déjà livré des systèmes de niveau fintech.
Besoin d’abonnements & de paiements sur la plateforme
Bonjour l’équipe S-PRO,
Une question rapide. Je veux ajouter des abonnements et des paiements à ma plateforme. Les utilisateurs sont de plus en plus nombreux et nous devons commencer à facturer d’ici le T3.
En combien de temps pouvez-vous le faire ?
Cordialement,
John
CEO · FinCo
Re : Besoin d’abonnements & de paiements sur la plateforme
Bonjour John,
Ce sera prêt la semaine prochaine.
Cordialement,
Sarah
Product Owner · S-PRO
Concentrez-vous sur votre business. Nous nous occupons du produit.
Des Product Owners, Business Analysts et ingénieurs expérimentés pilotent le développement, appuyés par une CI/CD éprouvée, des modèles d’infrastructure testés en conditions réelles et une IA utilisée là où elle aide vraiment. Dès le premier jour, la spécification, l’arbre des stories et les wireframes finaux sont dans vos outils. Vous restez proche de vos clients ; nous livrons le logiciel.
Pas « que voulez-vous ? », mais voici ce qui fonctionne.
Nous ne commençons pas par un formulaire de 40 pages. La demande du client arrive ; notre Product Owner senior et notre BA répondent avec une proposition concrète, tirée de chaque service comparable que nous avons livré. Des recommandations, pas un interrogatoire.
Pour un service comme le vôtre, nous recommandons :
- ✓3 niveaux d’offre avec bascule mensuel/annuel et une offre mise en avant.
- ✓Essai de 14 jours, sans carte au départ. Paiement collecté au 12e jour.
- ✓Checkout hébergé par Stripe pour un périmètre PCI SAQ-A. (Adyen si vous avez besoin de SEPA / iDEAL.)
- ✓Séquence de relance : 3 tentatives sur 7 jours, un e-mail à chaque étape, puis rétrogradation.
- ✓TVA par juridiction (CH, UE, US) sur la facture. Affichage multidevise.
- ✓Forçage admin, remboursement sous 30 jours, journal d’audit complet.
La même source, décomposée en arbre de fonctionnalités.
Ces conseils n’ont pas été inventés. Ils viennent de notre index RAG privé de chaque projet livré : spécifications Confluence, tickets Jira, historique GitLab, rétrospectives. Le même index décompose l’epic en un arbre de fonctionnalités propre, chacune prête pour les stories.
La spécification arrive sous une forme que vous relisez en cinq minutes.
Rédigée à partir de l’échange avec le BA et ancrée dans le contexte RAG. Les critères d’acceptation sont vérifiables. Les cas limites qui nous ont déjà piégés y figurent. Vous validez, ou la renvoyez avec un commentaire.
Souscrire à une offre et démarrer un essai payant
En tant qu’utilisateur inscrit sur la plateforme,
je veux choisir une offre d’abonnement et démarrer un essai gratuit de 14 jours sans saisir mes coordonnées de paiement au départ,
afin de pouvoir évaluer les fonctionnalités payantes sans risque avant de m’engager.
- ✓L’utilisateur voit trois offres (Starter, Pro, Business) avec les prix dans sa devise, une bascule mensuel/annuel et une offre clairement mise en avant.
- ✓Le choix d’une offre démarre immédiatement l’essai ; les coordonnées de paiement sont collectées au 12e jour via une page hébergée par Stripe (périmètre PCI SAQ-A).
- ✓Si le premier prélèvement échoue, la relance dure 7 jours (3 tentatives) avant la rétrogradation de l’accès. L’utilisateur est prévenu par e-mail à chaque étape.
- ✓TVA calculée par juridiction (CH, UE, US) et affichée sur la facture ; factures stockées dans une archive liée à Confluence.
- ✓L’admin peut forcer l’offre, prolonger l’essai ou rembourser sous 30 jours depuis le back-office (avec journal d’audit).
Des parcours de référence, pas inventés de zéro.
Notre designer imagine les écrans avec Claude à partir du design system Figma existant du projet, puis les compare à des parcours réels issus de Mobbin (Airbnb, Duolingo, Stripe, Netflix). Résultat : des parcours d’abonnement et de checkout qui semblent natifs dans le produit et suivent des patterns que les utilisateurs connaissent déjà.
Claude
Génère des premières maquettes, des micro-textes et des variantes de composants, en appliquant automatiquement les design tokens existants du projet.
Mobbin
De vrais parcours d’apps à succès : Stripe Checkout, changement d’offre Netflix, upgrade Spotify. Nous comparons les nôtres aux leurs avant de livrer.
Figma
Notre design system prêt à l’emploi. Les mêmes tokens, composants et primitives que le reste du produit, pour que les nouveaux écrans s’intègrent naturellement.
Spécification, design et tickets, directement dans vos outils.
Les livrables ne restent pas dans un outil d’IA. Ils arrivent là où votre équipe travaille déjà : Confluence pour la spécification, Jira pour le backlog, Figma pour l’UI. L’ingénierie peut démarrer demain.
Contexte métier, Q&R du BA, décisions, références RAG. Document vivant.
Arbre de stories avec critères d’acceptation, estimations et priorisation. Prêt pour le backlog.
Choix de l’offre, checkout, confirmation, back-office de facturation. Tout sur le design system.
Les tickets arrivent dans l’IDE. Les ingénieurs livrent.
Le travail ne change pas d’outil. Il vient là où se trouve déjà l’ingénieur. Claude récupère le ticket et la spécification Confluence dans l’IDE via MCP, le travail se répartit en pistes backend et frontend, et nos skills Claude maison gèrent les patterns que nous avons déjà livrés des centaines de fois.
Une IA qui respecte votre code.
Avant d’écrire une ligne de code de paiement, Claude charge le contrat projet de FinCo : structure des fichiers, conventions de nommage, périmètre des changements de ce sprint, ce qui est hors limites. Le SubscriptionController qui arrive dans la PR ressemble aux services existants de FinCo. Mêmes patterns, mêmes frontières, même vocabulaire. Pas de refactoring opportuniste. Pas de violation des conventions. Pas d’« IA qui fait n’importe quoi ».
›charger les règles du projet finco-platform
Claude MCP rapatrie tout.
L’ingénieur ne change pas d’onglet. Claude récupère PAY-101 depuis Jira, la spécification depuis Confluence et les implémentations passées les plus pertinentes depuis notre base de connaissances RAG, le tout dans l’éditeur en quelques secondes.
›récupérer PAY-101 avec la spécification et l’existant
Backend et frontend en parallèle.
Le même contexte chargé est réparti entre deux ingénieurs. Chacun reçoit la partie du travail liée à sa stack, plus une sélection de skills Claude maison affinées au fil des années de projets S-PRO.
Services d’abonnement & de facturation
L’ingénieur backend senior conçoit d’abord l’architecture des modules (services, adaptateurs, workers), puis implémente à l’intérieur de ces modules avec les skills Claude maison.
UI de choix d’offre & de checkout
Les maquettes viennent de Figma via MCP. Le rôle de l’ingénieur est de valider les composants générés, de les connecter à l’API et de gérer l’accessibilité & les états.
Les modules avant le code.
L’ingénieur backend senior définit d’abord les frontières des modules : ce qui est un service, un worker, un adaptateur. Une fois l’architecture revue, les skills Claude maison génèrent le code de base dans le contrat de chaque module.
Le backend livre un endpoint. Claude côté frontend le voit dans l’heure.
Dès que le SubscriptionController arrive POST /subscriptions et
POST /subscriptions/:id/cancel, le contrat d’API se synchronise automatiquement dans le dépôt frontend. La prochaine fois que l’ingénieur frontend ouvre Claude, les nouveaux endpoints sont déjà dans le contexte. Pas de collection Postman obsolète. Pas de message Slack pour demander le corps de la requête. Le frontend branche l’API dans l’heure qui suit sa livraison côté backend.
Les maquettes passent dans le code, sans être refaites.
La frame Figma est la source de vérité. Un serveur Figma MCP lit la maquette, et les skills Claude maison génèrent un composant React avec nos design tokens existants. Le rôle de l’ingénieur : valider, connecter à l’API et livrer.
export const PlanSelector = ({ plans, onSelect }) => { const [billing, setBilling] = useState('monthly'); return ( <Stack tokens={tokens.plans}> <BillingToggle value={billing} onChange={setBilling} /> {plans.map(p => ( <PlanCard key={p.id} plan={p} featured={p.featured} onPick={onSelect} /> ))} <Button variant="primary"> Start 14-day free trial </Button> </Stack> ); };
De la fonctionnalité à la topologie cloud, en un prompt.
Le payments-service a besoin de plus que du code. Il lui faut une base de données, une file, des secrets, un endpoint de webhook, de l’observabilité et un endroit où tourner. Claude rédige l’Infrastructure-as-Code à partir de patterns déjà livrés sur AWS, Azure et GCP, en générant Terraform, Pulumi ou CDK selon le cas. L’ingénieur relit, durcit et applique.
Les ressources d’abord, le code ensuite.
À partir de déploiements passés d’abonnements & paiements, Claude propose l’ensemble des ressources : edge, calcul, données, secrets, observabilité, intégrations. L’ingénieur retire ce qui n’est pas nécessaire pour ce client (pas de Redis si l’app existante en a déjà un) et ajoute ce qui est spécifique.
Terraform pour le cloud, Helm pour le cluster.
Même approche que pour le code backend : les skills Claude maison génèrent une première version des modules Terraform et des valeurs Helm. L’ingénieur lit chaque ligne, durcit les règles IAM et réseau, puis applique. Rien n’est autonome, mais c’est rapide.
# Subscription & Payments stack module "payments_db" { source = "./modules/rds-postgres" name = "subscriptions" instance_class = "db.t4g.small" multi_az = var.env == "prod" } module "payments_service" { source = "./modules/ecs-service" name = "payments-service" cpu = 512 memory = 1024 desired_count = var.env == "prod" ? 3 : 1 secrets = [ "stripe/secret_key", "stripe/webhook_secret", ] } module "webhook_endpoint" { source = "./modules/stripe-webhook" events = [ "invoice.payment_failed", "customer.subscription.updated", ] }
replicaCount: {{ .Values.env.replicas }} image: repository: payments-service tag: {{ .Chart.AppVersion }} resources: requests: cpu: 200m memory: 512Mi limits: cpu: 500m memory: 1Gi autoscaling: enabled: true minReplicas: 2 maxReplicas: 10 targetCPU: 70 env: - name: DATABASE_URL valueFrom: secretKeyRef: payments-db
Du dev à la prod avec la même source de vérité.
Les mêmes modules Terraform et Helm s’appliquent au dev, au staging et à la production. Les différences sont des variables par environnement (tailles d’instances, nombre de réplicas, durées de conservation), pas des exceptions modifiées à la main. La dérive est vérifiée chaque nuit.
Développement
SynchroniséStaging
SynchroniséProduction
SynchroniséLa QA sans goulot d’étranglement.
Notre Agent QA récupère dans Jira les tickets prêts pour la QA, rédige des scénarios de test à partir des critères d’acceptation, et Playwright MCP les exécute dans de vrais navigateurs. Les mêmes scénarios tournent en régression nocturne. Le résultat est un rapport de test avec preuves, pas une coche verte sortie d’une boîte noire.
Claude liste d’abord les tickets prêts.
La QA ne court pas après les tickets. Claude lit Jira et regroupe tout par statut — ce que le dev considère prêt, ce qui est en cours, ce qui est bloqué — pour que le testeur voie tout le lot d’un coup.
›qu’est-ce qui est prêt pour la QA sur l’epic Abonnements & paiements ?
Pas de sélecteurs fragiles. Pas de page objects.
Pour chaque critère d’acceptation, Claude rédige un scénario numéroté que n’importe quel testeur (ou partie prenante côté client) peut lire. L’ingénieur QA relit, ajuste et le confie à Playwright MCP pour l’exécution.
- Se connecter en tant qu’utilisateur de test
alice@finco.ch(sans abonnement actif). - Aller sur
/pricing. - Cliquer sur Démarrer l’essai sur la carte de l’offre Pro .
- Vérifier que la page redirige vers
/dashboard/pro. - Vérifier que la bannière d’essai affiche « 14 jours restants ».
- Vérifier que aucune page de paiement n’est affichée à la première visite.
- Avancer l’horloge de 11 jours via
scheduler.advance(11d). - Vérifier que l’utilisateur reçoit l’e-mail add-payment-method .
- Vérifier que
/billingaffiche le CTA « Ajouter un moyen de paiement » .
Playwright MCP exécute le scénario.
Claude pilote Chromium étape par étape, lit le DOM en direct (pas seulement les pixels), prend des captures en cas d’échec et relance après correction. Les mêmes scénarios tournent chaque nuit en régression complète — tout ce qui casse fait l’objet d’un rapport dans le Slack de l’équipe avant le standup.
- ✓Connecté en tant que
alice@finco.ch - ✓Navigué vers
/pricing - ✓Clic sur Démarrer l’essai sur la carte de l’offre Pro
- ✓Redirigé vers
/dashboard/pro - ▶Vérification que la bannière d’essai affiche 14 jours restants…
- ○Vérifier l’absence de page de paiement à la première visite
- ○Avancer l’horloge
scheduler.advance(11d) - ○Vérifier l’envoi de l’e-mail add-payment-method
Deux rôles, une seule passe de régression.
PAY-101 implique deux rôles : le client qui souscrit à une offre et l’admin qui, dans le back-office, force des offres, prolonge des essais et rembourse des prélèvements. Les deux parcours tournent en parallèle dans une seule fenêtre de navigateur, avec cookies, sessions et stockage isolés par onglet. Une seule passe de régression vérifie que le client a souscrit, que l’admin a vu l’entrée du journal d’audit et que le forçage s’est appliqué, sans aucune contamination entre les sessions.
Un rapport validé, pas une simple coche verte.
Chaque passe de QA produit un rapport auditable : quel critère a été vérifié, avec quelles étapes, avec quel résultat. Les échecs incluent le chemin exact de reproduction et un bouton Copier le bug pour l’envoyer directement dans Jira.
Rapport de test : PAY-101 · Souscrire à une offre
Synthèse
Matrice de couverture des tests
| Domaine | Critère | Réussis | Échoués | Bloqué | Couverture |
|---|---|---|---|---|---|
| Choix de l’offre & tarifs | AC-001 | 1 | 0 | 0 | 100% |
| Démarrage de l’essai sans paiement | AC-002 | 1 | 0 | 0 | 100% |
| Relance après échec de paiement | AC-003 | 0 | 1 | 0 | 0% |
| Calcul de la TVA par juridiction | AC-004 | 1 | 0 | 0 | 100% |
| Forçage admin & remboursement | AC-005 | 1 | 0 | 0 | 100% |
| Total | 5 | 4 | 1 | 0 | 80% |
Échoués (1 / 5)
Critère : « Si le premier prélèvement échoue, la relance dure 7 jours (3 tentatives) avant la rétrogradation de l’accès. L’utilisateur est prévenu par e-mail à chaque étape. »
- Configurer un abonnement avec une carte de test Stripe en échec
4000 0000 0000 0341 - Première tentative de prélèvement déclenchée à 09:00 via le simulateur de webhooks
- Attente de la première nouvelle tentative à 09:15
- ÉCHEC — Aucun e-mail de relance reçu avant la 2e tentative à 09:30
- Attendu : e-mail après le premier échec. Constaté : seulement après le second.
47 scénarios, un bouton, n’importe qui dans l’équipe.
Une fois les 47 scénarios de PAY-101 validés, ils sont enregistrés dans le système de gestion des tests du projet : versionnés, tagués, liés aux critères d’acceptation. Demain, quand PAY-102 sera livré, la même suite servira de contrôle. Dans six mois, quand FinCo intégrera un nouveau QA, celui-ci lancera la régression d’hier dès son premier jour. Claude peut aussi lancer la suite : aucun humain nécessaire pour savoir si le parcours d’abonnement est « toujours vert ».
La régression n’est pas une personne. C’est un bouton.Release candidate, rétrospective, boucle de connaissances bouclée.
PAY-101 ne s’arrête pas au « merged ». La release part, le système observe, l’équipe apprend, et le prochain epic démarre avec ce que nous venons d’apprendre déjà intégré.
Lire les PR. Rédiger les notes. Valider.
Claude lit les PR de PAY-101 et les tickets Jira liés, puis rédige les notes de release au format maison de FinCo : changelog client, diff de l’API interne, notes de migration pour l’équipe plateforme. L’ingénierie valide ; rien n’est saisi deux fois à la main.
Notes de release · PAY-101 en production
- NOUVEAUEssai gratuit de 14 jours sur les offres Pro et Business, sans carte au départ.
- NOUVEAUCollecte du paiement hébergée par Stripe au 12e jour de l’essai.
- AMÉLAffichage multidevise dans le choix d’offre (CHF, EUR, USD).
- +
POST /api/v1/subscriptions - +
POST /api/v1/subscriptions/:id/cancel - ~
GET /api/v1/billing/invoicesrenvoie désormais la TVA.
- ENVNouveau :
STRIPE_API_KEY,STRIPE_WEBHOOK_SECRETdans Secrets Manager. - SQLMigration
2026_05_07_subscriptions_init.sqlappliquée.
Relus par les SRE avant le premier incident.
Blocage des webhooks Stripe. File de relance saturée. API TVA limitée en débit. Échec de génération des factures. Chaque scénario reçoit un runbook généré à partir du schéma d’architecture : procédure de reprise, escalade d’astreinte, déclencheur de rollback.
Derrière un flag, sur une partie du trafic.
PAY-101 est livré derrière un feature flag, en canary sur une partie du trafic de FinCo. Les métriques de succès des abonnements, de déclenchement des relances et de calcul de la TVA sont branchées avant le déploiement. Les seuils d’anomalie sont ajustés pendant les deux premières semaines d’usage réel.
PAY-102 démarre avec les leçons de PAY-101 déjà chargées.
Ce qui a marché, ce qui a glissé, ce qui nous a surpris. Capturé et réindexé dans la base de connaissances. Le prochain epic sur ce produit (ou un produit comparable) démarre automatiquement plus intelligemment.
- Figma MCP a fait gagner 3 jours de dev sur le choix d’offre.
- Le contexte RAG sur AC-002 a détecté le bug limite de l’essai avant le merge.
- Skill maison
stripe-checkout: zéro reprise.
- Timing de l’e-mail de relance (AC-003) : détecté en QA, pas en test unitaire.
- Les identifiants Adyen ont bloqué PAY-112 pendant 3 jours.
- La TVA pour la Suisse était plus simple que prévu (taux unique).
- L’affichage multidevise était prêt dès le premier jour.
Les projets ne ralentissent pas la deuxième année. Ils accélèrent.
Deux semaines après la livraison de PAY-101, Claude lance le premier audit technique planifié du projet sur le nouveau code : dérive d’architecture, exports inutilisés, branches mortes dans la logique de relance, dépendances en retard. Ensuite, l’audit tourne toutes les deux semaines sur l’ensemble du code.
PAY-101 · 14 jours après la release
- 0 dérive d’architecture par rapport aux règles OK
-
2
exports inutilisés dans
subscription.service.tsFaible - 1 branche morte dans la logique de relance Faible
-
3
dépendances en retard :
stripe,zod,pgMoyen
Ce qu’on nous demande.
De vraies questions de vrais prospects, des réponses directes.
Les assistants de code IA sont des outils formidables, mais pas des baguettes magiques pour des logiciels complexes. Dès que vous dépassez un simple prototype, l’IA atteint vite ses limites de contexte, peine sur les intégrations complexes et se perd en gérant des dizaines de tickets en parallèle.
Nous apportons l’état d’esprit d’ingénierie nécessaire pour gérer les fenêtres de contexte, l’optimisation des tokens et l’architecture système, afin que votre projet franchisse réellement la ligne d’arrivée.
Oui, c’est sûr. Nous utilisons des environnements de niveau entreprise et des politiques strictes de gouvernance des données. Votre code propriétaire et votre logique métier ne sont jamais utilisés pour entraîner des modèles d’IA publics.
Nous garantissons que votre propriété intellectuelle reste entièrement la vôtre et totalement isolée.
Absolument. Notre méthodologie AI SDLC est entièrement indépendante du modèle.
Si votre équipe conformité restreint l’usage d’outils comme Claude ou OpenAI, nous pouvons faire passer votre développement par des plateformes d’entreprise sécurisées et approuvées ou des environnements cloud privés comme AWS Bedrock ou MS Foundry.
Non. Il y a une énorme différence entre du « code IA bâclé » rapide et notre méthodologie de niveau bancaire. Nous ne laissons pas l’IA écrire du code sans contrôle ; nous utilisons l’IA pour renforcer les workflows d’ingénieurs seniors.
Chaque ligne de code passe par un Agent QA rigoureux et des tests automatisés (comme Playwright) pour garantir une architecture solide, évolutive et maintenable.
Un développement par IA non maîtrisé peut vite faire exploser les coûts à cause d’une mauvaise « tokenomics ». Nos architectes structurent les prompts et le partage de contexte pour optimiser fortement l’usage des tokens.
Nous savons exactement comment exploiter la technologie efficacement pour que votre projet reste dans le budget, sans sacrifier la qualité.
Le paysage de l’IA change chaque semaine, et nous aussi. Nous évaluons, testons et intégrons en continu les derniers modèles et outils de pointe dans notre pipeline.
Cette page reflète notre stack actuelle, et nous mettons à jour notre méthodologie tous les quelques mois en toute transparence pour que vous ayez toujours le meilleur avantage concurrentiel possible.
Pas du tout. Notre approche automatise les phases fastidieuses d’exécution et de validation, ce qui libère nos ingénieurs seniors et nos product owners pour agir en véritables consultants.
En laissant l’IA prendre en charge le gros de la génération de code, nos experts se concentrent entièrement sur votre logique métier, la résolution créative des problèmes et l’adéquation parfaite du produit à votre vision.
Le développement traditionnel avance par trimestres ; nous avançons en jours et en semaines. En automatisant l’implémentation et la validation, nous réduisons drastiquement le time-to-market.
Vous pouvez ainsi tester vos idées avec des groupes cibles et mettre de vrais produits entre les mains de vos utilisateurs bien plus vite que la norme du secteur.