Une même équipe n’est pas également performante avec toutes les technologies
Une DSI décide de moderniser une application. Le périmètre fonctionnel est connu, l’équipe maîtrise le métier et l’architecture générale du système. Mais le projet introduit un nouveau langage, un nouveau framework ou un nouvel environnement de développement.
Faut-il conserver le même niveau d’effort dans le chiffrage ?
Probablement pas.
Une équipe compétente peut avoir besoin de temps pour maîtriser un nouvel environnement technologique : découvrir ses mécanismes, acquérir les bonnes pratiques, comprendre ses bibliothèques, configurer les outils, corriger des erreurs liées à l’apprentissage ou simplement apprendre à utiliser efficacement l’ensemble de la chaîne de développement.
COCOMO II prend explicitement en compte cette situation à travers le facteur LTEX – Language and Tool Experience.
Que mesure l’expérience du langage et des outils ?
LTEX mesure le niveau d’expérience de l’équipe dans le langage de programmation et les outils logiciels utilisés par le projet.
La notion d’outils est assez large. Le modèle cite notamment les outils utilisés pour représenter et analyser les exigences et la conception, gérer les configurations, produire la documentation, gérer les bibliothèques, contrôler la cohérence ou encore assurer la planification et le contrôle du projet.
Il ne faut donc pas réduire ce facteur à une question du type : « Depuis combien de temps développez-vous en Java ? »
Il s’agit davantage d’évaluer la familiarité de l’équipe avec l’environnement technologique effectivement nécessaire pour produire le logiciel.
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 distingue cinq niveaux utilisables pour LTEX.
| Niveau | Expérience | Coefficient |
| Très faible | ≤ 2 mois | 1,20 |
| Faible | 6 mois | 1,09 |
| Nominale | 1 an | 1,00 |
| Élevée | 3 ans | 0,91 |
| Très élevée | ≥ 6 ans | 0,84 |
La logique est simple : plus l’équipe maîtrise le langage et les outils, moins elle consacre d’effort à l’apprentissage, aux tâtonnements et aux difficultés liées à leur utilisation.
Que signifient réellement ces coefficients ?
LTEX est un multiplicateur d’effort du modèle Post-Architecture de COCOMO II. Il ne détermine donc pas seul l’effort du projet : il vient modifier l’effort calculé à partir des autres caractéristiques du projet.
Prenons volontairement un projet dont l’effort serait de 1 000 jours-homme au niveau nominal.
| Niveau | Coefficient | Effort correspondant | Écart / nominal |
| Très faible | 1,20 | 1 200 j.h. | +200 |
| Faible | 1,09 | 1 090 j.h. | +90 |
| Nominal | 1,00 | 1 000 j.h. | — |
| Élevé | 0,91 | 910 j.h. | -90 |
| Très élevé | 0,84 | 840 j.h. | -160 |
L’écart entre les situations extrêmes atteint donc 360 jours-homme.
Autrement dit, l’effort associé au niveau très faible est environ 43 % supérieur à celui associé au niveau très élevé.
Cela ne signifie pas qu’une équipe débutante coûtera systématiquement 43 % de plus : COCOMO II combine LTEX avec de nombreux autres facteurs. Cela indique l’ordre de grandeur de l’influence que le modèle attribue à ce facteur, toutes choses égales par ailleurs.
Cas concret : la modernisation d’un portail client
Imaginons une entreprise qui décide de reconstruire son portail client avec une nouvelle stack technologique.
Les développeurs connaissent parfaitement le système existant et les règles métier. Ils connaissent également l’environnement d’exploitation de l’entreprise.
Mais ils découvrent le nouveau framework et une partie de la chaîne d’outillage.
Les premières semaines peuvent alors être consacrées à des sujets qui auraient demandé beaucoup moins de temps à une équipe expérimentée : choix de patterns inadaptés puis corrigés, difficultés de configuration, mauvaise utilisation de certaines bibliothèques, temps de recherche, problèmes d’intégration ou reprises de composants développés pendant la phase d’apprentissage.
Le problème n’est donc pas la compétence générale de l’équipe.
C’est l’adéquation entre son expérience et les technologies réellement utilisées sur le projet.
Pourquoi l’impact peut-il être important ?
L’apprentissage agit à plusieurs niveaux.
Un développeur expérimenté dans une technologie sait généralement plus rapidement comment structurer une solution, quelles fonctionnalités standards utiliser et quelles approches éviter.
Il maîtrise également mieux les outils associés.
À l’inverse, une équipe en apprentissage peut multiplier les expérimentations, les recherches et les corrections. Certaines difficultés apparaissent tardivement : une solution techniquement fonctionnelle peut, par exemple, s’avérer peu maintenable ou mal adaptée aux pratiques de déploiement.
L’expérience réduit ainsi non seulement le temps nécessaire pour réaliser certaines tâches, mais également une partie des erreurs, reprises et incertitudes techniques.
Quels symptômes doivent alerter ?
Plusieurs signaux peuvent révéler un niveau LTEX défavorable :
- technologie récemment introduite dans l’entreprise ;
- majorité de l’équipe formée juste avant le démarrage ;
- dépendance à un ou deux experts ;
- nombreux prototypes destinés à découvrir le framework ;
- estimations techniques fréquemment révisées ;
- temps important consacré à rechercher des solutions ;
- difficultés récurrentes avec les environnements de développement, de test ou de déploiement ;
- forte proportion de reprises techniques en début de projet.
Ces symptômes ne prouvent pas nécessairement un manque de compétence. Ils indiquent surtout qu’une courbe d’apprentissage doit probablement être prise en compte.
Quelles conséquences sur le chiffrage ?
Lors du chiffrage, demander simplement « l’équipe est-elle expérimentée ? » est insuffisant.
Il faut préciser l’objet de cette expérience.
Quelques questions sont particulièrement utiles :
Depuis combien de temps l’équipe utilise-t-elle le langage principal du projet ?
Depuis combien de temps travaille-t-elle avec le framework et les principaux outils associés ?
Quelle proportion de l’équipe possède réellement cette expérience ?
La technologie est-elle déjà utilisée en production dans l’entreprise ?
Les personnes expérimentées seront-elles réellement disponibles pendant le projet ?
Cette analyse évite une erreur classique : considérer l’expérience globale des développeurs comme équivalente à leur expérience dans l’environnement technologique du projet.
COCOMO II distingue d’ailleurs explicitement l’expérience du domaine applicatif (APEX), de la plateforme (PLEX) et du langage et des outils (LTEX).
Comment améliorer ce facteur ?
Une DSI dispose de plusieurs leviers.
Le premier consiste à introduire quelques profils expérimentés dans une équipe qui découvre une technologie. Il n’est pas nécessaire que chaque développeur possède six années d’expérience pour réduire fortement la courbe d’apprentissage collective.
Le deuxième est la formation, idéalement avant le démarrage des développements critiques.
Le troisième est le compagnonnage : revues techniques, programmation en binôme, standards partagés, exemples de référence et accompagnement par des personnes ayant déjà pratiqué la technologie.
Enfin, lorsqu’une technologie est nouvelle pour toute l’organisation, un prototype ou une phase préparatoire peut permettre de transformer une partie de l’incertitude en expérience avant de s’engager sur le budget et le calendrier du projet principal.
Quel impact des IA génératives ?
Les IA génératives modifient sensiblement le sujet, mais ne font probablement pas disparaître LTEX.
Elles peuvent accélérer la découverte d’un langage ou d’un framework, proposer des exemples, expliquer une API, générer certaines portions de code ou aider à diagnostiquer des erreurs.
Elles peuvent donc réduire certains coûts de la courbe d’apprentissage.
Mais produire rapidement du code n’est pas équivalent à maîtriser une technologie.
Une équipe peu expérimentée peut avoir davantage de difficultés à évaluer la qualité d’une proposition générée, à détecter une mauvaise pratique, à choisir entre plusieurs architectures ou à identifier les conséquences d’une solution sur la sécurité, les performances et la maintenabilité.
L’IA pourrait donc réduire l’importance de certaines connaissances syntaxiques tout en renforçant la valeur de l’expérience nécessaire pour évaluer et contrôler ce qui est produit.
Les coefficients historiques de COCOMO II ne doivent évidemment pas être interprétés comme une mesure spécifique de l’effet des IA génératives. Ils constituent avant tout un cadre pour identifier et expliciter l’hypothèse d’expérience technologique retenue dans un chiffrage.
Les erreurs fréquentes
La première consiste à confondre ancienneté professionnelle et expérience technologique. Quinze années de développement ne signifient pas quinze années d’expérience sur la technologie du projet.
La deuxième est d’évaluer l’expérience à partir des meilleurs experts alors que ceux-ci ne représentent qu’une faible partie de l’équipe.
La troisième est d’oublier les outils et de ne considérer que le langage.
La quatrième consiste à supposer que la formation supprime immédiatement la courbe d’apprentissage.
Enfin, une erreur fréquente consiste à introduire une nouvelle technologie sans modifier le chiffrage initial, comme si le changement était transparent pour l’équipe.
À retenir
5 idées essentielles
- LTEX mesure l’expérience de l’équipe dans le langage et les outils utilisés par le projet.
- COCOMO II utilise des coefficients allant de 1,20 à 0,84.
- Sur une référence de 1 000 jours-homme, cela correspond à un écart théorique pouvant atteindre 360 jours-homme entre les niveaux extrêmes.
- L’expérience technologique doit être distinguée de l’expérience métier et de l’expérience de la plateforme.
- Les IA génératives peuvent raccourcir certaines phases d’apprentissage, mais elles ne suppriment pas le besoin d’expérience pour contrôler les choix et les résultats.
Quelles décisions un DSI peut-il prendre à la lumière de ce paramètre ?
LTEX ne conduit évidemment pas à recommander aux DSI de privilégier systématiquement les technologies déjà maîtrisées.
Introduire une nouvelle technologie peut être nécessaire pour moderniser le SI, améliorer sa maintenabilité ou préparer son évolution.
En revanche, le coût de son apprentissage doit être visible.
Avant de valider un budget ou un engagement de délai, un DSI peut donc demander que le niveau d’expérience réel de l’équipe soit explicité, identifier les technologies nouvelles, sécuriser quelques compétences clés et vérifier que la courbe d’apprentissage a bien été intégrée dans l’estimation.
Cette approche permet également de comparer plus justement plusieurs scénarios technologiques : le meilleur choix à long terme n’est pas nécessairement celui qui minimise l’effort du premier projet.
« Une nouvelle technologie peut être un investissement. Sa courbe d’apprentissage reste un coût. »
Le conseil Estimancy
Ne demandez pas seulement si l’équipe est expérimentée. Demandez : expérimentée dans quoi ?
Dans un chiffrage, distinguez systématiquement l’expérience du domaine, de la plateforme et du langage et des outils. Une hypothèse explicite sur ces trois dimensions est beaucoup plus fiable qu’une appréciation générale du niveau de l’équipe.
