Coût total de possession des logiciels de défense : guide d'achat

Un programme de logiciel de défense budgétise 2,4 millions d'euros pour une plateforme de connaissance de la situation. Deux ans après le déploiement, la dépense totale atteint 6,1 millions d'euros. L'écart — 3,7 millions d'euros — n'était inscrit dans aucune ligne budgétaire. Il s'est accumulé à travers le travail d'intégration, les rotations de formation, trois cycles de ré-accréditation de sécurité, une migration vers une version majeure, et une couche middleware propriétaire que le fournisseur a exigée mais n'a jamais mentionnée dans le devis initial.

Ce schéma est suffisamment courant pour être structurel, pas accidentel. Le coût total de possession (TCO) des logiciels de défense est systématiquement et parfois dramatiquement sous-estimé lors de la phase d'achat — non pas parce que les responsables des marchés sont négligents, mais parce que le modèle de coût utilisé lors de l'acquisition est structurellement incomplet. Ce guide fournit un cadre pour construire une estimation TCO défendable avant l'attribution du contrat.

Pourquoi le TCO des logiciels de défense est systématiquement sous-estimé

Dans les marchés de logiciels commerciaux, le coût d'acquisition et le TCO sont suffisamment proches pour qu'utiliser l'un comme substitut de l'autre soit défendable. L'environnement d'intégration est relativement standardisé, la base de formation correspond à la main-d'œuvre générale, et la cadence de maintenance suit des normes commerciales prévisibles.

Les marchés publics de défense opèrent dans un environnement différent sur chacune de ces dimensions. La couche d'intégration se connecte à des réseaux classifiés, des formats de données militaires propriétaires, et des systèmes patrimoniaux vieux de plusieurs décennies qui précèdent les conventions API modernes. La base de formation est composée d'opérateurs militaires avec des profils de rôle définis et un taux de rotation annuel élevé. Le processus de maintenance comprend une ré-accréditation de sécurité avant tout déploiement de correctif sur un système classifié — un processus qui ajoute des semaines ou des mois à chaque cycle de mise à jour.

Sur le plan structurel, le problème est amplifié par la façon dont les budgets de défense sont organisés. Le coût d'acquisition apparaît dans le budget des marchés publics. Le travail d'intégration apparaît dans le budget d'ingénierie du bureau de programme. La formation apparaît dans l'allocation de formation de l'unité. Le soutien apparaît dans une ligne de maintenance pluriannuelle négociée séparément du contrat initial. Aucun responsable budgétaire unique n'a de visibilité sur les quatre. Il en résulte que les fournisseurs gagnent systématiquement sur la base d'un faible coût d'acquisition, puis récupèrent leurs marges via les coûts que personne n'avait budgétisés.

Les cinq composantes du TCO et leur pondération

Un modèle TCO complet pour les logiciels de défense couvre cinq catégories de coûts. Leur poids relatif varie selon le programme, mais la distribution ci-dessous reflète les programmes typiques sur 10 ans observés dans les marchés publics de défense européens :

Coût d'acquisition (15 à 25 % du TCO sur 10 ans)

C'est le chiffre figurant sur le devis du fournisseur : frais de licence, frais d'abonnement, frais par utilisateur, et frais d'installation uniques. Pour les licences perpétuelles, ce coût est largement concentré sur la première année. Pour les modèles d'abonnement, projetez les frais annuels en avant en utilisant le plafond d'escalade de prix contractuel du fournisseur — typiquement 3 à 8 % par an pour les logiciels de défense — et actualisez à la valeur présente sur la durée de vie du programme.

Soyez attentif aux tarifications par utilisateur qui augmentent de façon inattendue. Une plateforme tarifée à 40 000 euros par an pour 50 utilisateurs peut atteindre 320 000 euros par an si le programme s'étend à 400 utilisateurs au sein d'une coalition. Modélisez le plafond réaliste d'utilisateurs, pas seulement l'effectif du déploiement pilote.

Coût d'intégration (25 à 35 % du TCO sur 10 ans)

L'intégration est la principale source de sous-estimation du TCO dans les programmes de défense. Elle couvre le travail et l'infrastructure nécessaires pour connecter le nouveau logiciel à l'environnement opérationnel existant : systèmes C2, flux de capteurs, bases de données de renseignement, plateformes logistiques, gestion des identités et infrastructure réseau.

L'intégration en défense n'est pas un travail de commodité. Chaque point de connexion implique une transformation de données personnalisée (les formats de données militaires ne sont pas compatibles REST), une médiation de couche de sécurité (chaque connexion à travers des frontières de classification nécessite une séparation cryptographique), et des tests sur des données opérationnelles réelles ou représentatives. La documentation d'intégration du fournisseur est rédigée pour des environnements commerciaux. L'adapter à un environnement de défense classifié multiplie typiquement l'effort documenté par 1,5 à 2.

Coût de formation (20 à 30 % du TCO de la première année ; 10 à 15 % annuellement par la suite)

La formation initiale couvre les opérateurs, les administrateurs système et les responsables de la sécurité. Pour un déploiement de taille moyenne sur trois unités, cela représente typiquement 400 à 800 heures-personnes d'instruction auxquelles s'ajoutent les frais de formateur et de locaux. Le chiffre systématiquement absent des estimations d'achat est le coût de formation récurrente généré par la rotation du personnel.

Les unités militaires opérationnelles renouvellent 20 à 35 % de leur personnel par an. Pour un système comptant 200 utilisateurs actifs, cela signifie que 40 à 70 nouveaux opérateurs nécessitent une formation chaque année — indéfiniment, pendant toute la durée du programme. Les supports de formation nécessitent également une maintenance : chaque changement majeur de version logicielle invalide les supports existants et nécessite un cycle de révision documentaire que les fournisseurs ne financent pas et soutiennent rarement.

Coût de maintenance et de support (20 à 30 % du TCO sur 10 ans)

Les frais de maintenance annuels pour les logiciels de défense s'élèvent typiquement à 15 à 22 % du coût de licence initial par an. Ces frais couvrent le développement de correctifs côté fournisseur et l'accès au support. Ils ne couvrent pas le travail interne nécessaire pour valider, tester et déployer ces correctifs dans un environnement classifié — un processus nettement plus coûteux que l'équivalent commercial en raison des exigences de ré-accréditation.

Les niveaux de SLA ont plus d'importance en défense que dans les contextes commerciaux car les conséquences d'une interruption sont opérationnelles. Évaluez les engagements de temps de réponse au support pour les incidents P1, la capacité de support documentée du fournisseur (effectifs et chaîne d'escalade), et la durée de la fenêtre de support à long terme par rapport à la durée de vie opérationnelle du programme. Un fournisseur offrant 5 ans de support pour un programme de 15 ans crée un vide structurel que les contrats d'achat abordent rarement.

Coût d'évolution (10 à 20 % du TCO sur 10 ans)

Les programmes de logiciels de défense subissent au moins deux transitions majeures de version sur une durée de vie de 10 ans. Chaque transition dans un environnement classifié implique : le travail de migration, la ré-accréditation (revue de sécurité et approbation formelle pour exploiter la nouvelle version), la re-formation, et les re-tests d'intégration. Les services professionnels des fournisseurs pour la migration sont systématiquement sous-estimés dans les devis initiaux car la complexité de la migration n'est pas pleinement connue lors de l'attribution du contrat.

Budgétisez une contingence de ré-accréditation de 40 à 80 % de l'effort d'intégration initial pour chaque transition majeure de version. C'est le chiffre le plus fréquemment absent des estimations des bureaux de programme.

Modèle de coût d'intégration : estimer le travail avant l'attribution du contrat

Une estimation du coût d'intégration avant attribution est nécessairement imprécise, mais une estimation d'ordre de grandeur est bien meilleure qu'aucune estimation. Le modèle suivant fournit un point de départ structuré.

Pour chaque point d'intégration, attribuez un score de complexité API de 1 à 5 basé sur quatre facteurs : complexité du protocole (REST/JSON score 1 ; protocoles binaires personnalisés score 5), exigences d'authentification (clé API score 1 ; TLS mutuel avec infrastructure PKI score 4 à 5), complexité de transformation des données (mappage direct de champs score 1 ; traduction sémantique entre modèles de données score 4 à 5), et disponibilité de SDK (SDK fourni par le fournisseur score 1 ; aucune documentation score 5).

L'estimation de base du travail est : (score de complexité × 20 heures) par point de terminaison, plus un ajout fixe de 80 heures pour la revue de sécurité par point d'intégration dans un environnement classifié, plus 40 heures pour les tests d'acceptation par point de terminaison. Pour un système avec 8 points d'intégration à score de complexité moyen de 3, l'estimation de base est (3 × 20 × 8) + (80 × 8) + (40 × 8) = 480 + 640 + 320 = 1 440 heures avant contingence.

Appliquez un multiplicateur de contingence de 1,3 à 1,5 pour les infrastructures classifiées où l'accès aux outils, la segmentation réseau et les processus d'approbation contraignent la productivité. L'estimation ajustée de 1 872 à 2 160 heures (environ 12 à 14 personnes-mois) constitue un chiffre de planification réaliste pour l'intégration d'un système de défense de complexité moyenne.

Coût de formation : modéliser la charge récurrente

La modélisation du coût de formation commence par la différenciation des rôles. Tous les utilisateurs n'ont pas les mêmes exigences de formation. Les opérateurs nécessitent une formation fonctionnelle sur leurs workflows spécifiques. Les administrateurs système nécessitent une formation complète sur la plateforme, y compris la configuration de sécurité. Les responsables de la sécurité nécessitent une formation spécifique à l'accréditation sur les fonctionnalités de sécurité du système et les procédures d'audit.

Pour un déploiement de 200 opérateurs, 10 administrateurs et 3 responsables de la sécurité, un budget de formation de base pour la première année pourrait ressembler à ceci : 200 opérateurs à 16 heures chacun (3 200 heures), 10 administrateurs à 40 heures chacun (400 heures), 3 responsables de la sécurité à 24 heures chacun (72 heures), plus les coûts de formateur et de supports — totalisant environ 3 700 heures-personnes d'instruction directe plus les frais généraux.

Le coût annuel récurrent avec 25 % de rotation est de 50 opérateurs à 16 heures (800 heures) plus la rotation proportionnelle des administrateurs et responsables de la sécurité — environ 900 heures par an. Sur une durée de vie de programme de 10 ans, le travail de formation récurrente dépasse l'investissement initial en formation dès la 4e année. Les programmes qui ne budgétisent que la formation initiale découvrent ce décalage au cours de la troisième ou quatrième année d'exploitation.

La maintenance des supports de formation est un poste distinct. Chaque version majeure du logiciel — typiquement tous les 18 à 24 mois — nécessite une révision des supports. Budgétisez 200 à 400 heures de rédaction technique et de conception pédagogique par cycle de version majeure.

Maintenance et support : niveaux de SLA et risque de viabilité du fournisseur

L'évaluation des SLA de support pour les logiciels de défense nécessite d'examiner trois dimensions que les listes de contrôle standard des marchés publics commerciaux omettent.

La première est la cadence des correctifs par rapport aux frais généraux de ré-accréditation. Un fournisseur qui publie des correctifs de sécurité mensuellement crée une charge de ré-accréditation mensuelle pour les déploiements classifiés. Une cadence de correctifs trimestrielle — avec des correctifs d'urgence pour les CVE critiques — est plus compatible opérationnellement avec les contraintes de déploiement classifié. Évaluez la fréquence historique de publication des correctifs du fournisseur par rapport à la capacité d'accréditation de votre organisation.

La deuxième est le risque de viabilité du fournisseur. Les fournisseurs de logiciels de défense sur le marché européen comprennent une proportion significative de petites et moyennes entreprises à profondeur financière limitée. Un fournisseur de 40 employés fournissant une plateforme critique représente un risque de concentration : dépendance aux personnes clés, risque d'acquisition, et abandon potentiel du produit. Évaluez la santé financière du fournisseur, sa structure de propriété et ses engagements de support à long terme dans le contrat. Le séquestre du code source est la mesure standard d'atténuation — le fournisseur dépose le code source et les instructions de compilation auprès d'un agent de séquestre neutre, avec libération déclenchée par des événements de continuité définis.

La troisième dimension est l'exposition aux composants open source. La plupart des logiciels de défense incluent des bibliothèques open source dont la maintenance est financée par la communauté. Les composants open source significatifs dont le support communautaire décline créent un coût futur : soit le fournisseur absorbe le coût de maintenance interne (qui finit par se répercuter sur les frais de support), soit le composant devient une responsabilité de sécurité. Demandez une nomenclature logicielle (SBOM) et examinez la santé des principales dépendances open source dans le cadre de la diligence raisonnable du fournisseur.

Pour un cadre détaillé d'évaluation des capacités des fournisseurs avant l'attribution du contrat, voir évaluation des fournisseurs de logiciels de défense : guide de diligence technique pour les responsables des marchés publics.

Développer vs. acheter vs. COTS : quand le développement sur mesure l'emporte sur le TCO

L'hypothèse standard lors des marchés publics est que le logiciel COTS (commercial off-the-shelf) est moins cher que le développement sur mesure car il amortit le coût de R&D sur de nombreux clients. Cette hypothèse s'applique dans les environnements commerciaux et s'effondre dans des contextes de défense spécifiques.

Le développement sur mesure devient compétitif sur le TCO avec le COTS lorsque trois conditions s'alignent. Premièrement, le modèle de données du produit COTS est architecturalement incompatible avec le système d'enregistrement, nécessitant une couche middleware qui est elle-même un projet logiciel significatif. Une couche middleware ajoute des coûts d'intégration, des coûts de maintenance et un point de défaillance unique — et elle est invisible dans la tarification du fournisseur COTS. Deuxièmement, la couche d'intégration propriétaire du produit COTS crée une dépendance fournisseur qui se compose dans le temps : les futures migrations de version deviennent otages des outils de migration du fournisseur, et les fournisseurs alternatifs font face au même problème de middleware en partant de zéro. Troisièmement, le périmètre fonctionnel est étroit et stable. Un outil sur mesure qui fait une seule chose bien — la fusion de pistes pour un type de capteur spécifique, par exemple — peut être construit, testé et maintenu par une petite équipe à un coût sur 10 ans inférieur à celui d'une large plateforme COTS avec 80 % de fonctionnalités inutilisées.

Le calcul du point de croisement : si le travail d'intégration COTS en première année dépasse 150 % du coût de la licence, et que les frais de maintenance annuels sont supérieurs à 20 % de la licence, et que la durée de vie du programme dépasse 8 ans, modélisez le développement sur mesure comme une option concurrente avant l'attribution. La comparaison doit inclure le coût complet du développement sur mesure (pas seulement la construction initiale — maintenance continue, correction de sécurité et évolution) projeté sur le même horizon.

Pour les programmes où le COTS est le bon choix mais où les conditions d'achat nécessitent une structuration soigneuse, le guide des marchés publics de défense de l'appel d'offres au contrat couvre les structures contractuelles qui protègent contre l'escalade des coûts après attribution.

Assembler le modèle : un exemple concret

Considérons une plateforme tactique de fusion de renseignement acquise pour un quartier général de niveau brigade. Le devis du fournisseur est de 1,8 million d'euros pour une licence de 5 ans couvrant 150 utilisateurs. Un modèle TCO complet pour une durée de vie de programme de 10 ans :

Acquisition (10 ans) : Licence années 1 à 5 : 1,8 M€, renouvellement années 6 à 10 estimé à 2,2 M€ (escalade annuelle de 3 % appliquée). Total : 4,0 M€.

Intégration : 10 points d'intégration à score de complexité moyen de 3,5, avec contingence d'infrastructure classifiée de 1,4. Estimation de 2 100 heures de travail au taux chargé de 120 €/heure. Plus infrastructure (serveur middleware, équipements de sécurité) : 180 K€. Total : 432 K€.

Formation (10 ans) : Formation initiale 3 700 heures-personnes à 85 €/heure = 315 K€. Formation récurrente annuelle à 80 K€/an × 9 ans = 720 K€. Maintenance des supports 3 cycles de version majeure à 35 K€ chacun = 105 K€. Total : 1,14 M€.

Maintenance et support (10 ans) : Frais de support annuels à 18 % de la licence originale (324 K€/an) × 10 = 3,24 M€. Travail interne de gestion des correctifs à 60 K€/an = 600 K€. Total : 3,84 M€.

Évolution (2 mises à niveau majeures) : Travail de migration 2 × 1 000 heures à 120 €/heure = 240 K€. Ré-accréditation 2 × 600 heures à 120 €/heure = 144 K€. Total : 384 K€.

TCO sur 10 ans : environ 9,8 millions d'euros pour un devis d'acquisition affiché de 1,8 million d'euros. Le coût d'acquisition représente 18 % du coût total du programme. Les 82 % restants n'étaient jamais dans le devis du fournisseur.

Structurer les marchés publics pour maîtriser le TCO

Un modèle TCO est utile avant l'attribution. Après l'attribution, la maîtrise des coûts dépend de la structure du contrat. Plusieurs mécanismes réduisent substantiellement le risque d'escalade des coûts après attribution.

Les plafonds de prix sur l'escalade des abonnements empêchent l'effet composé des augmentations annuelles de frais sur de longues durées de programme. Les taux des services professionnels d'intégration doivent être fixés lors de l'attribution du contrat, et non laissés à une négociation future quand le fournisseur a le levier. La propriété des supports de formation doit être dévolue à l'organisation acheteuse — les supports de formation appartenant au fournisseur sont un centre de coûts récurrent. Les obligations de support à la migration doivent être spécifiées : ce que le fournisseur fournit, à quel taux, pour chaque transition majeure de version. Et les engagements de fenêtre de support à long terme doivent être explicites — un fournisseur s'engageant à 10 ans de support lors de l'attribution du contrat est matériellement différent d'un fournisseur s'engageant à 5 ans avec renouvellement à la discrétion du fournisseur.

La modélisation TCO n'est pas une garantie contre les dépassements de coûts. Les programmes changent, les exigences évoluent et les fournisseurs sont rachetés. Mais une décision d'achat prise avec une image complète des coûts — plutôt qu'avec un substitut basé sur le coût d'acquisition — part d'une position de conscience structurelle plutôt que d'aveuglement structurel.