--- title: "AI-Native SDLC : fonctionnalités bancaires en jours | S-PRO" url: https://s-pro.io/fr/sdlc-natif-ia lang: fr description: "Comment S-PRO livre des fonctionnalités logicielles de niveau bancaire en jours : spécification, développement, infrastructure et Agent QA augmentés par l’IA." updated: 2026-07-30T08:45:15+00:00 source: S-PRO (https://s-pro.io) --- # 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. Promesse 1 · Vélocité ### 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. Promesse 2 · Créativité libérée ### 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. Boîte de réception · hi@s-pro.io Aujourd’hui · 09:42 De **John Weber** À hi@s-pro.io ### 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 Réponse · de S-PRO Aujourd’hui · 10:11 De **Sarah Müller** · Product Owner À john@finco.ch ### Re : Besoin d’abonnements & de paiements sur la plateforme Bonjour John, Ce sera prêt **la semaine prochaine**. Cordialement, Sarah Product Owner · S-PRO Découvrir comment Ou lire les questions fréquentes Faites défiler pour voir la suite 01 Phase 01 · Spécification & design ## 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. 1Demande client + conseil ### 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. JW John Weber · CEO, FinCo · client « Je veux ajouter des **abonnements et des paiements** à ma plateforme. » Conseil · Product Owner + BA S-PRO Issu de **17 missions similaires d’abonnements & paiements** 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. **Issu de** notre base de connaissances des missions passées 2Base de connaissances → fonctionnalités ### 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. Spécifications Confluence Exigences passées 412 Tickets Jira Stories, critères d’acceptation, anomalies 8.4k Historique GitLab Patterns de code & de revue 126 dépôts Rétrospectives Retours d’expérience 47 **Base de connaissances S-PRO** En direct · Privée & isolée par projet Epic : Abonnements & paiements 8 fonctionnalités · prêtes pour les stories F-01Choix de l’offre F-02Activation de l’essaiPAY-101 est ici F-03Collecte du paiement (hébergée par Stripe) F-04Séquence de relance & de nouvelles tentatives F-05Calcul de la TVA F-06Affichage multidevise F-07Forçage admin & remboursement F-08Journalisation d’audit 3Le résultat : une user story complète ### 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. PAY-101 Story Epic : Abonnements & paiements Fonctionnalité : F-02 Activation de l’essai P1 Prêt pour le design ### Souscrire à une offre et démarrer un essai payant User story **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. Critères d’acceptation - ✓ 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). Liés : 3 epics précédents Contexte RAG : 18 documents Rédigé par Claude · Relu par le BA 4Idéation UI/UX, validée face aux meilleurs ### 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à. Copilote #### 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. M Validation #### 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. Source de vérité #### 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. 5Wireframes & passation documentée ### 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. Abonnement · Choix de l’offre Starter $0/mois Pro $29/mois Business $99/mois Cycle de facturation · Mensuel | Annuel (–20 %) Prestataire de paiement · Stripe (hébergé) TVA · Calculée automatiquement par région Démarrer l’essai gratuit de 14 jours Confluence · Spécification de l’epic Contexte métier, Q&R du BA, décisions, références RAG. Document vivant. Jira · Epic + 14 stories Arbre de stories avec critères d’acceptation, estimations et priorisation. Prêt pour le backlog. Figma · Wireframes & design final Choix de l’offre, checkout, confirmation, back-office de facturation. Tout sur le design system. 02 Phase 02 · Développement ## 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. 1Claude lit d’abord les règles de FinCo ### 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 ». claude · finco-platform contrat projet ›charger les règles du projet finco-platform ✓claude.mdconventions du projet & structure des fichiers ✓docsarchitecture.md, code-style.md ✓eslintrègles maison & exceptions du projet ✓scopece sprint : abonnements & paiements uniquement ✓no-goauth-service, payments-legacy (hors périmètre) → Fonctionne selon les règles de FinCo, pas par défaut. 2Le ticket arrive dans l’IDE ### 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. claude · payments-service MCP connecté ›récupérer PAY-101 avec la spécification et l’existant ✓jiraticket chargé PAY-101 — Souscrire à une offre ✓confluencespécification récupérée Abonnements & paiements / Discovery ✓rag3 implémentations précédentes référencées ✓skills13 skills maison disponibles pour cette stack → Contexte chargé. Prêt à implémenter. 3Un epic, deux pistes ### 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. PAY-101 Souscrire à une offre et démarrer un essai payant Piste backend #### 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. Piste frontend #### 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. 4Backend : l’architecture d’abord ### 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. payments-service · architecture des modules API · Controller SubscribeController Service SubscriptionService Service PlanService Adaptateur StripeAdapter Worker WebhookHandler Worker DunningWorker Repository SubscriptionRepository Repository InvoiceRepository Service VATCalculator Backend POST /subscriptions synchro auto du contrat Frontend useSubscription() ### 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. 5Frontend : de Figma MCP au composant ### 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. Figma · Choix de l’offre Figma MCP React · PlanSelector.tsx export const PlanSelector = ({ plans, onSelect }) => { const [billing, setBilling] = useState('monthly'); return ( {plans.map(p => ( ))} ); }; CI/CD · Contrôles qualité · chaque PR Vert · contrôle de merge validé Lint & formatage ESLint · Prettier OK Vérification des types TypeScript strict OK Tests unitaires Seuil de couverture 85 % 87% Build Backend + frontend OK Scan de sécurité Dependabot · gitleaks OK Smoke tests 10 scénarios critiques 10/10 **Vert = merge.** Rouge = reste ouverte. Le contrôle est le même pour chaque ingénieur, chaque PR, chaque projet. 03 Phase 03 · Infrastructure ## 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. 1Cartographier la topologie cloud ### 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. payments-service · topologie cloud · exemple AWS (nous livrons aussi sur Azure / GCP) Edge Route 53 + CloudFront Edge ALB / API Gateway Intégration Endpoint de webhook Stripe Calcul · ECS payments-service Calcul · ECS webhook-handler Calcul · CronJob dunning-worker Données · RDS subscriptions-db Données · ElastiCache sessions-redis Secrets Secrets Manager Observabilité CloudWatch · logs & métriques Observabilité X-Ray · traces Observabilité Alertes PagerDuty 2Claude rédige l’IaC ### 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. Terraform · payments.tf # 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", ] } Helm · values.yaml 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 3Un modèle, trois environnements ### 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é Dernier applyil y a 12 min Ressources42 Réplicas1 Base de donnéest4g.micro #### Staging Synchronisé Dernier applyil y a 2 h Ressources42 Réplicas2 Base de donnéest4g.small #### Production Synchronisé Dernier applyHier Ressources42 Réplicas3 · multi-AZ Base de donnéest4g.small + RR 04 Phase 04 · Agent QA ## 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. 1Récupérer ce qui est prêt pour la QA ### 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. claude · payments-qa Jira MCP ›qu’est-ce qui est prêt pour la QA sur l’epic Abonnements & paiements ? Prêt / Revue QA5terminé côté dev, en attente de QA PAY-101Souscrire à une offre et démarrer un essai payant PAY-103Parcours de montée & descente d’offre PAY-104Gestion des webhooks Stripe en cas d’échec de paiement PAY-105E-mails de relance pour la séquence de nouvelles tentatives PAY-108Admin : remboursement sous 30 jours depuis le back-office En cours2encore en implémentation PAY-109Génération des factures PDF avec TVA PAY-110Affichage multidevise dans le choix d’offre Bloqué1 PAY-112SEPA via Adyen *(en attente des identifiants de production)* → 5 tickets prêts à tester. Rédaction des scénarios à partir des critères d’acceptation… 2Des scénarios rédigés à partir des critères, en langage clair ### 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. Critère d’acceptation PAY-101 · AC-002 Scénario de test en langage clair rédigé par Claude · exécuté par Playwright MCP 1. Se connecter en tant qu’utilisateur de test `alice@finco.ch` (sans abonnement actif). 2. Aller sur `/pricing`. 3. Cliquer sur **Démarrer l’essai** sur la carte de l’offre **Pro** . 4. Vérifier que la page redirige vers `/dashboard/pro`. 5. Vérifier que la bannière d’essai affiche **« 14 jours restants »**. 6. Vérifier que **aucune page de paiement n’est affichée** à la première visite. 7. Avancer l’horloge de 11 jours via `scheduler.advance(11d)`. 8. Vérifier que l’utilisateur reçoit l’e-mail **add-payment-method** . 9. Vérifier que `/billing` affiche le CTA **« Ajouter un moyen de paiement »** . 3Claude clique, dans un vrai navigateur ### 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. Playwright · running PAY-101 · AC-002 En cours - ✓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 https://app.finco.ch/dashboard/pro 🎉 14 jours restants sur votre essai Pro **Régression nocturne** · les 47 scénarios · les échecs arrivent dans Slack avant le standup 4Client et admin, en parallèle ### 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. https://app.finco.ch/dashboard/pro CLIENT 🎉 14 jours restants sur l’essai Pro https://admin.finco.ch/users/alice ADMIN ✓ Journal d’audit : essai prolongé (admin : ops@finco.ch) **Les deux sessions vérifiées** · cookies, sessions et stockage isolés par onglet · zéro contamination croisée 5Rapport de test avec preuves ### 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 **Date :** 2026-05-07 · **Environnement :** finco-dev (https://app.dev.finco.ch) · **Branche :** feat/PAY-101-subscribe-trial **Testeur :** Claude AI (Senior QA) · **Navigateur :** Chromium (Playwright MCP) · **Suite :** 47 scénarios · exécutés en 4 min 12 s #### Synthèse 5 Total critères 4 Réussis 1 Échoués 0 Bloqué 80% Taux de réussite 1 Bugs trouvés #### 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) AC-003 FAIL L’e-mail de relance part à la deuxième tentative, pas à la première **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. » Étapes réalisées 1. Configurer un abonnement avec une carte de test Stripe en échec `4000 0000 0000 0341` 2. Première tentative de prélèvement déclenchée à **09:00** via le simulateur de webhooks 3. Attente de la première nouvelle tentative à **09:15** 4. **ÉCHEC —** Aucun e-mail de relance reçu avant la 2e tentative à **09:30** 5. 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. 05 Phase 05 · Déploiement & exploitation ## 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é. 1Notes de release rédigées à partir du travail mergé ### 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. v2.14.0 · 2026-05-07 Epic : Abonnements & paiements ### Notes de release · PAY-101 en production Changelog client - 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). API interne - +`POST /api/v1/subscriptions` - +`POST /api/v1/subscriptions/:id/cancel` - ~`GET /api/v1/billing/invoices` renvoie désormais la TVA. Notes de migration - ENVNouveau : `STRIPE_API_KEY`, `STRIPE_WEBHOOK_SECRET` dans Secrets Manager. - SQLMigration `2026_05_07_subscriptions_init.sql` appliquée. 2Des runbooks pour les nouveaux modes de défaillance ### 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. Blocage des webhooks Stripe reprise · escalade · rollback Runbook prêt File de relance saturée reprise · escalade · rollback Runbook prêt API TVA limitée en débit reprise · escalade · rollback Runbook prêt Échec de génération des factures reprise · escalade · rollback Runbook prêt 3Déploiement observable, canary d’abord ### 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. Canary · PAY-101 · production 25%du trafic Succès des abonnements 99.2% Taux de déclenchement des relances 0.3% Latence du calcul de TVA · p95 84ms 4Une rétro qui capitalise ### 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. Ce qui a marché - 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. Ce qui a glissé - 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. Ce qui a surpris - La TVA pour la Suisse était plus simple que prévu (taux unique). - L’affichage multidevise était prêt dès le premier jour. Indexé dans la base de connaissances S-PRO · PAY-102 démarre plus intelligemment 5Deux semaines après la release : le premier audit ### 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. Audit technique · planifié le 2026-05-21 Sain ### 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.ts` Faible - 1 branche morte dans la logique de relance Faible - 3 dépendances en retard : `stripe`, `zod`, `pg` Moyen **Prochain sprint :** 4 correctifs priorisés, en file dans Confluence avant le sprint planning. Dans trois mois, PAY-101 sera toujours comme au jour de sa livraison. Questions fréquentes ## 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. Lien copié dans le presse-papiers Langue - [EN](https://s-pro.io/ai-native-sdlc) - [DE](https://s-pro.io/de/ai-native-sdlc) - [FR](https://s-pro.io/fr/sdlc-natif-ia) [Nous contacter](https://s-pro.io/fr/nous-contacter)