Des outils partout… mais pour quels gains ?
Les DSI ont considérablement investi dans l’outillage des équipes de développement : gestion des exigences et des backlogs, environnements de développement, gestion de versions, CI/CD, tests automatisés, qualité du code, gestion de configuration, observabilité…
Plus récemment, les assistants de développement utilisant les IA génératives sont venus compléter cet environnement.
Pourtant, deux équipes disposant apparemment des mêmes catégories d’outils peuvent présenter des niveaux d’efficacité très différents.
La différence ne réside donc pas seulement dans le nombre ou la puissance des outils disponibles. Elle dépend également de leur maturité, de leur intégration dans le cycle de développement et de leur articulation avec les processus de l’organisation.
C’est précisément ce que cherche à caractériser le facteur TOOL – Use of Software Tools de COCOMO II.
Ce facteur est issu du modèle international COCOMO II, utilisé depuis de nombreuses années pour l’estimation des projets logiciels.
Que mesure le facteur TOOL ?
COCOMO II classe TOOL parmi les facteurs liés au projet. Ces facteurs prennent notamment en compte l’utilisation des outils logiciels, la localisation des équipes et les contraintes de calendrier.
Le principe est simple : un projet réalisé avec des outils élémentaires nécessite davantage d’effort qu’un projet comparable bénéficiant d’un environnement mature et intégré.
Le modèle ne mesure donc pas simplement la présence d’un outil.
Il cherche à caractériser le niveau global d’outillage mis à disposition du projet et son degré d’intégration au cycle de vie logiciel.
Les différents niveaux
COCOMO II décrit une progression depuis des outils élémentaires jusqu’à un environnement fortement intégré.
| Niveau | Description simplifiée |
| Très faible | Édition, codage, débogage |
| Faible | Outils simples front-end / back-end |
| Nominal | Outils CASE avec peu d’intégration |
| Élevé | Outils de base couvrant le cycle de vie, modérément intégrés |
| Très élevé | Outils de cycle de vie solides et matures, modérément intégrés |
| Extra High | Outils matures et proactifs, bien intégrés aux processus, méthodes et mécanismes de réutilisation |
Cette échelle montre un point important : posséder de nombreux outils ne suffit pas pour obtenir une évaluation élevée.
L’intégration entre outils et processus est déterminante.
Les coefficients COCOMO II
Les coefficients publiés dans le document de référence sont les suivants :
| Niveau | Coefficient d’effort |
| Très faible | 1,17 |
| Faible | 1,09 |
| Nominal | 1,00 |
| Élevé | 0,90 |
| Très élevé | 0,78 |
| Extra High | n/a |
Un coefficient supérieur à 1 augmente l’effort estimé. Un coefficient inférieur à 1 le réduit.
Il faut néanmoins éviter d’interpréter ces valeurs comme une promesse automatique de gain. Elles appartiennent au modèle COCOMO II et doivent être utilisées dans le cadre global de celui-ci.
Exemple sur un projet de 1 000 jours-homme
Prenons un projet dont l’effort de référence est de 1 000 jours-homme au niveau nominal, toutes les autres hypothèses restant identiques.
| Niveau TOOL | Coefficient | Effort | Écart / nominal |
| Très faible | 1,17 | 1 170 j.h. | +170 |
| Faible | 1,09 | 1 090 j.h. | +90 |
| Nominal | 1,00 | 1 000 j.h. | — |
| Élevé | 0,90 | 900 j.h. | -100 |
| Très élevé | 0,78 | 780 j.h. | -220 |
Entre les niveaux Très faible et Très élevé, l’écart atteint donc 390 jours-homme.
Autrement dit, dans cet exemple théorique, le projet avec l’environnement le plus rudimentaire représente 50 % d’effort de plus que celui disposant de l’environnement Très élevé :
1 170 / 780 = 1,50.
Ce chiffre permet surtout de comprendre l’ordre de grandeur potentiel du facteur. Il ne signifie évidemment pas que l’achat de nouveaux outils réduira automatiquement de 390 jours la charge d’un projet.
Cas concret : modernisation d’un portail client
Imaginons la refonte d’un portail client mobilisant plusieurs équipes.
Dans une première organisation, les exigences sont gérées dans des documents séparés, les tests sont partiellement manuels, les déploiements nécessitent plusieurs interventions et certains contrôles de qualité sont réalisés tardivement.
Une partie de l’effort est alors absorbée par des activités périphériques : ressaisie, synchronisation, vérification, correction et déploiement.
Dans une seconde organisation, les équipes disposent d’une chaîne mieux intégrée : backlog partagé, gestion de versions, intégration continue, tests automatisés, analyse de qualité, déploiement automatisé et traçabilité.
La fonctionnalité demandée au projet est identique.
Mais l’effort nécessaire pour la produire, la vérifier et la mettre à disposition peut être sensiblement différent.
Pourquoi un tel impact ?
L’outillage agit sur plusieurs mécanismes.
L’automatisation réduit certaines tâches manuelles répétitives.
L’intégration limite les ressaisies et les ruptures entre les différentes étapes.
Les contrôles précoces permettent d’identifier certaines anomalies avant qu’elles ne deviennent coûteuses à corriger.
La standardisation facilite l’application de pratiques communes entre les équipes.
La traçabilité réduit le temps nécessaire pour retrouver l’origine d’une modification ou comprendre l’état d’un élément du projet.
Le gain ne provient donc pas uniquement de la vitesse avec laquelle un développeur produit du code.
Il concerne potentiellement l’ensemble du cycle de réalisation.
Les symptômes d’un niveau défavorable
Plusieurs signes doivent attirer l’attention :
- nombreuses opérations manuelles ;
- informations ressaisies dans plusieurs outils ;
- outils peu ou pas interconnectés ;
- tests automatisés insuffisants ;
- déploiements complexes ou fortement manuels ;
- contrôles de qualité tardifs ;
- difficulté à assurer la traçabilité entre exigences, développements et tests ;
- outils disponibles mais faiblement utilisés par les équipes.
Le dernier point est particulièrement important : un outil installé n’est pas nécessairement un outil réellement opérationnel dans le processus projet.
Conséquences sur le chiffrage
Lors d’un chiffrage, demander simplement « Quels outils utilisez-vous ? » est insuffisant.
Il faut chercher à comprendre comment le projet va réellement fonctionner.
Quelques questions sont particulièrement utiles :
- quelles activités sont automatisées ?
- quelles étapes restent manuelles ?
- les outils communiquent-ils entre eux ?
- quelle part des tests est automatisée ?
- les builds et déploiements sont-ils automatisés ?
- existe-t-il une chaîne CI/CD réellement utilisée ?
- les équipes maîtrisent-elles les outils disponibles ?
- les processus et méthodes sont-ils intégrés à cet environnement ?
Cette analyse permet d’éviter une erreur fréquente : reprendre la productivité historique d’une équipe fortement industrialisée pour estimer un projet dont l’environnement le sera beaucoup moins.
L’hypothèse d’outillage doit donc être explicitée et documentée dans le chiffrage.
Comment améliorer ce facteur ?
Trois leviers peuvent être privilégiés.
- Automatiser les activités répétitives
Tests, builds, déploiements, contrôles de qualité ou génération de certains livrables constituent des candidats naturels.
- Intégrer les outils
L’objectif n’est pas nécessairement d’ajouter de nouveaux produits, mais de réduire les ruptures entre ceux qui existent déjà.
- Standardiser les pratiques
Un environnement industriel produit peu de gains si chaque équipe l’utilise différemment ou seulement partiellement.
L’enjeu devient donc autant organisationnel que technologique.
Quel impact des IA génératives ?
Les IA génératives modifient profondément la question de l’outillage.
Elles peuvent intervenir dans la rédaction et l’analyse des exigences, la génération de code, les tests, la documentation, l’analyse d’anomalies ou encore certaines opérations de maintenance.
Elles peuvent donc renforcer l’effet d’un environnement logiciel performant.
Mais il serait imprudent d’appliquer directement les coefficients COCOMO II pour quantifier les gains liés aux IA génératives. Le document de référence date d’une période très antérieure à leur utilisation actuelle.
La question pertinente devient donc : quel gain est réellement constaté sur les projets de l’organisation ?
Une IA utilisée ponctuellement comme assistant individuel n’a pas le même impact qu’une IA intégrée à une chaîne de conception, développement, tests et contrôle qualité.
L’IA ne supprime donc pas le facteur TOOL. Elle oblige plutôt à réexaminer la manière de le mesurer et, idéalement, à recalibrer les gains à partir des données réelles de l’organisation.
Les erreurs fréquentes
Confondre possession et utilisation.
Une licence disponible n’implique pas une adoption effective.
Multiplier les outils.
Davantage d’outils peuvent au contraire créer davantage de ruptures.
Négliger l’intégration.
C’est souvent le passage fluide d’une activité à l’autre qui génère les gains.
Supposer un gain théorique sans le mesurer.
Une DSI devrait confronter les bénéfices attendus aux données de ses propres projets.
Considérer l’IA comme un coefficient de productivité universel.
Son impact dépend fortement des activités, des équipes, des technologies et de son intégration aux processus.
À retenir
TOOL — Utilisation des outils logiciels
- COCOMO II considère l’outillage comme un facteur influençant l’effort du projet.
- Ses coefficients vont de 1,17 à 0,78 entre les niveaux Très faible et Très élevé.
- Sur une référence de 1 000 jours-homme, cela représente un écart théorique de 390 jours-homme.
- Le nombre d’outils compte moins que leur maturité, leur intégration et leur utilisation effective.
- Les IA génératives renforcent l’intérêt du sujet mais nécessitent de mesurer les gains réels plutôt que de supposer une productivité uniforme.
Quelles décisions pour un DSI ?
Pour un DSI, le facteur TOOL conduit à considérer l’outillage non comme une simple dépense technique, mais comme une composante de la performance économique des projets logiciels.
Trois décisions en découlent.
D’abord, identifier les chaînes de développement dans lesquelles les ruptures et opérations manuelles consomment encore beaucoup d’effort.
Ensuite, privilégier l’intégration et l’automatisation plutôt que l’accumulation de nouveaux outils.
Enfin, mesurer la performance avant et après les évolutions majeures d’outillage, notamment l’introduction des IA génératives.
Ces données permettront progressivement d’établir des coefficients adaptés au contexte réel de la DSI et d’améliorer la qualité des estimations.
« La valeur d’un outil ne se mesure pas à ses fonctionnalités, mais à l’effort qu’il permet réellement d’éviter. »
Le conseil Estimancy
Lors d’un chiffrage, ne décrivez pas uniquement les outils disponibles : décrivez la chaîne de travail réellement utilisée par le projet.
Une équipe peut disposer d’un environnement technologique moderne tout en conservant de nombreuses opérations manuelles et ruptures de processus.
Pour fiabiliser l’estimation, confrontez donc le niveau d’outillage déclaré aux pratiques réelles et, lorsque vous disposez d’un historique suffisant, mesurez son impact sur les projets terminés.
