Livrer un SaaS en 3 semaines avec Claude Code

Claude Code seul ne suffit pas à livrer vite. Ce qui crée la vitesse, c’est le cadre autour : des règles écrites, des tickets détaillés, des rôles clairs, une recette réelle et un humain qui décide de la production. Voici comment une petite équipe de TIC-NOVA s’y prend, avec ses chiffres, ses limites et ses erreurs.

Le contexte

Une petite équipe, un lead qui est aussi responsable produit et trois développeurs, a construit un SaaS métier B2B complet pour un premier client : une API, un back-office web, un site public et une application mobile. Le travail est réparti entre plusieurs sessions Claude Code qui avancent en parallèle, supervisées par une session « lead dev ».

Pour des raisons de confidentialité, nous ne nommons ni le client ni le produit, et les exemples de cet article sont génériques.

Les chiffres, et leurs limites

Sur trois semaines, du 6 au 27 octobre 2026, nous avons mesuré dans le dépôt et le suivi de tickets :

environ 680 commits sur la branche principale de développement ;
près de 300 demandes de fusion fusionnées en 9 jours, soit 30 à 35 par jour ;
près de 100 000 lignes de code ajoutées et environ 29 000 supprimées, sur environ 1 100 fichiers ;
23 versions livrées, de la 0.0 à la 0.16 ;
plus de 600 tickets suivis, et 4 applications couvertes.

Ce sont des mesures d’activité, pas des preuves de gain de productivité. Nous n’avons ni comparaison « avant / après » ni équipe témoin sans Claude Code, et le nombre de lignes de code ne mesure pas la valeur. Ce qui compte, et qui se voit : la cadence de livraison, le nombre de versions, et le fait que la recette sur environnement réel suit.

Les dix pratiques qui font avancer vite

1. Un fichier CLAUDE.md court, versionné. Une page et demie, dans le dépôt, lue par toutes les sessions. Il dit où se trouve la vérité et dans quel ordre la consulter, les règles de code en dix lignes, les règles Git et d’intégration continue, et les interdits : pousser sur les branches principales, modifier les variables de CI, lancer une migration en production, désactiver un test. Toute nouvelle session démarre dans le même cadre, et on met le fichier à jour par une demande de fusion comme une autre.

2. Une source de vérité hiérarchisée. Les décisions sont écrites dans un fichier daté. Quand deux documents se contredisent, l’ordre de priorité tranche : Claude n’a pas à deviner ce qui a été décidé, et nous non plus trois semaines plus tard.

3. On complète le ticket, pas le prompt. Un ticket décrit une tâche précise : fichiers concernés, étapes, tests attendus. Si le ticket ne suffit pas, on le complète. N’importe quelle session peut alors prendre n’importe quel ticket, et le travail reste traçable.

4. Les maquettes comme point de départ et comme référence de recette. On code à partir de la maquette, pas à partir de l’ancienne page. La recette compare l’écran réel à la maquette, côte à côte, sur deux largeurs. Une fonctionnalité maquettée mais absente est un défaut, pas une suggestion.

5. Une session « lead dev » qui orchestre. C’est la pratique qui change le plus la vitesse. La session lead dev répartit les tickets, relit les demandes de fusion, les fusionne quand l’intégration continue est verte et prépare les versions. Elle ne code presque pas. Des sessions paires prennent un ticket ou un lot de tickets, le codent, le testent et ouvrent la demande de fusion. Des sous-agents de recette testent le résultat déployé comme le ferait un utilisateur.

6. Un dossier de travail par session. Chaque session travaille dans son propre dossier Git isolé : pas de conflit entre sessions, pas de branche qui change sous les pieds. Ces dossiers pèsent lourd, avec leurs dépendances installées. Sur ce projet, une centaine de dossiers ont occupé plusieurs dizaines de gigaoctets et il a fallu nettoyer en urgence. Prévoyez un nettoyage régulier dès le départ.

7. Des garde-fous qui ne dépendent pas de la bonne volonté. Les permissions sont réglées par le projet : ce que Claude peut faire sans demander, ce qu’il doit demander. Un push forcé sur une branche partagée a été refusé automatiquement. Un humain donne le « go » pour la production, à chaque fois. Les données de test en production sont préfixées puis supprimées, et aucun secret n’est affiché ni enregistré.

8. Une mémoire persistante. Claude garde de petits fichiers mémoire, un fait ou une règle par fichier : comment on fait la recette, qui est assigné à quoi, ce qui a été décidé hier. Une nouvelle session ne repart pas de zéro et les mêmes erreurs ne se répètent pas.

9. Une recette automatisée avec de vraies interactions. Navigateur piloté par l’outil de test, émulateur pour le mobile, contrôle d’accessibilité automatique, comparaison maquette et réel, tests de bout en bout. Règle apprise : un échec de recette se confirme par une vraie interaction, clavier ou clic, pas par un script qui force l’élément. Sinon on fabrique de fausses alertes.

10. Des conventions qui font tourner les versions. Les commits suivent un format conventionnel, avec la référence du ticket. Un job lit ces commits, crée la version et son numéro. L’environnement de recette se déploie à chaque version, la production se déploie à la main.

Ce qui s’est mal passé

Une méthode qui n’avoue aucune erreur n’est pas crédible. Voici cinq erreurs réelles :

Deux demandes de fusion vertes qui cassent la branche principale une fois ensemble. Chacune passait la CI, mais un type partagé avait changé entre-temps. Désormais, une demande de fusion qui touche un type partagé se rebase avant d’être fusionnée, et c’est écrit dans le CLAUDE.md.
De fausses alertes de recette. Un « bug critique » rapporté n’en était pas un : c’était la mauvaise page. Il faut reproduire et confirmer avant d’ouvrir un ticket critique.
Un outil de filtrage de sortie qui déformait une liste, ce qui a fait échouer une suppression en masse. Dans un script, on ne laisse pas un filtre réécrire la sortie.
Une transition de ticket devinée au lieu d’être lue, par la session lead dev. Le ticket s’est retrouvé dans le mauvais statut, corrigé aussitôt. On liste les transitions disponibles avant de transitionner.
L’intégration continue devenue rare, faute de machine d’exécution disponible. Réponse : regrouper plusieurs petites tâches dans une seule demande de fusion, un commit par ticket, et tout vérifier en local avant de pousser.

Ce que nous ne promettons pas

Nous ne promettons ni « dix fois plus vite », ni « sans développeur », ni « l’IA fait tout ». Ce n’est pas notre expérience. Notre expérience, c’est une équipe humaine qui décide, relit et garde la main sur la production, et qui utilise Claude Code pour tenir une cadence de livraison élevée à l’intérieur d’un cadre strict.

Monter la même chose dans votre équipe

Si vous voulez mettre en place Claude Code sur un vrai projet d’équipe, avec un CLAUDE.md, des tickets, des sessions et une recette adaptés à votre contexte, parlez-nous de votre projet.