Achats de logiciels de défense : du RFI au contrat signé

Les achats de logiciels de défense ne sont pas une version ralentie de l'acquisition commerciale de logiciels. Il s'agit d'un processus structurellement différent, avec des instruments distincts, une logique d'évaluation différente, des cadres juridiques spécifiques, et des modes d'échec qui n'existent pas sur les marchés commerciaux. Un fournisseur qui a remporté des contrats dans le secteur privé et qui entre dans un processus d'acquisition de défense sans préparation perdra systématiquement face à des concurrents plus petits et moins capables qui comprennent le fonctionnement du processus. Un responsable des achats qui applique ses réflexes commerciaux à un marché de logiciels de défense se retrouvera souvent avec un contrat mal spécifié qui génère des années de litiges.

Cet article retrace le processus du premier contact avec le marché à l'attribution du contrat — en couvrant chaque instrument dans sa séquence, la logique d'évaluation qui guide la sélection des sources, les certifications qui conditionnent la participation, et les structures contractuelles qui déterminent l'allocation des risques. Il identifie également les erreurs qui éliminent les fournisseurs techniquement solides de la compétition avant même que l'évaluation ne commence.

Les instruments d'achat : RFI, RFP et ITT

Les achats de logiciels de défense utilisent trois instruments principaux en séquence, et confondre leur finalité conduit à une mauvaise allocation des efforts à chaque étape.

RFI — Demande d'information

Le RFI est un outil d'étude de marché. Il ne comporte aucun engagement d'attribution et ne génère aucune obligation contraignante pour l'une ou l'autre des parties. L'autorité adjudicatrice — BAAINBw en Allemagne, DGA en France, IU MON en Pologne, ou une agence d'achat commune de l'OTAN — utilise le RFI pour comprendre quelles solutions existent, quels fournisseurs peuvent les livrer de manière crédible, et à quoi ressemble une fourchette réaliste de coûts et de délais avant de rédiger les exigences formelles. Les réponses au RFI sont généralement courtes (5 à 15 pages) et l'évaluation est informelle. Il n'existe pas de grille de notation, pas de présélection compétitive, et aucun mécanisme permettant d'exclure un fournisseur d'un RFP ultérieur sur la base de sa réponse au RFI.

La valeur stratégique du RFI pour les fournisseurs n'est pas la notation — c'est l'influence. Une réponse au RFI bien construite, qui introduit une capacité que l'autorité n'avait pas envisagée, ou qui définit une approche technique qui devient la base des exigences du RFP, crée un avantage structurel avant que l'évaluation compétitive ne commence. Les autorités rédigent ce qu'elles connaissent. Les fournisseurs qui les aident à comprendre ce qui est possible influencent le document d'exigences.

RFP — Demande de propositions

Le RFP est la sollicitation formelle. Il ouvre la sélection compétitive des sources et contient la spécification complète des exigences, les critères d'évaluation avec leurs pondérations, les instructions pour la préparation des propositions, les termes et conditions du contrat, et le calendrier d'évaluation et d'attribution. Les réponses au RFP sont formellement évaluées selon les critères énoncés et constituent la base juridique de la décision d'attribution du contrat. Le dossier compétitif constitué lors de l'évaluation du RFP est celui qu'un fournisseur perdant utilise s'il dépose un recours.

Les RFP pour les programmes de logiciels de défense sont généralement des documents volumineux — 100 à 400 pages n'est pas inhabituel pour une acquisition importante — et la spécification des exigences qu'ils contiennent est contraignante. Un fournisseur qui soumet une proposition qui n'aborde pas explicitement chaque exigence ne reçoit aucun crédit pour cette exigence, quelle que soit sa capacité réelle. C'est l'erreur structurelle la plus courante dans les réponses aux RFP de logiciels de défense : des réponses rédigées comme des documents marketing décrivant ce que fait le fournisseur, plutôt que comme des documents de conformité qui cartographient la solution du fournisseur par rapport à chaque exigence énoncée.

ITT — Invitation à soumissionner

L'ITT, utilisée principalement dans les contextes d'achat européens et britanniques et dans le cadre des directives européennes sur les marchés publics de défense, est fonctionnellement équivalente au RFP dans la plupart des aspects. La principale distinction est que les ITT appliquent généralement une pondération plus stricte sur la compétitivité des prix et sont utilisées dans des contextes d'achat où les spécifications techniques sont entièrement définies à l'avance, laissant moins de marge pour la différenciation de l'approche technique. Une ITT est souvent l'instrument approprié pour les composants logiciels aux spécifications établies (protocoles de communication, formats de données, normes d'interopérabilité), où la principale variable concurrentielle est le prix et le calendrier de livraison.

Le calendrier d'achat : 12 à 36 mois

Le délai réaliste entre la publication du RFI et l'attribution du contrat pour un programme important de logiciels de défense est de 18 à 36 mois. Les acquisitions plus petites et bien définies peuvent aller plus vite — 12 à 18 mois est réalisable lorsque les exigences sont déjà spécifiées et que le marché est structuré comme un ordre compétitif sur un accord-cadre existant. La répartition typique du calendrier est la suivante :

Publication du RFI et étude de marché : 2 à 3 mois. L'autorité collecte les réponses, organise des journées industrie et développe une évaluation préliminaire du marché. Développement des exigences et rédaction du RFP : 3 à 6 mois. L'autorité traduit l'étude de marché en spécification formelle des exigences et rédige l'appel d'offres. Cette phase comprend souvent une période de commentaires sur un RFP provisoire permettant aux fournisseurs d'identifier les ambiguïtés. Période ouverte du RFP : 2 à 3 mois. Les fournisseurs préparent leurs propositions ; l'autorité gère les questions-réponses formelles. Évaluation des propositions et présélection : 3 à 6 mois. Les commissions d'évaluation notent les volumes technique, de gestion et de coût selon les critères énoncés. Phase BAFO (si utilisée) : 1 à 2 mois. Un ensemble de fournisseurs présélectionnés soumet des propositions finales révisées. Décision de sélection et attribution : 1 à 3 mois. L'autorité de sélection émet la décision d'attribution et la période de notification préalable à l'attribution requise. Période de recours : 35 à 90 jours selon la juridiction. Les fournisseurs non retenus disposent d'une fenêtre définie pour déposer un recours avant le début de l'exécution du contrat.

Les programmes qui sautent la phase RFI et rédigent les exigences sans engagement avec le marché tendent à produire des spécifications qui favorisent soit un seul fournisseur (générant des recours), soit décrivent une capacité qu'aucun fournisseur ne peut pleinement livrer (générant des avenants après attribution). Le temps consacré à l'engagement pré-sollicitation raccourcit presque toujours la phase de litige post-attribution.

Critères de sélection des sources : comment les propositions sont évaluées

Les RFP de logiciels de défense évaluent généralement les propositions selon trois volumes — technique, de gestion et de coût — avec des pondérations définies qui doivent totaliser 100 %. Les pondérations exactes varient selon le programme et l'autorité, mais une répartition courante pour les acquisitions de logiciels complexes est de 40 à 50 % pour le technique, 20 à 30 % pour la gestion et 20 à 30 % pour le coût. Certaines autorités utilisent une porte technique de type pass/fail avant que l'évaluation des coûts ne commence : les propositions qui ne satisfont pas un seuil technique minimum sont exclues de la comparaison des coûts.

Volume technique

Le volume technique est évalué par rapport aux exigences fonctionnelles et non fonctionnelles énoncées dans le RFP. Les évaluateurs évaluent si la solution proposée satisfait les exigences, si l'approche technique est réaliste et réalisable dans le calendrier proposé, et si le fournisseur a démontré sa compréhension des risques techniques. Une proposition qui affirme une conformité totale sans expliquer comment elle est atteinte obtient une note inférieure à celle qui cartographie explicitement chaque exigence sur une décision architecturale ou d'implémentation spécifique. Les évaluateurs sont généralement des experts en la matière — ingénieurs logiciels, intégrateurs systèmes, spécialistes en cybersécurité — qui peuvent identifier les affirmations de conformité vagues.

Volume de gestion

Le volume de gestion couvre le plan d'exécution du projet, les qualifications de l'équipe, le personnel clé, l'approche de gestion des risques et la gestion des sous-traitants. Les références de performance passée sont un élément central — l'autorité examine l'historique documenté des livraisons sur des programmes comparables comme preuve du risque d'exécution. La performance passée est généralement évaluée séparément du volume de gestion dans le cadre d'une évaluation de confiance (confiance substantielle, confiance satisfaisante, confiance limitée, absence de confiance) qui peut éliminer des fournisseurs techniquement solides si leur historique de livraison montre des problèmes de calendrier ou de qualité.

Volume de coût

Le coût est évalué pour son réalisme et sa raisonnabilité, pas seulement pour sa valeur absolue. Un prix irréaliste bas — que l'estimation de coût indépendante de l'autorité indique ne pouvoir pas soutenir l'approche technique proposée — est noté négativement comme indicateur de risque, et non récompensé. Les autorités effectuent une analyse du réalisme des coûts sur les contrats T&M et à coût plus marge ; sur les contrats FFP, elles évaluent la raisonnabilité du prix. Un volume de coût qui ne comprend pas une structure de décomposition du travail détaillée avec des estimations d'heures de travail traçables est difficile à défendre lors d'un examen du réalisme des coûts.

Certifications obligatoires et exigences de conformité

Les programmes de logiciels de défense exigent que les fournisseurs détiennent des certifications spécifiques avant l'attribution. L'ensemble de base qui apparaît dans la plupart des appels d'offres des États membres de l'OTAN comprend ISO 27001 (système de management de la sécurité de l'information), ISO 9001 (système de management de la qualité), et AQAP 2110 — la norme d'assurance qualité de l'OTAN pour la conception, le développement et la production, alignée sur ISO 9001 et requise pour tout logiciel intégré à un système d'armes, une plateforme C2 ou une infrastructure critique de mission. AQAP 2110 n'est pas ISO 9001 avec une étiquette défense ; elle comporte des exigences spécifiques en matière de gestion de la configuration, de revue de conception et de tests d'acceptation qui ne sont pas présentes dans la norme commerciale.

Les exigences nationales s'ajoutent à la base de l'OTAN. Les programmes BAAINBw allemands pour les systèmes classifiés exigent la conformité aux procédures nationales de gestion des informations classifiées. Les programmes DGA français peuvent exiger la certification ANSSI pour les systèmes traitant des données gouvernementales sensibles. Les programmes IU MON polonais exigent la conformité avec la loi nationale de protection des informations classifiées. Les programmes du ministère de la Défense britannique font référence à JSP 440 (Manuel de la défense sur la sécurité) et au dispositif Cyber Essentials Plus comme exigences de base pour les fournisseurs de logiciels commerciaux.

Le statut sans ITAR comme différenciateur concurrentiel

Les réglementations américaines sur le trafic international d'armes (ITAR) restreignent l'exportation de technologies liées à la défense d'origine américaine. Pour les programmes de défense européens, les logiciels qui incorporent des composants soumis au contrôle ITAR créent des contraintes de conformité et opérationnelles : l'autorité adjudicatrice doit obtenir l'autorisation du gouvernement américain avant de partager le logiciel avec des nations alliées, de le déployer dans des opérations conjointes avec des partenaires non autorisés, ou de le modifier d'une manière qui altère la technologie contrôlée. Ces contraintes sont opérationnellement significatives pour les programmes multinationaux et créent un risque d'achat pour les autorités souhaitant de la flexibilité dans le déploiement du système.

Les fournisseurs de logiciels basés dans l'UE dont les produits ne contiennent aucun composant ITAR contrôlé d'origine américaine peuvent commercialiser cela comme un véritable avantage opérationnel, et non comme un argument marketing. Cela simplifie l'examen juridique, supprime une dépendance à l'autorisation de ré-exportation, et donne à l'autorité adjudicatrice un contrôle total sur les décisions de déploiement. Pour les programmes exploités par plusieurs États membres de l'UE ou déployés dans des environnements multinationaux, le statut sans ITAR est souvent une exigence formelle, et non une préférence. Voir notre analyse des considérations relatives aux logiciels de défense sans ITAR pour un traitement plus complet de l'impact sur le positionnement concurrentiel.

BAFO : la phase de meilleure offre finale

Une phase BAFO (Best and Final Offer, ou meilleure offre finale) est utilisée lorsque l'évaluation initiale des propositions a réduit la compétition à une liste restreinte de fournisseurs dont les notes sont suffisamment proches pour que des propositions révisées puissent changer l'issue. L'autorité contractante émet des instructions écrites précisant ce que les fournisseurs peuvent réviser — généralement le prix, le plan de dotation en personnel et des éléments techniques définis — et ce qui est figé. Les fournisseurs soumettent des propositions révisées dans une fenêtre définie, généralement 2 à 4 semaines.

L'erreur stratégique que font la plupart des fournisseurs lors d'une phase BAFO est de la traiter uniquement comme une négociation de prix. Si l'évaluation montre un écart de note technique de 3 points et une différence de prix de 5 %, réduire le prix sans combler l'écart technique perd. Les réponses BAFO efficaces traitent les deux dimensions simultanément : renforcer l'approche technique là où le retour d'évaluation (lorsqu'il est disponible) indiquait des écarts de notation, et affiner le prix là où une marge existe. Les autorités ne peuvent légalement pas fournir de ventilations de notes spécifiques avant le BAFO, mais les débriefings après l'évaluation initiale — lorsqu'ils sont disponibles — fournissent suffisamment de signaux pour identifier où se situe l'écart.

Structures contractuelles pour les logiciels de défense : FFP vs T&M

Les deux principales structures contractuelles pour les logiciels de défense sont le prix ferme et fixe (FFP) et la régie (T&M), avec des variantes à coût plus marge utilisées pour les travaux à forte intensité de recherche ou très incertains. Le choix entre les deux alloue différemment le risque de calendrier et de coût et façonne l'ensemble de la relation de gestion de programme après attribution.

Le FFP transfère le risque de coût et de calendrier au fournisseur. Le gouvernement paie un montant fixe quelle que soit la durée des travaux ou ce qu'il coûte à livrer. Le FFP est approprié lorsque les exigences sont entièrement spécifiées, stables et suffisamment détaillées pour que le fournisseur puisse établir une estimation ascendante réaliste des coûts. Pour des versions logicielles définies avec des bases d'exigences acceptées, le FFP crée une incitation pour le fournisseur à livrer efficacement. Le risque pour le fournisseur est la dérive des exigences après attribution — tout changement par rapport à la base d'exigences convenue déclenche un processus d'avenant, et les litiges sur ce qui était et n'était pas dans le périmètre à l'attribution sont une cause principale de retards de programme.

Le T&M rémunère le fournisseur pour les heures travaillées aux taux de catégorie de main-d'œuvre convenus plus les coûts directs des matériaux, le gouvernement supportant le risque de calendrier et de coût. Le T&M est approprié lorsque les exigences sont exploratoires, lorsque le périmètre implique l'intégration avec des systèmes existants de configuration inconnue, ou lorsque le travail implique de la recherche et du développement où le résultat est incertain. Le T&M ne réduit pas l'obligation du gouvernement de gérer le programme — il l'augmente, car l'autorité doit activement surveiller les heures de travail et les livrables pour s'assurer de la valeur obtenue.

La plupart des programmes de logiciels de défense d'envergure significative utilisent une structure hybride : FFP pour les livrables définis (versions logicielles, livrables de documentation, formation), T&M ou coût plus marge pour le travail exploratoire, le soutien à l'ingénierie des systèmes et les activités de maintenance où le volume de travail ne peut pas être estimé de manière fiable à l'avance. Pour la phase de maintenance post-attribution, voir notre analyse détaillée des structures de contrats de maintenance de logiciels de défense et des points de négociation.

Erreurs courantes des fournisseurs qui éliminent des propositions compétitives

Plusieurs erreurs récurrentes apparaissent dans les réponses aux RFP de logiciels de défense qui sont techniquement capables mais procéduralement déficientes.

Ne pas aborder chaque exigence explicitement. Une proposition qui ne répond pas à chaque exigence énoncée dans le RFP reçoit un crédit nul pour les exigences qu'elle omet, quelle que soit la conformité implicite. Les évaluateurs notent ce qui est écrit, pas ce qui peut être inféré. Une matrice de conformité — un tableau associant chaque exigence à une section de la proposition — n'est pas optionnelle ; c'est l'outil de navigation principal de l'évaluateur.

Surestimer les références de performance passée. Les autorités contractantes de défense vérifient les références de performance passée. Une référence qui gonfle la valeur du contrat, le périmètre ou la performance de livraison crée un problème de crédibilité qui nuit à la notation sur tous les volumes d'évaluation, pas seulement la performance passée. Des références de performance passée précises et spécifiques provenant de programmes comparables surpassent les références gonflées provenant de travaux sans rapport.

Sous-coter pour gagner et prévoir de récupérer les coûts par des avenants. Cette stratégie est bien comprise par les autorités contractantes et intégrée dans leurs modèles d'évaluation. Un prix inférieur à l'estimation indépendante du gouvernement de plus de 15 à 20 % déclenche généralement un examen du réalisme des coûts. Une proposition qui gagne sur un prix irréaliste bas et génère ensuite des avenants crée les conditions de la rupture de la relation qui mène à l'échec du programme et aux procédures d'exclusion.

Manquer les exigences de certification. Une proposition d'un fournisseur qui ne détient pas les certifications requises au moment de la soumission de la proposition ne peut pas être attribuée. Les évaluateurs n'acceptent pas les engagements d'obtenir des certifications après attribution pour les exigences listées comme obligatoires. Le moment de commencer la certification AQAP 2110 n'est pas après la publication du RFP — c'est 12 à 18 mois avant de vouloir concourir pour les programmes qui l'exigent.

Ce que les responsables des achats doivent surveiller du côté des autorités

Les autorités adjudicatrices commettent des erreurs structurelles qui génèrent des recours de fournisseurs et des retards de programme avec une égale régularité. Les spécifications d'exigences rédigées autour de la solution d'un seul fournisseur sortant — identifiables lorsque les exigences de performance correspondent exactement à la capacité actuelle du titulaire, ou lorsque la spécification utilise la terminologie propriétaire du titulaire — génèrent des recours qui retardent l'attribution de 6 à 12 mois. Les exigences techniques trop prescriptives qui imposent une architecture spécifique plutôt qu'un résultat de performance limitent la concurrence aux fournisseurs qui peuvent démontrer leur conformité avec l'approche spécifiée plutôt qu'à ceux qui peuvent livrer la capacité requise.

Les critères d'évaluation appliqués de manière incohérente entre les propositions — où les évaluateurs notent des approches techniques similaires différemment sans justification documentée — sont la deuxième cause principale de recours réussis. Les acquisitions de logiciels de défense qui utilisent des grilles d'évaluation structurées avec une notation consensuelle documentée produisent des décisions d'attribution plus défendables et moins de recours que celles qui reposent sur le jugement individuel des évaluateurs.