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

Il n’existe pas de durée universelle défendable pour développer un SaaS. Définissez d’abord ce qui doit être prêt : prototype, pilote privé, ouverture contrôlée ou service soutenable. Pour chaque résultat, notez qui en répond, ce qui doit le précéder et qui est disponible.

Le calcul suit chaque suite de tâches dépendantes en jours ouvrés. La plus longue fixe la première fin possible : c’est la chaîne déterminante. Si plusieurs chaînes arrivent ensemble, elles restent toutes visibles.

Renseignez une durée favorable, centrale et prudente par tâche, avec la cause de l’écart. Gardez la réserve à part. Une entrée manquante, une boucle ou une personne ou équipe partagée entre des tâches sans ordre explicite bloque le calcul. Le résultat reste un brouillon à faire relire, jamais un engagement.

Représentez une tâche par son résultat, pas par une activité vague. Une tâche sans dépendance peut commencer à J1 si sa capacité est disponible. Si elle attend plusieurs résultats, son point de rencontre — la jonction — attend le dernier. Sa fin devient son début relatif plus sa durée. Ce calcul se répète jusqu’aux résultats terminaux. Les branches parallèles ne sont pas additionnées. En cas d’égalité, aucun chemin déterminant n’est masqué : chaque chaîne ex aequo est restituée.

début(tâche) = maximum des fins de ses prérequis
fin(tâche) = début(tâche) + durée du scénario
fin du réseau = maximum des fins terminales
total de revue = fin du réseau + réserve affichée séparément

Le Schedule Assessment Guide du GAO formalise, pour de grands programmes publics, l’importance de la logique horizontale, des liens complets et du plus long chemin continu vers la fin. Ici, on transpose seulement ce principe de calcul à un petit réseau SaaS. La source ne fournit ni durée type ni garantie pour ce contexte.

Le plan des dépendances dit ce qui doit attendre. La capacité désigne la personne ou l’équipe réellement disponible. Ces deux informations sont distinctes : deux tâches sans ordre métier peuvent pourtant se disputer la même personne ou équipe. Dans ce cas, le planificateur retourne CLARIFY_CAPACITY_BEFORE_CALENDAR jusqu’à ce qu’un ordre soit écrit ou qu’une personne ou équipe distincte soit confirmée.

Le Scrum Guide officiel de novembre 2020 borne un Sprint à un mois au maximum et en fait une boucle d’inspection et d’adaptation. Cette cadence aide à voir le travail et à apprendre ; elle ne donne pas la durée totale du SaaS. Compter des sprints sans relier les décisions, les tiers, les validations et l’exploitation change seulement l’unité d’une hypothèse incomplète.

Ajouter une personne, un outil d’IA ou une plateforme no-code ne raccourcit pas automatiquement la chaîne. Il faut montrer la tâche supprimée ou modifiée, la capacité réellement nouvelle, les jonctions déplacées et les preuves qui restent à produire. La durée est ensuite recalculée, jamais décrétée.

L’ordre des personnes ne suffit pourtant pas : deux calendriers ne se comparent que s’ils visent exactement le même résultat final.

« SaaS terminé » n’est pas une ligne d’arrivée. Décrivez qui peut utiliser le résultat, dans quel environnement, avec quelles données, quels contrôles, quel support et quelle possibilité de revenir en arrière. Sans cette frontière, deux calendriers peuvent couvrir des produits différents tout en employant le même mot.

Le Service Manual GOV.UK distingue découverte, alpha, bêta et phase live par leur but. Sa page de découverte, mise à jour le 21 juin 2021, demande de comprendre le problème avant de construire et prévoit qu’une équipe puisse arrêter. Sa page live, mise à jour le 8 mai 2019, maintient recherche, sécurité, accessibilité, supervision et qualité dans l’exploitation. Ces pages concernent des services publics britanniques : on reprend la distinction des fins, pas leurs indications de durée.

Une option sans nouveau produit peut être préférable

Avant de planifier le développement, rejouez le résultat attendu avec une fonction déjà disponible, une configuration limitée, un processus manuel contrôlé, un contenu explicatif, un partenariat ou l’option de ne rien construire. Comparez le même utilisateur, le même résultat, les mêmes risques et la même preuve. Si l’option plus légère tient la ligne d’arrivée, elle devient la décision à revoir.

La tâche support-prepare avance réellement en parallèle du parcours construit grâce à une capacité distincte. Elle rejoint le réseau à la recette et n’est pas additionnée si elle finit avant l’autre prérequis. La capacité dev-relaispro apparaît deux fois, mais les tâches sont explicitement ordonnées par la recette : aucun parallélisme artificiel n’est supposé.

favorable : 3 + 8 + 3 + 2 = 16 ; réserve 4 ; revue J+20
central : 5 + 12 + 5 + 3 = 25 ; réserve 4 ; revue J+29
prudent : 7 + 17 + 8 + 5 = 37 ; réserve 4 ; revue J+41
stress combiné : (6 + 6) + 17 + (8 + 5) + 5 = 47 ; réserve 4 ; revue J+51
raisonnement inverse : prudent avec réserve 41 - maximum 34 = écart de 7 jours

Le stress combiné dégrade en même temps l’attente externe et la validation interne. La chaîne déterminante bascule alors de parcours → parcours-construit → recette → pilote-ouvert vers acces-tiers → parcours-construit → recette → pilote-ouvert. Le moteur ne conserve donc pas un chemin critique figé. Il n’emploie l’étiquette « stress combiné » que si ces deux familles portent chacune un effet additionnel strictement positif ; avec une seule ou aucune, il le dit explicitement.

Sur votre projet, vérifiez maintenant si les entrées sont assez complètes et cohérentes pour autoriser le calcul.

Commencez vide ou chargez RelaisPro. Le moteur vérifie les identifiants, les responsables, les trois durées, l’ordre des tâches, les boucles et les personnes ou équipes partagées. Il ne calcule les quatre scénarios qu’après ces portes. Le brouillon Markdown reste visible et sélectionnable pour être relu.

Chaque champ numérique conserve la chaîne saisie avant conversion. Le point est le seul séparateur décimal accepté (par exemple 0.5), sans exposant, avec au plus six décimales significatives et une borne technique de 1 000 000 jours ouvrés. Toute entrée ou somme qui dépasse ces règles place les quatre scénarios en STOP : elle n’est jamais arrondie ni partiellement calculée.

# Plan de calendrier SaaS — brouillon local

## Statut

**STOP_REQUIRED_INPUTS_UNKNOWN** — STOP — les entrées nécessaires restent inconnues

Le calcul ne remplace pas une ligne d’arrivée, un résultat, un responsable, une capacité, trois durées et une incertitude explicitement renseignés.

Prochaine action : Attribuez les entrées manquantes. Conservez une valeur inconnue comme inconnue : ne la remplacez pas par zéro.

## Ligne d’arrivée

STOP — ligne d’arrivée inconnue

## Travail, responsables, capacités et dépendances

- STOP — aucune tâche renseignée

## Entrées manquantes

- Ligne d’arrivée non renseignée
- Aucune tâche renseignée
- Réserve explicite en jours ouvrés non renseignée
- Maximum de jours ouvrés disponibles non renseigné

## Erreurs de réseau

- Aucune erreur de réseau détectée

## Conflits de capacité à clarifier

- Aucun conflit de capacité détecté

## Scénarios déterministes

STOP — aucun scénario calculé

## Raisonnement inverse

- STOP : impossible avant validation des entrées et du réseau.

## Limites

- J+N signifie N jours ouvrés écoulés depuis l’ouverture de J1, pas le numéro ordinal du jour : une tâche de 1 jour occupe J1 et atteint son jalon à J+1.
- La réserve reste distincte des durées et ne représente aucune probabilité.
- Les tâches réellement parallèles ne sont pas additionnées ; tous les chemins dépendants ex aequo qui déterminent la fin relative sont affichés.
- Cet outil calcule. Une personne décide de la ligne d’arrivée, du périmètre, de la capacité et de l’engagement éventuel.

Le calcul peut maintenant démarrer. Avant d’en discuter, expliquez ce que couvrent les trois durées et ce qui relève de la réserve.

Écrivez pour chaque tâche une hypothèse favorable, centrale et prudente. L’écart doit venir d’une incertitude observable : nombre de cas à arbitrer, disponibilité d’une validation, qualité des données fictives, temps de réponse d’un tiers ou reprise après un contrôle. Une simple étiquette sans cause ne rend pas la valeur défendable.

Le raisonnement inverse compare le maximum de jours ouvrés réellement disponibles au scénario prudent, réserve séparée comprise. S’il manque sept jours, le résultat est un écart de sept jours. Le moteur ne réduit aucune tâche, ne déplace aucune preuve et ne prétend pas qu’une nouvelle capacité existe.

Six décisions possibles, aucune n’est automatique

1. Changer la ligne d’arrivée : passer d’une ouverture générale à un pilote privé, avec ses propres preuves.
2. Retirer un résultat de la première version : accepter explicitement ce qui est reporté et son effet pour l’utilisateur.
3. Remplacer le développement : utiliser une fonction existante ou un processus manuel contrôlé pour le même résultat.
4. Changer l’ordre : seulement si la dépendance métier le permet et si les nouveaux points de rencontre sont testés.
5. Ajouter une personne ou équipe réellement disponible: nommer sa disponibilité et les coordinations induites.
6. Déplacer la date : après définition de J1 et de la convention de jours ouvrés applicable.

Après chaque décision, reconstruisez le réseau depuis les entrées. Une correction peut déplacer la chaîne déterminante, créer un conflit de capacité ou changer le stress combiné. Une capture d’un ancien calcul ne constitue pas une preuve du nouveau calendrier.

Une date ne devient défendable que si le calendrier comprend aussi les contrôles et l’exploitation qui rendent le service utilisable.

Ne placez pas les contrôles essentiels dans une tâche finale appelée « mise en production ». Reliez chaque contrôle au travail qu’il peut bloquer : choix de données fictives, règles d’accès, critères d’accessibilité, tests unitaires et d’intégration, sécurité, environnement de préproduction, restauration, observabilité, support, correction et retour arrière. Un échec arrête ainsi le calendrier au bon endroit.

Le NIST SP 800-218 SSDF v1.1 est final depuis février 2022. Il recommande d’intégrer les pratiques de développement sécurisé tout au long du cycle. La v1.2 publiée le 17 décembre 2025 reste une Initial Public Draft : elle ne remplace pas la v1.1 finale dans ce guide. De son côté, le guide CNIL de sécurité, version 2024 mise à jour en 2026, demande notamment des tests avant mise en production, la séparation des environnements et l’usage de données fictives lorsque possible.

Contrôle autonome avant une date civile

1. Relire la ligne d’arrivée avec son autorité d’acceptation.
2. Attribuer chaque résultat, décision et réponse externe.
3. Vérifier tous les liens, les jonctions et l’absence de cycle.
4. Ordonner les tâches qui partagent une capacité.
5. Expliquer chaque écart favorable, central et prudent.
6. Rejouer le stress combiné et observer le changement de chemin.
7. Comparer le prudent au maximum disponible sans le comprimer.
8. Fixer J1 et la convention de jours ouvrés seulement après cette revue.

Une fois ces contrôles terminés, le cahier des charges SaaS aide à figer ce qui doit être construit. L’organisation de la recette prépare les preuves d’acceptation. La page SaaS et applications métier décrit l’accompagnement. Pour demander une relecture, partagez une version sans donnée sensible.

Un calendrier ne se raccourcit pas en pressant l’équipe, mais en réduisant le périmètre : le guide ce qu’un MVP doit contenir explique quelles fonctions peuvent attendre sans vider le produit de son intérêt. En amont, la validation d’une idée de SaaS évite de planifier un développement dont l’hypothèse principale n’a jamais été confrontée à un client.

Trois inconnues pèsent plus lourd que les autres sur une date. Le calcul du retour sur investissement arbitre ce qui justifie d’allonger le calendrier. La reprise d’un logiciel métier existant et la migration sans interruption de service ajoutent des tâches que les plannings oublient presque toujours : inventaire, reprise de données, coexistence et retour arrière. Enfin, choisir un prestataire sur preuves évite d’accepter une date qu’aucun élément ne soutient.