Combien de temps faut-il pour développer un SaaS ?

Les fondateurs posent cette question en attendant un chiffre et reçoivent « ça dépend » — ce qui est vrai, inutile, et un peu vexant quand on essaie de planifier sa trésorerie ou d'annoncer une date à un investisseur.

Voici donc de vrais chiffres, suivis de ce qui détermine réellement lequel vous atteindrez. Ce n'est pas la vitesse à laquelle on écrit du code.

Les fourchettes honnêtes

Pour une équipe compétente construisant un produit réellement prêt pour la production — authentification, facturation, un workflow central, déployé et supervisé :

Si quelqu'un vous annonce trois semaines pour la ligne du milieu, soit il comprend mal le périmètre, soit il prévoit discrètement de sauter les 40 % du travail qui rendent un logiciel viable. Les deux finissent de la même façon.

Où passe réellement le temps

Un projet type de 12 semaines se décompose plus souvent ainsi qu'on ne l'imagine :

• Cadrage et découverte — 1 à 2 semaines. Décider ce qu'il ne faut pas construire. Le temps le plus rentable du projet.
• Design — 2 à 3 semaines. Parcours et écrans, validés avant que le développement ne commence.
• Développement du cœur — 5 à 7 semaines. La partie que tout le monde prend pour le projet entier.
• Intégration et recette — 1 à 2 semaines. Navigateurs, cas limites, chemins d'erreur.
• Préparation au lancement — 1 semaine. Supervision, sauvegardes, limitation de débit, la liste ingrate.

Le code fonctionnel occupe donc environ la moitié du calendrier. C'est normal et ce n'est pas du gaspillage : l'autre moitié est ce qui distingue un produit d'une démo.

La variable dont personne ne parle

Voici ce que nous dirions à n'importe quel fondateur autour d'un café : les projets ne prennent pas du retard parce que le développement est lent. Ils prennent du retard parce que les décisions sont lentes.

Chaque projet génère un flux de questions auxquelles seul le client peut répondre. Que se passe-t-il quand un abonnement expire ? Un administrateur peut-il supprimer un utilisateur qui possède des données ? Lequel de ces trois parcours d'inscription retient-on ? Chacune est une petite question. Chacune, sans réponse, bloque du travail réel.

Nous avons vu deux projets de périmètre quasi identique se terminer à neuf semaines d'écart, et toute la différence tenait à ceci : l'un avait un décideur unique qui répondait dans la journée, l'autre faisait passer chaque question par un comité qui se réunissait le jeudi.

Pour comprimer votre délai, le levier le plus puissant à votre disposition n'est ni le budget ni la taille de l'équipe. C'est de désigner une personne habilitée à trancher sous 24 heures.

Ce qui ralentit systématiquement

1. Les ajouts déguisés en petites demandes. « Tant qu'on y est, est-ce que ça pourrait aussi… » — chacune est vraiment petite, et trente d'entre elles font un mois.
2. Le design par comité. Chaque relecteur supplémentaire ajoute un aller-retour et un compromis.
3. Les tiers. Si votre produit dépend de l'API, du bac à sable ou de la validation de quelqu'un d'autre, son calendrier devient le vôtre. Intégrations bancaires et validations de stores sont les suspects habituels.
4. Un « terminé » flou. Sans critères d'acceptation écrits, les fonctionnalités sont rediscutées après avoir été construites.
5. Démarrer le développement avant que le design ne soit figé. La reprise la plus coûteuse qui soit.

Ce qui accélère systématiquement

• Un périmètre écrit et figé avec un plan de jalons — chacun sait ce qui est inclus et ce qui est explicitement reporté en v2.
• Un décideur unique avec un engagement de délai de réponse.
• Achetez les problèmes résolus. Authentification, paiements, e-mails et analytics disposent d'excellentes solutions prêtes à l'emploi. Les redévelopper, ce sont des semaines dépensées pour ne pas être mieux loti.
• Livrez d'abord le workflow central, mettez-le devant de vrais utilisateurs, et laissez leur comportement ordonner le backlog.
• Travaillez en parallèle. Concevez la phase deux pendant que le développement construit la phase une.

L'IA accélère-t-elle tout cela ?

En partie, et il vaut la peine d'être précis sur l'endroit. L'outillage IA a réellement comprimé le premier segment — échafaudage, code répétitif, première version d'interface. Un prototype qui prenait trois semaines en prend trois jours, et c'est réel.

Ce qu'elle n'a guère comprimé, c'est le reste : le modèle de sécurité, le modèle de données confronté à la réalité, les cas limites, les intégrations, et le travail opérationnel qui rend un produit fiable. C'est les 40 % entre un prototype et une application en production, et c'est là que se loge l'essentiel d'un calendrier de 12 semaines.

Attendez-vous donc à ce que l'IA déplace votre ligne de départ, pas votre ligne d'arrivée — un gain réel, simplement pas celui que les démonstrations laissent entendre.

Comment planifier autour de tout ça

Choisissez une date de lancement, remontez le calendrier, et réduisez le périmètre jusqu'à ce qu'il rentre — plutôt que de choisir un périmètre en espérant que la date suive. Le périmètre est la seule des trois variables (périmètre, temps, qualité) que l'on peut déplacer sans danger, car déplacer les deux autres ne fait que relocaliser la douleur.

Et budgétez comme vous planifiez : délai et coût avancent ensemble, à lire donc avec ce que coûte réellement un MVP SaaS.

Si vous voulez un calendrier ferme avec des dates de jalons plutôt qu'une fourchette vague, c'est ainsi que notre agence cadre chaque mission. Découvrez notre approche du développement SaaS, ou réservez un appel et nous vous remettrons un planning écrit.