Cycle d'acquisition des startups de défense : du pilote au programme officiel

La plupart des startups technologiques de défense qui échouent commercialement n'échouent pas parce que leur produit a cessé de fonctionner. Elles échouent parce que la distance entre un pilote réussi et un Programme officiel (POR) financé est plus longue, plus complexe sur le plan bureaucratique et plus dépendante des relations que tout plan produit ne l'anticipe. Les mécanismes pour remporter ce premier contrat gouvernemental sont bien documentés. Ce qui reçoit beaucoup moins d'attention, c'est la phase plus difficile qui suit : convertir un paiement de pilote ponctuel en une ligne budgétaire soutenue capable de financer une entreprise en phase de croissance. Cet article retrace le cycle d'acquisition complet -- de la conception du pilote via le prototype OTA, l'accréditation de sécurité, la culture du champion de programme, les considérations de coalition, jusqu'aux risques structurels de transition qui mettent fin aux programmes avant qu'ils n'atteignent l'échelle opérationnelle.

La vallée de la mort : pourquoi les bonnes technologies se bloquent entre le pilote et le contrat

La vallée de la mort n'est pas une métaphore sur la qualité du produit. C'est un déficit de financement structurel qui résulte d'un décalage entre la vitesse de démonstration technologique et la vitesse des cycles budgétaires de défense. Une entreprise peut achever un pilote en 90 jours. Le bureau de programme peut confirmer que cela a fonctionné. Mais le bureau de programme ne peut pas engager de nouveaux fonds sur une capacité qu'il vient de découvrir -- pas avant que cette capacité ait survécu au processus du Mémorandum d'objectif de programme (POM), qui fonctionne sur un cycle de 18 mois et exige des exigences documentées, des estimations de coûts et des évaluations des risques qui n'existent pas pour une technologie que le programme vient d'évaluer.

Pendant cet intervalle, la startup est censée continuer à développer le produit, maintenir une équipe formée, soutenir la documentation d'évaluation du gouvernement et rester solvable grâce aux contrats Phase II SBIR, contrats-relais ou OTA de suivi qu'elle peut obtenir. La durée médiane de cet écart -- entre la fin d'un pilote réussi et le premier engagement dans le cadre d'un nouveau budget de programme -- est de 18 à 36 mois pour un logiciel sans historique d'acquisition DoD préalable. Les entreprises qui planifient un écart de 6 mois et se retrouvent à court de ressources au mois 14 n'ont pas de deuxième chance dans la plupart des bureaux de programme ; le champion passe à autre chose, et la technologie est réévaluée à zéro par le prochain gestionnaire de programme.

L'implication pratique est que la conception du pilote doit tenir compte de la vallée avant que le pilote ne commence. Un pilote structuré pour générer la documentation spécifique -- analyse des lacunes de capacité, données d'efficacité opérationnelle, architecture d'intégration, projection de coût unitaire -- dont un gestionnaire de programme a besoin pour construire une soumission POM survivra à la période de transition à des taux plus élevés qu'un pilote conçu uniquement pour démontrer les performances techniques. Les performances techniques sont le strict minimum. La lisibilité administrative vis-à-vis du processus budgétaire est ce qui traverse la vallée.

Accords OTA, SBIR et voies DIU -- en quoi ils diffèrent

Trois instruments contractuels dominent l'engagement précoce des startups de défense : les accords de prototype d'autorité de transaction spéciale (OTA), les attributions de recherche pour les petites entreprises innovantes (SBIR) et le processus d'appel à solutions commerciales (CSO) de l'Unité d'innovation pour la défense (DIU). Ils ne sont pas interchangeables, et choisir le mauvais véhicule pour le mauvais moment dans le cycle d'acquisition crée des retards difficiles à rattraper.

Les accords de prototype OTA en vertu du 10 USC 4022 constituent la voie la plus rapide d'une exigence financée à un prototype évalué pour une startup sans systèmes comptables gouvernementaux. Ils se situent en dehors du Règlement fédéral d'acquisition, ce qui signifie qu'un bureau de programme peut attribuer un OTA à une entreprise qui n'a jamais détenu de contrat DoD, ne dispose pas de systèmes comptables approuvés par la Defense Contract Audit Agency (DCAA) et ne peut pas produire de données de coût ou de prix certifiées. La contrepartie est la portée : les attributions OTA sont légalement limitées aux activités de prototype. Une transition vers une production à part entière nécessite soit une attribution de source unique compétitive de suivi, soit une attribution de production de source unique en vertu de la disposition de transition du statut OTA -- et cette source unique n'est pas automatique. Elle exige que le bureau de programme établisse par écrit que le prototype a été attribué de manière compétitive et que la suite de production est une extension logique. Les bureaux de programme qui n'ont pas préplanifié cette transition perdent souvent l'autorité de source unique et doivent relancer la mise en concurrence, recommençant le calendrier.

Les attributions SBIR Phase II fournissent jusqu'à 1,72 million de dollars (limite actuelle du DoD) pour une période de 24 mois. La disposition Phase III -- qui permet à un bureau de programme d'attribuer un contrat de suivi de source unique à un titulaire Phase II sans mise en concurrence -- est le mécanisme qui convertit le financement de recherche SBIR en contrat d'acquisition. La Phase III n'a pas de plafond de montant ni d'exigence de mise en concurrence, ce qui en fait le principal instrument de transition disponible pour une petite entreprise. La limitation est que l'attribution Phase III dépend entièrement d'un bureau de programme prêt à participer avec une ligne de financement ouverte -- et identifier ce bureau de programme avant l'expiration de la période Phase II exige le même travail de culture du champion que toute autre voie d'acquisition. Les programmes d'écosystème comme Brave1 en Ukraine ont démontré que des cadres d'accélération public-privé structurés peuvent comprimer ce délai d'identification du champion en donnant aux startups un accès visible aux bureaux de programme qui recherchent activement des types de capacités spécifiques.

Le processus CSO de la DIU est optimisé pour la technologie commerciale à application de défense et produit une attribution d'appel à solutions commerciales pouvant être transférée vers un contrat de production en vertu du 10 USC 4022. La force de la DIU est la rapidité -- les attributions peuvent se clore en 60 à 90 jours -- et son réseau, qui connecte les entreprises sélectionnées aux utilisateurs opérationnels et aux bureaux de programme de l'ensemble des armées. La limitation structurelle pour une startup est que la DIU est un mécanisme de transition, pas un financeur soutenu. Une attribution DIU prouve le concept et fournit une ligne budgétaire d'introduction ; elle ne remplace pas un bureau de programme de service qui possède l'exigence dans son POM.

Construire un produit viable minimum évaluable pour les responsables d'acquisition

Un produit viable minimum (MVP) pour l'acquisition n'est pas le même artefact qu'un MVP pour un lancement de logiciel commercial. Les MVP commerciaux sont conçus pour tester une hypothèse de marché avec des utilisateurs précoces payants. Les MVP d'acquisition de défense doivent satisfaire un ensemble différent d'évaluateurs -- responsables de passation de marchés, gestionnaires de programme, testeurs opérationnels et évaluateurs de sécurité -- chacun avec des exigences distinctes qui ne sont pas pleinement capturées dans un seul cadre d'évaluation.

Le responsable de passation de marchés doit confirmer que le prix proposé est équitable et raisonnable et que le fournisseur est responsable (c'est-à-dire qu'il dispose de la capacité financière, technique et managériale à exécuter). Cela signifie que le MVP doit être accompagné d'une structure de coûts d'ordre de grandeur approximatif (ROM) que l'entreprise peut défendre sous examen, d'un code CAGE et d'un enregistrement SAM.gov, et d'au moins une référence de performance passée -- même provenant d'un programme commercial ou d'une nation alliée -- qui démontre que l'entreprise a fourni un travail comparable. Comprendre le flux complet de l'appel d'offres au contrat aide les startups à préparer cette documentation avant qu'elle ne soit demandée, plutôt que de l'assembler dans l'urgence sous une date limite de réponse de 72 heures.

Le gestionnaire de programme doit confirmer que la technologie répond à une lacune de capacité documentée et que la charge d'intégration pour le gouvernement est gérable. Un MVP qui oblige le bureau de programme à modifier les systèmes C2 existants, à recycler les populations d'opérateurs ou à maintenir deux pipelines de données parallèles ajoute un coût de transition que le gestionnaire de programme doit justifier auprès des autorités supérieures. Les MVP les plus lisibles en termes d'acquisition se connectent aux normes de données existantes (CoT, STANAG, Link 16, NIEM) sans nécessiter de middleware que le gouvernement doit financer et maintenir séparément. Chaque dépendance d'intégration qu'une startup supprime de son MVP réduit le coût de friction que le bureau de programme doit absorber pour défendre le produit.

Délais d'accréditation de sécurité et moyens de les raccourcir

L'accréditation de sécurité -- obtenir une autorisation d'exploitation (ATO) dans le cadre du Cadre de gestion des risques (RMF) du DoD -- est l'élément de calendrier le plus constamment sous-estimé dans le plan d'acquisition d'une startup de défense. Les candidats à une première ATO budgétisent systématiquement 6 mois et arrivent au mois 18 encore en attente de la signature de l'autorité d'accréditation. Les retards ne surviennent pas parce que le produit est peu sécurisé ; ils surviennent parce que la documentation de contrôle est incomplète, le périmètre du système est mal défini, ou l'organisation d'évaluation n'a pas la bande passante pour planifier l'évaluation de sécurité avant des mois après la soumission du dossier de documentation.

Les ATO les plus rapides sont construites sur des contrôles hérités d'une base d'hébergement pré-autorisée. Si le produit fonctionne sur un environnement d'infrastructure en tant que service qui détient déjà une autorisation provisoire DoD Niveau d'impact 2 ou Niveau d'impact 4 -- AWS GovCloud East, Azure Government ou équivalent -- la startup hérite d'une partie substantielle de l'ensemble de contrôles NIST SP 800-53 du fournisseur de services cloud à partir de son package d'autorisation existant. L'évaluation de la startup couvre alors uniquement les contrôles qui ne sont pas hérités : contrôles au niveau de l'application, gestion de la configuration, contrôle d'accès au niveau logiciel et contrôles de superposition spécifiques au niveau de classification des données. Un produit natif cloud bien délimité peut réduire son ensemble de contrôles de mise en œuvre autonome de la base complète de 325 contrôles NIST 800-53 Rev 5 à 80 à 120 contrôles spécifiques à l'application, réduisant proportionnellement la durée de l'évaluation.

Le deuxième levier d'accélération est la discipline documentaire dès le premier jour du développement du produit. Le RMF exige un Plan de sécurité du système (SSP) qui décrit comment chaque contrôle applicable est mis en œuvre. Écrire rétrospectivement un SSP pour un produit construit sans documentation d'architecture de sécurité est lent et sujet aux erreurs ; l'écrire au fur et à mesure que le produit est construit -- avec des pipelines DevSecOps qui produisent des preuves de conformité continues -- réduit le SSP à une tâche éditoriale plutôt qu'à une reconstruction forensique. Les startups qui instrumentent leurs pipelines CI/CD avec des preuves de contrôle au format OSCAL et une analyse de conformité automatisée peuvent présenter à un évaluateur des packages de preuves lisibles par machine qui compriment la phase de planification de l'évaluation de semaines à jours.

Trouver le champion du bureau de programme : les relations avant les propositions

Aucune voie d'acquisition ne produit un Programme officiel sans un employé gouvernemental prêt à défendre la technologie à l'intérieur du bureau de programme lorsque le fournisseur n'est pas présent. Cette personne -- le champion -- ne se trouve pas uniquement par le biais de soumissions de propositions ou de participations aux journées industrie. Les champions se cultivent grâce à un engagement persistant et techniquement crédible sur 12 à 24 mois qui démontre que la startup comprend le problème opérationnel aussi bien que tout titulaire de contrat.

La voie la plus fiable pour identifier un champion passe par les utilisateurs opérationnels plutôt que par les bureaux d'acquisition. Un gestionnaire de programme qui reçoit des retours positifs constants d'utilisateurs finaux en uniforme qui ont utilisé le produit -- même dans le cadre d'une évaluation non officielle ou d'exercices -- est beaucoup plus motivé à défendre une ligne budgétaire que celui qui n'a lu qu'un document de présentation de capacité. Cela signifie que les startups doivent investir dans l'accès aux exercices opérationnels, aux jeux de guerre et aux événements de coalition où leur technologie peut être testée par de véritables opérateurs, même sans véhicule contractuel formel. Les boucles de rétroaction de ces points de contact génèrent les endorsements d'opérateurs que les gestionnaires de programme utilisent pour justifier les demandes de nouveau départ auprès des responsables du programme.

Acquisition en coalition et auprès de l'OTAN : couches supplémentaires et préparation

Une startup de défense qui a prouvé son produit sur un marché national se trouve face à un ensemble structurellement distinct d'exigences lorsqu'elle poursuit l'acquisition en coalition ou auprès de l'OTAN. La technologie peut être identique, mais les exigences juridiques, de sécurité et d'interopérabilité se multiplient avec chaque nation supplémentaire. Les entreprises qui abordent l'acquisition en coalition comme une simple expansion géographique de leur stratégie contractuelle existante sous-estiment systématiquement la préparation requise et perdent du temps au moment précis où leur avantage de premier entrant est le plus précieux.

Le contrôle des exportations est la première contrainte à résoudre. Les logiciels ou matériels d'origine américaine à application de défense sont soumis aux contrôles du Règlement international sur le trafic d'armes (ITAR) ou du Règlement sur l'administration des exportations (EAR). Une startup qui n'a pas déterminé le Numéro de classification du contrôle des exportations (ECCN) de son produit et obtenu les licences requises avant de poursuivre un bureau de programme britannique, allemand ou finlandais crée une exposition juridique pour elle-même et pour la contrepartie gouvernementale étrangère. L'analyse de la classification à l'exportation doit être achevée avant la première réunion avec un bureau de programme étranger, et non après réception d'une lettre d'intérêt.

Pour l'acquisition à financement commun de l'OTAN via l'Agence de soutien et d'acquisition de l'OTAN (NSPA), le produit doit satisfaire à la fois les exigences de sécurité de la nation acquéreuse et les politiques de sécurité applicables de l'OTAN. Cela introduit une voie de double accréditation -- ATO nationale plus accréditation OTAN -- qui peut se dérouler en parallèle mais nécessite une coordination entre deux structures de gestion de la sécurité qui ne partagent pas les formats de documentation ni les calendriers d'évaluation. Les startups entrant dans cet espace doivent déterminer si leur architecture prend en charge des instances nationales séparées ou un déploiement multi-locataires avec ségrégation des données renforcée par chiffrement, car la réponse détermine si un seul package d'accréditation peut être adapté entre les nations ou si des packages séparés doivent être construits pour chacune. Le calendrier de passation de marchés de la NSPA pour un contrat de capacité de nouveau départ s'étend de 24 à 36 mois de l'exigence initiale à l'attribution, ce qui doit être intégré dans la planification des flux de trésorerie dès le départ.

De la preuve de concept au déploiement complet : gérer le risque de transition

Le risque de transition -- le risque qu'une technologie ayant réussi un pilote échoue à atteindre l'échelle opérationnelle -- est la principale raison pour laquelle les bureaux de programme hésitent à s'engager sur un Programme officiel avec un fournisseur startup. Cette hésitation n'est pas irrationnelle. Les bureaux de programme qui ont investi dans des programmes de nouveau départ avec de petits fournisseurs ont connu des discontinuités technologiques lorsque le fournisseur a manqué de ressources, des pivots de produit qui ont invalidé l'évaluation de capacité initiale, et des défaillances d'intégration qui n'ont émergé que lors du déploiement à grande échelle. Aborder explicitement ces risques dans les documents de planification de transition est plus efficace qu'affirmer la stabilité dans les documents de présentation de capacité.

La déclaration de droits sur les données est le document le plus opérationnellement significatif d'un plan de transition. En vertu du DFARS 252.227-7013, le gouvernement a droit aux droits à usage gouvernemental sur les données techniques développées avec un financement mixte -- mais la portée de ces droits dépend de la façon dont la startup a documenté son investissement en recherche et développement indépendant (IR&D) au moment du développement. Une startup qui n'a pas maintenu des archives contemporaines des composants du produit développés avec des fonds d'IR&D propres à l'entreprise par rapport aux fonds gouvernementaux aura du mal à faire valoir les droits limités auxquels elle a droit, et peut accidentellement accorder au gouvernement des droits sur les données plus larges que prévu. À l'inverse, une startup qui fait valoir des droits limités trop larges sur un développement financé par le gouvernement créera un litige contractuel qui retardera la transition. L'approche correcte consiste à maintenir un programme d'IR&D financé avec des dépenses documentées, à faire valoir des droits de financement mixte de manière étroite et précise, et à négocier une structure de licence qui donne au gouvernement un accès suffisant aux données pour la remise en concurrence à la fin de la période contractuelle sans transférer la propriété intellectuelle centrale de la startup.

La planification du maintien en condition opérationnelle (MCO) reçoit moins d'attention qu'elle ne le mérite pendant la phase pilote, et l'écart se manifeste lors de la transition. Un Programme officiel exige non seulement la capacité, mais une structure de soutien définie : une analyse de soutien logistique (ou équivalent pour les logiciels), un plan de soutien logiciel, une stratégie de MCO en cybersécurité, et -- pour le matériel déployé -- une chaîne de pièces de rechange et de maintenance. Les startups qui présentent ces artefacts au bureau de programme avant d'être sollicitées démontrent une maturité institutionnelle qui les distingue des concurrents qui traitent le MCO comme un problème post-attribution. L'utilisateur opérationnel qui a défendu le pilote sera tenu responsable de la structure de soutien qui s'ensuit. Réduire cette charge de responsabilité est l'un des moyens les plus efficaces de renforcer la relation avec le champion tout au long de la phase de transition.