Évaluation des fournisseurs de logiciels de défense : guide de due diligence technique pour les officiers chargés des marchés publics

Les marchés publics de logiciels de défense échouent plus souvent lors de la phase d'évaluation des fournisseurs qu'à tout autre stade du cycle d'acquisition. Non pas parce que les officiers chargés des marchés manquent de diligence — mais parce que les cadres d'évaluation qu'ils appliquent ont été conçus pour l'informatique commerciale, où les risques sont les interruptions de service, les dépassements de coûts et les problèmes d'intégration. Les marchés de défense ajoutent une catégorie de risque entièrement différente : des défaillances de sécurité aux conséquences opérationnelles, une exposition de la chaîne d'approvisionnement aux services de renseignement adverses, et des lacunes contractuelles qui ne se manifestent que lorsque le système est le plus nécessaire.

Ce guide fournit un cadre structuré de due diligence technique spécifiquement conçu pour l'évaluation des fournisseurs de logiciels de défense. Il couvre huit domaines d'évaluation : pourquoi les approches commerciales échouent, comment évaluer l'architecture technique, quelles certifications de sécurité importent réellement, les exigences d'entiercement du code source, l'évaluation des SLA et du support pour les programmes à long cycle, la vérification des références clients, la structure PoC et les droits contractuels sur les données.

Pourquoi l'évaluation commerciale standard des fournisseurs échoue pour la défense

Les cadres commerciaux d'évaluation des fournisseurs ont été construits autour de quatre dimensions de risque : le fournisseur livre-t-il les fonctionnalités promises, au coût indiqué, intégré dans la pile existante, avec une disponibilité acceptable ? Ce sont des risques réels — mais pas les risques dominants dans les marchés publics de logiciels de défense. La conformité ITAR, les exigences de longévité (15 à 20 ans de durée de vie opérationnelle), la continuité opérationnelle dans des conditions adverses et l'accréditation au niveau de classification sont des dimensions d'évaluation obligatoires que les cadres commerciaux ignorent systématiquement.

Revue de l'architecture technique

La qualité de la documentation d'architecture est l'un des indicateurs précoces les plus fiables de la discipline d'ingénierie d'un fournisseur. Demandez à chaque fournisseur présélectionné : un diagramme d'architecture des composants, un diagramme d'architecture de déploiement, la documentation API, un Software Bill of Materials (SBOM) au format SPDX ou CycloneDX, et des Architecture Decision Records (ADRs).

Vérification des certifications de sécurité

ISO 27001 certifie le système de management de la sécurité de l'information. SOC 2 Type II évalue les contrôles de sécurité opérationnels sur une période d'exploitation. La conformité ITAR n'est pas une certification mais une obligation légale : pour les programmes avec des exigences de partage en coalition, un examen juridique indépendant est requis. L'AQAP-2110 OTAN est la norme OTAN pour la gestion de la qualité des logiciels, requise lors de la fourniture de logiciels dans le cadre d'un programme OTAN.

Entiercement du code source et continuité des activités

L'entiercement du code source est un arrangement contractuel dans lequel le fournisseur dépose le code source, les scripts de compilation, les suites de tests et la documentation auprès d'un agent tiers neutre. Pour les programmes de défense ayant une durée de vie opérationnelle de 15 à 20 ans, c'est un mécanisme de continuité des activités. Spécifiez dans le contrat : la portée du dépôt, la fréquence de mise à jour, les conditions de déclenchement, la vérification de la reproductibilité de la compilation et un agent d'entiercement accrédité.

Évaluation du support et des SLA

L'évaluation des SLA pour les programmes de défense doit couvrir quatre dimensions : les engagements de temps de réponse par niveau de gravité (P1 en heures, pas en jours), la fréquence des correctifs de sécurité, la durée de la fenêtre de support à long terme (les systèmes militaires nécessitent au minimum 10 à 15 ans), et la capacité de l'équipe de support lors des situations de crise.

Vérification des références clients

Les listes de références fournies par le fournisseur sont un point de départ, pas une finalité. Contactez directement le gestionnaire de programme ou le responsable technique de l'organisation de référence. Posez des questions opérationnelles : qu'est-ce qui a échoué lors du déploiement ? Qu'est-ce qui a pris plus de temps que promis ? Choisiriez-vous à nouveau ce fournisseur ? Priorisez les références avec des cas d'utilisation similaires et des niveaux de classification comparables.

Structure du pilote et du PoC

Un PoC défendable nécessite : des critères de succès mesurables convenus à l'avance, un environnement de test réaliste reflétant les contraintes opérationnelles, une rubrique de notation, une équipe d'évaluation neutre séparée des décideurs en matière de marchés publics, et un protocole de documentation des échecs.

Considérations contractuelles : PI, droits sur les données et conformité ITAR

Clauses contractuelles critiques : droits de propriété intellectuelle sur les logiciels développés avec des fonds publics, droits de modification sans approbation du fournisseur, droits sur les données opérationnelles et les produits de renseignement dérivés, obligations de conformité ITAR dans la chaîne de sous-traitance, et dispositions de sortie et de transition.