Une date réglementaire approche. Un produit doit impérativement être lancé avant un concurrent. Un ancien système doit être arrêté à une date précise. La direction demande alors à la DSI : « Peut-on livrer trois mois plus tôt ? »
La réponse paraît parfois simple : renforcer l’équipe et accélérer.
Mais un projet logiciel ne se comporte pas comme une activité parfaitement divisible. Ajouter des personnes, multiplier les tâches parallèles ou réduire les temps intermédiaires entraîne également davantage de coordination, d’intégration et de sécurisation.
La question n’est donc pas seulement : pouvons-nous livrer plus tôt ?
Elle est aussi : combien cette accélération va-t-elle coûter ?
Ce que mesure la contrainte sur le calendrier
Le paramètre SCED — Required Development Schedule — mesure la contrainte imposée au calendrier du projet.
Le principe consiste à comparer le délai demandé au calendrier nominal, c’est-à-dire au délai normalement nécessaire compte tenu des caractéristiques du projet.
Un projet dont le calendrier nominal serait de 20 mois et qui doit être réalisé en 15 mois se situe ainsi à 75 % de son calendrier nominal.
Ce facteur est issu du modèle international COCOMO II, utilisé depuis de nombreuses années pour l’estimation des projets logiciels.
Sa particularité est importante : contrairement à beaucoup d’autres paramètres, il agit simultanément sur la question du délai imposé et sur l’effort nécessaire pour respecter ce délai.
Les différents niveaux
COCOMO II définit cinq situations principales :
| Niveau | Calendrier demandé |
| Très faible | 75 % du calendrier nominal |
| Faible | 85 % |
| Nominal | 100 % |
| Élevé | 130 % |
| Très élevé | 160 % |
Il faut ici éviter une confusion liée au vocabulaire COCOMO II : un niveau « très faible » ne signifie pas que la contrainte est faible. Il correspond au contraire à un calendrier très fortement comprimé, ramené à 75 % du calendrier nominal.
Les coefficients associés
Les coefficients d’effort COCOMO II.2000 sont :
| Calendrier | Coefficient d’effort |
| 75 % | 1,43 |
| 85 % | 1,14 |
| 100 % | 1,00 |
| 130 % | 1,00 |
| 160 % | 1,00 |
Deux enseignements apparaissent immédiatement.
Le premier est que comprimer fortement le calendrier augmente l’effort.
Le second est qu’allonger le calendrier au-delà du calendrier nominal ne génère pas automatiquement d’économie d’effort dans le modèle. Une équipe plus petite peut réduire certains coûts de coordination, mais le projet et ses fonctions de gestion doivent alors être maintenus plus longtemps.
Exemple sur un projet de 1 000 jours-homme
Prenons un projet nécessitant 1 000 jours-homme avec un calendrier nominal.
Toutes les autres hypothèses restent identiques.
| Calendrier demandé | Effort estimé | Écart |
| 75 % du nominal | 1 430 j.h | +430 j.h / +43 % |
| 85 % | 1 140 j.h | +140 j.h / +14 % |
| 100 % | 1 000 j.h | Référence |
| 130 % | 1 000 j.h | 0 % |
| 160 % | 1 000 j.h | 0 % |
Le résultat peut sembler paradoxal : réduire de 25 % le délai ne réduit pas de 25 % le coût. Cela peut au contraire augmenter l’effort de 43 %.
Il faut cependant interpréter correctement ces chiffres. Ils représentent l’effet statistique modélisé par COCOMO II, toutes les autres caractéristiques du projet étant supposées identiques. Ils ne constituent pas une règle universelle applicable mécaniquement à chaque projet.
Cas concret : un portail client à lancer impérativement
Imaginons la refonte d’un portail client dont le calendrier réaliste est estimé à 16 mois.
La direction souhaite finalement le mettre en production en 12 mois pour respecter une échéance commerciale.
Le calendrier demandé représente :
12 / 16 = 75 % du calendrier nominal.
La première tentation pourrait être de conserver le budget initial et simplement d’augmenter les effectifs pour raccourcir la durée.
COCOMO II invite à raisonner différemment.
Si l’effort nominal est de 1 000 jours-homme, le passage à 75 % du calendrier nominal conduit à un ordre de grandeur de 1 430 jours-homme.
La décision de gagner quatre mois doit donc être considérée comme un arbitrage économique : l’entreprise accepte potentiellement plusieurs centaines de jours-homme supplémentaires pour disposer plus tôt de son système.
Cette dépense supplémentaire peut être parfaitement rationnelle si la date possède une forte valeur économique ou réglementaire. L’essentiel est qu’elle soit identifiée et chiffrée.
Pourquoi un tel impact ?
Une forte compression du calendrier oblige généralement à augmenter le parallélisme.
Certaines activités qui auraient normalement été réalisées successivement doivent être menées simultanément.
Cela peut entraîner :
- davantage de coordination entre équipes ;
- des décisions d’architecture prises plus rapidement ;
- une mobilisation précoce pour identifier et réduire les risques ;
- des activités de développement et d’intégration davantage imbriquées ;
- des tests réalisés en parallèle d’autres travaux de finalisation ;
- une documentation produite simultanément avec les dernières phases du développement.
L’augmentation des ressources n’est donc pas intégralement transformée en réduction du délai.
Une partie de l’effort supplémentaire est absorbée par la coordination, la synchronisation et la sécurisation nécessaires à cette accélération.
Les symptômes observables
Plusieurs signaux doivent attirer l’attention d’une DSI :
- une date de mise en production fixée avant le chiffrage ;
- un planning construit à rebours depuis une échéance politique ou commerciale ;
- une augmentation rapide des effectifs pour « tenir la date » ;
- de nombreuses activités critiques menées simultanément ;
- des phases de validation raccourcies ;
- une multiplication des dépendances entre équipes ;
- une intégration repoussée tardivement ;
- des tests et corrections qui se chevauchent fortement.
Ces symptômes ne signifient pas automatiquement que le projet est mal piloté. Ils indiquent cependant que la contrainte de calendrier doit être explicitement intégrée au chiffrage et à l’analyse des risques.
Conséquences sur le chiffrage
Une estimation sérieuse ne devrait donc pas demander uniquement :
« Quelle est la date de livraison souhaitée ? »
Il faut également déterminer :
- quel serait le calendrier réaliste sans contrainte particulière ;
- pourquoi la date demandée est impérative ;
- quelle partie du périmètre doit réellement être disponible à cette date ;
- quelles fonctionnalités peuvent être différées ;
- quelles ressources peuvent effectivement être mobilisées ;
- quelles dépendances externes limitent l’accélération ;
- quels jalons sont réellement incompressibles.
L’erreur classique consiste à considérer la date comme une donnée indépendante du coût.
Elle ne l’est pas.
Lorsque le planning imposé est sensiblement inférieur au planning nominal, l’hypothèse doit apparaître explicitement dans le chiffrage.
Cela permet également de présenter plusieurs scénarios au décideur :
Scénario A : périmètre complet et calendrier nominal.
Scénario B : périmètre complet avec calendrier accéléré et surcoût associé.
Scénario C : calendrier imposé mais périmètre réduit ou livré progressivement.
La discussion quitte alors le terrain du « il faut absolument tenir la date » pour devenir un véritable arbitrage coût-périmètre-délai-risque.
Comment agir sur cette contrainte ?
Le premier levier n’est pas nécessairement d’ajouter des personnes.
Une DSI peut agir sur plusieurs dimensions.
Réduire le périmètre de la première livraison
Identifier un socle fonctionnel permettant de respecter l’échéance puis reporter les fonctions moins prioritaires.
Sécuriser très tôt l’architecture et les risques
Plus le calendrier est tendu, moins le projet peut absorber tardivement une mauvaise décision structurante.
Réduire les dépendances
Les dépendances avec d’autres projets, fournisseurs ou équipes constituent souvent des points difficilement compressibles.
Préparer les moyens avant le démarrage
Une accélération décidée plusieurs mois après le lancement est généralement beaucoup plus difficile à absorber qu’une contrainte connue dès l’origine.
Comparer plusieurs scénarios
Le bon niveau de compression dépend de la valeur économique de la date. Dépenser 300 jours-homme supplémentaires peut être pertinent pour respecter une échéance réglementaire majeure et injustifié pour une date essentiellement indicative.
Quel impact des IA génératives ?
Les IA génératives peuvent réduire le temps nécessaire à certaines activités : rédaction ou analyse d’exigences, production de documentation, génération de code, préparation de tests, analyse d’anomalies ou assistance au développement.
Elles peuvent donc contribuer à réduire l’effort de certaines tâches et, dans certains contextes, faciliter un calendrier plus court.
Mais elles ne font pas disparaître SCED.
Un projet reste soumis à des contraintes d’architecture, d’intégration, de validation, de coordination, de décision et de dépendances organisationnelles.
Il faut donc distinguer deux effets.
L’IA peut modifier le calendrier nominal du projet en améliorant l’efficacité de certaines activités.
Mais une fois ce nouveau calendrier réaliste déterminé, vouloir encore le réduire fortement reste une contrainte susceptible de générer des surcoûts et des risques supplémentaires.
L’IA ne supprime donc pas le problème. Elle déplace potentiellement le point de référence à partir duquel la compression du calendrier doit être évaluée.
Les erreurs fréquentes
« Deux fois plus de personnes permettront d’aller deux fois plus vite »
Certaines activités peuvent être parallélisées. D’autres non. Et chaque personne supplémentaire crée également des besoins de communication et de coordination.
« La direction a fixé la date, elle n’a donc pas à intervenir dans l’estimation »
C’est précisément l’inverse : une date imposée est une hypothèse majeure du chiffrage.
« Allonger le projet permettra forcément de réduire son coût »
COCOMO II ne retient pas cette hypothèse pour SCED : au-delà du calendrier nominal, les économies liées à une équipe potentiellement plus petite sont compensées par la durée plus longue des fonctions de gestion et d’administration du projet.
« Les outils d’IA permettront de compenser n’importe quelle réduction du planning »
Les gains apportés par l’IA doivent être intégrés à l’estimation du calendrier nominal. Ils ne rendent pas toutes les activités arbitrairement compressibles.
À retenir
SCED — Contraintes sur le calendrier
- Une date imposée est une hypothèse de chiffrage, pas seulement une contrainte de planning.
- Ramener le calendrier à 85 % du nominal porte le coefficient d’effort COCOMO II à 1,14.
- À 75 % du calendrier nominal, le coefficient atteint 1,43.
- Pour un projet nominal de 1 000 jours-homme, cela représente potentiellement 430 jours-homme supplémentaires.
- La bonne décision consiste à arbitrer simultanément date, périmètre, moyens et risques.
Quelles décisions pour un DSI ?
Une date de livraison peut être non négociable. Une réglementation entre en vigueur à une date précise. Un contrat arrive à échéance. Un ancien système doit être arrêté. Un lancement commercial possède une fenêtre de marché.
L’objectif n’est donc pas de considérer toute accélération comme une mauvaise décision.
Il s’agit de rendre son coût visible.
Face à une échéance ambitieuse, le DSI peut demander une estimation du calendrier nominal, mesurer l’écart avec la date demandée, chiffrer le coût de cette compression puis comparer plusieurs scénarios de périmètre et de ressources.
La question pertinente devient alors :
« Quelle valeur sommes-nous prêts à payer pour disposer du logiciel plus tôt ? »
« Une date imposée n’est jamais gratuite : elle doit faire partie du chiffrage. »
Le conseil Estimancy
Ne demandez pas à une équipe de chiffrage de partir directement de la date souhaitée.
Estimez d’abord le calendrier réaliste du projet, puis mesurez explicitement le coût de l’accélération demandée.
Cette séparation entre délai nominal et délai imposé permet de transformer une contrainte de planning en décision économique explicite et de présenter au management plusieurs scénarios comparables.
Les valeurs utilisées dans l’article correspondent exactement à la calibration COCOMO II.2000 : SCED = 1,43 / 1,14 / 1,00 / 1,00 / 1,00 pour respectivement 75 / 85 / 100 / 130 / 160 % du calendrier nominal. Le manuel précise également que SCED s’applique au projet dans son ensemble, contrairement aux autres multiplicateurs pouvant être différenciés par module.
