Renseignement BTW Media

Résumé

Le Secure Border Initiative Network, ou SBInet, était le volet technologique d'un programme plus large du Département de la sécurité intérieure annoncé en 2005. Les douanes et la protection des frontières (CBP) avaient pour objectif d'intégrer des tours, des radars, des caméras, des capteurs au sol sans surveillance, des communications et un logiciel de commandement en une image opérationnelle commune pour le personnel de la patrouille frontalière.
En septembre 2006, la CBP a sélectionné Boeing comme intégrateur principal du système. L'acquisition dépendait d'un bureau de programme gouvernemental capable de définir les besoins opérationnels, de contrôler les exigences, de vérifier les progrès du contractant et de décider quand un système intégré était prêt pour une utilisation sur le terrain et son extension.
Le projet 28, un prototype d'environ 20,6 millions de dollars couvrant 28 miles dans le secteur de Tucson en Arizona, a exposé la différence entre l'équipement livré et la capacité prouvée. Le gouvernement l'a accepté en février 2008, huit mois de retard, après des problèmes d'intégration et des actions correctives. Des responsables et des agents ont signalé des avantages limités ainsi que des solutions de contournement opérationnelles persistantes.
Le GAO et le Bureau de l'inspecteur général du DHS ont constaté à plusieurs reprises des faiblesses dans les exigences, les tests, les bases de coûts et de calendrier, la gestion des risques, la supervision des contractants et les effectifs gouvernementaux. Il ne s'agissait pas de défauts administratifs distincts. Ensemble, ils ont affaibli les preuves nécessaires pour relier l'activité d'acquisition à la valeur opérationnelle.
En 2010, le premier bloc proposé de SBInet avait réduit sa portée géographique et ses attentes de performance, tandis que son calendrier et sa valeur sur le cycle de vie restaient incertains. Le GAO a rapporté que le programme manquait d'un calendrier principal intégré fiable, d'une estimation fiable du coût du cycle de vie et d'une relation démontrée entre les avantages attendus et les coûts.
En janvier 2011, le DHS a mis fin à SBInet tel qu'il avait été conçu à l'origine et s'est orienté vers un plan technologique adapté au terrain et aux besoins opérationnels. Cette décision ne signifiait pas que toute technologie de surveillance frontalière était inutile, ni n'effaçait la capacité limitée déjà déployée sur 53 miles en Arizona.
La leçon de responsabilité de SBInet est qu'un mur de capteurs n'est pas une capacité publique tant que la détection, la classification, les communications, la réponse des opérateurs, la maintenance et les coûts ne peuvent être démontrés ensemble. Le contrôle pratique appartient aux institutions qui peuvent exiger cette preuve, arrêter l'expansion lorsqu'elle est absente et préserver les preuves derrière les deux décisions.

Un écran de surveillance peut cacher la partie la plus difficile

L'image au centre d'une clôture virtuelle est trompeusement simple. Un radar détecte un mouvement. Une caméra se tourne vers une cible. Un logiciel place une icône sur une carte. Un opérateur voit l'événement et envoie un agent. Comparé à la construction d'une barrière physique sur un terrain difficile, l'écran peut sembler une réponse flexible et presque automatique.

Mais l'écran est la dernière couche visible d'un système beaucoup plus vaste. Un radar doit distinguer un mouvement pertinent des animaux, des conditions météorologiques et du fouillis. Une caméra doit fournir une imagerie utilisable à la distance et dans les conditions d'éclairage promises. Les tours ont besoin d'alimentation, de communications et de maintenance. Le logiciel doit combiner les observations sans créer de délai ou de confusion intolérables. La carte doit refléter les positions avec précision. Les agents ont besoin d'accès à l'information, de confiance en celle-ci et de procédures pour décider de la réponse appropriée.

SBInet a essayé de transformer ces dépendances en une plateforme de surveillance frontalière. Le programme n'achetait pas simplement des caméras ou installait des tours. Il acquérait une revendication opérationnelle intégrée: que les capteurs, les communications, les logiciels et les flux de travail de la patrouille frontalière créeraient une meilleure connaissance de la situation sur de vastes zones.

Cette revendication ne pouvait être vraie que par des preuves. La livraison de matériel était une preuve de livraison de matériel. Une version logicielle achevée était une preuve que le code existait. Un jalon du contractant montrait qu'un événement contractuel avait eu lieu. Aucun de ces faits ne prouvait à lui seul que le système pouvait détecter, identifier et classer un élément d'intérêt sur un terrain réel, communiquer l'observation, aider un opérateur à prendre une décision et rester disponible assez longtemps pour être utile.

Cette distinction explique pourquoi SBInet appartient à une série sur le risque et la responsabilité. L'échec central n'était pas que chaque appareil ait échoué ou qu'aucun agent n'ait reçu un avantage. C'était que l'ambition du programme a constamment dépassé la capacité du gouvernement à produire des preuves fiables et prêtes à la décision concernant les performances intégrées, les coûts, le calendrier et l'état de préparation à la mise à l'échelle.

SBInet a commencé comme une promesse d'intégration de systèmes

Le DHS a établi l'initiative plus large Secure Border Initiative en novembre 2005. SBInet était l'effort technologique au sein de cette initiative, géré par les douanes et la protection des frontières. Selon le GAO, la solution prévue comprenait des capteurs, des communications, des technologies de l'information, des infrastructures tactiques et des capacités de commandement et de contrôle. Elle visait également à développer une image opérationnelle commune pouvant fournir des données uniformes dans les centres de commandement et soutenir l'interopérabilité avec des organisations extérieures au DHS.

Cette description est importante car elle définit l'unité de responsabilité. Si le besoin public était seulement un radar, le gouvernement pourrait juger si le radar répondait à ses spécifications. L'unité de SBInet était le système: un mélange de personnel, de réponse rapide, d'infrastructure et de technologie visant à soutenir le contrôle opérationnel.

En septembre 2006, la CBP a attribué à Boeing un contrat d'intégrateur principal de systèmes à livraison indéterminée et quantité indéterminée. Le contrat avait une période de base de trois ans et trois options d'un an. Les ordres de mission finançaient des travaux spécifiques, y compris la gestion de programme, le déploiement de prototypes, les logiciels d'image opérationnelle commune, la maintenance et les activités de déploiement ultérieures.

L'utilisation d'un intégrateur principal peut être raisonnable pour un système complexe. Un contractant peut coordonner les interfaces entre de nombreux fournisseurs et composants. Cet arrangement ne transfère pas la responsabilité publique. Le gouvernement doit toujours définir les résultats de la mission, conserver les connaissances techniques, contrôler les exigences, évaluer les informations sur les coûts et le calendrier, superviser le travail des sous-traitants et décider si le système livré est acceptable.

Les premiers enregistrements de surveillance montrent à quel point ce rôle était exigeant. En février 2007, le GAO a déclaré que le plan de dépenses pour l'exercice 2007 satisfaisait à quatre conditions législatives, en satisfaisait partiellement quatre et n'en satisfaisait pas une. Le plan contenait des informations générales sur les coûts et les jalons mais manquait de détails suffisants pour soutenir la mesure et la responsabilité. Il ne reliait pas correctement les activités individuelles aux objectifs stratégiques, et les processus clés de gestion des acquisitions n'étaient pas entièrement définis et mis en œuvre.

Le problème était donc visible avant le déploiement national. SBInet tentait une acquisition multiple simultanée alors que la machinerie de planification, d'exigences, de risque et de contrôle des performances du gouvernement était encore en construction.

Une estimation de 7,6 milliards de dollars n'était pas encore une carte fiable

Le dossier de dépenses de 2007 illustre la différence entre un grand nombre et une base de référence fiable. Le DHS estimait que l'achèvement de la phase d'acquisition pour la frontière sud-ouest coûterait 7,6 milliards de dollars pour les exercices 2007 à 2011. Il discutait d'environ 790 millions de dollars pour le secteur de Tucson et 260 millions de dollars pour le secteur de Yuma.

Le GAO n'a pas traité ces chiffres comme auto-validants. Le plan manquait de détails suffisants sur les activités, les jalons et les coûts. Il ne précisait pas comment l'allocation de Tucson serait répartie entre les clôtures, les capteurs au sol, les radars, les caméras, les tours fixes et les tours mobiles. Il ne fournissait pas de dates de mise en œuvre spécifiques pour ces éléments et omettait les activités et les coûts correspondants pour la frontière nord.

Une base de référence doit permettre à quelqu'un en dehors de l'équipe du projet de demander si la réalité progresse comme promis. Quelle capacité est financée? Quand est-elle due? Quelle dépendance pourrait déplacer la date? Quel est le coût de la main-d'œuvre gouvernementale ainsi que du contractant? Quel résultat démontrera que la dépense a amélioré la mission?

Sans ces liens, un programme peut signaler que de l'argent a été engagé et que des tâches sont actives, tout en laissant le décideur incapable de juger si une capacité utile se rapproche. Le plan devient un compte rendu de l'activité, pas un instrument de contrôle.

Le GAO a également remis en question le maximum déclaré du contrat. Le DHS considérait « 6 000 miles de frontière américaine sécurisée » comme une quantité maximale adéquate pour le véhicule à quantité indéterminée. Le GAO a fait valoir qu'il s'agissait d'un résultat, pas d'une limite calculable sur les fournitures, les services ou les dollars. Le désaccord a exposé un problème de responsabilité plus large: une aspiration n'est pas un plafond d'acquisition mesurable.

Le rapport recommandait des engagements explicites et mesurables pour les capacités, les calendriers, les coûts et les avantages; une limite contractuelle exprimée en unités ou en dollars; et une reconsidération de la simultanéité. Le DHS a accepté la première et la troisième recommandation, mais a contesté le maximum contractuel. Quelle que soit l'interprétation juridique, le point opérationnel demeurait: le gouvernement avait besoin d'une description bornée et vérifiable de ce qu'il achetait.

Le projet 28 a rendu visible l'échec de l'intégration

Le projet 28 a été le premier test vivant du concept de clôture virtuelle. L'ordre de mission couvrait 28 miles dans le secteur de Tucson et était évalué à environ 20,6 millions de dollars. Son objectif était de fournir des capacités de détection, d'identification et de classification à l'aide de radars, de caméras, de capteurs, d'ordinateurs, de communications et de logiciels d'image opérationnelle commune.

Les composants ont été déployés, mais le système n'est pas devenu opérationnel selon le calendrier initial. Le GAO a signalé des problèmes d'intégration logicielle, notamment des retards dans l'affichage des informations radar dans les centres de commandement. Les exigences n'avaient pas été suffisamment définies et les utilisateurs n'avaient pas été suffisamment impliqués dans leur développement. Le matériel pouvait être présent dans le désert tandis que la chaîne opérationnelle restait incomplète.

En août 2007, la CBP a informé Boeing qu'elle n'accepterait pas le projet tant que les problèmes spécifiés ne seraient pas corrigés. Boeing a soumis des plans d'actions correctives. Le DHS a accepté conditionnellement le projet 28 en décembre 2007 et a exigé une analyse supplémentaire de la qualité vidéo, des données radar et du timing des composants. L'acceptation finale a suivi le 22 février 2008, huit mois après la date prévue.

L'acceptation finale ne signifiait pas que le système répondait à toutes les attentes opérationnelles. Le GAO a noté que les responsables du programme considéraient les exigences contractuelles comme remplies tout en disant aussi que le projet 28 n'avait pas pleinement répondu à leurs attentes. La patrouille frontalière a signalé des limitations persistantes, notamment la résolution de l'image de la caméra à des distances plus longues. Les tests opérationnels futurs devaient informer le développement ultérieur plutôt que de refaire substantiellement le prototype accepté.

Ces faits ne doivent pas être réduits à l'affirmation que le projet 28 n'a rien apporté. Il a fonctionné le long de la zone de 28 miles. Des agents ont dit plus tard au GAO qu'il avait amélioré certaines capacités opérationnelles. Les preuves ont également montré des solutions de contournement impliquant la force du signal sans fil, le contrôle à distance de la caméra et la sensibilité du radar.

La question de responsabilité est plus tranchée qu'un succès ou un échec en tant que slogan. Qu'a certifié l'acceptation? Si l'acceptation contractuelle signifiait qu'un ensemble défini de livrables avait été fourni, les décideurs avaient toujours besoin de preuves distinctes concernant l'adéquation opérationnelle, les besoins des utilisateurs, la maintenabilité et l'état de préparation à la réplication. Un événement d'acceptation signé pouvait clore une obligation tout en laissant la décision de mise à l'échelle non résolue.

L'acceptation et la valeur opérationnelle sont des portes différentes

Les acquisitions publiques utilisent souvent le mot acceptation comme s'il s'agissait d'un verdict universel. En pratique, plusieurs portes peuvent porter cette étiquette. Un gouvernement peut accepter une livraison parce qu'un contractant a satisfait à des critères négociés. Une organisation de test peut constater qu'un système a achevé un événement prévu. Une unité opérationnelle peut décider que le système est utile dans des conditions spécifiées. Un département peut déterminer que la capacité est suffisamment rentable pour être étendue.

SBInet avait besoin que ces jugements restent distincts. Le projet 28 a montré pourquoi. Son acceptation finale reflétait une relation contractuelle après une action corrective. Elle n'établissait pas que le prototype était la conception correcte pour toute la frontière sud-ouest, que chaque préoccupation de terrain avait été résolue ou que la même architecture serait économique sur un terrain différent.

Le programme prévoyait également des générations ultérieures de technologie qui remplaceraient une grande partie de l'équipement du projet 28. Cela faisait du prototype une source de leçons ainsi qu'une capacité limitée. Mais les leçons apprises ne sont précieuses que lorsqu'elles sont capturées dans les exigences, les plans de test, les contrôles d'interface, les estimations de coûts et les décisions de déploiement.

Une acquisition faible traite un prototype comme une démonstration que l'élan doit continuer. Une acquisition contrôlée demande quelles hypothèses le prototype a réfutées. Les composants commerciaux étaient-ils suffisamment matures? Le logiciel pouvait-il traiter les données des capteurs à la vitesse opérationnelle? La couverture des communications correspondait-elle au concept? Les interfaces opérateur étaient-elles utilisables? Combien de défauts sont apparus sous des charges de travail réalistes? Quelle charge de maintenance l'expérience de terrain a-t-elle révélée?

Le gouvernement doit également se protéger contre le déplacement des critères. Si les tests d'acceptation sont révisés principalement pour s'adapter aux performances actuelles du système, le test cesse de représenter le besoin initial de la mission. Inversement, refuser tout changement serait tout aussi insensé si les exigences initiales étaient inabordables, invérifiables ou sans rapport avec les opérations de terrain.

Le contrôle est la traçabilité. Chaque critère modifié doit montrer la justification de la mission, les preuves techniques, l'effet sur les coûts et le calendrier, l'autorité d'approbation et l'effet sur les résultats des utilisateurs. Sans cet enregistrement, les responsables du programme ne peuvent pas distinguer une adaptation disciplinée d'une redéfinition progressive du succès.

Les exigences étaient l'architecture de la responsabilité

Les exigences peuvent ressembler à de la paperasse technique, mais dans SBInet, elles allouaient la responsabilité. Les exigences opérationnelles décrivaient ce que la patrouille frontalière devait accomplir. Les exigences du système traduisaient ces besoins en caractéristiques de performance et fonctionnelles. Les exigences des composants concernaient les caméras, les radars, les communications et d'autres éléments. Les exigences logicielles et de conception régissaient la façon dont ces éléments interagiraient.

Le GAO a constaté que le programme avait défini un processus de développement et de gestion des exigences mais ne l'avait pas appliqué de manière cohérente. Un examen indépendant du DHS a révélé que certaines exigences opérationnelles étaient inabordables et invérifiables. Parce que les exigences de niveau inférieur découlaient de ces déclarations opérationnelles, l'incertitude au sommet pouvait se propager à travers la conception du système, les cas de test et le travail du contractant.

Le GAO a recommandé de fixer les exigences de base avant la conception et le développement, de les analyser pour leur exhaustivité, leur faisabilité et leur vérifiabilité, et de les relier vers le haut aux besoins de la mission et vers le bas aux composants et aux tests. Ce ne sont pas des étapes cérémonielles. Elles créent une chaîne de traçabilité pour la revendication de capacité.

Considérez une exigence de caméra. Une spécification de portée optique est incomplète sans hypothèses sur le terrain, l'atmosphère, la taille de la cible, l'éclairage, la stabilisation et la façon dont un opérateur utilisera l'image. Une probabilité de détection est incomplète sans définir l'ensemble de cibles pertinent, les conditions de test et la charge de fausses alarmes. Une exigence de communication est incomplète si elle ignore où les véhicules se déplacent et combien de temps prend la connexion ou la reconnexion.

Les utilisateurs de terrain sont essentiels car ils savent où la performance abstraite rencontre la friction opérationnelle. Il ne faut pas leur demander simplement si un écran fini semble utile. Ils ont besoin d'une influence structurée avant que les décisions de conception ne se figent: scénarios, missions prioritaires, délais acceptables, charge de travail, conditions environnementales et quelles informations soutiennent une décision de réponse.

Les exigences forment donc une architecture de responsabilité publique. Elles énoncent ce que l'agence considère comme nécessaire, ce que le contractant doit livrer, ce que les testeurs doivent prouver et ce que les dirigeants autorisent lorsqu'ils approuvent un changement. Lorsque cette architecture est instable, chaque mesure ultérieure (calendrier, coûts, fermeture de défauts et acceptation) devient plus difficile à interpréter.

Les tests devaient prouver toute la chaîne

L'approche de test de SBInet envisageait plusieurs niveaux. La qualification des composants pouvait montrer si un équipement individuel répondait aux caractéristiques spécifiées. Les tests d'intégration pouvaient démontrer les interfaces et l'interopérabilité. La qualification du système pouvait tester la conception assemblée. Les tests d'acceptation du système pouvaient soutenir la décision contractuelle du gouvernement. Les tests et évaluations opérationnels pouvaient examiner l'efficacité et l'adéquation dans l'environnement où la patrouille frontalière utiliserait le système.

Le GAO a constaté que les tests n'étaient pas gérés efficacement. Le programme avait commencé à intégrer des composants avant de tester individuellement les composants réels destinés aux premiers sites de déploiement. Une stratégie de gestion des tests avait été rédigée mais pas finalisée ni approuvée. Elle manquait d'une définition claire des rôles, d'un calendrier principal de haut niveau et de suffisamment de détails sur les jalons et les métriques pour guider les tests du projet.

L'ordre compte. Si un composant instable entre en intégration, les ingénieurs peuvent passer du temps à diagnostiquer un comportement du système qui provient d'une pièce non qualifiée. Si les interfaces ne sont pas contrôlées, un test de composant réussi en dit peu sur le système combiné. Si les utilisateurs opérationnels n'arrivent qu'après la fixation des critères d'acceptation, le programme peut prouver la mauvaise performance.

Le GAO a signalé plus tard environ 1 300 défauts trouvés entre mars 2008 et juillet 2009. De nouveaux défauts apparaissaient généralement plus rapidement qu'ils n'étaient résolus, et beaucoup manquaient de priorité de résolution. Le seul nombre ne prouve pas que chaque défaut était grave. La tendance et le triage incomplet ont miné la confiance dans le fait que le système mûrissait vers le déploiement.

Le dossier officiel a également décrit des préoccupations selon lesquelles certaines modifications des cas et procédures de test semblaient orientées vers la réussite du test plutôt que vers la qualification du système. C'est une limite de gouvernance critique. Un programme doit mettre à jour un test lorsque des preuves montrent que le test est invalide, redondant ou déconnecté des besoins de la mission. Il ne doit pas abaisser le fardeau de la preuve simplement parce que la conception actuelle ne peut pas réussir.

Les tests sont l'endroit où les promesses publiques deviennent falsifiables. Le contrôle le plus fort aurait relié chaque exigence opérationnelle à un cas de test, une condition de test, un résultat mesuré, un enregistrement de défaut, une disposition et une autorité d'approbation. Ce registre aurait permis de voir non seulement si un événement a réussi, mais ce que la réussite a réellement prouvé.

Le terrain a signalé à la fois des avantages et des solutions de contournement

L'histoire de SBInet est déformée si l'utilisation limitée est effacée. En 2008 et 2009, des agents de la patrouille frontalière dans le secteur de Tucson ont dit au GAO que le projet 28 avait amélioré certains aspects de leur capacité opérationnelle. Le système était utilisé pendant que le programme attendait les déploiements ultérieurs de SBInet.

Les agents ont également décrit des solutions de contournement persistantes. Ils avaient des problèmes pour trouver une force de signal sans fil fiable, contrôler les caméras à distance et ajuster la sensibilité du radar. Le GAO a observé une utilisation limitée des terminaux de données mobiles installés dans les véhicules. Selon la force du signal, la connexion pouvait prendre beaucoup de temps et les connexions pouvaient être perdues à plusieurs reprises pendant un quart de travail. Les opérateurs de l'image opérationnelle commune relayaient parfois les informations à la place.

Ces preuves mixtes sont plus utiles qu'un verdict binaire. Un système peut fournir une valeur locale tout en restant inapproprié comme modèle pour une expansion nationale. Il peut aider un flux de travail et en alourdir un autre. Il peut fonctionner sous certaines conditions environnementales et se dégrader sous d'autres.

Les retours opérationnels doivent être structurés autour de cette variation. Quelles fonctions ont été utilisées? À quelle fréquence? Dans quelles conditions? Que faisaient les agents lorsque la technologie était indisponible? Le système a-t-il réduit ou augmenté la charge de travail des opérateurs? Les alertes étaient-elles fiables? À quelle vitesse les mainteneurs pouvaient-ils restaurer l'équipement défaillant? Une solution de contournement préservait-elle la mission, et à quel coût en personnel?

La tentation dans un programme en difficulté est d'utiliser toute déclaration de terrain positive comme preuve que l'expansion est justifiée, ou toute plainte comme preuve que le système est sans valeur. Aucune des deux inférences n'est responsable. Les preuves de terrain doivent être liées à des bénéfices de mission définis et comparées aux coûts, aux alternatives et aux performances de l'équipement existant.

L'expérience de SBInet suggère une norme par étapes. Un déploiement limité peut être précieux comme découverte. L'expansion devrait exiger des preuves plus solides: performances reproductibles sur un terrain représentatif, tendances des défauts contrôlées, communications utilisables, maintenabilité, opérateurs formés et un bénéfice quantifié par rapport aux systèmes qu'il remplacerait ou compléterait.

La simultanéité a transformé les inconnues en engagements de calendrier

Les premiers plans de SBInet utilisaient des ordres de mission et des activités connexes simultanés. La simultanéité peut accélérer la livraison lorsque les interfaces sont stables et les risques compris. Elle peut également multiplier les reprises lorsque les exigences, les conceptions et les tests changent encore.

Le GAO a averti en 2007 que le programme n'avait pas fourni de preuves montrant qu'il avait identifié les dépendances entre les activités simultanées et gérait activement le risque associé. Dans le même temps, le bureau du programme a déclaré que la mise en œuvre accélérée avait été prioritaire sur la définition et la mise en œuvre complètes de certains processus de gestion des acquisitions.

Ce compromis est courant dans les programmes publics urgents. Les dirigeants craignent que le processus ne retarde la capacité. Pourtant, une exigence, une revue d'interface ou un plan de test n'a pas de valeur parce qu'il retarde le travail. Il a de la valeur s'il empêche l'organisation de mettre à l'échelle une hypothèse non prouvée.

Le projet 28 a rendu la chaîne de dépendances concrète. L'intégration logicielle a retardé le prototype. Les leçons du prototype étaient censées informer les blocs ultérieurs. Mais le travail sur les exigences, conceptions, tours et systèmes de commandement ultérieurs ne pouvait pas simplement s'arrêter sans conséquences sur le calendrier. Plus le travail avançait avant que la leçon ne soit stable, plus la correction pouvait devenir coûteuse.

Un registre de simultanéité aurait rendu le risque visible. Pour chaque activité autorisée avant que les preuves du prédécesseur ne soient complètes, le programme pouvait enregistrer la preuve manquante, la raison de la poursuite, l'exposition maximale, un plan de retour en arrière et la date de la décision. Les dirigeants sauraient alors si l'accélération était un risque limité ou une accumulation d'engagements irréversibles.

Le problème n'était pas l'urgence elle-même. La sécurité des frontières était une priorité déclarée et l'équipement existant avait des limitations. Le problème était de savoir si l'urgence modifiait la norme de preuve ou seulement la vitesse à laquelle les preuves devaient être produites. Si la norme baisse, le programme peut sembler plus rapide jusqu'à ce que l'intégration et les reprises consomment le temps gagné.

L'échelle a rétréci tandis que la revendication du programme restait grande

SBInet a été décrit comme une solution frontalière complète, mais son déploiement prévu a changé à plusieurs reprises. En 2009, le GAO a documenté des années de retard et un périmètre à court terme qui se réduisait. Le projet 28 couvrait 28 miles. Les déploiements prévus du bloc 1 à Tucson-1 et Ajo-1 couvraient ensemble environ 53 miles.

Les plans antérieurs avaient envisagé un déploiement initial à travers les secteurs de Tucson, Yuma et El Paso, soit environ 655 miles. Une base de référence ultérieure a réduit ce périmètre initial à Tucson et Yuma, soit environ 387 miles. Les plans pour les incréments suivants restaient flous.

La réduction de la portée peut être prudente. Un programme ne doit pas maintenir un périmètre irréaliste simplement pour préserver une ancienne promesse. Mais la responsabilité exige que le coût, le calendrier et la promesse de bénéfice changent avec la portée.

En 2010, le GAO a décrit le premier bloc comme coûtant environ 1,3 milliard de dollars. Il a constaté que les capacités prévues continuaient de diminuer. Les seuils de performance ont été assouplis. Les seuils de détection et d'identification qui avaient été fixés à 95 % ont été réduits à 70 %, tandis que le seuil de disponibilité opérationnelle est passé de 95 % à 85 %.

Le GAO a noté que la définition résultante pouvait permettre une performance agrégée acceptable même si des catégories d'identification particulières performaient en dessous de 50 %. La signification opérationnelle exacte dépendait de la façon dont les mesures étaient construites et appliquées, mais le point de gouvernance est clair: un seuil de performance est une déclaration sur ce que l'agence est prête à appeler acceptable.

Changer un seuil peut être justifié par la réalité technique, le coût ou une meilleure compréhension de la mission. Le dossier de décision doit expliquer quel besoin de l'utilisateur reste satisfait, quel risque est accepté et si l'estimation des bénéfices tient toujours. Sinon, le programme peut préserver l'étiquette « Bloc 1 » tout en livrant une promesse matériellement différente.

Les contrôles de coûts et de calendrier n'ont pas produit de prévisions fiables

En 2010, le GAO et l'IG du DHS remettaient en question les contrôles derrière les déclarations de coûts et de calendrier de SBInet. Le GAO a évalué le calendrier principal intégré d'août 2009 par rapport à neuf pratiques reconnues et a trouvé une conformité substantielle avec seulement deux. Le calendrier ne capturait pas correctement toutes les activités, n'attribuait pas de ressources, n'identifiait pas de chemin critique, ne tenait pas compte d'une marge raisonnable ni n'analysait le risque de calendrier.

Un calendrier n'est pas fiable parce qu'il contient de nombreuses dates. Il est fiable lorsque les dépendances sont logiquement connectées et que les décideurs peuvent voir quel travail contrôle la date d'achèvement. Si un glissement de qualification de radar affecte l'intégration, la préparation des tests, le déploiement et la formation des opérateurs, cette relation doit être visible. Sans cela, une date d'achèvement déclarée est une agrégation de souhaits.

Le GAO a également constaté que l'estimation du coût du cycle de vie du bloc 1 ne répondait pas suffisamment aux caractéristiques d'une estimation fiable: complète, bien documentée, précise et crédible. Les exclusions et les hypothèses limitaient son utilité. L'estimation omettait ou ne traitait pas correctement l'effort gouvernemental, certaines opérations et maintenance, les coûts des systèmes existants, les logiciels, le soutien du programme et l'évolution future des blocs. Les risques associés à la maturité des composants commerciaux n'étaient pas entièrement reflétés.

L'IG du DHS a trouvé des problèmes de contrôle connexes. Les informations de base actuelles n'étaient pas toujours saisies dans le système de gestion de la valeur acquise, réduisant sa capacité à avertir des écarts de coûts et de calendrier. Le bureau du programme a fonctionné sans calendrier principal intégré approuvé pendant une partie de l'examen, et le personnel de surveillance des coûts et du calendrier était réduit.

Ces constatations n'étaient pas des prédictions que chaque dollar serait gaspillé. Elles montraient que les dirigeants manquaient de prévisions fiables. Les contrôles des coûts et du calendrier sont censés révéler les divergences suffisamment tôt pour changer de cap. Lorsque les bases de référence sont tardives, incomplètes ou instables, la direction apprend le problème après que les engagements ont déjà réduit les options.

La supervision des contractants nécessitait une autorité technique gouvernementale

SBInet dépendait fortement des contractants, de l'intégrateur principal du système au personnel de soutien au sein de l'organisation du programme. Les contractants ont apporté des compétences en ingénierie, en intégration et en gestion. Ils ont également créé un problème de contrôle si le personnel gouvernemental manquait de capacité à remettre en question les hypothèses, évaluer les livrables ou distinguer le soutien des contractants des décisions intrinsèquement gouvernementales.

L'avis de risque de l'IG du DHS de 2006 indiquait que le département manquait de capacité suffisante pour planifier, superviser et exécuter SBInet, administrer les contrats et contrôler les coûts et le calendrier. À ce stade, une grande partie des postes prévus étaient des contractants. Le rapport avertissait que les exigences opérationnelles avaient été reportées après la sélection de l'intégrateur et recommandait des plans pour renforcer la capacité de gestion et stabiliser les exigences.

Un rapport de l'IG de 2009 a constaté que des contractants de soutien avaient effectué ou approché des activités qui devraient rester sous un contrôle gouvernemental plus fort. Il recommandait de distinguer les rôles des contractants et des fédéraux et d'attribuer davantage de représentants techniques de l'officier contractant pour superviser les performances.

La préoccupation n'est pas que les contractants soient intrinsèquement peu fiables. Un contractant principal est responsable envers des incitations contractuelles, la portée et les critères d'acceptation. Seule l'agence publique peut concilier ces incitations avec la valeur de la mission, les choix politiques et la gestion des fonds alloués.

L'autorité technique gouvernementale doit être pratique, pas cérémonielle. Le personnel a besoin d'accès aux données sources, aux bases de référence des exigences, aux inventaires de défauts, aux procédures de test, à la logique du calendrier et aux hypothèses de coûts. Il a besoin de temps pour examiner les livrables en retard avant un jalon. Il a besoin du pouvoir de rejeter les preuves qui ne répondent pas à la norme.

SBInet illustre également pourquoi les effectifs seuls sont insuffisants. Le programme avait besoin d'ingénieurs systèmes, de gestionnaires de test, d'analystes de coûts, d'analystes de calendrier, de spécialistes des marchés et de représentants opérationnels avec des droits de décision clairement assignés. Si l'institution ne peut pas dire qui possède une interface, un changement de seuil ou une dérogation d'acceptation, l'intégrateur peut devenir l'auteur de facto des preuves publiques.

La gouvernance des jalons nécessitait des preuves d'entrée et de sortie

Le rapport de l'IG du DHS de 2010 sur les coûts et le calendrier s'est concentré sur une question apparemment procédurale avec de grandes conséquences: si les événements du programme avaient des critères d'entrée et de sortie documentés et si le gouvernement montrait pourquoi il acceptait les preuves.

Les revues majeures sont censées réduire l'incertitude. Une revue des exigences doit montrer que les besoins sont compris et traçables. Une revue de conception doit montrer que la solution est suffisamment mature pour la construction ou le codage. Une revue de préparation aux tests doit montrer que les procédures, les configurations et les environnements peuvent produire des résultats valides. Une revue de préparation opérationnelle doit montrer que les parties prenantes conviennent que le système peut entrer en service dans des conditions définies.

Si l'événement a lieu parce que le calendrier le dit, la revue devient du théâtre. Si les critères sont incomplets, les problèmes non résolus doivent être enregistrés avec les propriétaires, les délais et les décisions de risque. Si les dirigeants procèdent conditionnellement, la condition doit limiter les travaux pouvant commencer.

L'IG a recommandé que le programme documente l'examen et l'acceptation par le gouvernement des réalisations et des critères de l'événement, s'assure que les conditions d'entrée et de sortie étaient satisfaites, traite les problèmes ouverts et mette à jour les évaluations des risques avant les événements ultérieurs. La CBP a accepté tout en contestant certaines parties de la caractérisation par l'IG de décisions de déploiement particulières.

Ce désaccord lui-même démontre la valeur d'un dossier de preuves durable. Les auditeurs et les gestionnaires peuvent raisonnablement interpréter le risque différemment. Un dossier de décision complet doit permettre à un lecteur ultérieur de voir les critères, les preuves, les éléments non résolus, la justification de la poursuite et les limites imposées à la phase suivante.

Pour un programme technologique public, la gouvernance des jalons protège plus que le calendrier. Elle préserve la base de la responsabilité après les changements de direction, les renouvellements de contrat et les pressions politiques. Elle indique aux équipes futures si un système a progressé parce qu'il était prêt, parce que le risque était consciemment limité ou parce que l'élan a vaincu les contrôles.

L'évaluation de 2010 a changé la question de la décision

En janvier 2010, le secrétaire à la sécurité intérieure a lancé une évaluation à l'échelle du département de SBInet. La question n'était plus simplement de savoir comment rattraper le calendrier actuel. Le DHS a examiné si l'approche était la stratégie technologique de sécurité frontalière la plus efficace, efficiente et économique.

Le rapport du GAO de mai 2010 a renforcé cette question. Il a constaté une portée réduite, un calendrier peu fiable, une estimation du coût du cycle de vie peu fiable, des avantages attendus non identifiés et une mise en œuvre incohérente des processus de gestion du cycle de vie. Le GAO a recommandé de limiter les investissements supplémentaires au-delà des deux sites de déploiement actuels jusqu'à ce que le DHS dispose d'une base analytique défendable.

C'est un pivot important en matière de responsabilité. Les programmes répondent souvent aux difficultés en produisant une nouvelle date, un nouveau nom de bloc ou un seuil de performance révisé. Ces actions supposent que le concept sous-jacent reste justifié. L'évaluation de 2010 a rouvert le concept lui-même.

Une décision sur les alternatives nécessite une comparaison commune. Quel problème de mission doit être résolu dans chaque région? Quels systèmes existants contribuent? Quelles conditions de terrain et de population importent? Quelles technologies commerciales sont matures? Quels sont les coûts du cycle de vie, y compris le personnel gouvernemental et la maintenance? À quelle vitesse chaque option peut-elle produire un bénéfice mesurable?

L'analyse devait également éviter un faux choix entre SBInet et l'absence de technologie. Le DHS pouvait mettre fin à l'architecture unique tout en continuant à utiliser des caméras, des systèmes mobiles, l'imagerie thermique, des drones et d'autres outils de surveillance. La décision concernait le modèle d'acquisition et la conception intégrée, pas l'existence d'une mission frontalière.

En recadrant la question, l'évaluation a reconnu que la discipline de rétablissement signifie parfois s'arrêter. L'annulation n'est pas automatiquement une preuve de bonne gouvernance; elle peut arriver tard et laisser des coûts irrécupérables. Mais continuer un programme sans un dossier crédible de rapport coût-bénéfice ne récupérerait pas ces coûts irrécupérables. Cela augmenterait l'exposition.

L'annulation était une réinitialisation de la gouvernance, pas un effacement

En janvier 2011, le DHS a mis fin à SBInet tel qu'il avait été conçu à l'origine. Le département a déclaré que l'évaluation montrait que le programme ne pouvait pas atteindre son objectif initial en tant que solution technologique frontalière unique. Il s'est orienté vers un plan utilisant des technologies éprouvées adaptées au terrain, à la densité de population et aux besoins opérationnels.

Des contrôles ultérieurs ont résumé le dossier plus brutalement: retards importants et dépassements de coûts, technologie livrée dans deux zones de l'Arizona, et annulation parce que le programme ne répondait pas aux normes de viabilité et de rentabilité. Le GAO a considéré la décision d'abandonner l'approche originale comme une réponse à ses recommandations accumulées.

La décision n'a pas établi que chaque composant de SBInet était inutile. Des systèmes de surveillance avaient été déployés sur 53 miles, et le projet 28 avait fourni une capacité opérationnelle limitée avant son remplacement. L'annulation n'a pas non plus prouvé que les technologies successives seraient automatiquement efficaces.

La distinction est importante pour l'apprentissage institutionnel. Si l'annulation est racontée comme un échec technologique total, des preuves de terrain utiles peuvent être rejetées. Si elle est racontée comme un simple changement de marque, les échecs de contrôle peuvent disparaître. Une clôture responsable identifie les exigences qui étaient valides, les hypothèses d'architecture qui ont échoué, les composants qui restent soutenables, les contrats qui doivent être clos et les preuves qui devraient guider le successeur.

Le plan successeur de surveillance technologique de la frontière de l'Arizona utilisait un menu de technologies plutôt que le modèle intégré d'origine. Des rapports ultérieurs du GAO et de l'IG du DHS ont encore trouvé des faiblesses de planification et de mesure. Cette continuation ne fait pas de SBInet la cause de tous les problèmes ultérieurs. Elle montre que changer le portefeuille d'équipements ne répare pas automatiquement la discipline d'acquisition.

La réinitialisation de la gouvernance ne serait complète que lorsque le nouveau plan pourrait documenter les alternatives, les bénéfices attendus de la mission, les calendriers, les coûts du cycle de vie, les mesures de performance et les évaluations opérationnelles. Un ensemble différent de tours n'est pas un système de responsabilité différent à moins que les preuves de décision ne changent également.

Le risque public était plus large qu'un appareil cassé

Les risques publics directs de SBInet étaient des risques de gestion et de capacité. Les fonds alloués pouvaient être engagés sans preuve fiable de valeur. Le déploiement pouvait être retardé tandis que les systèmes existants continuaient à porter la mission. L'agence pouvait mettre à l'échelle une architecture qui n'avait pas démontré de performances intégrées. Des changements répétés pouvaient affaiblir la confiance dans la gestion technologique du DHS.

Ces risques ne doivent pas être convertis en affirmations non étayées sur la migration, la criminalité ou des incidents frontaliers spécifiques. Les sources officielles ont discuté de l'objectif de détecter et de répondre aux entrées illégales, mais ce compte rendu n'attribue pas un passage, une arrestation ou un résultat de sécurité particulier à un défaut de SBInet.

La distinction est une force, pas une limitation. La responsabilité publique n'exige pas d'inventer un événement dramatique en aval. Une acquisition peut imposer un risque sérieux en consommant du temps, du budget et de l'attention organisationnelle tout en échouant à prouver que la capacité promise arrivera.

Elle peut également créer des coûts opérationnels cachés. Les agents travaillant autour de communications peu fiables, les opérateurs compensant le comportement des capteurs, les mainteneurs gardant en vie un mélange d'équipements existants et nouveaux, et les gestionnaires reconstruisant des calendriers incertains utilisent tous une capacité rare. Ces effets doivent être mesurés plutôt que supposés, mais ils appartiennent à une analyse complète du cycle de vie.

La légitimité institutionnelle est affectée lorsque les déclarations publiques restent larges tandis que la portée livrée se rétrécit. Les responsables peuvent avoir des raisons de sécurité valides de ne pas divulguer les détails de performance sensibles. Ils peuvent toujours fournir aux organes de contrôle des preuves contrôlées sur les coûts, le calendrier, la rigueur des tests et les critères de décision.

La norme publique n'est pas que chaque programme technologique doive réussir. Une intégration complexe révélera des défauts. La norme est que l'incertitude est rendue visible, les utilisateurs opérationnels influencent les preuves, les contractants sont supervisés, et les dirigeants arrêtent ou remodèlent le programme lorsque le dossier de valeur n'est plus crédible.

La responsabilité suit le contrôle pratique

La responsabilité de SBInet était distribuée, mais le contrôle pratique peut encore être identifié. La direction du DHS contrôlait le cadre d'investissement et la décision d'évaluer ou d'arrêter le programme. La CBP possédait la mission et l'organisation d'acquisition. Le bureau du programme SBInet contrôlait les exigences, la supervision des ordres de mission, les bases de référence et les recommandations de jalons. Boeing contrôlait une grande partie du travail d'intégration et des preuves du contractant. Les utilisateurs de la patrouille frontalière contrôlaient les retours opérationnels essentiels.

Les organisations de test et d'audit remettaient en question la qualité des preuves.

La responsabilité doit suivre les décisions que chaque entité pouvait prendre. Un contractant est responsable du travail et des représentations dans le cadre du contrat. Il n'est pas l'autorité finale pour savoir si un seuil sert la mission publique. Les opérateurs sont responsables d'une évaluation disciplinée, mais ils ne peuvent pas corriger une estimation de coût structurellement peu fiable. Les auditeurs peuvent identifier les faiblesses, mais les cadres du programme possèdent la réponse.

Le contrôle le plus conséquent était l'autorité de mise à l'échelle. L'expansion engage de l'argent et rend les hypothèses de conception plus difficiles à inverser. L'institution qui l'autorise aurait dû exiger un dossier de preuves intégré: scénarios de mission stables, exigences tracées, composants qualifiés, défauts contrôlés, résultats de terrain représentatifs, estimations fiables des coûts et du calendrier, planification de la maintenance et une comparaison des avantages.

Aucun artefact favorable unique ne devrait se substituer au dossier. Un test d'acceptation réussi peut ne pas prouver la maintenabilité. Une estimation de coût peut être bien documentée mais reposer sur des performances non prouvées. Un retour utilisateur positif peut être local et conditionnel. La valeur réside dans la cohérence des preuves.

Ce cadre empêche également que le blâme ne s'effondre sur une caméra défectueuse, une équipe logicielle ou un cadre. Le dossier de SBInet montre des faiblesses de contrôle interactives sur plusieurs années. La responsabilité pratique demande qui pouvait voir chaque faiblesse, qui pouvait exiger une correction et qui a autorisé l'engagement suivant.

Un meilleur portail de preuves avant la mise à l'échelle

Les futures acquisitions publiques de surveillance peuvent tirer un modèle de contrôle concret de SBInet.

Premièrement, définir des scénarios opérationnels avant de sélectionner une architecture. Le terrain, les communications, les types de cibles, la charge de travail des opérateurs, l'accès à la maintenance et les procédures de réponse doivent façonner l'exigence.

Deuxièmement, maintenir une traçabilité bidirectionnelle. Chaque exigence de composant et de logiciel doit se connecter vers le haut à un besoin d'utilisateur et vers le bas à un cas de test. Les changements doivent préserver la justification et l'autorité d'approbation.

Troisièmement, séparer l'acceptation technique, contractuelle et opérationnelle. Chaque portail doit indiquer ce qu'il prouve, ce qui reste non prouvé et quelles actions suivantes sont autorisées.

Quatrièmement, mesurer la maturité des défauts. Les défauts doivent avoir une gravité, un effet opérationnel, un propriétaire, une version cible et des preuves de clôture. La tendance doit informer l'état de préparation, pas seulement le nombre de tickets fermés.

Cinquièmement, rendre les estimations de coûts et de calendrier suffisamment complètes pour les décisions. La main-d'œuvre gouvernementale, l'effort du contractant, l'infrastructure, les logiciels, la formation, la maintenance, le chevauchement des systèmes existants et le risque doivent être visibles. Le calendrier doit identifier les dépendances, le chemin critique et l'incertitude.

Sixièmement, préserver l'autorité technique gouvernementale. Les contractants peuvent intégrer le système, mais le personnel fédéral doit posséder les exigences, l'acceptation, le risque et le dossier de décision.

Septièmement, utiliser le déploiement incrémental comme une expérience avec des objectifs d'apprentissage explicites. Un incrément doit répondre à des questions définies avant que l'expansion suivante ne commence.

Enfin, exiger une décision de mise à l'échelle qui peut échouer. Si les preuves ne soutiennent pas l'expansion, le défaut devrait être une pause, une refonte ou un arrêt, pas une réinterprétation de la promesse initiale.

Ces contrôles ne garantissent pas le succès. Ils rendent l'échec informatif et limitent le coût de la découverte qu'une architecture est erronée. Ils donnent également aux dirigeants une base défendable pour continuer lorsque les preuves sont solides.

Conclusion: Une clôture virtuelle doit être prouvée sur le terrain

SBInet a été construit autour d'une idée attrayante: intégrer des capteurs et des logiciels pour qu'une vaste frontière devienne plus visible et que les agents puissent répondre avec de meilleures informations. L'idée n'a pas été réfutée simplement parce que l'acquisition initiale a pris fin. Le dossier du programme montre à quel point il est difficile de transformer cette idée en une infrastructure publique fiable.

Le projet 28 a livré de l'équipement et une capacité limitée, mais il a également exposé des problèmes d'intégration, d'exigences et opérationnels. Les blocs ultérieurs portaient une promesse plus grande tandis que la portée et les attentes de performance changeaient. Les contrôles de coûts et de calendrier n'ont pas donné aux dirigeants des prévisions fiables. La supervision des contractants et des jalons n'a pas constamment préservé les preuves nécessaires à une expansion confiante.

Le DHS a finalement changé la question de savoir comment continuer SBInet à savoir si l'architecture était le bon investissement. Mettre fin au programme tel qu'il avait été conçu à l'origine était un aveu que les preuves existantes ne justifiaient pas le modèle de mise à l'échelle initial.

La leçon n'est pas que les gouvernements doivent éviter la technologie complexe. La surveillance des frontières, les systèmes météorologiques, les répartitions d'urgence et les services numériques publics dépendent tous de l'intégration. La leçon est que la complexité augmente le fardeau de la preuve.

Une tour n'est pas une couverture. Une détection radar n'est pas une identification. Une icône de carte n'est pas une réponse opérationnelle. Un jalon contractuel n'est pas une valeur de mission. Un pilote n'est pas une architecture nationale.

La capacité publique commence lorsque ces liens peuvent être démontrés dans des conditions représentatives, avec un coût connu, des défauts contrôlés, des utilisateurs formés, une maintenance durable et un calendrier qui reflète les dépendances réelles. Jusque-là, la clôture virtuelle est une revendication d'acquisition.

SBInet a fait de la décision de mise à l'échelle l'artefact central de responsabilité. Les institutions ayant un contrôle pratique devaient décider si les preuves de terrain étaient suffisamment solides pour justifier le mile suivant. Lorsque ces preuves manquaient, arrêter l'expansion n'était pas un abandon de la responsabilité. C'était l'exercice de celle-ci.

SBInet: des capteurs de frontière virtuelle comme test de redevabilité des acquisitions