Capacité des analystes : un facteur sous-estimé du coût des projets logiciels

Un même projet, mais pas nécessairement le même effort

Lorsqu’une DSI cherche à comprendre pourquoi deux projets apparemment comparables connaissent des trajectoires très différentes, les explications avancées sont souvent techniques : complexité de l’architecture, technologie, volumétrie, exigences de disponibilité ou difficultés d’intégration.

Un autre facteur est parfois moins visible : la capacité des personnes chargées de comprendre le besoin, de l’analyser et de le traduire en exigences et en conception.

Une ambiguïté non détectée, une règle métier mal comprise ou une interface insuffisamment analysée peut ne produire ses effets que plusieurs semaines ou plusieurs mois plus tard. Il faut alors reprendre une conception, modifier un développement ou corriger des tests.

COCOMO II considère ainsi les facteurs humains comme particulièrement importants après la taille du produit.

Qu’entend-on par « capacité des analystes » ?

Dans COCOMO II, les analystes sont les personnes qui interviennent sur les exigences ainsi que sur la conception de haut et de bas niveau.

La capacité des analystes — ACAP, pour Analyst Capability — est appréciée selon quatre dimensions principales :

• capacité d’analyse et de conception ;
• efficacité ;
• rigueur et exhaustivité ;
• capacité à communiquer et à coopérer.

Le modèle demande d’évaluer l’équipe et non une personne isolée. Cette distinction est importante pour une DSI : une équipe ne devient pas excellente simplement parce qu’elle comprend quelques experts particulièrement performants.

Autre distinction essentielle : COCOMO II demande de ne pas intégrer l’expérience dans cette évaluation. L’expérience du domaine applicatif, de la plateforme, du langage ou des outils est prise en compte par d’autres paramètres.

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 définit cinq niveaux utilisables pour ce facteur, positionnés selon des percentiles.

Ces percentiles ne doivent pas être transformés artificiellement en une grille RH. Ils constituent avant tout les points de référence utilisés pour la calibration du modèle.

Les coefficients COCOMO II

Les coefficients associés montrent l’importance du facteur.

Un cost driver COCOMO II agit de manière multiplicative sur l’effort estimé.

L’écart entre les deux extrêmes est spectaculaire :

1,42 / 0,71 = 2.

Toutes choses égales par ailleurs, le modèle estime donc un effort deux fois plus important entre les niveaux « Très faible » et « Très élevé ».

Exemple : un projet de référence de 1 000 jours-homme

Prenons un projet dont l’effort serait de 1 000 jours-homme avec une capacité nominale des analystes, tous les autres paramètres restant constants.

Il faut interpréter correctement ces chiffres. Ils ne signifient pas que 710 jours-homme suffiront nécessairement dès que l’on constitue une équipe d’excellents analystes.

Ils illustrent l’effet du facteur ACAP dans le modèle COCOMO II, les autres caractéristiques du projet étant maintenues constantes.

Cas concret : refonte d’un portail client

Imaginons la refonte du portail client d’un assureur.

Le projet doit gérer plusieurs parcours : consultation des contrats, déclaration de sinistres, dépôt de justificatifs, modification des coordonnées et suivi des demandes.

Une équipe d’analyse peu performante décrit correctement les écrans mais identifie mal certaines règles transverses. Les conditions d’éligibilité sont incomplètes, plusieurs cas d’exception ne sont pas documentés et les interactions avec le système de gestion des contrats sont découvertes tardivement.

Les développeurs avancent néanmoins.

Pendant les tests, les écarts apparaissent. Il faut préciser les exigences, modifier certaines interfaces, reprendre des développements et rejouer des tests.

Une équipe d’analyse plus performante aurait probablement identifié davantage de ces questions avant le développement : règles métier, cas limites, données nécessaires, dépendances et critères d’acceptation.

La différence ne réside donc pas seulement dans la vitesse à laquelle l’analyste produit ses spécifications. Elle réside surtout dans les conséquences de son travail sur l’ensemble de la chaîne de développement.

Pourquoi un tel impact ?

Une analyse insuffisante génère des effets en cascade.

Une exigence ambiguë entraîne plusieurs interprétations. Une règle oubliée apparaît lors des tests. Une dépendance non identifiée impose une modification d’architecture. Une incohérence découverte tardivement provoque des reprises.

À l’inverse, une bonne équipe d’analyse contribue à clarifier plus tôt les décisions et à réduire les boucles inutiles.

C’est pourquoi le coefficient ACAP porte sur l’effort global estimé et non uniquement sur le nombre de jours consacrés à l’analyse.

Quels symptômes observer ?

Plusieurs signaux doivent attirer l’attention :

• nombreuses questions des développeurs après validation des spécifications ;
• exigences fréquemment réinterprétées ;
• incohérences entre documents ;
• cas d’exception découverts pendant les tests ;
• critères d’acceptation imprécis ;
• nombreuses reprises fonctionnelles ;
• décisions métier insuffisamment tracées ;
• difficultés récurrentes entre métiers, analystes et équipes techniques.

Aucun de ces symptômes ne suffit isolément à conclure que la capacité des analystes est faible. Leur accumulation constitue néanmoins un signal utile.

Quelles conséquences sur le chiffrage ?

Une estimation ne devrait pas considérer automatiquement la capacité de l’équipe comme « nominale ».

Avant de fixer l’hypothèse, plusieurs questions peuvent être posées :

Qui réalisera l’analyse ?
L’équipe est-elle déjà constituée ou seulement envisagée ?

Quelle est la qualité habituelle des productions ?
Les exigences nécessitent-elles régulièrement des reprises importantes ?

Comment se déroule la collaboration ?
Les analystes communiquent-ils efficacement avec les métiers, architectes, développeurs et testeurs ?

Quelle est leur capacité à traiter des sujets complexes ?
Identifient-ils les exceptions, dépendances et incohérences ?

Il faut également éviter une confusion fréquente : ancienneté et capacité ne sont pas synonymes. COCOMO II sépare explicitement ces dimensions.

Lorsque l’équipe n’est pas encore connue, retenir une hypothèse très favorable sans justification crée un risque de sous-estimation.

Comment améliorer ce facteur ?

Une DSI dispose de plusieurs leviers.

Le premier consiste à professionnaliser les pratiques d’analyse : modèles communs, critères de qualité, check-lists, revues croisées et méthodes structurées de formalisation des exigences.

Le deuxième consiste à organiser des revues suffisamment tôt. Une exigence ambiguë coûte généralement beaucoup moins cher à clarifier avant le développement qu’après son implémentation.

Le troisième est de développer les compétences de communication. COCOMO II inclut explicitement la capacité à communiquer et à coopérer parmi les caractéristiques de la capacité des analystes.

Enfin, il est utile de mesurer les résultats : nombre de demandes de clarification, défauts liés aux exigences, reprises fonctionnelles ou stabilité des spécifications peuvent aider à objectiver progressivement la situation.

Quel impact des IA génératives ?

Les IA génératives modifient le travail de l’analyste, mais elles ne font probablement pas disparaître l’importance de sa capacité.

Elles peuvent l’aider à :

• détecter des ambiguïtés ;
• identifier des exigences manquantes ;
• rechercher des incohérences ;
• reformuler une exigence ;
• proposer des critères d’acceptation ;
• explorer des scénarios alternatifs ;
• vérifier plus systématiquement un corpus documentaire.

Elles peuvent donc amplifier la capacité d’une équipe bien organisée.

Mais produire davantage de texte ou davantage de propositions ne garantit pas une meilleure analyse. Il faut toujours déterminer si une exigence correspond réellement au besoin, arbitrer les contradictions et valider les règles métier.

L’IA ne supprime donc pas nécessairement le facteur ACAP. Elle pourrait plutôt modifier ce que signifie être un analyste performant : moins de temps consacré à certaines tâches de production, davantage de capacité nécessaire pour questionner, contrôler, arbitrer et valider.

Les erreurs fréquentes

Confondre capacité et expérience.
Un analyste peut connaître parfaitement un secteur tout en rencontrant des difficultés à structurer et formaliser un problème complexe.

Évaluer les individus plutôt que l’équipe.
COCOMO II demande une appréciation collective.

Retenir systématiquement le niveau nominal.
C’est pratique pour le chiffrage, mais cela masque un risque réel lorsque l’équipe est connue.

Considérer uniquement la vitesse de production.
Produire une spécification rapidement n’est pas nécessairement synonyme d’efficacité si elle provoque ensuite de nombreuses reprises.

Penser que l’IA compensera automatiquement une faible capacité d’analyse.
Un outil puissant utilisé sans méthode peut aussi accélérer la production d’exigences incorrectes ou inutiles.

À retenir

5 idées essentielles

1. La capacité des analystes concerne l’analyse, la conception, la rigueur, l’efficacité, la communication et la coopération.
2. COCOMO II la distingue explicitement de l’expérience.
3. Les coefficients vont de 1,42 à 0,71, soit un rapport de 2 entre les deux extrêmes.
4. Son impact ne concerne pas uniquement la phase d’analyse : une mauvaise analyse peut générer des reprises tout au long du projet.
5. Les IA génératives peuvent renforcer le travail des analystes, mais ne remplacent ni le jugement ni la validation.

Quelles décisions un DSI peut-il prendre à la lumière de ce paramètre ?

La première décision est de ne plus considérer la capacité des analystes comme une donnée implicite du projet.

Pour les projets importants, elle peut devenir une hypothèse explicite du chiffrage.

La deuxième consiste à identifier les projets sur lesquels une analyse particulièrement exigeante justifie de mobiliser les équipes les plus performantes.

La troisième est d’investir dans les méthodes, les revues et les outils permettant d’améliorer collectivement la qualité de l’analyse.

Enfin, l’arrivée des IA génératives constitue une occasion de réexaminer le rôle de l’analyste : automatiser ce qui peut l’être tout en renforçant les activités qui exigent compréhension, discernement et validation.

« Une exigence bien analysée coûte peu. Une exigence mal comprise peut coûter tout au long du projet. »

Le conseil Estimancy

Avant de valider un chiffrage important, rendez explicite l’hypothèse concernant la capacité de l’équipe d’analyse.

Si l’équipe n’est pas connue, conservez une hypothèse prudente. Si elle est connue, appuyez-vous autant que possible sur des observations objectives issues des projets précédents.

Et surtout, ne confondez pas trois questions différentes : l’équipe connaît-elle le domaine ? Dispose-t-elle d’expérience ? Est-elle réellement performante dans l’analyse et la conception ?

COCOMO II distingue ces dimensions précisément parce qu’elles n’ont pas le même effet sur un projet.