Une équipe expérimentée prend en charge un nouveau projet. Les développeurs sont compétents, les analystes connaissent leur métier et l’organisation a déjà mené de nombreux projets comparables.
Le chiffrage semble donc relativement sûr.
Mais il manque une question : l’équipe connaît-elle réellement la plateforme technique sur laquelle elle va devoir travailler ?
Une migration vers le cloud, le déploiement d’un nouvel ERP, l’adoption d’une architecture distribuée ou l’arrivée d’un nouvel environnement d’exploitation peuvent placer une équipe pourtant expérimentée dans une situation d’apprentissage.
Cette expérience spécifique est prise en compte dans COCOMO II par le facteur PLEX – Platform Experience.
Pour une DSI, ce facteur mérite une attention particulière : l’expérience générale d’une équipe ne garantit pas sa maîtrise de l’environnement technique du projet.
Qu’est-ce que l’expérience de la plateforme ?
PLEX mesure le niveau d’expérience de l’équipe avec la plateforme utilisée par le projet.
COCOMO II souligne notamment l’importance de la maîtrise des plateformes exploitant des capacités avancées telles que les interfaces graphiques, les bases de données, les réseaux ou les middlewares distribués.
Il faut surtout distinguer PLEX de deux autres notions :
- l’expérience du domaine applicatif ;
- l’expérience des langages et outils.
Une équipe peut ainsi très bien connaître le métier bancaire et maîtriser Java, tout en ayant peu d’expérience de la plateforme technique et de son architecture.
Ce facteur est issu du modèle international COCOMO II, utilisé depuis de nombreuses années pour l’estimation des projets logiciels.
Les différents niveaux
COCOMO II classe l’expérience de la plateforme selon cinq niveaux.
| Niveau | Expérience équivalente |
| Très faible | ≤ 2 mois |
| Faible | 6 mois |
| Nominal | 1 an |
| Élevé | 3 ans |
| Très élevé | 6 ans |
| Extra élevé | Non applicable |
La mesure repose donc sur une notion simple : depuis combien de temps l’équipe possède-t-elle une expérience équivalente de cette plateforme ?
Cette formulation est importante. Il ne suffit pas qu’une technologie existe dans l’entreprise depuis cinq ans pour considérer l’équipe comme expérimentée.
Les coefficients PLEX
Les coefficients d’effort associés sont les suivants :
| Niveau | Coefficient PLEX |
| Très faible | 1,19 |
| Faible | 1,09 |
| Nominal | 1,00 |
| Élevé | 0,91 |
| Très élevé | 0,85 |
Le niveau nominal constitue la référence.
Une expérience très faible augmente ainsi l’effort calculé de 19 % par rapport à cette référence, tandis qu’une expérience très élevée conduit à un coefficient de 0,85.
Il ne faut pas interpréter ces valeurs comme une règle universelle applicable directement à n’importe quel projet. Elles correspondent aux coefficients du modèle COCOMO II calibré et doivent être utilisées dans le cadre global du modèle.
Exemple : un projet de 1 000 jours-homme
Prenons un projet dont l’effort serait de 1 000 jours-homme au niveau nominal, toutes les autres caractéristiques restant identiques.
| Expérience | Coefficient | Effort obtenu | Écart / nominal |
| ≤ 2 mois | 1,19 | 1 190 j.h. | +190 |
| 6 mois | 1,09 | 1 090 j.h. | +90 |
| 1 an | 1,00 | 1 000 j.h. | Référence |
| 3 ans | 0,91 | 910 j.h. | -90 |
| 6 ans | 0,85 | 850 j.h. | -150 |
Entre les deux situations extrêmes, l’écart atteint donc :
1 190 – 850 = 340 jours-homme.
Autrement dit, le projet réalisé par une équipe quasiment novice sur la plateforme représente, selon ces coefficients, 40 % d’effort de plus que le même projet confié à une équipe au niveau « très élevé ».
Ce chiffre montre pourquoi l’expérience de la plateforme ne devrait pas être considérée comme une information secondaire lors du chiffrage.
Cas concret : migration d’un portail client vers une nouvelle plateforme cloud
Imaginons une DSI qui décide de moderniser un portail client historique.
L’équipe connaît parfaitement les fonctions du portail, les processus métier et les technologies de développement utilisées. Elle possède également plusieurs années d’expérience sur l’application existante.
Mais la nouvelle solution doit être déployée sur une plateforme cloud que l’équipe maîtrise peu.
Le risque serait de conclure :
« L’équipe connaît déjà l’application, donc son expérience est élevée. »
Ce raisonnement confond plusieurs dimensions.
L’équipe possède effectivement une forte expérience applicative. Elle peut aussi disposer d’une excellente maîtrise des langages utilisés.
Mais elle doit encore acquérir les réflexes propres à la nouvelle plateforme : architecture, services, sécurité, déploiement, supervision, performances, intégrations ou exploitation.
Le chiffrage doit refléter cette situation.
Pourquoi l’expérience de la plateforme a-t-elle un tel impact ?
Une équipe qui découvre une plateforme consacre une partie de son effort à des activités qui ne sont pas directement visibles dans le périmètre fonctionnel.
Elle doit comprendre l’environnement, expérimenter certaines solutions, résoudre des problèmes nouveaux et parfois revenir sur des décisions techniques prises trop tôt.
Plusieurs phénomènes peuvent apparaître :
Temps d’apprentissage.
Les équipes doivent rechercher, tester et comprendre les mécanismes spécifiques de la plateforme.
Décisions techniques moins sûres.
Une architecture techniquement possible n’est pas nécessairement la plus adaptée à l’environnement retenu.
Erreurs et reprises.
Certaines contraintes ne sont découvertes qu’au moment de l’intégration, des performances ou du déploiement.
Dépendance à quelques experts.
L’équipe sollicite davantage les architectes, experts internes ou fournisseurs de la plateforme.
Estimations trop optimistes.
Les références historiques peuvent provenir de projets réalisés sur une plateforme parfaitement maîtrisée et ne plus être directement comparables.
Quels symptômes observer ?
Plusieurs signes doivent attirer l’attention d’un chef de projet, d’un PMO ou d’un responsable des études :
- nombreuses questions techniques restant ouvertes ;
- multiplication des prototypes ou preuves de concept ;
- dépendance forte à un expert externe ;
- temps important consacré à la documentation technique ;
- difficultés récurrentes d’intégration ou de déploiement ;
- choix d’architecture régulièrement remis en cause ;
- incidents techniques inattendus pendant les tests ;
- estimations reposant sur des projets réalisés dans un autre environnement.
Pris séparément, ces symptômes ne prouvent pas une expérience insuffisante. Leur accumulation doit néanmoins conduire à vérifier explicitement le niveau PLEX.
Conséquences sur le chiffrage
L’une des erreurs classiques consiste à demander :
« L’équipe est-elle expérimentée ? »
La question est trop générale.
Pour apprécier PLEX, il est préférable de demander :
- Quelle plateforme sera réellement utilisée ?
- Depuis combien de temps l’équipe travaille-t-elle sur cette plateforme ?
- Quelle proportion de l’équipe possède cette expérience ?
- Les personnes expérimentées seront-elles effectivement affectées au projet ?
- Existe-t-il des références récentes réalisées dans un environnement comparable ?
- La plateforme comporte-t-elle de nouveaux composants que l’équipe n’a encore jamais utilisés ?
Ces informations doivent être recueillies avant de figer le chiffrage.
Lorsque le niveau d’expérience reste incertain, il peut être pertinent d’établir plusieurs scénarios plutôt que de retenir arbitrairement une hypothèse nominale.
Comment améliorer ce facteur ?
Le premier levier n’est pas nécessairement de former toute l’équipe pendant plusieurs années.
Une DSI peut agir beaucoup plus rapidement.
Introduire quelques profils expérimentés.
Des experts de la plateforme peuvent sécuriser les décisions structurantes et accompagner les autres membres de l’équipe.
Anticiper la montée en compétence.
Formation, prototypes et expérimentations peuvent être réalisés avant le démarrage des développements principaux.
Capitaliser sur les premiers projets.
Standards d’architecture, composants réutilisables, retours d’expérience et pratiques de déploiement évitent aux projets suivants de redécouvrir les mêmes difficultés.
Conserver les compétences clés.
La maîtrise accumulée sur une plateforme constitue un actif pour les projets suivants.
Adapter le sourcing.
Lorsqu’une plateforme est nouvelle pour l’entreprise, la connaissance spécifique de celle-ci peut devenir un critère de sélection des prestataires.
Quel impact des IA génératives ?
Les IA génératives modifient partiellement la question, mais ne font pas disparaître PLEX.
Elles peuvent accélérer l’accès à la documentation, expliquer une API, proposer des configurations, suggérer des architectures ou aider à diagnostiquer certaines erreurs.
Elles peuvent donc réduire une partie du coût de l’apprentissage.
Mais connaître une plateforme ne consiste pas uniquement à trouver rapidement une information.
L’expérience permet aussi de savoir quelles solutions fonctionnent réellement dans un contexte donné, quelles contraintes apparaîtront en production, quels choix sont risqués et quels compromis sont acceptables.
Par ailleurs, une réponse générée par une IA doit elle-même être validée. Sur une plateforme complexe ou critique, cette validation suppose précisément de disposer de compétences suffisantes.
Les IA génératives devraient donc réduire certains effets du manque d’expérience, mais elles ne permettent pas encore de considérer l’expérience de la plateforme comme sans importance.
Les erreurs d’appréciation les plus fréquentes
Confondre ancienneté et expérience pertinente.
Dix années de développement logiciel ne signifient pas dix années d’expérience de la plateforme du projet.
Confondre langage et plateforme.
Maîtriser un langage utilisé sur plusieurs environnements ne garantit pas la maîtrise de chacun de ces environnements.
Évaluer uniquement les experts.
La présence d’un architecte très expérimenté ne signifie pas nécessairement que toute l’équipe possède le même niveau.
Utiliser automatiquement le niveau nominal.
Lorsqu’aucune information n’est disponible, retenir 1,00 par défaut masque l’incertitude plutôt qu’il ne la résout.
Réutiliser sans précaution les performances historiques.
Un projet réalisé par une équipe maîtrisant parfaitement une plateforme ne constitue pas forcément une référence valable pour une équipe qui la découvre.
À retenir
PLEX – Expérience de la plateforme
- L’expérience générale des développeurs ne suffit pas : il faut mesurer leur expérience de la plateforme réellement utilisée.
- COCOMO II fait varier le coefficient PLEX de 1,19 à 0,85.
- Sur une référence de 1 000 jours-homme, cela représente un écart potentiel de 340 jours-homme entre les deux niveaux extrêmes.
- Une nouvelle plateforme doit conduire à réexaminer les références historiques utilisées pour chiffrer.
- Formation, expertise ciblée, capitalisation et transfert de compétences permettent de réduire progressivement ce risque.
Quelles décisions pour un DSI ?
L’expérience de la plateforme est un facteur sur lequel une DSI peut agir.
Avant de valider un budget, elle peut vérifier que le niveau d’expérience retenu dans le chiffrage correspond réellement à l’équipe prévue. Elle peut également décider d’intégrer des experts, d’organiser une montée en compétence préalable ou de sécuriser certains choix techniques par des prototypes.
Lors d’un changement important de plateforme, elle peut surtout éviter une erreur fréquente : supposer que les performances obtenues historiquement resteront automatiquement valables dans le nouvel environnement.
La question n’est donc pas seulement : « Avons-nous une équipe compétente ? »
Elle devient :
« Avons-nous une équipe suffisamment expérimentée sur la plateforme que nous lui demandons de maîtriser ? »
« L’expérience d’une équipe n’a de valeur pour le chiffrage que si elle correspond à l’environnement du projet. »
Le conseil Estimancy
Lors d’un chiffrage, séparez systématiquement trois expériences : celle du domaine applicatif, celle de la plateforme et celle des langages et outils.
COCOMO II les distingue précisément en trois facteurs — APEX, PLEX et LTEX — avec des coefficients propres. Le document de référence définit notamment APEX à partir de l’expérience sur ce type d’application, puis PLEX à partir de l’expérience de la plateforme.
Cette distinction évite de considérer une équipe comme « très expérimentée » sur la seule base de son ancienneté générale.
