COCOMO
Chiffrer le coût de reconstitution d'un logiciel à partir de son volume de code et de sa complexité technique.
Type d'actif : Logiciel · Approche : Marché
En une phrase
COCOMO répond à une question précise : combien coûterait-il de redévelopper ce logiciel aujourd'hui, en partant de zéro, avec une équipe au prix du marché ?
Ce qu'elle mesure vraiment
COCOMO — COnstructive COst MOdel — est un modèle publié par Barry Boehm et maintenu par l'université de Californie du Sud. C'est le standard de l'industrie pour estimer l'effort de développement d'un projet logiciel. Mukeï en détourne l'usage : au lieu de prévoir le coût d'un projet à venir, on chiffre le coût de reconstitution d'un logiciel existant.
Le raisonnement tient en trois temps. On mesure la taille du logiciel en KLOC — kilo lines of code, milliers de lignes de code source, hors commentaires. On en déduit un effort en hommes-mois : le travail d'une personne pendant un mois. On convertit enfin cet effort en euros, au coût mensuel chargé d'un développeur.
Le point non intuitif du modèle : la relation entre taille et effort n'est pas proportionnelle. Un logiciel deux fois plus gros coûte plus du double, parce que la complexité de coordination croît plus vite que le code. C'est ce que traduit l'exposant de la formule.
Pourquoi l'approche Marché et non Effort ? Parce que COCOMO ne regarde aucune facture. Il applique des barèmes de productivité publiés et un coût horaire de marché à un volume de code observé. C'est une comparaison, pas une reconstitution comptable. La méthode qui reconstitue les dépenses réellement engagées est Coûts de développement historiques (VRN), et elle, est bien classée Effort.
De quel COCOMO parle-t-on ?
Le modèle implémenté par Mukeï emprunte à deux générations du travail de Barry Boehm, et il vaut mieux le dire franchement que de le laisser découvrir. Les constantes de base a et b, ainsi que les trois modes Organic, Semi-détaché et Embedded, viennent de COCOMO 81 Basic (Boehm, Software Engineering Economics, 1981). Les 17 facteurs de coût du calculateur EAF viennent en revanche de COCOMO II (University of Southern California, 2000), qui a supprimé les modes au profit de cinq facteurs d'échelle.
Ce choix se défend sur deux points. Les constantes de COCOMO 81 Basic restent publiées et vérifiables par un tiers, ce qui compte pour un calcul opposable. Et le réglage par mode est nettement plus lisible pour un évaluateur que le paramétrage des cinq facteurs d'échelle de COCOMO II. Mais il faut être clair : ce n'est pas une implémentation conforme de COCOMO II, et c'est la raison pour laquelle la méthode s'appelle ici simplement « COCOMO ».
Pour quel type d'actif
Logiciel. Elle suppose l'accès au code — ou au moins une mesure fiable de son volume — et un logiciel suffisamment développé pour que la mesure ait un sens.
C'est la méthode de choix quand le logiciel ne génère pas encore de revenus identifiables : un outil interne, une brique technique, un produit avant lancement commercial. Elle est aussi la référence en contentieux, pour chiffrer ce qu'il en coûterait de reconstruire un actif détruit, détourné ou copié.
Les données qu'elle demande
| Donnée | Origine | Obligatoire |
|---|---|---|
| Nombre de lignes de code source | Saisie — hors commentaires | Oui — doit être positif ou nul |
| Mode COCOMO (Organic / Semi-détaché / Embedded) | Saisie, défaut Organic | Oui |
| Coût homme-mois | Saisie — référentiel de coûts salariaux | Oui — doit être positif ou nul |
| Facteur d'ajustement (EAF) | Saisie — assistant à 18 curseurs | Non — 1 par défaut |
| Dette technique par ligne de code | Saisie — moyennes par langage proposées | Non — 0 par défaut |
| Taux de coût de transition | Saisie, défaut 20 % | Non |
| Date d'évaluation | Saisie | Oui |
| Devise | Héritée de l'actif | Automatique |
Les trois modes décrivent le contexte de développement, et changent les coefficients de la formule :
| Mode | Ce qu'il décrit |
|---|---|
| Organic | Application classique, équipe expérimentée, contraintes souples. Un logiciel de gestion, un SaaS métier. |
| Semi-détaché | Situation mixte : contraintes moyennes, équipe partiellement expérimentée. |
| Embedded | Fortes contraintes matérielles, temps réel, exigences de sûreté. Un logiciel embarqué, un système critique. |
Le mode Embedded produit un effort nettement supérieur pour un même volume de code — le modèle considère qu'un code contraint coûte plus cher à écrire.
Comment le calcul se déroule
Aucune actualisation, aucune projection : le résultat est un coût d'aujourd'hui. La date d'évaluation ne fait qu'horodater le calcul.
1. Effort de base
Effort = a × KLOC^b (en hommes-mois)
Les coefficients a et b dépendent du mode et sont ceux de COCOMO 81 Basic (voir « De quel COCOMO parle-t-on ? » plus haut). En mode Organic, a vaut 2,4 et b vaut 1,05 — d'où la croissance plus que proportionnelle évoquée plus haut.
60 000 lignes de code = 60 KLOC, mode Organic : 2,4 × 60^1,05 ≈ 175 hommes-mois.
2. Ajustement par les facteurs de coût (EAF)
L'EAF — Effort Adjustment Factor — est le produit de tous les facteurs retenus. Chaque facteur est un multiplicateur : au-dessus de 1 il alourdit l'effort, en dessous il l'allège.
L'assistant intégré propose les 17 facteurs standard de COCOMO II, répartis en quatre familles : produit (fiabilité requise, complexité, volume de données, documentation, réutilisabilité), plateforme (contraintes de temps, de stockage, volatilité), personnel (compétence des analystes et des développeurs, turnover, expérience applicative, plateforme et outils), projet (outillage, développement multi-sites, compression du calendrier).
Mukeï y ajoute un 18e facteur, propre au produit : l'assistance par IA. Il va de 1,10 — aucune IA, politique restrictive — à 0,55 pour un développement piloté par agents autonomes. Ce facteur n'est pas dans le modèle académique : il traduit un changement réel de productivité que le barème d'origine ne pouvait pas anticiper. Il doit être justifié dans le rapport comme une extension assumée.
Une équipe très expérimentée sur un produit peu critique peut atteindre un EAF de 0,75 ; une équipe junior sur un système à haute fiabilité peut dépasser 1,6. Sur les 175 hommes-mois de l'exemple, cela fait la différence entre 131 et 280.
3. Valeur brute
Valeur brute = effort ajusté × coût homme-mois
175 hommes-mois × 8 500 € = 1 487 500 €.
4. Deux déductions
Le coût de transition (20 % par défaut). Récupérer un logiciel existant n'est jamais gratuit : il faut le comprendre, le reprendre, se l'approprier. Un acquéreur ne paie pas le coût de reconstitution plein.
La dette technique, exprimée en euros par ligne de code. C'est le coût estimé de remise en état du code : refactorisation, mise à niveau, tests manquants. Le formulaire propose des moyennes par langage. Zéro par défaut.
1 487 500 − 297 500 (transition 20 %) − 60 000 (1 €/LOC de dette) = 1 130 000 €.
5. Plancher à zéro
Si les déductions dépassent la valeur brute, le résultat est ramené à zéro — jamais négatif. Un logiciel ne peut pas valoir moins que rien par cette méthode.
Le niveau de confiance n'est pas fixe : il se compose de deux facteurs, et le plus faible l'emporte.
| Facteur | Élevé | Moyen | Faible |
|---|---|---|---|
| Volume de code | 5 KLOC ou plus | entre 0 et 5 KLOC | aucune ligne comptabilisée |
| Facteur d'effort (EAF) | ajusté | laissé à 1,00 | — |
Le volume domine parce que l'effort en dépend directement (Effort = a × KLOC^b) : sous 5 000 lignes, la loi de COCOMO n'a plus grand-chose à mesurer. Un EAF laissé à 1,00 n'ajuste rien — l'effort redevient une pure fonction de la taille, indifférente à la complexité, à l'équipe et aux contraintes du projet.
Une estimation peut donc être élevée sur un logiciel conséquent dont la complexité a été renseignée. Elle tombe à faible si aucune ligne n'est comptée.
L'analyse de sensibilité
Elle fait varier le coût homme-mois, pas le volume de code. C'est le paramètre le plus discutable de la méthode : un développeur senior parisien et un prestataire offshore ne coûtent pas le même prix, et l'écart se répercute proportionnellement sur le résultat.
Quand la choisir, quand l'éviter
La choisir quand :
- le logiciel n'a pas encore de revenus, ou des revenus non isolables ;
- on est en contentieux : contrefaçon, départ d'un associé avec le code, destruction. Le préjudice se chiffre en coût de reconstruction ;
- il s'agit d'un outil interne qui crée de la valeur sans jamais être facturé ;
- on cherche une borne technique à confronter à une valeur économique.
L'éviter quand :
- le logiciel est très rentable : le coût de reconstitution sera largement inférieur à ce qu'il vaut économiquement, et présenter ce chiffre seul se retournerait contre vous ;
- le volume de code n'est pas mesurable de façon fiable — code généré, bibliothèques tierces massives, monorepo mêlant plusieurs produits ;
- le logiciel est surtout de la configuration ou de l'assemblage de briques existantes : peu de lignes, beaucoup de valeur ;
- pour un dossier IP Box, où l'administration attend des dépenses tracées plutôt qu'un coût théorique — c'est le terrain de la méthode VRN.
Les pièges classiques
Compter les lignes générées, les dépendances et les tests. Le champ attend les lignes de code source écrites par l'équipe, hors commentaires. Inclure les bibliothèques installées, le code généré automatiquement ou les fichiers de configuration gonfle artificiellement le volume — c'est l'erreur la plus courante, et elle peut multiplier le résultat par trois.
Choisir le mode Embedded pour valoriser plus. Le mode se justifie par des contraintes réelles : temps réel, sûreté de fonctionnement, ressources matérielles limitées. Un SaaS de gestion en mode Embedded est un choix indéfendable devant un expert technique.
Régler tous les facteurs EAF au maximum. Chaque curseur pris isolément semble plausible ; leur produit ne l'est plus. Dix facteurs à 1,15 donnent un EAF de 4. L'EAF calculé par l'assistant reste visible dans le calcul : un EAF supérieur à 2 doit être argumenté facteur par facteur.
Confondre coût homme-mois et salaire. Le champ attend un coût chargé complet : salaire brut, charges patronales, outillage, part de structure. Un salaire brut seul sous-estime de 60 à 100 %.
Prendre le résultat pour la valeur du logiciel. COCOMO donne un coût de remplacement. Un logiciel bien conçu, concis, qui résout un vrai problème vaut souvent plusieurs fois son coût de reconstruction — et un logiciel volumineux et inutile vaut moins.
Le paradoxe du bon code. Un code refactorisé, concis et élégant produit un COCOMO plus bas qu'un code redondant et bavard. La méthode récompense mécaniquement la verbosité. C'est sa limite la plus profonde, et il faut la connaître avant de la présenter.
Ce que dit un tiers qui la conteste
« Votre décompte de lignes n'est pas vérifiable. » Objection facile à anticiper : produire la sortie d'un outil de comptage standard, avec les exclusions explicitées — dépendances, code généré, fichiers de test. C'est une pièce à déposer sur l'actif, pas une affirmation à défendre à l'oral.
« Le nombre de lignes n'est pas un indicateur de valeur. » Objection de fond, et parfaitement recevable — le paradoxe du bon code est réel. Deux réponses. D'abord, COCOMO ne prétend pas mesurer la valeur, seulement un coût de reconstitution : c'est un plancher technique. Ensuite, on croise avec une méthode Potentiel (valeur de rendement) ou Marché (multiple ARR), qui, elles, mesurent l'économique.
« Votre coût homme-mois est celui d'un grand compte. » Attaque efficace, car le résultat lui est directement proportionnel. La défense : citer la source du coût retenu — grille salariale du secteur, coûts réels constatés dans l'entreprise — et montrer l'analyse de sensibilité, qui donne la fourchette.
« Le facteur d'assistance par IA n'existe pas dans COCOMO II. » C'est exact, et il faut le dire plutôt que de le laisser découvrir. C'est une extension Mukeï, assumée comme telle, motivée par un gain de productivité que le modèle d'origine ne pouvait anticiper. Si l'interlocuteur le conteste, le calcul se refait sans ce facteur — l'écart est alors chiffrable et présentable.
« Pourquoi 20 % de coût de transition ? » Le taux est un défaut, pas une règle. Il traduit le fait qu'un repreneur doit s'approprier un code qu'il n'a pas écrit. Il se justifie par la qualité de la documentation et la disponibilité de l'équipe d'origine — et se modifie.
Références
- Barry W. Boehm, Software Engineering Economics, Prentice Hall, 1981 — le modèle d'origine (COCOMO 81), d'où proviennent les coefficients a et b et les trois modes de complexité utilisés par le moteur.
- COCOMO II Model Definition Manual, University of Southern California, 2000 — d'où proviennent les 17 facteurs de coût du calculateur EAF. Le moteur n'en reprend pas les facteurs d'échelle : voir « De quel COCOMO parle-t-on ? ».
- IAS 38 (immobilisations incorporelles) pour le cadre de capitalisation des coûts de développement.
Pour aller plus loin
- Catalogue des méthodes
- Les trois approches
- Coûts de développement historiques (VRN) — le pendant Effort, fondé sur des factures.
- Multiple ARR (SaaS)
- Valeur de rendement (logiciel)