Quand gagner du temps au démarrage en fait perdre ensuite
Un projet est validé. Le budget est disponible. Les équipes sont mobilisées. La pression est forte pour commencer rapidement le développement.
Pourtant, plusieurs questions restent ouvertes : l’architecture cible est-elle suffisamment définie ? Les performances attendues sont-elles réalistes ? Les interfaces avec les systèmes existants sont-elles maîtrisées ? Les composants externes ont-ils été validés ? Les principaux risques techniques ont-ils été identifiés ?
Dans cette situation, lancer immédiatement le développement donne l’impression de gagner du temps.
Mais une partie de ce gain peut être reperdue ensuite sous forme de reprises, de modifications d’interfaces, de changements d’architecture, de difficultés d’intégration ou de retards.
COCOMO II prend explicitement en compte cette situation avec le facteur Résolution de l’architecture et des risques.
Ce facteur est issu du modèle international COCOMO II, utilisé depuis de nombreuses années pour l’estimation des projets logiciels.
Son intérêt pour une DSI est important : il permet de traduire une question souvent considérée comme essentiellement technique — « l’architecture est-elle suffisamment mature ? » — en une question économique : « quel effort supplémentaire risque-t-on de supporter si le projet démarre avec trop d’incertitudes ? »
Ce que mesure la résolution de l’architecture et des risques
Le facteur évalue dans quelle mesure le projet a suffisamment travaillé son architecture et traité ses risques avant d’engager massivement le développement.
COCOMO II prend notamment en compte :
- l’existence d’un plan de gestion des risques ;
- l’identification et le traitement des risques critiques ;
- la cohérence entre les risques identifiés, le planning et le budget ;
- le temps consacré à l’établissement de l’architecture ;
- la disponibilité des architectes nécessaires ;
- les outils utilisés pour analyser les risques et valider l’architecture ;
- l’incertitude concernant les principaux choix structurants ;
- le nombre et la criticité des risques encore ouverts.
Il ne s’agit donc pas simplement de vérifier qu’un document d’architecture existe.
La question est de savoir si les décisions structurantes ont été suffisamment étudiées et les risques suffisamment maîtrisés pour éviter qu’ils ne réapparaissent pendant le développement.
Les six niveaux définis par COCOMO II
COCOMO II distingue six niveaux.
| Niveau | Situation générale |
| Très faible | Architecture très peu résolue, risques critiques nombreux |
| Faible | Premiers travaux réalisés mais incertitudes importantes |
| Nominal | Architecture et risques partiellement maîtrisés |
| Élevé | Principaux choix établis et risques largement traités |
| Très élevé | Architecture fortement consolidée, peu d’incertitudes |
| Exceptionnel | Architecture et risques pratiquement totalement résolus |
Le modèle donne des indicateurs particulièrement concrets.
La part du calendrier de développement consacrée à l’établissement de l’architecture passe ainsi de 5 % au niveau Très faible à 40 % au niveau Exceptionnel.
La disponibilité des architectes clés nécessaires au projet passe de 20 % à 120 % selon les niveaux.
Parallèlement, l’incertitude concernant les éléments déterminants de l’architecture — mission, interfaces utilisateurs, progiciels, matériel, technologies, performances — évolue d’« extrême » à « très faible ».
Cette lecture montre un point essentiel : investir dans l’architecture ne constitue pas uniquement une dépense préalable au développement. C’est également un moyen de réduire l’incertitude du projet.
Les coefficients COCOMO II
La Résolution de l’architecture et des risques est un facteur d’échelle.
Ses coefficients sont les suivants :
| Niveau | Coefficient RESL |
| Très faible | 7,07 |
| Faible | 5,65 |
| Nominal | 4,24 |
| Élevé | 2,83 |
| Très élevé | 1,41 |
| Exceptionnel | 0,00 |
Une particularité est essentielle pour interpréter ces chiffres : ils ne sont pas directement appliqués comme des multiplicateurs à l’effort.
Ils contribuent à déterminer l’exposant de taille de COCOMO II.
Cela signifie que l’effet de ce facteur dépend de la taille du projet. Plus le projet est important, plus une architecture insuffisamment résolue et des risques mal maîtrisés peuvent amplifier les déséconomies d’échelle.
Exemple : un projet de référence de 1 000 jours-homme
Prenons un projet dont l’effort est de 1 000 jours-homme au niveau nominal, en conservant tous les autres paramètres identiques.
Pour rendre la simulation reproductible, nous retenons une taille technique de référence de 100 KSLOC.
L’effet du seul facteur Résolution de l’architecture et des risques devient approximativement :
| Niveau | Effort relatif | Écart / nominal |
| Très faible | 1 139 j.h | +13,9 % |
| Faible | 1 067 j.h | +6,7 % |
| Nominal | 1 000 j.h | Référence |
| Élevé | 937 j.h | –6,3 % |
| Très élevé | 878 j.h | –12,2 % |
| Exceptionnel | 823 j.h | –17,7 % |
L’écart théorique entre les deux situations extrêmes atteint donc environ 316 jours-homme sur ce projet de référence.
Ce résultat doit être interprété avec prudence. Il ne signifie pas qu’améliorer l’architecture permet mécaniquement d’économiser 316 jours-homme sur n’importe quel projet de 1 000 jours-homme.
RESL étant un facteur d’échelle, son impact dépend notamment de la taille du logiciel. La simulation sert à montrer l’ordre de grandeur et surtout la dynamique du modèle.
Cas concret : refonte d’un portail client
Prenons la refonte du portail client d’une grande entreprise.
Le projet doit remplacer plusieurs applications existantes et s’interfacer avec le CRM, le système de facturation, la gestion des identités et plusieurs API historiques.
Le planning est tendu.
Pour gagner du temps, le développement des premières fonctionnalités démarre alors que plusieurs sujets restent ouverts :
- architecture d’intégration non définitivement choisie ;
- performances des API historiques mal connues ;
- stratégie d’authentification en discussion ;
- volumes réels d’utilisation incertains ;
- responsabilités entre plusieurs équipes encore mal définies.
Les premières itérations produisent rapidement des écrans fonctionnels.
Le projet semble avancer.
Quelques mois plus tard, les tests de charge montrent que l’architecture d’intégration ne supporte pas les volumes attendus. Plusieurs interfaces doivent être modifiées. Certains développements doivent être repris et les environnements de test adaptés.
Le problème n’est pas que les développeurs aient mal travaillé.
Le développement a simplement commencé avant que certaines incertitudes structurantes aient été suffisamment levées.
Pourquoi l’impact augmente-t-il avec la taille du projet ?
Sur un petit projet, une erreur d’architecture peut parfois être corrigée rapidement.
Sur un grand projet, une même décision peut avoir des conséquences sur plusieurs équipes, composants et interfaces.
Une modification tardive entraîne alors une cascade :
architecture → composants → interfaces → développement → tests → intégration → documentation → déploiement.
COCOMO II traduit notamment ce phénomène par les déséconomies d’échelle.
Lorsque les projets grossissent, les coûts de communication et d’intégration augmentent. Une architecture solide et une résolution précoce des risques permettent de limiter une partie de ces surcoûts.
La question n’est donc pas uniquement : « Avons-nous une architecture ? »
Elle devient : « Avons-nous suffisamment réduit l’incertitude avant de multiplier les développements qui dépendent de cette architecture ? »
Les symptômes à surveiller
Plusieurs signaux doivent attirer l’attention d’une DSI :
- choix technologiques structurants encore en discussion après le démarrage ;
- nombreux risques critiques sans responsable ni plan d’action ;
- interfaces majeures insuffisamment spécifiées ;
- performances attendues non testées ;
- composants ou progiciels choisis sans preuve de faisabilité ;
- architectes clés insuffisamment disponibles ;
- absence de prototypes sur les points les plus incertains ;
- changements fréquents des principes d’architecture ;
- estimation réalisée en supposant implicitement que tous les choix techniques sont stabilisés.
Plus ces symptômes sont présents, plus le chiffrage doit intégrer l’incertitude correspondante.
Quelles conséquences sur le chiffrage ?
Une estimation ne devrait pas uniquement mesurer ce qu’il faut construire.
Elle doit également apprécier dans quelles conditions le projet va être construit.
Pour évaluer ce facteur, le responsable du chiffrage peut notamment poser les questions suivantes :
Quels sont les risques critiques actuellement identifiés ?
Combien restent encore ouverts ?
Les principaux choix d’architecture ont-ils été validés ?
Des prototypes ou preuves de concept ont-ils été réalisés sur les sujets incertains ?
Les architectes nécessaires sont-ils réellement disponibles ?
Les contraintes de performance, de sécurité et d’intégration sont-elles connues ?
Les principaux composants externes ont-ils été validés ?
L’erreur classique consiste à chiffrer le projet comme si toutes ces questions étaient résolues alors qu’elles ne le sont pas.
Le résultat est une estimation artificiellement optimiste.
Lorsque l’information disponible est insuffisante, il est préférable de rendre l’hypothèse explicite : « estimation réalisée sous réserve de validation de l’architecture X » ou « risque Y non résolu à la date du chiffrage ».
La qualité d’un chiffrage dépend autant de la visibilité sur ses hypothèses que de la valeur finale obtenue.
Comment améliorer ce facteur ?
Trois leviers sont particulièrement importants.
1. Identifier les risques avant de développer
La gestion des risques ne doit pas être une liste administrative actualisée une fois par mois.
Les risques susceptibles de remettre en cause l’architecture doivent être identifiés très tôt.
2. Tester ce qui est incertain
Un prototype n’a pas pour objectif de développer plus rapidement une partie du produit.
Il doit prioritairement permettre de répondre à une question.
L’architecture supportera-t-elle les volumes ?
Le progiciel peut-il réellement couvrir ce besoin ?
Cette API peut-elle fournir les performances attendues ?
La technologie envisagée est-elle compatible avec les contraintes de sécurité ?
3. Conditionner certaines décisions d’engagement à la maturité du projet
Une DSI peut introduire des critères explicites avant l’engagement complet du développement :
- architecture cible définie ;
- principaux risques identifiés ;
- risques critiques traités ou couverts par un plan ;
- faisabilité des choix structurants démontrée ;
- hypothèses du chiffrage documentées.
L’objectif n’est pas d’ajouter une validation administrative.
Il est d’éviter de mobiliser une capacité de développement importante sur des hypothèses susceptibles d’être remises en cause quelques semaines plus tard.
Que changent les IA génératives ?
Les IA génératives peuvent contribuer à améliorer la résolution de certains risques.
Elles peuvent aider à analyser des exigences, identifier des incohérences, comparer des scénarios d’architecture, préparer des revues, rechercher des dépendances ou produire rapidement des prototypes exploratoires.
Elles peuvent également accélérer le développement.
Mais cette accélération crée un paradoxe.
Produire du logiciel plus rapidement augmente encore l’intérêt de vérifier que l’on développe dans la bonne direction.
Une IA peut générer rapidement du code reposant sur une hypothèse d’architecture incorrecte. Elle peut accélérer une mauvaise décision aussi facilement qu’une bonne.
L’IA ne supprime donc pas ce facteur.
Elle modifie plutôt la manière de le traiter : certaines analyses et expérimentations deviennent plus rapides, mais la validation des choix structurants et la responsabilité de la décision restent essentielles.
Les erreurs fréquentes
Confondre architecture documentée et architecture validée.
Un dossier d’architecture complet ne garantit pas que les principaux risques aient été levés.
Considérer les prototypes comme du développement anticipé.
Leur objectif principal devrait être de réduire une incertitude.
Attendre le développement pour identifier les problèmes.
Les premiers sprints ne devraient pas systématiquement servir de phase d’exploration architecturale déguisée.
Chiffrer comme si les risques étaient déjà résolus.
Une estimation doit refléter le niveau réel d’information disponible.
Chercher systématiquement à réduire la phase de conception.
Réduire le temps consacré à l’architecture peut diminuer le délai avant le début du développement tout en augmentant l’effort total du projet.
À retenir
- La résolution de l’architecture et des risques est un facteur d’échelle : son impact augmente avec la taille du projet.
- Commencer à développer plus tôt ne garantit pas de terminer plus tôt.
- Les risques techniques non résolus peuvent se transformer en reprises, difficultés d’intégration et surcoûts.
- Le chiffrage doit refléter le niveau réel de maturité de l’architecture.
- Les IA génératives accélèrent l’analyse et le prototypage, mais ne suppriment pas la nécessité de valider les décisions structurantes.
Quelles décisions pour un DSI ?
Pour un DSI, l’enseignement principal n’est pas qu’il faut consacrer systématiquement davantage de temps à l’architecture.
Il faut consacrer le temps nécessaire aux incertitudes qui peuvent remettre en cause le projet.
Cela implique de rendre visibles les risques critiques, de vérifier la disponibilité des compétences d’architecture, d’utiliser prototypes et preuves de concept sur les sujets réellement incertains et d’intégrer le niveau de résolution de ces risques dans les chiffrages.
La décision de lancer un développement ne devrait donc pas reposer uniquement sur la disponibilité du budget et des équipes.
Elle devrait également répondre à une question simple :
Sommes-nous suffisamment certains de la direction prise pour engager le coût du développement ?
Le conseil Estimancy
Avant de valider un chiffrage important, ajoutez une revue explicite de la maturité de l’architecture et des risques.
Ne demandez pas seulement : « L’architecture est-elle définie ? »
Demandez également :
- quels risques critiques restent ouverts ?
- quelles hypothèses structurantes ne sont pas encore validées ?
- quels choix pourraient provoquer des reprises importantes ?
- ces incertitudes sont-elles correctement prises en compte dans le chiffrage ?
Un projet mal défini ne devient pas moins risqué parce que son estimation est précise au jour-homme près.
« Le meilleur moment pour résoudre un risque est avant qu’il ne devienne du développement à refaire. »
Les valeurs utilisées dans l’article correspondent bien à la calibration COCOMO II.2000 : RESL varie de 7,07 à 0, avec 4,24 au niveau nominal. Le manuel définit par ailleurs explicitement les critères de classement : gestion des risques, part du calendrier consacrée à l’architecture, disponibilité des architectes, outils, incertitude architecturale et nombre de risques critiques.
